This chapter is from the book
This chapter is from the book
This chapter is from the book
WMI in ConfigMgr
ConfigMgr uses WMI extensively for both client and server operations. The ConfigMgr client uses WMI for internal control of its own operations and for gathering hardware inventory. ConfigMgr also uses WMI as an interface to the site database. The next sections discuss how ConfigMgr uses WMI on the client and then describe the use of WMI in ConfigMgr server operations.
ConfigMgr Client Namespaces
ConfigMgr 2012 creates and uses several namespaces in addition to adding classes to the Root\CIMV2 namespace. The primary namespace created by the ConfigMgr client is the Root\CCM namespace. Together with several namespaces under Root\CCM, this namespace holds the configuration and policies that govern the operation of the ConfigMgr client. The Root\CIMV2\SMS namespace contains additional system-wide objects used by ConfigMgr. The hardware inventory process described in the next section of this chapter uses a policy stored in the Root\CCM\Policy\Machine\actualconfig namespace to specify what inventory data to retrieve from managed objects defined in the Root\CimV2 namespace. The “Additional Client Operations Through WMI” section discusses additional uses of the Root\CCM namespace.
Hardware Inventory Through WMI
The ConfigMgr client agent gathers hardware inventory data by querying WMI. The Client Agent settings determine which object classes are reported as part of the client inventory. For the majority of hardware inventory policy definitions, enabling or disabling what is reported from the clients to the ConfigMgr infrastructure is done from the console, via Client Agent settings. Modifications can be applied on as site wide basis by editing the Default Client Agent settings. To modify the hardware inventory settings for a subset of the environment (servers for example), create and modify a custom client setting, then assign it to a collection consisting of the appropriate systems. Chapter 9 describes client settings and inventory customization through the ConfigMgr console. Chapter 9 also discusses the changes in client inventory from ConfigMgr 2007. Appendix B, “Extending Hardware Inventory,” provides a detailed discussion of inventory customization.
The configuration.mof file defines classes used by the hardware inventory client agent to collect inventory. The CAS or top-level primary site imports the class definitions from the configuration.mof file and replicates them throughout the hierarchy. The configuration.mof file that ships with ConfigMgr provides a standard set of WMI classes, such as the Win32 classes. In some cases, a custom data class might be required. For example, an application or device driver may act as a WMI provider and create custom classes. You can also create data classes to provide inventory data that is accessible through existing WMI providers, such as data from the client’s system registry. In those cases, the administrator must import a custom mof file into the default client agent settings.
To apply inventory settings from a custom mof file, navigate to Administration -> Client Settings, and either select the Default Client Settings or create or a Custom Client Device Settings object. On the Properties page, choose Hardware Inventory and click Set Classes -> Import.
ConfigMgr clients download client settings as part of their machine policy retrieval cycle. Any changes are compiled and loaded into the WMI repository. The ConfigMgr client stores its machine policy in the Root\CCM\Policy\Machine\actualconfig WMI namespace. You can use the WMI Object Browser from the WMI Administrative Tools to examine some to the inventory-related objects in this namespace. To launch the WMI Object Browser and connect to the Root\CCM\Policy\Machine\actualconfig namespace, follow these steps:
- Select Start -> All Programs -> WMI Tools -> WMI Object Browser.
The WMI Object Browser opens a web browser and attempts to run an ActiveX control.
If your browser blocks the control, select the option Allow Blocked Content.
- Change the entry in the Connect to namespace dialog box to Root\CCM\Policy\Machine\actualconfig and then click OK.
- Click OK to accept the default logon settings.
You can locate objects of a specified class by clicking the Browse button (the binocular icon on the toolbar above the left pane). Select InventoryDataItem from the available classes, as shown in Figure 3.21. Click OK to display a list of the items that will be inventoried.
)
Figure 3.21. Browsing for InventoryDataItem in the WMI Object Browser.
InventoryDataItem is the class representing inventory items specified in the machine policy. Figure 3.22 lists several of these instances in the Root\CCM\Policy\Machine\actualconfig namespace.
)
Figure 3.22. InventoryDataItem instances listed in the WMI Object Browser.
Figure 3.22 has the columns resized to hide the Key (1) column, which displays an object GUID (Globally Unique Identifier), and to display the more interesting information in Key(2) and Key (3).
Selecting the instance that refers to the Win32_DiskDrive class in the Root\CIMV2 namespace and double-clicking this entry displays the instance properties, as shown in Figure 3.23.
)
Figure 3.23. Properties of the Win32_DiskDrive instance of the InventoryDataItem as displayed in the WMI Object Browser.
The Namespace and ItemClass properties tell the hardware inventory agent it can retrieve inventory data for this class from Win32_DiskDrive objects in the \\Root\CIMV2 namespace. The Properties property contains a list of properties to inventory from each instance of \\Root\CIMV2\Win32_DiskDrive. Here are the properties listed:
- Availability, Caption, Description, DeviceID, Index, InterfaceType, Manufacturer, MediaType, Model, Name, Partitions, PNPDeviceID, SCSIBus, SCSILogicalUnit, SCSIPort, SCSITargetId, Size, SystemName
Win32_DiskDrive objects have many other properties besides these. The property list in the machine policy settings instance corresponds to the properties selected in the applicable client settings object. To view these settings in the console, navigate to the Administration workspace and select Default Client Agent Settings -> Properties -> Hardware Inventory -> Set Classes. Classes that are checked will be collected and reported upon. Figure 3.24 shows the client agent hardware inventory settings for Disk Drives (Win32_DiskDrive).
)
Figure 3.24. Client Settings Specifying Disk Drive Properties to Inventory.
Another InventoryDataItem instance in the Root\CCM\Policy\Machine namespace—Win32Reg_AddRemovePrograms—configures inventory settings for reporting on items of the Win32Reg_AddRemovePrograms class in the \\Root\CIMV2 namespace. Here is the MOF code for Win32Reg_AddRemovePrograms:
#pragma namespace("\\\\.\\ROOT\\CIMV2")
//**************************************************************************
//* Class: Win32Reg_AddRemovePrograms
//* Derived from:
//**************************************************************************
[dynamic: ToInstance, provider("RegProv"), ClassContext("local|HKEY_LOCAL_MACHINE\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall")]
class Win32Reg_AddRemovePrograms
{
[key] string ProdID;
[PropertyContext("DisplayName")] string DisplayName;
[PropertyContext("InstallDate")] string InstallDate;
[PropertyContext("Publisher")] string Publisher;
[PropertyContext("DisplayVersion")] string Version;
};
The System Registry provider (RegProv) exposes registry data to management applications. The Win32Reg_AddRemovePrograms class uses the Registry provider to retrieve the information stored under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall in the local registry dynamically. Each key under this location stores information about an item in Add/Remove Programs.
This example shows how the Registry provider exposes registry keys and values through WMI. You can use a mof compiler such as the one in CIM Studio to create classes representing various registry data, which you can then add to the ConfigMgr inventory. You can use similar methods to add data from any provider installed on the ConfigMgr client machines.
Additional Client Operations Through WMI
The ConfigMgr client creates WMI classes to represent its own components and configuration. The root of the ConfigMgr client namespace hierarchy is Root\CCM. The Root\CCM namespace contains classes representing client properties, such as identity and version information, installation options, and site information. Two of the classes in this namespace expose much of the functionality available through the Configuration Management Control Panel applet:
- The SMS_Client WMI class provides methods, displayed in Figure 3.25, that implement client operations such as site assignment, policy retrieval, and client repair.
Figure 3.25. The SMS_Client class with the Methods tab displayed in CIM Studio.
- The CCM_InstalledComponent class defines properties such as name, file, and version information describing each of the installed client components. Figure 3.26 displays a list of the instances of the CCM_InstalledComponent class.
)
)
Figure 3.26. Instances of the CCM_InstalledComponent class listed in the WMI Object Browser.
You will find managed objects for various client components in namespaces under Root\CCM. Figure 3.27 shows an instance of these classes, the CacheConfig class. The CacheConfig class in the Root\CCM\SoftMgmtAgent namespace contains settings for the client download cache, found on the Advanced tab of the Configuration Management Control Panel applet.
)
Figure 3.27. The properties of the CacheConfig class instance represent the client download cache settings.
The ConfigMgr client uses the Root\CCM\policy namespace hierarchy to store and process policy settings retrieved from the management point. The client maintains separate namespaces for machine policy and user policy.
During the policy retrieval and evaluation cycle, the policy agent, a component of the client agent, downloads and compiles policy settings and instantiates the requested policy settings in the Root\CCM\policy\{machine|user}\RequestedConfig namespace, where the value of {machine|user} is machine for systemwide policies or user for user specific policies. The Policy Evaluator component then uses the information in RequestedConfig to update the Root\CCM\policy\{machine|user}\ActualConfig namespace. Based on the policy settings in the actual configuration, the Policy Agent Provider component updates various component instances with their appropriate settings. As an example, consider some of the objects used by the client to process policy for a deployment:
- The policy agent: The policy agent stores the policy for an assigned deployment as an instance of the CCM_SoftwareDistribution class in the Root\ccm\policy\<machine|user>\ActualConfig namespace, as shown in Figure 3.28.
Figure 3.28. The properties of the CCM_SoftwareDistribution class instance for a ConfigMgr client upgrade deployment.
- The Scheduler component: The Scheduler maintains history for the deployment in a CCM_Scheduler_History object in the Root\CCM\scheduler namespace, as displayed in Figure 3.29.
Figure 3.29. The Scheduler uses the CCM_Scheduler_History object to maintain history for a deployment.
This namespace can also contain schedule information for other components, including compliance evaluation schedules, software update schedules, and NAP schedules.
- The Execution history: The Execution Manager component uses the CCM_ExecutionRequestEx object in the Root\CCM\SoftMgmtAgent namespace, shown in Figure 3.30, to manage execution history for the deployment.
Figure 3.30. The CCM_ExecutionRequestEx object is used to manage execution history for the deployment.
- The Software Distribution Client Configuration class: Machine policy also controls the settings of various ConfigMgr client components. The CCM_SoftwareDistributionClientConfig class in the root\ccm\policy\machine\actualconfig namespace, shown in Figure 3.31, contains the Software Distribution client agent settings.
Figure 3.31. Some of the properties of the CCM_SoftwareDistributionClientConfig class reflect client agent settings received from the site.
)
)
)
)
This section looked at some of the more important WMI classes the ConfigMgr client uses for its operations. This is by no means an exhaustive list; in fact, the client uses hundreds of WMI classes. The Configuration Manager server components have an even larger set of WMI classes. The next section presents an overview of how ConfigMgr uses WMI for server operations.
WMI on ConfigMgr Servers
The SMS Provider is a WMI provider that exposes many of the most important objects in the ConfigMgr site database as WMI managed objects. This provider is generally installed on either the site server or the site database server, as discussed in Chapter 4. The ConfigMgr console, auxiliary applications such as the Resource Explorer, Service Manager, and various ConfigMgr tools are implemented as WMI management applications. Chapter 8, “The Configuration Manager Console,” discusses the ConfigMgr console. As with other WMI providers, you can also take advantage of the SMS Provider’s objects in custom scripts or other management applications. Some people have even built their own console or web interfaces to replace console operations. The provider also implements the ConfigMgr object security model. Chapter 20 discusses the object security model and explains how to grant users access to the console and rights on various ConfigMgr objects and classes.
The SMS Provider namespace is Root\SMS\site_<site code>. You can use standard WMI tools to view ConfigMgr classes and objects.
This section uses ConfigMgr collections to illustrate how to drill down into the underlying WMI using PowerShell. (Chapter 11, “Packages and Programs,” and Chapter 13, “Distributing and Deploying Applications,” discuss collections.) The following PowerShell command connects to the site_CAS namespace on the site server Armada and displays the collection objects:
Get-WmiObject -class SMS_Collection -computer "Armada" -namespace "root\SMS\site _CAS"
Here are several selected properties of one collection output by this statement:
IsBuiltIn : True LimitToCollectionID : SMS00001 LimitToCollectionName : All Systems MemberClassName : SMS_CM_RES_COLL_SMSDM001 Name : All Mobile Devices OwnedByThisSite : True
Notice that the MemberClassName property shows the WMI class for all members of the collection. This statement displays the complete attribute set of all members of the All Mobile Devices collection:
Get-WmiObject -class SMS_CM_RES_COLL_SMSDM001 -namespace root\SMS\site_CAS
Figure 3.32 shows a PowerShell command to display the properties and methods of the SMS_Collection class, together with its output.
)
Figure 3.32. The SMS_Collection class Properties and Methods.
The SMS_Collection class methods allows you to perform operations such as pushing the ConfigMgr Client to collection members with the Create CCRs method and updating collection membership with the RequestRefresh method. When you perform these operations through the ConfigMgr console, you are actually invoking the methods of the SMS_Collection class. Figure 3.33 displays the SMS_Collection class associations.
)
Figure 3.33. The SMS_Collection class associations link a collection to its members (class SMS_Resource), and deployments (SMS_Advertisement) assigned to the collection.
The following PowerShell commands create an object representing the Odyssey Computers collection and enumerate all associated objects of type SMS_Resource, writing the results to a text file:
$MyCollection = Get-WmiObject -class SMS_Collection -computer "Armada" -namespace
"root\SMS\site_CAS" | where {$_.Name -eq "Odyssey Computers"}
$MyCollection.GetRelated()|Where {$_.__SUPERCLASS -eq "SMS_Resource"} |Out-File
"OdysseyCollectionComputers.txt"
Several blogs referenced in Appendix C, “Reference URLs,” provide additional examples of how you can use PowerShell with ConfigMgr. Microsoft has announced plans to release a PowerShell provider for ConfigMgr by the end of 2012. This provider will extend the usefulness of PowerShell for managing ConfigMgr operations.
The smsprov.mof file contains the MOF language defining the Root\SMS namespace and the classes it contains. You can find the smsprov.mof file in the bin\<platform> folder under the ConfigMgr installation folder. You can also export MOF definitions for instances of the following ConfigMgr object types directly from the console:
- Device Collections are found in the Assets and Compliance workspace.
- User Collections are found in the Assets and Compliance workspace.
- Queries are found in the Monitoring workspace.
To export objects definitions to MOF files, right-click the workspace node to export multiple object or right-click a single object to export, choose Export, and complete the wizard to choose the instances to export and file location as well as to enter descriptive text. You can use a similar process to import objects from MOF files. You can use this process to copy objects between hierarchies. For example, you might develop and test queries in your lab environment and import them into production.
This section showed how the SMS Provider exposes Configuration Manager server components and database objects as WMI-managed objects. The “Root\CCM Namespace,” “Hardware Inventory Through WMI,” and “Additional Client Operations Through WMI” sections discussed how the ConfigMgr client uses WMI to maintain its configuration and policy and to gather inventory data. The ConfigMgr SDK, which was in prerelease when writing this chapter, is available for download from http://www.microsoft.com/download/en/details.aspx?id=29559 (or search for ConfigMgr SDK at www.microsoft.com/downloads). It provides extensive documentation and sample code for using WMI to manage ConfigMgr programmatically, with managed code or scripts.