All objects in Active Directory are instances of classes defined in the AD schema. The schema provides definitions for common objects such as users, computers, and printers. Each object class has a set of attributes that describes members of the class. As an example, an object of the computer class has a name, operating system, and so forth. Additional information about the AD schema is available at http://msdn.microsoft.com/en-us/library/ms675085(VS.85).aspx.

The schema is extensible, allowing administrators and applications to define new object classes and modify existing classes. Using the schema extensions provided with Configuration Manager eases administering your ConfigMgr environment. The ConfigMgr schema extensions are relatively low risk and involve only a specific set of classes not likely to cause conflicts. Extending the schema is a recommended best practice for Configuration Manager because it allows you to avoid additional configuration tasks and implement stronger security. Nevertheless, you will want to test any schema modifications before applying them to your production environment.

Viewing Schema Changes

If you are curious about the details of the new classes, you can use the Schema Management Microsoft Management Console (MMC) snap-in to view their full schema definitions. Before adding the snap-in to the management console, you must install it by running the following command from the command prompt:

regsvr32 schmmgmt.dll

After installing the snap-in, perform the following steps to add Schema Management to the MMC:

1. Select Start, choose Run, and then enter MMC.
2. Choose Add/Remove snap-in from the File menu of the Microsoft Management Console.
3. Click the Add button and then choose Active Directory Schema.
4. Choose Close and then click OK to complete the open dialog boxes.

The left pane of the schema management tool displays a tree control with two main nodes—classes and attributes. If you expand out the classes node, you will find the following classes defined by ConfigMgr:

• mSSMSManagementPoint

• mSSMSRoamingBoundaryRange

• mSSMSServerLocatorPoint

• mSSMSSite

Clicking a class selects it and displays the attributes associated with the class in the right pane. The list of attributes for each class includes many attributes previously defined in Active Directory, in addition to those attributes specifically created for ConfigMgr 2007. You can right-click a class and choose Properties to display its property page. As an example, Figure 3.1 shows the general properties of the mSSMSSite class. You can see an explanation of these properties by clicking the Help button on the Properties page.

Figure 3.1. General properties of the schema class representing ConfigMgr sites

You can see the 14 ConfigMgr attributes under the Attributes node in the schema management console. The names of each of these attributes start with mS-SMS. You can right-click an attribute and choose Properties to display its property page. Figure 3.2 shows the properties of the mS-SMS-Capabilities attribute.

Figure 3.2. General properties of the schema attribute representing site capabilities

Tip

Verifying the Schema Extensions

Check ExtADSch.log for failures. Seeing the Event IDs 1137 in the Directory Service Event Log alone is not confirmation that the schema was extended properly; several experiences in the field have found what seemed to be a successful schema extension to show failures in the log file.

Additional Tasks

After extending the schema, you must complete several tasks before ConfigMgr can publish the objects it will use to Active Directory:

• Creating the System Management container where the ConfigMgr objects will reside in AD. If you previously extended the schema for SMS, the System Management container will already exist. Each domain publishing ConfigMgr data must have a System Management container.

• Setting permissions on the System Management container. Setting permissions allows your ConfigMgr site servers to publish site information to the container.

• Configuring your sites to publish to AD.

The next sections describe these tasks.

Creating the System Management Container

You can use the ADSIEdit MMC tool to create the System Management AD container. If you do not already have ADSIEdit installed, you can install the tool yourself. The steps to install ADSIEdit will vary depending on the version of Windows Server you are running.

On Windows Server 2008, add ADSIEdit using Server Manager. Note that configuring the domain controller server role automatically adds ADSIEdit to the Administrative Tools program group.

To install ADSIEdit on Windows Server 2003 or Windows 2000 Server, perform the following steps:

1. Run the Windows Installer file at SUPPORTTOOLSsuptools.msi from the Windows Server 2003 installation media. (For Windows 2000 systems, the installer file is adminpak.msi.)
2. Select Start, choose Run, and then enter MMC.
3. Choose Add/Remove snap-in from the File menu.
4. Click the Add button and choose ADSI Edit.
5. Choose Close and then click OK to complete the open dialog boxes.

To create the System Management container from ADSIEdit, perform the following steps:

1. Right-click the Root ADSI Edit node in the tree pane, select Connect to..., and then click OK to connect to the default name context.
2. Expand the default name context node in the tree pane. Then expand the node showing the distinguished name of your domain (this will begin with DC=<domain name>) and right-click CN=System node.
3. Select New and then choose Object.
4. Select Container in the Create Object dialog box and click Next.
5. Enter the name System Management and then click Next and Finish, completing the wizard.

Figure 3.3 shows ADSIEdit with the tree control expanded to the CN=System node and the Create Object dialog box displayed.

Figure 3.3. Using ADSIEdit to create the System Management container

Setting Permissions on the System Management Container

You can view the System Management container and set permissions on it using the Active Directory Users and Computers (ADUC) utility in the Windows Server Administrative Tools menu group. After launching ADUC, you need to enable the Advanced Features option from the View menu. You can then expand out the domain partition and System container to locate System Management.

