Common Information Model
Microsoft® Windows® 2000 Scripting Guide
If you are going to build a house, you need to know how to read and interpret an architectural drawing. If you are going to build an electronic device, you need to know how to read and interpret a schematic diagram. And if you are going to write WMI scripts, you need to know how to interpret the WMI blueprint for management: the CIM repository.
The CIM repository is the WMI schema that stores the class definitions that model WMI-managed resources.
To emphasize the importance of the CIM and CIM classes, consider the scripts in Listing 6.6 and Listing 6.7. Listing 6.6, a slightly enhanced version of Listing 6.3, returns information about the services installed on a computer.
Listing 6.6 Retrieving Service Information Using WMI and VBScript
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Listing 6.7, meanwhile, is another variation of the same basic script, this time using the Win32_OperatingSystem class. As you might expect, it returns information about the operating system currently in use on a computer.
Listing 6.7 Retrieving Operating System Information Using WMI and VBScript
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
There are only two differences between these scripts: the class name identifying the WMI-managed resource and the property values reported for each class. For example, the services script reports values for properties such as DisplayName, StartMode, and State; the operating system script reports values for properties such as LastBootUpTime, Version, and ServicePackMajorVersion.
The fact that the same script template can be used to retrieve total physical memory, services, event log records, processes, and operating system information demonstrates the important role CIM classes play in WMI scripting. After you know how to write a script to manage one type of WMI-managed resource, you can use the same basic technique to manage other resources.
Of course, knowing a managed resource class name and its corresponding properties is only part of the story. Before you can tap the full power of WMI scripting, you need to know a little bit more about the structure of the CIM repository and WMI classes for two important reasons:
Understanding how to navigate the CIM repository will help you determine the computer and software resources exposed through WMI.
Understanding how to interpret a managed resource blueprint (class definition) will help you understand the tasks that can be performed on the managed resource.
Both points are true regardless of the WMI tool you use: Whether you use the WMI scripting library or an enterprise management application, you need to know how to navigate the CIM repository and interpret WMI classes.
A less obvious yet equally important reason to learn about the CIM repository is that the CIM repository is an excellent source of documentation for WMI-managed resources. If you need detailed information about a WMI class, you can use the WMI SDK. But what if you do not need detailed information about a WMI class? Suppose you want to know only whether a specific class, method, or property is supported on the version of Windows you are managing. You can check the CIM repository of the target computer.
For example, suppose you see this script in the Script Center on Microsoft TechNet:
Const JOIN_DOMAIN = 1
Const ACCT_CREATE = 2
Set objNetwork = CreateObject("Wscript.Network")
strComputer = objNetwork.ComputerName
Set objComputerSystem = GetObject _
("winmgmts:{impersonationLevel=Impersonate}!\\" & strComputer & _
"\root\cimv2:Win32_ComputerSystem.Name='" & strComputer & "'")
ReturnValue = objComputerSystem.JoinDomainOrWorkGroup _
("FABRIKAM", "password", "FABRIKAM\shenalan", NULL, JOIN_DOMAIN+ACCT_CREATE)
You want to know whether the script will run on Windows 2000-based computers. As it turns out, it does not, because the Win32_ComputerSystem class does not support the JoinDomainOrWorkGroup method on Windows 2000. The JoinDomainOrWorkGroup method was added to the Win32_ComputerSystem class in the version of WMI included with Windows XP.
But how would you find this out, other than trying the script and having it fail? One way is by using the collection of WMI tools described in "Exploring the CIM Repository" later in this chapter. A more powerful and flexible approach is to use the WMI scripting library. One useful property of WMI is the fact that you can use the WMI scripting library to learn about WMI itself. In the same way you write WMI scripts to retrieve information about managed resources, you can write WMI scripts to learn many interesting details about WMI itself. For instance, you can write WMI scripts that list all of the namespaces and classes in the CIM repository. You can write scripts to list all of the providers installed on a WMI-enabled computer. You can even write WMI scripts to retrieve managed resource class definitions.
Whether you choose to use existing tools or create your own, you need a basic understanding of the structure of the CIM repository and its contents, as well as knowledge of how to interpret managed resource class definitions. The next section takes a closer look at the WMI blueprint for management - the CIM repository.