CHAPTER 1
Introduction to WMI in Configuration Manager 2012
In Microsoft System Center 2012 Configuration Manager, Windows Management Instrumentation (WMI) plays a major role in storing site-specific and client-related management information. WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM) and Common Information Model (CIM) standards from the Distributed Management Task Force (DMTF).
The purpose of WMI is to define a proprietary set of environment-independent specifications that allow management information to be shared between management applications. WMI prescribes enterprise management standards and related technologies for Windows operating systems that work with existing management standards, such as Desktop Management Interface (DMI) and Simple Network Management Protocol (SNMP). WMI complements these other standards by providing a uniform model. This model represents the managed environment through which management data from any source can be accessed in a common way. WMI is also the key component of System Center 2012 Configuration Manager. Management information related to site server and client is stored within WMI.
This chapter describes WMI, how the WMI tools interact with WMI, and the namespaces and classes specific to Configuration Manager 2012. This chapter builds a strong foundation for understanding WMI.
Web-Based Enterprise Management (WBEM)
Web-Based Enterprise Management (WBEM) is the Industry joint effort to provide a unifying mechanism for describing and sharing management information. Prior to WBEM, administrators of systems running on multiple platforms did not have any easy way to obtain management data from their different platforms. They had to use individual application programming interfaces (APIs) or a separate console for each management application. WBEM defines a common mechanism for sharing management information, and provides a consistent view of managed environments without locking you into one management framework, protocol, or platform.
WBEM was developed by the Desktop Management Task Force (DMTF). The two main goals motivating the DMTF to create WMEB are:
To standardize the publication of management data
To provide a standard method for accessing management information
To standardize the publication of management data, the DMTF adopted a standardized data model called the Common Information Model (CIM). CIM is an object-oriented schema for describing a system’s management objects. It offers one extensible data description mechanism for all enterprise systems, network devices, and other management tools such as applications, peripherals, and databases. CIM supports data inheritance and associations and is independent of any execution environment or programming language model.
Previously, administrators had to use customized API calls and software designed specifically for each environment that they wanted to access management data from. WBEM provides one method for accessing management data that originates from disparate sources.
Windows Management Instrumentation (WMI)
WMI provides a uniform interface for any local or remote applications or scripts that obtain management data from a computer system, a network, or an enterprise. The uniform interface is designed such that WMI client applications and scripts do not have to call a wide variety of operating system APIs. Many APIs cannot be called by automation clients like scripts or Visual Basic applications. Other APIs do not make calls to remote computers. Figure 1-1 shows the WMI architecture.
Managed objects and WMI providers
A WMI provider is a COM object that monitors one or more managed objects for WMI. A managed object is a logical or physical enterprise component, such as a hard disk drive, network adapter, database system, operating system, process, or service.
Similar to a driver, a provider supplies WMI with data from a managed object and handles messages from WMI to the managed object. WMI providers consist of a DLL file and a Managed Object Format (MOF) file that defines the classes for which the provider returns data and performs operations. Providers, like WMI C++ applications, use the COM API for WMI.
For example, the preinstalled Registry provider, which accesses data in the system registry, has one WMI class, StdRegProv, with many methods but no properties. Other preinstalled providers, such as the Win32 provider, usually have classes with many properties but few methods, such as Win32_Process or Win32_LogicalDisk. The Registry provider DLL file, Stdprov.dll, contains the code that dynamically returns data when requested by client scripts or applications.
For X86 versions of Windows, WMI MOF and DLL files are located in %WINDIR% System32Wbem. For x64 versions of Windows, these files are located in %WINDIR%Sys-WOW64Wbem together with the WMI Command-Line Tools, such as Winmgmt.exe and Mofcomp.exe. Provider classes, such as Win32_LogicalDisk, are defined in MOF files, and then compiled into the WMI repository at system startup.
WMI infrastructure
The WMI infrastructure is a Microsoft Windows operating system component. The WMI infrastructure is implemented by the WMI service (winmgmt) and includes the WMI core and the WMI repository.
The WMI repository is organized by WMI namespaces. The WMI service creates some namespaces such as rootdefault, rootcimv2, and rootsubscription at system startup and preinstalls a default set of class definitions, including the Win32 classes, the WMI system classes, and others. The remaining namespaces found on a system are created by providers for other parts of the operating system or products.
The WMI service acts as an intermediary between the providers, management applications, and the WMI repository. Only static data about objects is stored in the repository, such as the classes defined by providers. WMI obtains most data dynamically from the provider when a client requests it. You also can set up subscriptions to receive event notifications from a provider.
WMI consumers
A WMI consumer is a management application or script that interacts with the WMI infrastructure. A management application can query, enumerate data, run provider methods, or subscribe to events by calling either the COM API for WMI or the Scripting API for WMI. The only data or actions available for a managed object, such as a disk drive or a service, are those that a provider supplies.
Understanding WMI schema
Whereas the WMI object model defines how programs work with WMI, the WMI schemas define the actual implementation of WMI objects. Consider an analogy of a driving manual versus a map. A driving manual explains the techniques of driving a car; a map illustrates where the destinations are and how to get to them. The object model is analogous to a driving manual, and schemas are like maps. Understanding WMI schemas allows you to understand the relationships among the objects that WMI manages.
The DMTF defines a standard schema for WBEM called the CIM schema. This schema is implemented as the Cimv2 namespace in WMI. The CIM schema, in the form of the core and common models, provides a conceptual architecture for a managed environment. It is a framework of organizing principles that can be used by schema designers to understand and analyze the information requirements of management applications. The common model is represented by a set of abstract and concrete classes that define the basic characteristics of systems, networks, applications, and various groupings of statistical and other computer management-related data.
Figure 1-2 shows the relationship between the namespace, class, properties, method, and instance as explained above.
FIGURE 1-2 Namespace, classes, and instance relationship.
Namespaces
Namespaces contain classes and instances. Namespaces are not physical locations; they are more like logical databases. Namespaces can be nested. That is, within a namespace, there can be other namespaces that define subsets of objects.
CIM classes are organized into namespaces. Namespaces are the partitioning mechanism employed by the CIM to control the scope and visibility of managed resource class definitions. Each namespace in the CIM contains a logical group of related classes representing a specific technology or area of management.
Namespaces are roughly equivalent to folders on a disk drive. Like folders, namespaces provide a place to store related information; a folder named Scripts is likely to contain scripts and a namespace named MicrosoftActiveDirectory is likely to contain WMI classes used to manage Active Directory. Both folders and namespaces help you to uniquely identify an item. You can have only one file on a computer named C:ScriptsWMI_Script.vbs; likewise, you can have only one WMI class named rootcimv2:Win32_Process.
One difference between folders and WMI namespaces is that folders are often deeply nested; for example, it is common to have folders such as C:Program FilesMicrosoft OfficeOfficeOffice15. By contrast, namespaces rarely go more than three levels deep; the vast majority of classes useful in system administration scripts reside in the rootcimv2 namespace, a namespace nested only two levels deep.
Classes
The namespace contains the classes as explained above. All classes within a namespace must have a unique class name, and classes in one namespace cannot be derived from classes in another namespace. This is why you will find identical system, core, and common classes defined in multiple namespaces.
Instances
An instance is a particular manifestation of a class. Instances are more commonly thought of as data. Because instances are objects, the two terms are often used interchangeably. However, instances are usually thought of in the context of a particular class, whereas objects can be of any class.
Using WMI tools to explore WMI namespaces and classes
To access the WMI, Windows operating systems include the built-in tool called the Windows Management Instrumentation Tester (Wbemtest.exe). By using the Wbemtest, you can navigate the different WMI classes and see the different properties and methods. The following procedure demonstrates the use of Wbemtest for browsing Configuration Manager classes.
1. Press the Windows logo key + R and type Wbemtest.exe to launch the Windows Management Instrumentation Tester.
2. Click Connect and type rootSMSSite_CM1 to specify the namespace.
3. Click Connect again and, when connected, click Enum Classes to open the Superclass Info dialog box and select Recursive:
4. Click OK to return a large number of Configuration Manager classes as shown in the following screenshot:
NOTE By using the Wbemtest you can navigate any WMI class and access its properties and methods.
Configuration Manager 2012 specific WMI namespaces, classes, properties, and methods
When Configuration Manager 2012 is installed on a site server, several namespaces and a number of different WMI classes are added to the WMI of the site server. This section explores some of the different WMI namespaces and WMI classes specific to Configuration Manager 2012. Note that each site might have classes that other sites might not have depending on the specific site settings, the inventory that is tracked, and so on.
To view the Configuration Manager 2012 specific namespaces, complete the following steps on the Configuration Manager 2012 site server.
1. Open the Computer Management console and, under Services And Applications, right-click WMI Control and then select Properties.
2. Click the Security tab to view all the different namespaces. For example, the namespace rootCCM is specific to the Configuration Manager 2012 client, as shown in the following screenshot:
And the namespace rootSMSsite_<siteCode> is specific to the Configuration Manager 2012 site server, as shown in the following screenshot.
3. Launch Wbemtest on the site server and specify the namespace as rootSMSsite_<siteCode>. and click Connect
4. Click Enum Classes to open the Superclass Info dialog box, select Recursive, and click OK. You will see several classes whose names begin with SMS_. All of these classes are specific to the site server and are created during installation of Configuration Manager 2012.
Using WMI classes to create Configuration Manager queries and dynamic collections
In Configuration Manager 2012, use queries to list the resources based on specific criteria. The Configuration Manager Queries node and collections use a WMI Query Language (WQL) query to request the Configuration Manager Object data from the SMS provider WMI schema, which in turn retrieves the data from the site database. To retrieve the data from WMI repository, you need to be able to create queries using WQL.
NOTE WQL is also sometimes referred to as SQL for WMI.
In the previous section you saw that several WMI classes are created during installation of the Configuration Manager 2012 site server. In this section, you start with the built-in Configuration Manager queries to view the respective WMI classes and properties used to retrieve the required information. Then you create new queries and collections using WQL.
1. In the Configuration Manager console, select the Monitoring workspace, and then select Queries.
2. Right-click the All Systems query, select Properties, Edit Query Statement, and then under the General tab click Show Query Language.
3. In the All Systems Query Statement Properties dialog box, you can see that the SMS_R_ System Class is queried to retrieve the Configuration Manager object.
4. Next use Wbemtest to see the different properties of this class used in the query. Launch Wbemtest, connect to the rootSMSsite_<siteCode> namespace, click Enum Classes, select Recursive, click OK, and navigate to the SMS_R_System class. Double-click SMS_R_System to open its properties as shown in the following screenshot.
Note that Windows Query Language (WQL) statements and SQL statements often appear similar but are actually quite different in how they are used by Configuration Manager. For example, WQL returns data by querying WMI classes while SQL returns data by querying the database. And while WQL is used in Configuration Manager queries and collections, SQL is used for custom reporting. So when you need to deal with WQL, you can use the Wbemtest tool, and when you need to work with SQL statements you can use SQL Management Studio. So as you can see, WQL and SQL are two different mechanisms, one for querying data from the SMS provider and the other from the SQL database. To continue with this example, now use the SMSprov.log to see how WQL interacts with the SMS provider, which converts WQL Statements into their equivalent SQL statement.
5. Select the Monitoring workspace, then select Queries, then create a new query as shown in the following screenshot:
6. On the General page, click Edit Query Statement, click Show Query Language, and then type the WQL query as shown in the following screenshot.
7. Select the Assets And Compliance workspace, select Device Collections, then create a device collection as shown below:
8. On the Membership Rules page, click Add Rule, and select Query Rule.
9. In the Query Rule Properties dialog box, click Import Query Statement. Then in the Browse Query dialog box under Queries, select the query created previously in step 7.
10. Click Next on all subsequent wizard pages, and then right-click the collection to update the collection membership.
11. Open the SMSProv.log and look for the WQL statement pertaining to the query you created. The log file entry selected in the following screenshot shows the WQL statement from the example in this procedure.
12. The line just below the WQL statement shows the equivalent SQL statement.
NOTE Unlike SQL tables, SQL views always begin with V_XXX. The SMSProv.log references SQL tables instead of SQL views. Best practice is to always use SQL views when querying the SQL database. For more information on SQL views versus tables, see Chapter 2 of this book.
Interaction between the site server and the Configuration Manager client
Let’s now examine how interaction between the site server and Configuration Manager client works. Configuration Manager employs a client-server architecture whereby the site server sends the client policies and configurations. The client in turn stores these policies and configurations in the local WMI repository on the client machine.
Configuration Manager client-specific WMI namespaces can be accessed by Wbemtest as explained earlier in this document. The following section focuses on the client hardware inventory actions and examines how the client’s different WMI classes are queried to gather the inventory data and send it to the Configuration Manager site server.
Using Resource Explorer on the site server, you can watch as the hardware inventory client agent captures some of the resource information on the Configuration Manager client and sends it to the site server. Figure 1-3 shows the Resource Explorer view of the one of the Configuration Manager clients.
FIGURE 1-3 Configuration Manager Resource Explorer.
As you can see, the Device ID for the Configuration Manager client is C: and the Volume Serial Number is 5897846F. This information about the Logical Disk resides on the Win32_ LogicalDisk WMI class. During the inventory cycle, the Hardware inventory agent queries the WMI class to gather this information and sends it to the site server.
Figure 1-4 shows the Configuration Manager client Win32_LogicalDisk WMI class. This is the same client shown in Figure 1-3. As you can see, the information that resides on the Win32_LogicalDisk is the same as collected and shown in Figure 1-3. You can also examine the inventoryagent.log to see which activities are performed when the hardware inventory cycle occurs.
FIGURE 1-4 Win32_LogicalDisk Class
Reading from the SMS Provider, WMI Scripting, and the Configuration Manager SDK
The SMS Provider is a WMI provider that provides both read and write access to the Configuration Manager site database. The SMS Provider is used by the Configuration Manager console, Resource Explorer, tools, and custom scripts used by Configuration Manager administrators to access site information stored in the site database. The SMS Provider also helps ensure that Configuration Manager object security is enforced by returning only site information that the user account running the console is authorized to view.
The SMS Provider can be installed on the site database server computer, site server computer, or another server-class computer during Configuration Manager setup. After setup has completed, the current installed location of the SMS Provider is displayed on the site properties General tab.
A WMI schema exists to describe the structure of the SMS Provider. Schema namespaces describe the location of Configuration Manager Data within the SMS Provider schema. Table 1-1 contains the common namespaces used by the SMS Provider.
TABLE 1-1 Common namespaces used by the SMS Provider
To connect to an SMS provider using VBScript, we need to perform below steps
1. Get a WbemScripting.SWbemLocator object. To set the object reference in visual basic script you can use the following command:
Set swbemLocator = CreateObject ("WbemScripting.SWbemLocator")
2. Set the authentication level to packet privacy.
swbemLocator.Security_.AuthenticationLevel = 6 'Packet Privacy
3. Set up a connection to the SMS Provider by using the SWbemLocator object Connect-Server method. Supply credentials only if it is a remote computer.
Set net = CreateObject ("WScript.NetWork")
If UCase (net.ComputerName) = UCase (server) Then
LocalConnection = true
userName = ""
userPassword = ""
server = "."
End If
' Connect to the server.
Set swbemServices= swbemLocator.ConnectServer (server, root
sms",userName,userPassword)
If Err.Number<>0 Then
Wscript.Echo "Couldn't connect: " + Err. Description
Connect = null
Exit Function
End If
4. Using the SMS_ProviderLocation object ProviderForLocalsite property, connect to the SMS Provider for the local computer and receive a SWbemServices object.
' Determine where the provider is and connect. Set providerLoc = swbemServices.InstancesOf("SMS_ProviderLocation") For Each location In providerLoc If location.ProviderForLocalsite = True Then Set swbemServices = swbemLocator.ConnectServer _ (location.Machine, "rootsmssite_" + _ location. SiteCode,userName,userPassword) If Err.Number<>0 Then Wscript.Echo "Couldn't connect:" + Err.Description Connect = Null Exit Function End If Set Connect = swbemServices Exit Function End If Next Set Connect = null ' Failed to connect.
5. Use the SWbemServices object to access provider objects.
On Error Resume Next
Dim net
Dim localConnection
Dim swbemLocator
Dim swbemServices
Dim providerLoc
Dim location
Set swbemLocator = CreateObject ("WbemScripting.SWbemLocator")
swbemLocator.Security_.AuthenticationLevel = 6 'Packet Privacy.
' If the server is local, don't supply credentials.
Set net = CreateObject ("WScript.NetWork")
If UCase (net.ComputerName) = UCase (server) Then
LocalConnection = true
userName = ""
userPassword = ""
server = "."
End If
' Connect to the server.
Set swbemServices= swbemLocator.ConnectServer (server, root
sms",userName,userPassword)
If Err.Number<>0 Then
Wscript.Echo "Couldn't connect: " + Err. Description
Connect = null
Exit Function
End If
'Determine where the provider is and connect.
Set providerLoc = swbemServices.InstancesOf("SMS_ProviderLocation")
For Each location In providerLoc
If location.ProviderForLocalsite = True Then
Set swbemServices = swbemLocator.ConnectServer _
(location.Machine, "rootsmssite_" + _
location. SiteCode,userName,userPassword)
If Err.Number<>0 Then
Wscript.Echo "Couldn't connect:" + Err.Description
Connect = Null
Exit Function
End If
Set Connect = swbemServices
Exit Function
End If
Next
Set Connect = null ' Failed to connect.
The Configuration Manager SDK, which can be downloaded from http://msdn.microsoft.com/en-us/library/hh948960.aspx, contains documentation and samples that are necessary to write applications to access and modify Configuration Manager data. It provides information about extending the Configuration Manager console, and also provides comprehensive reference material for each Configuration Manager feature.
The Configuration Manager SDK provides information applicable to administrators who want to automate Configuration Manager through script and useful to developers adding features and extensions to base Configuration Manager functionality.