By default, only certain administrative groups have the rights required to create and modify objects in the System Management container. For security reasons, you should create a new group and add ConfigMgr site servers to it, rather than adding them to the built-in administrative groups. Perform the following steps to grant the required access to the ConfigMgr site server security group:

1. Right-click the System Management container, choose Properties, and then select the Security tab.
2. Click the Add button and select the group used with your ConfigMgr site servers, as shown in Figure 3.4.

   Figure 3.4. Selecting the Site Server security group

   
3. Check the box for Full Control as displayed in Figure 3.5, and choose OK to apply the changes.

   Figure 3.5. Assigning permissions to the System Management container

   

Configuring Sites to Publish to Active Directory

Perform the following steps to configure a ConfigMgr site to publish site information to AD:

1. Navigate to System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> in the ConfigMgr console (select Start -> All Programs -> Microsoft Configuration Manager to open the Configuration Manager console).
2. Right-click the site code and choose Properties. Click the Advanced tab and then select the Publish this site in Active Directory Domain Services check box as shown in Figure 3.6. Choose OK to apply your changes.

   Figure 3.6. Configuring a site to publish to AD

   

After extending the schema and taking the other steps necessary to enable your sites to publish to AD, you should see the ConfigMgr objects displayed in the System Management container. Figure 3.7 shows the ConfigMgr objects viewed in Active Directory Users and Computers.

Figure 3.7. The System Management container displayed in Active Directory Users and Computers

Once you extend the Active Directory schema and perform the other steps necessary to publish site information to AD, clients in the same AD forest as your ConfigMgr sites can query AD to locate Configuration Manager services and retrieve important information about your ConfigMgr sites. Those clients in workgroups and domains without trust relationships are not able to take advantage of the schema extensions.

The following ConfigMgr features require extending the AD schema and publishing site information to AD:

ConfigMgr clients can also receive a number of services through the extended schema that may be available in other ways. Chapter 12 discusses many of these features. In each case, the alternatives are more difficult to implement and some require extensive manual effort. You can use the schema extensions for the following capabilities:

In addition, the schema extensions allow for automated public key exchange, thus facilitating site-to-site communication. If you have clients assigned to your central site and do not have the schema extended, recovery from a site failure can require reprovisioning all clients manually using the trusted root key.

The AD schema extensions are a key enabling technology for Configuration Manager. You should extend the schema and take the other steps previously listed in the “Schema Extensions” section of this chapter to publish site information to Active Directory, if this is possible.

WMI serves as an abstraction layer between management applications and scripts and the physical and logical resources they manage. WMI exposes managed resources through a COM (Component Object Model) API (application programming interface). Programs written in C/C++ can call these resources directly, or you can access them through intermediate layers from applications such as scripts, 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 an object model removes much of the complexity that would otherwise be required to access and manipulate these resources. Some examples of resources you can manage through WMI include hardware devices, running processes, the Windows file system and Registry, and applications and databases.

You can invoke WMI services in several ways:

Configuration Manager 2007 uses all three of these access methods to connect to WMI. Chapter 5 describes the use of DCOM in ConfigMgr and the network protocols used for DCOM connections.

WS-Management is a Simple Object Access Protocol (SOAP)–based specification published by the DMTF. SOAP is a standard for invoking objects remotely over a Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) connection. The main advantage of SOAP is that it works across many existing network firewalls without requiring additional configuration. A complete description of WS-Management and related specifications can be found at http://www.dmtf.org/standards/wsman.

The ConfigMgr Out of Band (OOB) management point and OOB console use WS-Management to connect to the OOB management controller on systems equipped with Intel vPro technology. Chapter 6 discusses OOB Management in detail.

WMI supports requests from management applications to

Figure 3.8 shows the basic data flow in WMI:

Figure 3.8. How WMI accepts a request from a management application and returns a response from a managed resource

The WMI Infrastructure

Figure 3.9 displays the main logical components of the WMI infrastructure. The core of the WMI infrastructure is the Common Information Model Object Manager (CIMOM), described in the “Inside the WMI Object Model” section of this chapter. CIMOM brokers requests between management applications and WMI providers, and communicates with management applications through the COM API, as described earlier in the “WMI Feature Set and Architecture” section. CIMOM also manages the WMI repository, an on-disk database used by WMI to store certain types of data. Beginning with Windows XP, WMI also includes an XML (eXtensible Markup Language) encoder component, which management applications and scripts can invoke to generate an XML representation of managed objects.

Figure 3.9. The major WMI infrastructure components

Most files used by WMI are stored on the file system by default under the %windir%System32Wbem folder. The executable containing the WMI service components is Winmgmt.exe. The physical implementation of the WMI infrastructure varies, depending on the version of Windows you are running. In Windows NT and Windows 2000, Winmgmt runs as a separate Windows service. In these earlier versions of Windows, WMI providers are loaded into the Winmgmt process space, which means that a fault in one provider can crash the entire WMI process. This can cause repository corruption, which is a common cause of WMI problems in earlier Windows implementations. Using a single process space also means that providers share the security context of the Winmgmt process, which is generally the highly privileged Local System account.

Newer versions of Windows achieve greater process isolation by loading providers into one or more instances of WMIPrvse.exe. All WMI service components beginning with Windows XP run inside shared service host (SVCHOST) processes. Windows Vista 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. The next section of this chapter discusses WMI security. These enhancements are also available as an update for Windows XP and Windows Server 2003 systems at http://support.microsoft.com/kb/933062.

Configuration parameters for the WMI service are stored in the system Registry subtree HKEY_LOCAL_MACHINESoftwareMicrosoftWBEM. The WMI repository is a set of files stored under %windir%System32Wbem. The exact file structure varies slightly depending on the Windows version. WMI uses a customized version of the Jet database engine to access the repository files.

WMI also provides detailed logging of its activities. Prior to Windows Vista, log entries were written in plain text to files in the %windir%System32Wbemlogs folder. In Windows Vista and Windows Server 2008, most of these logs no longer exist, and Windows Event Tracing makes log data available to event data consumers, including the Event Log Service. By default, event tracing for WMI is not enabled. The “Managing WMI” section of this chapter discusses logging and event tracing options for WMI in. Some WMI providers, such as the ConfigMgr provider, also log their activity. The “Status Messages and Logs” section discusses logging by the ConfigMgr WMI provider.

This section is intended to illustrate the options available for configuring WMI rather than as a “how-to” guide to administering WMI. You will rarely need to modify the WMI settings directly during day-to-day ConfigMgr administration. However, understanding the available options will help you understand the inner workings and functionality of WMI.

The Windows 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 the WMI Control. To run this tool, perform the following steps:

The WMI Control opens to the General tab. As shown in Figure 3.10, the General properties confirm you have successfully connected to WMI on the local machine, display a few basic properties of your system, and specify the installed version of WMI.

Figure 3.10. The General tab of the WMI Control showing a successful connection to WMI on the local machine

You can manage WMI security from the Security tab of the WMI Control tool. WMI uses standard Windows access control lists (ACLs) to secure each of the WMI namespaces that exist on your machine. A namespace, as described more precisely 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, as displayed in Figure 3.11.

Figure 3.11. The Security tab of the WMI Control tool, displaying the top-level WMI namespaces

It is important to note that the namespace is the most granular level in which to apply ACLs in WMI. The process of setting security on WMI namespaces, and the technology behind it, is very similar to the process of setting NTFS (NT File System) security. If you click a namespace to select it and click Security, you will see a dialog box similar to the one displayed in Figure 3.12.

Figure 3.12. The WMI Security dialog box for the CCM namespace (the root namespace of the ConfigMgr client)

The dialog box in Figure 3.12 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 they have. Prior to Windows Vista, this was the only namespace access control implemented in WMI. The Vista WMI enhancements, mentioned previously in the “WMI Feature Set and Architecture” section of this chapter, add a system access control list (SACL) for WMI namespaces. The SACL specifies the actions audited for each security principal.

To specify auditing on a WMI namespace, perform the following steps:

Figure 3.14 shows the entries to enable auditing for all access failures by members of the ConfigMgr Site Servers group.

Figure 3.14. The WMI Auditing Entry dialog box displaying auditing enabled for all access failures by members of the ConfigMgr Site Servers group

The remaining tabs of the WMI Control tool allow you to change the default namespace for WMI connections, and they provide one of several methods of backing up the WMI repository. Windows system state backups also back up the repository. Prior to Windows Vista, the WMI Control tool also contained a logging tab that allowed you to specify verbose, normal, or no logging, as well as choose the WMI log location and maximum log size. In Windows Server 2008 and Vista, you can enable logging and configure log options in the Windows Event Viewer.

To enable WMI Trace Logging in Windows 2008 and Vista, perform the following steps:

You can read more about WMI Logging at http://msdn.microsoft.com/en-us/library/aa394564(VS.85).aspx.

You should be aware that User Account Control, also introduced in Windows Vista, 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/en-us/library/aa826699(VS.85).aspx.

Additional command-line tools are available for managing WMI, which you can download from http://msdn.microsoft.com/en-us/library/aa827351(VS.85).aspx.

The DMTF’s Common Information Model (CIM) is the basis for the WMI object model. CIM 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:

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 to it 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 not inherited from the parent.

Typically, core and common classes are not used directly to represent managed objects. Rather, they are used as base classes from which other classes are derived. The “Looking Inside the CIMV2 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 the system class. WMI uses system classes internally to support its operations. They represent providers, WMI events, inheritance metadata about WMI classes, and more.

WMI classes support three types of attributes:

You can also modify WMI classes, properties, and methods by the use of 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 instantiated. Two important qualifiers designate data as static or dynamic:

The CIM specification also includes a language for exchanging management information. The 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 in the WMI repository. Examples of information in MOF format are included throughout the chapter.

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. As already seen in the “Managing WMI” section, the Root namespace defines a hierarchy organizing the namespaces on a system. The “Managing WMI” section also mentions that the WMI Control tool allows you to specify the default namespace for connections to WMI. Generally, the default namespace will be RootCIMV2. This is the namespace defining most of the major classes for Windows management. The next section looks at several of the classes in that namespace. Because Configuration Manager is all about Windows Management, it is not surprising that ConfigMgr uses this namespace extensively. ConfigMgr also defines its own namespaces, discussed in the section “Looking Inside Configuration Manager with WMI.”

This section covers the major concepts of WMI and the CIM model, which will be used to look inside ConfigMgr WMI activity. If you are interested in learning about other aspects of CIM, a good place to start is the tutorial at http://www.wbemsolutions.com/tutorials/CIM/index.html. The full CIM specification can by found at http://www.dmtf.org/standards/cim/cim_spec_v22. Documentation for WMI is available at http://msdn.microsoft.com/en-us/library/aa394582.aspx.

Windows provides a basic tool called WBEMTest that allows you to connect to a WMI namespace and execute WMI operations. There are also a number of tools from Microsoft and third parties with more intuitive graphical interfaces for displaying and navigating WMI namespaces. This section uses the Microsoft WMI Administrative Tools to look into the RootCIMV2 namespace. These tools include the WMI CIM Studio and the WMI Object Browser. You can download the WMI Administrative Tools from http://www.microsoft.com/downloads/details.aspx?FamilyID=6430f853-1120-48db-8cc5-f2abdc3ed314&DisplayLang=en or search for WMITools at www.microsoft.com/downloads. After downloading, you will need to run the WMITools.exe executable file to install the tools.

You can use CIM Studio to explore the classes in a namespace and view the properties, methods, and associations of each class. Perform the following steps to launch CIM Studio and connect to the CIMV2 namespace:

When you open CIM Studio and connect to a namespace, the Class Explorer in the left pane contains a tree structure that displays the base classes in the selected namespace. Figure 3.15 displays the left pane with some of the root classes of the CIMV2 namespace.

Figure 3.15. The root classes of the CIMV2 namespace displayed in CIM Studio

Notice that most of the class names in Figure 3.15 begin with CIM or Win32. Class names starting with CIM indicate that the class is one of the core or common classes defined in the DMTF CIM schema. Extended classes are those classes with names beginning with Win32, which are part of the Win32 schema defined by Microsoft for managing the Win32 environment.

The Win32_LogicalShareSecuritySetting class

This section uses the Win32_LogicalShareSecuritySetting class to illustrate how you can use CIM Studio to understand a class of managed objects. Figure 3.16 shows the Win32_LogicalShareSecuritySetting class displayed in CIM Studio. This class represents the security settings on a Windows file share. The expanded tree shows the root class, CIM_Setting, and the classes derived from each successive subclass.

Figure 3.16. The Win32_LogicalShareSecuritySetting class displayed in CIM Studio

Looking at the tree structure, you can see that Win32_LogicalShareSecuritySetting is derived from Win32_SecuritySetting, which in turn is derived from CIM_Setting. The Class View in the right pane displays the properties of the Win32_LogicalShareSecuritySetting class. To the left of each property name you will see one of the following icons:

• A yellow downward-pointing arrow indicates the property is inherited from the parent class.

• A property page indicates the property is defined within the class.

• A computer system indicates that the property is a system class. You can also recognize system classes by their names, which always start with a double underscore (__).

As an example, each WMI class has certain System properties, such as __PATH, __DYNASTY, __SUPERCLASS, and __DERIVATION. Here are some points to keep in mind:

• The __PATH property shows the location of the class in the namespace hierarchy. Management applications and scripts use the __PATH property to connect to the class.

• __DYNASTY, __SUPERCLASS, and __DERIVATION are all related to class inheritance and represent the root class from which the class is derived, its immediate parent, and the entire family tree of the class, respectively.

Clicking the Array button next to __DERIVATION displays the array of parent classes from which the class is derived. The array is essentially the inheritance information already observed by traversing the tree, as shown in Figure 3.17.

Figure 3.17. The array of classes from which the Win32_LogicalShareSecuritySetting class is derived, as displayed in CIM Studio

The remaining properties of Win32_LogicalShareSecuritySetting are the ones that actually represent characteristics describing instances of Windows file share security settings. You can see that except for the name, all of these properties are inherited. An object that has nothing unique about it except its name would not be very interesting, but there is more to the Win32_LogicalShareSecuritySetting class than just the class properties. The most interesting attributes of Win32_LogicalShareSecuritySetting are on the remaining tabs of the CIM Studio Class View pane.

Clicking the Methods tab displays the two methods of the Win32_LogicalShareSecuritySetting class (GetSecurityDescriptor and SetSecurityDescriptor), as shown in Figure 3.18.

