CHAPTER 3
Looking Inside Configuration Manager

This chapter explores some of the internals of System Center Configuration Manager Current Branch, also referred to as ConfigMgr. It describes the architecture and how ConfigMgr is designed, at both site and hierarchy levels. It dives into components that make up ConfigMgr and external components that ConfigMgr depends on—such as Windows Management Instrumentation (WMI), SQL Server, and Internet Information Services (IIS)—and reviews site-to-site and client-to-site communication methods.

This chapter includes an overview of WMI for those unfamiliar with this venerable technology, which powers Windows manageability. The chapter discusses the infrastructure architecture of WMI and the logical WMI object model, as well as how ConfigMgr leverages WMI to provide a stable automation and development interface for both clients and servers.

This chapter also explores the ConfigMgr database, discussing its data store and data access, as well as the types of client information stored and represented in the database. It introduces ConfigMgr’s status and state message systems and the role these play in relaying client and server status throughout the hierarchy.

This chapter discusses site-to-site replication for administrators and architects considering implementation of a hierarchy. It reviews the major replication methods provided by ConfigMgr to move data and content between sites. The last section covers Active Directory (AD) integration for those implementing Configuration Manager for the first time or planning to publish site data to AD.

A combination of scalability of the various components, including sites, enables support of up to 175,000 clients in a standalone primary site or 150,000 clients in a primary site in a hierarchy. ConfigMgr therefore provides a distributed solution that scales depending on the function of each server. For example, a management point (MP), which is primarily a web service, scales up to 25,000 clients. A distribution point (DP) supports up to 4,000 client connections.

At its core, ConfigMgr is a three-tiered application:

Web Server Tier: At the front of client and user connections are web servers that host websites and web services along with servers hosting content for applications and servers. These servers are the most numerous in a site, supporting large-scale environments.

Site Server Tier: The middle tier is the site server, which performs data processing for client data along with site and site system status data. The site server also manages the site systems within the site and performs and initiates intersite communication. The site server provides servicing for the site by installing and updating other site systems and the site itself.

Site Database Tier: The third tier is the site database tier, hosted on Microsoft SQL Server. Since ConfigMgr 2012, the amount of processing performed by the database tier has steadily increased. The trend of the database tier tacking on more processing responsibilities continues in the latest version of ConfigMgr, with additional processing occurring in the site database rather than the site server or site systems.

The site server uses WMI to install new and manage existing site systems. WMI determines whether prerequisites are met and installs bootstrap services that perform the actual installations of the site systems.

WMI is also used with various functions on the client side. It is used to store client information and configuration and to provide client-side automation and SDK support for client activities, along with older component object model (COM) interfaces. The ConfigMgr client uses WMI to gather hardware/software inventory, using built-in providers to gather the information required from the operating system (OS). Hardware inventory information is gathered directly from WMI.

Knowledge of WMI is crucial to troubleshooting various ConfigMgr processes on both the client and server sides. It is also useful if you are interested in scripting, automating, or developing applications to run on top of ConfigMgr.

Management Point

Distribution Point

Software Update Point

Application Catalog

IIS is used to support .NET-based web services and ASP.NET websites (such as in the Application Catalog website and service), as well as Internet Server Application Programming Interface (ISAPI) filters and extensions (for example, in the MP). It also includes simpler file publishing capabilities for the DP. Understanding IIS is essential to troubleshooting client-side issues.

Even the ConfigMgr client contains a SQL Server Compact Edition (SQL Server CE) database for various internal functions. Microsoft does not document the database structure; ConfigMgr client automation should use the WMI Client SDK provider, discussed further in the section “The Configuration Manager Client WMI Namespace,” later in this chapter. Knowledge of SQL Server is useful for creating custom reports and troubleshooting advanced performance issues.

ConfigMgr uses SMB and file shares for content replication and intrasite communication, and clients may use it to access content. For additional information regarding client behavior and content replication, see the chapters that discuss software distribution functions: Chapter 11, “Creating and Managing Applications,” Chapter 12, “Creating and Using Deployment Types,” Chapter 13, “Creating and Managing Packages and Programs”, and Chapter 14, “Distributing and Deploying Applications and Packages.” Content includes application installation source files and OS images.

When installing site systems, you use SMB to place ConfigMgr site system installation files on the destination server to allow installation to start. This process uses administrative shares in Windows—that is, shares created automatically by Windows to enable easier remote administration of the Windows folder (%windir%) and the root folder of the hard drive. Push installation of ConfigMgr clients by the site server also uses SMB to place client installation binaries on Windows systems.

SMB also replicates information from remote site systems to the site server. The SMB connection is initiated by the site system server to the site server by default; you can override this in the site system properties in the console. Information replicated in this manner includes client-generated inventory and status and state messages received by the MP. The MP receives this information via its IIS web service and forwards it to the site server for processing.

DRS is both initialized and invoked by the site server. Replication occurs directly between the SQL Server database engine instances hosting the site database at each site and is built on a combination of SQL Server change tracking and the SQL Server Service Broker (SSB). Outside of invocation by the site server, all other work occurs inside the SQL Server database engine.

The client does not communicate directly with the site server; it communicates with site system roles. You may install site system roles on the site server, which is common in smaller ConfigMgr environments. Note that except for client push installation, the client always initiates communication to the site system from a network point of view and never vice versa. This does not imply that ConfigMgr does not push software, updates, or general instructions to clients; it refers to the network traffic and how ports are opened.

While this may appear to be an architectural limitation, it is a key design component that enables ConfigMgr to scale to the level it does. Instead of the server consuming its own Transmission Control Protocol/Internet Protocol (TCP/IP) ports making outbound connections, clients connect to a single port and pull policy. That policy might be an instruction to “push” software or updates.

This method of communication includes client notifications, used to run an immediate policy retrieval or endpoint protection scan. Here the client establishes an outbound TCP connection to the server and attempts to keep that port open. The server can then reply on the same TCP session to instruct the client to immediately perform an operation. This means the server does not have to establish an outbound connection, and no open ports are required on the client. This is very similar to the architecture Exchange ActiveSync uses to push email to mobile phones, as well as the push notification infrastructures used by Apple and Google for their respective mobile platforms.

Information and messaging within a site are routed through a series of folders and file shares called inboxes. Each inbox is located under <ConfigMgr install directory>inboxes and exists at each type of site, although some inboxes are dormant as the data they receive is not processed at that type of site. (For example, hardware inventory is not processed at the central administration site [CAS] or secondary sites.)

Another critical component is the SMS Agent Host, ccmexec.exe. This component or service, often known as the ConfigMgr client component, also serves critical functions on site system role holders such as the MP. These threads and their log files have names starting with MP_ (such as MP_Ddr.log or MP_Location.log). The MP runs primarily within IIS. Internally to IIS, it is hosted within a set of ISAPI components, which rely on ccmexec.exe threads to pull information from the site database. The components both respond to ConfigMgr client requests for policy and receive client data for eventual processing by the site server.

ccmexec.exe is also responsible for pushing client inventory, status, and state messages to the site server. You can override this in secure environments where it may be desirable to have the site server pull from a lower-trust Internet-facing MP than have that MP reach out to the site server.

Configuration Manager Update: This standalone process and Windows service is responsible for handling upgrades of sites when initiated via the Updates and Servicing node of the console. It runs prerequisite checks and initiates setup.

Discovery Data Manager: This is a set of threads of SMSExec and is responsible for processing discovery information gathered by the various discovery methods available in ConfigMgr.

Hierarchy Manager: This thread of SMSExec services various functions. It ensures that information about the site is published to AD for clients and other sites in the hierarchy. It monitors for configuration errors that could block DRS. It also serves a critical role in replicating mobile device data from Intune (see the sidebar “A Replication Exception: Hybrid MDM with Microsoft Intune,” later in this chapter). The Hierarchy Manager is integral to the site and hierarchy upgrade process in ConfigMgr Current Branch, coordinating the upgrade process and packaging upgrade content binaries/files for replication through the hierarchy.

Inventory Data Loader: This SMSExec thread is responsible for processing hardware inventory data from clients at primary site servers. It does not provide a direct function on the CAS or secondary sites.

LAN Sender: LAN Sender is a set of threads of SMSExec. This component is confusingly named, as it is responsible for replication of information between sites—and sites often reside across WAN links. This naming has to do with legacy data protocols that are no longer supported, such as X.25 and ISDN. The LAN Sender uses SMB to transmit files to file shares hosted on a destination site, and it uses certain capabilities of the SMB protocol to make these copies capable of restarting and throttling.

Replication Configuration Monitor: This SMSExec thread is responsible for handling DRS replication between ConfigMgr sites. It handles both setup and repair of replication through initialization and regular initiation of replication in SQL Server itself by executing a stored procedure (spDRSActivation). This component runs all on types of ConfigMgr sites to support DRS across the hierarchy. If this component or SMSExec is not running, the site cannot use DRS to replicate and is considered offline.

Site Component Manager: This is hosted as a separate Windows process named SiteComp.exe and is responsible for servicing and updating within a site. While Configuration Manager Update updates the site by running setup in the background, Site Component Manager is responsible for updating SMSExec and all remote site systems and also for initial installation of those site systems. If this component is stopped, servicing operations cannot successfully complete, and no new remote site system roles can be installed or removed.

This list is not exhaustive. For a more comprehensive list of components and their log files, see Appendix A, “Configuration Manager Log Files.”

For example, say that the MP pulls information from the site database. Instead of writing information there, it pushes that information to one of the site server’s inboxes, based on the type of data. The major client information inboxes include authdataldr.box (hardware inventory), authsinv.box (software inventory), and authstatesys.box (state messages).

Discovery information processing also leverages inboxes. The various discovery methods write the discovery data records (DDR, or .ddr files) to authddm.box for processing by Data Discovery Manager, which inserts this information into the site database. This is then made available via the SMS provider over WMI and SQL Server views for Transact-SQL (T-SQL) access.

Inboxes also handle the flow of information for the purposes of content replication to support application management and operating system deployment (OSD).

Basically, all ConfigMgr client and server data touches an inbox at some point—to be forwarded (for processing), replicated (if content), or processed. The key design difference from ConfigMgr 2007 and earlier is that information now traverses inboxes as seldom as possible. Information and data is no longer processed and forwarded up the hierarchy for reprocessing at a higher level or down the hierarchy (in the case of content metadata and configuration information). The newer versions of ConfigMgr process information once and rely on DRS to move data between site databases.

WMI exposes managed resources through a COM API. Programs written in C/C++ can call these resources directly, or you can access them through intermediate layers with applications such as scripts, .NET code, 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 WMI, which has been available since Windows 2000, ensures that the scripts you write will run on the widest variety of systems, although PowerShell is becoming equally ubiquitous for supported Microsoft operating systems. PowerShell has the added benefit of supporting Microsoft’s cloud services, and PowerShell itself can use WMI.

Following are examples of what you can do with WMI:

Obtain a list of all accounts on a system and rename one of them

Get a list of running processes on the system

Extract the network configuration of a system

Using an object model removes much of the complexity that is otherwise required to access and manipulate these resources. Examples of resources that are manageable through WMI include hardware devices, running processes, the Windows file system and Registry, applications, and databases.

You can use several methods to access WMI’s services and object model, including the following:

Directly on the local machine

Remotely through a Distributed COM (DCOM) network connection

Remotely using WinRM (Windows Remote Management)

Remotely using PowerShell Remoting

ConfigMgr also relies on DCOM access for remote access and calls WMI directly on systems running ConfigMgr code.

WMI supports requests from management applications to do the following:

Retrieve or modify individual data items (properties) of managed objects

Invoke actions (methods) supported by managed objects

Execute queries against the data set of managed objects

Register to receive events from managed objects

WMI handles requests from management applications as follows:

1. A management application submits a request to the WMI infrastructure, which passes the request to the appropriate provider. (The next section of this chapter describes WMI providers.)

2. The provider handles the interaction with the system resources and returns the resulting response to WMI.

3. WMI passes the response back to the calling application. This may be actual data about the resource or the result of a request operation.

Figure 3.1 shows this basic data flow in WMI.

FIGURE 3.1 Basic WMI data flow.

As dynamic link libraries (DLLs)

As Windows processes and services

The idea behind creating a provider is to relieve management applications and scripts from having to be coded specifically to use an interface or a method that a developer provides. WMI providers are translation layers between management/administrative tools and applications, and they enable applications to be easily integrated in an enterprise information technology (IT) operations environment.

Just as the WMI infrastructure serves management applications through a COM interface, providers act as COM servers to handle requests from the WMI infrastructure. When a provider loads, it registers its location and the classes, objects, properties, methods, and events it provides with WMI. WMI uses this information to route requests from management/administrative tools to the proper providers. Providers are then responsible for interacting with the underlying managed object, using whatever custom method the developer chose to implement.

Most files that WMI uses are stored by default on the file system in the %windir%system32wbem folder. The WMI Repository is a set of files located by default in %windir%System32wbem epository. The exact file system structure varies slightly depending on the Windows version.

The Winmgmt executable contains the WMI service components. The physical implementation of the WMI infrastructure varies depending on the version of Windows. Beginning with Windows Vista, Microsoft 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.

FIGURE 3.2 The major WMI infrastructure components.

Configuration parameters for the WMI service are stored in the Windows Registry subtree HKEY_LOCAL_MACHINESoftwareMicrosoftWBEM. The keys and values in this section of the Registry specify WMI file locations, logging behavior, the list of installed providers, the default namespace for scripts, and other WMI options. You rarely need to edit these options directly. As with any changes to the Registry, use extreme caution as such changes can destabilize your system.

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. Most of these logs no longer exist; Event Tracing for Windows (ETW) makes log data available to event data consumers, including the Event Log Service. Event tracing for WMI is not enabled by default. The “Managing WMI” section, later in this chapter, discusses logging and event tracing options for WMI and configuration of tracing for WMI.

Some WMI providers, such as the ConfigMgr provider, also log their activity. Appendix A discusses logging by the ConfigMgr WMI provider.

Core classes represent general constructs that are applicable to all areas of management. Core classes are part of the core model and are the basic building blocks from which other classes are developed.

Common classes represent specific types of managed objects and are generalized representations of a category of objects, such as a computer system or an application. These classes are not tied to a particular implementation or technology. The CIM_ManagedSystemElement class is the most basic and general class, and is at the root of the CIM class hierarchy.

Extended classes are technology-specific extensions of common classes, such as a Win32 computer system or ConfigMgr.

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 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 that are not inherited from the parent.

Typically, core and common classes are not used directly to represent managed objects; they are used as base classes from which other classes are derived. The “The Configuration Manager Client WMI 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 SystemClass. WMI uses system classes internally to support its operations. They represent things such as providers, WMI events, and inheritance metadata about WMI classes.

WMI classes support three types of attributes:

Properties are characteristics of managed objects, such as the name of a computer system or the current value of a performance counter.

Methods are actions that a managed object can perform on your behalf. As an example, an object representing a Windows service may provide methods to start, stop, or restart the service.

Associations are links to a special type of WMI class, an association class, which represents a relationship between other objects.

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

Static data: This data is supplied in the class or object definition and stored in the WMI Repository.

Dynamic data: This data is accessed directly through the provider and represents live data on the system.

The CIM specification includes a language for exchanging management information. 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 to the WMI Repository. Examples of information in MOF format are included in the next section.

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. The root namespace defines a hierarchy organizing the namespaces on a system. The “Managing WMI” section, later in this chapter, describes the WMI Control tool, which allows you to specify the default namespace for connections to WMI. Generally, the default namespace is rootCIMv2. This namespace defines most of the major classes for Windows management, and the next section looks at several classes in that namespace. Because ConfigMgr is all about Windows management, it is not surprising that it uses this namespace extensively. ConfigMgr also defines its own namespaces, discussed in the section “Configuration Manager and WMI.”

If you are familiar with relational databases such as SQL Server, you may find it useful to consider an analogy between WMI and a database system. Table 3.1 presents some corresponding WMI and database concepts. Table 3.1 is useful when you are attempting to correlate between SMS provider information in WMI and database views in SQL Server.

TABLE 3.1 Corresponding WMI and Database Concepts

This section discussed the major concepts of WMI and the CIM model, which are essential to understanding ConfigMgr WMI activity. To learn about other aspects of CIM, you might start with the tutorial at http://www.wbemsolutions.com/tutorials/CIM/index.html. The full CIM specification is at http://www.dmtf.org/standards/cim. Documentation for WMI is available at http://msdn.microsoft.com/library/aa394582.aspx.

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

1. Launch the Computer Management MMC snap-in (compmgmt.msc). The exact procedure varies depending on the version of Windows you are running. Generally, you can right-click Computer or My Computer and choose Manage.

2. Expand the Services and Applications node in the console tree. For server operating systems, expand the Configuration node.

3. Right-click WMI Control and choose Properties.

WMI Control opens to the General tab. As shown in Figure 3.3, the properties on this tab confirm that you have successfully connected to WMI on the local machine, display some basic properties of your system, and specify the installed version of WMI.

FIGURE 3.3 The General tab for WMI Control shows a successful connection to WMI on the local machine.

You manage WMI security from the Security tab of the WMI Control tool. WMI uses standard Windows ACLs to secure each WMI namespace existing on a machine. A namespace, as described further 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 (see Figure 3.4).

FIGURE 3.4 The Security tab of the WMI Control tool, displaying the top-level WMI namespaces.

The namespace is the most granular level for applying ACLs in WMI. The process of setting security on WMI namespaces, and the technology behind it, is similar to the process of setting NT File System (NTFS) security. If you click a namespace to select it and click Security, you see a dialog box similar to the one displayed in Figure 3.5.

FIGURE 3.5 The WMI ACL entries for rootCIMv2, the main WMI namespace.

The dialog box in Figure 3.6 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. Windows Vista enhancements to WMI, mentioned earlier in this chapter, in the section “Understanding the WMI Architecture,” include a system access control list (SACL) for WMI namespaces, which specifies the actions audited for each security principal.

To specify auditing on a WMI namespace, follow these steps:

1. In the Security dialog box, shown in Figure 3.5, click Advanced.

2. In the Advanced Security Settings dialog box, click the Auditing tab.

3. Click Select a Principal and then enter the name of the user group or built-in security principal, as shown in Figure 3.6. Click OK.

4. Select Fail from the Type dropdown menu.

5. Click Show Advanced Permissions to display a list of specific types of events to audit.

6. In the Advanced dialog box, check the desired types of events from the selection of check boxes and click OK.

FIGURE 3.6 Adding permissions for a security principal.

Figure 3.7 shows the entries to enable auditing for all access failures by members of the Domain Admins group.

