I'm having a difficult time using Windows Management Instrumentation (WMI) for much more than retrieving data. I want to change the Description field in Server Manager and the Comments field in Network Neighborhood and My Network Places on all our servers. I tried modifying the Description property that the Win32_ComputerSystem class defines, as Listing 1 shows, but that didn't do the trick. In fact, the script ran without errors, but it failed to change the Description field. Am I using the wrong class and property?
Yes, you're using the wrong WMI class and property to implement the changes you're trying to make. Instead, you must use the Win32_OperatingSystem class Description property. To fix your script, simply replace Win32_ComputerSystem with Win32_OperatingSystem, as Listing 2 shows. That's the good news.
The bad news is that some WMI read-only properties (e.g., the read-only properties that the Win32_ComputerSystem and Win32_OperatingSystem classes define) don't generate error messages as they should. That is, if you try to write to a read-only property, no error is returned.
To work around this problem, your best course of action is to verify that the property you're trying to modify is writable before you create a script to try to change it. But before you can verify writable properties, you must identify them in WMI classes by examining the property's Write qualifier. If the property's Write qualifier is set to TRUE, you can modify the property's value by using the same basic approach that you employed in Listing 1. However, most of the properties that WMI exposes are read-only. In fact, of the 4395 defined properties across 287 or so dynamic classes in the root\cimv2 namespace in Windows 2000, only 39 properties*fewer than 1 percent*are writable. Before you ask, "If I can't modify it, what's the point?" let me remind you that WMI's usefulness and breadth of coverage is constantly increasing. For example, in Windows XP, WMI defines a total of 6560 properties across 414 dynamic classes in the root\cimv2 namespace. Of those properties, 145 are writable. Web Table 1 (http://www.winscriptingsolutions.com, InstantDoc ID 27340) shows the total number of properties and the total number of writable properties in the root\cimv2 namespace for four different Windows platforms. See Web Table 2 for lists of the writable properties and their corresponding classes in Win2K and Windows NT 4.0 Service Pack 4 (SP4) with WMI 1.5.
To verify that a property is writable, you can use one of the WMI tools, such as WMI Tester (wbemtest.exe), WMI CIM Studio, or WMI Command-line (wmic.exe). WMI Tester exists on every WMI-enabled computer; you can find it in the %systemroot%\system32\wbem directory. WMI CIM Studio is part of the WMI software development kit (SDK) and the WMI Administrative Tools package. (If you don't want to download and install the entire WMI SDK, you can download only the WMI Administrative Tools from the Microsoft Download Center at http://www .microsoft.com/downloads/release.asp?releaseid=40804.) WMI Command-line is available only with XP.
You can also write WMI scripts to dump relevant information directly from the Common Information Model (CIM) repository. That's precisely what I did to collect the numbers that Web Table 1 shows and the list of writable properties that Web Table 2 shows. I adapted several scripts from "WMI Scripting Primer: Part 2," which you can find on the Microsoft Web site at http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting08132002.asp?frame=true.
The following steps describe how to use WMI Tester to examine the Win32_OperatingSystem class's Description property to verify that it's writable. Before you start, ensure that you're logged on with administrator privileges. (I based these steps on the version of WMI Tester that ships with XP. However, I specify in the steps which labels are different in Win2K and NT 4.0.)
- Open a command prompt and type
C:\>wbemtest.exePress Enter to open the Windows Management Instrumentation Tester window. Most of the buttons and options will be disabled, which means that you aren't connected to WMI.
- Click Connect to connect to the Windows Management service on a local or remote computer. The Connect dialog box includes a Namespace text entry field (on Win2K and NT 4.0 machines, the field is labeled Server\Namespace) that displays root\default as its initial value. Change the Namespace value to root\cimv2. Click Connect (in Win2K and NT 4.0, click Login) to return to the main WMI Tester dialog box. The Namespace: identifier field displays root\cimv2, and all options in the dialog box are enabled, which signals that you're connected to WMI on the local computer under the context of your current credentials.
- Click Enum Classes to open the Superclass Info dialog box. Leave the Enter superclass name field blank. Select Recursive, then click OK. The Query Result dialog box that appears lists all classes that the root\cimv2 namespace*the namespace you connected to in Step 2*defines. The number of classes that appear in the Query Result dialog box will match the value you find in Web Table 1 under the appropriate OS column and Classes row.
- Scroll down to the Win32_OperatingSystem class, then double-click the class name to open the Object Editor dialog box, which contains the definition for the class.
- Select the Hide System Properties check box to hide the WMI system properties.
- In the Properties list, scroll down to the Description property for the Win32_OperatingSystem class. Select the Description property, then click Edit Property to open the Property Editor dialog box. The property qualifiers for the Description property appear at the bottom of the Property Editor dialog box, as Figure 1 shows. The Description property's write qualifier is set to TRUE, which means that the property is one of 39 that you can modify under Win2K and NT 4.0 SP4.
Without the list that Web Table 2 shows, you must go through a similar process for any property you want to change. Note that the table lists only the properties that the root\cimv2 namespace defines. If you're working in another namespace, you must identify and verify writable properties as I've described.