[5.5.1] Configuring Autopatch and Update Rings in Practice


The architecture article made the case for Autopatch as the default update approach when licensing allows. This one covers what it actually takes to get it running – the prerequisites that matter, how Autopatch groups work, and where manual update rings are the right answer instead.


Licensing and prerequisites

Windows Autopatch requires Windows Enterprise E3 or higher, or Microsoft 365 Business Premium. As of April 2025, Microsoft extended Autopatch availability to Business Premium – previously it required Enterprise licensing. If you’re on Business Premium and haven’t looked at Autopatch recently, it’s worth revisiting.

Beyond licensing, devices need to meet several conditions to register with Autopatch. They must be managed by Intune as the primary MDM authority, or co-managed with the Windows Update workload switched to Intune. They must be corporate-owned – BYOD devices are explicitly excluded. They must have checked in with Intune within the last 28 days. And they need a serial number, model, and manufacturer recorded in Intune, which rules out devices with incomplete hardware inventory.

One prerequisite that trips up hybrid environments: if you have Group Policy Objects applying Windows Update settings, those GPOs will take precedence over Autopatch’s MDM-delivered policies. The registry keys under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate are the specific conflict zone. Any GPO writing to those paths will override what Autopatch is trying to configure. If you’re seeing Autopatch devices not updating on the expected schedule, check for conflicting GPOs before assuming an Autopatch problem.


How Autopatch groups work

An Autopatch group is not an Entra ID group – it’s a separate concept inside Autopatch that represents a collection of deployment rings. Most environments need a single Autopatch group. Large environments with geographically separate teams or distinct management boundaries might use multiple groups, up to 300.

Within each Autopatch group, you define rings. The First and Last rings are pre-created and required. First is your earliest adopters – typically IT staff and willing testers. Last is your VIP or deferred population – executives or devices where disruption is particularly costly. You add additional rings between them for the general population, split by percentage of the enrolled device base.

The ring distribution works by assigning Entra groups to the Autopatch group. Autopatch then automatically creates new Entra groups and distributes devices across rings according to the percentages you define. The percentages must total 100%. Default distribution for smaller environments (under 200 devices) puts 5% in First, 15% in Fast, and the remainder in Broad. For larger environments you define the distribution yourself.

Autopatch removes the scheduling burden but not the ring design decision. You still need to think about who gets updates first and what the acceptable deferral window is for your environment.


What Autopatch manages

Autopatch manages Windows quality updates, feature updates, Microsoft 365 Apps updates, Microsoft Edge updates, Teams updates, and driver updates. Quality updates – the monthly security patches – are the core function. Everything else is opt-in or configurable within the Autopatch group settings.

For quality updates, Autopatch controls the deferral and deadline settings per ring automatically. You can customize these, but the defaults are sensible – First gets updates immediately, subsequent rings get progressively longer deferrals, and Last gets the longest deferral before the deadline forces installation. Microsoft also monitors update health telemetry and can pause a problematic update before it reaches later rings, which is the primary operational advantage over manual rings.

Hotpatch is available for devices running Windows 11 Enterprise 24H2 or later on x64 hardware with Virtualization-based Security enabled. Hotpatch delivers security updates without requiring a restart, which is significant for high-uptime devices. If your fleet meets the requirements, it’s worth enabling – Autopatch handles the scheduling automatically, alternating between hotpatch months (no restart) and baseline months (restart required) on Microsoft’s schedule.


When manual update rings make more sense

Autopatch is the right default when your licensing covers it, your devices are corporate-owned, and you don’t have complex update governance requirements. The scenarios where manual rings are a better fit are specific:

When you need precise control over update scheduling – specific install windows, maintenance schedules that Autopatch’s automated timing doesn’t align with. When you have Business Premium licensing but want to manage updates manually. When you’re in a heavily regulated environment with update approval requirements that Autopatch’s automated rollout doesn’t satisfy. When you have significant co-management complexity with ConfigMgr handling workloads that conflict with Autopatch’s expected configuration.


Configuring manual update rings

If you’re not using Autopatch, Windows Update for Business policies through Intune are configured under Devices → Windows → Update rings for Windows 10 and later. Each ring is a policy that defines the deferral period, the deadline, the active hours window, and the restart behavior.

A standard three-ring structure – Pilot, UAT, Production – covers most environments. Pilot defers quality updates by zero days, giving immediate access to test the patch before broader rollout. UAT defers by seven days. Production defers by fourteen days. Deadlines should be set tightly enough to close the security window without being so aggressive that they cause forced restarts during business hours. A seven-day deadline after the deferral ends is a reasonable starting point.

Active hours are worth configuring – they tell Windows not to restart during hours the user is likely working. Set them to match your organization’s actual working hours rather than leaving the default. A device that forces a restart at 9am because active hours weren’t configured correctly will generate helpdesk tickets.

Feature update policy is separate from quality update rings in Intune. Create a dedicated feature update policy that targets a specific Windows version, assign it to your device groups, and let quality update rings handle the monthly patches. Don’t try to manage feature updates through the quality update ring deferral – the mechanisms are different and conflating them creates confusion.


Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.5] Updates: Autopatch as Default, Rings as the Alternative.