If the SQL Server database is the heart of
Configuration Manager, WMI is its lifeblood. Windows Management
Instrumentation has been the core management infrastructure for all
Windows desktop and server operating systems beginning with Windows
2000, and it’s available for download for use with earlier versions of
Windows. WMI is the Windows implementation of Web-Based Enterprise
Management (WBEM). WBEM is a set of standards intended to provide the
basis for cross-platform interoperability of technologies to exchange
management data and access management interfaces across distributed
computing environments.
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:
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.
|
WMI provides its own query
language that allows you to query managed objects as data providers.
WMI Query Language (WQL) is essentially a subset of SQL (Structured
Query Language) with minor semantic changes. Unlike SQL, WQL does not
provide statements for inserting, deleting, or updating data and does
not support stored procedures. WQL does have extensions that support WMI
events and other features specific to WMI. WQL is the basis for
Configuration Manager queries, whereas SQL is used for ConfigMgr
reports. One important advantage of WQL is that a WQL query can
return WMI objects as well as specific properties. Because management
applications such as the Configuration Manager console interact with WMI
objects, WQL queries can return result sets that you can use within the
ConfigMgr infrastructure. For example, Configuration Manager
collections are based on WQL queries. For more information about WQL,
see http://msdn.microsoft.com/en-us/library/aa394606(VS.85).aspx.
|
Figure 1 shows the basic data flow in WMI:
1. | Management applications submit a request to the WMI infrastructure, which passes the request to the appropriate provider.
|
2. | The provider then handles the interaction with the actual system resources and returns the resulting response to WMI.
|
3. | WMI
passes the response back to the calling application. The response may
be actual data about the resource or the result of a requested
operation.
|
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:
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.
