SCCM / MECM

Complex OS deployment (OSD)

Task sequences in ConfigMgr support multi-phase deployments with driver injection, WIM capture, MDT integration, pre-staging content, and conditional steps based on hardware model or disk configuration. For large fleets with diverse hardware and complex imaging requirements, ConfigMgr OSD is significantly more flexible than Autopilot alone.

Large-scale software distribution

The ConfigMgr content library and distribution point infrastructure supports distributing large application packages (multi-GB installers, SQL, Visual Studio) across thousands of machines with bandwidth throttling, scheduled distribution windows, and BranchCache for branch office scenarios — without each device pulling from the cloud.

WSUS-integrated patch management

ConfigMgr Software Update Point integrates directly with WSUS for per-KB approval, ADR (Automatic Deployment Rules) for monthly Patch Tuesday automation, and phased deployment for update rings. The reporting and maintenance window integration is more granular than Intune update rings for environments with complex patching requirements.

On-premises compliance and reporting

Configuration baseline assessment in ConfigMgr evaluates device compliance against custom rules and reports results to SSRS (SQL Server Reporting Services). For environments where cloud reporting is not permitted or where compliance data must stay on-premises, ConfigMgr provides a full reporting stack without data leaving the datacenter.

Server management

ConfigMgr manages Windows Server endpoints — software distribution, patch management, hardware inventory, and software metering — alongside workstation fleets. Intune does not manage on-premises servers. For environments needing a unified management view across workstations and servers, ConfigMgr remains the only Microsoft-native option.

Co-management and migration staging

Co-management lets ConfigMgr and Intune share management authority simultaneously, with each workload explicitly assigned to one or the other. This makes ConfigMgr the practical bridge for organisations migrating to cloud-only management — you can slide workloads to Intune incrementally without a hard cutover.

Device vs User collections

Device collections target the machine — useful for OS-level deployments, patches, and configuration items that should apply regardless of who is logged on. User collections target the user object in AD — useful for application deployments that should follow the user across devices. Most patch deployments use device collections for predictable scheduling behaviour.

Query-based vs direct membership

Query-based collections use WQL queries against the ConfigMgr database to dynamically include devices matching criteria (OS version, installed software, last logon, hardware attributes). Direct membership adds specific devices explicitly. Hybrid: use a query rule as the base and direct membership for exceptions. Always test queries in the collection simulator before creating a production collection.

Limiting collections

Every collection must be limited by a parent collection. The limiting collection defines the maximum scope — a collection cannot include a device not in its limiting collection. Use "All Systems" as the limiting collection only at the top of the hierarchy. Create intermediate limiting collections per site, per department, or per management group to prevent accidental over-targeting.

Deployment purpose: Required vs Available

Required deployments install automatically at the deadline — the client enforces installation regardless of user activity (within maintenance window rules). Available deployments appear in Software Center for user-initiated install. For patches and security software, use Required. For productivity apps with user adoption considerations, Available is appropriate. Never use Required for software that needs user data migration.

Maintenance windows

Maintenance windows define when ConfigMgr is permitted to make changes to a device — install software, apply patches, or reboot. Without a maintenance window, deployments can run at any time. Configure non-overlapping windows for servers (weekend nights), shift workers (daytime), and office desktops (business hours + weekend). Software updates and all deployments have separate maintenance window overrides.

Phased deployments

ConfigMgr phased deployments automate multi-collection rollouts — starting with a pilot collection and automatically advancing to the production collection when the pilot success criteria are met (e.g., 95% deployment success rate with zero failure threshold). Use for major application updates and feature update deployments to reduce manual monitoring.

Boot image and WinPE

Task sequences boot devices into Windows PE via PXE (via Distribution Point with PXE role) or bootable media. The boot image contains ConfigMgr client components, network drivers, and storage drivers needed to reach the distribution point. Customise boot images via the Windows ADK — add drivers for network adapters on new hardware before the boot image can reach SCCM content.

Driver management

ConfigMgr driver management imports driver packages into the driver catalogue, matched to hardware models via the Auto Apply Drivers step or explicit Apply Driver Package steps. The best practice for large fleets is model-based driver packages — one package per hardware model family — applied via a task sequence condition checking %Model% or Win32_ComputerSystem.Model.

MDT integration (Zero Touch Installation)

Microsoft Deployment Toolkit integration with ConfigMgr (ConfigMgr + MDT) adds the Use Toolkit Package and Gather steps, enabling MDT rules, the CustomSettings.ini variable engine, and offline domain join. MDT integration is the standard approach for environments that need complex conditional logic beyond what native task sequence conditions support.

In-place upgrade task sequences

The Upgrade Operating System step runs Windows Setup in an upgrade scenario, preserving user data, installed apps, and settings. In-place upgrade task sequences are lower-risk than wipe-and-reload OSD for feature update migrations (Windows 10 to Windows 11). Add pre-check steps to fail the task sequence early if the device does not meet hardware requirements.

