One of the more quietly significant changes to land in Intune recently is a new Enrollment Status Page setting that controls whether Windows installs quality updates during OOBE. It sounds straightforward, but the behaviour differences between new and existing ESP profiles, the interaction with update rings, and the way pre-provisioning (White Glove) fits into the picture create enough gotchas to warrant a dedicated post.
This is available now — activated with the January 2026 Windows quality update — and it’s already the default for any new ESP profile you create. If you’re running existing profiles and haven’t reviewed them yet, keep reading.
The problem this solves
Every Autopilot deployment has historically had the same baseline vulnerability: the device image on the shelf is already stale before the box is opened. A laptop imaged in October and deployed in December ships to the user without three months of cumulative security updates. They sign in, OOBE completes, Intune pushes policies and apps — and somewhere in that first-day experience, Windows Update kicks in and starts downloading a sizeable patch payload.
The result is a device that’s non-compliant from the moment the user first touches it, a potential reboot mid-morning on day one, and update traffic that wasn’t planned for. For fleets imaging and deploying at scale, this is a persistent operational friction point.
The new OOBE quality update capability addresses this directly: the device applies the latest monthly security update before handing control to the user, so first sign-in happens on a fully patched system.
How it works
The feature is controlled by a single new setting in the Enrollment Status Page profile:
Devices > Enrollment > Enrollment Status Page > [profile] > Settings
Install Windows quality updates (might restart the device)
When set to Yes, the device performs a Windows Update check at the final OOBE screen and installs any applicable monthly security update before completing setup. When set to No, provisioning continues to desktop without that update pass.
Under the hood, the Windows Management Service writes a registry value early in the ESP:
HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device\Setup\Policy\InstallQualityUpdates
Value 1 installs updates during OOBE; value 0 skips them. The ESP sets this before the final Windows Update check runs, so the decision is baked in at provisioning time.
Key detail: The 2026-01 B quality update (January 13, 2026) is the first update offered once the feature is active. The OS enforcement for this setting is also included in that same January 2026 cumulative update, so devices need to have it or the November 2025 non-security update (or the November 2025 OOBE zero-day patch) in the image for the control to function correctly.
Default behaviour: new vs. existing profiles
This is the part most likely to catch you off guard if you’re managing an established Autopilot deployment.
| Profile type | Default value | What happens |
|---|---|---|
| New ESP profiles (created now) | Yes | OOBE quality update runs by default unless you explicitly disable it |
| Existing ESP profiles (pre-feature) | No | No change to existing provisioning behaviour — you must edit the profile to opt in |
| Autopilot Device Preparation (AP-DP) | Yes (always on) | No ESP toggle — quality updates during OOBE are always applied; there is no current off switch |
Watch out: If you create a new ESP profile today — for a new deployment ring, a new device type, anything — that profile will have OOBE quality updates enabled by default. If your provisioning process doesn’t account for the extra time or a potential restart, this will surprise you in production.
Prerequisites
Not every device in your fleet will qualify. Before enabling this for a group, verify the following:
- OS version: Windows 11, version 22H2 or later (24H2 and 25H2 supported). Windows 10 is not supported.
- SKU: Pro, Enterprise, Education, or SE. Consumer SKUs are out of scope.
- Join type: Entra joined or Entra hybrid joined.
- Management: Device must be managed by Intune (or a third-party MDM that explicitly integrates ESP functionality).
- ESP profile targeting: Must use device targeting — either the Autopilot preregistered device group or the “All devices” assignment. User-targeted ESP profiles do not support this setting.
- Image currency: Device image must include the November 2025 non-security update or later, or must be automatically updated by the November 2025 OOBE zero-day patch (ZDP) before the ESP runs. Without this, the OS control is absent and the setting has no effect.
- Network: Quality updates are not installed during OOBE on metered connections. Ensure provisioning environments have unmetered network access.
The update rings co-assignment: don’t skip this
One of the less obvious requirements is that your Windows Update rings policy needs to be assigned to the same device group as your ESP profile. If it’s not, your deferral and pause settings may not be applied before the OOBE update check runs — meaning a device that should be deferring the current month’s update might install it anyway.
The sequence during provisioning is:
- Device phase of ESP begins
- Intune synchronises the Windows Update rings policy to the device before exiting the device phase
- Final OOBE Windows Update page runs the quality update check
- Update rings settings (pause, deferral) are now in place and honoured
If the rings policy isn’t co-assigned, step 2 doesn’t happen reliably, and step 4 can’t enforce your deferral windows. Assign both the ESP profile and the update rings policy to the same Autopilot device group (or to All devices) to ensure consistent behaviour.
Note: Feature updates are handled separately and are not installed during OOBE by this setting. This covers monthly security updates (quality updates) only. Your feature update policies apply after OOBE completes as normal.
Pre-provisioning (White Glove): what actually happens
If you’re running Autopilot pre-provisioned deployments, the behaviour here is different from what you might expect — and it’s important to understand before enabling this at scale.
The Install Windows quality updates setting is only evaluated during the user-driven OOBE flow. During the technician phase of pre-provisioning, the setting is skipped entirely. This means:
- The device does not install quality updates during the technician flow, regardless of what the ESP setting says.
- When the user receives the device and powers it on, the user phase of OOBE runs — and if the ESP is configured with the setting enabled, the update check happens there.
- The user will see the Windows Update screen and wait through the install (plus a potential restart) before reaching the desktop.
For organizations using pre-provisioning specifically to hand users a fully-ready device with minimal setup time, this is a meaningful gap. The ideal flow — device patched in the technician phase, sealed, delivered, and handed to user without an update wait — is not currently supported.
Pre-provisioning gotcha: If your ESP has ‘Install Windows quality updates’ set to Yes and your users are going through the user phase of a pre-provisioned Autopilot, they will see the update screen on first sign-in. Factor this into your user communication and provisioning SLAs. Until Microsoft adds technician-phase support, consider whether disabling the setting for your pre-provisioned device groups makes more operational sense.
Provisioning time and bandwidth impact
Enabling quality updates during OOBE adds time to the provisioning process. Testing has shown roughly 20 to 40 minutes of additional provisioning time depending on update size, device hardware, and network speed. This isn’t negligible for high-volume deployment scenarios.
Additional considerations:
- Restart behaviour: The update process may trigger a device restart. If a restart occurs during OOBE, Windows will return to a lock screen requiring the user to sign in again before account setup continues — the restart does not break provisioning, but it does add friction and extends total setup time.
- Bandwidth at scale: Large batch deployments where many devices provision simultaneously can generate significant Windows Update traffic. Configure Delivery Optimization and peer caching for provisioning environments to absorb this, particularly if you’re running large imaging events.
- Hybrid join time-out risk: There is a documented known issue where OOBE quality update scans can time out during Autopilot Entra hybrid joined deployments when the Allow OOBE Updates policy is configured. Devices affected by this will not receive the quality update during OOBE, but provisioning continues normally. Test this scenario specifically in your hybrid environment before broad rollout.
How to configure it
For new ESP profiles
New profiles default to Yes. If you want to disable OOBE quality updates for a new profile (e.g. for pre-provisioned or kiosk device groups), explicitly set it to No when creating the profile. Don’t rely on the default without a conscious decision.
For existing ESP profiles
Existing profiles default to No. To enable OOBE quality updates on an existing profile:
- Intune admin center > Devices > Enrollment > Enrollment Status Page
- Select the ESP profile you want to update
- Go to Properties > Settings > Edit
- Locate Install Windows quality updates (might restart the device) and set to Yes
- Select Review + save
Ensuring update ring co-assignment
In the Intune admin center, navigate to your Windows Update rings policy and verify its assignments include the same Autopilot device group (or All devices) as your ESP profile. Both must be assigned to the same scope for deferral and pause settings to apply consistently during OOBE.
Should you enable it? A decision guide
| Scenario | Recommendation |
|---|---|
| User-driven Autopilot, up-to-date images, unmetered network | Enable. Devices arrive at first sign-in fully patched. |
| User-driven Autopilot, older images or slow/metered networks | Test in pilot first. Measure provisioning time impact before broad rollout. |
| Pre-provisioned (White Glove) deployments | Disable for the pre-provisioned device group, or accept that the user phase will include the update wait. Communicate to users accordingly. |
| Autopilot Device Preparation (AP-DP) | No action available — quality updates during OOBE are always on for AP-DP. |
| Kiosk or shared device deployments | Evaluate case by case. Provisioning time impact may be acceptable; restart behaviour during user phase may not be. |
| Entra hybrid joined environments | Test specifically for the hybrid join timeout issue before enabling broadly. Run a pilot with telemetry enabled. |
The bottom line
This is a genuinely useful feature that solves a real problem — the day-one patch gap has been a friction point in Autopilot deployments since the beginning. The implementation is clean: it’s an opt-in/opt-out ESP setting with sensible defaults (new profiles on, existing profiles off), and the update ring integration means your existing deferral policies are respected.
The sharp edges are mostly around pre-provisioning and the default-on behaviour for new profiles. If you’re actively building new ESP profiles right now, check that setting intentionally rather than inheriting whatever default is set. And if you’re running White Glove at scale, set expectations with your service desk about the user-phase update experience before you enable this broadly.
A pilot group, a bandwidth measurement, and a pre-provisioning test with a representative image are all the validation you need before rolling this out to your full fleet.
Hope this helps!
É
