WMI Overview
Simply put, WMI is the COM-based implementation of WBEM for the Windows platform. WMI uses the familiar Windows Open Systems Architecture (WOSA) model to abstract management applications from the underlying hardware or software that uses a set of DCOM interfaces and a set of supplied providers (as shown in Figure 1). Some of these providers query their respective devices at system startup and place static information about the devices in the CIM Object Repository (located at \winnt\system32\wbem\repository) using the CIM Object Manager (CIMOM); others query the devices dynamically when the application calls for information. A system service (WinMgmt.exe) runs as a background process to facilitate communication between the various components. This open architecture allows third parties to develop WMI providers for their own hardware and software to seamlessly integrate with Windows. For a discussion on writing your own CIM provider, see "Say Goodbye to Quirky APIs: Building a WMI Provider to Expose Your Object Info" on MSDN.
In Figure 1, you'll notice that Microsoft provides a large set of classes that are ready to use against the Windows platform. WMI also aggregates classes into collections called namespaces that allow classes to be uniquely identified within the namespace.
WMI Architecture. Management applications use the WMI automation objects to communicate with the WMI interfaces and WinMgmt.exe service. Providers are used to abstract the hardware- or software-specific information.
The WMI automation object model sits on top of the WMI DCOM interfaces and contains a simple set of generic objects, prefixed with "SWbem," that wrap the underlying COM interfaces. The most important of these objects—and the ones I'll show you in the example code—are listed in the following table:
Object |
Description |
SWbemLocator |
Used to obtain a reference to an SWbemServices object that represents the services within a namespace on a particular machine. Has ConnectServer and Security members to handle the connection and manipulate security. |
SWbemServices |
Represents the services within a namespace. Contains methods such as ExecQuery, ExecMethod, and InstancesOf to query and manipulate specific class instances. |
SWbemObject |
Represents a single WMI object instance of a class definition. Contains both generic and dynamic properties used to manipulate the object. The dynamic properties use automation to provide access to methods and properties of the specific class. |
SWbemObjectSet |
Is a collection of SWbemObject object instances that is returned through methods such as SWbemServices.ExecQuery. |
These objects are interesting because they use the SWbemLocator object to provide generic access to any class in the namespace to which you connect, while simultaneously providing dynamic binding for method and property access. This architecture simplifies the writing of management applications that query a variety of different information. You'll also note from the table that the ConnectServer method can be used to explicitly pass the security credentials you would like to use in subsequent calls to WMI. Because WMI uses the security context of the current process by default, this is particularly useful when using WMI from ASP scripts on IIS 4.0. In addition, the Security object can be used to set the authentication and impersonation levels that will be used by default.
Obviously, there is much more to be said about WMI, but I'm sure that you're anxious to get to the code. To avoid going into extensive detail, I'll simply recommend two excellent articles that will provide you with additional background information: "Windows Management Instrumentation: Administering Windows and Applications Across Your Enterprise," which is located on MSDN (msdn.microsoft.com/library/periodic/period00/wmiover.htm), and "Manage Resources with WMI," which is found in the July issue of the Visual Basic Programmers Journal.
Before you get started, you'll want to download the WMI SDK from msdn.Microsoft.com/downloads/sdks/wmi/download.asp. The SDK contains additional classes, sample applications, and a set of ActiveX controls you can embed in your own applications. Although WMI 1.5 ships with Windows 2000, NT developers can also take advantage of WMI by downloading and installing the WMI Core Software Installation on NT 4.0 found at the preceding link. Remember, though, that each server you want to query with WMI must have the core components installed.