Install Servicing Stack Updates Before Other Updates
Currently, when servicing stack updates and regular updates are deployed in the same software update group, the patches do not apply in a determinant order. This leads to cases where a cumulative update that requires a new servicing stack is installed before the servicing stack itself.
While this can be worked around by separately deploying the servicing stack update before updates that require said servicing stack, it would be much more convenient if the update installation process checked if there are any servicing stack updates to be deployed and automatically installed them first
Jesse Schauer
shared this idea
23 comments
-
Anonymous
commented
I agree with all the comments in this thread. We need the ability to run software update evaluation after all updates are installed regardless of reboot.
-
Sriram
commented
Indeed MS should enhance SCCM capability for sug to detect a pre-requisite, before patches in sug get applied on device
-
Sai Kurapati
commented
I agree with all the comments in this thread. We need the ability to run software update evaluation after all updates are installed regardless of reboot.
-
Paul
commented
This is proving almost unmanageable.
We also work in healthcare, our Servers have 2 hours maintenance windows which is well enough to install updates but when the SSU installs the process then completes, no reboot and the CU which has been saved to the ccmcache folder just sits uninstalled. So next month comes around and same thing can happen again with the next SSU and no CU.Very very poor MS, can you please coordinate the ConfigMgr and WinUpdate teams to work together on a solution.We have had many times in the past where there are clashes between CM and WU and neither team claim responsibility, please MS these are your products! Remember we have choices as to patching mechanisms, Operating Systems and these situations are not in your favour!
-
CBraun
commented
No SSU this month? Does that mean it has been built into the monthly CU? This is a good sign for patching in the days ahead.
-
Anonymous
commented
Same problem when offline-servicing an OS image.
-
Meister-T
commented
Planned. Great. How its going on. Any status updates or feedback?
-
Jesper Hassing
commented
Planned! Yay!
-
Andrew
commented
This patching process is making my job miserable. Working in healthcare, I have a very small window to deploy patches. Finding out that patches didn't apply in time, or the CU's weren't even detected because the SSU wasn't updated is causing us to miss our patching window, which means more coordinated downtime with the units. Please find a better way to handle these updates.
-
Ken
commented
The service stack is a wall between old and new updates.
Old update are still valid until the time the service stack is installed.
Then No Updates are viable.
After the service stack is install and scan run only then can the new updates viable.Can the cumulative update monthly install equal to the service stack month not be made viable for both pre and post cumulative update?
Then both order and scans become irrelevant.
Its detection and install will work before the service stack or after the service stack. -
Pieter Pessemier
commented
My 2 cents:
Just having an option to automatically run an SU Scan Cycle and SU Deployment Evaluation Cycle right after successful or unsuccessful installation of the triggered updates, regardless of a reboot requirement, would fix this. We basically just want everything patched within our defined maintenance window regardless of the amount of reboots or prerequisites.
-
Bryan Dam
commented
@Charles: You're not wrong but keep in mind that options 2-4 are out of the ConfigMgr team's hands. So the only thing in their control is #1 which I've been told they are looking into.
I can't find this stated anywhere but I heard from the product team that the new Unified Update Platform will implement #2: Make the SSU and CU on patch. But that's not going to help for a long time.
It's worth noting that the behavior indicated by the actual UVI (install SSU before CU if both appear) would be great from a steady-state perspective. This month we're just all a tizzy because MS made them pre-reqs again which hasn't been the norm. So we really need both.
-
Charles Flanders
commented
This is crazyness! A number of really simple fixes:
1. SCCM should be able to rescan for newly available patches after all updates are done in a run WITHOUT a reboot.
2. Include the SSU into the CU patch, and build the patch such that the SSU content hits first.
3. Change the SSU patches to require a reboot if we can't change SCCM.
4. Stagger the updates! Don't put out an SSU in May and have the May CU require it!Any of these could work, with the appropriate care. Why are we forced to find janky workarounds for something that should have been considered within MS (both the patch creator team, and the SCCM team) well before patches were ever published for deployment.
-
Anonymous
commented
Please install SSU first
-
Jason Oakes
commented
Come on MS, PLEASE FIX THIS! Patching is a pain as is let alone left having to wonder about this stuff every month! Please make some investments here. It has been like this for far too long.
-
bdam
commented
It appears that my earlier UVI got merged into this one. Though similar they were not the same in the technical details that matter.
Just again this month (May 2019) Microsoft released updates that required the same month's SSU be installed. In this situation this UVI won't matter: only the SSU will be detected as applicable. The solution is to run a software update evaluation after _all_ updates have been installed to see if any new one are now available. The product currently has a setting to do that after reboot but the SSUs don't require a reboot.
TL;DR: We need to run a software update evaluation after all updates are installed regardless of reboot.
-
bdam
commented
This more or less a dupe of this: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/34608748-run-software-update-evaluation-after-updates-have
The patches _do_ apply in a determinate order. If the metadata for a CU requires a SSU then the CU will not be applicable and therefore not be offered for install in the first place.
-
HoustonAU
commented
As much as I would love this, it is a far wider problem with the Servicing Stack. This should be resolved at the OS level, not the Config Mgmt level.
They need to address the entire issue of SSU updates in general, why do we need them, why are they different from other updates, why aren't they identified as SSU in some way etc.
Fix the updates themselves and we wont need to modify SCCM
-
gxt
commented
https://support.microsoft.com/en-us/help/4471329
Microsoft strongly recommends you install the latest servicing stack update (SSU) for your operating system before installing the latest cumulative update (LCU). SSUs improve the reliability of the update process to mitigate potential issues while installing the LCU and applying Microsoft security fixes. For more information, see Servicing stack updates.If SSU's aren't installed first, they cause the:
1. BSOD we had back in January 2018
2. Loss of USB we had in February 2018"You have to get them installed first. To have them install second/or not at all can crater a machine." (credit: Patch Lady Susan)
In my experience, the installation order in ConfigMgr is random and given the importance of having the SSU installed first, we can't just install the SSU first and then LCU after, because once the deployment deadline is passed (for example a newly built machine), we can't guarantee the order.
-
Max
commented
This is the most important/missing feature today. This is right not only for servicing stack updates but also for regular updates. Currently there is no simple/builtin way to get (some) systems fully patched using a single deployment schedule within a single window, if some updates fail during the deployment, or if some updates cause WU client to detect new updates in next scan cycle.
The problem is that a deployment may show as compliant, let's say in the morning after patching, but later it the same deployment shows as non-compliant. This is because the re-scan or re-evaluation cycle occurs after the maintenance window ends. According to the documentation the interval between 2 scan cycles or 2 deployment re-evaluations cycles cannot be set to less than 1 day. The documentation states that if the interval is set to less than 1 day it is reset automatically to 1 day.
There a lot of workarounds to get deployment re-scheduled again or creating multiple deployments or multiple cycles, but this get complicated and causes a an administrative overhead, instead of packing multiple cycles into a single step.