Windows Update rings for Intune pilots: a starter layout that won't page you
If every device takes this month's quality update the day it ships, one bad driver or a broken line-of-business app hits the whole company at once. Update rings exist to buy you detection time. A small group gets updates first, you watch for problems, and the rest of the fleet follows a few days later.
This is the short, practical version for admins using Intune → Devices → Windows → Update rings for Windows 10 and later. It covers Windows only. Exact setting names and limits move over time, so check them against current Microsoft docs before you copy any numbers.
1. A starter ring layout
Three rings covers most small and mid-size tenants:
| Ring | Who | Size (starter idea) | Quality deferral (starter idea) |
|---|---|---|---|
| Ring 0 — IT | IT staff + a few willing champions | ~1–3% | 0 days |
| Ring 1 — Pilot | A mix across departments (not only IT) | ~10–15% | A few days (e.g. 3–5) |
| Ring 2 — Broad | Everyone else | The rest | About a week or more, inside your patch SLA |
A few rules that save pain later:
- Assign rings to device groups, not just user groups. Patching is a device problem, and shared or multi-user devices make user targeting messy.
-
One ring per device. If a device lands in two update ring policies with different values, you'll get conflicts and confusing reports. Use clear names like
WU-Ring0-IT,WU-Ring1-Pilot,WU-Ring2-Broad, and make the broad group exclude the earlier rings. - Pilot ≠ IT only. Your pilot ring needs Finance's and Ops' real apps on it. That's where the breakage shows up.
- Execs usually follow Broad, not first. If someone senior insists on being early, write down that they agreed to it.
2. Quality vs feature updates (they're not the same dial)
| Quality updates | Feature updates | |
|---|---|---|
| What | Monthly cumulative security + fixes (Patch Tuesday) | New Windows version (e.g. a new 24H2-style release) |
| Risk | Usually lower, but a bad one still hurts | Higher. Apps, drivers, and hardware eligibility all matter |
| Ring setting | Quality update deferral (days) | Feature update deferral (days), or a separate Feature updates policy |
| Typical pace | Days | Weeks to months, pilot first |
Two practical points:
- If you control the Windows version with a Feature updates policy (pin a target version), Microsoft's guidance is to leave the feature deferral in the update ring at 0 so the two settings don't fight. Check current docs for your setup.
- Deferral and deadline are different things. Deferral controls when the update is offered. Deadline settings (plus grace period and restart behavior) control how long the user can put off installing and rebooting after it's offered. A pilot ring with 0-day deferral and a long deadline can still be weeks behind in practice.
3. Why "minimum OS version" compliance fails first
This is the most common way rings and compliance end up fighting each other.
You set a compliance policy with Minimum OS version = this month's build (e.g. 10.0.22631.xxxx) right after Patch Tuesday. Then:
- Ring 0 gets the update, but some of it is still waiting on a reboot.
- Rings 1 and 2 haven't been offered the build yet, because you deferred them on purpose.
- Compliance evaluates them anyway. Every device below that build shows noncompliant.
- If Conditional Access requires a compliant device, those users are now blocked from email and Teams because of a schedule you chose.
The device didn't do anything wrong. The compliance rule got ahead of the ring.
Safer habits:
- Set minimum OS to a build that your broad ring has actually received: usually last month's cumulative, or the org standard (N-1). Raise it only after Ring 2's deadline has passed and your reports show the fleet caught up.
- Use the compliance grace period / actions for noncompliance so a device gets time (and a notification) before it's marked noncompliant, instead of being blocked right away.
- Look at the gap before you raise the bar. A read-only Graph pull of OS versions tells you how many devices you'd break:
Connect-MgGraph -Scopes 'DeviceManagementManagedDevices.Read.All'
Get-MgDeviceManagementManagedDevice -All -Filter "operatingSystem eq 'Windows'" -Property 'deviceName','osVersion','lastSyncDateTime' |
Group-Object OsVersion | Sort-Object Count -Descending |
Select-Object Count, Name
If a big chunk of the fleet sits below the build you were about to require, wait.
- Treat feature-version minimums (e.g. "must be on 23H2 or later") as a separate, slower project with its own pilot. Don't bundle it into a monthly change.
4. A simple monthly rhythm
Patch Tuesday: Ring 0 offered (0-day deferral). Read known-issues notes.
Wed–Thu: Validate Ring 0: install success, reboots done, smoke tests.
Following days: Ring 1 offered (deferral expires). Watch helpdesk volume.
~1 week+ later: Ring 2 offered if Ring 1 is clean.
After Ring 2 deadline + reports caught up: consider raising min OS in compliance.
Smoke tests worth five minutes on Ring 0/1: Outlook send/receive, a Teams call, VPN connect, your top 3–5 line-of-business apps, printing, browser sign-in to your identity provider, and a check that BitLocker still reports healthy.
When something breaks: pause the affected rings (quality and feature pauses are separate, and pauses expire on their own, so note when). Write down who approved it, the reopen criteria, and a reopen date. A pause with no end date turns into unpatched devices.
5. Common mistakes
| Mistake | What happens | Fix |
|---|---|---|
| Min OS compliance raised on Patch Tuesday | Deferred rings go noncompliant, CA blocks users | Raise only after the broad ring has the build |
| Device in two ring policies | Conflicts, reports nobody trusts | One ring per device, exclusions on the broad group |
| Pilot ring is only IT laptops | LOB app breakage found in Broad | Add real users from each department |
| Treating "deferral 0" as "patched today" | Long deadlines and pending reboots mean it isn't installed | Watch install/reboot status, not just policy assignment |
| Feature deferral in the ring + a Feature updates policy | Confusing or blocked version offers | Pick one control. With a Feature updates policy, ring feature deferral = 0 |
| Pausing with no reopen date | Security debt piles up quietly | Time-box every pause with an owner |
| Exec devices excluded "temporarily" | Forgotten, unpatched for months | Every exclusion gets an owner and a review date |
| Ignoring the reports | Problems found by users first | Check Intune's Windows update reports for errors weekly |
6. When it's not actually an update-ring problem
Not every "it broke after Tuesday" ticket is about Windows Update:
- Device isn't getting the ring at all: check enrollment, sync, and group membership before you touch ring settings.
- Compliance flapping right after patching: usually the min-OS timing from section 3, or BitLocker/health attestation re-evaluating after a reboot.
- An app failed to install or update: that's app deployment, not update rings.
Side note: app installs are a different problem. Update rings only control Windows quality and feature updates. They don't install or update your Win32 apps. If your real headache is Win32 apps failing to install, reinstalling in a loop, or showing "not detected" after a successful install, that's packaging and detection rules. We cover it separately in a Win32 app packaging pack ($39): https://cashflow4375.gumroad.com/l/cgnpzt
Want the compliance side done properly?
Most ring pain shows up as compliance pain. The Intune & M365 Admin Starter Pack ($19 during launch week; normally $29) covers enrollment hygiene, a baseline Windows compliance bar (including minimum OS set to builds you actually patch to), inventory snapshots, M365 admin hygiene, and break/fix cards. It also includes three read-only PowerShell scripts: a local enrollment snapshot, a Graph managed-device snapshot, and a compliance policy summary. The scripts only read. They take no device actions and make no policy changes.
👉 https://cashflow4375.gumroad.com/l/joonf
Admin Pack Studio. Not affiliated with Microsoft. Operational guidance for admins authorized to manage their tenant. Pilot first, and check current Microsoft documentation for setting names and limits.
Top comments (0)