Servicing Stack Updates (SSU) and how they affect policy runs that include them on their patch manifest
A distinctly Windows problem, Microsoft occasionally releases SSUs to be applied to their devices. They've reduced the amount of them seen overall by rolling the updates into their monthly cumulative releases, but they still appear from time to time. SSUs require exclusivity on their installation, which causes anything else in the same manifest to be pushed back to the next scheduled execution of the policy.
Why this causes unexpected behavior with patch policy executions
SSUs are updates to the Windows Updater and its files. To accomplish their update, Microsoft has set them up to not be happy being run in a group. Thus causing patch manifests with an SSU and anything to suddenly become just the SSU on the post-policy run report.
What can be done within Automox
- First, now that you know about the exclusivity behavior, it can help with properly setting expectations on patch policy results.
- Second, as an SSU does not require a reboot and is updating items that are not being actively engaged by the user (unless they happen to be doing updates outside of the agent's control), you can set up a separate policy for just SSUs that runs before your standard policy runtime. This will get them out of the way of the standard patch policy run.
- An example of how to set the policy up can be found here: What Are the Recommended Best Practices for Patching in Automox?