Windows Autopatch is the single best way to stay on top of OS patching in your environment. If you have M365 E3 or E5, it’s well worth a look.
This blog is a record of my experiences implementing Autopatch for the company I work for. It does not serve as a step-by-step guide for Autopatch, as plenty of those already exist.
Background
Before starting this project, all devices were cloud-native Intune enrolled/Entra joined, no update settings were previously configured by Intune or Windows Update for Business; the RMM product handled all patching settings.
What is Autopatch & what should I do before using it?
Device Onboarding
When you’ve completed the Autopatch tenant onboarding steps, it will go away and make all the groups and rings in your tenant. If you want the easiest experience, the only group we need to worry about is the one called Windows Autopatch Device Registration. Devices added to this group get registered to the Autopatch service and the service itself will decide how to split devices and stagger updates from there.
Here’s a view of all the groups created by the Autopatch service
I converted the membership type of Windows Autopatch Device Registration to Dynamic, and added a query to add all Windows 10/11 devices:
This is fine in our environment, but may not be for yours. If you have kiosk devices, operational tech, or other non-human operated Windows devices, consider your settings carefully.
Cyber Essentials Compliance
The default timings for updates are quite relaxed and wouldn’t meet the requirements of Cyber Essentials in the UK, where we need all updates installed within 14 days of release. I edited the release management settings so that even the latest patching group would fall within 14 days:
Since we are a relatively small environment, I also adjusted the ring distribution.
- 30% of our devices are in Ring 1
- 30% of our devices are in Ring 2
- 40% of our devices are in Ring 3
I don’t care which devices go where, so I’ll let the Autopatch service decide – and that’s how a patching policy should be, randomised for proper exposure and testing because no one is too important.
Rings Test and Last are not dynamically assigned; I don’t mind being the first I added my own machine into that group:
Autopatch detected issues
When all devices showed up in the registrations, I was later alerted to potential issues that would prevent the update service running properly:
When you click on a device, it shows you why:
This is a leftover registry setting from the RMM product we had handling Windows Updates before. Upon disabling the patching feature, it did not clean up the reg keys it set… 😱
Cleaning Up
I needed to detect and remove the WindowsUpdate registry key entirely which is located at: HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
However, intitially after doing so, Windows Update on the endpoint still showed three policies were controlled by Group Policy, which is weird as this is a Windows 365 PC which has never seen a domain controller, and all settings were removed from the highlighted registry location.
Much more digging later revealed that Windows Update uses some kind of caching system controlled by the key at: HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache. I’m not exactly sure what this is used for, but it disrupts what Autopatch tries to set.
Looking at the cache settings, we can see that the ActiveCache DWORD is set to use the policies from CacheSet002. The AU key has settings we don’t want, and the Windows Update agent is prioritising this registry location for some reason.
Once the CacheSet contents are removed, all the intended settings immediately displayed in the Windows Update UI.
I’m not sure how long that cache remains active, but since I want Autopatch to get to work ASAP, I made a remediation script to remove any values set in both the normal WindowsUpdate policy key, and in both cache sets.
(I’ve not seen or heard of more than 2 cache sets being used during my discussions)
The detection script
$paths = @(
"HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet001\WindowsUpdate",
"HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet002\WindowsUpdate",
"HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
)
$anyPathExists = $false
foreach ($path in $paths) {
if (Test-Path $path) {
$anyPathExists = $true
break
}
}
if ($anyPathExists) {
Write-Host "Registry keys do exist"
EXIT 1
} else {
Write-Host "Registry keys do not Exist"
EXIT 0
}The remediation script – be sure to run this remediation in 64-bit PowerShell
# Define the registry paths
$registryPathWindowsUpdate = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$registryPathCacheSet001 = "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet001\WindowsUpdate"
$registryPathCacheSet002 = "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet002\WindowsUpdate"
# Function to remove registry keys if they exist
function Remove-RegistryPath($path) {
if (Test-Path $path) {
Remove-Item -Path $path -Recurse -Force
Write-Output "Contents of $path have been deleted successfully."
} else {
Write-Output "$path does not exist."
}
}
# Remove all subkeys and contents at the specified paths
Remove-RegistryPath $registryPathWindowsUpdate
Remove-RegistryPath $registryPathCacheSet001
Remove-RegistryPath $registryPathCacheSet002
# Restart the Windows Update service
Restart-Service -Name "wuauserv" -Force
https://github.com/Lewis-Barry/Scripts/tree/main/WindowsUpdate
What is Autopatch doing?
Relax
Over the years, I’ve overheard many discussions which go in favour of extremely controlled patching regimes. IT teams must review every KB and driver update that becomes available in their RMM or WSUS. Only when they decide it passes their rigorous “that’ll probably be ok” quality checks will they allow their endpoints to receive it. But only between the hours of 9:00-9:15 on the third Wednesday past the second full-moon of the year, and the end user absolutely cannot see an update prompt or reboot at any time!
What makes someone qualified to approve an update?
An endpoint admin’s job is to balance business availability with patch compliance, however the long-term harm of preventing updates increases the cyber security risk, and potentially induces catastrophic downtime.
Autopatch is a dedicated service from Microsoft which has teams of people whose sole job is to manage Windows Updates for everyone… That’s what they wow people with on Tinder dates. Leave them to it!
Enterprise and RMM control freaks mean that on average, the group of computers managed by the team of experts as part of their full-time job has worse patch compliance than a home user who bought a Windows 11 machine from PC World and left it all on default.
Release Management
Under Release Settings, you can control what Autopatch is responsible for. Everything is enabled by default. Expedited quality updates will prioritise patching automatically if a 0-day is found, meaning you don’t need to go in and create manually targeted rings.
The only thing we have disabled in our environment is M365 App updates, and that’s because we’re using Cloud Update which is managed over at https://config.office.com
Driver updates
Leaving driver updates on auto, my device is in the test group and a driver was auto-approved:
My system showed the update shortly after:
What now?
Now we wait, and that’s just for curiosity reasons. The service is set, it’s doing the job, and we can go look at the reports or respond to future issues that pop up.
Autopatch will keep devices at the minimum serviced Windows Feature edition. If you want to push everyone to the latest, you’ll need to do that manually under the Release Management section:
I created one to get all our devices to Windows 11 23H2.
And, when patch Tuesday comes around you’ll get a nice email:
But if you want to see what’s going on across your environment in the meantime , go check the Autopatch reports:
And even the non-Autopatch reports are very good now:
Get Patching!
I hope you found this useful, I’m happy that patching is no longer any of our jobs and we have a service that provides excellent notifications and reporting on what is going on.
If you have any feedback or questions on the setup, email me: [email protected]
Further Reading on GPCache
https://thedxt.ca/2024/08/windows-update-settings-stuck – I wish I’d found this sooner.