This chapter is from the book
This chapter is from the book
This chapter is from the book
A WMI Primer
WMI is Microsoft’s implementation of Web-Based Enterprise Management (WBEM), an industrywide initiative that provides a common technology for accessing management information across a heterogeneous enterprise estate. The group behind the standard is the Distributed Management Task Force (DMTF); for information on the DMTF and WBEM, see http://www.dmtf.org/standards/wbem. WBEM is a discovery, access, and manipulation methodology. The data model it provides access to is the Common Information Model (CIM). WMI implements CIM and provides access in accordance with WBEM.
Understanding the WMI Architecture
WMI provides a method to write programs and scripts that interact with local resources on Windows systems. It is frequently supplanted by PowerShell, which often leverages WMI to perform some of these functions. PowerShell is discussed further in the section “Interaction Between WMI and PowerShell,” later in this chapter, which discusses how ConfigMgr now allows access to its WMI interfaces via PowerShell.
WMI exposes managed resources through a COM API. Programs written in C/C++ can call these resources directly, or you can access them through intermediate layers with applications such as scripts, .NET code, 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 WMI, which has been available since Windows 2000, ensures that the scripts you write will run on the widest variety of systems, although PowerShell is becoming equally ubiquitous for supported Microsoft operating systems. PowerShell has the added benefit of supporting Microsoft’s cloud services, and PowerShell itself can use WMI.
Following are examples of what you can do with WMI:
Obtain a list of all accounts on a system and rename one of them
Get a list of running processes on the system
Extract the network configuration of a system
Using an object model removes much of the complexity that is otherwise required to access and manipulate these resources. Examples of resources that are manageable through WMI include hardware devices, running processes, the Windows file system and Registry, applications, and databases.
You can use several methods to access WMI’s services and object model, including the following:
Directly on the local machine
Remotely through a Distributed COM (DCOM) network connection
Remotely using WinRM (Windows Remote Management)
Remotely using PowerShell Remoting
ConfigMgr also relies on DCOM access for remote access and calls WMI directly on systems running ConfigMgr code.
WMI supports requests from management applications to do the following:
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 handles requests from management applications as follows:
A management application submits a request to the WMI infrastructure, which passes the request to the appropriate provider. (The next section of this chapter describes WMI providers.)
The provider handles the interaction with the system resources and returns the resulting response to WMI.
WMI passes the response back to the calling application. This may be actual data about the resource or the result of a request operation.
Figure 3.1 shows this basic data flow in WMI.
)
FIGURE 3.1 Basic WMI data flow.
WMI Providers
WMI providers are similar to device drivers in that they know how to interact with a particular resource or set of resources. Like a device driver, a provider must implement certain interfaces that WMI expects every provider to have, along with some additional ones. Microsoft supplies several built-in providers as part of Windows, such as the Event Log provider and the BitLocker Drive Encryption provider. A list of Microsoft-supplied providers is available at https://msdn.microsoft.com/library/aa394570.aspx. You will see providers implemented in the following ways:
As dynamic link libraries (DLLs)
As Windows processes and services
The idea behind creating a provider is to relieve management applications and scripts from having to be coded specifically to use an interface or a method that a developer provides. WMI providers are translation layers between management/administrative tools and applications, and they enable applications to be easily integrated in an enterprise information technology (IT) operations environment.
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 from management/administrative tools to the proper providers. Providers are then responsible for interacting with the underlying managed object, using whatever custom method the developer chose to implement.
About the WMI Infrastructure
Figure 3.2 displays the main logical components of the WMI infrastructure. The core is Common Information Model Object Manager (CIMOM), described in the “Inside the WMI Object Model” section, later in this chapter. CIMOM handles requests between management applications and WMI providers, communicating with management applications through the COM API, as described earlier, in the “Understanding the WMI Architecture” section. CIMOM also manages the WMI Repository, an on-disk database that WMI uses to store certain types of data. Dynamic data is pulled on demand from the provider when requested. Static data is stored in the WMI Repository. Providers can compile static information into this repository as part of registration; the information can be flagged for automatic recompilation.
Most files that WMI uses are stored by default on the file system in the %windir%\system32\wbem folder. The WMI Repository is a set of files located by default in %windir%\System32\wbem\repository. The exact file system structure varies slightly depending on the Windows version.
The Winmgmt executable contains the WMI service components. The physical implementation of the WMI infrastructure varies depending on the version of Windows. Beginning with Windows Vista, Microsoft 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.
)
FIGURE 3.2 The major WMI infrastructure components.
Configuration parameters for the WMI service are stored in the Windows Registry subtree HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM. The keys and values in this section of the Registry specify WMI file locations, logging behavior, the list of installed providers, the default namespace for scripts, and other WMI options. You rarely need to edit these options directly. As with any changes to the Registry, use extreme caution as such changes can destabilize your system.
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. Most of these logs no longer exist; Event Tracing for Windows (ETW) makes log data available to event data consumers, including the Event Log Service. Event tracing for WMI is not enabled by default. The “Managing WMI” section, later in this chapter, discusses logging and event tracing options for WMI and configuration of tracing for WMI.
Some WMI providers, such as the ConfigMgr provider, also log their activity. Appendix A discusses logging by the ConfigMgr WMI provider.
Inside the WMI Object Model
Understanding the WMI object model is essential for writing programs or scripts that interact with WMI. It is also helpful for ConfigMgr administrators who want a better understanding of ConfigMgr objects such as collections and client settings. CIM is the basis for the WMI object model. It defines a core model that provides the basic semantics for representing managed objects and describes several common models representing specific areas of management, such as systems, networks, and applications. Third parties develop extended models, which are platform-specific implementations of common classes. You can categorize the class definitions used to represent managed objects as follows:
Core classes represent general constructs that are applicable to all areas of management. Core classes are part of the core model and are the basic building blocks from which other classes are developed.
Common classes represent specific types of managed objects and are generalized representations of a category of objects, such as a computer system or an application. These classes are not tied to a particular implementation or technology. The CIM_ManagedSystemElement class is the most basic and general class, and is at the root of the CIM class hierarchy.
Extended classes are technology-specific extensions of common classes, such as a Win32 computer system or ConfigMgr.
WMI classes support inheritance, meaning you can derive a new class from an existing class. The derived class is often referred to as a child, or subclass, of the original class. The child class has a set of attributes available from its parent class. Inheritance saves developers the effort of needing to create definitions for all class attributes from scratch. Developers of a child class can optionally override the definition of an inherited attribute with a different definition better suited to that class. A child class can also have additional attributes that are not inherited from the parent.
Typically, core and common classes are not used directly to represent managed objects; they are used as base classes from which other classes are derived. The “The Configuration Manager Client WMI Namespace” section of this chapter presents an example of how a class inherits attributes from its parent class.
A special type of WMI class is SystemClass. WMI uses system classes internally to support its operations. They represent things such as providers, WMI events, and inheritance metadata about WMI classes.
WMI classes support three types of attributes:
Properties are characteristics of managed objects, such as the name of a computer system or the current value of a performance counter.
Methods are actions that a managed object can perform on your behalf. As an example, an object representing a Windows service may provide methods to start, stop, or restart the service.
Associations are links to a special type of WMI class, an association class, which represents a relationship between other objects.
You can also modify WMI classes, properties, and methods by using qualifiers. A qualifier on a class may designate it as abstract, meaning the class is used only to derive other classes, and no objects of that class will be created. Two important qualifiers designate data as static or dynamic:
Static data: This data is supplied in the class or object definition and stored in the WMI Repository.
Dynamic data: This data is accessed directly through the provider and represents live data on the system.
The CIM specification includes a language for exchanging management information. Managed Object Format (MOF) provides a way to describe classes, instances, and other CIM constructs in textual form. In WMI, MOF files are included with providers to register the classes, properties, objects, and events they support with WMI. The information in the MOF files is compiled and stored to the WMI Repository. Examples of information in MOF format are included in the next section.
Namespaces organize WMI classes and other elements. A namespace is a container, much like a folder in a file system. Developers can add objects to existing namespaces or create new namespaces. The root namespace defines a hierarchy organizing the namespaces on a system. The “Managing WMI” section, later in this chapter, describes the WMI Control tool, which allows you to specify the default namespace for connections to WMI. Generally, the default namespace is root\CIMv2. This namespace defines most of the major classes for Windows management, and the next section looks at several classes in that namespace. Because ConfigMgr is all about Windows management, it is not surprising that it uses this namespace extensively. ConfigMgr also defines its own namespaces, discussed in the section “Configuration Manager and WMI.”
If you are familiar with relational databases such as SQL Server, you may find it useful to consider an analogy between WMI and a database system. Table 3.1 presents some corresponding WMI and database concepts. Table 3.1 is useful when you are attempting to correlate between SMS provider information in WMI and database views in SQL Server.
TABLE 3.1 Corresponding WMI and Database Concepts
WMI Concept |
Database Concept |
WMI infrastructure |
Database engine |
Namespace |
Database |
Class |
Table |
Instance |
Row |
Attribute |
Column |
This section discussed the major concepts of WMI and the CIM model, which are essential to understanding ConfigMgr WMI activity. To learn about other aspects of CIM, you might start with the tutorial at http://www.wbemsolutions.com/tutorials/CIM/index.html. The full CIM specification is at http://www.dmtf.org/standards/cim. Documentation for WMI is available at http://msdn.microsoft.com/library/aa394582.aspx.
Managing WMI
This section illustrates options available for configuring WMI; it is not a “how-to” guide for administering WMI. You should seldom need to modify the WMI settings directly during day-to-day ConfigMgr administration. However, understanding WMI’s options can help you understand its inner workings and functionality.
WMI Control is a graphical tool for managing the most important properties of the WMI infrastructure. Only members of the local Administrators group can use WMI Control. To run this tool, perform the following steps:
Launch the Computer Management MMC snap-in (compmgmt.msc). The exact procedure varies depending on the version of Windows you are running. Generally, you can right-click Computer or My Computer and choose Manage.
Expand the Services and Applications node in the console tree. For server operating systems, expand the Configuration node.
Right-click WMI Control and choose Properties.
WMI Control opens to the General tab. As shown in Figure 3.3, the properties on this tab confirm that you have successfully connected to WMI on the local machine, display some basic properties of your system, and specify the installed version of WMI.
)
FIGURE 3.3 The General tab for WMI Control shows a successful connection to WMI on the local machine.
You manage WMI security from the Security tab of the WMI Control tool. WMI uses standard Windows ACLs to secure each WMI namespace existing on a machine. A namespace, as described further in the “Inside the WMI Object Model” section of this chapter, is a container that holds other WMI elements. The tree structure in the Security tab shows the WMI namespaces (see Figure 3.4).
)
FIGURE 3.4 The Security tab of the WMI Control tool, displaying the top-level WMI namespaces.
The namespace is the most granular level for applying ACLs in WMI. The process of setting security on WMI namespaces, and the technology behind it, is similar to the process of setting NT File System (NTFS) security. If you click a namespace to select it and click Security, you see a dialog box similar to the one displayed in Figure 3.5.
FIGURE 3.5 The WMI ACL entries for root\CIMv2, the main WMI namespace.
The dialog box in Figure 3.6 allows you to add security principals to the discretionary ACL (DACL) of the WMI namespace. The DACL specifies who can access the namespace and the type of access. Windows Vista enhancements to WMI, mentioned earlier in this chapter, in the section “Understanding the WMI Architecture,” include a system access control list (SACL) for WMI namespaces, which specifies the actions audited for each security principal.
To specify auditing on a WMI namespace, follow these steps:
In the Security dialog box, shown in Figure 3.5, click Advanced.
In the Advanced Security Settings dialog box, click the Auditing tab.
Click Select a Principal and then enter the name of the user group or built-in security principal, as shown in Figure 3.6. Click OK.
Select Fail from the Type dropdown menu.
Click Show Advanced Permissions to display a list of specific types of events to audit.
In the Advanced dialog box, check the desired types of events from the selection of check boxes and click OK.
FIGURE 3.6 Adding permissions for a security principal.
)
){kind=link}
Figure 3.7 shows the entries to enable auditing for all access failures by members of the Domain Admins group.
The remaining tabs of the tool allow you to change the default namespace for WMI connections and provide several methods for backing up the WMI Repository. Windows system state backups also back up the repository. To enable tracing in Windows Vista and newer operating systems, enable logging and configure log options in the Windows Event Viewer.
)
FIGURE 3.7 Adding permissions for a security principal.
Follow these steps to enable WMI Trace Logging in Windows Vista and later:
Open the Event Viewer (eventvwr.exe).
From the View menu, select Show Analytic and Debug Logs.
In the tree control, expand Applications and Service Logs -> Microsoft -> Windows -> WMI-Activity.
To enable the Trace event log, right-click Trace and select Enable Log from the context menu. Choose Log Properties from that menu to configure logging properties for WMI. You can now view, filter, and manage the WMI log from this node in the Event Viewer tree.
Enabling WMI activity tracing causes three different types of events to be generated in the WMI activity. These logs show the start, middle, and end of a single sequence (or WMI session). Following are the possible event IDs for these events:
Event ID 1: This event shows the start of the WMI session. The key event fields are User and Namespace. The User event field allows you to focus on only the operation sessions that you are looking for (as do the Operation and GroupOperationId fields if that user account is making multiple connections). The Namespace event field is important when similarly named classes are in two different namespaces, as the next event does not provide you with details of the namespace used.
Event ID 2: This event shows the actual operations performed. There may be one or more Event ID 2 events generated, depending on the behavior of the application or script using WMI. These events contain ProviderName and Path fields. The Path field indicates the path to the WMI object called.
Event ID 3: This event shows the end of the WMI session. The only event field that this event contains is GroupOperationId, and it is used to indicate the session or sequence being closed.
Read more about WMI logging at http://msdn.microsoft.com/library/aa394564.aspx.
Note that User Account Control applies to privileged WMI operations. This can affect some scripts and command-line utilities. For a discussion of User Account Control and WMI, see http://msdn.microsoft.com/library/aa826699.aspx.
Additional command-line tools are available for managing WMI; see http://msdn.microsoft.com/library/aa827351.aspx.