Pitfall: Windows clients install updates past WSUS

Windows[German]There is occasional feedback here on the German and English blogs from administrators who use WSUS to control the distribution of updates to Windows clients, and complain that clients have surprisingly pulled updates past WSUS and installed them. The cause may be a recommended group policy from Microsoft's baseline security templates. Here is some information on this issue, which a reader comment brought to my attention.


Updates pulled past WSUS

In many companies, the distribution of updates to Windows clients is managed by WSUS. Administrators set up Windows clients to query Windows Server Update Services (WSUS) on a central server for pending updates. At the same time, administrators release the updates that are scheduled for the clients.

In theory, this should allow control over which updates are distributed to the clients in the organization. In particular, problematic updates can be blocked in this way and postponed or excluded from distribution and installation. In practice, however, it happens again and again that administrators find out that the clients have pulled the updates past WSUS and installed them. There is a German comment from reader Patchie, received on the March 2022 patchday.

We use WSUS for KB distribution.
Today we were horrified to find that this KB was automatically deployed past all rules. Does anyone know any advice?

It is not the only comment of this kind left here on the blog regarding this. This means that administrators in such environments no longer have control over what updates are installed by clients.

Cause #1: Dual Scan is active

My first guess in this context was that the Dual Scan option might be enabled on the Windows clients. For example, I had mentioned this issue in the blog post Windows 10 October Update (Version 1809): (Upgrade-) FAQ pointed out this issue.

Microsoft also addressed the issue of Update/DisableDualScan for Windows 10/11 (Pro and above) in this support document. In addition, there is this Microsoft post from 2017 on the topic. There is a policy under Windows Components – Windows Update that can be used to disable Dual Scan. The English name of the policy is Do not allow update deferral policies to cause scans against Windows Update. German blog reader John Ripper pointed out the issue in this comment back in 2017.


Microsoft also published another post on the topic in 2017 – on Technet, this one discusses the issue with pulling updates on WSUS/SCCM. 

Cause #2: Policy conflict

But then German blog reader Patchie mentioned above wrote that Dual Scan was disabled on his clients. So it must be something else that is causing problems. In this context, German blog reader Verena pointed out another issue in this comment (thanks for pointing it out).


I can say what it was for us, the policy line "Configure registry policy processing" was active in our case and caused this. This is included in the recommended Microsoft security baseline, so we had implemented it. However, MS now recommends setting this to "not configured".

Every time the policies are rewritten, the keys are not available for a short time. If in this time a scan from the update comes, the client loads past the wsus, even if the policies are then already active again.

It took us a long time to find out why our clients sometimes patched past WSUS.

Disadvantage if the policy is set to not configured: If an administrative user fiddles with the policy, it will not be overwritten automatically.

Maybe this hint from Verena helps one or the other affected person.

Cookies helps to fund this blog: Cookie settings

This entry was posted in issue, Update, Windows and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *