Audit and Fix Windows Update Registry Keys in a Co-management Scenario
Recently I’ve been working on enrolling devices into co-management and piloting the Windows Updates workload in Intune. The devices I’ve been working with have been compromised of various manufacturers and models with varying life spans - some for years, some much newer. Some had specific Group Policies configured (Automatic Updates = disabled, in order to stop Dual Scan, for example).
After a round of patches I noticed that some devices, even though their Windows Update Ring had been successfully applied, were not being patched!
This must have triggered Bryan Dam’s spidey-sense because not long after I noticed, he started a very fruitful discussion on Twitter.
I recently uncovered a blog post from Arnab Mitra on the Microsoft Tech Community that provides a great explanation of how a device itself should be configured you migrate the Windows Update workload to Intune. I highly recommend reading this post for a better understanding of Co-Management of Windows Updates Workloads
In the post, it’s stated that a policy update will enroll the device into co-management and set some additional registry keys for you - enabling Dual Scan and allowing devices to connect to Windows Update for example - if you have disabled them through ConfigMgr, Group Policy, or some other means. What I discovered is that some of these devices are not having their settings enabled properly. Below is what the device should look like after the Windows Update workload is switched:
At this point I haven’t found any commonalities to cause this behavior to fail. Fortunately, there are a couple of steps we can take to quickly audit and fix this. (Thanks, Maurice)!
First, we can run the following CMPivot query on a collection to determine which devices have the above registry keys set to ‘1’
Registry('HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate') | where Value == '1'
Then, if the query does return any devices, we run a simple script against them to change the registry keys to the expected ‘0’.
$key = 'HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate'
New-ItemProperty -Path $key -Name "DoNotConnectToWindowsUpdateInternetLocations" -Value 0 -propertyType "DWord" -Force -Verbose
New-ItemProperty -Path $key -Name "DisableDualScan" -Value 0 -propertyType "DWord" -Force -Verbose
New-ItemProperty -Path $key -Name "SetPolicyDrivenUpdateSourceForDriverUpdates" -Value 0 -propertyType "DWord" -Force -Verbose
New-ItemProperty -Path $key -Name "SetPolicyDrivenUpdateSourceForFeatureUpdates" -Value 0 -propertyType "DWord" -Force -Verbose
New-ItemProperty -Path $key -Name "SetPolicyDrivenUpdateSourceForOtherUpdates" -Value 0 -propertyType "DWord" -Force -Verbose
New-ItemProperty -Path $key -Name "SetPolicyDrivenUpdateSourceForQualityUpdates" -Value 0 -propertyType "DWord" -Force -Verbose
And that’s it! The next time devices run a Windows Update scan, they should follow your Windows Update Ring from Intune and will be allowed to download from Windows Update. Hopefully we can determine the cause for this in the future, but for now I hope these quick tips will save you some time.
Thanks!
Andrew