Category filter
Designing Infrastructure: Modern SCCM System Requirements and UEM Integration
Technical Summary
Deploying Microsoft Configuration Manager (formerly System Center Configuration Manager, or SCCM) alongside third-party patching integrations and modern Unified Endpoint Management (UEM) solutions like Hexnode requires strict alignment across your core server compute, database allocation, and disk IOPS.
This guide details the definitive hardware sizing baselines required for a modern Configuration Manager (Current Branch) deployment, maps the core site system roles, and explains exactly how to bridge your legacy on-premises management with cloud-native capabilities using Hexnode UEM’s native SCCM and WSUS integrations.
1. Primary Site Server and Database Sizing Guidelines
Configuration Manager infrastructure operates on a bottom-up data aggregation model. Client devices stream hardware inventory, discovery records, and state messages up to Management Points, which directly load the underlying SQL Server database.
A. Co-located Site Servers (Site Server & Database on One Machine)
This configuration is recommended for small-to-medium enterprise boundaries where network latency between the site processor and the database must be eliminated.
| Managed Device Scale | CPU (Cores) | Memory | Recommended SQL Memory Allocation |
|---|---|---|---|
| Lab / Proof-of-Concept | 2 – 4 | 8 – 12 GB | Default Windows Handling |
| Up to 25,000 Clients | 6 | 24 GB | 65% of Available System Memory |
| 25,000 to 50,000 Clients | 8 | 32 GB | 70% of Available System Memory |
| 50,000 to 100,000 Clients | 12 | 64 GB | 70% of Available System Memory |
| 100,000 to 150,000 Clients | 16 | 96 GB | 80% of Available System Memory |
Note: For the top-tier 150,000 client deployment, allocating 80% to SQL is strictly required to prevent database thread starvation during peak evaluation cycles.
B. Decoupled Site Servers (Remote Database Server Topology)
For high-scale infrastructures up to the maximum standalone limit (150,000 total clients), splitting the computation engines prevents resource exhaustion.
- Primary Site Server (App Layer only): Requires a baseline of 8 Cores and 16 GB of RAM, regardless of target client volume, as intensive query tracking is deferred to the remote host.
-
Remote Database Server (SQL Layer only):
Managed Device Scale Database CPU Database Memory Recommended SQL Memory Allocation Up to 25,000 Clients 4 Cores 16 GB 70% of Available System Memory 25,000 to 50,000 Clients 8 Cores 24 GB 70% of Available System Memory 50,000 to 100,000 Clients 12 Cores 48 GB 80% of Available System Memory 100,000 to 150,000 Clients 16 Cores 72 GB 90% of Available System Memory
2. Remote Site System Roles Matrix
To balance network payloads across WAN links, sub-roles must be distributed to secondary server footprints. These remote instances require dedicated computing reserves:
- Management Point (MP): 4 Cores, 8 GB RAM, 50 GB disk space. (Supports up to 25,000 active endpoints per instance).
- Software Update Point (SUP / WSUS integration): 8 Cores, 16 GB RAM. Storage scales relative to the volume of metadata catalogs synchronized (Microsoft + Third-Party extensions).
- Distribution Point (DP): 2 Cores, 8 GB RAM. Storage footprint dictates package load volume.
3. Hexnode UEM Integration Capabilities
Migrating devices or establishing a co-managed state between legacy SCCM infrastructure and Hexnode UEM relies on native, purpose-built integrations rather than standard MSI deployments. Furthermore, Hexnode is designed to absorb and enhance your existing WSUS update architecture.
A. Native SCCM Integration via the Hexnode Agent
To seamlessly migrate PCs from an SCCM server to the Hexnode console, Hexnode provides a dedicated server-side application.
- The Server Handshake: Administrators must download and install the Hexnode SCCM Agent app directly onto the SCCM server.
- Site Code Mapping: During the setup wizard, you must provide the SCCM server’s specific three-character alphanumeric Site Code alongside your Hexnode Portal Name. This establishes the API trust between your on-premises server and the Hexnode cloud environment.
- Deployment Execution: Once integrated, the application is packaged as a Windows MSI file in UNC path format and deployed to specific user Collections directly through the SCCM Software Library.
B. Unified Patch Management & Native WSUS Integration
Adopting Hexnode UEM does not require you to dismantle your existing on-premises WSUS infrastructure. Hexnode PC Management features dedicated WSUS Specific Settings within its patching policies.
- WSUS Redirection: IT admins can use Hexnode to push policies that redirect the Windows Update Agent to an internal WSUS server using a specific Update Service URL (typically over port 8530 or 8531).
- Granular Control: You can configure Alternate Update Service URLs, Update Detection Frequencies, and mandate certificate-pinning for WSUS communications natively through the Hexnode portal.
- Third-Party Patching: For third-party applications, you can continue using WSUS plugins, or transition to Hexnode’s automated Winget integration, allowing the silent patching of applications like Zoom, Chrome, and Adobe directly from the cloud.
4. Third-Party Patching Extension Prerequisites
If you maintain on-premises third-party patching through WSUS, the plugin relies on a dedicated background proxy service to stage non-Microsoft binaries.
Base Plugin Machine Requirements:
- Processor Engine: Intel Core i3 (2 Cores/4 Threads) running at 2.0 GHz with 3 MB Cache minimum.
- Memory Architecture: 2 GB RAM minimum.
- Disk Overhead Allocation: 10 GB minimum available space to stage application binaries.
- Operating System Target: 64-bit architecture running Windows Server 2012 up to 2022.
Critical Dependencies:
- WSUS Version Alignment: The proxy machine must host a local WSUS Console matching the primary WSUS server. It must be at least Version 3.0 SP2 with hotfix KB2720211.
- Access Entitlements: The Service Account requires SMS Admins group membership and Full Administrator permissions inside the SCCM console.
5. Storage Architecture and IOPS Tuning
Selecting the correct storage tier is critical. Disk drives can bottleneck entire deployments if the processing queues (inboxes) cannot handle active file transfers.
- Site Server Inboxes: Always format volumes using NTFS with a 4 KB or 8 KB Allocation Unit Size. Resorting to ReFS forces a large 64 KB block layout that exhausts disk throughput when handling SCCM’s millions of tiny text-based tracking files.
- SQL Database Components (.MDF & .LDF): Always format these specific volumes using ReFS with a 64 KB Allocation Unit Size. This allows large database tables to map directly onto contiguous hardware sectors, drastically accelerating disk indexing speeds.
IOPS Scalability Targets:
- 25,000 Clients: 600 IOPS for inboxes / 1,700 IOPS for SQL tracks.
- 50,000 Clients: 1,200 IOPS for inboxes / 2,800 IOPS for SQL tracks.
- 100,000 Clients: 1,200 IOPS for inboxes / 5,000 IOPS for SQL tracks.
6. Troubleshooting Hardware & Synchronization Bottlenecks
Case 1: 100% CPU Spike During Software Update Synchronization
The Symptom: During catalog refreshes, the site server’s CPU utilization pegs at 100%, causing the console to freeze.
Remediation via IIS Application Pool Tuning:
By default, WSUS application pool memory limits are capped too low. Tune your local WSUS IIS parameters to prevent thread locks:
- Open Internet Information Services (IIS) Manager on your SUP server.
- Expand the server node and click on Application Pools.
- Right-click on WsusPool and select Advanced Settings.
- Locate Private Memory Limit (KB) and increase it based on system RAM (e.g., 4194304 for 4 GB, or 8388608 for 8 GB).
- Open an administrative command prompt and reset IIS using the following:
|
1 |
iisreset /noforce |
Case 2: Tracking Component Sync Failures in Log Files
Administrators can isolate performance failures using these two central log paths in the <ConfigMgr_Install_Directory>\Logs\ folder:
- wsusctrl.log: Verify SUP communication with local WSUS system APIs. Look for HTTP 503 errors pointing to memory allocation issues.
- Wsyncmgr.log: Documents metadata transformation cycles. Disk I/O constraints or SQL timeouts will record validation error blocks here in real time.
