Windows Autopatch: Revisited Part 1

hader

Last year, I released a super popular article that was my top article on 2024. It’s time to update things and take a fresh look at Windows Autopatch, how its changed, advanced troubleshooting, and the new “Hotpatch” capability that is amazing. One of the many reasons we’re revisiting this is the amazing news that Autopatch is now available to Business Premium. We will split it into two parts for fun. Today, we will cover:

What is Autopatch?

Well, a simple refresher is certainly useful.

Windows Autopatch is the next generation patching framework for Microsoft. It uses some magical things called “Autopatch Groups” as you can see below:

Windows Autopatch Group Diagram

The idea is that you tell Autopatch “this is my group of devices that should use Autopatch” and Autopatch will slice them up into various rings automatically, which have custom configurations on how and when to patch. Windows Autopatch is a cloud services delivering Windows, Microsoft 365 Apps for Enterprise, and Edge. (The docs say Teams, but I know that’s not accurate).

One other thing I like to note about some of the Autopatch magic:

How the Magic HappensTarget SLA
Windows Autopatch deploys CSPs to each update deployment ring to control the rollout. Deferrals, deadlines, and grace periods are used to cultivate the experience.The goal is to hit 95% updated devices within 21 days.
Feature update profiles are created that correlate to Windows Autopatch groups to rollout new feature updates gradually. The profile contains the minimally supported OS at the minute which is 21H2. You can create custom profiles to enforce newer OS versions, which will automatically deactivate the existing ones.The goal is to keep 99% of devices on a supported OS.
Covers the primary suite, Visio, and Project. No policy conflicts can exist. This doesn’t rely on rings as its powered by the Microsoft CDN. The service relies on devices, and they will receive notifications like regular Office updates. Devices must have checked in within the last 5 days and apps must close for the update process to complete.The goal is to keep 90% of devices on a supported version of the monthly enterprise channel. Supportability is a 2-month window.
Must ensure no policy conflicts exist and it requires an Edge restart to apply updates. Updates are checked for every 10 hours. Quality Updates will occur weekly. Feature updates happen every 4 weeks and rollout progressively.All users see updates within a few days of its release.
Device must be signed into the device and Teams. Updates are checked for every few hours. After the download, the device must reach an idle state for 40 minutes to perform the automatic update.Updates happen once a month or twice a month for members of TAP.

Setting up Autopatch

Ironically, I’ve decided to show how this works, since they have changed a bunch about how it works now. You used to have groups automatically created throughout, but now they make you do a little bit more work. It’s okay, but I got you covered!

I have a video below that will walk you through the entire setup. Before doing that, a few tips to help you get started:

  • Try to avoid getting too cute and pointing your rings at actual groups. You really don’t need to. That is it’s actual job!
  • There’s some key capabilities they aren’t setting up for you (expedited updates, Hotpatch, but more on those later)
  • You will need to do some cleanup to make sure you don’t have a conflict party when trying to onboard devices (more on that later also).

Enjoy the video that shows you how to easily setup Autopatch within 5 minutes:

What is Hotpatch?

Now, we will discuss a very exciting capability. Outside of the name: Hotpatch being pretty cool. Hotpatch has a very simple idea in mind: “Let’s patch without a reboot yay!!!”

Hotpatch updates are the monthly B release security updates (the monthly quality update) where you don’t need a reboot to apply those nicely fancy security changes anymore. It implictly requires Autopatch to deploy those Hotpatch updates and just furthers the story of Windows Autopatch’s dominance on the patching world.

Hotpatch coincides with your regular Windows Autopatch policies, but you do need to create and deploy the policy itself. The requirements for Hotpatch are:

  • Same licensing requirements as Autopatch (Business Premium, Edu A3/A5, Win 11 E3/E5/VDA)
  • Windows 11 Enterprise 24H2
  • Device must be on the latest Baseline release version to qualify for Hotpatch updates (the calendar is below)
  • Enrolled in Intune

We do have a few OS requirements to use Hotpatch. Firstly, you need to have VBS enabled (that should be enabled by default already).

For those running ARM64, like myself you should use this remediation below.:

##Check Script##
# Define the registry path and value name
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management"
$valueName = "HotPatchRestrictions"

try {
    # Get the registry value
    $regValue = Get-ItemProperty -Path $regPath -Name $valueName -ErrorAction Stop

    if ($regValue.$valueName -eq 1) {
        Write-Output "$valueName is correctly set to 1"
        exit 0
    } else {
        Write-Output "$valueName exists but is not set to 1 (current value: $($regValue.$valueName))"
        exit 1
    }
} catch {
    Write-Output "$valueName does not exist under $regPath"
    exit 1
}
##Remediation##
# Define the registry path and value
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management"
$valueName = "HotPatchRestrictions"
$valueData = 1

# Create the registry key if it doesn't exist
if (-not (Test-Path $regPath)) {
    New-Item -Path $regPath -Force | Out-Null
}

# Set the DWORD value
Set-ItemProperty -Path $regPath -Name $valueName -Value $valueData -Type DWord

