Looking Inside Microsoft Configuration Manager Current Branch
- Understanding the ConfigMgr Architecture
- A WMI Primer
- Configuration Manager and WMI
- Inside the ConfigMgr Database
- Status and State Messages Overview
- Site-to-Site Replication
- Active Directory Integration with ConfigMgr
- Summary
Discusses the design concepts behind Configuration Manager Current Branch, major ConfigMgr components, its relationship with Windows Management Instrumentation (WMI), the ConfigMgr database, and more.
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
Understanding the ConfigMgr Architecture
Configuration Manager is a highly scalable client management solution capable of supporting over a million client devices in a single hierarchy. Part of its capability to scale is due to its internal architecture. This chapter discusses ConfigMgr internals, providing information on how it operates and laying a foundation for further learning about ConfigMgr.
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.
External Components to ConfigMgr
The following sections describe components that are crucial to the functioning of ConfigMgr. While these are not the only underlying components leveraged, they are the most crucial and are the ones you will come across most regularly.
The Role of WMI
WMI is used heavily throughout ConfigMgr. Used by the SMS provider on the server side, it provides a software development kit (SDK) interface to the site database. All administrative write and, optionally, read access to the site database is performed via WMI. This includes the ConfigMgr console itself. Every change made in the console is sent via remote procedure call (RPC) to the SMS provider. This WMI provider provides a stable platform to build applications and a gating mechanism to control access. ConfigMgr’s PowerShell cmdlets also leverage the SMS provider for access.
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.
The Role of IIS
IIS is a built-in component of Windows Server that enables Windows to host websites and services. ConfigMgr uses IIS to enable the platform to build its websites and services. ConfigMgr uses IIS to host a range of site system roles, including the following:
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.
The Role of SQL Server
Microsoft SQL Server is the only database engine supported for hosting the ConfigMgr site database. Its database engine also provides the core components that enable ConfigMgr’s database replication service between sites. As discussed in the earlier section “Understanding ConfigMgr Architecture,” the site database of ConfigMgr has been performing an increasing amount of computation and processing of data since the 2012 release.
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 Communication Methods
ConfigMgr uses a variety of communication methods between clients and servers. Understanding these methods can assist with troubleshooting as well as designing environments with complex network security requirements.
Server Message Block Protocol
Server Message Block (SMB), the protocol powering Windows Server file servers and file shares, has been used for file sharing since the early days of Windows. While the protocol has changed greatly over the years, these changes are not critical to ConfigMgr’s usage of SMB.
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.
Data Replication Service
DRS is a communication method first introduced in Configuration Manager 2012. It replaced the file-based replication methods previously used, removing the need to reprocess those files at each site in a hierarchy. All non-content replication between sites uses this method of replication.
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.
ConfigMgr Client Communications
Client communications in ConfigMgr primarily occur via HTTP or optionally HTTPS between the client and the MP, DP, and software update point (SUP). Several exceptions include clients accessing legacy package/program content from DPs and booting to Windows Preinstallation Environment (WinPE) via the Preboot eXecution Environment (PXE) protocol from a PXE-enabled DP.
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.
ConfigMgr’s Internal Components
A site server has several core internal components, each with a specific function. The most important ConfigMgr process is SMSExec, the SMS Executive, which is the main service on the site server. All major site server functions exist as threads underneath this process. The ConfigMgr console refers to these threads as components. A single component often consists of multiple threads responsible for initializing all types of intersite replication, processing of client information, processing of ConfigMgr site system information, and installation of site system roles.
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.
Key Site Components
The following are some of the key site components and their functions:
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.”
ConfigMgr’s Use of Inboxes
Inboxes in ConfigMgr have a long history. Although still crucial, their criticality to the operation of a ConfigMgr site and its hierarchy has been reduced over the years. All client data passes through the inboxes located in the <ConfigMgr install directory>\inboxes folder on the site server.
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 auth\dataldr.box (hardware inventory), auth\sinv.box (software inventory), and auth\statesys.box (state messages).
Discovery information processing also leverages inboxes. The various discovery methods write the discovery data records (DDR, or .ddr files) to auth\ddm.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.