Content pre-staging and BranchCache

For branch offices without a local distribution point, pre-stage content to a local server or enable BranchCache to allow devices to pull content from each other after the first download. Without pre-staging, large task sequences pull from a remote DP over WAN — causing slow deployments and potential deployment failures during the WIM apply phase.

Task sequence variables and conditions

Built-in variables (_SMSTSMachineName, OSDComputerName, SMSTSUserStatePath) and custom variables set via Set Task Sequence Variable steps control flow. Condition checks on steps (WMI query, file existence, task sequence variable match) allow hardware-specific or environment-specific branching without maintaining separate task sequences per scenario.

Software Update Point (SUP) role

The SUP role installs and manages WSUS on the site server. It synchronises update metadata from Microsoft Update on a configurable schedule and downloads updates to the content library. WSUS still manages the approval database — ConfigMgr controls which updates are deployed to which collections, using WSUS approvals as the delivery mechanism.

Automatic Deployment Rules (ADRs)

ADRs automate monthly Patch Tuesday deployments. Configure an ADR to run on the second Tuesday of each month, filter by classification (Security Updates, Critical Updates), and deploy to a pilot collection with a 7-day deadline. A second ADR phase targets the broad production collection two weeks later. ADRs create deployment packages and software update groups automatically.

Software update groups

A software update group is a container of specific KBs targeted for deployment. ADRs add updates to a group automatically. Manual update groups are used for out-of-band patches (zero-day fixes between Patch Tuesdays). A single update group can be deployed to multiple collections with different maintenance windows and deadline offsets.

Deployment rings via collections

Create separate device collections for each ring (Pilot, IT, Early Adopter, Production). Deploy the same software update group to each collection with staggered deadlines — Pilot: 0 days, IT: 7 days, Early Adopter: 14 days, Production: 21 days. ConfigMgr compliance reports show deployment progress per collection, per update.

WSUS cleanup and maintenance

WSUS databases grow significantly without regular maintenance. Declined and superseded updates accumulate in the WSUS catalogue. Run the built-in WSUS Cleanup Wizard monthly, or use the WSUS maintenance tasks in ConfigMgr site maintenance. A WSUS database over 10GB often causes synchronisation timeouts — run the WSUS database maintenance script against the SUSDB to re-index and defragment.

Conflict with Intune update rings on co-managed devices

If Windows Update policies workload remains with ConfigMgr, Intune update ring policies are ignored on co-managed devices. If it is slid to Intune, ConfigMgr SUP policies are ignored. Running both simultaneously causes unpredictable behaviour — devices may defer updates based on ConfigMgr policy then receive them from the Windows Update cloud service via Intune, bypassing the ConfigMgr ring structure.

CCMSetup and client installation logs

CCMSetup.log (on the device, at C:\Windows\ccmsetup\Logs\) records the installation process. ccmsetup.exe failures are usually network (DP unreachable), prerequisite (missing .NET or VC++ runtime), or permissions issues. On the site server, client.msi.log records MSI installation detail. Use the Client Push Installation status in the console to identify devices where push installation failed and why.

Key client log files

C:\Windows\CCM\Logs\ contains all operational client logs. The most useful: LocationServices.log (DP and MP discovery), CcmMessaging.log (communication with MP), PolicyAgent.log (policy download and application), UpdatesDeployment.log (software update installation), AppDiscovery.log (application detection), and ExecMgr.log (program execution). CMTrace.exe (bundled with ConfigMgr) is the recommended viewer.

Client health check triggers

The ConfigMgr Client Health evaluation (CCMEval) runs daily and checks: WMI repository integrity, SMS Agent Host service state, Configuration Manager bits, client version currency, and hardware inventory cycle recency. If CCMEval detects a problem it attempts auto-remediation. Results appear in the Client Health dashboard under Monitoring > Client Health.

WMI repository corruption

A corrupt WMI repository is one of the most common causes of ConfigMgr client failure — inventory stops reporting, policies do not apply, and CCMEval flags the device. Repair with winmgmt /salvagerepository followed by a client reinstallation if salvage does not resolve. CCMEval auto-remediation handles this in most cases without manual intervention.

Management Point communication

If a client cannot reach the management point, it cannot download policies, report inventory, or receive deployments. Test MP reachability from the client with: Test-NetConnection -ComputerName <MP FQDN> -Port 80 (or 443 for HTTPS). Check LocationServices.log for MP detection failures. Common causes: DNS resolution failure, firewall blocking port 80/443, or the client boundary not being assigned to a boundary group containing the MP.

CMTrace vs OneTrace

CMTrace.exe is the classic ConfigMgr log viewer bundled since SCCM 2012. OneTrace is the successor, integrated into Support Center (installed via the ConfigMgr toolkit). OneTrace supports multiple log tabs, advanced filtering, and merged log views — useful when correlating events across UpdatesDeployment.log, WUAHandler.log, and RebootCoordinator.log simultaneously.