Your Update Deferral Policy And The Quality Update Autopilot Installs During OOBE Meet Inside The ESP

A brand new laptop finishes Windows Autopilot provisioning, reaches the desktop, and immediately puts a restart prompt in front of the user. Another laptop from the same batch reaches the desktop looking clean, then stays a month behind on patches for a fortnight. Neither outcome was chosen by anybody. Both are the same collision. The out-of-box experience (OOBE) wants to install this month's monthly security update release. Your Windows Update deferral policy wants to hold it back. They meet inside the Enrollment Status Page (ESP), and the order in which they meet decides what the user sees.

The problem: the device patched itself, or refused to, and nobody decided which

For years a device that came out of Autopilot was a device on whatever build the factory image shipped with. Patching was somebody else's problem, handled later by Windows Update for Business. That has changed. Microsoft now documents that the Windows out-of-box experience installs the latest available monthly security update releases by default, so devices are secure and up to date from day one.

Microsoft's wording on the new control is worth quoting, because it sets expectations correctly: "Windows OOBE is used by Intune and by Windows Autopilot scenarios through the Intune enrollment status page (ESP) configurations." This is not a separate Autopilot feature. It is Windows OOBE behaviour, gated by an Intune ESP setting.

That produces three symptoms in the field. All three look like bugs when you do not know the mechanism.

The first symptom is provisioning that takes far longer than your fleet baseline. Microsoft states that installing the quality updates during OOBE adds 20 to 40 minutes to the provisioning process. The documented default ESP time limit is 60 minutes. If you never raised that limit, you have now asked one hour to cover both your application payload and a cumulative update.

The second symptom is a freshly provisioned device that wants to restart. Microsoft documents that a restart might be required, and that if a restart occurs, the user is not automatically signed in to Windows. On a self-deploying or kiosk device that relies on autologon this is not cosmetic. Microsoft says restarts "can break some autologon provisioning scenarios".

The third symptom is the opposite, and it generates the angriest tickets. An administrator turns the setting on, watches a provisioning run, and sees no update screen at all. The device reaches the desktop on the same build it started on. Nothing failed. The Windows Update scan ran, obeyed a 30-day quality deferral, found that the current monthly release was 11 days old, and correctly offered nothing.

Why it happens: two update regimes meet inside the ESP

The mechanism is a sequence, and the sequence is documented. Understanding it removes almost all the surprise.

Step one: the ESP setting decides whether a scan happens at all

The setting is Install Windows quality updates (might restart the device). Microsoft describes what each value does. Set to Yes, "at the end of OOBE, the device checks Windows Updates for any missing and applicable monthly security update releases", and a page shows the update progress if updates are found. Set to No, monthly security update releases are not installed and the device continues to the desktop as usual.

Two documented details about the default trip people up. On new ESP profiles the setting defaults to Yes. On existing ESP profiles it defaults to No until you edit the profile. So a tenant with a five-year-old ESP profile behaves differently from a tenant that created one last week, with no visible difference until you open the blade.

The documented click path to change it is:

1. Sign in to the Microsoft Intune admin center.
2. Select Devices, expand Device onboarding, then select Enrollment.
3. On the Windows tab, under Windows Autopilot, select Enrollment Status Page.
4. Select the profile that applies to your provisioning devices, then select Properties.
5. In the Settings section, select Edit.
6. Set Install Windows quality updates (might restart the device) to Yes or No deliberately, then select Review + save.

Step two: the ring policy has to arrive before the scan

This is the part that answers the deferral question directly. Microsoft's documentation says: "Update rings settings, such as monthly security update release deferrals and pauses, are honored. The ESP page doesn't exit until ring settings are synced. This process ensures sure that the right settings are used when Windows Update scan occurs."

So the two intentions are not actually racing. The ESP is designed to sequence them. Elsewhere in the same article Microsoft is explicit about the order: "ESP applies any Update rings policies and then applies the quality updates. So, your organization policy is honored."

That is the good news. The bad news is that this ordering guarantee depends on a second setting entirely.

Step three: the deferral does exactly what deferrals do

Once the ring policy is on the device, the OOBE scan is governed by it. The relevant node is DeferQualityUpdatesPeriodInDays, documented in the Policy CSP with an allowed range of 0 to 30 days and a default of 0. Microsoft's description of the matching Intune setting is unambiguous about the arithmetic: "Specify the number of days from 0 to 30 for which quality updates are deferred."

Play that forward on a real calendar. Monthly security update releases publish on the second Tuesday of each month. Suppose you set a 14-day quality deferral, which is a completely reasonable production value, and you provision a device on the 16th. The current release is four days old. The scan runs, the deferral holds it, and nothing installs. The device reaches the desktop on the factory build. That is your policy working, not the feature failing.

A pause behaves the same way but harder. PauseQualityUpdatesStartTime takes a date string, and Microsoft documents the pause period as 35 days from the specified start date. While the pause holds, provisioning devices get nothing, which is usually exactly what you want during an incident.

Step four: where the assignment can quietly miss

Microsoft lists the supported configurations. The device must run a currently supported version of Windows 11, and be assigned an ESP profile with the setting configured to Yes. It must also be either registered for Windows Autopilot, or, if it is not registered, assigned using the All Devices assignment. The same article adds that for a device not registered as a Windows Autopilot device, All Devices assignments must be used for both the Update Rings and the ESP profile settings.

Two scenarios are documented as unsupported outright. Windows Autopilot device preparation does not use the ESP, so the setting is not applicable and monthly security update releases cannot install during OOBE. And in Windows Autopilot for pre-provisioned deployment, the updates are not installed during the Technician Flow, though the setting is honoured during the User Flow.

How to verify: read the policy the device actually resolved

Console reporting tells you what you assigned. It does not tell you what the device resolved. For that you read the registry, and this is where a lot of published guidance goes wrong.

Microsoft's Update ring troubleshooting article states it directly: "If Intune successfully deploys the Windows Update ring policies to the target device, those settings appear in the Registry Editor under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update." The same article repeats the path when describing how to monitor the Windows Update source keys.

There are three registry surfaces involved, and they are easy to confuse.

Here is the read, on the correct key.

The same values in Registry Editor, so you know what a correct read looks like on a device that has both an MDM deferral and a Group Policy leftover.

Every node worth checking after a provisioning run, all under that same parent key.

Then check the diagnostic surface. Microsoft's troubleshooting guidance points at two channels. Policy delivery shows up under Applications and Services Logs, then Microsoft, then Windows, then DeviceManagement-Enterprise-Diagnostics-Provider, then Admin. Update client behaviour shows up under WindowsUpdateClient, then Operational.

The fix: design rings that cooperate with provisioning

The goal is not to pick a side. It is to make the sequence deliberate. Six changes do it.

1. Make the ESP blocking, or the sequencing guarantee does not apply

Set Block device use until all apps and profiles are installed to Yes in the ESP profile your provisioning devices actually receive. This is the documented prerequisite for the Windows Update client policies and the monthly security update releases both being applied before the device reaches the desktop.

2. Give the ESP a time limit that can absorb an update

The documented default is 60 minutes, set through Show an error when installation takes longer than specified number of minutes. Microsoft documents that the OOBE quality update adds 20 to 40 minutes. Add that to your measured application install time and set the limit from evidence, not habit.

3. Assign the Update ring to the same population as the ESP profile

The documented path for the ring policy:

1. Select Devices, then Windows, then Update rings for Windows 10 and later.
2. Open, or create, the ring that provisioning devices will receive.
3. Under Update settings, set Quality update deferral period (days) to the value you actually intend for a day-zero device.
4. Under User experience settings, review Automatic update behavior, Active hours start and Active hours end, because these govern the first restart.
5. In Assignments, target the same devices your ESP profile targets. For devices not registered for Windows Autopilot, Microsoft documents that All Devices must be used for both the ring and the ESP profile.
6. Confirm delivery on the ring's View report, then verify on a device using the registry read above.

4. Decide the provisioning deferral on purpose

A dedicated provisioning ring with Quality update deferral period (days) set to 0 means a device leaves OOBE current. Your production rings can keep whatever deferral your change process requires, because they apply to devices already in service. If instead you want new hardware to arrive on the tested build, keep the deferral and accept that the OOBE update stage will usually find nothing. Both designs are valid. What is not valid is inheriting a 30-day deferral by accident and then filing a bug against the ESP setting.

