Export (0) Print
Expand All

WMI Scripting Library Object Model

Microsoft® Windows® 2000 Scripting Guide

The WMI scripting library consists of 19 Automation objects, 16 of which are illustrated in the WMI scripting library object model diagram shown in Figure 6.4. In many ways, you can compare the Automation objects in the WMI scripting library with the core interfaces provided by ADSI. The ADSI core interfaces, IADs and IADsContainer, provide a consistent approach to managing objects in Active Directory, irrespective of the object class and attributes. Similarly, the Automation objects in the WMI scripting library provide a consistent and uniform scripting model for WMI-managed resources.

It is important to understand the relationship between the Automation objects in the WMI scripting library (wbemdisp.dll) and the managed resource class definitions that reside in the CIM repository (cim.rep). As previously explained, managed resource class definitions are the blueprints for the computer resources exposed through WMI. In addition to defining the resources that can be managed, the blueprints define the methods and properties unique to each managed resource.

The WMI scripting library, on the other hand, provides a general-purpose set of Automation objects that scripts can use to authenticate and connect to WMI, giving the scripts to access instances of WMI-managed resources. After you obtain an instance of a WMI-managed resource using the WMI scripting library, you can access the methods and properties defined by the class definition of the managed resource - as if the methods and properties were part of the WMI scripting library itself.

Figure 6.4 WMI Scripting Library Object Model



  • The lines in Figure 6.4 point to the object that is obtained by calling a method (or accessing a property) of the originating object. For example, calling the SWbemLocator ConnectServer method returns an SWbemServices object. Calling the SWbemServices InstancesOf method returns an SWbemObjectSet collection. On the other hand, calling the SWbemServices Get method returns an SWbemObject.

The WMI scripting library object model diagram provides a great deal of insight into the mechanics of how WMI scripting works. For example, consider all of the WMI scripts presented thus far. Each script performs three basic steps common to many WMI scripts.

  1. Each script starts by connecting to the WMI service on a target computer. The scripts use the VBScript GetObject function combined with a WMI connection string consisting of the WMI moniker "winmgmts:" followed by a WMI object path to the target computer and a namespace.

    strComputer = "."
    Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

    Connecting to WMI in this way returns a reference to the SWbemServices object shown in Figure 6.4. After you obtain a reference to an SWbemServices object, you can call one of the object methods. The method you call depends on the type of WMI script you are creating. For more information about WMI script types, see "Creating Scripts Based on WMI Templates" later in this chapter.

  2. Each script retrieves instances of a WMI-managed resource using the InstancesOf method.

    Set colSWbemObjectSet = objSWbemServices.InstancesOf("Win32_Service")

    InstancesOf always returns an SWbemObjectSet collection. As shown by the line between the SWbemServices and SWbemObjectSet objects in Figure 6.4, this is one of the three WMI scripting library object types SWbemServices can return. (The other two are SWbemObject and SWbemEventSource.)

  3. Each script accesses properties of a WMI-managed resource by enumerating the instances in the SWbemObjectSet.

        Wscript.Echo "Name: " & objSWbemObject.Name
    For Each objSWbemObject In colSWbemObjectSet
        Wscript.Echo "Name: " & objSWbemObject.Name

    As illustrated in Figure 6.4, each managed resource instance in an SWbemObjectSet collection is represented by an SWbemObject. For example, if your SWbemObjectSet consists of a collection of all the services installed on a computer, two things will be true:

    • Each item in the collection will be an SWbemObject. (This is true for any SWbemObjectSet.)

    • Each object in the collection will be an instance of an installed service.

You can think of the WMI scripting library object model as your road map to WMI scripting. As you become more proficient with WMI scripting, you will learn that WMI provides multiple ways to script the same task. For example, you have seen the SWbemServices InstancesOf method used a number of times to retrieve instances of WMI-managed resources. You can use the SWbemServices ExecQuery method to do the same thing, as you will see later in this chapter.

Interpreting the WMI Scripting Library Object Model

What else does the WMI scripting library object model tell you? The object model tells you that the SWbemLocator, SWbemSink, SWbemObjectPath, SWbemNamedValueSet, and SWbemLastError objects are created using the CreateObject function. On the other hand, SWbemServices and SWbemObject can be created using the GetObject function combined with the WMI moniker and a WMI object path.

The object model also tells you that seven of the objects in the WMI scripting library expose an SWbemSecurity object, as indicated by the circle S call-out immediately beneath or to the right of the object.

Of the nineteen Automation objects in the WMI scripting library, the two most important WMI scripting objects are SWbemServices and SWbemObject. SWbemServices represents an authenticated connection to a WMI namespace on a local or remote computer. Additionally, SWbemServices plays an important role in two of the most powerful scripting features found in WMI: query and event processing.

SWbemObject is the multiple-identity object that masquerades as the managed resource you have requested. For example, if you retrieve instances of the Win32_Process managed resource, SWbemObject takes on an identity modeled after the Win32_Process class definition. In other words, each returned object will have the properties of an actual process currently running on the computer. Likewise, if you retrieve instances of the Win32_Service managed resource, SWbemObject takes on an identity modeled after the Win32_Service class. You use SWbemObject to call the methods and access the properties defined in the managed resource class definition.

The discussion that follows examines the role that the primary WMI scripting library Automation objects play in WMI scripting. As you read about each WMI scripting object and review the accompanying scripts, take a moment to examine the relationship of each object with adjacent objects in the object model diagram. After you have a basic understanding of the role of each object and how it interacts with other objects in the WMI scripting library, you will be well on your way to becoming proficient in WMI scripting.

Variable Naming Conventions

In the example scripts that accompany the WMI scripting library object descriptions, the variable names used to reference each WMI automation object follow a consistent naming convention. Each variable is named according to the Automation object name in the WMI scripting library and is prefaced with "obj" (to indicate an object reference) or "col" (to indicate a collection object reference). For example, a variable that references an SWbemServices object is named objSWbemServices. A variable that references an SWbemObject is named objSWbemObject. And a variable that references an SWbemObjectSet is named colSWbemObjectSet.

This information is important because it helps you understand the type of WMI object you are working with at any given point in a WMI script. In addition, following a consistent naming convention makes your code easier to read and to maintain. However, the object reference variable names can be whatever you choose. If you prefer variable names such as x and y, that is fine. There is no requirement stating that you must name a reference to an SWbemServices object objSWbemServices. For example, these two script snippets are functionally identical; they simply use different variable names:

strComputer = "."
Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
strComputer = "."
strComputer = "."
Set x = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

  • Note

    The following discussion does not attempt to cover every method and property provided by each Automation object in the WMI scripting library. However, this information can be found in the WMI Software Development Kit. For information about how to download the WMI SDK, see the Microsoft Windows Management Instrumentation (WMI) SDK link on the Web Resources page.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft