Chapter 3: Looking Inside Configuration Manager

Sams

1 2 3 4 5 6 7 8 9 10 Page 6
Page 6 of 10
  • 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. Chapter 12 discusses client 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.

  3. If your browser blocks the control, select the option Allow Blocked Content.

  4. Change the entry in the Connect to namespace dialog box to Root\CCM\Policy\Machine and then click OK.

  5. 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 3.21. 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 3.22.

FIGURE 3.22

InventoryDataItem instances listed in the WMI Object Browser

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

FIGURE 3.23

Properties of the Win32_DiskDrive instance of the InventoryDataItem as displayed in the WMI Object Browser

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.

 The Configuration Manager Client WMI Namespace

The Configuration Manager 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.24, that implement client operations such as site assignment, policy retrieval, and client repair.

  • The CCM_InstalledComponent class defines properties such as name, file, and version information describing each of the installed client components. Figure 3.25 displays a list of the instances of the CCM_InstalledComponent class.

FIGURE 3.25

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

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.


Using Local Client Policy - Clients normally download and apply policy defined on their assigned site as described in this section. You can choose to override downloaded policy settings on individual clients using local client policy. As an example, the Remote Tools client agent configuration is a sitewide setting, but the needs of individual client systems may vary. If your sitewide settings require a user to accept a remote control session, you may choose to use local policy to override this on servers. The ConfigMgr SDK (Software Development Kit) documentation describes how to manage local policy at http://msdn.microsoft.com/en-us/library/cc145455.aspx. Use caution when using local policy because it can complicate troubleshooting client issues.


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. 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 an advertisement:

  • The policy agent—The policy agent stores the policy for an assigned advertisement as an instance of the CCM_SoftwareDistribution class in the Root\ccm\policy\<machine|user>\ActualConfig namespace, as shown in Figure 3.27.

  • FIGURE 3.27

    The properties of the CCM_SoftwareDistribution class instance for an advertisement to download and run Notepad

  • The Scheduler component—The Scheduler maintains history for the advertisement in a CCM_Scheduler_History object in the Root\CCM\scheduler namespace, as displayed in Figure 3.28.

  • This namespace can also contain schedule information for other components, including DCM schedules, software update schedules, and NAP schedules.

    FIGURE 3.28

    The Scheduler uses the CCM_Scheduler_History object to maintain history for an advertisement.

  • The Content Transfer Manager—The Content Transfer Management component uses the CacheInfoEx object in the Root\CCM\SoftMgmtAgent namespace, shown in Figure 3.29, to manage cached content for the advertisement.

  • FIGURE 3.29

    The CacheInfoEx object is used to manage cached content for the advertisement.

  • The SoftwareDistributionClientConfig class—Machine policy also controls the settings of various ConfigMgr client components. The SoftwareDistributionClientConfig class, shown in Figure 3.30, contains the Software Distribution client agent settings.

  • FIGURE 3.30

    Some of the properties of the 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, hundreds of classes are used by the client. The classes presented here are representative of some of the most important client operations. 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 Configuration Manager Servers

The SMS provider is a WMI provider that exposes many of the most important objects in the Configuration Manager site database as WMI managed objects. This provider is generally installed on either the site server or the site database server, discussed in Chapter 5. The ConfigMgr console and auxiliary applications such as the Resource Explorer, Service Manager, and various ConfigMgr tools are implemented as WMI management applications. Chapter 10, “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. The provider also implements the Configuration Manager object security model. Chapter 20, “Security and Delegation in Configuration Manager 2007,” 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. You can also view the properties of SMS provider objects from within the ConfigMgr console. To enable viewing of WMI information, navigate to the AdminUI\bin folder under the main ConfigMgr installation folder and start the console with either or both of the following command-line options:

  • AdminConsole.msc /SMS:NamespaceView=1—This adds a ConfigMgr Namespace node to the console tree. The Namespace node displays a list of WMI classes in the ConfigMgr namespace. You can click a class name, as shown in Figure 3.31, to display its properties, qualifiers, and methods in the details pane. You can also select a property to see its associated list of property qualifiers.

  • FIGURE 3.31

    The SMS_Site class as displayed in the console Namespace view

  • AdminConsole.msc /SMS:DebugView=1—This allows you to view object properties as raw WMI data. With Debug view enabled, you can right-click an object in the console tree and choose ConfigMgr Object Properties View to display the WMI properties. Notice that the default console view essentially presents the same information in a Windows dialog box. Figure 3.32 shows the WMI properties of the DAL ConfigMgr site.

Figure 3.32 displayed the property qualifiers of the Status property, showing that the status value “1” means ACTIVE.

FIGURE 3.32

The properties of the DAL site displayed in the console’s Object Properties view

Using the console WMI views makes exploring the SMS provider namespace much easier. To illustrate how to drill down into the underlying WMI from the console, this section uses ConfigMgr collections as an example. (Chapter 13, “Creating Packages,” and Chapter 14, “Distributing Packages,” discuss collections.) To explore the WMI behind ConfigMgr collections, perform the following steps:

1 2 3 4 5 6 7 8 9 10 Page 6
Page 6 of 10