Microsoft Windows Servicing Stack Updates (SSU) – A Rant

Copied from my twitter rant here: https://twitter.com/ip1/status/1039668421615529985

May contain edits and be added to at a later time

A rant about service stack updates (SSU) and why Microsoft really needs to work something better out for this:
When the major monthly cumulative update requires the SSU as a pre-req, it creates major pain points with managed deployment. If you are running “unmanaged” and just let clients go to Microsoft directly to get whatever is applicable, then you probably aren’t worried about this.

So first scenario: Small org using WSUS, and/or someone with ADR setup to auto-approve “needed” updates. In this case, the main CU doesn’t even register with WSUS as needed because it needs to install the SSU first. So think about the timing here.
WSUS gets the latest catalogue, client scans/reports results, ADR runs and gets “needed” SSU update, client installs update, next client scan now detects CU needed, next ADR run now sees CU needed, next client scan sees CU now applicable and install… this cycle could take days!
Now, if you are using something like GPO or have expected time frames you want thing to install in (change windows), this certainly makes things complicated.
Even if you manually approve the CU, it will still depend on how often your clients run the update scan to get it
If use WSUS to patch servers, and need to have that install process happen within a specified change window, you need a process/config that triggers the clients to do multiple update scans within your change window so it can detect and install the CU after the SSU is done
So now what about using a managed system like ConfigMgr? Unfortunately in some ways it can be even worse, but essentially the same challenges remain. Since the SSU doesn’t require a reboot, it won’t trigger the ConfigMgr setting for “run scan after update triggers restart”
This means that the update deployment you send out will install the SSU, but then nothing more until your client policy triggers another Update scan cycle. You don’t know *exactly when* the SSU will be installed, so what options do you have?
For servers we have a clearly defined maintenance window we can do things in, so the awful hack is to have a script that trigger the update scan cycle *every hour* during the change window so it can detect the CU after the SSU has completed
But for workstations we just have a “start time”, so the SSU could install, no reboot needed, and then nothing happens until the next scan cycle. This means we will likely end up with machines wanting to reboot a day after we said the updates start.
You can’t have a recurring job triggering an update scan on workstations since we don’t have a clear window when they will install, and if you have your “re-scan” schedule set to 7 days (default) then it might be a week before the CU is actually detected as needed.
Fortunately for workstations, there are usually Office updates that also need to install and they will require a reboot, so you get to use the “scan after restart” option.
This does mean however, that after all those Office updates have finally installed, and the user finally reboots, that the CU will get detected, and then it will start installing and then require another reboot.

Users love that experience.

Now what if you don’t force reboots?
Well, if you only notify users a reboot is required and leave it up to them, you can be back to spending days/weeks waiting for machines to get compliant.
So what’s the solution for all this? I dunno. Maybe there needs to be some special logic for updates/WSUS/ConfigMgr to deal with the SSU when installed. Maybe have an option to require a reboot for the SSU even if it doesn’t need one. Maybe find a way to roll SSU’s into CU?
If SSU’s are going to become a regular thing, then there needs to be a better way to deal with them.

Because the current options are not much fun.