Issue
A patch policy runs against a Windows device, but the run reports only a Servicing Stack Update (SSU) as installed while the other scheduled updates — most often a cumulative update — show as awaiting, deferred, or not installed. The remaining updates then install on a later policy run, which can look like the policy failed or skipped patches.
Environment
- Automox (current agent release)
- Windows devices; patch policies installing Windows updates
- Console areas: Manage Devices (device Software page), patch Policies, Activity Log
Overview
A servicing stack update fixes the servicing stack — the component that installs Windows updates. Because that component performs the installation, an SSU is a prerequisite: the correct servicing stack has to be in place before the latest cumulative update (LCU) can install reliably. When a device is missing a required SSU, the cumulative update can appear stuck — it stays in an awaiting/failed state — until the SSU is applied first.
To reduce this problem, since February 2021 Microsoft ships the latest servicing stack inside the monthly cumulative update as a single combined payload (starting with KB4601382 on Windows 10 version 2004 and later), so most modern devices no longer receive a separate SSU. On rare occasions Microsoft still releases a standalone, out-of-band SSU — rated Critical — when it is needed for that month's cumulative update to install. Older or lagging devices may also still have a separate SSU pending.
Automox installs a standalone SSU on its own, ahead of the other updates in the same manifest, rather than alongside them. This is why a single run can complete the SSU and defer everything else to the next scheduled execution of the policy — the SSU goes in first, and the remaining updates install on the following run once the servicing stack is current. This is expected behavior, not a failure.
Resolution
- Confirm what actually happened in the run:
- Open the device's Activity Log and the Software page and check whether the completed item is a Servicing Stack Update (its name includes "Servicing Stack Update") and whether the remaining updates are still awaiting rather than failed.
- If the SSU installed and the other updates are simply pending, no action is needed — let the policy run again and it will install the deferred updates.
- Re-run the policy (or wait for its next scheduled execution) so the previously deferred updates install now that the servicing stack is current:
- You can rescan and re-run on demand from the device's Software page instead of waiting for the schedule.
- For predictable results, install servicing stack updates ahead of your standard patching with a dedicated policy:
- Create a separate patch policy that targets only servicing stack updates and schedule it to run before your regular patch policy. See Creating a Patch Policy and use an Advanced (package-targeting) policy to filter by display name for "Servicing Stack Update."
- A standalone SSU generally does not require a reboot, so this pre-patch policy can complete quickly and clear the prerequisite before the main run.
- If a cumulative update continues to fail after the SSU is installed and current:
- Reset the Windows Update components — see Windows Update Services Reset — then rescan and re-run the policy.
Notes
- On devices running Windows 10 version 2004 and later, the servicing stack and the cumulative update usually arrive as one combined package, so you may never see a separate SSU. A standalone SSU most often appears on older builds or when Microsoft ships an out-of-band prerequisite for a specific month.
- Seeing only the SSU complete in a run does not mean the policy failed. Confirm the other updates are awaiting (they install next run) rather than failed before troubleshooting further.
- For cumulative updates that never install even after the servicing stack is current, see Common Windows Update Error Codes to identify the specific failure.