Microsoft’s plan to install Windows quality (monthly security) updates during the out-of-box experience (OOBE) for managed Windows 11 devices is now a live, configurable admin control — but it comes with caveats, prerequisites, and real-world trade-offs that every IT team should evaluate before flipping the switch.
Background / Overview
For years IT teams have wrestled with two realities: getting freshly imaged or newly provisioned devices to a secure baseline before first use, and keeping the end-user onboarding experience fast and painless. Microsoft’s recent rollout of OOBE quality-update support seeks to bridge those goals by allowing eligible devices to check for and install applicable
monthly quality updates during the final page of OOBE so that the first sign-in already happens on a patched system.
This capability is surfaced as a new Microsoft Intune Enrollment Status Page (ESP) setting called
Install Windows quality updates (might restart the device). When configured to
Yes, the device will perform a Windows Update scan at the last OOBE screen and apply any relevant monthly security updates prior to handing the device to the user. When configured to
No, OOBE continues to desktop without applying those quality updates.
The feature was announced in mid‑2025, rolled into Intune’s ESP controls during the late‑summer service release, and Microsoft scheduled enforcement as part of the Windows servicing cadence (with a planned enforcement window in the January 2026 security update). Multiple official product pages and independent industry outlets confirm the feature mechanics, the supported device targeting, and the major prerequisites that govern whether a device can or will apply updates during OOBE.
Why this matters now
- Security from day one: Devices that receive the latest monthly security updates in OOBE reduce the window in which newly provisioned machines may be vulnerable to recently disclosed threats.
- Lower post‑deployment churn: IT helpdesks and issued‑device workflows commonly include immediate update activity after first sign-in. Applying quality updates during OOBE can reduce that post‑deployment update traffic and reboot activity during the user’s first day.
- Operational control through Intune: Rather than making this behavior mandatory for all devices, Microsoft provided a policy control in Intune so administrators can decide which device groups should apply updates during OOBE and which should not.
However, this isn’t a universal “turn on and forget” change — it affects provisioning timelines, restart behavior, pre‑provisioning flows, and network bandwidth planning. The rest of this article breaks down the details you need to plan a safe adoption.
Supported scenarios and hard prerequisites
Device eligibility (what Microsoft requires)
To honor the ESP “Install Windows quality updates” setting, a device must meet all of the following:
- Running Windows 11, version 22H2 or later.
- One of these SKUs: Pro, Enterprise, Education, or SE. Consumer SKUs are not in scope for Intune‑managed ESP installs during OOBE.
- Managed by Microsoft Intune (or an alternative MDM that explicitly integrates the Enrollment Status Page functionality).
- Assigned an ESP profile that uses device targeting — either as devices registered for Windows Autopilot (Autopilot preregistered device group) or by assigning the ESP profile to All devices. User‑targeted ESP profiles are not supported for this setting.
- The device image or runtime must include the OS update that introduces the control (updates published mid‑2025 and later). Devices should be imaged with the June/November 2025 non‑security update or receive the relevant OOBE zero‑day patch (ZDP) so the new control is present in the OS.
If a device does not meet these requirements, the ESP will not honor the Install Windows quality updates setting and quality updates won’t be installed during OOBE for that device.
Notable exceptions and unsupported flows
- Windows Autopilot device preparation (pre‑provisioning / White Glove): The technician flow does not apply the setting — the OOBE update flow is honored only in the user phase, not during the technician phase. That means large organizations using pre‑provisioned images must plan carefully; the update can interrupt autologon flows.
- Technician Flow (white glove) limitations: Applying an enforced OOBE update and subsequent restart in technician flows may break the automated technician provisioning unless specific safeguards are in place.
- Metered networks: Monthly quality updates aren’t installed during OOBE when the device is on a metered network.
- Third‑party patching solutions: If your environment relies on a third‑party patch broker that bypasses Windows Update or doesn’t integrate with ESP, the OOBE quality‑update path may not be usable for those devices.
- Expedited updates and feature updates: Expedited update types (critical hotfix scenarios outside monthly quality updates) aren’t part of the OOBE install; feature updates are handled separately after OOBE as per your configured feature‑update policies.
How the setting works in Intune (practical details)
Microsoft added the control to the Intune Enrollment Status Page profile settings. Administrators will find it in the Intune admin center under:
Devices > Enrollment > Enrollment Status Page
Within an ESP profile’s Settings tab, locate
Install Windows quality updates (might restart the device). The choices are:
- Yes — At the final OOBE page the device will check Windows Update and install any missing applicable monthly security updates. The ESP applies Windows Update rings settings first (so pause/deferral policies can be enforced) and then triggers quality update installation.
- No — Device proceeds to desktop without installing monthly security updates during OOBE.
Important implementation details IT teams should note:
- New ESP profiles created after the rollout initially default to Yes in the early releases; existing ESP profiles defaulted to No. (Administrators must explicitly edit existing profiles to enable the behavior.
- Microsoft has stated that the OS enforces the behavior as part of a later monthly security update; early availability in Intune may have been controllable before enforcement. Administrators should expect some tenant‑by‑tenant timing differences as Microsoft stages the service.
- Installing quality updates during OOBE adds provisioning time — Microsoft reported roughly 20–40 minutes in private preview depending on the size and number of updates and device characteristics. Restarts can occur as part of the process; a restart during OOBE will not automatically sign the user in.
- To ensure pause/deferral settings are honored, assign the Windows Update rings profile to the same device group as the ESP profile (or use All devices). During the device phase ESP synchronizes the rings’ policy prior to exiting the page so that Windows Update honors your update deferrals and pauses when the final Windows Update check runs.
Step‑by‑step: recommended admin checklist before enabling OOBE quality updates
- Confirm device image and updates
- Ensure images include the June/November 2025 OS changes (or the OOBE ZDP) that add the OS control, or plan to install the relevant monthly security update that Microsoft notes enforces the behavior.
- Audit device targeting
- Verify devices are registered for Windows Autopilot or are covered by an All devices assignment. User‑targeted ESPs won’t work for this setting.
- Review ESP profiles
- In Intune, open the ESP profile(s) to see the Install Windows quality updates control. Edit existing profiles you want to change from No to Yes.
- Align Update rings
- Assign the Windows Update rings profile to the same Autopilot device group (or All devices) as the ESP profile so that pause/deferral settings are applied before the final OOBE update check.
- Pilot in a controlled group
- Create a pilot group with a representative hardware mix and real‑world network conditions to measure time added to OOBE, restart behavior, and any breakages in provisioning flows (especially autologon and provisioning scripts).
- Consider bandwidth and Delivery Optimization
- For large rollouts, Delivery Optimization and peer caching reduce peak bandwidth demand during provisioning. Plan background download distribution windows.
- Adjust pre‑provisioning strategy
- If you rely on the Autopilot device preparation/technician flow, consider disabling OOBE quality updates for those devices or rework the provisioning pipeline because the technician flow may not account for restarts.
- Monitor and rollback
- Use telemetry and deployment reports to monitor provisioning times and failure rates. If you see regressions, flip the ESP setting back to No for the affected groups.
Benefits (what IT teams gain)
- Faster security posture: Devices come online with the latest monthly security updates applied, reducing the period between device delivery and being fully patched.
- Reduced first‑day reboots for users: Installing the patch before first sign‑in reduces surprise reboots and background update activity for new users.
- Policy alignment: Because ESP syncs Windows Update rings first, organizations can still enforce deferrals and pauses and maintain corporate update policies even for OOBE installs.
- Simplified lifecycle management: Reduces the number of post‑deployment update cycles IT teams must manage immediately after deployment.
Risks and trade‑offs (what to watch out for)
- Longer OOBE times and user friction: An extra 20–40 minutes on OOBE can be unacceptable for some onboarding scenarios. In many enterprise environments, users or technicians expect a quick first sign‑in.
- Breakage in pre‑provisioned/white glove scenarios: Automatic restarts during OOBE can leave pre‑provisioned devices stuck in DefaultUser0 or break autologon counts unless your process accounts for the restart behavior.
- Device targeting blind spots: If some of your fleet is not Autopilot registered or uses user‑targeted ESPs, those devices won’t benefit and could still require post‑deployment patching.
- Bandwidth spikes: Large fleets imaging overnight and provisioning next day may generate considerable Windows Update traffic if many devices attempt to patch simultaneously.
- Third‑party patch tools: Organizations that centralize patch distribution through WSUS, SCCM, or third‑party tooling must validate compatibility — ESP’s OOBE update path uses Windows Update and Windows Update for Business semantics, and non‑Microsoft patch chains may not trigger it.
- Metered or limited networks: Devices on metered networks won’t install quality updates during OOBE, possibly creating inconsistent exposure across locations.
- Autopatch/hotpatch exceptions: Some update types (hotpatch) are managed differently; expedites may not be part of the OOBE flow and will apply later.
Best practices and recommendations
- Pilot first, then expand: Roll out OOBE update installs to a controlled pilot group that mirrors production hardware. Measure OOBE time, restart behavior, completion rates, and helpdesk calls.
- Keep the ESP and Update rings co‑assigned: Assign both the ESP and Windows Update rings to the same Autopilot device group or All devices so pause and deferral policies are enforced consistently.
- Avoid enabling for pre‑provisioned/technician flows: Until Microsoft provides more robust safeguards for the technician flow, disable OOBE updates for Autopilot device preparation groups to avoid broken provisioning scenarios.
- Use Delivery Optimization and caching: Configure Delivery Optimization and peer caching for new devices to limit internet bandwidth consumption during large deployments.
- Set Block device use until all apps and profiles are installed (when needed): If you must ensure updates are applied before user access, configure ESP’s “Block device use until all apps and profiles are installed” to Yes so the ESP won’t exit prematurely and leave updates uninstalled.
- Monitor message center and tenant notifications: Microsoft stages feature availability and enforcement; always check your tenant’s Message Center or Intune “What’s new” for the precise rollout window for your tenant.
- Document fallback and rollback steps: If you encounter provisioning issues, know which ESP profile to edit and how to revert the setting. Maintain a communication plan for users and technicians.
Procedural example: minimal safe rollout (recommended sequence)
- Update a test image to include the OS patches that contain the ESP control (June/November 2025 non‑security updates or the OOBE ZDP).
- Create a pilot device group in Autopilot and register a small set of devices.
- Create/update an ESP profile:
- Settings → Install Windows quality updates = Yes
- Block device use until all apps and profiles are installed = Yes (optional for strict controls)
- Create an Update rings policy with your deferral/pause settings and assign to the same Autopilot device group.
- Provision devices and measure:
- Time from power‑on to desktop
- Number and timing of restarts
- Any provisioning failures or stuck states
- After successful pilot (no provisioning blockages), expand assignment to larger groups in staged waves while continuing to monitor.
What to verify in your tenant right now
- Confirm whether the Install Windows quality updates control is present in your tenant’s Intune admin center.
- Check the default value for new ESP profiles in your tenant; historically Microsoft has defaulted new profiles to Yes while existing profiles remained No — but rollout timing and defaults can change as Microsoft updates enforcement months.
- Review the Message Center (or Microsoft 365 admin notifications) for the specific Message Center change or plan item that applies to your tenant, and note the exact date/KB linked to enforced behavior.
- Confirm whether your images already include the OS update or ZDP that adds the OS‑level support for the control; without that, the ESP setting may be present but not enforced by the OS.
Note: There has been some public discussion and iterative messaging from Microsoft about deployment timing and default values. Administrators should not assume a single global default applies to every tenant and should verify their tenant UI and Message Center notifications. If you see messaging in community posts suggesting the default behavior will change (enabled vs disabled by default), reconcile that with the Message Center entry that targets your tenant — Microsoft often stages changes.
Final assessment — is enabling OOBE quality updates right for your organization?
Enable OOBE quality updates during provisioning if:
- Your organization prioritizes immediate security posture and can accept the added provisioning time.
- Devices are Autopilot‑registered or covered by All devices assignment, and you can assign Update rings to the same groups.
- You have tested and validated that technician/pre‑provisioning workflows won’t be broken by restarts.
- Your network and Delivery Optimization configuration can handle the extra update traffic.
Delay or disable it if:
- You rely extensively on Autopilot device preparation/technician flow that cannot tolerate restart‑driven breaks.
- You cannot tolerate extended OOBE times for users or technicians.
- You have complex third‑party patching flows that don’t integrate with Windows Update and ESP.
- You’re still validating app compatibility with the latest monthly updates and need more time to stage updates through test rings.
Closing perspective
Microsoft’s ESP OOBE quality‑update capability is a meaningful step toward reducing the gap between provisioning and baseline security. It gives administrators a modern lever to reduce post‑deployment patching and produce more consistent security posture on day one. Yet it is not an automated panacea — the added time, restart behavior, and integration limitations with pre‑provisioning flows and non‑Intune patch solutions mean that the feature must be treated as another policy tool to be planned, tested, and controlled.
Administrators should pilot the feature, align Update rings and ESP assignments, and validate pre‑provisioned flows before broad adoption. Where the business prioritizes security upon first use and can tolerate a lengthened OOBE, the capability will meaningfully reduce early lifecycle patch work. Where speed of user onboarding or technologically constrained provisioning processes dominate, keep the ESP control off for those device groups until Microsoft provides fuller support for technician/pre‑provisioning flows and additional safeguards.
In short: this is a valuable capability — but it requires thoughtful operational changes and testing to deliver security without user disruption.
Source: Microsoft - Message Center
Get ready for Windows quality updates out of the box - Windows IT Pro Blog