Decoding WUfB deferrals: why your 7-day ring is really a 37-day ring

An admin opens the Intune update ring, reads Quality update deferral period: 7, and writes "our production ring is one week behind Patch Tuesday" into the risk register. That sentence is wrong on the device I used to write this article, and it is wrong by a factor of five.

The real number on that machine is 37 days — not because anything is broken, but because four separate clocks are running, each with a different starting gun, and the portal shows you one of them.

Worse: the classic registry hive that every "audit our WUfB config" script greps held none of the values that produce the 37.

The problem: the portal says 7 and the device is 37 behind

Deferral misreading is not a rare edge case. It is the default state of most fleets, because the mistake is baked into the vocabulary. "Deferral period" sounds like "how late we are". It is not. It is one input to how late you are.

Three things make this failure hard to catch. The first is that the portal is telling the truth: Intune really is sending a 7-day quality deferral, the device really did apply it, nothing shows as non-compliant and no event is logged. The gap between intent and reality is arithmetic, not failure.

The second is that the periods use different anchors. Microsoft documents the feature-update deferral plainly: "The deferral period begins when Microsoft releases the update." But the deadline anchor moved — "The deadline calculation for both quality and feature updates is based off the time when the client initially discovered the update through scan." Discovery cannot happen until the deferral expires. So they stack.

The third is where the values live. On a modern Intune-managed device, they are not in the Group Policy hive that every audit script checks.

Here is the classic hive on the device used for this article, read read-only:

The values are one hive over. Intune writes Policy CSP settings into the PolicyManager tree, and Microsoft's own configuration article documents the MDM landing zone as \Microsoft\PolicyManager\default\Update. On this build, that is not where the live values are either — default\Update holds the schema, one subkey per policy, and the applied values sit under current\device\Update. Sixty-five of them.

Why it happens: four clocks, four different starting guns

There are four independent controls that can hold an update back, and they do not share a clock. Understanding which event starts each countdown is the entire skill.

Clock 1 — the deferral, anchored to release

The deferral answers one question: how long after Microsoft publishes an update will this device even be offered it. Microsoft's example is unambiguous: a device with DeferFeatureUpdatesPeriodinDays=30 "won't install a feature update that is first publicly available on Windows Update in September until 30 days later, in October".

Quality and feature deferrals use days, but with wildly different ceilings. Quality is capped at 30 days. Feature is capped at 365. That asymmetry is deliberate and the single most common source of "why is this device two releases behind" — a 365-day feature deferral is a legal, supported configuration.

Clock 2 — the pause, anchored to a date string

A pause is not a longer deferral. It is a hard stop with its own fixed 35-day life, and it is anchored to a date you supply, not to any update's release.

The modern controls are PauseQualityUpdatesStartTime and PauseFeatureUpdatesStartTime, and they are strings, not numbers — the CSP specifies "string (yyyy-mm-dd, ex. 2018-10-28)", and the in-box WindowsUpdate.admx declares them as text elements with maxLength="10", which is exactly the width of that format. Microsoft is explicit about the arithmetic: "Quality Updates will be paused for 35 days from the specified start date."

That anchoring is what makes a pause dangerous. The 35 days count from a string, so a later start date silently extends the pause — Microsoft documents that too: "In cases where the pause policy is first applied after the configured start date has passed, you can extend the pause period up to a total of 35 days by configuring a later start date."

The legacy boolean forms still exist and still have different windows. PauseQualityUpdates=1 pauses "for 35 days or until value set back to 0, whichever is sooner". PauseFeatureUpdates=1 pauses for 60 days. Same policy family, same units, near-identical names, nearly double the window. Intune writes both booleans and the start-time string to the device, so you have to check all three per update class.

Clock 3 — the deadline, anchored to scan discovery

A compliance deadline does not override a deferral. It runs after it. That is what turns a 7-day ring into a 37-day ring.

Microsoft states the anchor directly: the deadline is "based off the time when the client initially discovered the update through scan", a change from the older behaviour where quality deadlines counted from the release date. A deferred update is not returned by a scan until the deferral expires, so discovery is the earliest post-deferral scan, and deadline days start counting there.

Both deadlines take 0–30 days, with CSP defaults of 7 for quality and 2 for feature. Intune's ring UI documents the input range as "(2-30)" — another place the portal's constraint is narrower than the CSP's.

Clock 4 — the grace period, anchored to pending-restart

Grace is the fourth window, and it exists to stop a user returning from leave being restarted in their face. Microsoft: "The grace period for both quality and feature updates starts its countdown from the time of a pending restart after the installation is complete."

Grace and deadline do not add naively. The documented resolution is a maximum: "The effective deadline is whichever is the later of the scan discovery time plus the specified deadline or the restart required time plus the grace period." Grace only extends the window when installation lands very late relative to discovery.

The fallback chain matters when you audit. ConfigureDeadlineGracePeriodForFeatureUpdates falls back to ConfigureDeadlineGracePeriod if unset, then to a default of 7. Quality grace defaults to 2. An absent value is not a zero.

Precedence: which channel wins, and how the device records it

When both Group Policy and MDM set the same Update policy, the arbiter is MDMWinsOverGP in the ControlPolicyConflict CSP. Microsoft: "If set to 1 then any MDM policy that's set that has an equivalent GP policy will result in GP service blocking the setting of the policy by GP MMC." Default is 0 — meaning Group Policy wins unless you flip it.

You can read both halves of that mechanism on the device. Each schema subkey under PolicyManager\default\Update carries GPBlockingRegKeyPath and GPBlockingRegValueName, naming the exact classic-hive value that gets blocked. The arbiter itself is a single value under PolicyManager\current\device\ControlPolicyConflict, and on this device it reads 1 — consistent with the classic hive holding no deferral values at all.

Microsoft is blunt about the alternative: "it is recommended that the same settings should not be configured in both GPO and MDM policies unless the settings are under the control of MDMWinsOverGP. Otherwise, there will be a race condition and no guarantee which one wins."

Which binary actually reads all this

The arithmetic is not done by Intune. It is done on the box, by components you can version-check.

The version split is the point. wuaueng.dll reads 1509.2607.1012.0 while the OS is 10.0.26200.9168. The update agent is versioned independently of Windows, so "our devices are all on the same build" does not mean they are all running the same deferral-evaluation code.

How to verify: read the effective values off the device

Four keys, in this order. Do not skip to the third: the value of this sequence is watching the intent turn into an effective number.

Step 1 — the applied MDM values

The shared parent key for everything in the next table:

Step 2 — the on-device schema, for units and ranges you can trust

This is the step almost nobody knows about, and it is the one that ends arguments. Every Policy CSP node has a schema subkey on the device carrying its real range, its default, and the classic value it blocks.

Two rows in that table are worth stopping on.

SetActiveHours has no schema subkey because it is not a Policy CSP node. It exists only as an ADMX enable-flag — I confirmed valueName="SetActiveHours" and valueName="SetActiveHoursMaxRange" in the in-box C:\Windows\PolicyDefinitions\WindowsUpdate.admx. A device managed purely by Intune will never have it, so its absence tells you nothing about whether active hours are in force.

ConfigureFeatureUpdateUninstallPeriod has an empty GP-blocking name: MDM-only, no Group Policy twin. Range 2–60 days, matching Intune's "Set feature update uninstall period (2 - 60 days)", measured at 30 here.

Step 3 — the client's own resolved verdict

This is the key that answers "what does the Windows Update agent think it is doing", and it is not the key anyone greps.

Step 4 — the pause status, and the active hours nobody set by policy

Microsoft documents two status values under HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings, and they are the only honest answer to "is this device paused right now": PausedQualityStatus and PausedFeatureStatus, where 0 means not paused, 1 paused, and 2 "auto-resumed after being paused". The companion dates PausedQualityDate and PausedFeatureDate are documented too — but on a never-paused device they do not exist, so a script reading them without a null check reports a blank rather than "never paused".

Microsoft also flags why you cannot trust the console here: "The local group policy editor (GPEdit.msc) won't reflect whether the feature update pause period has expired. Although the device will resume feature updates after 35 days automatically, the pause check box will remain selected in the policy editor."

Active hours are the last trap. The brief for this article expected ActiveHoursStart, ActiveHoursEnd and SetActiveHours to be absent under the WindowsUpdate policy key, and they are. But they are not absent from the device:

Sixteen hours a day of restart suppression, configured by nobody in your management plane, invisible to an audit that only reads policy keys. Microsoft's CSP note is that the default maximum active-hours range is 18 hours from the start time unless ActiveHoursMaxRange says otherwise — and that policy is not set here either, so the user could legally have chosen 18.

The fix: compute days-actually-behind, then hunt the stale pause

The fix is not a registry edit. It is a number you can defend in a risk review, then a search for the control silently holding your fleet.

The arithmetic, on the real measured values

Take Patch Tuesday as day 0 and walk the four clocks with the values measured above — defer 7, deadline 30, grace 7, no-auto-reboot 1.

Now add a pause: an incident the Monday before Patch Tuesday, and someone sets PauseQualityUpdatesStartTime to that date.

Note the second row against the first. Adding a deadline — a control whose whole purpose is to force compliance — more than doubled the exposure window, because it was set to its maximum of 30 while the CSP default is 7. A generous deadline is a deferral in disguise.

Where a stale pause actually comes from

Nobody sets a pause and forgets it on purpose. Two documented Intune behaviours create stale pauses as a side effect.

