Windows Management Instrumentation: The Journey Begins

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%\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.