How to Set Up Windows Update Rings in Microsoft Intune (Step by Step)

Update rings are the single most under-configured setting in most Intune tenants I’ve seen. Most orgs either leave devices on “install as soon as available” or defer everything by the same number of days across the whole fleet — which means a bad patch like the September 2026 KB5124008 regression that broke Remote Desktop Services lands on every machine at once instead of getting caught on ten pilot devices first. Here’s how to actually set up rings the way they’re meant to work, step by step.

Key takeaways

An update ring in Intune controls deferral (how many days after release an update installs), the deadline (how long a user can postpone before it’s forced), and the servicing channel. Build at least three rings — a small IT/pilot ring with 0-day deferral, a department ring with a few days, and the rest of the fleet with 10+ days — and assign each to a specific group, never “All devices.” Anything running Remote Desktop Services deserves its own ring with an even longer hold.

What update rings actually control

An update ring is a policy that governs when a device installs Windows quality and feature updates relative to their release date — not whether it gets them at all. The three settings that matter most:

Deferral period: how many days after Microsoft releases an update before it becomes available to devices in this ring.
Deadline: how many days a user can postpone the install before Intune forces it, with a grace period and automatic restart.
Servicing channel: almost always General Availability Channel for production devices.

Before you start — plan your rings

Don’t create one ring and assign it to everyone. The whole point is staggered exposure:

Ring 0 — IT and volunteers: 0-day deferral. If something’s broken, this is where you find out first.
Ring 1 — one department or a slice of the fleet: 4-7 day deferral.
Ring 2 — everyone else: 10+ day deferral.
A separate ring for anything running RDS/RDP session host roles: the longest hold of all, in its own group. That’s the exact lesson from KB5124008 — a management-plane server is the worst place to find out an update is broken.

Step by step: create an update ring

Open Windows updates in the Intune admin center. Go to Devices > Windows > Windows updates for Windows 10 and later.
Start a new profile. Select the Update rings tab, then + Create profile.
Name it by ring, not by date. On the Basics tab, use a name that says what the ring is — e.g. “Update Ring 0 – IT Pilot” — not “October patches.” Rings are permanent infrastructure; the deferral number is what changes, not the ring itself.
Set the deferral periods. On the Update ring settings tab, set the quality update deferral and feature update deferral in days, and confirm the servicing channel.
Set the deadline and restart behavior. Scroll down to the deadline settings — days before forced install, grace period, and whether to auto-restart before the deadline hits.
Control the user experience. Set update notifications and restart warnings so people aren’t blindsided by a forced reboot mid-task.
Assign it to a specific group — never “All devices.” On the Assignments tab, include the group for this ring only (your pilot group for Ring 0, a department group for Ring 1, and so on). Exclude anything that needs to stay on a longer hold, like your RDS group.
Review and create. Confirm the summary and select Create.
Confirm it applied. Back in the Update rings list, check the new ring shows the right assignment count. On a pilot device, Settings > Windows Update should reflect the deferral once it checks in.

Repeat it — and don’t skip the exception ring

Do this three or four more times: once per ring, with progressively longer deferral numbers. The one most people skip is the exception ring for RDS/RDP session hosts and anything else you manage exclusively over remote desktop. Give it the longest hold in your whole environment and its own group, even if that means a manual step every month to move it forward once you’ve confirmed the update is clean everywhere else.

Bottom line

Rings only work if devices are actually staggered across them by deferral day and by group — one ring assigned to everyone isn’t a ring, it’s just a delay. Build IT/pilot, department, and fleet rings with increasing deferral, and put anything you manage over RDP in its own ring with the longest hold you can tolerate. It’s a 20-minute setup that turns “a bad patch took down the whole fleet” into “a bad patch got caught on ten machines” — which is exactly what should have caught KB5124008 before it reached anything that mattered.