The first is rollback. Intune's own documentation: "When you initiate an uninstall of feature or quality updates on an Update Ring, Intune also pauses updates of the same type on that Update Ring." Roll back one bad LCU and you have paused the ring, whether or not you meant to.

The second is worse, and it is the one to check first. Deleting the ring does not clear what it set: "Deleting a ring from Intune doesn't modify the settings on devices that were assigned the update ring. Instead, the device keeps its current settings. Devices don't maintain a historical record of what settings they held previously."

Delete the incident-response ring that carried the pause, and the values stay on every device that received it, with nothing left in the portal to show you they exist. That is exactly the fingerprint I found on this device.

The numbered decision path

Run this in order on a device that looks behind. Every step is a read.

1. Read PausedQualityStatus and PausedFeatureStatus under WindowsUpdate\UpdatePolicy\Settings. If either is 1, stop — the device is paused and nothing else in this list matters yet. Go to step 2. If either is 2, a pause expired and auto-resumed; go to step 3. If both are 0, go to step 3.
2. Find the pause anchor. Read PauseQualityUpdatesStartTime / PauseFeatureUpdatesStartTime and the legacy PauseQualityUpdates / PauseFeatureUpdates booleans under PolicyManager\current\device\Update. A date string gives you an expiry: start + 35 days. A legacy boolean at 1 gives 35 days (quality) or 60 (feature) with no visible anchor. Then find which ring still sends it — and whether that ring was deleted.
3. Read the deferrals from the same key, then confirm them against QualityUpdatesDeferralInDays / FeatureUpdatesDeferralInDays under UpdatePolicy\PolicyState. If the two disagree, policy has been changed but not yet resolved by the agent — do not compute anything until they match.
4. Read the deadline trio: ConfigureDeadlineForQualityUpdates, ConfigureDeadlineGracePeriod, ConfigureDeadlineNoAutoReboot. Remember the fallbacks: absent quality grace means 2, absent feature grace means quality grace, then 7. Absent deadline means 7 for quality, 2 for feature.
5. Compute. Days actually behind = deferral + deadline, floored by (install date + grace) if installation lands late. Add the remaining pause days if step 1 said paused.
6. Check the classic hive last, not first. If HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate holds any of the same value names and MDMWinsOverGP under PolicyManager\current\device\ControlPolicyConflict is 0 or absent, Group Policy is winning and your Intune number is fiction.
7. Check active hours under WindowsUpdate\UX\Settings. A 16-hour user-chosen window plus ConfigureDeadlineNoAutoReboot=1 means restarts are only ever attempted in an 8-hour slot — and only if the machine is awake.
8. Check UpdateNotificationLevel. At 2, restart warnings are suppressed. Your users are not ignoring the prompt; they are not getting one.

Proof it worked: a real read-only deferral audit

The audit above, run against the live device, produces a number you can put in a report and a provider GUID you can trace back to a management authority.

The event log corroborates the offering side of this. The channel is:

Look at the ratio: 555 scans, every one reporting zero updates, against 110 downloads. Event 26 is the most common event on the channel and carries almost no information about deferral state, which is exactly why "the device is scanning fine" is not evidence that the device is current.

One last correlation from the same device, proving the offering path is live rather than blocked. The Setup log recorded Event 2 — "Package KB777778 was successfully changed to the Staged state" — at 21:46:02 on 21 August, and Event 1013/1014 (store corruption detection, "Detection Only: 1", zero instances found) later that evening. Staging happens. Scans succeed. The device is not stuck.

That is the distinction this article is about. "Stuck" is a fault you fix. "Thirty-seven days behind by configuration" is a decision somebody made, probably without knowing they were making it, and it appears nowhere in your compliance reporting.

References

• Configure Windows Update client policies — the deferral and pause policy tables, the 35-day pause arithmetic, the PausedQualityStatus / PausedFeatureStatus values, and the GPEdit.msc warning.
• Enforce compliance deadlines with policies — the effective-deadline definition, the scan-discovery anchor, and the grace-period countdown.
• Update Policy CSP — every node name, data type, range and default cited above.
• ControlPolicyConflict Policy CSP — MDMWinsOverGP, its default of 0, and the race-condition warning.
• Manage Windows update ring policies (Intune) — Pause, Resume, Extend and Uninstall behaviour, and the fact that deleting a ring leaves device settings in place.
• Update rings policy settings reference (Intune) — the portal-side ranges, including the 0–30 and 0–365 deferrals and the 2–60 day uninstall period.
• Avoid legacy policy configurations — DeferUpdatePeriod in weeks, DeferUpgradePeriod in months, and the 60-day legacy feature pause.

All registry values, binary versions and event counts here were read read-only from one live Windows 11 Enterprise 25H2 device, build 26200.9168, on 23 August 2026. The console blocks are CSS-simulated reproductions of that output, not screenshots.