The remaining tabs of the tool allow you to change the default namespace for WMI connections and provide several methods for backing up the WMI Repository. Windows system state backups also back up the repository. To enable tracing in Windows Vista and newer operating systems, enable logging and configure log options in the Windows Event Viewer.

FIGURE 3.7 Adding permissions for a security principal.

Follow these steps to enable WMI Trace Logging in Windows Vista and later:

1. Open the Event Viewer (eventvwr.exe).

2. From the View menu, select Show Analytic and Debug Logs.

3. In the tree control, expand Applications and Service Logs -> Microsoft -> Windows -> WMI-Activity.

4. To enable the Trace event log, right-click Trace and select Enable Log from the context menu. Choose Log Properties from that menu to configure logging properties for WMI. You can now view, filter, and manage the WMI log from this node in the Event Viewer tree.

Enabling WMI activity tracing causes three different types of events to be generated in the WMI activity. These logs show the start, middle, and end of a single sequence (or WMI session). Following are the possible event IDs for these events:

Event ID 1: This event shows the start of the WMI session. The key event fields are User and Namespace. The User event field allows you to focus on only the operation sessions that you are looking for (as do the Operation and GroupOperationId fields if that user account is making multiple connections). The Namespace event field is important when similarly named classes are in two different namespaces, as the next event does not provide you with details of the namespace used.

Event ID 2: This event shows the actual operations performed. There may be one or more Event ID 2 events generated, depending on the behavior of the application or script using WMI. These events contain ProviderName and Path fields. The Path field indicates the path to the WMI object called.

Event ID 3: This event shows the end of the WMI session. The only event field that this event contains is GroupOperationId, and it is used to indicate the session or sequence being closed.

Read more about WMI logging at http://msdn.microsoft.com/library/aa394564.aspx.

Note that User Account Control 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/library/aa826699.aspx.

Additional command-line tools are available for managing WMI; see http://msdn.microsoft.com/library/aa827351.aspx.

The SMS provider is typically deployed alongside the site server or site database server at each site, as discussed in Chapter 4, “Architecture Design Planning.” The provider also implements the ConfigMgr role-based administration (RBA) security model; ConfigMgr requires more granular administration controls than those provided by the WMI infrastructure. Chapter 23, “Security and Delegation in Configuration Manager,” covers RBA and security in detail.

The SMS provider has existed since Systems Management Server (SMS) was released. While the internals of the provider have changed, and object types have come and gone, its function remains unchanged. MSDN (Microsoft Developer Network) documentation sometimes refers to it as the SDK provider. The provider provides a translation layer between ConfigMgr console and the underlying SQL Server database, as shown in Figure 3.8. As SDKs tend to be stable to ensure backward compatibility and avoid breaking developer applications, the translation function of the SMS provider is critical. As Microsoft changes the database to support alterations to ConfigMgr, the SMS provider’s internal implementation also changes to talk to the altered components, keeping the public side of the interface intact. When entire features are deprecated and removed from ConfigMgr, the SMS provider removes the public interfaces.

FIGURE 3.8 Diagram of the SMS provider architecture.

An important gating and control mechanism used by the SMS provider is a locking mechanism called Serialized Editing of Distributed Objects (SEDO), which helps ensure that objects are locked across the ConfigMgr hierarchy or within a site.

This is all handled for the user by the console and the SMS provider. When the same object is edited in one site while open in another site (even by the same user), an error is thrown by the console, allowing the user to either view the object as read-only or retry accessing the same object. Figure 3.9 shows an example of the error message.

FIGURE 3.9 An error message generated by a failure to lock a remote object via SEDO.

This section uses ConfigMgr collections to illustrate how to walk through the capabilities provided by the SMS provider. (For information regarding collections, see Chapter 11 and Chapter 13.) It also walks through various SMS provider methods of extracting data. It assumes that these commands are local on the server hosting the SMS provider (usually the site server or the site database server) and that the site code of the ConfigMgr site is CAS. The commands are native PowerShell methods of interacting with WMI and not ConfigMgr-specific cmdlets, discussed in the “Interaction Between WMI and PowerShell” section, later in this chapter.

The following PowerShell command pulls all collection objects from the SMS provider:

Click here to view code image

Get-WmiObject -class SMS_Collection -namespace "rootSMSsite_CAS"

This command should return a number of collections. The following is an example of the output, showing a selection of important properties:

Click here to view code image

CollectionID                   : SMS00001
Comment                        : All Systems
LastChangeTime                 : 20160424145345.500000+***
LastMemberChangeTime           : 20160425182902.723000+***
LastRefreshTime                : 20160530110058.993000+***
MemberClassName                : SMS_CM_RES_COLL_SMS00001
MemberCount                    : 11
Name                           : All Systems

This output includes the MemberClassName property, which returns the class for all members of the collection. Use the following command to determine what devices are members of the All Systems collection:

Click here to view code image

Get-WmiObject -class SMS_CM_RES_COLL_SMS00001 -namespace "rootSMSsite_CAS"

This returns all instances of the SMS_CM_RES_COLL_SMS00001 class, which itself inherits the SMS_CollectionMember class (a generic definition of what any collection member should look like). There is one instance of the SMS_CM_RES_COLL_xxxxxxxx class per member of a collection. Each instance contains information about a member device or user (jointly referred to as a resource). Following are examples of properties that appear in the output:

Click here to view code image

DeviceOS                                 : Microsoft Windows NT Server 10.0
Domain                                   : ODYSSEY
IsClient                                 : False
Name                                     : PANTHEON
ResourceID                               : 2097152003
ResourceType                             : 5

Next, a ResourceID property is obtained. Every resource in the database has a ResourceID property that uniquely identifies it. You can use this property to find details about the client. These client details are intrinsic to that client and not related to its membership in one or more collections. The following command (which you can modify to match your client machine’s ResourceID) retrieves that information:

Click here to view code image

Get-WmiObject -class SMS_R_System -namespace "rootSMSsite_CAS" -filter
"ResourceID=2097152003"

