For the past few months, the monthly Windows Updates proved to be a bit more difficult to handle, thanks to Microsoft’s Servicing Stack updates. Servicing Stack updates are basically updating the components that process Windows Update among other management components. This means that pretty much each time a servicing stack update is released, it must be applied prior to being able to install the various cumulative updates required. In this post, we will demonstrate how to manage servicing stack updates with SCCM using Automatic deployment rules (ADR)

Those updates are not necessarily being released each month, and if they are, it may be for only a few OS version or builds. For most environments, it will mean that some OS will require Servicing Stack updates pretty much each month as Microsoft been releasing updates each month for the past few months

This great write up by DamGoodAdmin gives more details on how the servicing stack updates affect monthly updates.

As described by DamGoodAdmin, the Servicing stack updates create a catch 22 situation :

  • The CU isn’t applicable until the SSU is installed and a full scan is ran.
  • A full scan won’t run outside of its normal schedule unless you reboot.
  • The SSU doesn’t trigger a reboot.

Servicing stack update SCCM’s ADR

We usually recommend keeping servers and workstations in separate ADR to prevent accidental patching of servers. The process remains the same as we demonstrate here.

  • Browse to Software Library/Software Updates/Automatic Deployment Rules and create a new ADR
Servicing stack update SCCM
  • Give a significant Name, target a test collection and select Create a new Software Update Group
Servicing stack update SCCM
  • Leave default
Servicing stack update SCCM
  • The Search Criteria is the most important part.
    • Products: select either workstation or server-side of OS.
      • SSU are available for all supported OS version, including LTSB/LTSC builds of Windows 10
    • Title: add Servicing Stack
      • In this case, we don’t have x86 or Itanium servers, so we excluded those.
    • Hit Preview to see the search criteria result
Servicing stack update SCCM
  • Search criteria result
Servicing stack update SCCM
  • For the Recurring schedule for this rule, we use the same as usual. SSU are released along with other cumulative updates, usually on Patch Tuesday
Servicing stack update SCCM
  • Plan the test phase deployment.
Servicing stack update SCCM
Planning SSU deployment schedule

Much like planning your global patching schedule for various phases(test, pilot, production), SSU should be delt the same way. The most important part is the timing!!!

In order for the cumulative update to be applied on a due date based on your deployment strategy, the servicing stack update must be installed on the computer AND a software update Scan must run after the SSU installation and before the deployment date of the cumulative updates.

To do so, we deploy the SSU at least 24 hours prior to the cumulative updates. To match this, the Software Update scan schedule is set to 1 day.

Careful planning based on your configuration is required to respect those requirements.

  • The Servicing stack update doesn’t require a reboot. But just in case, check the Suppress system restart. We also hide every notification as no user impact is expected. Be mindful of your maintenance windows in case you need an exemption from it.
Servicing stack update SCCM
  • Set alerts if desired
Servicing stack update SCCM
  • The deployment package can be your usual ones. No need for a separate package.
Servicing stack update SCCM
  • Download update from the internet
Servicing stack update SCCM
  • Leave the default for languages
Servicing stack update SCCM
  • We usually check If software updates are not available on DP, download from Microsoft Update as a backup solution
Servicing stack update SCCM
  • Summary
Servicing stack update SCCM

That’s it. The same can be done for workstations. Adding additional deployment to fit your need is key also. Remember, SSU must be applied and an update scan must have run before the cumulative updates deployment to succeed.

Will it always be required to applied SSU prior to the cumulative updates? So far it seems like it. Will Microsoft change the “rules” again in the future? Probably…

Happy updating!

[ratings]

Comments (16)

Ashokkumar

03.02.2020 AT 07:27 AM
Hi John, I just checked and found we haven't roll out the latest SSU. Now i am planning to do it but after seen your post came up some of the doubts. Please let me know if i can rollout now via SCCM with out ADR. Before going to be rollout what actions should i do for safer side. Thank you

ravi kiran

01.26.2020 AT 02:53 AM
Thank You Nice Articale

Pradeep Soni

11.07.2019 AT 12:10 PM
Hi John, Apart from SCCM, do you have idea on SSU been offered on systems that gets updates through Windows Update. I have my Win10 systems (builds 1703, 1803, 1809 & 1903) but everytime I scan for updates, the SSU patches doesn't offered. Any idea on this behavior ?

ngana2001

09.24.2019 AT 06:28 AM
I have a quick question to every other friend who works with SCCM. I am reaching out to seek your help and inputs on a solution. Requirement:  The requirement is to be able to manage workstations thru SCCM for organizations which have yet not been integrated with the current parent organizations. There is no trust relationship that exists between the parent forests of these companies (another forest). Also, the domain is not registered to the Parent company’s tenant.  Need help to cater a solution, based on any new advancement feature set available with SCCM (CMG with Public CA), that would allow us to manage https workstations. Solution what I think about:- 1. The current SCCM infra will be leveraged to implement CMG using Public CA. 2. Reason for using Public CA, - Workstation in a different domain will not trust the parent domain if using internal CA. 3. Considering I will install SCCM agent and certificate imported manually as all user (or) use the existing deployment solution in-place. Note:- According to Systemcenterdudes & Microsoft you don't even need to have your computers Hybrid-domain joined (or) Azure AD joined so long as you use a Public CA. https://docs.microsoft.com/en-us/sccm/core/clients/manage/cmg/certificates-for-cloud-management-gateway#bkmk_clientauth Here are is my question?  Is this a workable solution or not?  Machines that are not parent domain joined but joined to a different domain installing SCCM client & Certificate will authenticate and get discovered in SCCM.  Reason for this question - Workstations are no way registered with AAD or AD by any means. Thanks & Regards N.Ganapathy

Jonathan Lefebvre

09.24.2019 AT 07:45 AM
Hi NGana, please contact us at [email protected] thanks Jonathan

Greg

09.23.2019 AT 04:03 PM
For those asking about the application of SSU before CU/SU, there was the windows update for client OS's in August that had an SSU released in the same month's patching that the CU requiring it was released. Due to windows not ordering patches based on required/pre-requisite, it didn't install first. This meant that some devices had an issue with the winload/UEFI part of the boot process. So, yes, it's possible that sometimes MS will release an update within the month that requires the SSU to be deployed first. More a risk mitigation of something that will rarely happen, however, worth doing.

Greg

09.23.2019 AT 04:04 PM
FYI this was for Win7 / 2008 R2, so may not be a concern for a lot, however SSU's are also being applied to Win10/later server versions.

Jonathan Lefebvre

09.24.2019 AT 07:39 AM
Thanks Greg to share that info Jonathan

Dana Black

09.23.2019 AT 01:22 PM
I have been releasing SSU updates with a separate deployment from the other MS updates but have not forced them to deploy before the other updates. Have you seen issues when the SSU updates are not released first? I have not.

Jonathan Lefebvre

09.24.2019 AT 07:37 AM
Hi Dana, yes I did! mostly with servers. There was a limited maintenance window. At that time, the SSU installed correctly, no reboot was required. Then 24hours later, an update scan ran and only at that time the CUs appeared. This lead to a second maintenance window that was not originally planned which the business didn't like too much. Overall it's not a big deal, but knowing the behavior and have a standard deployment approach for the SSU, I think helps meet the expectation for a defined maintenance window with the business. Jonathan

Andrew Lukaszewski

09.23.2019 AT 10:33 AM
I've personally seen Software Center report that the a Servicing Stack Update is "Pending Restart" after installation (only installed that update). Had I not ticked the option to suppress reboot I am sure the machine would have been restarted. Also, I don't agree with the notion of setting client settings to perform a full scan every day, certainly not if you have many thousands of clients and only one central Software Update Point.

Jonathan Lefebvre

09.23.2019 AT 11:28 AM
Hi Andrew, thank you for your comment. I haven't seen the pending restart only for the SSU update, but I won't risk it without the checkbox to prevent auto-restart anyway. As for the Scan Schedule, I agree, it's a case by case. The important part is making sure a Scan occurs in between the SSU and CU deadline schedule. thanks Jonathan

John Cotter

09.23.2019 AT 10:20 AM
Hi, Have you ever come across a situation where the servicing stack update has caused an issue?

Jonathan Lefebvre

09.23.2019 AT 11:25 AM
Hi John, no, not so far. But like all other updates, I wouldn't bet against the odds of possible failure one day... thanks Jonathan

Madhu Sunke

09.23.2019 AT 08:00 AM
Will it always be required to applied SSU prior to the cumulative updates? No - not for all the months.

Jonathan Lefebvre

09.23.2019 AT 11:24 AM
Hi Madhu, possible that it's not always required, but I prefer a standardized solution, to always do same if possible. thanks Jonathan