Figure 3.18. The Win32_LogicalShareSecuritySetting class methods, displayed in CIM Studio, allow management applications to retrieve or modify security on file shares.

Putting It All Together

The Win32_LogicalShareSecuritySetting example in the “A Sample Help Entry” sidebar shows that the GetSecurityDescriptor method returns the current security descriptor of the file share as an object of type Win32_SecurityDescriptor. The SetSecurityDescriptor method accepts a Win32_SecurityDescriptor object as input and replaces the security descriptor on the share with information supplied in the security descriptor object. The example also lists the status codes returned by these methods.

The information on the Class View Associations tab, shown in Figure 3.19, provides the key to understanding the implementation of Win32_LogicalShareSecuritySetting.

Figure 3.19. The Win32_LogicalShareSecuritySetting class associations, displayed here in CIM Studio, link the share security setting’s objects to objects representing the share and the share’s ACL entries.

The Win32_LogicalShareSecuritySetting Associations tab shown in Figure 3.19 displays an association with the Win32_Share class as well as associations with the two instances of the Win32_SID class. Class icons marked with a diagonal arrow represent the association classes linking other classes together. If you hover your mouse cursor over the Class icons for each of the association classes linking Win32_LogicalShareSecuritySetting to Win32_SID class instances, you can see that one is a Win32_LogicalShareAccess class instance and the other is a Win32_LogicalShareAuditing class instance.

• Instances of the Win32_LogicalShareAccess association represent access control entries (ACEs) in the DACL (that is, share permissions).

• The Win32_LogicalShareAuditing instances represent ACEs in the SACL (audit settings) on the share. You can double-click any of the classes shown on this tab to navigate to it in Class View.

Because objects of the Win32_LogicalShareSecuritySetting class allow you to work with live data on the system, you would expect this to be a dynamic class. You can verify this by returning to the Properties or Methods tab, right-clicking any attribute, and selecting Object Qualifiers. The Win32_LogicalShareSecuritySetting object qualifiers are shown in Figure 3.20, including the Dynamic qualifier, which is of type Boolean with a value of True.

Figure 3.20. The Win32_LogicalShareSecuritySetting class qualifiers displayed in CIM Studio

From the Class View you can also use the Instances button to display all instances of the class, and you can open the properties of an instance by double-clicking it. The section “Hardware Inventory Through WMI” discusses how to use another of the WMI administrative tools, the WMI Object Browser, to view class instances. Just above the toolbar are icons that launch the MOF generator and MOF compiler wizards, as shown earlier in Figure 3.16. To launch the MOF compiler, you must check the Class icon next to the class and double-click the Wizard icon. The MOF language defining the Win32_LogicalShareSecuritySetting class is as follows:

The first line of the MOF entry, #pragma namespace ("\\.\ROOT\CIMV2"), is a preprocessor command instructing the MOF compiler to load the MOF definitions into the RootCIMV2 namespace. A comment block follows, which indicates the class name Class: Win32_LogicalShareSecuritySetting and the class derivation Derived from: Win32_SecuritySetting. Next, a bracketed list of object qualifiers (refer to Figure 3.20 for a GUI representation of the object qualifiers):

• The dynamic qualifier indicates that the class is dynamic and will be instantiated at runtime.

• The provider qualifier specifies that the instance provider is “SECRCW32.”

• The locale qualifier indicates the locale of the class, 1033 (U.S. English).

• The UUID qualifier is a Universally Unique Identifier for the class.

Each of these qualifiers propagates to class instances, as indicated by the toinstance keyword.

The next section contains the class declaration Win32_LogicalShareSecuritySetting : Win32_SecuritySetting. This declaration derives the Win32_LogicalShareSecuritySetting class from the Win32_SecuritySetting base class. The body of the class declaration declares locally defined class properties and methods. The Name property (the name of the share) is declared to be of type String and designated as a key value, indicating that it uniquely identifies an instance of the class. The GetSecurityDescriptor and SetSecurityDescriptor methods are both of type uint32, indicating that each method return an unsigned 32-bit integer. GetSecurityDescriptor has an output parameter of type Win32_SecurityDescriptor, whereas SetSecurityDescriptor has a corresponding input parameter of the same type. Immediately preceding each of these method definitions you will see the following method qualifiers specified:

• Privileges requests the access privileges required to manipulate Win32 security descriptors.

• Implemented is a Boolean value indicating the method is implemented in the class.

• Valuemap specifies the method’s return values. The “A Sample Help Entry” sidebar lists the meaning of each of these values.

In addition to the locally implemented properties and qualifiers, the Win32_LogicalShareSecuritySetting class inherits properties and qualifiers defined as part of its parent class, Win32_SecuritySetting.

Before continuing, you may want to explore several other classes in the RootCIMV2 namespace:

• Work your way up the inheritance tree from the Win32_LogicalShareSecuritySetting class and see where each of the inherited properties of the class originates. In addition, notice that if you bring up the object qualifiers on the parent classes, you can see these are qualified as abstract classes.

• The immediate sibling of the Win32_LogicalShareSecuritySetting class is the Win32_LogicalFileSecuritySetting class. Notice the differences in the properties and associations for this class. Share security and file security have many characteristics in common but a few important differences. Seeing how they are both derived from the Win32_SecuritySetting class demonstrates the power and flexibility of class inheritance.

• Expand the CIM_StatisticalInformation root class and then the Win32_Perf class. The two branches of Win32_Perf show how a variety of performance counters are implemented as managed objects.

This section looked at several of the default classes in the RootCIMV2 namespace and discussed how to use CIM Studio to explore a WMI namespace. The “Hardware Inventory Through WMI” section looks at how ConfigMgr uses the classes in RootCIMV2 and adds some of its own classes.

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 RootCIMV2 namespace.

The most important namespace created by the ConfigMgr client is the RootCCM namespace. Together with several namespaces under RootCCM, this namespace holds the configuration and policies that govern the operation of the ConfigMgr client. The hardware inventory process described in the next section of this chapter uses a policy stored in the RootCCMPolicyMachine namespace to specify what inventory data to retrieve from managed objects defined in the RootCIMV2 namespace. “The Configuration Manager Client WMI Namespace” section discusses additional uses of the RootCCM namespace.

ConfigMgr uses two MOF files to control hardware inventory:

The ConfigMgr client stores its machine policy in the RootCCMPolicyMachine 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:

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.21. Browsing for InventoryDataItem in the WMI Object Browser

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 RootCIMV2 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 RootCIMV2 namespace.

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

The Properties property contains a list of properties to inventory from each instance of RootCIMV2Win32_DiskDrive. Here are the properties listed:

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:

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 RootCCMPolicyMachine namespace—Win32Reg_AddRemovePrograms—configures inventory settings for reporting on items of the Win32Reg_AddRemovePrograms class in the RootCIMV2 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:

When the ConfigMgr client downloads and compiles the Configuration.mof file during its machine policy retrieval cycle, WMI adds this class to the RootCIMV2 namespace. The class uses the Registry provider (RegProv) to retrieve the information stored under HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionUninstall 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 creates WMI classes to represent its own components and configuration. The root of the ConfigMgr client namespace hierarchy is RootCCM. The RootCCM 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.

Figure 3.24. 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.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 RootCCM. Figure 3.26 shows an instance of these classes, the CacheConfig class. The CacheConfig class in the RootCCMSoftMgmtAgent 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 RootCCMpolicy 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 RootCCMpolicy<machine|user>RequestedConfig namespace. The Policy Evaluator component then uses the information in RequestedConfig to update the RootCCMpolicy<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 Rootccmpolicy<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 RootCCMscheduler namespace, as displayed in Figure 3.28.

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

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

• The Content Transfer Manager— The Content Transfer Management component uses the CacheInfoEx object in the RootCCMSoftMgmtAgent 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.

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 RootSMSsite_<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 AdminUIin 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. The properties of the DAL site displayed in the console’s Object Properties view

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

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:

The Smsprov.mof file contains the MOF language defining the RootSMS namespace and the classes it contains. You can find the Smsprov.mof file in the bin<platform> folder under the Configuration Manager installation folder. You can also export MOF definitions for instances of the following ConfigMgr object types directly from the console:

To export object definitions to MOF files, right-click the parent node, choose Export Objects, and complete the wizard to choose the instances to export and the file location as well as to enter descriptive text. You can use a similar process to import objects from MOF files.

This section showed how the SMS provider exposes Configuration Manager server components and database objects as WMI-managed objects. The “RootCCM Namespace,” “Hardware Inventory Through WMI,” and “The Configuration Manager Client WMI Namespace” sections discussed how the ConfigMgr client uses WMI to maintain its configuration and policy and to gather inventory data. The Configuration Manager SDK, which you can download from http://www.microsoft.com/downloads/details.aspx?FamilyID=064A995F-EF13-4200-81AD-E3AF6218EDCC&displaylang=en (or search for ConfigMgr SDK at www.microsoft.com/downloads), provides extensive documentation and sample code for using WMI to manage ConfigMgr programmatically, with managed code or scripts.

Microsoft’s Configuration Manager developers provide an extensive set of database views that present the underlying data tables in a consistent way. The views abstract away many of the details of the underlying table structure, which may change with future product releases. In some cases, ConfigMgr uses stored procedures in place of views to retrieve data from the tables. The reports in Configuration Manager use SQL views. Chapter 18 presents numerous examples of reports based on the SQL views. You can use the views to understand the internal structure of the database. The next sections present a subset of these views and provide information about how the views are organized and named.

Most of the Configuration Manager SQL views correspond to ConfigMgr WMI classes. In many cases, the views also reflect the underlying table structure, with minor formatting changes and more meaningful field names.

Most ConfigMgr administration tasks do not require you to work directly with SQL statements. One Configuration Manager component—ConfigMgr reporting—allows you to directly supply native SQL statements that access the site database. The ConfigMgr console also allows you to create and schedule SQL database maintenance tasks. Chapter 21, “Backup, Recovery, and Maintenance,” discusses database maintenance tasks.

