June 15th 1909 SSU incorrectly flagged as "no reboot required"

We're running ZENworks 2017 Update 4.

On June 15th, 2021, there was released KB5003974. It's a servicing-stack update for Windows 10 version 1909 - the second such SSU released in a single month, which in my experience is highly unusual.

Unlike every other SSU I've ever seen, this one is flagged as "reboot required: no" (and also "supports uninstall: no", which is less relevant).

I did not specifically check on that detail before approving this update for deployment via patch policies. Now, I'm seeing that many computers across the organization are being rebooted automatically in the middle of the day (in alignment with the patch-policy schedule), without prompting the user; this is interrupting work in a significant way.

What I think is happening is that because the patch is not flagged as "reboot required" in ZPM, the remediation engine does not pass in the flags to disable reboot, and so the SSU applicator proceeds with its default behavior, which is to reboot automatically.

Is that analysis likely correct?

Has anyone else been encountering such issues?

Has this incorrect "reboot required: no" flag been fixed?

What can I do to be able to deploy this SSU without causing these reboots?

I suspect that if Lumension has resolved the problem upstream, then I wouldn't necessarily see it right away, but by deleting the SSU from my ZPM instance and running a "check for available patches" I might be able to get the corrected version to show up. However, I'm not positive about what would happen even in that scenario, or even about what would happen if they haven't changed the patch upstream - and much less certain that they even have fixed the issue to begin with.

Parents
  • Verified Answer

    Yes, the issue has been reported to our Content Provider.

    Work-Around is don't put it into a policy and deploy it stand-alone.  (Sorry not great answer).

    Hopefully our provider will get the June SSU fixed sooner rather than later.

  • Thanks for the prompt response!

    Assuming they do fix this, most likely by releasing an updated version of this patch to their availability channels, do you know what behavior I can expect to see on my end?

    One possibility would be that they would just have the new patch supersede this one; that would mean I'd have two patches with the same apparent name, release date, and contents, one of which supersedes the other, which wouldn't be ideal.

    Another would be that they would just update the canonical version of this patch. In that case, one of two things might happen: either I'd see the new version show up in my patch feed, near-seamlessly replacing the one I already have, or nothing would seem to happen on my end at all, and I'd have to take separate/special action to get the new patch to show up - most likely, deleting the existing patch and running a "check for available patches" action.

    I imagine that there might be other possibilities I'm not thinking of.

  • to be more specific, use the remediation wizard to create the standalone deployment.  the reboot only occurs when there is more than one patch (example patch policy) because the ssu doesn't chain.  

    sometimes the do just replace content with blind rev.  since the vendor does the official supserseding it's unusual that they would supersed it but it's possible. asssuming it's a blind rev you would need to re-cache if/when it gets fixed/

Reply
  • to be more specific, use the remediation wizard to create the standalone deployment.  the reboot only occurs when there is more than one patch (example patch policy) because the ssu doesn't chain.  

    sometimes the do just replace content with blind rev.  since the vendor does the official supserseding it's unusual that they would supersed it but it's possible. asssuming it's a blind rev you would need to re-cache if/when it gets fixed/

Children
No Data