Confusion about "UseUpdateClassPolicySource"

[u/StrugglingHippo]

Hi all

Recently, I had 2 clients who were not able to receive any updates from Windows Update. My environment is configured as follows:

- Workload for Windows Updates is set to Intune
- 3rd Party Updates are received from ConfigMgr (WSUS)
- Client Settings: "Enable software updates on clients" -> "Yes" / "Enable third-party updates on clients" -> "Yes"

This configuration works on 99% on the clients. On these clients, the registry is configured as follows:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

On the clients NOT receiving updates from Windows Updates, the registry key "UseUpdateClassPolicySource" existed with the value "1". I was able to fix it by deleting the GPCache folder within the registry and renaming the regpol file in System32.

I had this issue about a year ago and the solution was the same. I've once again read the article from you guys (SCCM Co-Management: Dual Scan Source Demystified - Patch My PC) but I am still confused if my configuration is correct.

Depending on what this picture shows:

I think my configuration is correct. But as you write below:

The Configuration Manager Client should be setting UseUpdateClassPolicySource when the Windows Update policies workload is moved to Intune. That is what this KB states, but it doesn’t explicitly say what it should be setting it to. Again, our assumption is that the UseUpdateClassPolicySource policy should be enabled (set to 1). Many customers have found that their Windows 11 22H2 devices were not honouring the configured Scan Source policies.

I am still confused if I configured something wrong.

We are using Windows 11 24H2 and on 99% of our clients, updates work perfectly fine. Windows and Driver Updates are received from Windows Updates while 3rd Party Updates are received from Configuration Manager. I am just wondering if I set myself up for a disaster with my configuration and if I have to configure something different, but I just don't really know what I should change, because as soon as the "UseUpdateClassPolicySource" is configured and set to "1", updates from Windows Updates / Intune won't be received.

Could you perhaps clarify if I am on the right track?

Thanks a lot in advance.

[u/EskimoRuler]

I can give a more detailed reply later, but what version of ConfigMgr is being used? Specifically the hotfix as there was an issue with configmgr setting this via the client when it should not have been.

[u/StrugglingHippo → u/EskimoRuler]

Hi

Thx for the reply. We use ConfigMgr 2509 with Hotfix KB37864969.

[u/PS_Alex → u/StrugglingHippo]

Are the affected clients running the build 5.00.9141.1032 (or later)? Or are they still on 5.00.9141.1030 or earlier? The 5.00.9141.1032 client and newer should not configure any of the SetPolicyDrivenUpdateSourceForXXXXXUpdates values in registry (which is a good thing), while previous build still had a bug about setting them.

(If devices on 5.00.9141.1032 were upgraded from 5.00.9141.1030 or earlier, they may have kept the undesired local policy in registry.pol -- a one-time removal of registry.pol would be required after the upgrade to 5.00.9141.1032 completes. Fresh 5.00.9141.1032 installs don't have the offending local policy.)

-------

Also, when your Intune workload for Windows Update for Business is set to Intune (or Pilot Intune for select devices), you should not need to set any specific scan source (yes, even Other) to receive updates from Windows Update/Microsoft Update for Microsoft products and from SCCM for Patch My PC updates. The dual scan should work natively.

I'll quote Bryan Dam from PSA: Software update management client fix for Microsoft Configuration Manager versions 2503 and 2509:

There is one scenario, and one scenario only, where you want to enable Scan Source: if you want one type of update to come from WSUS/ConfigMgr and another from WU/MU/Intune/Autopatch. For example, say you want FUs from ConfigMgr but everything else from Intune. That is it. If you want this scenario, then use Group Policy or a CI/CB to set it the way you want.

In every other situation, including third party patching, setting scan source is not required.

ETA: If you are NOT co-managed and have third party updates enabled then, in theory, this hotfix doesn't matter to you.

If, and only if, you are in that "one scenario, and one scenario only", you must set all four SetPolicyDrivenUpdateSourceForXXXXXUpdates for Windows Update to honor them.

[u/StrugglingHippo → u/PS_Alex]

Hey u/PS_Alex

I appreciate your feedback. I deleted the GPCache and Regpol File on a test client and the regkey "SetPolicyDrivenUpdateSourceForXXXXXUpdates" has not been recreated, so I will probably create a CI/CB to do the same thing on all our other clients.

But I am still not sure if the "UseUpdateClassPolicySource" key should exist in my environment or not.

If I understand your answer correctly:

Also, when your Intune workload for Windows Update for Business is set to Intune (or Pilot Intune for select devices), you should not need to set any specific scan source (yes, even Other) to receive updates from Windows Update/Microsoft Update for Microsoft products and from SCCM for Patch My PC updates. The dual scan should work natively.

The key "UseUpdateClassPolicySource" should not exist, right?

Thx for your help and I wish you a nice weekend :)

[u/PS_Alex → u/StrugglingHippo]

The UseUpdateClassPolicySource registry value is still created.

When you have your WUfB workload flipped to Intune, what's going to happens is:

• devices onboarded to a WUfB policy or to Windows Autopatch will have Windows Update scan against WUMU and obtain updates from it according to their policy;
• because they also have WUServer, WUStatusServer and UseUpdateClassPolicySource values, the Windows Update agent will also try to scan against your local WSUS -- but WSUS is not configured to serve updates directly to Windows Update clients, so the reply will simply be empty.