The primary user interface for administering SQL Server 2005 is the SQL Server Management Studio. To access the Configuration Manager views, perform the following steps:

Viewing Collections

The “WMI on Configuration Manager Servers” section of this chapter looked in some detail at the Collections WMI object. The Collections WMI object provides access to the properties and methods of the Configuration Manager collections defined in the site database. The SQL view v_Collections provides access to much of the same data. Figure 3.38 shows the tree control expanded in the left pane to display the column definitions for v_Collections, whereas the view on the right displays some of the column values visible when opening the view. These columns correspond to the SMS_Collection WMI class properties, many of which were shown in Figures 3.33 and 3.34. Notice that the MemberClassName column provides the name of the view for the collection membership. These views correspond to the WMI objects specified in the MemberClassName property of the SMS_Collection WMI class.

Figure 3.38. The v_Collection SQL view displays the most important properties of the site’s Configuration Manager collections.

The v_Collection view is one of several views referencing Configuration Manager objects. Similar views include v_Advertisement, v_Package, and v_Report. The naming conventions for views generally map to the corresponding WMI classes, according to the following rules:

• WMI class names begin with SMS_, and SQL view names begin with v or v_.

• View names over 30 characters are truncated.

• The WMI property names are the same as the field names in the SQL views.

Other Views

Several views are included that present metadata on other views and serve as keys to understanding the view schema. The v_SchemaViews view, displayed in Figure 3.39, lists the views in the view schema family and shows the type of each view.

Figure 3.39. V_SchemaViews provides a list and categorization of Configuration Manager views.

The following SQL statement generates the V_SchemaViews view:

If you examine the SQL statement, you can see that the selection criteria in the CASE statement use the naming conventions to determine the type of each view.

The v_ResourceMap view presents data from the DiscoveryArchitectures table, which defines the views representing discovery data. Table 3.3 displays the data provided by the v_ResourceMap view.

Table 3.3. The v_ResourceMap View

ConfigMgr uses the fields in Table 3.3 in the following manner:

• The ResourceType field is the key used throughout the resource views to associate resources with the appropriate discovery architecture.

• The DisplayName field is a descriptive name of the discovery architecture.

• The ResourceClassName indicates the view that contains basic identifying information for each discovered instance of the architecture.

As an example, the v_R_System view provides the unique Resource ID of each computer system discovered by Configuration Manager as well as basic system properties such as the NetBIOS name, operating system, and AD domain. Each resource view containing system information includes the Resource ID field, allowing you to link resources such as hard drives and network cards with the system to which they belong. Chapter 18 discusses using the Resource ID to create reports using data from multiple views.

The v_ResourceAttributeMap view displayed in Figure 3.40 presents resource attribute types extracted from discovery property definition data in the DiscPropertyDefs table.

Figure 3.40. v_ResourceAttributeMap lists the attributes used in resource views.

Tip

Column Names Have a “0” Appended

The ConfigMgr development team appends the column names with “0” to avoid possible conflicts with SQL reserved words.

The v_GroupMap view lists the inventory groups and views associated with each inventory architecture. Table 3.4 displays some v_GroupMap entries. Each inventory architecture represents a WMI class specified for inventory collection in the SMS_Def.mof file.

Table 3.4. The v_ GroupMap View (Partial Listing)

Each entry in Table 3.4 specifies the resource type, a unique GroupID, the inventory and inventory history views that present the group data, and the Management Information Format (MIF) class from which the inventory data for the group is derived.

The v_GroupAttributeMap lists the attributes associated with each inventory group, and the v_ReportViewSchema view provides a list of all classes and properties.

This section examined several of the SQL views Microsoft provides. You can learn a lot about the internal structure of ConfigMgr by using the SQL Server Management Studio to explore the database on your own. You may want to look at the views, the underlying tables, and some of the stored procedures ConfigMgr uses. The examples in this section show how you can analyze and understand these objects.

Caution

Do Not Modify the Site Database Directly

The site database is critical to the functioning of your site. Do not attempt to create, delete, or modify any database objects, or to modify data stored in the database, unless asked to do so by Microsoft support personnel. Remember to test all modifications before applying them to your production environment.

As the smsprov.log and SQL Profiler trace were captured while joining a Configuration Manager site to a new parent site, the ParentSiteCode property was changed. Changing the parent site is a change to the site properties, which results in writing a new site control file. As described in the “Components and Communications” section of this chapter, the SMS provider initializes this operation, performed by the Site Control Manager, Site Hierarchy Manager, and the Database Monitor. The Site Control Manager and Site Hierarchy Manager generate milestone status messages when they have completed each major phase of processing the site control file updates. Table 3.5 displays these status messages.

The third entry in Table 3.5 identified as 2814 in the Message ID column contains the following statement:

Comparing these two files shows the delta entry in the new site control file, 00000035.ct0:

This entry indicates the change is in the Site Definition section of the file. Table 3.6 presents part of the Site Definition section of each site control file. (The parent site code entry is changed from <> to <CEN>.)

To capture this activity in detail, configure the logging for these three components to write to a single log file. This log provides a detailed record of how the Configuration Manager components work together to process changes to the site. The log entry displayed in Figure 3.43 shows the Database Monitor dropping an .SCU (Site Configuration Update) file in the Hierarchy Manager inbox.

Figure 3.43. The Database Monitor dropping a site configuration file (Trace32)

To see even more detail of the process activity that carries out the site modification, use Process Monitor to capture the file system activity of the SMSExec process during the site join. More information on Process Monitor and a link to download this useful tool are available at http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx.

Figure 3.44 shows the initial phase of the site join activity as displayed in the Process Monitor user interface. You can use some of Process Monitor’s filtering options to selectively display activity related to processing the site change:

Figure 3.44. Process Monitor displays file operations executed by selected Configuration Manager components.

Notice the NotifyChangeDirectory (directory change notifications) operations are highlighted. These initiate processing by a ConfigMgr component in response to a change to the component’s inbox folder. The first highlighted event in Figure 3.44 shows the Database Monitor (TID 2484) creating the site control update file DAL.SCU in the Hierarchy Manager inbox.

When Database Monitor creates the DAL.SCU file in the Hierarchy Manager inbox, Hierarchy Manager (TID 3420) begins reading the database for site configuration changes and preparing the delta site control (*.CT1) file.

Process Monitor can display Registry access as well as file access. You could use Process Monitor to see the details of Hierarchy Manager retrieving the Registry values it uses to construct a connection string to the site database and accessing the SQL client libraries to initiate the database connection.

The filters omit the sequence of events showing this activity. Instead, take a look at the SQL activity from the Hierarchy Manager found in the SQL Profiler data:

This shows the actual SQL queries Hierarchy Manager uses to retrieve data from the Sites and SiteControl tables. Hierarchy Manager uses this data to construct the delta site control file. Hierarchy Manager writes the site configuration changes to a temporary file and then executes a file-rename operation to place the delta site control file in the Site Control Manager inbox. The rename operation is the last event shown prior to the next highlighted NotifyChangeDirectory operation in Figure 3.44. At this point Hierarchy Manager logs the following single entry:

Hierarchy Manager also generates the first status message shown in Table 3.5 and logs this entry:

The directory change notification signals to the Site Control Manager (TID 744) that it has work to do. Site Control Manager generates the following log entries to record its processing of the delta site control file (some details are omitted here):

The logs show that after detecting the delta site control file, the Site Control Manager moves the master site control file to the history folder and creates a new site control file. Site Control Manager then enumerates and validates the changes in the new file. Once the file is validated, it becomes the new master site control file and is written to the history folder as well.

In addition, Site Control Manager writes the new site control file in SMS VarFile format to the Hierarchy Manager inbox as a .CT2 file. The Hierarchy Manager updates the sites table in the database with the new site information. Hierarchy Manager then creates a .CT6 file with the site’s public key information and forwards this file to the parent site to initiate the site join. The following log entries show Hierarchy Manager updating the database and triggering replication to the new parent site:

At this point, the SQL Profiler trace shows a large amount of activity by the Site Hierarchy Manager updating the site database with information from the new master site control file. Here’s a sampling of these queries:

The components responsible for replicating the site change to the parent site are the Replication Manager, Scheduler, and Sender. To see how Hierarchy Manager initiates the actual site join, the next section looks at some events captured with Process Monitor. It then reviews some of the key entries from the logs from the three components involved in intersite replication.

When a component requires intersite replication services, you expect to see the component write to the Replication Manager’s inbox to initiate the replication process. Here the Process Monitor data is filtered to find events that indicate files are written to replmgr.box. The filtered data is sent to Microsoft Excel for analysis. Table 3.7 contains some events related to the site-join process.

Both the Status Summarizer and Hierarchy Manager create files for Replication Manager to process:

Replication Manager scans its inboxes, finds the files, and processes them to create jobs for the Scheduler, as the following sequence of log entries shows:

Process Monitor shows Replication Manager creating the .JOB file in the Scheduler’s inbox:

Figure 3.45 displays the log entries by the Scheduler’s initial processing of these jobs, which takes place during the next Scheduler Processing cycle.

Figure 3.45. The Log Viewer (Trace32) shows the events logged during the sender processing cycle

After a 10-second delay, the Scheduler processes the sending requests.

The following excerpts from the LAN sender log show the major phases of the sending operation. First, the sender connects to the Scheduler’s outbox (..schedule.boxoutboxesLAN) to check for sender instructions. The sender then finds the send request and establishes a connection to the destination site.

When a site is joined to a new parent site, all site configuration, discovery, and inventory data is replicated to the parent site. The sending components continue this process until the replication is complete. Other processes not detailed here due to space considerations include the receiving end of the site join and the synchronization of objects and data between the newly joined sites.