Some of the object types introduced with ConfigMgr 2012 contain string properties that store eXtensible Markup Language (XML). While the role of the provider remains intact, using these XML properties allows for complex object models, such as the application model, and any objects based on compliance settings to be represented easily without massively extending the SMS provider object model. (Chapters 11 and 12 discuss the application model, and Chapter 10, “Managing Compliance,” covers compliance settings.) Storing this level of detail in distinct properties would mean a lot of inflexibility in regard to changes. The “Interaction Between WMI and PowerShell” section, later in this chapter, discusses how to read this information. You would write to these XML attributes by using .NET code (which is what the console does) published in the ConfigMgr SDK or PowerShell cmdlets specifically written to support these XML properties. You can see one of these XML elements by running the command in Listing 3.1 to return the XML definition of a ConfigMgr application object. (In this code, replace '7-Zip 15.14 (x64 edition)' with the name of an application in your environment.)

LISTING 3.1 Returning the XML Definition of a ConfigMgr Application Object

Click here to view code image

$app = Get-WmiObject -Class SMS_Application -Namespace "rootSMSsite_CAS"
   -Filter "LocalizedDisplayName='7-Zip 15.14 (x64 edition)'"
$app.Get()
$app.SDMPackageXML

The script returns a single string containing the XML definition of the application object. The $app variable shows very little specific information about the application, as all the critical information is stored in the SDMPackageXML property in XML.

The script has an intermediary step of calling $app.Get(). This is an important step, as the SDMPackageXML property is defined as a “lazy” property in WMI by the SMS provider. Marking a property lazy denotes that it is expensive to return relative to the other properties in an object. This may only be noticeable when a large number of instances of the class are returned. Because lazy properties are not returned using the default instantiation process for a class, these properties are returned null by default when queried. Using Get() tells WMI to return all lazy properties for a given instance of a class.

1. Run wbemtest.exe with elevated administrative rights.

2. Click Connect.

3. Under Namespace, enter rootCCM.

4. Click Connect.

5. Click Enum Instances.

6. Type __NAMESPACE and click OK.

FIGURE 3.10 Using wbemtest to view namespaces under the rootCCM namespace.

Some of the most interesting namespaces are rootCCMPolicy and its child namespaces rootCCMPolicyMachineactualconfig and rootCCMPolicy<User SID>actualconfig, which show machine and user policies targeted to that ConfigMgr agent. (Replace <User SID> with the Windows account security identifier [SID] for that user.) A policy is a combination of client settings, deployment, and schedules sent to the client by the ConfigMgr site, as discussed in the next section.

Other interesting namespaces are rootCCMSoftwareUpdates and rootCCMClientSDK. The SoftwareUpdates namespace is used to store information returned from the Windows Update Agent (WUA) API calls performed by the ConfigMgr agent as part of software update management. (See Chapter 15, “Managing Software Updates,” for information on software updates.) The ClientSDK namespace allows you to automate client-side activities. The “Automating the ConfigMgr Client via WMI” section, later in this chapter, discusses combining these two classes.

The Default Settings client settings ship out of the box with a number of preconfigured classes to gather. In some cases, you might require a custom data class. For example, you might need to gather information about an application or a specific OS configuration exposed in WMI. There may also be some Registry information you want to gather as a part of hardware inventory. (You can also determine how the Registry is configured via compliance settings; see Chapter 10.) In these cases, you import a .mof file into the default client settings or a custom client setting to gather this additional information.

To apply inventory settings from a custom .mof file, navigate to Administration -> Client Settings and either select Default Client Settings or create a Custom Client Device Settings object. On the Properties page, choose Hardware Inventory, click Set Classes, and click 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 rootCCMPolicyMachineactualconfig WMI namespace. Use wbemtest to examine some of the inventory-related objects in this namespace. Follow these steps to launch wbemtest:

1 Run wbemtest.exe with elevated administrative rights.

2. Click Connect.

3. Under Namespace, as shown in Figure 3.11, enter rootCCMPolicyMachineactualconfig.

4. Click Connect.

FIGURE 3.11 Using wbemtest to connect to the rootCCMPolicyMachineactualconfig namespace.

To return a list of available classes in this namespace, click Enum Classes. You can double-click any of the returned classes to show their definitions. Then, to return all instances of a class, click Instances. Alternatively, if you know the name of the class you want to view, use Enum Instances instead of Enum Classes on the main page of wbemtest. Use either method to view the instances of the InventoryDataItem class.

InventoryDataItem is the class that represents inventory items defined in machine policy. At first, the list looks quite intimidating, with a bunch of globally unique identifiers (GUIDs) returned in a list. However, if you scroll to the right, you see the ItemClass property and much more human-readable information. Double-clicking the row for Win32_Service returns a list of all Windows services.

The Namespace and ItemClass properties tell the InventoryAgent thread of CCMExec.exe (the main ConfigMgr client process) what to inventory and its location. InventoryAgent is the component of the client responsible for gathering inventory. The Properties property contains a comma-separated list of properties to gather for each instance of Win32_Service under the rootCIMv2 namespace. These properties follow:

Click here to view code image

DisplayName, Name, PathName, ServiceType, StartMode, StartName, Status

Instances of the Win32_Service class have additional properties beyond those listed. To add additional properties to be gathered as part of hardware inventory, modify the client settings (either default or custom ones). To view these settings, open the ConfigMgr console and navigate to Administration -> Default Client Agent Settings -> Properties -> Hardware Inventory -> Set Classes. Classes that are checked are collected along with any checked properties. Figure 3.12 shows the properties for the Win32_Service class, which represents Windows background services.

FIGURE 3.12 The hardware inventory properties gathered for instances of Win32_Service on ConfigMgr clients.

Following is a list of the key ConfigMgr client namespaces:

ScanAgent

StateMsg

SoftwareUpdates

ContentTransferManager

DataTransferService

CIStore

ClientSDK

Scheduler

RebootManagement

Messaging

DCMAgent

dcm

Policy

InvAgt

LocationServices

For example, if you want to automate software update management, you can use the CCM_SoftwareUpdatesManager and CCM_SoftwareUpdate classes to interact with and get the status of software updates, respectively. You can do the same for software distribution by using CCM_Program and CCM_ProgramManager and/or CCM_Application, CCM_ApplicationActions, and CCM_ApplicationPolicy, depending on the type of software distribution used.

A simple example of how to use ClientSDK is to get and set business hours defined on the client system. These business hours are designed to allow end users some self-service determination of when ConfigMgr client activity will occur (although ConfigMgr administrators can override this at will). Some customers want to modify or preconfigure these settings for end users. This section uses PowerShell to call out to WMI to get information about the configured business hours and change them.

You can start with getting the currently configured business hours by running the following command (run with elevated administrative rights), which invokes the GetBusinessHours method of the CCM_ClientUXSettings class:

Click here to view code image

Invoke-WmiMethod -Class CCM_ClientUXSettings -Namespace "rootccmclientsdk"
   -Name GetBusinessHours

This command returns something similar to the following (though internal WMI properties that start with __ and PSComputerName have been removed for readability):

Click here to view code image

EndTime          : 22
ReturnValue      : 0
StartTime        : 5
WorkingDays      : 62

These results show that on the test client, business hours start at 5 AM (05:00) and end at 10 PM (22:00). Figure 3.13 displays this in the Software Center.

FIGURE 3.13 The default Software Center business hours match what is found via the ClientSDK namespace.

You can alter this setting to set working hours to start at 6 AM (06:00) and end at 7 PM (19:00). Start by retrieving the order of the parameters for the SetBusinessHours method of the CCM_ClientUXSettings class. The Invoke-WmiMethod PowerShell cmdlet expects that input parameters are specified in a specific order. The following command finds the order:

Click here to view code image

([wmiclass]'rootccmclientsdk:CCM_ClientUXSettings').GetMethodParameters
  ('SetBusinessHours')

This command returns something similar to the following (though internal WMI properties that start with __ and PSComputerName have been removed for readability):

Click here to view code image

EndTime          :
StartTime        :
WorkingDays      :

This shows that the order of the input parameters is EndTime, StartTime, and WorkingDays. Leave WorkingDays as it is (on the test client, it is 62, which maps to Mon–Tue–Wed–Thu–Fri). The following command allows you to invoke the SetBusinessHours method to alter the client’s business hours to 6 AM to 7 PM (06:00 to 19:00):

Click here to view code image

Invoke-WmiMethod -Class CCM_ClientUXSettings -Namespace "rootccmclientsdk"
   -Name SetBusinessHours -ArgumentList 19,6,62

You should get a result with a ReturnValue property set to zero (success). Now if you re-invoke GetBusinessHours, you get the following (though internal WMI properties that start with __ and PSComputerName have been removed for readability):

Click here to view code image

EndTime          : 19
ReturnValue      : 0
StartTime        : 6
WorkingDays      : 62

This matches Figure 3.14, which shows the new Software Center business hours settings.

FIGURE 3.14 The changed Software Center business hours after invoking the SetBusinessHours method.

Further information on the ClientSDK namespace is available in the ConfigMgr SDK in MSDN at https://msdn.microsoft.com/library/jj874139.aspx.

Starting with ConfigMgr Current Branch version 1610, Microsoft has integrated PowerShell cmdlets into each release of ConfigMgr Current Branch. This negates the need to update the cmdlet module in addition to the console with each release. The latest information on the changes in each release can be found at https://docs.microsoft.com/powershell/sccm/overview.

One of the most important capabilities of the PowerShell module is that it introduces the ability to handle XML data types. ConfigMgr 2012 and later rely heavily on XML data types of compliance settings and related objects (software update, application management, and MDM). When these features are accessed via WMI, critical data is stored only in string WMI properties as XML. Reading this data is therefore challenging if you do not have knowledge of the data types, and writing becomes a dangerous operation to codify.

The ConfigMgr console achieves reading and writing of these XML documents via specific .NET libraries, documented in the ConfigMgr SDK. The PowerShell module requires the console to be installed so it can leverage the full suite of the .NET libraries to enable access to the SMS provider.

Compare the results of this PowerShell WMI cmdlet:

Click here to view code image

$app = Get-WmiObject -Namespace "rootsmssite_CAS" -Class SMS_Application
  -Filter "LocalizedDisplayName='Microsoft Outlook'"
Get-WmiObject -Namespace "rootsmssite_CAS" -Class SMS_DeploymentType
  -Filter ("AppModelName='" + $app.ModelName + "'")

with the results of this ConfigMgr PowerShell module cmdlet:

Click here to view code image

Get-CMDeploymentType -ApplicationName "<application name>"

The ConfigMgr PowerShell method is simpler, and you can also easily create deployment types by using Add-CMDeploymentType, whereas with WMI, you would need to build the XML in PowerShell or use PowerShell to call out to .NET, neither of which is a trivial task.

Microsoft does not publish the database schema, as it can change without notice. Instead, Microsoft publishes information about the views and works to keep these views static between releases.

As discussed in the previous section, Microsoft does not publicly document these tables. SQL Server provides another method of accessing information: using views. Consider views as virtual tables; a view is essentially a query exposing data from one or more tables. Microsoft publishes information about these views, and every built-in report in ConfigMgr is based on these views. The idea is not to isolate information from customers but rather to provide a stable platform for them to build reports and solutions. In the event that a table needs to be changed, Microsoft modifies the associated view to ensure that existing reports are not impacted. Chapter 21 provides more details on views and their usage along with other methods of reporting on ConfigMgr data.

To access the ConfigMgr views, perform the following steps:

1. Open SQL Server Management Studio by going to Start -> All Programs -> Microsoft SQL Server <version> -> SQL Server Management Studio.

2. After the console launches, enter the name of the SQL Server hosting the ConfigMgr site database.

3. After the connection completes, expand the <servername>databaseCM_<site code>views in the left-hand pane.

FIGURE 3.15 v_Collection displayed using SQL Server Management Studio.

Figure 3.15 shows the CollectionID column as the unique (within the hierarchy) identifier for the collection. This is an important column when you want to link v_Collection to other views. You can also use this column with v_FullCollectionMembership to return devices or users in a given collection.

In addition, there are views created dynamically for each collection, named v_CM_RES_COLL_<collectionID>. For example, the view v_CM_RES_COLL_SMS00001 represents the default All Systems collection. As you create collections, more of these dynamic collections are created, each containing the member users or devices of that collection. This is useful when you are writing scripts or queries that need to access collection members and you need to use a specific collection every time. If you need to parameterize, or take the collection as input to the script/query you are writing, using v_FullCollectionMembership provides a better view.

LISTING 3.2 Extracting the Endpoint Protection Definition Update Fallback Source

Click here to view code image

SELECT AMSettings.Name, CliSettings.PropertyName,

   AMSettingsValue.FallbackSource.value('.', 'nvarchar(max)') AS 'FallbackSource'
FROM vSMS_AntimalwareSettings AS AMSettings

JOIN vSMS_ClientAgentConfig_Base AS CliSettings
ON AMSettings.ID = CliSettings.SettingsID

CROSS APPLY CliSettings.XmlValue.nodes('/StringArrayXML/Value') AS
AMSettingsValue(FallbackSource)

WHERE CliSettings.PropertyName = 'FallbackOrder'

This should return something similar to the information shown in Figure 3.16, with readable information for each endpoint protection policy defining the fallback order to use.

FIGURE 3.16 Query results showing how XML data is presented when handled via T-SQL.

SELECT [Type],[ViewName] FROM [v_SchemaViews] WHERE [Type]='Schema'

LISTING 3.3 Searching the Definitions of All Database Views for a Particular String

Click here to view code image

DECLARE @varObjectToSearchFor varchar(max)

SET @varObjectToSearchFor = '%ResourceID%'

SELECT
udf.name AS [Name]

FROM
sys.objects AS udf
LEFT OUTER JOIN sys.sql_modules AS smudf ON smudf.object_id = udf.object_id
LEFT OUTER JOIN sys.system_sql_modules AS ssmudf ON ssmudf.object_id = udf.object_id
WHERE
(udf.type = 'V') AND
(ssmudf.definition LIKE @varObjectToSearchFor OR smudf.definition
   LIKE @varObjectToSearchFor)

ORDER BY
[Name] ASC

Conversely, status messages are useful for task sequences in OSD. Because a task sequence (TS) is a custom set of steps defined by an administrator, generating a hard-coded set of state messages would not be useful as these messages could only define known stages (such as starting, processing, and ending a TS). Status messages are generated for each step in the TS during task sequence execution. (For more information about OSD, see Chapter 22, “Operating System Deployment.”)

Status messages are also useful for picking up specific events from site servers and site systems for methods of eventing as data from clients is processed and internal processes occur. For example, if the Data Loader (DataLdr) is unable to process a delta inventory because it has yet to receive a full inventory (usually because a client was deleted manually from the console), it generates a status message to reflect that. If the Site Component Manager (SiteComp) cannot install or reinstall a site system role, it generates a status message for each failed attempt.

Client status messages are sent via the MP to the primary site server for processing. Both client and server status messages are written to the statmgr.box inbox for processing and are processed by the Status Manager component of SMSExec on the site server and inserted into the site database.

For example, a certain topic type defines some state messages as relating to application management. Within that topic type are state message IDs that correlate to the various states of an application deployment, including Success, In Progress, Unknown, Requirements Not Met, or Error. The instance of the topic type in this case is an application deployment to a user or device. Each message reflects a state of the deployment and overwrites the last reported state. Conceptually, an application deployment may go from Unknown to In Progress and then to either Success or Error, depending on whether the application installer succeeded or failed.

State messages are used primarily to support client operations and reduce the need for repeated messages and are generally less noisy than status messages. For example, if an application repeatedly fails, it may simply stay in the Error state unless the specific type of error changes. Contrast this with status messages, which are generated for each attempt, with potentially more than one status message per attempt. A client also maintains a list of the various activities and deployments for which it has sent a state message; wherever possible, it attempts to send delta state messages to reduce the load on the site infrastructure.

State messages are sent via the MP to the primary site server for processing. They are written to the authstatesys.box inboxes for processing and are in turn processed by the State System component of SMSExec on the site server and inserted into the site database.

These files contained client data (status and state messages along with inventory and discovery) and server data (status messages and discovery data). These were processed at each site, which had an impact on the scalability of the site as the messages had to be processed at each site they traversed to ensure that each site’s database contained the correct information. This lack of scalability led to bloated hierarchies with additional sites just to distribute (scale out) processing load.

This method was inefficient because information was processed at least twice in a hierarchy—once at the primary site and again at the central site. In complex and large hierarchies with multiple tiers of primary sites (which was possible with ConfigMgr 2007 and earlier versions), this could cause the same file to be processed numerous times. Each processing incurred write costs into the site database for each site, along with inbox processing by ConfigMgr components. The event of a flood of data to process at any one site resulted in a flood of data to every site above that flooded site.

ConfigMgr 2012 removed this issue by introducing database replication. Database replication is a slightly confusing term as transactional database replication is one of the most common methods of database replication used by SQL Server database administrators. This term was also used in early beta versions of ConfigMgr 2012. For this reason, this book refers to it as DRS from here on, as DRS has nothing to do with transactional database replication in SQL Server.

DRS uses SQL Server change tracking to monitor for table changes and store them. With each activation of DRS by SMSExec’s Replication Control Manager (RCM), changes since the last activation are reviewed and bundled into compressed XML messages and passed to the SSB. The SSB provides a guaranteed transmission method between SQL Server database engine instances for an SQL Server-based application, in this case ConfigMgr. The term guaranteed is used from a developer point of view to refer to a transmission method that the developer is not responsible for maintaining; rather, the SSB provides a resilient transmission method for atomic messages where the developer can fire messages and assume that they were delivered.

As part of creating a ConfigMgr site in a hierarchy, asymmetric keys are exchanged for authentication of each SQL Server database engine instance for use with the SSB. Setup also initializes the database on each end of the replication. The initialization extracts from the database information that is authoritative for that type of data. The CAS is authoritative for global data, which includes all console objects. Primary sites are authoritative for site data, which includes client data (inventory, state/status, and discovery) along with site-specific information (state and status messages). In addition, some types of data could be conceptually viewed as being shared—in the sense that the CAS and its child primary sites both write different information to the same table. For the purposes of DRS, authority is defined at the table layer and not within a table. This is an important distinction, as DRS is used to recover a site outside its change-tracking interval.

For these reasons, if you implement a hierarchy, it is important to monitor DRS replication between your ConfigMgr sites to ensure that any outage is resolved as quickly as possible. Furthermore, while it is possible to increase the data retention value to 14 days, doing so has an impact on the performance of the site database and SQL Server because almost three times the amount of data for the changes must be stored in the site database.

DRS CRASH COURSE

As discussed earlier in this section, change tracking detects changes within a site database for the purposes of DRS. These changes must be stored somewhere for subsequent use. There are scenarios where a transmission outage between two sites could occur: There could be a transitory network issue, or one of the site servers (or a site database server) could be down. Change tracking has a rolling buffer to cater for these sorts of outages. By default, this rolling buffer is configured to store 5 days’ worth of data. You can configure the data retention value from 1 to 14 days via the Database properties for the site database in the ConfigMgr console under Monitoring -> Database Replication -> Parent Database Properties (or Child Database Properties, depending on the server you are changing). Figure 3.17 shows the default configuration for a CAS database.

