Home > Articles

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:

  1. 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.)

  2. The provider handles the interaction with the system resources and returns the resulting response to WMI.

  3. 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

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

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:

  1. 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.

  2. Expand the Services and Applications node in the console tree. For server operating systems, expand the Configuration node.

  3. 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

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

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

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:

  1. In the Security dialog box, shown in Figure 3.5, click Advanced.

  2. In the Advanced Security Settings dialog box, click the Auditing tab.

  3. 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.

  4. Select Fail from the Type dropdown menu.

  5. Click Show Advanced Permissions to display a list of specific types of events to audit.

  6. In the Advanced dialog box, check the desired types of events from the selection of check boxes and click OK.

    FIGURE 3.6

    FIGURE 3.6 Adding permissions for a security principal.

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

FIGURE 3.7 Adding permissions for a security principal.

Follow these steps to enable WMI Trace Logging in Windows Vista and later:

  1. Open the Event Viewer (eventvwr.exe).

  2. From the View menu, select Show Analytic and Debug Logs.

  3. In the tree control, expand Applications and Service Logs -> Microsoft -> Windows -> WMI-Activity.

  4. 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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020