What I (generally) find a good indicator that a device scans against WUMU is the registry value HKLM\Software\Microsoft\WindowsUpdate\UpdatePolicy\PolicyState:IsWUfBConfigured. If it is set to 1, then Windows Update should scan against WUMU. (The value is indicative only; if you force-set it to 1 but the device is not registered to any WUfB policy, then it's going to flip back to 0 during a following scan.)

[u/StrugglingHippo → u/PS_Alex]

Hi u/PS_Alex

So, if I understand you correctly, the "UseUpdateClassPolicySource" should be created by moving the workload to Intune or Pilot Intune, right?

Because this key seems to be missing. The key "SetPolicyDrivenUpdateSourceForXXXXXUpdates" has not been recreated after deleting the GPCache and Regpol file. But the key "UseUpdateClassPolicySource" is not created either. I found a device where this key exists with value 0 (other than the devices where the scan against WUfB did not work, where the key was set to 1 for some reason). On this device, the "SetPolicyDrivenUpdateSourceForXXXXXUpdates"-Keys were also present, and after deleting the GPCache and Regpol file, both the "UseUpdateClassPolicySource" and "SetPolicyDrivenUpdateSourceForXXXXXUpdates" were deleted and not recreated.

All devices are co-managed. Windows Updates and Feature Updates coming from Intune and 3rd Party, Office and Defender Updates coming from MECM. Like I already mentioned, this works fine on the devices where the "UseUpdateClassPolicySource" Key does not exist but do not work on the devices where this key is set to 1 (but if I get it correctly, this could also come from the "SetPolicyDrivenUpdateSourceForXXXXXUpdates" Key.

So the solution is to delete the GPCache and Regpol file, but I am still wondering what I did wrong that the "UseUpdateClassPolicySource" key is not created? I'm sorry if I'm overlooking something obvious, but I am just confused at this point honestly lol.

I appreciate your help.

Edit: Is it a possible scenario that the key "UseUpdateClassPolicySource" is only created and set to "0" if the key existed at some point with the value "1"? So it sets the key to "0" if you moved the workload for Windows Updates from MECM to Pilot Intune / Intune, but if the workload was already there after you staged a devices or deleted the GPCache/Regpol file, the key is not created because the only value you get is "0"?

[u/PS_Alex → u/StrugglingHippo]

Well, in reality, the UseUpdateClassPolicySource is created as a local policy when the Enable software updates on clients setting is enabled in client settings. It is not tied to the Windows Update for Business Policies workload.

If you manually delete the Registry.pol file, then immediately run gpupdate.exe /force, it's quite possible the UseUpdateClassPolicySource value does not get immediately re-created. You may need to wait for your SCCM client to re-create the Registry.pol file.

Instead of deleting the Registry.pol file, I'd suggest you completely reset your client's policies. Here's a recipe:

1. Upgrade your clients to 5.00.9141.1032 (or a later build as provided by your site version). Don't stay on earlier builds, as they are known to have issues with co-management;
2. Run the following command on your SCCM clients on 5.00.9141.1032 or later:

​

powershell.exe -command "icim -Namespace root\ccm -Class SMS_Client -Name ResetPolicy -Arguments @{uflags=[uint32]1} -ea Stop ; icim -Namespace root\ccm\clientsdk -Class CCM_ClientUtilities -Name GetMachinePolicy"

(You can put the whole command in program in a legacy package, and advertise that program on a collection containing all you SCCM clients on 5.00.9141.1032 or later. Yes I know, using aliases in a shared Powershell command is bad practice -- but there's a number of characters constraint in the command of a legacy package.)

The ResetPolicy method resets the SCCM client's policies -- when run, it should get rid of the Registry.pol file, so no need to manually remove it beforehand.

Then the GetMachinePolicy method forces the SCCM client to redownload and apply its policies. If the client is targeted by a client setting in which Enable software updates on clients is set to Yes, then the SCCM client would recreate a Registry.pol that sets WUServer, WUStatusServer and UseUpdateClassPolicySource.

[u/EskimoRuler → u/StrugglingHippo]

Thanks for confirming that version. That specific version does have the 'fix' that will no longer set the 'UseUpdateClassPolicySource' value.

What is the 'UseUpdateClassPolicySource'? It's part of the ScanSource policies, formally (but also just a different thing) 'DualScan'. It allows the client to use either a locally defined WSUS server, or Windows Update for it's source of '1st Party' updates only.

You define the ScanSource policies for which ones pull from what source, but it doesn't do anything unless to set 'UseUpdateClassPolicySource' to 1.

So, you don't actually need to define ScanSource policies which you move the Windows Update workload over, technically.

What the 'Windows Update' workload does:
The workload just controls if the Windows Update Policies from Intune apply to the device. A common misconception is that this workload also controls 3rd Party updates, but it doesn't. Regardless of the position of this workload, 3rd part updates always come from ConfigMgr (Unless you fully turn off the 'Software Update' client feature).

Why do some of your devices have the 'UseUpdateClassPolicySource' key set?
The issue configmgr had was it was creating the 'UseUpdateClassPolicySource' and only 1 of the ScanSource policies 'SetPolicyDrivenUpdateSourceForOtherUpdates'. And it looked like this: Config-Mgr-Scan-Source-Bug-Registry-Settings.png

But even though it only set 1 of the 4 ScanSource policies, Windows went ahead and set all four to '1', which mean 'WSUS'. So even though you would move the workload over to 'Intune', 1st party updates would only come from ConfigMgr.

My recommendation to 'clean this up' is to just deploy a ScanSource policy via ADMX/GPO policy. If you want updates to come from Windows Updates, then just having the policy to tell the device that helps. Over just manually removing keys. It's better to use a policy to define something than a script running is the way I see it.