The Root\CCM Namespace
The ConfigMgr client
also uses WMI for internal control of its own operations. ConfigMgr 2007
creates and uses several namespaces in addition to adding classes to
the Root\CIMV2 namespace.
The most important
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 hardware inventory process uses a policy stored in the
Root\CCM\Policy\Machine namespace to specify what inventory data to
retrieve from managed objects defined in the Root\CIMV2 namespace. “The Configuration Manager Client WMI Namespace” section discusses additional uses of the Root\CCM namespace.
Hardware Inventory Through WMI
ConfigMgr uses two MOF files to control hardware inventory:
SMS_Def.mof—
Specifies the information reported to the management point during the
client inventory retrieval cycle. The actual SMS_Def.mof file is not
downloaded to the ConfigMgr client. Instead, the client receives changes
to reporting class configuration as part of its machine policy.
Configuration.mof—
Defines custom data classes the hardware inventory client agent will
inventory. In addition to standard WMI classes, such as the Win32
classes, you can create data classes to provide inventory data that is
accessible through WMI, such as data from the client’s system Registry.
ConfigMgr clients download the Configuration.mof file 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 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 ConfigMgr machine
policy namespace, perform the following steps:
1. | Select Start -> All Programs -> WMI Tools -> WMI Object Browser.
|
2. | 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.
|
3. | Change the entry in the Connect to namespace dialog box to Root\CCM\Policy\Machine and then click OK.
|
4. | 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). As an example, select InventoryDataItem
from the available classes, as shown in Figure 14.
InventoryDataItem is the class representing inventory items specified
in the machine policy. Click the Browse button to display a list of
InventoryDataItem instances in the Machine Policy namespace, as shown in
Figure 15.
Figure 15
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 shown in Figure 16.
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, 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. If you examine the
default SMS_Def.mof file that comes with ConfigMgr, you will find a
section starting with the following:
[ SMS_Report (TRUE),
SMS_Group_Name ("Disk"),
SMS_Class_ID ("MICROSOFT|DISK|1.0") ]
class Win32_DiskDrive : SMS_Class_Template
This section is followed by a
list of inventory properties available for the Win32_DiskDrive class.
The properties listed here correspond to the ones designated with
“SMS_Report (TRUE)” in the SMS_Def.mof file. SMS_Report is a class
qualifier defined in the SMS_Class_Template class definition in
SMS_Def.mof. If you change the SMS_Report qualifier on any of the
available inventory properties in SMS_Def.mof on the site server, the
corresponding WMI InventoryDataItem instance in the machine policy
namespace is updated on the client during the next machine policy
retrieval cycle.
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. Unlike Win32_DiskDrive, Win32Reg_AddRemovePrograms
is not a default Win32 class; it is defined in the Configuration.mof
file. The following is the MOF code for Win32Reg_AddRemovePrograms:
#pragma namespace ("\\\\.\\root\\cimv2")
[ dynamic,
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;
};
When
the ConfigMgr client downloads and compiles the Configuration.mof file
during its machine policy retrieval cycle, WMI adds this class to the
Root\CIMV2 namespace. The class uses the Registry provider (RegProv) 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 exposes these
keys as managed objects of the newly compiled WMI class. The reporting
class of the same name defined in SMS_Def.mof specifies what inventory
data to report from these managed objects.
This example shows how the
Configuration.mof and SMS_Def.mof files can be used together to add
information from the system Registry to the ConfigMgr inventory. You can
use similar methods to add data from any provider installed on the
ConfigMgr client machines.