Microsoft Servicing Stack Updates and Patch Policies

Hi All,

First poster and only 3 months into working with ZCC, specifically Patch Management and Patch Policies so please forgive me if I'm missing something obvious with my question below. Currently running ZCC 2017.3 patching both a WIN7 and WIN10 environment.

I'm taking over patch management which until now, was using manual remediation to patch 1500+ machines on a monthly basis :confused: I've done a ton of reading and am actively testing the 'migration' over to using Patch Policies - which seem to work great and I'm seeing positive results!

QUESTION: I am curious how any of you handle SSU/Service Stack Updates as they come out from Microsoft. Since SSUs should be installed prior to any other updates, how do you force that to happen? Do you use a separate remediation bundle? Are Patch Policies automatically configured to install the SSU first?

I couldn't find any helpful documentation on this and I only found two posts mentioning Service Stacks on this site and neither were related specifically to patching.

Any thoughts are greatly appreciated!

ZCC 2017.3 Primary Administrator for ZPM
3 Replies
Micro Focus Expert
Micro Focus Expert

Re: Microsoft Servicing Stack Updates and Patch Policies


Sorry for the Delay.....
Yes....Servicing Stack Updates can be a little tricky...

#1 - There is not any built-in way to Order the Patches so the Servicing Stack Update Applies 1st.
#2 - If a Patch Policy Contains both the "Servicing Stack Update" patch and other patches, it may generate a spurious reboot.
The reason for this is a little odd....it is the fact that the "Servicing Stack Update", while it does not require a reboot....it does not support being part of patch chaining as nearly all MS patches do.
As a Result, when included in a patch policy with other patches they may deploy in a fashion similar to...

Patch1 called with chaining and reboot suppression
Patch2 called with chaining and reboot suppression
Servicing Patch which does not support chaining
Patch3 called with chaining and reboot suppression - UH OH....

Since the "Chaining" was Broken, Windows now forces a reboot so it can start the next chain.


However, there are ways around this and I have not played with all permutations, but here is one thing I did successfully in my lab.

What I was able to do in my lab was build 2 different Patch Policies.
1 – Servicing Stack Only Policy.
2 – Non-Servicing Stack Patch Policy. (Everything Else)

I Set a System Requirement on the Servicing Stack Policy for following Registry Key to exist:
I Set a System Requirement for the Non-Servicing Stack Patch Policy for the following Registry key to NOT exist.

Next I created a bundle that did the following…..
Create Registry Key - – HKEY_LOCAL_MACHINE\SOFTWARE\ZPM,Apply_ServicingStack
Run “zac pap” – Wait to Finish
Delete Registry Key - – HKEY_LOCAL_MACHINE\SOFTWARE\ZPM,Apply_ServicingStack
Run “zac pap” – Wait to Finish.

The result is the 1st time ZAC pap runs, it runs ONLY the Servicing Policy
The 2nd time it runs, it Only runs the Non-Servicing Stack Policy.

There are a number of permutations on this……
#1 – You could use this to ONLY deploy the Servicing Stack and remove the 2nd “zac pap”
Non-Servicing Updates would run as Normal, since the SYSREQ for that policy would normally pass.

#2 – I would probably use a “Script” action in production to hide the command prompts, but for testing having visible “zac pap” output is quite useful.

#3 – It may require a change in Reboot Prompt Settings, since we do not want a reboot prompt for “Servicing Stack Updates” since they are rebootless updates.
This is why a Single Bundle may be better and use traditional Bundle Reboot and Message Features to handle reboots just like every other software installer that is not patch.

#4 – Scrap the Bundle and System Requirements Completely…They will likely still run perfectly fine, but the ideal o of “Servicing 1st and then “Other Patches” could not be assured. As a result the other patches may additional patch policy processing cycle to complete…….
Micro Focus Expert
Micro Focus Expert

Re: Microsoft Servicing Stack Updates and Patch Policies

Note: Discussions around "Servicing Stack Updates" are currently on-going and their handling may be slicker in the future, but it appears that they operate slightly different than nearly all prior MS Windows patches so updating handling methods may tweaked at some point.

Re: Microsoft Servicing Stack Updates and Patch Policies

Hi Craig,

Apparently I need to figure out how to use this forum a wee bit better. I didn't get the notice you had replied until now.

Since I posted this question, I have successfully implemented option #4 that you had listed. Essentially, it does require multiple reboots and/or scheduled Zac Pap's but things seem to be working fine and users are getting used to having a "patch week" instead of a "patch day". From testing, it seems that the dependency of specific SSU's listed on WIN10 cumulative updates are working as they should and if there is a required SSU, that will get installed first (providing it's included in the policy, which it is) and then the next time Zac Pap is run (in our case once a day, Wed-Fri on that site locations patch week) the cumulative update will run.

This has been working as expected for ~4 months now without issue and I believe the simplicity of it makes it work well. Thankfully the dependencies are adhered to in a reliable fashion.

Thanks again for taking the time to respond and provide your opinion on various workable options! It's greatly appreciated.

ZCC 2017.3 Primary Administrator for ZPM
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.