Windows Management Instrumentation: The Journey Begins

Use wbemtest.exe to determine WMI namespaces

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 Architecture
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%system32wbem 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_NTEventlogFile classes. Each Win32_NTLogEvent record is associated with one Win32_NTEventlogFile log. The Win32_NTLogEventLog association defines the relationship between the Win32_NTEventlogFile 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, rootcimv2, rootdefault, rootsecurity, and rootwmi. Other applications and technologies can introduce namespaces to extend the CIM (e.g., the rootSFUAdmin 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%system32wbem directory on every WMI-enabled machine. The following steps show you how to use wbemtest.exe to determine WMI namespaces on a target computer.

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, rootcimv2, 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.

I've merely scratched the surface of the things you can learn and do when you use wbemtest.exe. I encourage you to try some of wbemtest.exe's other options, such as using the wbemtest.exe Query button for WMI Query Language queries. You can also use Windows Script (WS) to perform the previous two exercises. I think you'll find that completing the exercises is easier to script than it was using wbemtest.exe.

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.