Intune update rings: the settings that cancel each other

Intune update rings are the only Windows update control most tenants ever configure, and they are the control most often left in a state that does nothing. The settings do not stack the way the blade implies. A deferral moves the start line, a deadline moves the finish line, and once the deadline lands it overrides the restart behaviour you spent an afternoon negotiating with the business. Here is what each setting actually controls, the exact ranges Microsoft documents, and the failure modes that make a correctly assigned ring look broken.

A ring is a policy like any other, so it inherits every conflict rule that applies to the rest of the service. When two rings reach the same device you are in the same territory as any other Intune policy conflict, and the reporting is no more forthcoming here than it is there. Ring design is where that vagueness costs the most, because the symptom is not an error. The symptom is a fleet that patches slightly later than you told the auditor it would.

One disclosure before the detail. My tenant is a lab with no enrolled devices, so I have not run these rings against a production estate or watched a compliance report fill in behind them. Everything below is documented behaviour, verified against Microsoft Learn on 3 September 2026, plus the places where I would expect it to bite.

What Intune update rings actually control

An update ring is a Windows Update for Business configuration delivered over MDM. It decides when a device is allowed to see an update, how long it may sit on it, and what happens at restart. It does not select individual updates and it does not approve them. Microsoft documents the licence requirement as Microsoft Intune Plan 1, and one client side prerequisite that is easy to miss: the Microsoft Account Sign-In Assistant service, wlidsvc, must be enabled and running. The blade sits under Devices > By platform > Windows > Manage updates > Windows updates, on the Update rings tab. That path has moved twice in three years, which is why half the walkthroughs on page one send you somewhere that no longer exists.

The ranges are worth writing down, because the blade does not show you the ceiling until you have already typed a number it will not accept.

The full reference, including the automatic update behaviour options and the notification levels, is on Microsoft’s update ring policy settings page. It is accurate and it is also the reason people misconfigure rings: it documents each setting in isolation, and the trouble is entirely in how three of them interact.

Deferral and deadline are two different clocks

This is the part that produces most of the confused questions in Microsoft Q&A, and it is not complicated once the two clocks are separated.

The deferral clock starts at release and holds the update away from the device. The deadline clock starts when the client’s own update scan first discovers the update, which is not the same moment and can be a day or more later on a device that was asleep. Microsoft is explicit that the deadline calculation is based off the time the client’s update scan initially discovered the update, so a deadline of 2 days does not mean two days after Patch Tuesday. It means two days after that particular machine noticed.

The grace period is a third clock and the one most often misread. It does not extend the deadline. It starts counting from the point at which a restart is pending, after installation has already completed. Microsoft’s compliance deadline documentation gives the effective deadline as whichever is later of the scan discovery time plus the deadline, or the restart required time plus the grace period. Read that twice before you set a grace period of 7 days on a ring with a 2 day deadline, because you have just built a policy whose real enforcement point is up to nine days out and moves depending on when the user last rebooted.

Two more behaviours follow from the deadline and both catch people:

• Once the effective deadline is reached, the device is forced to restart regardless of active hours. Active hours are a courtesy, not a guarantee, and the deadline outranks them.
• When a deadline policy is in place it ignores the download, installation and restart settings coming from Configure Automatic Updates. Microsoft carved out one exception: starting with the 10 December 2024 update for Windows 11 version 22H2 and later, Configure Automatic Updates is respected before the deadline occurs and ignored once the deadline passes. If your fleet spans that boundary, two devices in the same ring will behave differently and both are behaving correctly.

The failure modes

Intune update rings fail quietly. These are the states where the ring is assigned, the policy reports as applied, and nothing you expected happens.

1. Two rings on one device. Group nesting makes this trivially easy and the blade will not warn you. The device ends up with a mixture, and the reporting shows both policies as delivered. Assign rings to mutually exclusive groups and prove the exclusivity with a query rather than an assumption. Scope tags do not help here: they control who can see the policy, not which policy wins.
2. The deferral is doing exactly what you asked. A 30 day quality deferral with a 7 day deadline is not a 7 day patch cycle. Nothing is late. The ring is holding the update for a month first, and the deadline only begins to matter after that.
3. The device has not scanned. Every deadline in the ring is measured from a scan that has to happen first. A device that has been off, or on a metered connection, has not started the clock at all. Before blaming the ring, confirm the device is talking to the service: the diagnosis order in Intune device not syncing applies unchanged, and forcing a sync tells you nothing about Windows Update, because it is a different channel.
4. Group Policy is still present. A domain joined or co-managed device carrying legacy Windows Update GPOs will take the GPO value for settings the MDM policy also sets. The Intune report still says the ring applied. Both statements are true and the device follows the one you were not looking at.
5. wlidsvc is disabled. Hardening baselines disable the Microsoft Account Sign-In Assistant on the grounds that nobody signs in with a Microsoft account. Update rings need it running. The ring will not tell you.

The fastest way to see whether the ring reached the device at all is to read what actually landed, rather than what the console claims was sent. I have not run this against a production fleet, so treat it as the first check rather than a diagnosis:

1REM What the MDM channel actually wrote for Windows Update, per device
2reg query "HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Update" /s
3
4REM What Windows Update itself is doing about it
5Get-WindowsUpdateLog

If the first command returns nothing under that key, the ring never arrived and no amount of tuning the deadline will change that.

Update rings or Windows Autopatch

Microsoft’s own position has shifted, and the current guidance on the update ring management page is worth quoting rather than paraphrasing. When devices are managed through Windows Autopatch, update rings may be created and maintained by the service to implement rollout cadence and restart behaviour, and in those scenarios admins typically should not assign custom update rings to Autopatch managed devices.

That sentence decides the architecture. Intune update rings remain the mechanism underneath either way, but ownership of them changes hands. If you are running Autopatch, your job is to place devices into the service’s groups and stop hand building rings. If you are not, the rings are yours and the whole conflict surface above is yours as well. The one arrangement that reliably produces the symptoms in the previous section is the half migration: Autopatch enabled for part of the estate, hand built rings still assigned to a group that overlaps it, and nobody willing to delete the old policies in case something breaks.

What I would do differently

Three things about Intune update rings, none of which are in the documentation.

First, I would set the deferral to zero on every ring except the pilot and control the cadence entirely with deadlines. Two clocks running against each other is the root of nearly every confusing report, and the deferral is the one you can lose without losing any real control. A pilot ring at zero deferral and zero deadline, a broad ring at zero deferral with a 3 day deadline, and a late ring at 7 days gives you a genuine staged rollout that you can explain to an auditor in one sentence.

Second, I would keep the grace period at 0 or 1 and not treat it as a kindness. A 7 day grace period on a machine that is never restarted is a device that is patched, pending, and counted as compliant by nobody, sitting in that state for a week. If the concern is users returning from leave, the grace period does solve that specific case, which is what Microsoft designed it for. It is not a general softening dial.

Third, I would write the ring design down as a table of group names and settings, and check it against the assignments monthly. Ring drift is not a technical failure. It is a group membership change made for an unrelated reason six months earlier, and no report in the console will surface it, because from the service’s point of view nothing has gone wrong.

Last verified: 3 September 2026.