We had issues during this patching cycle we call catchup to patch any servers that missed a patch for various reasons and then the reboot would occur after the current month’s patches would be applied during our normal patching window. Our servers that are 2012 were stuck in a reboot loop as it applied 1 of 6 patches. The only way out of the loop was to boot the server into safe mode and then reboot the server to continue with the application of the remaining patches (some were skipped). This happed to over 20+ servers and was a mess to get the servers back up.
I opened a ticket with M$ and the tech indicated that SSU’s are always applied first then a reboot must occur before security/cumulative updates are applied. We have our SSU’s listed first in the baseline and then the security/cumulative updates follow. I have read that an SSU does not trigger a restart so what Microsoft tells me is contradictory, to how the SSU behaves. In my mind, if a reboot is required why is this not written in the patch.
How is everyone else applying the SSU’s and what has been your experience if you apply them first (no reboot) then the cumulative/security updates?
I’ve worked with some customers experiencing the same, and consider it a bug in the Microsoft patching. It’s gone on for several months, and as far as I’ve seen only affected 2012 (not R2) servers.
The behavior I’d expect, is that If the Cumulative Update requires a reboot first to avoid a boot-loop, it should refuse to install. Obviously that’s not happening.
Our workaround has been to run a separate action with its own reboot, prior to the maintenance window wherw normal patching occurs. That’s been tenable since fortunately we generally have a very small number of 2012 servers. I don’t expect MS is motivated to make 2012 patching easier at this point.
We are only patching Window Clients and we list SSU’s in our Baseline just as you do. You are correct that M$ is not very clear on these updates with regards to a reboot being 100% necessary. I’ve read in some release notes where they call this out and other times where they do not.
Being we do deploy to clients, we have the retry count set to 1, under the theory that the SSA will install and if the others fail, it will reboot and then try the others. It seems to work OK in our environment.
We had that problem pretty bad 2 months ago. Had to recover multiple servers that were looping/needed recovery.
Now we place all SSUs into the first group of the baseline and close it with a Restart Endpoint (#126). Then the regular patches are in group 2, and finally Malicious Software updates in group 3. Seems to work better, but I am testing another restart at the end of Group 2 to deal with ‘Restart Needed’ issues.
We do SSUs in a group called prereqs for monthly patches at the start of the baseline. Seems to work well, we only had an issue with 2 2008 servers last month.
Like several others in this thread, I just put the SSU’s as first in the list of fixlets in a single baseline. I’ve patched 425 servers this week. All required at least 2 reboots to finish. No issues, though we thankfully got rid of all of our 2012 (not R2) servers a couple of years ago.
I like the idea mentioned by Meydey to separate the patches into groups and put a Restart Endpoint at the end of that group. I’m going to try that in the future.