Deleting an update ring does not remove its settings from devices. They keep whatever they had.
The documentation says so directly, and no device anywhere keeps a record of what it was configured with before. So deleting a ring in the hope of undoing something leaves that exact something running on every machine the ring ever reached. Almost nobody expects this, and it explains a great many estates whose update behavior nobody can account for.
- 35 daysMaximum pause, resettable by extending
- 2 to 60 daysConfigurable feature update uninstall window
- ImmediatelyHow fast an uninstall command reaches devices
- wlidsvcThe service that must run for feature updates
Deleting an update ring does not remove its settings from devices.
It is in the documentation, it makes complete sense once somebody explains it, and it accounts for a surprising number of environments where update behavior has become genuinely inexplicable.
- Deletion does not reach the machines. They retain exactly what they last received, and because no device stores any record of previous settings, there is no earlier state waiting to be restored underneath.
- Follow that forward a few years. An organization that has been creating, assigning, editing and deleting rings since 2019 is running configuration issued by policies that no longer appear anywhere in the console, with nothing on the device pointing back to where any of it came from.
- On top of that, a machine can be picking up settings from other rings that are still active. What is in force on any given endpoint is therefore an accumulation, not a reflection of whichever single ring you happen to be looking at.
- Getting out is methodical rather than clever. Decide the rings you actually want, assign them to device groups on purpose, and then go and confirm what landed. The per-setting report is the one that shows reality; everything else shows intent.
Eight things that determine whether your update strategy works.
Client-side behavior, staged by group
What a ring governs is how long updates are held back, when restarts happen, what deadlines apply, which hours count as active, and what the user gets told. Point different settings at different groups of machines and you have your test, pilot and production stages. That layering is where the name came from in the first place.
Deleting a ring leaves the settings behind
Removing a ring from the console changes nothing on the machines it was assigned to. They hold on to whatever they were last given, and since no device keeps any history of prior settings, there is nothing to revert to even in principle. What deletion actually ends is enforcement, not configuration, and the distinction costs people entire afternoons.
Pause, and how the 35 days actually work
A pause holds feature or quality updates for a maximum of 35 days, counted from when you set it. Reach the end and it lapses by itself, at which point the machine goes looking for whatever applies to it. Resume then pause again and the clock restarts at 35, and extending does the same, so the ceiling is per pause rather than absolute.
A pause is not instant
Nothing happens on a machine until its next check-in, and plenty can happen before that arrives. Picture a laptop shut in a bag while you issue the pause. It wakes up, pulls and installs whatever was scheduled for it, and only afterwards gets around to asking the service whether anything has changed. By then the update you were trying to stop is already on.
Uninstall, which behaves urgently
The request goes out to machines straight away. Maintenance schedules configured on the ring do not constrain it, and where removal needs a reboot, the reboot happens with no option offered to postpone. Somebody mid-presentation finds that out the hard way, which is a good reason to know it before you click.
The service that silently blocks feature updates
One service has to be enabled and running, and if it is not, feature updates are never offered at all. This bites hardest in hardened images, where somebody methodically disabled everything deemed non-essential a few years ago. The symptom is machines that simply never move version, and the cause is genuinely difficult to find unless you already know to look.
Long-Term Servicing Channel limits
Quality updates work on the Long-Term Servicing Channel, feature updates do not, and five ring controls consequently do nothing there: pausing feature updates, their deferral period, their uninstall window, pre-release build enrollment, and any feature update deadline. Configure them anyway and the console will accept it without complaint.
Three reports, answering different questions
You get check-in status for devices and users as the default landing view, an assignment report covering everything targeted including machines still waiting to receive the policy, and a per-setting breakdown showing where each individual setting actually ended up. The third is the one that tells you the truth when a ring appears not to be working.
Uninstall restarts devices without asking, and a bad feature update may not be removable at all.
Think of uninstall as the emergency brake. It works, and it behaves with an urgency that is worth understanding before the day you actually need it.
- The request reaches machines immediately. Removal starts the moment the policy change arrives, maintenance schedules configured on the ring do not hold it back, and where a restart is needed the machine restarts with no opportunity for the person using it to defer.
- Your window is both finite and something you set. Feature updates can be removed within a configurable period running from 2 to 60 days. Past that boundary the files needed to reverse the installation have already been cleaned up during routine maintenance, and no amount of urgency brings them back.
- One situation defeats it regardless of how quickly you act: an update delivered through an enablement package cannot be uninstalled. If rollback is your safety net for a particular version transition, establish which mechanism that transition uses before you rely on it.
- And it is temporary by design. Uninstalling also pauses updates of that type on the ring, and once the pause runs out machines will reinstall the very update you removed, assuming it still applies to them. What you have bought is time to decide, not a decision, so the next action needs planning while the clock runs.
Four things that make update rings dependable.
We check the service that silently blocks feature updates
One service has to be running for feature updates to be offered at all, and disabling it produces no error anywhere. Where a hardened image switched off everything considered non-essential, this single fact explains an entire population of machines sitting on an old version while their policy configuration looks impeccable.
We trace overlapping ring assignments
Two facts combine badly here. A machine can take settings from several active rings simultaneously, and deleting a ring leaves everything it applied sitting on those machines with no record of what preceded it. Put those together across a few years and you get device configurations that genuinely cannot be reconstructed by looking at the console.
We assign to device groups rather than user groups
This is the documented recommendation, and the reasoning is practical: target devices and the policy applies without waiting for anybody to sign in. On shared hardware, or on machines that sit unused for weeks at a time, that distinction is the difference between an update policy that arrives and one that never does.
We write the rollback runbook before it is needed
Pausing waits for the next check-in and then holds for 35 days. Uninstalling arrives instantly, disregards your maintenance windows, and reboots people without asking. Wednesday morning, with a bad update working its way across the estate, is not when anybody should be discovering either of those properties for the first time.
Four phases across roughly four weeks.
- 01Week 1
Map the rings and what they actually target
We document every ring, everything it sets, and every group it points at, paying particular attention to where those groups intersect. Because a machine can take settings from several active rings at once, overlap is the first thing that has to be visible. Anything under Autopatch management is pulled out into its own list, since custom rings generally should not be aimed at those machines.
- Ring inventory with settings and assignments
- Overlapping assignments identified
- Autopatch-managed devices separated
- LTSC devices identified with their control limits
- 02Week 2
Fix the prerequisites that block updates silently
We confirm the sign-in assistant service is enabled and running everywhere, because with it disabled feature updates are never offered and nothing in the console will tell you why. Alongside that, we verify the machines can actually reach the service endpoints they depend on, which is the other silent cause of a ring that appears to do nothing.
- Sign-In Assistant service state verified across devices
- Endpoint reachability confirmed
- Devices not receiving feature updates investigated
- Edition coverage checked against the supported list
- 03Week 3
Redesign the ring structure
We build a clean set representing test, pilot and production, targeted at device groups rather than user groups. That choice matters: target a user group and nothing applies until somebody signs in, which is exactly the wrong dependency for update policy. Overlaps get eliminated at this point rather than layered over.
- Ring structure redesigned with clear stages
- Assignments moved to device groups
- Overlapping assignments resolved
- Scope tags applied where administration is delegated
- 04Week 4
Write the runbook for a bad update
This is the deliverable people actually open at eight in the morning when something has gone wrong. It covers what to pause and how long that takes to bite, whether uninstall is still available given the window you configured, the fact that uninstall reboots machines without asking anybody, and the reminder that deleting a ring reverses precisely nothing.
- Pause and resume procedure with timing expectations
- Uninstall decision criteria and window documented
- Enablement package limitation recorded
- Reporting views demonstrated to the operations team
Six situations where update ring design decides the outcome.
An organization with devices stuck on an old version
Our most frequent finding by a comfortable margin, and the usual culprit is a disabled sign-in assistant service, without which feature updates are simply never offered. Note what that means: the fault lives in the image, not the policy, so no amount of examining the ring configuration will reveal it.
An operator running LTSC on fixed-function machines
Because the servicing channel takes quality updates but not feature updates, five of the settings on your ring have no effect on those machines at all. Nothing warns you. In a mixed environment those devices need pulling into their own ring rather than being left to receive settings that quietly do nothing.
A business that needs to stop an update spreading
Pausing is the correct opening move, but it only lands when each machine next checks in. Anything currently powered off may well wake up, install the update, and only then hear about the pause. Understanding that changes how urgently the command needs issuing and how you communicate with staff in the meantime.
A provider that cannot accept a surprise restart
Removal begins the moment the policy arrives, your configured maintenance windows are not consulted, and the reboot comes with no option to postpone. On clinical or operational equipment that consequence has to be weighed deliberately beforehand, because discovering it afterwards means discovering it mid-procedure.
A regulated firm evidencing update currency
One report tells you where every individual setting actually landed; another lists every targeted machine including the ones still waiting. Run both and you have a documented answer rather than an assertion, which is the distinction a SOC 2 auditor, an insurance carrier or an FTC Safeguards Rule assessment is drawing when they ask the question.
A company adopting Windows Autopatch alongside rings
Autopatch creates and maintains its own rings for the machines it manages, and the guidance is explicitly against pointing custom rings at those same machines. Anywhere both approaches are in play, that boundary has to be drawn on purpose, because left alone the two will overlap and produce behavior nobody intended.
How US organizations manage Windows updates.
| Feature | Rings designed and documented | Rings created once | Default behavior |
|---|---|---|---|
Staged rollout across groups | Yes | Nominally | No |
Overlapping assignments resolved | Yes | Unknown | Not applicable |
Assigned to device groups | Yes | Mixed | Not applicable |
Prerequisite service verified | Yes | No | No |
Devices stuck on old versions found | Yes | Discovered late | Unknown |
Pause behavior understood | Yes | Partly | No |
Rollback window known | Yes | No | No |
Runbook exists for a bad update | Yes | No | No |
Per-setting status reviewed | Yes | Rarely | No |
Autopatch devices handled separately | Yes | Sometimes | Not applicable |
What each policy action actually does.
Action
Delete
- What it does
- Stops enforcement, and leaves current settings on devices unchanged
Action
Pause
- What it does
- Blocks feature or quality updates for up to 35 days, then expires automatically
Action
Resume
- What it does
- Restores updates, and a later pause restarts the 35 day period
Action
Extend
- What it does
- Resets the pause period for both update types back to 35 days
Action
Uninstall
- What it does
- Rolls back the latest feature or quality update, immediately
Action
Uninstall side effect
- What it does
- Also pauses updates of the same type on that ring
Action
After that pause elapses
- What it does
- Devices reinstall the uninstalled update if still applicable
Action
Uninstall window, feature updates
- What it does
- 2 to 60 days, set by the uninstall period setting
Action
Uninstall after an enablement package
- What it does
- Will not be successful
Action
Quality update rollback visibility
- What it does
- Still listed in Windows update history afterwards
Five steps, and the first finds the devices nobody knew were stuck.
- 1
Read the reports before the configuration
Three views, read together: who has checked in, what has been targeted including anything still pending, and where each setting genuinely ended up. That combination isolates the machines behaving differently from what the policy says, and those machines are the real starting point for everything that follows.
- 2
Check the prerequisites that block updates silently
Two checks, neither difficult. Is the sign-in assistant service running, given that feature updates are never offered without it, and can the machines actually reach the service endpoints they depend on. Between them these account for the overwhelming majority of devices that never move version despite apparently correct policy.
- 3
Untangle overlapping ring assignments
Since a machine can hold settings from several rings at once, and since deleting a ring strips nothing from the machines it reached, overlap does not cancel out over time. It accumulates, into effective configurations that cannot be derived from anything visible in the console. Untangling that is worth considerably more than adjusting any individual setting.
- 4
Redesign around device groups and clear stages
Three stages, targeted at device groups so that nothing waits on somebody signing in before it applies. Autopatch-managed machines are kept out of scope entirely, and anything on the long-term servicing channel is separated out given how many of the controls do nothing for it.
- 5
Write the runbook for the bad week
Pause timing and its 35 day expiry, the extend and resume behavior, the uninstall window between 2 and 60 days, the fact that uninstall restarts devices immediately without a user delay option, and that a feature update applied by enablement package cannot be uninstalled.
What organizations ask about Windows update rings.
Fifteen questions about your own update rings.
Structure
- How many rings do we have?And what each is for.
- Do any assignments overlap?Devices can get settings from several.
- Are rings assigned to device groups?Recommended over user groups.
- Are Autopatch devices excluded?Custom rings should not target them.
- Any LTSC devices in scope?Five feature update controls do not apply.
Blocked updates
- Is the Sign-In Assistant service running?Feature updates need it.
- Any devices stuck on an old version?Check that service first.
- Can devices reach Windows Update endpoints?A stated prerequisite.
- Are all editions supported?Pro, Enterprise, Education, and others.
- Do we check per-setting status?It shows what actually landed.
Emergency actions
- Does anybody know pause is 35 days?And that it expires automatically.
- Do we know pause is not instant?It applies at next check-in.
- What is our uninstall period set to?Between 2 and 60 days.
- Does the team know uninstall forces a restart?With no user delay option.
- Is there a written runbook?For the week it matters.
Open per-setting status on your main update ring and look for settings that did not apply everywhere.
That report shows how each individual setting landed across devices. It is the fastest route to the machines that are quietly behind, and the reason is frequently a service nobody thought to check.
Related Services
Explore more solutions that work great with this service