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.

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


    Be sure to "Like" My (and a few others) Cool Solutions below! 


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

  • We got a fix to the issue.  I have confirmed that the content was replaced but not yet tested the install due to not having a Windows 10 that is applicable available to me.  However if your would like to confirm the fix before I’m able to get to it:


    1. Update the subscription – this should have happened as the nightly schedule will have run, but if for any reason the service was disabled or server down, just make sure you update subscription.
    2. You can confirm in database query that the patch content has changed by running this query:
      select * from patchsignature where name like '%KB5003974%';
    3. In the above query the two patches should now have the following MD5 values:
      8403a5a7b567b752b8cd387691d68286 "2021-06 Servicing Stack Update for Windows 10 Version 1909 x64 (KB5003974)"
      ddc19ec3c3a835c95b6650acdafba116 "2021-06 Servicing Stack Update for Windows 10 Version 1909 for x86 -based Systems (KB5003974)"
    4. Run the Discover Available Updates (DAU) on the test device or let it run on schedule.
    5. You can confirm that the newer plr is on the workstation by running this:
      CertUtil -hashfile "2021-06 Servicing Stack Update for Windows 10 Version 1909 x64 (KB5003974).pls" MD5
      result should be:
      MD5 hash of 2021-06 Servicing Stack Update for Windows 10 Version 1909 x64 (KB5003974).pls: 8403a5a7b567b752b8cd387691d68286
    6. Bring up the patch in ZCC and select Action / Update Cache.  This is necessary to rebuild the patch bundle with the latest files.
    7. Use the deployment wizard to deploy the patch to the test workstation.  This shouldn’t reboot the device since it runs standalone even with the problem.  But in this case when you look at the event log for WSH event you should see the /norestart on the install command line.