Hi all,

we are experiencing an issue on approximately 2% of our devices after they upgraded to Windows 11 24H2 via Windows Update for Business (WUfB). We had a very similar issue about a year ago after moving the Windows Update workload from SCCM to Intune.

On the affected devices, the following registry value is present:

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseUpdateClassPolicySource

with the value set to 1.

As a result, these devices do not receive updates via WUfB because they are still using Configuration Manager as the update source. On all unaffected devices, this registry value does not exist.

I was able to resolve the issue, but I am wondering what could be causing it in the first place. The Co-Management capabilities are configured correctly, and there is no GPO explicitly configuring this registry value. The Site Version is 5.0.9141.1000 (Version 2509) and the Configuration Manager version on the clients is 5.00.9141.1032.

The workaround/fix I found is as follows:

1. Delete the following registry keys:
   • HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet001\WindowsUpdate
   • HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet002\WindowsUpdate
2. Rename the following file:
   • C:\Windows\System32\GroupPolicy\Machine\Registry.pol
3. Reinstall the CCM Agent.

After performing these steps, the UseUpdateClassPolicySource registry value under:

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

is no longer present, and the device starts receiving updates via WUfB again.

Has anyone experienced a similar issue or have any idea what could be causing UseUpdateClassPolicySource to be created on only a subset of devices after upgrading to 24H2? The upgrade to 24H2 was distributed over Intune, so it seems like it worked until the feature update, and then for some reason created this key.

In ConfigMgr, we use the Lenovo third party software updates catalog (v3) for driver/BIOS updates. I've then use a saved search for Vendor=Lenovo, Not Expired or Superseded, and Required by 1 or more machines, and right click on the results and select Publish Third-Party Software Update Content. After the next Software Update Point sync, I can deploy those to a software update group and download them to a deployment package which gets distributed to distribution points. Easy enough.

What I didn't realize until now was that simply publishing an update not only downloads additional publishing information about the updates, it also downloads the actual update payload to WsusContent and UpdateServicesPackages folders on the WSUS server. Further, the annoying thing about the Lenovo third party catalog is that newly added models are checked by default, meaning if I haven't looked at the list in a couple months, I might be syncing in 5 or 6 new models worth of updates into the WSUS database that we'll never use.

What I also didn't realize until now was that if I simply remove the "Required by 1 or more machines" filter from my search, I have over 8000 Lenovo updates, instead of the ~250 that are actually required. I do have all 3 automatic WSUS maintenance tasks enabled in ConfigMgr's Software Update Point settings, but when the Lenovo updates are rarely superseded or expired, nothing actually gets removed via those maintenance tasks.

I see we can use Patch My PC's Modify Published Updates tool without a license, but this would still be a problem because the tool doesn't have any way of knowing A, which machine model a third party update is for, or B, whether or not that update is required by any devices. So without comparing update IDs and doing them one at a time, I don't have any way of knowing which Lenovo updates are still needed from within the Modify Published Updates wizard.

So... how is everyone keeping the WSUS database and their list of third party drivers (from either Lenovo, or Dell/HP) clean? Are you still using this and enjoying the visibility of the which machines need which updates, the centralized control and monitoring of deployments, and saving your WAN links because the updates are on DPs instead of pulling from the internet? Or have you said "nope, this is a pain" and gone to Lenovo Commercial Vantage/GPOs (or other vendor direct tool) and are dealing with not having the visibility of when updates are performed and WAN links being slightly saturated?

I'm trying to change the desktop wallpaper for all users on a workgroup system using an OSD Task Sequence setup which installs the OS, runs a .cmd file that loads the default user hive, plugs in the reg keys for the new wallpaper location, and assuming this is a valid way to handle this...any NEW user that logs in gets their user hive from the default user account. I check post build and only the default hive has been changed, new local users that log in do not get the changed reg key. What am I doing wrong here?

REM Configure Default User profile

reg load HKU\DefUser C:\Users\Default\NTUSER.DAT

reg add "HKU\DefUser\Control Panel\Desktop" /v Wallpaper /t REG_SZ /d "C:\Lear\Wallpaper\WARNING1024.jpg" /f

reg add "HKU\DefUser\Control Panel\Desktop" /v WallpaperStyle /t REG_SZ /d 3 /f

reg add "HKU\DefUser\Control Panel\Desktop" /v TileWallpaper /t REG_SZ /d 0 /f

I constantly see appx packages being flagged is vulnerable on our machines. What's the best way to patch these apps?

A lot of our workstations are shared so multiple users will log into them and that that might be contributing to the issue because stale user profiles never update the old appx packages.

What I've been doing is creating PSADT scripts and removing old appx entries and installing the updated version. Am I going about this the right way? Would PatchMyPC be helpful in a case like this?

We have a recurring problem in our environment. The Configuration Manager Health Evaluation task goes in to Queued status and never runs. A few days later, the device shows up in Active Clients that failed client check.

I can manually run CCMeval.exe and that temporarily solves the failed client check problem but it returns a few days later.

I can get the schedule task back to Ready status, but when the task starts, it immediately goes back to Queued status.

This is intermittent, happens on all OSs in our environment randomly throughout the fleet of endpoints.

Does this sound familiar to anyone?

In our environment there are few devices not part of any boundaries but we are struggling to identify the exact list of devices that are not covered under any boundary.

For a single device I can manually check the IP against our existing boundaries

But for all devices, is there any way to identify the list of devices that are not part of any boundary in SCCM?

Any suggestions would be appreciated 👍