FIGURE 3.17 Data retention setting on a CAS’s database properties in the ConfigMgr console.

Notice the lengthy text describing this setting in Figure 3.17. By default, there is potential data loss in scenarios where an outage lasts longer than 5 days. Changes that occurred more than 5 days ago are lost, as SQL Server change tracking has a default retention of 5 days. DRS therefore knows it has some missing data (that occurred after the 5-day mark) and cannot trust any of the data sent or received since that truncation occurred (even if only a single day). When this occurs, the site goes through a process of reinitialization. Much as with initial setup, data is extracted from the parent and child database, sent via the file replication (SMB) method to each site, and inserted in bulk into the receiving database. Replication can continue from there via DRS.

As each site is authoritative for its own data and the CAS is authoritative for global data, there is minimal potential for overlap. There is a potential for data loss in scenarios where administrators begin editing global data or objects (applications, client settings, software update deployments, and so on) at the child primary site. In practice, administrators may unknowingly do this to allow client operations to continue to function during a replication outage. It is necessary to do so only when you are sure you can restore communication via the two sites within the data retention period. If this is not possible and the replication between the two sites is down for over 5 days, any changes to global data made at the primary site are overwritten by changes from the CAS. This overwriting occurs because ConfigMgr reinitialized DRS between the two sites, and the CAS’s export overwrites all global data at the primary site, regardless of who modified the data (because the CAS is authoritative for global data).

ConfigMgr uses ADDS implicitly to support authentication and authorization through the use of computer accounts, primarily through use of the Local System account, and optionally with service accounts to perform certain operations. ConfigMgr can also use published information about its sites and services, making that information easily accessible to ADDS clients. ConfigMgr clients treat AD as a trusted location for obtaining information to confirm the identity of a site’s MPs. To take advantage of these capabilities, you must extend the AD schema to create classes of objects specific to ConfigMgr.

While it is not necessary to extend the schema for ConfigMgr operations, it is required for certain ConfigMgr features. Extending the schema greatly simplifies ConfigMgr deployment and operations. The following section discusses the process of extending the AD schema. Chapter 4 discusses the benefits and feature dependencies of the extended schema and why you might want to include schema extensions in your design.

Before actually extending the schema for ConfigMgr, run the dcdiag and repladmin commands included as part of the Domain Controller role in Windows Server. These tools validate that all domain controllers are replicating and healthy. Because it may be difficult to validate the output of these tools, output the results to a text file by using the following syntax:

Click here to view code image

dcdiag > %temp%dcdiag.log

In the case of repladmin, the following syntax (all on one line) helps to validate the state of replication:

Click here to view code image

repadmin /replsum /bysrc /bydest /sort:delta > %temp%
epladmin.log

Review the output of the repladmin command to ensure that all domain controllers show no replication failures (that is, 0 in the Fails column). For more information on how to perform schema changes, see https://msdn.microsoft.com/library/windows/desktop/ms676929.aspx.

After you extend the ADDS schema and perform the other steps necessary to publish site information to ADDS, ConfigMgr sites can publish information to ADDS. The next sections describe the process for extending the schema and configuring sites to publish to AD, as well as the AD objects and attributes created by the schema extensions.

Running the ExtADSch.exe utility from the ConfigMgr installation media

Using the LDIFDE (Lightweight Directory Access Protocol [LDAP] Data Interchange Format Directory Exchange) utility included with Windows Server to import the ConfigMgr_ad_schema.ldf LDIF file

To use all the features of ConfigMgr, you must use AD with a Windows Server 2008 or later domain functional level. All site systems must be members of a Windows Server AD domain that meets that domain functional level (though it does not need to be the same domain or in some cases the same forest). ConfigMgr clients may be joined to a workgroup or a domain. For a complete list of Active Directory support requirements, see https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-active-directory-domains.

Find detailed information about using LDIFDE at https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc731033(v=ws.11) and ConfigMgr-specific instructions at https://docs.microsoft.com/sccm/core/plan-design/network/extend-the-active-directory-schema. The following example is a typical command to update the schema for ConfigMgr:

Click here to view code image

LDIFDE -i -f – ConfigMgr_ad_schema.ldf -v -j %temp%SchemaUpdate.log

The verbose logging available with LDIFDE includes more detail than the log file generated by ExtADSch.exe. The ConfigMgr_ad_schema.ldf file allows you to review all intended changes before they are applied, or you can provide the ConfigMgr_ad_schema.ldf to your Active Directory administrators for them to review if required.

The ConfigMgr schema modifications create 4 new classes and 14 new attributes used with these classes. The classes represent the following:

Management Points (MS-SMS-Management-Point): Clients can use this information to find a management point and confirm the identity of a management point in case the policy signing key changes (for example, during a site recovery).

Roaming Boundary Ranges (MS-SMS-Roaming-Boundary-Range): Clients can use this information to locate ConfigMgr services based on their network location.

Server Locator Points (MS-SMS-Server-Locator-Point): This legacy class is created but not used as part of ConfigMgr Current Branch schema extensions. It was used in ConfigMgr 2007 to enable clients to find an SLP and determine their assigned site. The SLP role no longer exists; its functionality has been integrated into the MP.

ConfigMgr Sites (MS-SMS-Site): Clients can retrieve important information about the site from this AD object.

Objects and attributes in the ConfigMgr schema modification are prefixed with MS-SMS, which helps minimize the risk of collisions with other custom or application-specific schema extensions. In addition, all objects and attributes in the schema have the isMemberOfPartialAttributeSet flag set to True. This flag causes instances of these objects and attributes to be included as part of the partial attribute set and marked for replication to all global catalog domain controllers in the forest. This allows a site server that is a member of a domain to advertise its existence to all clients in the forest instead of just that domain.

The chapter discussed WMI and ConfigMgr’s utilization of WMI at the server and client levels. This chapter also looked at the ConfigMgr database in depth, providing information on how to view the various SQL Server views available to administrators. A review of replication of content and DRS explains how information is moved through a hierarchy. The chapter also provided a summary of the ConfigMgr schema extensions to ADDS.