Intune feature updates: ring deferral vs a Feature updates policy vs Windows Autopatch
"Why did half the pilot ring jump to the new Windows release while the other half is still on the old one?" That question usually means two or three different controls are steering feature updates at the same time.
In Intune there are three common ways to control which Windows version a device ends up on:
- The feature update deferral setting inside an update ring.
- A Feature updates policy that pins devices to a specific version.
- Windows Autopatch, which creates and manages the rings and policies for you.
They overlap, and mixing them without a plan is where the surprises come from. This post explains what each one actually does, how they interact, and how to pick one approach. Setting names, licensing, and service behavior change over time, so check current Microsoft docs before you copy anything.
1. Ring deferral: "wait N days after release"
In Devices > Windows > Update rings for Windows 10 and later, the ring has a Feature update deferral period (days) setting (0 to 365).
What it does: when Microsoft releases a new feature update, devices in that ring wait the number of days you set, then the update is offered. There's no version target. A device with a 180-day deferral will eventually move to whatever the latest release is once the deferral runs out.
What it's good for:
- Small tenants that just want "not on day one."
- Devices where you don't care exactly which release they run, as long as it's supported.
What it's bad at:
- Holding a version. You can't say "stay on this release until I'm ready." Once the deferral runs out, the offer arrives.
- Moving Windows 10 to Windows 11. The deferral alone doesn't control the jump. Rings also have a separate Upgrade Windows 10 devices to Latest Windows 11 release setting, and that one is easy to miss when you inherit a tenant.
2. Feature updates policy: "be on exactly this version"
In Devices > Windows > Feature updates for Windows 10 and later (the menu path has moved between portal versions), you create a policy that names a specific release. Devices assigned to it are offered that release and then stay on it until you change the policy, even after newer releases ship.
You also get rollout options: make it available as soon as possible, on a start date, or as a gradual rollout across a window of days.
This is the control most mid-size and larger tenants want, because it matches how change control works: "We validated this version, now move these groups to it."
Things to know before you rely on it:
- Prerequisites. The service behind it needs devices that are Microsoft Entra joined or hybrid joined, managed by Intune, running a supported edition, and sending Windows diagnostic data at the Required level or higher. The tenant also has to allow Intune to use Windows diagnostic data (the setting lives under Tenant administration > Connectors and tokens, or a similar location). There are licensing requirements too. Check current Microsoft docs for the exact list for your plan.
- It doesn't replace rings. You still need an update ring for quality updates, restart behavior, and deadlines.
- The ring's deferral still applies. Microsoft's guidance is to set the ring's Feature update deferral period to 0 days for devices that also get a Feature updates policy. If you leave a deferral in the ring, devices can wait for that deferral before the policy's version is offered, which looks like "the policy isn't working."
- Pause in the ring affects it. Pausing feature updates in a ring also stops the version from being offered to those devices.
3. Windows Autopatch: "let the service run the rings"
Windows Autopatch is a Microsoft service that sits on top of the same Intune update controls. You create Autopatch groups, and it builds the deployment rings (a test ring, then progressively larger rings) and the update ring and feature update policies that go with them. It also gives you release management views and reporting.
What changes for you:
- You stop hand-editing the policies it creates. If you edit or delete Autopatch-created policies directly, you can end up fighting the service. Make changes through Autopatch's own settings.
- Group membership matters. Devices land in rings based on Autopatch group setup. If a device is also in one of your old hand-made rings, you have overlapping policy assignments.
- Licensing and feature availability have changed several times. Check the current Autopatch licensing page before you plan around it.
Autopatch is a good fit if you want a standard cadence and don't have time to run rings by hand. It's a worse fit if you have strict app-validation gates that don't map to its ring model.
4. How they interact (the conflict table)
| Situation | What you'll see | Fix |
|---|---|---|
| Ring has 180-day feature deferral and a Feature updates policy | Version offered late, or "policy did nothing" | Set ring feature deferral to 0 for devices with a Feature updates policy |
| Two Feature updates policies assigned to the same device | Conflict, or the device lands on a version you didn't plan for | One policy per device. Use exclusion groups |
| Old manual ring and an Autopatch ring on the same device | Conflicting settings, reports that don't match | Remove the manual assignment for Autopatch-managed devices |
| Feature updates paused in the ring | Nothing moves | Unpause on purpose, under a change ticket |
| Windows 10 device in a ring with "Upgrade to latest Windows 11" = Yes | Device jumps to Windows 11 outside your plan | Decide this setting deliberately, per ring |
| Device not sending Required diagnostic data | Feature updates policy shows errors or no status | Fix the diagnostic data configuration before blaming the policy |
5. Read-only checks before you change anything
On a single device, you can see what it thinks is happening without changing anything:
# Current Windows build and display version
Get-ComputerInfo -Property OsName, OsVersion, OsBuildNumber, OSDisplayVersion
# Windows Update for Business policy values the device received (read-only)
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update' -ErrorAction SilentlyContinue |
Select-Object DeferFeatureUpdatesPeriodInDays, PauseFeatureUpdates, TargetReleaseVersion, ProductVersion
# Diagnostic data level the device is using (policy value, if set)
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection' -ErrorAction SilentlyContinue |
Select-Object AllowTelemetry
Registry locations for MDM policy values can differ by build. If a value is missing, it may simply not be set, or it may live under a different key. Treat this as a quick look, not proof.
In the Intune admin center, the Windows feature update reports (under Reports > Windows updates) show per-device state and error codes for Feature updates policies. Check them before and after any change, and export the CSV as evidence.
6. Picking one approach
A simple decision path:
- Small tenant, no version requirements, one admin: rings with a feature deferral are fine. Write down the deferral per ring and the Windows 11 upgrade setting.
- You need "stay on this version until we sign off": use a Feature updates policy per wave (pilot, broad), set ring feature deferral to 0 for those devices, and keep rings for quality updates and restarts.
- You want a managed cadence and fewer hand-built policies: evaluate Windows Autopatch, migrate one pilot group, and remove the old manual assignments from those devices.
Whichever you choose, write it down in one sentence that a new admin can read: "Feature version is controlled by the Feature updates policies named FU-Pilot and FU-Broad. Rings do not defer feature updates." That sentence prevents most of the conflicts in section 4.
Want the ring process written down?
The Windows Update Rings & Patch Ops Pack ($25) from Admin Pack Studio covers ring topology with owned exclusions, promotion gates with line-of-business smoke tests, a weekly Patch Tuesday runbook with comms, pause and rollback habits with reopen criteria, and five patch break/fix cards. It works with Autopatch or with hand-built Intune rings. It's mostly docs, plus one read-only local snapshot script. It doesn't approve or install updates.
Setting up Intune from scratch? The Intune & M365 Admin Starter Pack covers enrollment hygiene and compliance baselines: https://cashflow4375.gumroad.com/l/joonf
Admin Pack Studio. Not affiliated with Microsoft. Windows, Intune, Windows Autopatch, and Microsoft Entra ID are Microsoft products. Operational guidance for admins authorized to manage their tenant. Settings, licensing, and service behavior change, so check current Microsoft documentation. Examples use placeholder names.
Top comments (0)