Since the release of August’s cumulative updates, I’ve heard from several Configuration Manager (ConfigMgr) system administrators who report that many of their Windows 11 22H2 devices do not detect them as applicable. An even smaller group experienced the same issue on Windows 10 and Windows 11 22H1. After some initial testing, it was clear that this wasn’t a global issue facing every deployment, which suggested that this problem was triggered by something environmental. With the help of several community members, I think I’ve figured it out, so if you are similarly impacted, read on.
The Tale Of Two Bugs
The problem administrators were facing was relatively simple: they had active deployments for Windows 11 22H2’s August cumulative update (KB5029263), the devices received the policy, the devices needed the update, but it would not be offered to the device in Software Center. We quickly discovered that if July’s cumulative update (KB5028185) were uninstalled, then August’s cumulative update would be detected and offered to the device. I’m this calling Bug #1: some change was made in July’s cumulative update leading to a change in update detection. If this is true, then this won’t just impact detecting August’s updates but all future updates. Further, since updates are cumulative, installing August’s cumulative update won’t fix the problem, as you won’t detect September’s cumulative update either. That is to say, if you are impacted then you have to solve this issue now otherwise it will keep happening.
In working through this issue, I re-read a part of the Windows Update for Business (WUfB) docs with a new set of eyes: “If you configure a WSUS server and deferral policies: All of your updates will come from Windows Update unless you specify the scan source policy.” For those not familiar, this exact situation is what kicked off the Dual Scan furor years ago: by setting a WUfB deferral for feature or quality updates, you would enable an undocumented (at the time) feature called Dual Scan. Dual Scan was designed to redirect the Windows Update Agent (WUA) to Windows Update (WU) for all Microsoft updates while still using Windows Server Update Services (WSUS) and ConfigMgr for 3rd party patches. These organizations were caught off guard as their devices started scanning against WU instead of WSUS/ConfigMgr, and things went poorly. In some cases, that meant Feature Updates raining down upon them uncontrollably. It was good times.
Windows 11 has never had Dual Scan and instead relies on the evolution of Dual Scan called Scan Source (docs). However, it seems clear that the July CU for Windows 11 22H2 has introduced functionality that mimics the original Dual Scan behavior as described in the documentation above. After July’s CU, any device configured with a WUfB deferral policy and a WSUS server will filter out the updates WSUS offers. If you extract the WindowsUpdate.log file, you will see a whole bunch of entries like the following:
The screenshot above shows that the WUA is aware of the WSUS updates but is ignoring them for ‘reasons.’ The screenshot below shows my test device with July’s CU installed, a WUfB Quality Update Deferral enabled and set to 0 day, and Software Center showing zero updates applicable:
If I uninstall July’s cumulative update on the same machine, then Software Center will offer August’s cumulative update after a scan an update deployment evaluation:
That’s Only One Bug!
Quite right, Count von Count. Good counting! The second bug is a longer-standing issue with ConfigMgr. While the real answer is more nuanced, a helpful rule of thumb for setting Windows Update GPO when using ConfigMgr is to just not do that. This rule of thumb is because the ConfigMgr agent will use Local (Group) Policy to configure the WUA to point at the Software Update Point (WSUS), and conflicting GPOs can lead to undesirable results. In recent versions of ConfigMgr, the client has begun configuring the Scan Source policies by setting the SetPolicyDrivenUpdateSourceFor*Updates values to 1 (WSUS). However, it does not set the UseUpdateClassPolicySource value that actually enables Scan Source. That is: Scan Source policies are configured but not enabled. This is a known issue that hopefully is fixed in the next release of ConfigMgr:
This is super unfortunate because if the ConfigMgr agent set that key correctly and thus actually enabled Scan Source, then this whole problem wouldn’t have happened. If we look at the same WUfB docs, we see why: “If you configure a WSUS server and the scan source policy: All of your updates will come from the source chosen in the scan source policy.” That’s precisely what we want but what ConfigMgr tries and currently fails to do.
Ok, What Do?! How Can I Fix This?
There are two reasonably straightforward fixes here, and while either fix should work independently, I would encourage you to do both.
Stop Configuring WUfB If You’re Not Using WUfB
If you intend for updates to be managed by ConfigMgr, then stop setting WUfB deferrals. This is the second time doing so has created significant issues, so just stop doing it. Doubly so since a WUfB deferral should have no purpose or impact when you’re managing updates with ConfigMgr. In my testing, disabling the WUfB deferral policy allows the August cumulative update to appear after a scan and update deployment evaluation:
Note: Other Windows Update policies may also trigger this behavior. I only tested WUfB quality update deferrals. YMMV.
Enable Scan Source Policies
The second, more permanent fix is to ensure the UseUpdateClassPolicySource is being set. I have confirmed with the Windows Update team that Scan Source policies are the intended method for controlling the update source. One option for doing so is by creating a Group Policy to configure and enable the ‘Specify source service for specific classes of Windows Update’ (docs) policy and configuring each update type to point at WSUS:
While this works in testing, I’m not a fan of setting GPO where ConfigMgr is supposed to be using Local (Group) Policy. As stated above, this can create policy conflicts that lead to undesirable results. In some cases, the ConfigMgr agent will refuse to scan until the policy conflict is resolved which leaves devices unpatched. Alternatively, I suggest creating a Compliance Item that ensures that the registry value HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAUUseUpdateClassPolicySource exists and is set to 1:
This method should be considered a temporary workaround until a release of ConfigMgr properly sets this value. At that point, this compliance item can be retired, and we can all just go on living our best our lives.
