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.

  • That would have been the solution I'd probably have settled on on my own, except that the "See Notes" on the patch from the ZPM patch list state to apply it only on computers which are experiencing the problem.

    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.
  • Grmph. The 1909 version of the workaround patch for 2021-03 is repeatedly failing to cache; the 1809 one (which, oddly, is marked as having been released on the same February date as the previous 2021-02 version) cached fine. (I haven't yet identified a patch we might want to deploy which isn't already cached, to test whether other patches are also failing to cache.) Is there any known issue there at the moment?
  • A Co-worker reported an issue with 1809 on Wednesday......

  • FWIW, the ZPM primary novell-zenworks-loader_stdout.log reports that the download of the PLP is failing with 403 from the novell.cdn.heatsoftware.com server. That sounds like a problem on the provider end.
  • Yea, definitely a problem on the backend.  Workaround 1909 will not download but all others did.



  • 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.

  • Looks like the 64bit 1909 is now downloading for me.....

  • Yep, it's doing so for me as well. I checked earlier this afternoon and it still wasn't, but re-checking after I got your notification I see that now it's cached normally.

    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!