Microsoft Configuration Manager
Microsoft Configuration Manager is a comprehensive systems management solution developed by Microsoft, designed to help IT administrators manage devices, applications, and infrastructure across on-premises, cloud, and hybrid environments.[1] It enables the deployment of operating systems, software updates, and applications; enforces compliance policies; monitors system health; and provides detailed inventory reporting for large-scale Windows deployments, with macOS support via co-management with Microsoft Intune and limited capabilities for Linux servers.[2] As part of the Microsoft Intune suite, it supports secure and scalable operations by integrating with tools like Azure, Windows Server Update Services (WSUS), and Active Directory, reducing manual tasks and optimizing resource utilization.[1] Originally introduced as Systems Management Server (SMS) in 1994 to address software distribution and inventory needs in enterprise networks, the product evolved significantly over the decades.[3] In 2007, it was rebranded as System Center Configuration Manager (SCCM) to align with the broader System Center portfolio, introducing advanced features like desired state configuration and enhanced endpoint protection integration.[4] The platform shifted to a current branch servicing model in 2016, allowing frequent updates without full version upgrades, and was renamed Microsoft Endpoint Configuration Manager (MECM) around 2020 as part of the Microsoft Endpoint Manager initiative, emphasizing cloud-hybrid capabilities alongside Microsoft Intune.[5] In March 2023 with version 2303, it received its current name, Microsoft Configuration Manager, to simplify branding while maintaining backward compatibility and support for existing deployments.[6] Key features include the Configuration Manager console for centralized administration, Software Center for end-user self-service, and cloud-attached management options that enable co-management with Intune for modern endpoint scenarios.[1] It supports real-time analytics, remote actions on devices, and integration with Microsoft Defender for Endpoint to enhance security posture.[7] As of November 2025, the product follows an annual release cadence starting with version 2609, focusing on security enhancements and streamlined servicing to meet evolving enterprise needs.[8]History
Origins as Systems Management Server
Microsoft Systems Management Server (SMS) 1.0 was launched on November 7, 1994, marking Microsoft's inaugural enterprise management tool designed specifically for Windows NT networks.[4] Development began in 1992 with a small team of two engineers and an intern, taking over two years to complete the initial release, which aligned with the build numbering of Windows NT Server 3.5.[4] This product emerged as a foundational solution for IT administrators seeking to oversee distributed computing environments amid the rapid proliferation of personal computers in corporate settings.[4] The creation of SMS 1.0 responded to the escalating demands for centralized management in client-server architectures following the widespread adoption of Windows 3.1.[4] As organizations transitioned from mainframe-based terminal emulation to x86-based distributed systems, there was a critical gap in tools capable of scaling PC management across enterprises.[4] Built on Windows NT Server 3.5, SMS 1.0 supported a diverse array of clients including MS-DOS, Windows, Windows NT, Macintosh, and OS/2, while integrating with networks such as NetWare, LAN Manager, and Pathworks.[9] Key features of SMS 1.0 included software distribution, which utilized a drag-and-drop interface to schedule and remotely install software and data packages across the network.[9] Inventory collection automatically gathered hardware and software data enterprise-wide, enabling hierarchical domain support for asset tracking.[9] Remote control capabilities allowed administrators to execute programs, update configurations, and perform troubleshooting directly from the server.[9] Early adoption of SMS 1.0 faced challenges due to its initial limitation to local area network (LAN) environments, lacking support for wide area networks (WANs) and thus restricting scalability in geographically dispersed setups.[9] Despite this, the tool demonstrated potential for managing tens of thousands of PCs, with endorsements from 25 third-party vendors including AT&T, Compaq, and Hewlett-Packard at launch.[9]Transition to Systems Center Configuration Manager
In 2007, Microsoft rebranded its Systems Management Server (SMS) 2003 product as System Center Configuration Manager (SCCM) 2007, marking a significant evolution in enterprise systems management tools. Released on November 29, 2007, SCCM 2007 introduced native mode operations, which provided deeper integration with Active Directory for enhanced authentication, site publishing, and discovery services, as well as seamless compatibility with Windows Server Update Services (WSUS) for streamlined software update management. This shift addressed limitations in the legacy mixed-mode operations of SMS, enabling more secure and efficient management of distributed environments supporting Windows Vista and Windows Server 2008.[10][11] The rebranding to SCCM aligned the product with Microsoft's emerging System Center family, which aimed to deliver a unified portfolio for IT infrastructure management, including tools like Operations Manager and Virtual Machine Manager. By emphasizing configuration management over general systems management, the name change reflected a strategic focus on desired state management and broader ecosystem integration, facilitating easier adoption within heterogeneous enterprise settings. This alignment helped position SCCM as a core component for holistic IT operations, reducing silos between server, client, and network management.[4] Subsequent enhancements in SCCM 2007, particularly through the R2 release in 2009, expanded support for virtualization technologies, including integration with Microsoft Application Virtualization (App-V) for streaming virtualized applications to endpoints without full installation. These updates improved scalability for virtual environments by enabling efficient deployment and management of sequenced applications, alongside features like out-of-band management via Intel AMT for remote hardware control. Service Pack 2 in 2009 further bolstered support for Windows 7 and Windows Server 2008 R2, enhancing overall performance and security.[12][13] The transition culminated in major milestones with SCCM 2012, released in 2012, which introduced role-based administration (RBA) for granular security control across hierarchies, the application model for user-centric software delivery with supersedence and revision tracking, and initial cloud attachments via integration with Windows Intune for hybrid management scenarios. Service Pack 1 in 2013 added support for mobile device management and enhanced cloud proxy features, while Service Pack 2 in 2015 refined scalability for large-scale deployments. These advancements solidified SCCM's role in bridging on-premises and emerging cloud-based IT strategies.[14][15][16][17]Modern Evolutions and Integrations
In 2016, Microsoft introduced the Current Branch servicing model for Configuration Manager, enabling faster delivery of new features through semi-annual updates rather than infrequent major releases. This shift allowed administrators to adopt enhancements more rapidly while maintaining stability, with the model becoming available to customers with active Software Assurance rights starting October 1, 2016.[18] Notable releases under this model include version 1806, which improved application management and cloud integrations, and version 1910, which enhanced reporting and compliance tools.[19] The product underwent a significant rebranding in 2019 to Microsoft Endpoint Configuration Manager, reflecting its evolving focus on endpoint management across hybrid environments. This change, first appearing in version 1910, aligned the tool more closely with Microsoft's broader endpoint strategy, emphasizing device-centric capabilities over traditional systems management.[20] Throughout the 2020s, key developments centered on enhanced co-management with Microsoft Intune, allowing seamless workload shifting between on-premises and cloud-based management for Windows 10 and later devices. This integration, which matured with updates like version 2103 for improved autopilot scenarios and version 2203 for advanced compliance reporting, enables organizations to leverage Intune for mobile device management while retaining Configuration Manager for complex deployments.[21] Support for Windows 11 was added starting in version 2107, including client installation on ARM64 devices and OS deployment capabilities, with further refinements in version 2403 for full ARM64 task sequences.[22] Additionally, Configuration Manager facilitates modern workload deployments, such as the Microsoft Teams desktop client, through application packaging and bulk installation methods that integrate with Microsoft 365 Apps updates.[23] By 2025, integrations with Microsoft Purview advanced compliance management, particularly through device onboarding for endpoint data loss prevention on Windows 10/11 and macOS devices managed via Configuration Manager.[24] Version 2403 and subsequent releases introduced analytics, including an automated diagnostic dashboard for software update health that monitors deployment issues and provides proactive insights to reduce troubleshooting time.[25] These evolutions underscore Configuration Manager's alignment with Microsoft's endpoint ecosystem, supporting hybrid cloud strategies amid the announced transition to an annual release cadence starting with version 2609.[8]Architecture and Components
Core Site Infrastructure
The core site infrastructure of Microsoft Configuration Manager consists of server-side components that enable centralized management of devices and applications across an organization. These elements form the foundational backbone, handling data storage, content distribution, and client interactions within a site's hierarchy. Primary and secondary site servers provide the structural core, while site system roles such as distribution points and management points support operational efficiency by managing content delivery and communication flows.[26] The primary site server serves as the central hub for a Configuration Manager site, hosting essential services and the site database. This database, built on Microsoft SQL Server, stores all site-specific data, including configuration settings, inventory information, and deployment details, ensuring reliable access and management for the site's resources. The SMS Provider, a key component on the primary site server, acts as the interface for site data storage and retrieval, allowing administrative tools like the Configuration Manager console to interact with the database securely. Primary sites can operate as stand-alone entities for smaller deployments or as child sites within a larger hierarchy, supporting direct management of up to hundreds of thousands of clients depending on scale.[27][26] Secondary site servers extend the reach of a primary site into distributed or remote environments, particularly where network links are slow or unreliable, by managing a subset of clients without replicating the full primary site database. Installed as child sites beneath a primary site, they use a lightweight local database—typically SQL Server Express—to handle local operations, compressing data transfers to the parent site for efficiency. This setup reduces bandwidth usage and latency for remote management tasks, with secondary sites automatically including default roles like distribution points for localized support. Each primary site can support up to 250 secondary sites, making them suitable for large, geographically dispersed organizations.[28][26] Distribution points (DPs) are dedicated site system servers responsible for storing and delivering content, such as software packages, updates, and operating system images, to managed clients. Content is replicated from the site server to DPs via multicast or unicast methods, with DPs organizing files in a content library to optimize storage and access. In cloud-integrated scenarios, pull distribution points enable DPs to fetch content on-demand from source DPs, reducing administrative overhead and supporting hybrid environments like Microsoft Azure. DPs can be configured with features like PXE booting for automated deployments and HTTPS for secure delivery, and boundary groups direct clients to the nearest available DP to minimize network traffic.[29] Management points (MPs) facilitate communication between clients and the site infrastructure, serving as the primary endpoint for policy retrieval and data submission. Clients connect to an MP to receive assigned policies, such as software deployment instructions, and to upload inventory and status data, which the MP then forwards to the site database. MPs support HTTPS communication for enhanced security and can use database replicas to offload query processing from the primary database server, improving performance in high-volume environments. Installed by default on primary and secondary site servers, additional MPs can be added to handle load balancing, with each primary site supporting up to 15 instances.[30]Client-Side Components
The Configuration Manager client agent is the primary software component installed on managed devices, enabling them to communicate with site servers, retrieve policies, and execute management tasks. This agent runs as the SMS Agent Host service, implemented by the executable ccmexec.exe, which relies on Windows Management Instrumentation (WMI) for core operations such as policy evaluation and enforcement. The service hosts various client-side processes, including those for inventory collection and software deployment, ensuring devices remain compliant with organizational policies.[31] Client push installation is a common method for deploying the Configuration Manager client to Windows devices, where the site server automatically discovers eligible computers through Active Directory integration and initiates the installation without manual intervention. This process uses the CCMSetup.exe installer, which can be configured with parameters to specify site assignment and management points during setup. Alternatively, manual installation allows administrators to run CCMSetup.exe directly on devices, providing flexibility for environments without Active Directory discovery.[32] Key client-side components include the Client Location Services, which enable devices to identify and connect to appropriate site system roles, such as management points, by querying for site resources based on network location and boundary groups. The Hardware Inventory Agent, another essential component, periodically collects detailed hardware configuration data from devices—such as processor, memory, and disk information—and reports it back to the site server via WMI queries, supporting asset management without requiring additional software. These components operate under the ccmexec.exe service to minimize resource overhead while maintaining real-time communication.[33][34]Hierarchical Site Structure
Microsoft Configuration Manager employs a hierarchical site structure to enable scalable management across large, geographically distributed environments, allowing organizations to interconnect multiple sites for centralized oversight and efficient data flow. This topology supports deployments ranging from a single standalone primary site to complex hierarchies with a central administration site (CAS) at the top level, overseeing child sites to handle global policies, reporting, and resource distribution. The central administration site serves as the top-tier component in multi-site hierarchies, designed to manage and monitor multiple primary sites without directly handling client devices or roles such as management points. It coordinates hierarchy-wide configurations, including policy enforcement and aggregated reporting from all child sites, ensuring consistent administration across the organization. For instance, the CAS replicates global data like software deployments and collection definitions to all sites, facilitating unified management in enterprises with thousands of devices.[35] Parent-child relationships form the backbone of the hierarchy, establishing bidirectional replication between sites to synchronize essential data such as boundaries, collections, and configurations. In this model, a CAS acts as the parent to up to 25 child primary sites, while each primary site can parent multiple secondary sites to extend coverage to remote locations. Replication occurs via SQL Server, using change tracking and the Service Broker on TCP port 4022 to merge updates bidirectionally; global data propagates downward to all sites, site-specific data like inventory flows upward to parents, and content uses file-based methods for secondary sites over low-bandwidth links. This ensures data consistency without overwhelming network resources, with initial snapshots transferred via SQL Server Bulk Copy Program.[35] Boundary groups enhance the hierarchical structure by logically organizing network boundaries—such as IP subnets or Active Directory sites—to define client assignment and resource access across sites. These groups associate boundaries with site system roles like distribution points (DPs) for content delivery and management points (MPs) for communication, allowing clients to efficiently locate nearby resources and reducing WAN traffic in multi-site setups. In a hierarchy, boundary groups can overlap and include fallback options, enabling clients to request services from preferred or adjacent sites as needed.[36] Scaling considerations in the hierarchy emphasize performance and capacity limits to support expansive deployments. A single CAS can oversee up to 25 primary sites, each managing up to 250 secondary sites, with SQL Server replication optimizing data transfer to maintain efficiency in large-scale environments. Organizations must plan topologies based on device count, geography, and bandwidth, often starting with a standalone primary site and expanding to include a CAS as needs grow beyond 175,000 clients.[37]Features and Capabilities
Software Distribution and Patching
Microsoft Configuration Manager facilitates software distribution and patching by enabling administrators to deploy applications, updates, and operating systems to managed endpoints across an organization. This process relies on a centralized console for creating, distributing, and enforcing software deployments to device or user collections, ensuring consistency and compliance with organizational policies. Content, such as installers or update files, is first packaged and sent to distribution points—servers that store and serve files to clients—before clients download and install them based on assigned schedules or user interactions via Software Center.[38] The application model in Configuration Manager supports modern deployment of software using MSI or MSIX formats, allowing for flexible packaging that includes multiple deployment types per application. Administrators define detection methods, such as file existence, registry keys, or scripts, to verify if an application is already installed on a target device, preventing unnecessary redeployments. Requirements can specify conditions like operating system version, architecture, or free disk space before installation proceeds. Supersedence rules enable automatic upgrades by designating newer application versions to replace older ones, streamlining version management without manual intervention. Unlike legacy packages, which offer basic script-based installations, the application model provides advanced features like simulation testing and user-friendly notifications in Software Center.[38][39] For patching, Configuration Manager integrates the Software Update Point (SUP) with Windows Server Update Services (WSUS) to synchronize and manage software updates from Microsoft Update or upstream servers. The SUP, installed on a site system server, retrieves update metadata during scheduled synchronizations—typically daily—and replicates it across the hierarchy for child sites. Clients scan for compliance using this metadata, reporting states like "Required" or "Installed" back to the management point, which administrators can monitor for deployment planning. Automatic Deployment Rules (ADRs) automate the patching process by evaluating criteria such as update classification, product, and severity to create software update groups, download content to distribution points, and deploy to targeted collections on a recurring schedule, such as monthly for Patch Tuesday releases. This reduces administrative overhead while enforcing deadlines and maintenance windows to minimize disruptions.[40][41][42] Task sequences in Configuration Manager automate complex workflows, including operating system (OS) deployment and custom scripting, by sequencing steps like partitioning disks, applying images, and installing drivers or applications. For OS deployment, administrators create task sequences that capture user state, format drives, and deploy Windows images from distribution points, with options to customize via variables for site-specific configurations. Integration with Microsoft Deployment Toolkit (MDT) enhances these sequences through a wizard that adds advanced steps for application deployment, driver management, and post-install scripting, enabling zero-touch installations without user intervention. Custom scripts, such as PowerShell or VBScript, can be embedded to handle tasks like joining domains or configuring settings, making task sequences versatile for both initial setups and in-place upgrades.[43][44] To optimize bandwidth usage during distribution and patching, Configuration Manager leverages Delivery Optimization, a peer-to-peer protocol built into Windows 10 and later, which allows clients to share content directly with nearby devices on the same network or across subnets using Group IDs derived from boundary groups. This reduces internet or WAN traffic by sourcing up to 100% of content from peers when available, falling back to distribution points or Microsoft Update as needed. Cloud-based delivery further enhances efficiency by enabling global peering through the Delivery Optimization service, particularly for express installation files (deltas) in updates, minimizing download sizes and supporting throttled transfers during off-peak hours. Administrators configure these settings via client policies to balance performance and network load.[45]Inventory and Asset Management
Microsoft Configuration Manager's hardware inventory feature collects detailed information about the physical and logical components of managed client devices by querying Windows Management Instrumentation (WMI) classes and the Windows registry. This process captures data such as central processing unit (CPU) details including model and speed, random access memory (RAM) capacity and type, and disk storage information like size and free space on logical drives. The inventory runs on a configurable schedule, typically every seven days by default, and clients report the data to the site's management point, which then stores it in the Configuration Manager database for centralized access and analysis. Administrators can extend hardware inventory beyond the standard classes by modifying the configuration.mof file on the top-level site server, which defines the WMI queries used for data collection. This customization allows the inclusion of additional hardware attributes not covered in the default inventory, such as specific peripherals or custom device properties, by adding new WMI class references to the MOF file and ensuring the corresponding classes exist on client devices through software updates or extensions. After modification, the site rebuilds the policy, and clients incorporate the new queries in subsequent inventory cycles, enabling tailored asset tracking without altering core functionality. Software inventory in Configuration Manager focuses on identifying and cataloging files and applications on client devices through systematic file scanning and registry enumeration. The agent scans specified file types—defaulting to executable files (*.exe)—across local drives and reads registry keys to detect installed applications, capturing details like file versions, sizes, and paths. Configuration occurs via client settings, where administrators define inventory schedules, file types to include or exclude, and optional file collection rules to copy detected files to a network share for further analysis; subsequent scans report only changes (delta inventory) to optimize bandwidth. This data integrates into the site database, providing visibility into software deployments across the environment.[46] Asset Intelligence enhances inventory capabilities by synchronizing with Microsoft's online catalog to classify inventoried software and manage licensing compliance. Enabled through an Asset Intelligence synchronization point, the feature downloads updates over HTTPS (TCP port 443) on a scheduled or on-demand basis, applying predefined categories, families, and labels to over 300,000 software titles for standardized reporting. Administrators can import license agreements into the database to reconcile against usage data, generating reports on license compliance and overutilization; custom software titles may be uploaded to Microsoft for review and categorization.[47] The Asset Intelligence synchronization point and the ability to synchronize with Microsoft's online catalog have been deprecated since November 2021 and are no longer supported as of November 2022. However, the Asset Intelligence hardware inventory classes and reporting features using them remain supported. Collections in Configuration Manager serve as logical groupings of devices and users based on inventory data, facilitating targeted management tasks such as software deployments. Static collections require manual addition of members, maintaining fixed membership until explicitly updated, which suits stable groups like department-specific servers. In contrast, dynamic collections use query-based rules—drawing from hardware, software, or Active Directory attributes—to automatically populate and refresh membership on a schedule, often every five minutes with incremental updates, ideal for evolving sets like all devices with insufficient RAM. These collections enable precise targeting without referencing distribution mechanisms directly.Compliance and Endpoint Protection
Microsoft Endpoint Configuration Manager provides compliance settings to enforce desired configurations on managed devices, ensuring adherence to organizational policies through configuration baselines and items. Configuration baselines group one or more configuration items (CIs), which define specific settings and compliance rules for platforms like Windows and macOS. These CIs support checks for registry keys, file properties, and custom scripts to verify compliance, allowing administrators to assess whether devices meet predefined standards such as security configurations or software requirements. For instance, a CI might validate the presence of a specific registry value or the integrity of a critical file, reporting deviations as noncompliant.[48][49] Compliance settings enable remediation actions for noncompliant devices, where applicable rules can automatically correct issues, such as resetting a registry entry or running a script to enforce the desired state. Evaluation schedules determine how frequently clients assess baselines, with results reported back to the site server via state messages; by default, these evaluations occur on a configurable interval, such as daily, and can be customized in client settings to balance thoroughness with resource usage. Administrators monitor compliance through the Configuration Manager console's Monitoring workspace or built-in reports, identifying noncompliant assets for targeted remediation. This process integrates briefly with inventory data to contextualize compliance against collected device attributes.[48][50][51] Endpoint Protection in Configuration Manager integrates with Microsoft Defender Antivirus to deliver real-time protection against malware on managed Windows devices. This integration allows for the creation and deployment of antimalware policies that configure scan settings, real-time monitoring, and behavioral analysis to detect and block threats like viruses, spyware, and rootkits. Policies can be applied to device collections, enabling centralized management of features such as on-access scanning and network protection through the Windows Defender Firewall. Definition updates for Defender are handled via Configuration Manager's software update infrastructure or direct downloads from the Microsoft Malware Protection Center, ensuring timely protection across the hierarchy. Monitoring of Endpoint Protection status occurs in the console's Security node, providing dashboards for threat detections and policy adherence.[52][53] Role-based access control (RBAC) in Configuration Manager secures compliance and endpoint protection features by defining granular permissions through security roles, scopes, and collections. Built-in roles, such as the Compliance Settings Manager, grant permissions like Read, Create, and Modify for configuration baselines and antimalware policies, while custom roles can be tailored for specific tasks. Security scopes limit visibility and access to securable objects, such as baselines or endpoint protection points, allowing delegated administrators to manage only assigned resources without full hierarchy access. For example, an admin might be scoped to a particular collection of devices for compliance enforcement, promoting secure delegation in large environments. Auditing of RBAC assignments ensures accountability for changes to these security configurations.[54][55]Deployment and Configuration
System and Hardware Requirements
Microsoft Configuration Manager (ConfigMgr) requires specific hardware and software configurations for its site servers, database servers, clients, and supporting infrastructure to ensure reliable operation and scalability. Site servers, which host core ConfigMgr roles, demand robust resources, particularly when collocated with the site database. For a stand-alone primary site with a collocated SQL Server instance, Microsoft recommends a minimum of 16 CPU cores and 96 GB of RAM, with 80% of the RAM allocated to SQL Server for optimal performance. When the SQL Server is remote, the site server requirements decrease to 8 CPU cores and 16 GB of RAM. Disk space for the site server should start at 50 GB for applications and logs, scaling up to 200 GB for environments with 100,000 clients, while the database file (.mdf) requires approximately 75 GB per 25,000 clients, potentially reaching 2 TB for 700,000 clients.[56] The site database, hosted on SQL Server, is a critical component that influences overall system performance. Supported SQL Server versions include 2022 (Standard/Enterprise), 2019 (CU5 or later), 2017 (CU2 or higher), and 2016 (with required service packs and CUs), with Express edition suitable only for secondary sites. For remote SQL Server deployments on primary sites, recommendations include 16 CPU cores and 72-96 GB of RAM, with up to 90% allocated to SQL Server. In large hierarchies supporting over 50,000 devices, an Enterprise edition of SQL Server is required to handle the scale, as Standard edition limits capacity to 50,000 devices. Log files (.ldf) need about 25 GB per 25,000 clients. All site system servers must run on 64-bit operating systems.[57][56][37] Client devices must meet minimum software prerequisites to install and operate the ConfigMgr client. Supported client operating systems include Windows 11 (version 21H2 and later), Windows 10 (version 1607 and later), Windows Server 2025 (Standard, Datacenter, IoT editions since ConfigMgr version 2409), Windows Server 2022 (since version 2107), Windows Server 2019, and Windows Server 2016. The client requires Microsoft .NET Framework version 4.6.2 or later (4.8 recommended), along with at least 500 MB of free disk space; a 5 GB cache is recommended for content storage. For optional features like OS deployment, clients need an additional 384 MB of RAM. Hardware for the Configuration Manager console includes an Intel i3 or equivalent CPU, 2 GB of RAM, and 2 GB of disk space, with a minimum display resolution of 1024x768.[58][59][56] Network infrastructure must support secure and efficient communication for ConfigMgr operations, especially in hybrid or cloud-integrated environments. HTTPS communication is required for distribution points when using enhanced security features, and for cloud management gateway or co-management with Microsoft Intune. Bandwidth considerations are essential for content replication and client downloads; ConfigMgr provides throttling controls via BITS (Background Intelligent Transfer Service) to limit usage, but initial content distribution to distribution points can consume significant network resources, with recommendations to plan for at least 100 Mbps links between sites in large deployments. Internet access endpoints must be allowed through firewalls for features like software updates and cloud services.| Component | Minimum CPU | Minimum RAM | Disk Space Notes | Scaling for Large Sites (>100,000 Clients) |
|---|---|---|---|---|
| Site Server (Collocated SQL) | 16 cores | 96 GB (80% to SQL) | 50 GB app/logs; 75 GB/25k clients for DB | Up to 128 GB RAM for CAS; 2 TB DB |
| Remote SQL Server | 16 cores | 72-96 GB (90% to SQL) | 300 GB .mdf for 100k clients; 25 GB .ldf/25k clients | Enterprise SQL required; additional cores/RAM |
| Distribution Point | 2 cores | 8 GB | Varies by content (e.g., 500 GB+ for OS images) | Multiple DPs |
| Client | OS-dependent | OS + 384 MB (OS deploy) | 500 MB min; 5 GB cache recommended | N/A |
| Console | Intel i3 equivalent | 2 GB | 2 GB | N/A |
Installation Processes
Installing Microsoft Configuration Manager (ConfigMgr) requires completing several prerequisite steps to ensure compatibility and proper functionality across Active Directory, database, and update services. The Active Directory (AD) schema must be extended to support ConfigMgr's discovery and client communication features. This extension adds necessary objects and attributes to the AD forest, performed once per forest. To extend the schema, use an account that is a member of the Schema Admins group on the schema master domain controller. Runextadsch.exe from the SMSSETUP\BIN\X64 folder on the installation media; this tool automatically applies the schema changes. Alternatively, import the ConfigMgr_ad_schema.ldf file using ldifde -i -f ConfigMgr_ad_schema.ldf -v -j "%temp%" after editing the domain components in the file. Verify success by checking the extadsch.log file in the system drive root or the LDIFDE log in the temp directory. After extension, create the System Management container in each domain using ADSI Edit (adsiedit.msc), granting full control to the site server computer account.
SQL Server setup is another critical prerequisite, as ConfigMgr sites rely on a supported SQL instance to host the site database. Supported versions include SQL Server 2022 (Standard or Enterprise editions, compatibility level 150), SQL Server 2019 (CU5 or later), SQL Server 2017 (CU2 or higher), and SQL Server 2016 (with required service packs and CUs). Use a 64-bit instance with Windows authentication, SQL_Latin1_General_CP1_CI_AS collation, and features like Database Engine Services enabled. Install SQL Server on the site server or a remote dedicated server, configuring it with at least 8 GB RAM for central or primary sites (50-80% max memory allocation if co-located). Enable nested triggers, CLR integration, Service Broker, and set the database to TRUSTWORTHY. For secondary sites, SQL Server Express is acceptable and can be installed automatically by ConfigMgr. The ODBC driver for SQL Server must also be present as a prerequisite.
WSUS configuration is required for software updates integration and must precede the software update point role installation. Supported WSUS versions include those on Windows Server 2025 (with appropriate CUs, as of 2025), Windows Server 2022 (10.0.20348 with 2023-02 CU or later), Windows Server 2019 (10.0.17763 for ConfigMgr 1810+), and Windows Server 2016 (10.0.14393). Install WSUS via Server Manager on the site system server, selecting the role with the Windows Internal Database or a full SQL instance. Do not configure WSUS using its administration console; instead, ConfigMgr handles synchronization and classification settings post-installation. Ensure IIS is installed on the server hosting the software update point, and install the WSUS administration console on the site server if the update point is remote.
The site installation occurs through the ConfigMgr Setup Wizard, launched by running setup.exe from the SMSSETUP\BIN\X64 folder on the target server. For a central administration site (CAS) or primary site, the wizard begins with the Getting Started page to select the site type—new hierarchy for CAS or stand-alone/child for primary—and optionally a typical installation for simplified setup. Subsequent pages include entering the product key (evaluation or licensed), accepting license terms, downloading prerequisites, and selecting languages for server and client consoles. On the Site and Installation Settings page, specify a unique three-character site code, descriptive site name, and installation path. The Site Installation page confirms hierarchy details, such as joining an existing CAS via FQDN.
Database creation is configured during the Database Information page, where the SQL Server FQDN (and port if non-default), instance name, database name (default: CM_<SiteCode>), and Service Broker port (default: 4022) are specified. Customize data and log file paths if needed, ensuring sufficient disk space. The SMS Provider Settings page designates the server hosting the provider (default: site server FQDN). For primary sites, the Client Communication Settings page configures HTTPS or Enhanced HTTP, followed by the Site System Roles page to install initial roles like management point and distribution point, specifying their FQDNs and communication protocols. The wizard concludes with a settings summary, prerequisite checks (resolving any failures), and the installation progress, where the site database is created and roles assigned in the background.
The Configuration Manager console can be installed separately on administrative workstations for remote management. Prerequisites include Microsoft .NET Framework 4.8 (required since version 2403). Run ConsoleSetup.exe from the site server's \Tools\ConsoleSetup folder or the installation media's \SMSSETUP\BIN\I386 path. In the wizard, enter the site server's FQDN and choose the installation directory, then proceed to install. For silent deployment, use the command line: ConsoleSetup.exe /q TargetDir=<Path> DefaultSiteServerName=<FQDN>. The console connects to the site upon launch, providing read-write access for configuration.
Post-installation verification involves testing client push installation and configuring boundaries to ensure proper client discovery and management. Enable client push in the console under Administration > Site Configuration > Sites > Properties > Client Installation Settings, specifying the installation properties and accounts with local admin rights on target devices. Test push installation on a sample client by right-clicking the device in the Assets and Compliance workspace and selecting Install Client, monitoring the CCM.log on the site server for success (e.g., no access denied errors) and the client's ccmsetup.log for completion. Configure boundaries under Administration > Hierarchy Configuration > Boundaries, defining IP subnets, AD sites, or ranges that match your network topology, then assign them to boundary groups for site assignment and content access. Verify boundary functionality by checking client site assignment in the console's device properties and ensuring discovery methods like AD System Discovery populate resources correctly.
Initial Configuration and Best Practices
After completing the installation of Microsoft Configuration Manager (Configuration Manager), initial configuration involves setting up discovery methods to populate the site with client devices and users. Active Directory System Discovery identifies computer resources by querying specified containers in Active Directory Domain Services (AD DS). To configure it, navigate to the Administration workspace in the Configuration Manager console, expand Hierarchy Configuration, select Discovery Methods, and choose Active Directory System Discovery. In its properties, specify LDAP paths to AD containers (e.g.,LDAP://CN=Computers,DC=contoso,DC=com), enable recursive search of child containers if needed, and assign an Active Directory discovery account with read permissions. Set a polling schedule, such as full discovery weekly and delta discovery daily, to balance data freshness with network load. Similarly, Active Directory User Discovery locates user accounts for tasks like software deployment targeting; configure it by defining AD container locations, using the same discovery account, and establishing a polling schedule. These methods ensure comprehensive client population without manual intervention, though excluding unnecessary subcontainers (available since version 2203) refines results and reduces overhead.
Site maintenance tasks are essential for ongoing reliability post-initial setup. The default Backup Site Server task safeguards the site database and configuration for disaster recovery; Microsoft recommends scheduling it at least every five days to align with SQL Server transaction log retention, adjustable based on environment size and change frequency. Enable and review all predefined tasks via the console under Administration > Site Configuration > Sites > Properties > Maintenance Tasks tab, including Delete Aged Status Messages (to clear old data weekly) and Rebuild Indexes (monthly for database optimization). Log monitoring supports proactive maintenance; examine smsexec.log on the site server daily for component thread processing and errors, as it records all site executive activities. Complement this with sitecomp.log for site component maintenance, sitestat.log for system availability and disk space, and compmon.log for thread status—all located in the site's Logs folder—to detect issues like service failures early.[60]
Best practices emphasize security, efficiency, and scalability from the outset. For secure client communication, configure HTTPS using public key infrastructure (PKI) certificates on management points and distribution points if a certificate authority is available, as it encrypts all site system interactions; alternatively, enable enhanced HTTP (self-signed certificates generated by Configuration Manager) for non-PKI environments, which secures key endpoints without additional infrastructure since version 2103, when plain HTTP became deprecated. Access this in site properties under the Communication Security tab. Boundary optimization prevents performance bottlenecks by defining network locations (e.g., IP subnets or AD sites) accurately; create boundaries in the console under Administration > Hierarchy Configuration > Boundaries, then group them logically in Boundary Groups to associate clients with site systems like distribution points—use the fewest boundaries possible, avoid overlaps for site assignment, and enable fallback to neighboring groups for content access. For scalability in environments with 10,000+ clients, provision site servers with at least 12 CPU cores, 64 GB RAM, and 5,000 SQL IOPS on SSD storage (e.g., RAID 10 configuration); limit hardware inventory to weekly cycles with minimal attributes, schedule collection updates off-peak, and test I/O performance using tools like Diskspd to ensure handling of large inventories without latency.
Troubleshooting basics address common post-configuration pitfalls. Site reset restores site components without altering settings, useful after account changes, OS upgrades, or corruption; run it via setup.exe from the Configuration Manager bin folder, selecting "Perform site maintenance or reset this site" and "Reset site with no configuration changes"—this restarts services, recreates shares, and reinstalls components, requiring local admin rights but not supported on secondary sites. For replication issues between sites, monitor incoming/outgoing queues in the console under Monitoring > Database Replication; common causes include stopped SMS Executive service, disk space shortages, or SQL throttling—use the Replication Link Analyzer tool to diagnose connectivity and permissions, or run SPDiagDRS in SQL Server Management Studio for detailed error analysis in RCMCtrl.log. Address backlogs by increasing sender threads or removing rate limits if bulk copy processes lag.[61]