WMI Infrastructure

Microsoft® Windows® 2000 Scripting Guide

The WMI infrastructure is the middle layer in the architectural model. WMI consists of three primary components: the Common Information Model Object Manager (CIMOM), also known as the WMI service; the Common Information Model (CIM) repository, also known as the WMI repository; and WMI providers. Together these three components provide the infrastructure through which configuration and management data is defined, exposed, accessed, and retrieved.

Note

• A related component, the WMI Scripting Library, is discussed later in this chapter.

WMI Providers

WMI providers act as an intermediary between the CIMOM and a managed resource. Providers request information from and send instructions to WMI-managed resources on behalf of consumer applications and scripts. For example, Listing 6.1 and Listing 6.3 use the built-in Win32® provider to retrieve memory and service-related information. Listing 6.4 uses the built-in Event Log provider to retrieve records from the Windows event logs.

Providers hide the implementation details unique to a particular managed resource by exposing the managed resource to the WMI infrastructure using a standards-based, uniform access model. WMI providers communicate with their respective managed resources by using the native application programming interfaces (APIs) of the managed resource, and communicate with the CIMOM by using WMI programming interfaces. For example, the built-in Event Log provider calls Win32 Event Log APIs to access event logs.

Why does this matter to you? To create an application that manages Windows subsystems, you typically use the Win32 APIs. Without WMI, you would need to call these APIs yourself. This creates at least two problems. First, Win32 APIs cannot be called from a script; as a result, you must use a programming language such as C++ or Visual Basic to manage these resources. Having to use a programming language such as C++ eliminates the benefits available through scripting:

• Scripts can be written in a matter of minutes.

• Scripts can be written using nothing more powerful than Notepad.

• Scripts can be written without requiring header files, compilers, and other items more commonly used by developers than by system administrators.

Second, the Win32 APIs do not necessarily work in a consistent manner; just because you learn how to program the Event Log APIs does not mean you have a head start in learning how to program the Win32 Service APIs. One of the difficulties in programming management applications in Windows is that different APIs must be accessed and used in different ways.

WMI providers help solve both of these problems. For one thing, you do not have to worry about calling the Win32 APIs; WMI will do that for you. Likewise, you do not have to worry about differences between various APIs; again, you use a standard set of WMI commands, and WMI will translate those commands into commands that the APIs understand. The WMI providers give you a simple and consistent way to access the Win32 APIs, even if you never realize that you are accessing the Win32 APIs.

Of course, WMI is not just for system administrators. Software developers can leverage the extensible architecture of WMI to develop and integrate add-on providers that expose the management functions unique to their products. The Exchange Server 2000 provider, which monitors Exchange connector status, is one such example. Likewise, Application Center, Operations Manager, Systems Management Server, Internet Information Services, and SQL Server all include WMI providers.

Providers are generally implemented as dynamic-link libraries (DLLs) residing in the systemroot\System32\Wbem directory. WMI includes many built-in providers for the Windows 2000 and Windows XP operating systems. The built-in providers, also known as standard providers, supply data and management functions from well-known operating system sources such as the Win32 subsystem, event logs, performance counters, and the registry. Table 6.1 lists several of the standard WMI providers included with Windows 2000 and Windows XP.

Table 6.1 Partial List of Standard WMI Providers

Windows XP includes many additional standard providers. For a complete list of standard providers, see the WMI Providers reference in the WMI Software Developers Kit (SDK) documentation. For information about downloading WMI SDK, see the Microsoft Windows Management Instrumentation (WMI) SDK link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

CIMOM

The CIMOM (pronounced see-mom) handles the interaction between consumers and providers. The term comes from the Web-Based Enterprise Management (WBEM) initiative and the Common Information Model (CIM) specification maintained by the Distributed Management Task Force (DMTF).

The CIMOM acts as the WMI information broker. All WMI requests and data flow through the CIMOM. When you write a WMI script, the script is directed to the CIMOM. However, the CIMOM does not directly handle your request. For example, suppose you request a list of all the services installed on a computer. The CIMOM will not actually retrieve the list of services for you. Instead, it will locate the appropriate WMI provider and ask the provider to retrieve the list. When the list has been retrieved, it will be handed back to the CIMOM, and the CIMOM will then return the information to you.

The WMI service (winmgmt.exe) provides the role of the CIMOM on Windows XP. It runs under the control of the generic services host process, svchost.exe.

Note

• On computers running Windows 2000 or Windows NT 4.0 with Service Pack 4 (SP4), the WMI service runs as a separate service process. On computers running Microsoft® Windows® Millennium Edition (Me), Windows® 98, or Windows® 95 OSR 2.5, WMI runs as a standard executable process.

The WMI service is similar to most operating system services; for example, it can be stopped and started using these commands:

net stop winmgmt
net start winmgmt

One interesting note: Suppose the WMI service is stopped, and you run a script or an application that requires WMI. In that case, the service will automatically restart itself.

In addition to providing the common interface through which consumers access WMI, the CIMOM provides the following core services to the WMI infrastructure:

• Provider registration. WMI providers register location and capability information with the CIMOM. The CIMOM stores this information in the CIM repository.

• Request routing. The CIMOM uses the provider registration information to route consumer requests to the appropriate provider. When a script requests information from a CIM class (such as Win32_Service or Win32_LogicalMemoryConfiguration), the CIMOM takes the query and forwards it to the provider capable of filling the request.

• Remote access. Consumers access remote WMI-enabled systems by connecting to the CIMOM on the remote system. After a connection is established, consumers can perform the same operations that can be performed locally. This is a key point: With only a few minor exceptions, anything WMI can do on the local computer it can do just as easily on a remote computer.

• Security. The CIMOM controls access to WMI-managed resources by validating each user access token before the user is permitted to connect to WMI on either the local computer or a remote computer.

• Query processing. Allows a consumer to issue queries against any WMI-managed resource by using the WMI Query Language (WQL). For example, you can query the event logs for all events matching a specific Event ID that occurred during the past 24 hours. The CIMOM performs the evaluation of the query in cases where providers do not natively support query operations.

• Event processing. Allows a consumer to subscribe to events that represent a change to a WMI-managed resource. For example, you can subscribe to an event that fires when the amount of space on a logical disk drive drops below an acceptable threshold. The CIMOM polls the managed resource at an interval you specify and generates an event notification when the subscription is satisfied.

Management applications, administrative tools, and scripts make requests to the CIMOM to retrieve data, subscribe to events, or to perform some other management-related task. The CIMOM retrieves the provider and class information necessary to service consumer requests from the CIM repository. The CIMOM uses the information obtained from the CIM repository to hand off consumer requests to the appropriate WMI provider.

CIM Repository

WMI is based on the idea that configuration and management information from different sources can be uniformly represented with a schema. The CIM repository holds the schema, also called the object repository or class store, that models the managed environment and defines every piece of data exposed by WMI. The schema is based on the DMTF Common Information Model standard.

Similar to the Active Directory schema, the CIM is built on the concept of classes. A class is a blueprint of a WMI-manageable resource. However, unlike Active Directory classes, which represent static objects that can be created and stored in the directory, CIM classes usually represent dynamic resources. Instances of resources are not stored in the CIM repository but are dynamically retrieved by a provider based on a consumer request. This means that the term repository is somewhat misleading in the context of the CIM. Although the CIM is a repository and is capable of storing static data, its primary role is storing the blueprints for managed resources.

The reason for this is simple: The operational state for most WMI-managed resources changes frequently and therefore must be read on demand to ensure that the most up-to-date information is retrieved. For example, WMI classes can be used to retrieve all the events from all the event logs on a computer and information about all the files stored on a computer. Storing all this information and keeping track of all the changes made to it would not be the most effective use of computer resources. Instead, it is faster and more efficient to dynamically retrieve the information each time it is needed.

Note

• Admittedly, retrieving information each time it is needed will occasionally cause queries to run slowly. For example, if you did need to enumerate all the files on a computer, this would take some time, simply because WMI would have to locate every file and retrieve information about it. However, the fact that a query such as this might run a bit slowly must be balanced against the computing resources required for and the complications involved in keeping an up-to-date copy of every managed object in the repository.

• Even though most instances must be retrieved dynamically, a typical WMI query will still be completed in a matter of seconds. (For example, it typically takes 1 to 2 seconds to return a list of all the services installed on a computer.)

Like Active Directory classes, CIM classes are organized hierarchically and child classes inherit from parent classes. The DMTF maintains the set of core and common base classes from which system and application software developers, such as those at Microsoft Corporation, derive and create system-specific or application-specific extension classes. For example, the Win32_Process class is derived from the CIM_Process class (which, in turn, is derived from CIM_LogicalElement and CIM_ManagedSystemElement).

Classes are grouped into namespaces, logical groups representing a specific area of management. For example, the root\cimv2 namespace includes most of the classes that represent resources commonly associated with a computer and an operating system. The classes used in the preceding scripts (Win32_LogicalMemoryConfiguration, Win32_Service, and Win32_NTLogEvent) reside in the root\cimv2 namespace and are just three of hundreds of classes defined in the various CIM namespaces.

Note

• Namespaces are also important in WMI security, a topic discussed later in this chapter.

CIM classes include both properties and methods. Properties describe the configuration and state of a WMI-managed resource; methods are executable functions that perform actions on the WMI-managed resource associated with the corresponding class.

In Windows 2000 and Windows NT 4.0 with SP4, the CIM is stored in systemroot\System32\Wbem\Respository\cim.rep. In Windows Millennium Edition (Me), Windows 98, and Windows 95 OSR 2.5 operating systems, the CIM repository is stored in %windir%\System\Wbem\Repository\cim.rep.

In Windows XP, the CIM repository resides in the systemroot\System32\Wbem\Repository\FS directory and consists of the following four files:

• Index.btr. Binary-tree (btree) index file.

• Index.map. Transaction control file.

• Objects.data. CIM repository where managed resource definitions are stored.

• Objects.map. Transaction control file.

Although the CIM is based on object-oriented design principles, you do not need to become an expert on information modeling or schema design to be productive using WMI and writing WMI-based scripts. However, it is important that you understand the basic structure and organization of the CIM repository and how to navigate and interpret its contents.