February 2021 Servicing Stack Update Recommendation
If anyone is having any issues deploying patches with ZPM, it is recommended to deploy the Feb 2021 Servicing Stack Update by a non-ZPM Means. This could be through standard ZCM Bundle.
There are some issues with specific prior Servicing Stacks that can interfere with even updating the Servicing Stack through traditional Windows Update processes.
ZENworks Engineering is also examining the matter to see if ZPM could potentially self resolve the current issue and similar future issues, but it cannot at this moment.
Note: CBS.LOG files may show something similar to the following, even when attempting to update the Servicing Stack.
2021-01-24 11:16:31, Info CBS Failed to initialize internal package [HRESULT = 0x800f0823 - CBS_E_NEW_SERVICING_STACK_REQUIRED]
2021-01-24 11:16:31, Info CBS Failed to create windows update package [HRESULT = 0x800f0823 -CBS_E_NEW_SERVICING_STACK_REQUIRED]
I see that there are now available "workaround" SSU patches in ZPM, of a "Software Installer" type rather than the more usual "Critical" type. I understand that these apply what is essentially the same update as the regular SSU patch, they just do their detection differently, so that they will appear as applicable even when the SSU is causing most detection to be broken. I have tested deploying one to an affected computer, and it has indeed restored detection to work properly, on the next scan following the first reboot after the deployment.
What is the recommendation for how to handle deploying this type of patch vs. the "normal" one, in an environment where some computers are affected and others are not?
The "workaround" patches recommend to deploy them only to computers which are experiencing the CBS.log update-detection errors. However, in an even slightly large organization, it is not practical to examine computers en masse to determine which ones are and are not exhibiting these log messages - and in cases where a large fraction of computers, out of a total of hundreds or thousands, fall on each side of that line, it's even less practical to restrict deployment of each patch type to only the machines which are or not affected.
How would deployment be expected to behave, on an unaffected computer, if we set our SSU patch policy to deploy both the regular SSU and the latest "workaround" SSU? Would it Just Work (at the cost of added network, server, and system load), or would it have a reasonable potential to misbehave?
My semi-intuitive suspicion is that it would work basically the same way as if the policy deploys only the regular SSU but the patch policy schedule triggers again after the first application of the policy and before the next reboot (something which happens routinely in our environment, since we have the policy schedule triggering up to three times a day), but I don't have a clear enough picture of the situation to be sure about that.
Both should not cause an issue or even simpler just assign the work-around SSU. It is the same exact patch from MS. It is just how it is called.
I'm guessing that that text was probably written with the expectation that most environments will have the other patch already in deployment, to one degree or another, and the intention to avoid winding up with one machine getting both?
Twiddling our SSU policy to just do the workaround SSU for this cycle or so will be a bit fiddly, but should be viable.
Presuming you have the Full ZCM, as a temporary fix, you could download the SSU from MS and deploy as a traditional bundle. The nice thing is it has built-in system requirements, so if it is not needed it will not install.
I'll adjust my SSU patch policy accordingly. Thanks for following up on this, at least to the extent of notifying us that things had changed!