System Center Configuration Manager 2007 : Configuration Manager and WMI (part 1) - WMI Feature Set and Architecture

The Distributed Management Task Force (DMTF) supports WBEM. This group is an industry consortium created to promote standardization and integration of enterprise and Internet management technology. For more information about WBEM in general and the DMTF, see http://www.dmtf.org/about/faq/general_faq.

• WMI architecture— This includes describing the WMI feature set, reviewing the major components of WMI, and discussing how they interact.

• WMI object model— The WMI object model and its implementation are discussed, with several tools you can use for managing WMI and looking into its inner workings.

• ConfigMgr use of WMI— Configuration Manager’s use of WMI is discussed, with how you can look inside ConfigMgr through its WMI interfaces.

WMI Feature Set and Architecture

WMI serves as an abstraction layer between management applications and scripts and the physical and logical resources they manage. WMI exposes managed resources through a COM (Component Object Model) API (application programming interface). Programs written in C/C++ can call these resources directly, or you can access them through intermediate layers from applications such as scripts, Windows forms, or web forms. WMI presents a consistent and extensible object model to represent a wide variety of system, network, and other resources.

Using an object model removes much of the complexity that would otherwise be required to access and manipulate these resources. Some examples of resources you can manage through WMI include hardware devices, running processes, the Windows file system and Registry, and applications and databases.

You can invoke WMI services in several ways:

• Locally on a machine

• Remotely through a DCOM (Distributed COM) connection

• Remotely using a WS-Management (Web Services for Management) connection

Configuration Manager 2007 uses all three of these access methods to connect to WMI. 

WS-Management is a Simple Object Access Protocol (SOAP)–based specification published by the DMTF. SOAP is a standard for invoking objects remotely over a Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) connection. The main advantage of SOAP is that it works across many existing network firewalls without requiring additional configuration. A complete description of WS-Management and related specifications can be found at http://www.dmtf.org/standards/wsman.

The ConfigMgr Out of Band (OOB) management point and OOB console use WS-Management to connect to the OOB management controller on systems equipped with Intel vPro technology.

WMI supports requests from management applications to

• Retrieve or modify individual data items (properties) of managed objects;

• Invoke actions (methods) supported by managed objects;

• Execute queries against the data set of managed objects;

• Register to receive events from managed objects.

Figure 1 shows the basic data flow in WMI:

Figure 1. How WMI accepts a request from a management application and returns a response from a managed resource

WMI Providers

WMI providers are analogous to device drivers in that they know how to interact with a particular resource or set of resources. In fact, many device drivers also act as WMI providers. Microsoft supplies several built-in providers as part of Windows, such as the Event Log provider and File System provider. You will see providers implemented in the following ways:

• As DLLs (Dynamic Link Libraries)

• As Windows processes and services

Just as the WMI infrastructure serves management applications through a COM interface, providers act as COM servers to handle requests from the WMI infrastructure. When a provider loads, it registers its location and the classes, objects, properties, methods, and events it provides with WMI. WMI uses this information to route requests to the proper provider.

The WMI Infrastructure

Figure 2 displays the main logical components of the WMI infrastructure. The core of the WMI infrastructure is the Common Information Model Object Manager (CIMOM), . CIMOM brokers requests between management applications and WMI providers, and communicates with management applications through the COM API, as described earlier in the “WMI Feature Set and Architecture” section. CIMOM also manages the WMI repository, an on-disk database used by WMI to store certain types of data. Beginning with Windows XP, WMI also includes an XML (eXtensible Markup Language) encoder component, which management applications and scripts can invoke to generate an XML representation of managed objects.

Most files used by WMI are stored on the file system by default under the %windir%\System32\Wbem folder. The executable containing the WMI service components is Winmgmt.exe. The physical implementation of the WMI infrastructure varies, depending on the version of Windows you are running. In Windows NT and Windows 2000, Winmgmt runs as a separate Windows service. In these earlier versions of Windows, WMI providers are loaded into the Winmgmt process space, which means that a fault in one provider can crash the entire WMI process. This can cause repository corruption, which is a common cause of WMI problems in earlier Windows implementations. Using a single process space also means that providers share the security context of the Winmgmt process, which is generally the highly privileged Local System account.

Newer versions of Windows achieve greater process isolation by loading providers into one or more instances of WMIPrvse.exe. All WMI service components beginning with Windows XP run inside shared service host (SVCHOST) processes. Windows Vista introduced several significant enhancements in WMI security and stability, including the ability to specify process isolation levels, security contexts, and resource limits for provider instances. These enhancements are also available as an update for Windows XP and Windows Server 2003 systems at http://support.microsoft.com/kb/933062.

Configuration parameters for the WMI service are stored in the system Registry subtree HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM. The WMI repository is a set of files stored under %windir%\System32\Wbem. The exact file structure varies slightly depending on the Windows version. WMI uses a customized version of the Jet database engine to access the repository files.

WMI also provides detailed logging of its activities. Prior to Windows Vista, log entries were written in plain text to files in the %windir%\System32\Wbem\logs folder. In Windows Vista and Windows Server 2008, most of these logs no longer exist, and Windows Event Tracing makes log data available to event data consumers, including the Event Log Service. By default, event tracing for WMI is not enabled.