# Confirm the change
$currentValue = Get-ItemProperty -Path $regPath -Name $valueName
Write-Output "Set $valueName to $($currentValue.$valueName) in $regPath"

If your device doesn’t meet requirements, you wind up with the Last Cumulative Update instead. The interesting thing is that you will need to reboot once a quarter anyways to get the baseline update. The calendar can be seen below:

MonthUpdate TypeTypeKB article
January2025.01 BBaseline (Restart)KB5050009
February2025.02 BHotpatchKB5052105
March2025.03 BHotpatchKB5053636
April2025.04 BBaseline (Restart)KB5055523
May2025.05 BHotpatchKB5058497

So, how do you know if you have that baseline update? You should follow this master KB article from Microsoft, which shows you the KBs to match. So, since this is May, you check to see if you have the baseline (KB5055523):

Screenshot of the baseline update for Hotpatch already being installed

So, in this scenario you won’t need to reboot when the May patch comes and will get a fun green banner:

Shows that the patch was hotpatch capable and was installed successfully.

Setting up Hotpatch

Setting up Hotpatch is pretty easy. You just create a quality update policy:

Creating the windows quality update policy

You turn on the two settings in there and deploy it to all users (ideally the same group you’re using for Autopatch):

Enabling hotpatch in the policy

You can confirm the setting came down inside of Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin and Event ID 813:

Verifying in the registry that Hotpatch is enabled

Deploying Expedited Quality Updates

One thing that really disappointed me during writing this is that they apparently removed automated expedited quality updates. Now, you need to do it manually, boo!!! Similar to Hotpatch, you create a quality update policy to deploy an expedited quality update:

Creating the windows expedite policy

You specify the name, tell it what quality update to expedite and how long to wait before a restart:

Setting up the expedite policy

Luckily, it’s very simple to make the magic happen there.

Transitioning from RMM/Old Patching to Autopatch

One of the main issues people run into is moving from patching on-prem or some 3rd party system. It’s very important to know what to cleanup in these scenarios.

Typically, the idea is to eliminate everything in the WindowsUpdate folder in your registry to escape the evil. A quick and simple remediation will help here too:

#Detection
$TranscriptPath = "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs"
$TranscriptName = "AutoPatchDetection.log"
New-Item $TranscriptPath -ItemType Directory -Force

# Stop any orphaned transcript sessions
try {
    Stop-Transcript | Out-Null
} catch [System.InvalidOperationException] {}

Start-Transcript -Path "$TranscriptPath\$TranscriptName" -Append

# Define registry paths to check
$regPaths = @(
    "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate",
    "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"
)

$RemediationNeeded = $false

foreach ($path in $regPaths) {
    Write-Host "Checking registry path: $path"
    try {
        $key = Get-Item -Path $path -ErrorAction Stop
        if ($key.Property.Count -gt 0) {
            Write-Host "Values found in $path"
            $RemediationNeeded = $true
        } else {
            Write-Host "No values found in $path"
        }
    } catch {
        Write-Host "Registry path not found: $path"
    }
}

if ($RemediationNeeded) {
    Write-Host "Registry settings are incorrect or need remediation"
    Stop-Transcript
    exit 1
} else {
    Write-Host "Registry settings are correct"
    Stop-Transcript
    exit 0
}

#Remediation
$TranscriptPath = "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs"
$TranscriptName = "AutoPatchRemediation.log"
New-Item $TranscriptPath -ItemType Directory -Force | Out-Null

# Stop any orphaned transcript
try {
    Stop-Transcript | Out-Null
} catch [System.InvalidOperationException] {}

Start-Transcript -Path "$TranscriptPath\$TranscriptName" -Append

# Define the Windows Update registry root path
$WUPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"

# Check if the key exists before trying to remove it
if (Test-Path $WUPath) {
    Write-Host "Removing the entire WindowsUpdate registry key..."
    Remove-Item -Path $WUPath -Recurse -Force
    Write-Host "Registry key removed successfully."
} else {
    Write-Host "WindowsUpdate registry key not found. Nothing to remove."
}

Stop-Transcript

Most of the actual sources of issues will be group policies, settings in SCCM, or 3rd party MDMs/patching solutions that put a stranglehold on your system. A few tips in general:

  • Run RSOP from CMD and look in Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update to make sure you don’t have any GPOs
  • Check SCCM at Administration > Overview > Client Settings and make sure Software Updates isn’t enabled.
  • Validate no 3rd party patching solution is messing around

Closing Thoughts

In part one, we covered many of the core concepts around Autopatch/Hotpatch. Next week, we will dig into fun things like advanced troubleshooting, interaction between the client and the Autopatch services, the APIs, and more.

Overall, let’s remember that Windows Autopatch is a really great product that almost everyone can use now. There’s no reason to leverage other patching services regardless of what your support team/MSP tells you. The value is huge, and we can accomplish so much more together.

Facebook
Twitter
LinkedIn

1 thought on “Windows Autopatch: Revisited Part 1”

Let me know what you think

Scroll to Top

Discover more from Mobile Jon's Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading