When people say “SCCM patch management,” they mean the Software Updates feature in Configuration Manager (formerly SCCM, System Center Configuration Manager). Configuration Manager (also called ConfigMgr) provides the tools to manage, deploy, and monitor software updates to client computers in an enterprise.
Under the hood, ConfigMgr uses Windows Server Update Services (WSUS) to synchronize update metadata from Microsoft Update. ConfigMgr then adds targeting, deployment scheduling, content distribution, and reporting.
This article walks the SCCM patching process in the order it happens on your network:
- Synchronize: Update metadata is synchronized from Microsoft Update.
- Deploy: Updates are downloaded, packaged, and deployed to device collections.
- Scan: Clients scan themselves for applicable updates and evaluate their compliance.
- Report: Clients send compliance results back to ConfigMgr.
- Restart: Devices reboot when required to complete installation.
- Reevaluate: Clients reassess update compliance and report their final status.
Note: Configuration Manager clients scan for software updates at multiple points during the patching lifecycle. An initial scan determines which updates are applicable, while subsequent scans can reassess applicability and compliance after updates are deployed or other relevant changes occur.
By understanding how these stages connect, it’s easier to manage day-to-day patching and troubleshooting.
What is SCCM Patch Management, and Where does it Fit?
The patch management process is a chain with five links:
- Microsoft Update supplies the update metadata.
- SUP or the software update point pulls that metadata down. A software update point is a Configuration Manager site system role installed on a server that has WSUS installed.
- Configuration Manager stores the update metadata in the site database and creates policy at the site.
- Clients receive policy through the normal client-policy/management-point path.
- The client scans against that policy and reports back.
These five links are part of a pipeline. A failure at any link (a stalled sync, an unhealthy SUP, a database replication delay, or a client that never got the policy) breaks everything downstream of it.
The “Enable software updates on clients” Setting
One client setting in ConfigMgr impacts the whole chain: “Enable software updates on clients”. This setting is enabled by default and applies to all clients, indicating that clients receive the SUP location and participate normally. If you set it to “No” in default settings, the SUP location is not sent to clients. In simple words, software updates are disabled. Clients won’t scan, they won’t report compliance, and no deployment will reach them.
You can also disable the “Enable software updates on clients” setting for a specific device collection instead of making it the default. So if a whole collection is missing from every compliance report, check this setting.
SCCM as an Enterprise Windows Management Suite
SCCM earns its place in large environments for several reasons:
- It’s GUI-driven, so an admin doesn’t have to learn a scripting language to run routine operations.
- Its feature set is more extensive than many configuration-management alternatives, covering software deployment, patching, OS deployment, inventory, compliance, and other endpoint management tasks.
- It’s comprehensively documented and has a large user community, which means that answers to problems exist somewhere in a forum or a Microsoft Learn article.
That said, three things need attention:
- Configuration Manager is available under the Current Branch label. Its latest version is 2603, released in May 2026.
- Configuration Manager should be appropriately licensed. The Current Branch requires an active Configuration Manager license with Software Assurance (SA) or equivalent subscription rights. Organizations purchasing a new Configuration Manager license must acquire License and Software Assurance (L&SA). Configuration Manager rights are also included with certain subscriptions, including Intune, EMS E3/E5, Microsoft 365 E3/E5, and Microsoft 365 F3.
- Microsoft positions co-management as one of the primary ways to cloud-attach an existing Configuration Manager deployment to Microsoft Intune. Organizations can choose which workloads, if any, to move to Intune, while Configuration Manager continues managing the remaining workloads.
Why Patch Management Needs Continual Attention
Patch management is a continuous process. New vulnerabilities appear every month. Technology changes, vendors change how they package and install updates, and Windows periodically changes its servicing model.
An update pipeline configured two years ago must be adjusted as these factors change. Consider automation. Manual deployment isn’t sustainable for an indefinite period.
How does SCCM Track Patch Compliance and Reporting?
Clients regularly scan for software update compliance. For each update, a state message showing that update’s compliance state is displayed in the ConfigMgr console. From there you can deploy and install updates on the computers that require them.
Software Update Compliance States
Every update, on every client, has one of these four compliance states:
- Required. The update applies to the machine and it isn’t yet deployed, or it’s deployed but not yet installed, or it was installed but the update completion state message hasn’t landed in the database yet, or it’s installed but waiting on a restart.
- Not Required. The update doesn’t apply to this machine.
- Installed. The update applies, and the client already has it installed.
- Unknown. The site server hasn’t received a state message from the client, usually because the client computer did not successfully scan for software updates compliance. the scan succeeded but the state message is waiting to be processed on the site server, or the message file was corrupted in transit.
After an install finishes, the client rescans and sends an updated state message, which can take several minutes to reach the console. An update can be installed on the machine and still show Required in the console for that period. That’s not a fault. Chase it if it’s still required an hour later.
The Software Updates Compliance Scan Process
A scan is how a client determines its own state for every update in the catalog. When the SUP is installed and synced, a site-wide machine policy is created that tells clients that software updates are enabled. On receiving the policy, the client schedules its first compliance assessment scan to start at a random point within the next two hours, so that thousands of clients don’t hit the SUP at once.
Internet-based clients must connect to the WSUS server over SSL.
When the scan starts, the Software Updates Client Agent clears the scan history, finds the correct WSUS server to use for the scan, and updates the local Group Policy with the WSUS server location. The scan request then passes to the Windows Update Agent (WUA), which connects to that WSUS location, pulls the synced metadata, and evaluates the machine against it.
When the Software Updates Client Agent process detects that the scan has finished, it creates state messages for every update whose compliance state changed since the last scan, and sends them to the management point. The management point then forwards them to the site server, where they’re processed into the database.
When a scan fails start by reviewing the following log files:.
- ScanAgent.log records the scan requests and their outcomes
- WUAHandler.log records the WUA’s interaction with WSUS, including which update source it picked and why.
After the initial scan for software updates compliance, the scan can start in several ways:
- The software updates scan schedule configured in the Software Updates Client Agent settings.
- A user running the Software Updates Scan Cycle or Software Updates Deployment Evaluation Cycle from the Configuration Manager Properties dialog on the client.
- The deployment reevaluation schedule, also set in the Software Updates Client Agent settings.
- Immediately before downloading update files for a new required deployment, to confirm the update is still required.
- Immediately before an update installs, for the same reason.
- Immediately after an installation completes, to confirm the update is no longer required, and to report it as installed or as pending a restart.
- After a system restart that an installation required, to confirm the update is no longer required.
Time to Live (TTL) Value
Not every scan hits WSUS. The metadata a client needs for a compliance scan is cached locally, and by default that cache is valid for 24 hours. This period is called Time to Live (TTL). Within TTL, the client can answer a scan request from its own cache without contacting WSUS. When a scan is outside the TTL, the client connects to WSUS to refresh the metadata before scanning.
Scan Types: Online vs. Offline, Forced vs. Non-Forced
A scan can be forced or non-forced, which decides whether the client reuses its cached scan results:
- Non-forced scans check the TTL first and only refresh if it’s expired.
- Forced scans always refresh and ignore the cache.
Online or offline decides where the metadata comes from when a scan runs:
- Online scans are allowed to pull fresh metadata from WSUS. It describes what a scan is allowed to do, not what it always does.
- Offline scans are restricted to whatever is already stored locally.
Every trigger in Configuration Manager, the scan schedule, the pre-install check, and so on, maps onto one specific combination of these two decisions.
| Online (metadata may come from WSUS) | Offline (metadata is local only) | |
|---|---|---|
| Non-forced (cache reused if fresh) | Client checks the TTL first. Inside the TTL, it answers from cache, no WSUS contact Outside the TTL, it connects to WSUS and refreshes | Not a real combination. A non-forced scan that’s also restricted to local data would never refresh, so Configuration Manager doesn’t generate this pairing. |
| Forced (cache ignored) | The client always connects to WSUS and refreshes the metadata without checking the TTL. When the scan finishes, the TTL counter resets to a full 24 hours from that moment. | Client doesn’t connect to WSUS, and scans using local metadata. |
A Scan Evaluates the Whole Catalog, Not a Single Deployment
A scan evaluates the client against every update synchronized on the SUP, not one deployment. A scan produces compliance for:
- Updates in new deployments
- Updates in existing deployments
- Updates that were never deployed
Whether a client is targeted by one deployment or ten, one scan evaluates it against everything the SUP knows about, deployed or not. Adding more deployments doesn’t add more scans.
A Scan Updates Compliance, but Installation Still Requires Deployment Policy
Running a Software Updates Scan Cycle refreshes the compliance state for every update the SUP knows about. It does not make the client install a newly added update. Before the client can install a specific update, it must first receive the deployment (machine) policy for that update. These are separate actions.
- Run a Software Updates Scan Cycle to refresh compliance across all updates.
- If compliance is current but the update isn’t installing, run a Machine Policy Retrieval & Evaluation Cycle to retrieve the latest deployment policy.
- Follow it with a Software Updates Deployment Evaluation Cycle so the client evaluates that policy and acts on it.
Skipping step 2 is a common reason why nothing happens when a cycle runs; the client is evaluating a deployment policy it hasn’t received.
Audit-Ready Compliance Reporting
Configuration Manager includes built-in reports under Monitoring > Reporting > Reports Software update reporting is organized into categories such as:
- “Software Updates – A Compliance,” “Software Updates – B Deployment Management,” “Software Updates – C Deployment States,” and “Software Updates – D Scan.”
- “Compliance and Settings Management” is a separate category that contains reports for configuration baselines and settings compliance.
For deeper visibility into patch status, stale clients, or compliance for a specific regulatory scope, you may also need custom reports.
| Report name | What it answers | Built-in or custom |
|---|---|---|
| Compliance 1 – Overall compliance | Overall device compliance against a specified software update group for the selected collection. It shows the percentage and count of computers that are compliant or non-compliant, | Built-in |
| Compliance 2 – Specific software update | Compliance for a specific update across every targeted device. Useful when a particular KB or CVE requires sign-off. | Built-in |
| Compliance 5 – Specific computer | Software update compliance data for a specified computer, optionally filtered by vendor and update classification. | Built-in |
| Count updates | How many updates in a group are Required, Installed, or Unknown across a collection, a quick health check on a deployment group. | Built-in |
| Deployment states | Success, failure, and in-progress counts for each deployment, useful for monitoring a live patch cycle. | Built-in |
| Days since last scan / last compliant | Which machines haven’t scanned or reported recently. This can help identify broken or stale clients before they show up as false compliance. | Custom (built using the SUM Compliance and AssetStatus views) |
| Update state by business unit or regulatory scope | Compliance filtered to the specific device population a given regulation covers (for example, systems in scope for PCI DSS or HIPAA). | Custom, built on top of Compliance 1 |
How does SCCM Automate Patch Deployment?
Configuration Manager supports several software update deployment approaches. This article focuses on two common workflows:
- Deploy manually first to bring clients up to a baseline.
- Automatic deployment carries the recurring monthly load of managing software updates on clients.
Manual Deployment to Build the Compliance Baseline
Manual deployment means selecting updates in the ConfigMgr console and starting the deployment yourself. It is the recommended way to:
- Get clients current with the required updates before automatic deployment rules (ADRs) take over the monthly update deployment cycle.
- Deploy out-of-band update requirements.
The workflow is four steps:
- Filter for updates that use specific requirements, such as provide criteria to fetch all security or critical updates that are required on more than 50 client computers.
- Create a software update group that contains the filtered updates.
- Download the content for the updates in that group.
- Manually deploy the group.
Once compliance is high enough across the fleet that an ADR won’t cause a mass, disruptive install, you can move to an automated update cycle.
Automatic Deployment Rules (ADRs) and Patch Tuesday
Automatic update deployment is configured with an automatic deployment rule (ADR). It is the preferred method for managing monthly updates (known as Patch Tuesday) and definition updates. When a rule runs:
- It either clears updates from the software update group (if it is using an existing one) or creates a new group.
- Adds the updates matching your criteria (for example, all security updates released in the last week) to the group.
- If a deployment package is configured, it downloads the content files for the update and copies them to distribution points.
- Deploys the updates to clients in the target collection.
When an ADR is created, you specify certain deployment settings, such as target collection; whether the deployment is enabled or is only reporting compliance for that collection; the software updates criteria; evaluation and deployment schedules; and download properties.
Run the ADR on a collection of test clients first, confirm that the updates install there, then either add a new deployment to the rule or change the existing deployment’s collection to a wider target.
Note the following:
- Updates deployed by an ADR are automatically deployed to new clients added to the target collection.
- New updates added to the software update group are automatically deployed to clients in the target collection.
- Deployments can be enabled or disabled at any time for the ADR.
You can also add further deployments to an existing ADR. Each added deployment:
- Reuses the same update group and package created when the rule first ran.
- Supports its own activation time, deadline, and alerts.
- Can target a different collection.
Admins prefer to run a small, fixed set of ADRs rather than one all-purpose rule. A practical starting set:
- Patch Tuesday, workstations: Security and critical updates, released in the last 7 days, targeted at a pilot collection first, then production workstations on a staggered schedule.
- Patch Tuesday, servers: Use the same update criteria, but target servers and workstations separately so you can apply different maintenance windows and restart settings.
- Definition updates: Run an ADR daily for antimalware and Defender definitions. These change much more frequently than regular security updates.
- Out-of-band, emergency: Keep a separate ADR disabled until it’s needed for a zero-day or other urgent patch. Set its criteria to match a specific article ID or severity flag. Noe that a disabled ADR can’t be run. Enable it before running, then disable it again once it’s done its job.
PowerShell Cmdlets and APIs for Programmatic Patching
It’s tedious to manage every ADR, update group, and deployment status check through the ConfigMgr console. Use PowerShell instead. The ConfigurationManager PowerShell module, installed with the console, provides cmdlets for automating these tasks.
The following example covers three common tasks: creating an update group, triggering an ADR on demand, and checking deployment status.
# Set environment variables
$SiteCode = "ABC" # ← CHANGE THIS
$ProviderMachineName = "your-site-server.domain.com" # ← CHANGE THIS
# Import the Configuration Manager module
$ModulePath = Join-Path (Split-Path $env:SMS_ADMIN_UI_PATH) "ConfigurationManager.psd1"
Import-Module $ModulePath -ErrorAction Stop
# Connect to the Site Drive
if (-not (Get-PSDrive -Name $SiteCode -ErrorAction SilentlyContinue)) {
New-PSDrive -Name $SiteCode `
-PSProvider CMSite `
-Root $ProviderMachineName |
Out-Null
}
Set-Location "$($SiteCode):\"
# 1. Create a Software Update Group from a specific update
New-CMSoftwareUpdateGroup `
-Name "August 2026 Security Rollup" `
-UpdateId 5040442 `
-Description "Monthly security rollup, workstations"
# 2. Trigger an existing ADR on demand
Invoke-CMSoftwareUpdateAutoDeploymentRule `
-Name "Patch Tuesday - Workstations"
# 3. Check the ADR's last run
Get-CMSoftwareUpdateAutoDeploymentRule `
-Name "Patch Tuesday - Workstations" |
Select-Object Name, LastRunTime, LastErrorCode
# 4. Get deployment status
$Deployment = Get-CMSoftwareUpdateDeployment `
-Name "Patch Tuesday - Workstations 2026-08-11 09:00:00" # ← update this name if needed
if ($Deployment) {
Get-CMSoftwareUpdateDeploymentStatus `
-InputObject $Deployment
}Quick checklist before using it:
| Item | Action |
|---|---|
| Site code | Change $SiteCode |
| Site server | Change $ProviderMachineName to FQDN |
| ADR name | Match an existing Automatic Deployment Rule |
| Update ID | Must be a Configuration Manager software update CI_ID, not necessarily the KB number displayed in Microsoft documentation. |
| Deployment name | The long name with timestamp must exist, or the status section will do nothing |
| Console installed | The script relies on $env:SMS_ADMIN_UI_PATH (i.e. the ConfigMgr console must be installed on the machine running the script) |
| Permissions | Account needs rights to create SUGs, run ADRs, and read deployment status |
Important: Run all Configuration Manager cmdlets from the site drive (PS ABC:\>), not from your normal filesystem location, or most of them will fail with a provider-related error. This same handful of cmdlets can form the basis of an automated workflow for creating software update groups, running automatic deployment rules (ADRs), and checking deployment status.
- New-CMSoftwareUpdateGroup
- New-CMSoftwareUpdateAutoDeploymentRule
- Invoke-CMSoftwareUpdateAutoDeploymentRule
- Get-CMSoftwareUpdateDeploymentStatus
Additional PowerShell code or another automation mechanism is required to schedule the workflow and send email notifications.
Note: Configuration Manager (SCCM) does not manage software updates for macOS, mobile devices, and IoT platforms, so there is no guidance in this article on programmatically patching them.
How does SCCM Handle Third-Party Application Patching?
Third-party patching in Configuration Manager focuses on updating non-Microsoft software (such as Adobe, Chrome, Java) running on Windows endpoints.
Centralized Third-Party Patch Catalogs and Ready-to-Deploy Packages
Managing third-party application patching in Configuration Manager can take a lot of hands-on work, from finding updates and creating packages to testing, deployment, and troubleshooting. A practical approach is to add a subscription-based third-party catalog on top of the existing WSUS and Configuration Manager setup:
- Subscribe to a third-party update catalog: Choose a Microsoft-partner catalog or a commercial patch-management add-on.
- Integrate that catalog’s update metadata with your existing update platform and configure its synchronization schedule.
- Newly synchronized third-party updates initially appear as metadata-only updates. Publish the updates you want to make available for deployment.
- After publishing, run another software update synchronization so the published updates become available for deployment.
- hird-party updates show up in the console the same way Microsoft updates do, and get deployed with the same software update groups and ADRs.
Third-party update files consume storage. Plan for at least 50 GB of free space on the volume hosting the WSUS content folder before adding a third-party catalog. This requirement can grow as you subscribe to multiple vendors, as third-party installers tend to be larger than Windows quality updates.
Mitigating Vulnerabilities in Third-Party Apps, VMs, and Offline Machines
Third-party applications such as Java, Adobe Acrobat/Reader, and Firefox need regular patching because they follow their own release schedules and can introduce vulnerabilities between Microsoft’s update cycles. Adobe, for example, reported that CVE-2026-34621 (a critical Acrobat/Reader vulnerability that allowed arbitrary code execution) was being exploited in the wild until an emergency fix was issued.
It is not easy to get these updates to every endpoint. Virtual machines that are powered off can’t receive Configuration Manager policy, can’t run a software update scan, and can’t download update content until they come back online. Offline endpoints with no network path to the SUP have the same problem. Once they reconnect, they must receive policy and run a software update scan before Configuration Manager can assess their compliance and deliver missing patches.
System Center Updates Publisher for Updates Not on Microsoft Update
Some updates don’t come through Microsoft Update, such as custom internal packages and hardware-vendor drivers without WSUS integration. Configuration Manager integrated with System Center Updates Publisher (SCUP) to bring that metadata into its software update workflow. However, as of January 31, 2024, Microsoft no longer supports SCUP and its integration with Configuration Manager.
When SCUP was supported, the process was three steps:
- Publish the update to WSUS or another configured update server using Updates Publisher.
- Synchronize the published update into Configuration Manager using the same way you’d sync any third-party catalog.
- Deploy the update to clients through the normal software update groups and deployment process.
For custom updates, consider supported third-party catalogs or patch-management solutions instead of building new workflows around SCUP.
Which Devices and Platforms Can SCCM Patch?
Configuration Manager’s Software Updates feature depends on WSUS and the Windows Update infrastructure, meaning it cannot natively patch macOS, Linux, mobile, and non-Windows IoT devices.
Previously, Configuration Manager offered limited client support for non-Windows operating systems. For quite some time, native macOS and Linux/UNIX client support has been officially retired.
If your environment includes Macs, mobile devices, and non-Windows endpoints that need patch management, use Microsoft Intune or a dedicated MDM platform.
The following table lists what ConfigMgr can and cannot patch natively:
| Platform | Patched natively by ConfigMgr Software Updates | Manageable as an end client |
|---|---|---|
| Windows desktop and server | Yes, for supported versions | Yes |
| Windows Embedded / IoT (write-filter enabled) | Yes, with write-filter handling required during deployment | Yes |
| macOS | No | No. The Configuration Manager macOS client is deprecated and support fully ended on Dec 31, 2022. |
| Mobile (iOS, Android) | No | No. Use Microsoft Intune or another supported MDM platform. |
| Linux / UNIX server variants | No | No. Client support was removed in version 1902. |
| IoT devices outside the Windows Embedded family | No | No |
Windows Embedded Devices That Use Write Filters
Write filters protect embedded devices (kiosks, point-of-sale terminals, thin clients) by redirecting disk writes to a temporary overlay that clears when the device restarts. If you deploy an update without disabling the write filter first, the update lands in that temporary overlay, appears to succeed, and then disappears when the device restarts, because the restart is precisely what the overlay is designed to wipe.
The “Commit changes at deadline or during a maintenance window (requires restarts)” checkbox controls the write filter behavior. Enable it, and Configuration Manager disables the write filter, installs the update, and restarts the device to commit the change.
One more thing: the Windows-embedded device should be a member of a collection that has a configured maintenance window. This lets you control when the write filter is disabled and re-enabled, and when the device restarts.
How does SCCM Synchronize Software Updates?
Software updates synchronization in Configuration Manager connects to Microsoft Update to fetch software updates metadata. The top-level site (whether a central administration site or a stand-alone primary site) synchronizes with Microsoft Update on a schedule or when you start synchronization manually from the ConfigMgr console.
When software updates synchronization finishes at the top-level site, it starts at child sites, if they exist. When this also completes, a site-wide policy is created that provides the location of the SUP to client computers.
After a client receives that policy, it scans for software updates compliance and writes the results to Windows Management Instrumentation (WMI). The compliance information goes to the management point, which forwards it to the site server.
Note: When you connect a Configuration Manager console to a child site, Configuration Manager displays the software updates metadata. However, that does not mean updates will be successfully deployed to clients. A SUP must be installed and configured at a child site, else clients at that site will not scan for compliance, will not report compliance information to Configuration Manager, and updates cannot be deployed.
You can install multiple SUPs at a primary site. The first one you install becomes the synchronization source. It synchronizes metadata from Microsoft Update or from a WSUS server outside the Configuration Manager hierarchy. The remaining SUPs at that site use the first SUP as their synchronization source.
You can specify an existing WSUS server (outside the Configuration Manager hierarchy) as your synchronization source instead of Microsoft Update. This is useful in isolated or air-gapped networks where the site server has no direct internet access, and relies on an upstream DMZ server or an offline WSUS export/import process.
Three log files are worth mentioning here:
- wsyncmgr.log tracks the software update synchronization process, start to finish, including the specific step where it’s currently stuck if something goes wrong.
- WCM.log tracks Software Update Point (SUP) configuration and connections to WSUS.
- WSUSCtrl.log provides information about WSUS configuration, database connectivity, and WSUS health.
Check these logs when troubleshooting problems with the SUP or its underlying WSUS installation.
Synchronization on the Top-Level Site
The process runs in a fixed order:
- Software updates synchronization starts.
- The WSUS Synchronization Manager requests WSUS on the SUP to begin synchronizing with Microsoft Update. You can configure criteria (products, classifications, languages) in Software Update Point Component properties at the top-level site. The synchronization process pulls only the update metadata that matches your criteria.
- Metadata synchronizes from Microsoft Update and changes are inserted or updated in the WSUS database.
- Once that finishes, the same metadata is synchronized again, from the WSUS database into the Configuration Manager site database. Changes since the last synchronization are inserted or updated and each update is stored as a configuration item.
- From there, the software update configuration items are sent to child sites through database replication.
- On success, WSUS Synchronization Manager creates status message 6702.
- WSUS Synchronization Manager sends a synchronization request to all child sites, then requests synchronization one at a time from WSUS running on other SUPs at the site.
Synchronization on Child Primary and Secondary Sites
Child sites do not reach out to Microsoft Update. During the top-level synchronization, update configuration items replicate to child sites through database replication. At the end of the process, the top-level site sends a synchronization request to the child site, and the child site starts its own WSUS synchronization.
WSUS running on the SUP on the child site synchronizes updates metadata from WSUS running on the SUP on the parent site. On success, WSUS Synchronization Manager creates status message 6702.
WSUS Synchronization Manager passes a synchronization request from a primary site to any child secondary sites, which then starts update synchronization with the parent primary site.
WSUS Synchronization Manager sends a request one at a time to WSUS running on other SUPs at the site.
How do SCCM Deployment Packages and Content Distribution Work?
Not every deployment uses a deployment package. When you select No deployment package, Configuration Manager doesn’t first download and distribute the update content through a deployment package. Depending on the client and configuration, clients can obtain update content from Microsoft Update, Microsoft cloud sources, or peer devices. Then download it to the local cache before installation. The deployment package remains a common way to distribute software update content through distribution points, but it isn’t mandatory for every deployment.
When You Use a Deployment Package
Software update content follows this path when you use a deployment package:
- A software update deployment package downloads the update from the download source (Microsoft Update, the internet, or a network shared folder for offline scenarios) into a network shared folder that you create manually.
- Configuration Manager copies the software update source files to the content library on the site server.
- Then to the content library on every targeted distribution point.
- Clients download required update files from a distribution point into their local cache before installation.
Two wizards move updates through this process:
- Use the Download Updates Wizard to download software updates and add them to deployment packages before you deploy them. This wizard lets you provision updates on distribution points and confirm that distribution succeeded before you deploy the updates to clients.
- The Deploy Software Updates Wizard gives you three choices when the software updates have not already been downloaded:
- Select an existing deployment package
- Create a new deployment package
- Choose No deployment package
If the updates were already downloaded, the wizard reuses the existing package automatically (or skips the package pages entirely). When you create or select a package, the updates are downloaded when the wizard finishes.
Note the following:
- You must create the shared network folder for the deployment package source files manually before naming it in the wizard, and every deployment package must use a different shared folder.
- Both the SMS Provider computer account and the administrative user downloading the update need Write permissions to the package source.
Tip: A standard monthly Windows quality update package runs about 800 MB to 1.5 GB per OS version once cumulative updates and their prerequisites are bundled together. That multiplies fast if you’re managing several OS versions in parallel (like Windows 10, 11, and Windows Server). Make sure your Distribution Point storage and network bandwidth can handle that monthly hit.
When You Select “No deployment package”
Software update content follows this path:
- Select No deployment package when configuring the software update deployment.
- Configuration Manager deploys the software update group and sends the associated software update policy to the targeted clients.
- The client receives the policy and determines which updates it needs.
- The client obtains the required update content from an available content source. If a local source is available, it can use that source; otherwise, clients download the content directly from Microsoft Update.
- The update content is downloaded to the client cache and then installed.
The Software Update Deployment Process (Client-Side
When you deploy updates, a deployment assignment policy is added to the client’s machine policy for the site.
- When a client in the target collection receives the machine policy, the Software Update Client Agent starts an evaluation scan and downloads content for required updates from a distribution point into the local client cache at the deployment’s configured software available time. (Optional deployments (those without an installation deadline) are not downloaded until a user manually starts the installation.)
- From that point, the updates are ready to install.
- When the deadline passes, the client runs a scan to confirm that the updates are still required, checks that the content is still in the local cache, and installs. If the content was deleted from the cache, the client re-downloads it from the distribution point.
- When installation completes, the client agent verifies that the updates are no longer required and reports them as installed to the management point.
Required System Restart Behavior
When an update from a required deployment installs and needs a restart to finish, the client is rebooted by default. For updates installed before the deadline, that automatic restart is postponed until the deadline, unless the machine reboots for some other reason. Restarts can be suppressed for servers and for workstations, and those settings are available on the User Experience page of the Deploy Software Updates Wizard or the Create Automatic Updates Rule Wizard.
Deployment Reevaluation Cycle (7-Day Default)
Clients run a deployment reevaluation cycle every 7 days (default). In this cycle, a client scans for updates that were previously deployed and installed. If any of them are missing, whether from a rollback, a reimage, or manual removal, the client reinstalls from its local cache if the content is still there, or redownloads from a distribution point if it isn’t. Use the Software Updates page in client settings for the site to configure the reevaluation schedule.
How does the SCCM Software Update Cycle Work, Log by Log?
The software update process moves through several stages. The following table shows what happens at each stage, the logs to check, and the client cycle involved.
| Stage | What happens | Main logs | Client cycle |
|---|---|---|---|
| 1. Synchronize | Update metadata moves from Microsoft Update into WSUS on the SUP and is then processed into the Configuration Manager site database. | Site Server: wsyncmgr.log for the synchronization process WCM.log for SUP/WSUS health | None, this runs at the site |
| 2. Package and distribute | Update files are downloaded into a deployment package, added to the content library, and distributed to targeted distribution points. | Console Machine: patchdownloader.log for downloading binaries Site Server: DistMgr.log for package creation and content distribution processing PkgXferMgr.log for transfer to remote distribution points | None (site-side task) |
| 3. Scan | The client evaluates its update compliance against available update metadata. The scan can run as forced or non-forced and online or offline. ConfigMgr scans several times during the update lifecycle. | Client: ScanAgent.log for scans request details WUAHandler.log for Windows Update Agent execution | Software Updates Scan Cycle |
| 4. Deploy | Configuration Manager creates a deployment assignment policy and makes the policy available to the targeted clients. | Client: PolicyAgent.log for policy requests UpdatesDeployment.log for deployment evaluation | Machine Policy Retrieval & Evaluation Cycle: retrieves new deployment policy |
| 5. Install and restart | Applicable required updates are downloaded, installed, and the client is restarted if necessary. | Client: UpdatesDeployment.log for deployment details UpdatesHandler.log for installation execution RebootCoordinator.log for reboot schedules | No separate restart cycle, this is a side effect of installation |
| 6. Reevaluate | Every 7 days (default), the client rechecks required updates to verify compliance and reinstall missing items. | Client: UpdatesDeployment.log, ScanAgent.log, and WUAHandler.log can help track the process. | Software Updates Deployment Evaluation Cycle |
| 7. Report | The client sends software update compliance state messages to the management point and site server for reporting. | Client: StateMessage.log for details about software update state messages Site Server: StateSys.log for processing of state system messages | None, triggered automatically post-scan/install |
What are the Most Common SCCM Patch Management Failures and How Do You Fix Them?
You may encounter these software update errors:
| Error or symptom | What it usually means | What to check |
|---|---|---|
| 0x87D00607 (-2016410105), content not found | The client can’t find the required update content. Common causes include missing content on the distribution point or boundary group and content-location problems. | Check that the update content was successfully distributed to the relevant distribution point. Then confirm that the client’s boundary group can locate a healthy DP with the required content. Check CAS.log, ContentTransferManager.log, and DataTransferService.log. |
| 0x80240022, updates failed | The Windows Update Agent failed to install all updates in the operation. The error itself doesn’t identify the root cause. | Check WUAHandler.log, UpdatesHandler.log, and Windows servicing logs to identify the specific update and underlying failure. |
| 0x8024401C, HTTP request timeout | The Windows Update Agent timed out while communicating with the update source. | Check connectivity between the client and WSUS/SUP, including proxy, firewall, DNS, and network timeout issues. |
| 0x87D01201 (-2016407039), insufficient cache or disk space | The client doesn’t have enough available cache or disk space to download the required content. | Increase the configured client cache size if appropriate, or free disk space on the endpoint. |
| 0x87D00692 (-2016409966), Group Policy conflict | Configuration Manager can’t access or update something required for the operation. In software update scenarios, a higher-priority Group Policy can also overwrite Windows Update settings. | Check WUAHandler.log for policy-related errors. Review conflicting Windows Update GPOs and verify access to the affected file, folder, or registry location. |
| 1603, generic installer failure | The installer returned a generic fatal error. The underlying cause is usually specific to the update or installer. | Check the update or installer logs, Windows servicing logs, and UpdatesHandler.log. |
| Unknown compliance that doesn’t resolve | The client may not have completed a successful scan, may not be reporting state messages, or the state messages may not be processing correctly. | Start with ScanAgent.log and WUAHandler.log to confirm that the scan completed. Then check StateMessage.log on the client and StateSys.log on the site server to trace state-message processing. |
FAQs
Can SCCM Patch Remote or Internet-Based Devices Without a VPN?
Yes. Configuration Manager can manage internet-based clients without a VPN when they’re configured for Cloud Management Gateway (CMG) or other supported internet-based client management. The client can communicate with the Configuration Manager infrastructure over the internet and receive policies, scan for updates, and download content from a content source.
H3 – What is the Best SCCM Alternative for OS and Third-Party Patch Management?
The right alternative depends on your environment, licensing, operating systems, and third-party application requirements. Microsoft Intune is a common option for cloud-based Windows management and Windows Update management, while third-party patch-management platforms can provide comprehensive third-party application coverage and automation.
How do You Roll Back or Uninstall a Bad Windows Update in SCCM?
If an update supports uninstalling, you can create an uninstall deployment for the update, or use the appropriate Windows servicing or PowerShell command on affected devices. For updates that don’t support removal, remediation may require restoring the device from a recovery point, uninstalling a related package, or following Microsoft’s guidance for that specific update.
H3 – Can SCCM and Intune Split Windows Update Management in a Co-Management Environment?
Yes. In a co-management environment, you can move the Windows Update policies workload to Intune while Configuration Manager continues managing other workloads. Organizations can decide which workloads remain with Configuration Manager and which move to Intune.
How do You Exclude a Specific KB or Problematic Update from an SCCM ADR?
Configure the ADR’s Software Updates filter criteria to exclude the update. For example, you can exclude a specific KB article ID or use other criteria such as update classification, product, or title. If the update has already been added to a software update group and deployed, changing the ADR’s criteria won’t automatically undo that existing deployment. You may need to remove the update from the software update group or take separate action on the existing deployment.
What is the Difference Between an ADR Evaluation Schedule, Software Available Time, and Installation Deadline?
They control different parts of the deployment process:
- ADR evaluation schedule: Controls when Configuration Manager runs the Automatic Deployment Rule. When the rule evaluates, it finds matching updates, updates the software update group, and creates or refreshes the deployments.
- Software available time: Controls when the update becomes available to clients for download and installation.
- Installation deadline: Controls when Configuration Manager requires the update to be installed on clients for Required deployments only, subject to the deployment’s user-experience and restart settings.
How does Action1 Simplify Patch Management Compared with SCCM?
Action1 simplifies patch management with its cloud-native, agent-based approach. It manages OS and third-party application patching for remote and on-premises endpoints without a VPN or on-premises patch-management infrastructure.
- Action1 provides autonomous OS patching for Windows, macOS, and Linux, plus third-party application patching from a cloud-based console.
- Update Rings let you stage patch deployments across groups of endpoints and control how updates progress through the rollout.
- Vulnerability detection and remediation help identify missing patches and address vulnerabilities on demand or through scheduled policies.
- Flexible scheduling options let administrators deploy updates according to their maintenance requirements.
- Missed-schedule retry allows offline endpoints to receive updates when they reconnect within the configured retry window.
- The same cloud-based console can manage on-premises, remote, and off-network endpoints without requiring them to connect through a corporate VPN.
- P2P distribution can share update files between endpoints on the same local network, reducing external bandwidth usage
- Action1 provides a privately maintained, secure software repository for deploying applications and managing software packages, it also supports software removal from endpoints.
- Built-in scripting lets administrators run PowerShell and CMD scripts remotely to automate repetitive endpoint-management tasks.
- Inventory, reporting, and real-time monitoring provide details on endpoint software, hardware, vulnerabilities, and patch status, with more than 100 customizable report templates available for reporting and compliance needs.
- Action1 offers a free tier covering up to 200 endpoints, fully featured, forever.
For organizations looking to reduce the infrastructure and effort involved in patch management, Action1 provides a cloud-based alternative to the traditional SCCM approach while also extending patching to remote and mixed-OS environments.