5. Handle the autologon and pre-provisioning cases explicitly

For self-deploying, kiosk and Teams Rooms style devices that depend on autologon, Microsoft's recommendation is direct: in these scenarios, set Install Windows quality updates to No. For Windows Autopilot device preparation, and for the Technician Flow of a pre-provisioned deployment, the setting is not honoured at all, so plan the first patch cycle for after provisioning rather than during it.

6. Cover the Group Policy path, and know when it applies

The same deferral exists in Group Policy, and the Policy CSP documents the mapping. The Group Policy path is:

The feature update equivalent is Select when Preview Builds and Feature Updates are received, in the same folder. Both come from WindowsUpdate.admx, and both write into HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. On a Microsoft Entra joined Autopilot device there is no domain Group Policy in play during OOBE, so this path matters in two situations. The first is a Microsoft Entra hybrid joined deployment, where policy arrives once the device can reach a domain controller. The second is a co-managed estate where an old object is still writing values. Microsoft also lists a limitation worth remembering as a known issue: "ESP doesn't apply to a Windows device that was enrolled with Group Policy (GPO)."

Proof it worked: a boring first boot

A correctly designed provisioning path produces an unremarkable device. The companion script reads the resolved policy, the competing Group Policy surface, the build, the pending reboot markers and the Windows Update client events, then gives you a single verdict.

Run it as a Microsoft Intune Remediations detection script, as a Win32 app detection script, or as a one-off sweep across a build batch. Add -JsonPath for an inventory pipeline, -EventLookbackDays 3 immediately after a provisioning run, and -SkipEventLog when the session is not elevated. It is read-only, and it aborts rather than reporting an empty policy set, because "no deferral configured" and "could not read the key" are very different conclusions.

Then close the loop in the console and confirm the two settings agree with each other.

A good outcome looks like this. The ESP profile is device-assigned and blocking. The resolved DeferQualityUpdatesPeriodInDays matches the ring you intended for day-zero hardware. No pause date is set unless you set it. No values sit under the Group Policy WindowsUpdate key. The Operational channel shows 26, then 41, then 19, and any event 21 is followed by a restart that happened inside provisioning rather than in front of the user. When that is true across a whole build batch, your deferral policy and your provisioning process have stopped arguing, because you decided the order instead of discovering it.

References

• Set up the Enrollment Status Page — Microsoft Intune. The Install Windows quality updates (might restart the device) setting, the 60 minute default time limit, the 20 to 40 minute provisioning cost, the supported configurations, the blocking prerequisite, and the Update rings and Windows Autopatch guidance.
• What's new in Windows Autopilot — Microsoft Learn. The announcement entry, the new-versus-existing ESP profile defaults, and the note that the capability is included in the Windows 2026-01 B quality update.
• Troubleshoot Update ring policies for Windows devices — Microsoft Intune. The documented resolved-policy path PolicyManager\current\device\Update, the Group Policy WindowsUpdate keys, and the two Event Viewer channels.
• Policy CSP - Update — Microsoft Learn. Node names, formats, allowed ranges and defaults, plus the Group Policy friendly names, paths and the WindowsUpdate.admx mapping.
• Update ring policy settings — Microsoft Intune. The exact Update ring setting labels, the 0 to 30 and 0 to 365 deferral ranges, and the deadline and grace period settings.
• Windows Update client policies — Microsoft Learn. The rename from Windows Update for Business, the maximum deferral table, and the 35 day pause window.
• Update release cycle for Windows clients — Microsoft Learn. What a monthly security update release is, why it lands on the second Tuesday, and how it differs from an optional nonsecurity preview release.
• WUA Update Installation — Microsoft Learn archive. The documented installation event IDs 19 through 24, including the reboot-required events.
• WUA Update Detection — Microsoft Learn archive. The documented detection event IDs, including 25 and 26.
• WUA Update Download — Microsoft Learn archive. The documented download event IDs, including 17, 18, 31 and 41.
• Get ready for Windows quality updates out of the box — Windows IT Pro Blog. The announcement post that Microsoft's Autopilot documentation links to for background.
• Questions with policies and profiles in Microsoft Intune. The documented refresh cadence for a newly enrolled Windows device: every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then around every 8 hours.

Microsoft MVP community deep-dives