Written by the Infronest Security Research Team. Product behaviour described here follows Microsoft Learn documentation for Configuration Manager current branch; the operational guidance reflects patch cycles we run on live Windows and Linux fleets.
Security & Compliance
SCCM Patch Management: How It Works and When to Use It
How Microsoft Configuration Manager patches Windows — software update points, update groups, deployment packages, maintenance windows and Automatic Deployment Rules — and an honest look at when a lighter cloud agent is the better fit.
Most organisations with a large Windows estate patch through Microsoft Configuration Manager — the product almost everyone still calls SCCM. Done well, it gives you precise targeting, bandwidth control and defensible compliance evidence. Done badly, it produces a dashboard that reads "68% compliant" for three months running while nobody can explain why. This guide covers how software update management actually works inside Configuration Manager, the rules that automate the monthly cycle, the failures that catch every admin at least once, and where a lighter tool genuinely fits better. The stakes are ordinary but expensive: IBM's Cost of a Data Breach Report 2025 puts the global average breach at USD 4.44 million, and unpatched software remains one of the cheapest routes in.
Definition
What is SCCM patch management?
SCCM patch management is the use of Microsoft Configuration Manager to scan Windows devices for missing updates, group those updates, distribute the content to local servers and install it on a schedule you control. Inside the product the feature is called software update management, and it runs on a Windows Server Update Services (WSUS) instance that Configuration Manager drives through a site system role called the software update point. WSUS supplies the update catalogue and metadata; Configuration Manager owns everything you care about operationally — targeting, timing, deadlines, reboots and reporting.
The naming has changed three times and it is worth getting right. System Center Configuration Manager (SCCM) was renamed Microsoft Endpoint Configuration Manager at version 1910 in late 2019, under the short-lived Microsoft Endpoint Manager brand. Microsoft retired that brand in 2022; the product is now simply Microsoft Configuration Manager, part of the Microsoft Intune family. It ships as current branch releases named by year and month — 2403, 2409, 2503 — with each release supported for 18 months. Practically everyone still says SCCM, and so do most job adverts, which is why this article does too.
One planning note before you build anything new on it: Microsoft announced in September 2024 that WSUS is deprecated. It still ships with Windows Server 2025 and remains supported, but no new features are planned, and Microsoft has announced the retirement of driver synchronisation through WSUS in favour of Windows Update for Business and Intune driver management. The Configuration Manager software update point still depends on WSUS today, so this affects your three-year roadmap rather than next month's patch cycle.
Mechanics
How software update management works, component by component
Every SCCM patch problem is easier to diagnose if you can name the stage it broke at. The pipeline runs from catalogue synchronisation, through client scanning, into grouping, content distribution and finally a scheduled install inside a maintenance window.
- Software update point (SUP) — the site system role installed on a server running WSUS. Once the SUP exists, you configure products and classifications in the SUP component properties, never in the WSUS console. Editing WSUS directly is one of the fastest ways to break the hierarchy.
- Synchronisation — the SUP pulls update metadata from Microsoft Update (or from an upstream SUP) on a schedule. The default is every seven days; most teams run it daily, or on a schedule offset from the second Tuesday of the month so the new catalogue is present when the monthly rule fires.
- Client scan — the Configuration Manager client hands a scan to the Windows Update Agent, which evaluates the device against the SUP catalogue and returns compliance state. The Software Updates Scan Schedule client setting also defaults to seven days, which is the single most common reason compliance dashboards look stale.
- Software update groups (SUGs) — the logical bundle you deploy and report against. A single software update deployment supports a maximum of 1,000 updates, so the standard pattern is a new SUG per month plus one rolled-up baseline group that you prune as updates expire.
- Deployment packages — the actual binaries, downloaded once to a source share and distributed to distribution points. Clients pull content from a distribution point in their boundary group, or fall back to downloading directly from Microsoft Update if you enable that option for devices with no reachable DP.
- Deployments — Available deployments appear in Software Center for the user to start; Required deployments install by a deadline. The user experience settings attached to the deployment (restart suppression, deadline behaviour, whether users can postpone) determine what actually happens on the day.
- Maintenance windows — set per device collection, and the hard boundary for required installs. Configuration Manager compares each update's configured maximum run time against the time remaining in the window; if it does not fit, nothing installs and no error is obvious from the console.
Automation
Automatic Deployment Rules: the part that saves the time
An Automatic Deployment Rule (ADR) is the monthly cycle expressed as configuration. On a schedule you define, the rule evaluates a filter — product, classification, date released or revised, superseded equals No, required count greater than zero — adds every matching update to a software update group, downloads the content into a deployment package, distributes it, and creates a deployment against a collection with your chosen deadline and user-experience settings. Without ADRs you are hand-building the same four objects every month; with them, the monthly work becomes reviewing what the rule produced.
A workable baseline is two kinds of rule. First, a definitions rule for Microsoft Defender updates: run daily, add to an existing update group rather than creating a new one (definitions churn far too fast for monthly groups), deploy as required with an immediate deadline and no restart. Second, one rule per deployment ring for the Patch Tuesday cycle, scheduled a day or two after the second Tuesday so synchronisation has completed and superseded updates are correctly filtered out. Ring rules should create a new software update group each run, so the month's scope is a single reportable object.
For staged rollouts, Configuration Manager has a built-in phased deployment feature: you can create a phased deployment from a software update group or from an ADR that promotes to the next collection automatically after a success percentage and a deferral period. It is genuinely useful, but it does not clean up after itself. An ADR that creates a new group every month and never expires the old ones will quietly bloat the WSUS database and the console, so pair it with supersedence expiry rules and scheduled WSUS maintenance from day one.
Rollout
A deployment ring model that survives contact with production
Rings exist so that a bad update damages twenty devices rather than two thousand, and so that you have a defensible answer when someone asks why patching takes ten days. With over 11,000 CVEs published by March 2026, the argument for long soak periods gets weaker every year — keep the rings tight and the deadlines real.
- Ring 0 — IT pilot, 5 to 20 devices including the service desk. Deploy on release day, deadline plus one day, no maintenance window. If it breaks here, it breaks in front of people who can describe the failure properly.
- Ring 1 — broad pilot, roughly 5 to 10 percent of workstations, deliberately spread across departments, hardware models and hardware ages. Deadline plus three days. This is the ring that catches driver and vendor-software conflicts, which a single-model IT pilot never will.
- Ring 2 — general workstation population. Deadline plus seven to ten days, installs outside business hours, restart notification with a bounded postponement rather than an open-ended one.
- Ring 3 — servers, split into collections by application tier and patched inside their maintenance windows. Cluster nodes belong in separate collections with staggered windows (node A Saturday, node B Sunday) so ordering is enforced by schedule rather than hope.
- Exceptions collection — a documented, time-limited collection for devices that genuinely cannot patch on the standard schedule, each with a named owner and a review date. Review it monthly; an exceptions collection that only grows is a compliance finding waiting to happen.
- A compliance gate — define done as a percentage compliant against the current software update group by a specific day, and report on the group rather than on individual KB numbers. Per-KB reporting is unreadable above a few hundred devices.
Troubleshooting
Eight problems every SCCM patch admin hits
- Compliance data looks stale — both the software updates scan schedule and the deployment re-evaluation schedule default to seven days. Shorten them in client settings before you conclude that patches are not installing; often they installed days ago and nothing has reported it.
- The WsusPool application pool keeps recycling — the IIS private memory limit for the WSUS pool defaults to roughly 1.8 GB, which a busy environment exceeds daily. Clients then fail scans with 0x80244022 (service unavailable). Raise the limit substantially or set it to unlimited on a server sized for it.
- The WSUS database bloats — usually caused by selecting far too many products and classifications during setup. Trim the selection, then use the WSUS Maintenance options on the software update point (decline expired updates by supersedence rules, add non-clustered indexes, remove obsolete updates) and set a supersedence expiry period so old updates leave the catalogue.
- Maintenance windows too short — the classic silent no-op. Cumulative updates carry a long maximum run time, and if the remaining window cannot accommodate it the client simply does nothing. Widen the window, or reduce the update's maximum run time to a value you have actually measured.
- Roaming and VPN-only laptops never comply — they cannot reach a distribution point, so content never arrives and state messages never return. The supported answers are a Cloud Management Gateway (Azure cost and design work), enabling the fallback to download content directly from Microsoft Update, or Delivery Optimization and peer cache where devices do cluster together.
- Third-party applications go unpatched — Configuration Manager natively patches Microsoft products only. Chrome, Zoom, Adobe Reader, Java and the rest require the Third-Party Software Update Catalogs feature with a partner catalogue subscription (mostly paid), a WSUS signing certificate, and the client policy that allows signed content from the intranet update service location.
- Content distribution chokes thin WAN links — large monthly packages replicated to every branch. Use pull distribution points, BranchCache or peer cache, and boundary group fallback ordering so a branch tries its local DP first and a regional one second.
- Devices sit in pending-restart limbo — installed but not counted compliant, sometimes for weeks on machines nobody reboots. Deadline behaviour and restart suppression settings decide this, not the update itself; servers with restart suppression enabled will accumulate indefinitely unless a reboot is scheduled separately.
Honest assessment
When SCCM is the right tool — and when it is not
Configuration Manager is the right choice for a large, mostly Windows, mostly domain-joined estate — particularly one with on-premises servers and offices where local distribution points save real bandwidth. It is also the right choice when patching is only part of the job: OS deployment and imaging, application packaging, configuration baselines, hardware and software inventory, and collection targeting of a granularity nothing else matches. If you already have use rights through Microsoft 365 E3/E5 or Intune Plan 1 licensing (check your own agreement) and an engineer who knows the product, replacing a healthy hierarchy purely to change how you patch is rarely worth it.
It is the wrong choice in three recognisable situations. First, a genuinely remote workforce: you can solve this with a Cloud Management Gateway, but that is Azure spend plus certificate and identity design work, and it is a lot of machinery to reach 90 laptops. Second, a mixed estate: Configuration Manager's Linux and UNIX client support was retired and macOS management moved to Intune, so a Windows-only patch engine leaves the rest of your fleet unmanaged. Third, a small team: SCCM assumes a site server, SQL Server, distribution points and somebody comfortable reading wsyncmgr.log, WSUSCtrl.log and UpdatesDeployment.log at two in the morning. Without that person, the platform degrades quietly and you find out during an audit.
The honest middle ground is worth stating plainly. For Windows-only cloud-first estates, Microsoft's own direction is Intune with Windows Update for Business and Windows Autopatch, and co-management lets you move the Windows Update policies workload to Intune while Configuration Manager keeps application deployment and OSD. A lightweight cloud-managed agent makes sense when devices are internet-first, the estate spans Windows and Linux, and you want patch state to live alongside your asset register and tickets rather than in a separate console. It does not make sense as a replacement for a working ConfigMgr hierarchy managing thousands of Windows endpoints — those are different problems.
Infronest
Conclusion
Infronest's Patch Management module scans Windows and Linux endpoints for missing patches, deploys in rings on a schedule and reports compliance, using one lightweight agent that does not need a site server, SQL Server or distribution points. Because it sits in the same tenant-isolated workspace as IT assets, MDM device management, RMM, helpdesk and the Security & VAPT module, a CVSS-scored finding from an assessment can be tracked through to a deployed patch and verified closure without moving between consoles or spreadsheets.
We will be straight about the boundary: Infronest does not replace Configuration Manager's OS deployment, application packaging or Windows-specific configuration baselines, and it is not the tool for an air-gapped 10,000-seat Windows hierarchy that already works. It is a good fit for remote-first and mixed Windows/Linux estates, for teams without a dedicated SCCM specialist, and for organisations that want patch compliance evidence in the same place as their assets and tickets. Start a 14-day free trial at infronest.com — no credit card required.
Infronest Technologies Pvt. Ltd. is based in Gurugram, India, and ships 16 modules in one workspace.
References
Sources and further reading
- Microsoft Learn — Configuration Manager current branch, software update management: software update point, synchronisation, update groups, deployment packages and maintenance windows.
- Microsoft Learn — Automatic deployment rules and phased deployments for software updates in Configuration Manager.
- Microsoft Windows Server blog, September 2024 — announcement that Windows Server Update Services (WSUS) is deprecated, with WSUS still shipping and supported in Windows Server 2025.
- Microsoft Learn — co-management workloads, including moving the Windows Update policies workload from Configuration Manager to Microsoft Intune.
- IBM, Cost of a Data Breach Report 2025 — USD 4.44 million global average cost of a data breach.
- CVE Program published vulnerability counts — over 11,000 CVEs published by March 2026.
Frequently Asked Questions
- Is SCCM still called SCCM in 2026?
- Officially no. System Center Configuration Manager became Microsoft Endpoint Configuration Manager at version 1910 in late 2019, and since Microsoft retired the Endpoint Manager brand in 2022 the product has been called Microsoft Configuration Manager, part of the Microsoft Intune family. In practice, engineers, job adverts and vendor documentation still use SCCM, and current branch releases are still identified by year and month, such as 2503.
- Does SCCM patch third-party applications like Chrome, Zoom and Adobe Reader?
- Not on its own. Configuration Manager natively patches Microsoft products through the software update point. For other vendors you need the Third-Party Software Update Catalogs feature, which requires a partner catalogue subscription (most are paid), a WSUS signing certificate, and a client policy allowing signed content from the intranet update service location. Many teams add a dedicated third-party patching tool instead of building this out.
- Can SCCM patch laptops that never connect to the office network?
- Only with additional infrastructure. Internet-only devices cannot reach a distribution point or the on-premises management point, so they neither receive content nor report compliance. The supported fix is a Cloud Management Gateway in Azure, optionally combined with the client setting that allows fallback download from Microsoft Update. For a small remote-first fleet, that is often more infrastructure than a cloud-managed patch agent would require.
- Can SCCM patch Linux servers?
- No. Configuration Manager had Linux and UNIX clients, but Microsoft retired that support, and macOS management moved to Intune. If your estate includes Linux, you will need separate tooling — native package managers driven by Ansible, a vendor platform such as Red Hat Satellite or Ubuntu Landscape, or a cross-platform patch tool that covers Windows and Linux with one agent.
- Should we move from SCCM to Intune for patching?
- It depends on where your devices live. For a cloud-first, Microsoft Entra joined Windows estate, Intune with Windows Update for Business (and Windows Autopatch where licensed) is Microsoft's own direction and removes the WSUS dependency. If you still rely on OS deployment, application packaging and on-premises servers, co-management is the pragmatic path: move the Windows Update policies workload to Intune and leave the rest in Configuration Manager.