Microsoft's Windows Management Instrumentation (WMI) gives you the ultimate control over Windows systems management. WMI is Microsoft's implementation of the Distributed Management Task Force's (DMTF's) Web-Based Enterprise Management (WBEM) initiative. WBEM is a set of open, industry-defined specifications that unify and extend the management of enterprise-computing environments.
(For more information about WBEM and WMI, see "Related Articles in Previous Issues," page 161.) Over the next few months, I'll embark on a WMI journey that covers WMI scripting from beginning to end. Let's start this trek with an introduction to the Common Information Model (CIM), which is the center of WMI's universe.
The CIM defines the managed environment and every piece of data that WMI exposes. Before I examine the CIM's internal structure and how it relates to scripting, you need to learn the basics about WMI's architecture and how WMI's other major components interact with the CIM.
WMI's major components include the CIM, the CIM Object Manager (CIMOM), providers, managed objects, and consumers, as Figure 1, page 160, shows. The Windows Management service, which is winmgmt.exe on the Windows platform, performs the CIMOM role. You can think of the CIMOM as the WMI information broker because the CIMOM provides the common interface through which consumers access WMI. Consumers call into the CIMOM to mine data, subscribe to events, or perform other management-related tasks that WMI provides. The CIMOM obtains provider and class information from the CIM to service the consumer's request, and uses the information to relay the consumer's request to the appropriate provider.
Providers are DLLs or executables (EXEs) that render a layer of abstraction between a managed object and WMI's infrastructure. Providers hide the implementation details that are unique to a given management methodology or protocol (e.g., Win32 APIs, Windows Driver Model—WDM, SNMP, Desktop Management Interface—DMI). A provider uses native APIs to communicate with its object and WMI-programming interfaces to communicate with the CIMOM. Software developers for WMI providers use the Managed Object Format (MOF) syntax to describe the management data that their applications or devices provide. The MOF file undergoes a compilation process that writes the data definition into the CIM. After the CIM receives the data definition, WMI-compliant consumers can access the data. The DLL or EXE provider fetches the application or device data for the CIMOM on the behalf of a consumer.
Managed objects are applications, devices, or resources (e.g., event logs, performance counters, the Registry, Microsoft Windows Installer, Active Directory—AD, the Win32-based computer system) that WMI exposes and manages. Because these applications, devices, and resources are WMI-managed objects, they all have associated MOF files and providers that communicate with the objects. Table 1, page 160, lists the providers that Windows 2000 supplies. You can find WMI providers and associated MOF files in Win2K's \%systemroot%\system32\wbem folder.
Consumers (i.e., subscribers) are the management applications that mine, analyze, and present WMI data. Management applications include traditional Win32 applications, such as the Microsoft Management Console (MMC) snap-in, third-party systems management applications, Web-based applications, and scripts. Consumers can also subscribe and respond to WMI events, which are realtime notifications that a change triggers. WMI events can be fired and returned to a subscribing consumer when a new event is written to any one of the event logs, when a Registry key or value is modified, or when a change occurs to almost any piece of data that WMI exposes. I'll cover this powerful WMI feature in detail in a future column as part of this series.
The Common Information Model
The CIM is the data model for the WMI-managed environment. You need a basic understanding of the CIM so that you can open and navigate your way through it and use the WMI Scripting API effectively. For more detailed information about the CIM, visit the DMTF Web site at http://www.dmtf.org and see Winston Bumpus et al., Common Information Model: Implementing the Object Model for Enterprise Management (John Wiley & Sons, 1999).
You can think of the CIM as a database, with a few key differences. Let's compare it with a Microsoft SQL Server database, which has a schema that defines the database structure. The SQL Server database schema includes table definitions with field names and data types, primary and foreign keys, and relationships between tables. The database also provides the backing store for the data; the database stores data as records.
In the WMI universe, the CIM is WMI's schema; Figure 2 shows a small piece of this schema. The CIM defines the data structure that comprises the managed environment. Unlike the SQL Server database's table-based schema definition, classes define the CIM. A class is a collection of properties and methods that model a managed object. For example, the Win32_NTLogEvent class that I used in "Windows Script Files in Action," June 2000, is a CIM class. This class defines a collection of properties that map to the fields in one event-log entry or record (e.g, Logfile, RecordNumber, Category, CategoryString, ComputerName, Data, EventCode, EventIdentifier).
The default CIM schema is extensive and includes more than 600 class definitions. However, many of these classes don't map directly to a managed physical or logical element. More than half of the classes are abstract classes that represent the foundation that other classes derive or inherit from. You can think of the CIM as a hierarchical, object-oriented class store that follows an inheritance model, much like C++.
The DMTF maintains the set of core and common CIM classes that other classes derive from. The core and common classes are generic representations of managed objects. Third parties, including Microsoft, inherit from the base set of abstract classes to define platform-specific extension classes for their managed environment. Properties and methods that the common DMTF classes define and that meet a vendor's needs remain unchanged in the new class that the vendor defines. If a class definition is deficient, the vendor defines properties and methods in addition to those that the parent class defines.
Like the relationships between tables in a database, CIM classes support a similar concept through associations. Associations are themselves classes that define a relationship between two classes. Association classes model the dependencies between WMI-managed objects and provide the mechanism to programmatically determine how system components and applications relate and interact with one another. For example, the Win32_NTLogEventLog class is an association between the Win32_NTLogEvent and Win32_NT EventlogFile classes. Each Win32_NTLog Event record is associated with one Win32_NTEventlogFile log. The Win32_ NTLogEventLog association defines the relationship between the Win32_NT EventlogFile log property and Win32_ NTLogEvent record property.
In terms of storage, the database is the storage facility for SQL data. You use records to write data to and retrieve data from the database. WMI doesn't have a similar storage facility because WMI data is dynamic.
Users often refer to the CIM as the object repository, but it's primarily a class store. The CIM stores the class definitions that define the managed environment. Instead of retrieving the data from a physical device as SQL Server does, WMI providers retrieve WMI data in realtime from native repositories such as AD (ntds.dit), event logs (.evt files), Registry hives, and Win32 APIs. You can store static data in the CIM, but the computational overhead to store and retrieve data directly from the CIM is high.
WMI uses a format it calls instances to return WMI data to a requesting consumer. Unlike the record-based format that databases employ to return data, instances are initialized occurrences of CIM classes. Properties that a class defines contain data, providing data exists. (Just because a class exists for a given hardware or software object doesn't mean data exists.) WMI packages class instances, even single-instance objects (e.g., Win32_LogicalMemoryConfiguration), as collections that you can easily enumerate in script.
You need to know about one final WMI concept—namespaces. A WMI namespace is a logical grouping of related classes. For example, consider Microsoft's Active Directory Service Interfaces (ADSI) namespaces (e.g., Lightweight Directory Access Protocol—LDAP, WinNT, Novell Directory Services—NDS). Each ADSI namespace represents a well-defined area of management that relates to a specific Directory Service (DS). Like an ADSI namespace, a WMI namespace is a mechanism that defines the scope of a specific management area. As Figure 2 shows, WMI includes several default namespaces, such as root, root\cimv2, root\default, root\security, and root\wmi. Other applications and technologies can introduce namespaces to extend the CIM (e.g., the root\SFUAdmin namespace in Figure 2). Table 1 provides a list of default WMI namespaces and the providers servicing those namespaces.
Exploring WMI with Wbemtest.exe
You might wonder how all this information relates to scripting. Consider the following three high-level steps: connect to the Windows Management service, execute a WMI query or request class instance data, and enumerate the query results. These three steps represent common actions that you find in many WMI-based scripts. The first step implies that you must identify the namespace that contains the target classes, so you need to understand WMI namespaces and what they contain. The second step includes identifying the target class and methods or properties the class provides. You therefore need to know how to obtain the class definition. The last step involves enumerating the returned data, so you need to know that WMI returns collections that contain the class instance data. You must use enumeration to gain access to the instance data.
Let's put this information to work in an exercise that highlights the three high-level scripting steps. The tool I use in the example is wbemtest.exe, and you can find it in the \%systemroot%\system32\wbem directory on every WMI-enabled machine. The following steps show you how to use wbemtest.exe to determine WMI namespaces on a target computer.
- For best results, ensure that you log on with administrator-equivalent privileges before you use wbemtest.exe. Open a command prompt, type
and press Enter to open the Windows Management Instrumentation Tester window. The buttons are disabled on the window, which means that you haven't connected to WMI at this stage of the process.
- To connect to the Windows Management service on a local or remote computer, click Connect. The Connect dialog box shows a text entry field for Server\Namespace: that has root\default as its default value. Change the Server\Namespace: value to root. Click Login to return to the Windows Management Instrumentation Tester dialog box.
- The Namespace: identifier in the dialog box's upper left-hand corner is root. All the dialog box's options are enabled, which indicates that you connected to WMI on the local host 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, and click OK to open the Query Result dialog box. This dialog box lists all classes defined in the root namespace. The root namespace consists solely of system classes that support several WMI activities (e.g., provider registration, security, event notification). System classes are predefined CIM classes that every namespace in the WMI core includes. You can identify system classes by the two underscores that preface the class name.
- Scroll down the Query Result dialog box list until you reach the __NAME SPACE class, and double-click the class name to open the Object editor for __NAMESPACE dialog box.
- The Object editor dialog box contains the selected class' implementation details. The Object editor's Properties list contains system properties; two underscores preface property names. Select the Hide System Properties check box to hide the system properties. Only the Name property will remain in the list.
- Click Instances to open a new Query Result dialog box that lists all instances of the __NAMESPACE class directly beneath the root namespace. Compare the instances of __NAME SPACE in the Query Result dialog box to the namespaces that Figure 2 shows. The two instances' collections should be similar.
You've now completed the first part of the exercise to determine the WMI namespaces beneath the root namespace. Additional subnamespaces exist beneath these namespaces, as Figure 2 implies. Let's continue the exercise and retrieve some class instance data that a class in one of the newly discovered namespaces, root\cimv2, defines. Close the two Query Result dialog boxes and the Object editor dialog box to return to the Windows Management Instrumentation Tester dialog box, and complete the following steps.
- Repeat steps 2 through 4 from the first part of the exercise to connect to the root\cimv2 namespace on the local host and recursively enumerate the classes defined in the CIMv2 namespace. After you complete these steps, you see a new Query Result dialog box that lists more than 600 classes.
- Scroll down the Query Result dialog box list until you locate the Win32_NTLogEvent class. If this is the first time you've examined the root\cimv2 namespace, you might want to become familiar with the comprehensive set of classes that the CIMv2 namespace defines, especially the classes that have a Win32_ prefix. These classes represent the data that the Win32 provider exposes. Double-click the Win32_NTLogEvent class name to open the Object editor for Win32_NTLogEvent dialog box.
- The Object editor dialog box contains the selected class' implementation details. Select the Hide System Properties check box to hide the system properties. The remaining properties resemble the fields that make up a Win2K and Windows NT event-log record.
- Click Instances to open a new Query Result dialog box that lists all instances of the Win32_NTLogEvent class. When I completed this step, I received 5674 instances that represent the same number of events residing in my six Win2K event logs. If you want to examine the details of one instance, double-click the target instance to open Object editor for Win32_NTLogEvent.Logfile="Application",RecordNumber=1. The Object editor's Properties list contains property names and CIM data types, as well as the dynamic data the ntevt.dll Event Log provider surfaces.
|Related Articles in Previous Issues|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com/articles.|
"Leveraging Windows Management Instrumentation in Windows 2000 Professional," Summer 2000, InstantDoc ID 8819
Internals, "Inside Windows Management Interface," February 2000, InstantDoc ID 7937
Scripting Solutions, "Systems Management Panacea," April 1999, InstantDoc ID 5043
Just Manage It
WMI is as important to the Windows platform as AD is. The next time you hear Microsoft discuss lowering total cost of ownership (TCO), you can bet that WMI is the foundation that backs up that claim. To make your systems administrator job easier, wrap your brain around WMI. But if you decide that WMI scripting isn't for you, you still need to ensure that third-party systems management products you evaluate for your Windows infrastructure are WMI-compliant. Next month, I'll cover the WMI Scripting Object Model and WMI Scripting API. Make your travel plans now to continue the WMI journey.