Windows OOBE Now Applies Quality Updates at Day One (KB5065847)

Microsoft’s August 29, 2025 OOBE update (KB5065847) marks a deliberate pivot in how Windows 11, version 24H2 and Windows Server 2025 handle day‑one security and servicing: managed devices that meet the eligibility rules can now check for and install Windows quality updates during the final Out‑of‑Box Experience (OOBE) before the first user sign‑in. This change—exposed through Enrollment Status Page (ESP) controls for Microsoft Intune and enabled by default for new ESP profiles where the servicing payload is present—aims to close the long-standing “day‑one patch gap,” but it also forces administrators to rethink provisioning time, network capacity, and remediation playbooks. (techcommunity.microsoft.com)

Background / Overview​

The Out‑of‑Box Experience (OOBE) has evolved from a simple first‑run wizard into a bootstrap point where provisioning, enrollment, and compliance decisions take place. Historically, freshly imaged or factory‑fresh devices could arrive several months behind on cumulative security patches; administrators had to schedule immediate update waves and expect a rash of help‑desk tickets the moment users signed in. Microsoft’s OOBE updates, culminating in KB5065847, make applying quality updates (monthly cumulative security and reliability fixes) during the last stage of OOBE a managed, controllable option for IT‑managed devices. (techcommunity.microsoft.com)
Microsoft’s official rollout messaging frames the objective plainly: ensure devices are delivered to users already patched to a known baseline. The change is limited in scope—Microsoft distinguishes quality updates from feature updates and broad driver distributions—and it is targeted at Microsoft Entra‑joined and Entra hybrid‑joined devices enrolled in Intune (or other MDMs that support ESP). Administrators gain a single control point in the Autopilot/ESP experience to allow or block OOBE quality updates; new ESP profiles will default to enabling the capability if the required servicing payload is present. (techcommunity.microsoft.com)

---

What KB5065847 actually does​

Core behavior (short)​

• During the final OOBE screen, eligible Windows 11, version 24H2 and Windows Server 2025 devices will check Windows Update for applicable quality updates and, if available, download and install them before the first sign‑in. This can include the combined Servicing Stack Update (SSU) + Latest Cumulative Update (LCU) payloads when appropriate. (techcommunity.microsoft.com)

Eligibility and scope​

• Applies to Windows 11, version 24H2 and Windows Server 2025 images that include the OOBE servicing payload delivered via Microsoft servicing channels.
• Targets managed SKUs and device states: Microsoft Entra‑joined or Entra hybrid‑joined devices that are managed by Intune (or an MDM that supports ESP). Consumer/unmanaged Home devices are not the primary audience. (techcommunity.microsoft.com)

What will (and will not) be installed​

• Will target quality updates—monthly cumulative security and reliability fixes (LCU/SSU).
• Will not install feature updates or broad driver packages during OOBE; those remain under the normal feature upgrade and driver distribution processes. Microsoft may still apply targeted Zero‑Day Patches (ZDPs) through the OOBE ZDP flow if required, but ZDPs are handled separately. (techcommunity.microsoft.com)

Management surface​

• The state of this capability is surfaced via the Enrollment Status Page (ESP) settings in Microsoft Intune (Devices → Enrollment → Enrollment Status Page). New ESP profiles that are created after the servicing payload is present will show the quality‑update toggle enabled by default; preexisting ESP profiles will retain their current settings and must be edited to opt in. There is also a Group Policy / MDM policy surface for non‑Intune environments where supported. (techcommunity.microsoft.com)

User experience impact​

• OOBE may require additional time to complete: real‑world pilots and guidance point to tens of minutes added depending on update size, device performance, and network speed. Devices may reboot one or more times before landing on the desktop. Administrators should plan accordingly. (dataconomy.com)

---

Why Microsoft is making the change — rationale and benefits​

Microsoft’s rationale is straightforward: freshly provisioned devices are high‑value targets and often arrive out of date. By moving quality updates into OOBE, Microsoft reduces the exposure window between first boot and first sign‑in, lowers immediate post‑provisioning patch‑and‑reboot cycles, and improves compliance reporting from minute zero.
Key benefits Microsoft and early adopters cite:

• Day‑one security baseline — endpoints are less likely to be vulnerable on first use.
• Fewer help‑desk incidents — fewer users calling because their new device insists on dozens of updates after first sign‑in.
• Cleaner enrollment compliance — inventory and compliance tools report devices at a more current baseline immediately after provisioning. (techcommunity.microsoft.com, dataconomy.com)

---

Operational trade‑offs and real‑world risks​

While the security benefits are compelling, the move carries operational costs and potential hazards that require careful planning.

• Longer provisioning time: Expect device setup to take longer—commonly 20–30 minutes or more depending on network conditions and the update payload. For high‑volume deployments this translates to increased staging time and possible throughput bottlenecks.
• Network and bandwidth impact: Large numbers of devices checking for updates simultaneously can saturate provisioning networks. Administrators should use Delivery Optimization, peer caching, Windows Update for Business rings, and staged rollouts to avoid WAN saturation. (dataconomy.com)
• Servicing stack permanence: Combined SSU+LCU OOBE payloads change the servicing stack; SSU components are effectively permanent once applied, reducing rollback flexibility and increasing the need for pilot testing. Treat OOBE installs as higher‑risk changes that require preflight validation against your images.
• Edge cases and failures: The August 2025 patch wave exposed a separate class of regressions—WSUS installation failures and recovery flow breakages—that demonstrated how servicing mismatches can produce severe operational issues. Admins should be conservative in pilot scope and have recovery playbooks (USB media, offline images) readily available. (bleepingcomputer.com)
• Policy misalignment risks: The OOBE update flow respects Windows Update for Business pause/deferral settings only when those settings are aligned with the ESP assignment. Mismatched assignments can lead to surprising behavior where some devices receive updates in OOBE and others don’t. Verify assignment and ring consistency. (techcommunity.microsoft.com)

---

What administrators must check before enabling OOBE quality updates​

Before flipping the ESP toggle or creating new ESP profiles that default to enabled, complete this checklist:

• Confirm device eligibility: Windows 11, version 24H2 or later, and Windows Server 2025 images contain the OOBE servicing payload. Devices imaged from older media may not expose the new option unless they have received the June/July 2025 servicing payloads or the August OOBE packages. (techcommunity.microsoft.com)
• Validate Intune / ESP assignment: Ensure the devices that will receive OOBE updates are targeted with the correct ESP profile, and that update ring policies assigned to those device groups match the intended pause/deferral behavior. (techcommunity.microsoft.com)
• Plan bandwidth and Delivery Optimization: Use Delivery Optimization, peer caching (where appropriate), and staged deployments to avoid saturating constrained WAN links. For remote or satellite locations, consider pre‑staging updates on local caches or using device images that already contain the servicing payload. (dataconomy.com)
• Extend temporary access / auth windows: If your Autopilot or enrollment flow uses temporary PINs, passcodes, or time‑limited tokens, increase their expiry to account for longer OOBE durations. Devices that fail to complete enrollment due to expired tokens can require manual intervention. (mc.merill.net)
• Pilot on representative hardware: Test across your product mix—low‑end, typical, and high‑end devices—to observe timing, driver interactions, and potential reboots. Pay particular attention to devices that historically required firmware or vendor driver coordination during first boot.

---

Recommended rollout plan (step‑by‑step)​

• Inventory: Identify images and hardware classes that will be part of your initial rollout. Confirm Windows 11, version 24H2 or Windows Server 2025 builds and presence of the servicing payload. (techcommunity.microsoft.com)
• Pilot group: Choose a small, geographically diverse pilot group (10–50 devices) that includes remote offices and different OEM vendors. Test enrollment, update behavior, and post‑OOBE compliance reporting.
• Network readiness: Configure Delivery Optimization, peer caching, and Quality of Service (QoS) for update traffic. Ensure local content caches are seeded with the intended cumulative updates. (dataconomy.com)
• ESP profile setup: Create a new ESP profile and confirm the “Install Windows Quality Updates (Might Restart The Device)” setting is visible and configured as desired. For new profiles created after the servicing payload is available, the setting will default to enabled—edit defaults before broad rollout if your org prefers manual opt‑in. (techcommunity.microsoft.com)
• Monitor and iterate: Use Intune reporting and monitoring to measure OOBE durations, failure modes, and device health. Watch for increased help‑desk tickets during pilot and be prepared to pause expansion if you detect systemic regressions.
• Staged expansion: Gradually increase device counts, applying lessons learned about throttling, token lifetimes, and local caching. Maintain a rollback plan (offline image or USB recovery media) in case of unexpected regressions.

---

Technical deep dive: how OOBE updates fit into the servicing stack​

OOBE updates are typically delivered as combined packages—often an SSU paired with an LCU—so the OOBE step can correct servicing stack issues and ensure the in‑box update engine is current before subsequent updates run. This is important because pre‑OOBE servicing anomalies (for example, problems with WinUpdate service crashes or WSUS delivery) may prevent later update flows from succeeding.
Two operational realities to keep in mind:

• Once an SSU is installed in the servicing stack it is difficult to remove; this increases the importance of pilot testing because servicing stack changes persist across subsequent update cycles.
• OOBE installs are performed before the primary user signs in; therefore, any network‑ or auth‑related failures during OOBE can leave devices in an incomplete enrollment state that requires IT assistance to resolve. Scheduling and token lifetimes must account for this. (mc.merill.net)

---

Known issues and gotchas (lessons from August 2025)​

August 2025’s cumulative update slate exposed a mix of regressions and WSUS issues that are instructive:

• WSUS delivery failures: Some enterprise WSUS environments experienced error 0x80240069 when installing the August 2025 24H2 cumulative update—Microsoft issued guidance and temporary Known Issue Rollback (KIR) mitigations while the fix rolled out. If your provisioning chain relies on WSUS or SCCM, validate that OOBE‑time deliveries will succeed across your management path. (bleepingcomputer.com)
• Reset/Recovery regression: A prior August rollup created failures in Reset this PC and cloud reimage operations on several client branches; Microsoft responded with out‑of‑band fixes (combined SSU+LCU) to repair recovery paths. This underscores the operational risk of shipping SSU changes widely without staging.
• ESP / ApplicationVersion subtleties: Following recent OOBE servicing updates, enrollment reporting values can change subtly—for example, the ApplicationVersion field in enrollment requests may be incremented by one on devices that receive the OOBE/restore package. MDM servers that use these fields to decide on restore flows or restore CSP pushes must be prepared to interpret the new semantics correctly. If you rely on these enrollment fields, validate how your MDM handles the change.

Because these issues can have material impact on device recovery and mass provisioning, they reinforce the need for conservative staging and robust fallback procedures.

---

Practical recommendations and mitigations​

• Start with a narrow pilot and measure real‑world OOBE durations on representative hardware. Don’t assume a single baseline—low‑end devices and networks will differ materially from well‑provisioned corporate endpoints.
• Use Delivery Optimization and peer caching to reduce WAN burden; pre‑seed local caches for remote offices when possible. Consider using branch‑cache approaches for large image and update deliveries. (dataconomy.com)
• Extend token and temporary credential lifetimes used during Autopilot/Enrollment so timeouts do not break long OOBE sequences. Document and test any changes to enrollment token lifetimes. (mc.merill.net)
• Keep recovery media and well‑tested offline images available so devices can be recovered when OOBE fails before sign‑in. Verify the remote assistance and help‑desk workflows for devices that fail OOBE.
• Coordinate OEM firmware or driver dependencies into the pilot plan. If your OEM supplies vendor drivers via Windows Update, validate the interplay between OOBE quality update checks and vendor driver rollouts so you don’t inadvertently skip required vendor steps.

---

Balance of benefits and risks — an IT leader’s take​

The move to install quality updates during OOBE is, on balance, an operationally positive evolution: it reduces the attack surface at the point of first use and lowers immediate post‑deployment friction. For modern, cloud‑centric device fleets where Intune and Autopilot are already central to provisioning, the feature is a natural fit that can materially improve compliance and reduce help‑desk load.
However, the operational trade‑offs are nontrivial. Organizations with constrained network infrastructure, complex WSUS/SCCM topologies, or legacy vendor dependencies should adopt a staged, measured approach. The mistakes of August 2025—where servicing stack and WSUS delivery regressions caused significant disruption—are a warning that servicing changes, even those aimed at improving security, must be staged with the same discipline as any other infrastructure change. (bleepingcomputer.com)

---

Final thoughts and next steps​

KB5065847 represents a pragmatic effort to harden day‑one posture for managed Windows devices. For organizations that have fully embraced Autopilot and Intune, it is a useful tool to reduce post‑provisioning workload and improve baseline compliance. For others—the ones that still rely on WSUS-only pipelines, complex driver flows, or heavily constrained networks—the feature is an opportunity to reassess provisioning architecture and rollout discipline before enabling OOBE updates at scale.
Actionable next steps:

• Inventory images and confirm servicing payload presence.
• Pilot the ESP quality‑update setting on representative hardware and networks.
• Tune Delivery Optimization and prepare local caches.
• Extend enrollment token windows and validate recovery procedures.
• Monitor the broader servicing landscape for any follow‑on fixes or KIR deployments before broad rollout. (techcommunity.microsoft.com)

This update is a meaningful step toward making freshly provisioned Windows devices safer from first sign‑in—but it demands that IT teams apply the same rigour they would to any change that affects the servicing stack and large‑scale provisioning pipelines.

---

Source: Microsoft Support KB5065847: Out of Box Experience update for Windows 11, version 24H2 and Windows Server 2025: August 29, 2025 - Microsoft Support

 

[AmirTeraniIT]

The new OOBE updates force a reboot which is fine for new deployments, but it breaks all Autopilot pre-provisioned devices that were resealed and shipped to users. The new update and reboot after coming up from reseal disables autologon and gets them stuck at the DefaultUser0 login.

 

[ChatGPT]

You’re seeing the predictable-but-painful result of KB5065847’s new OOBE behavior: quality updates can be applied (and reboot) before first sign‑in, which will interrupt Autopilot pre‑provisioning/resseal flows and break the autologon that hands the device off to the end user — leaving the device parked at DefaultUser0. This is a known operational trade‑off of the new OOBE update flow and there are both immediate remediations and short/medium‑term mitigations you should apply.
Immediate triage (devices already stuck at DefaultUser0)

• If you have physical access to the device:
  1. Try a normal reboot first (some devices will resume OOBE after the reboot).
  2. If that doesn’t return to normal OOBE, boot into WinRE → Troubleshoot → Reset this PC (or use a USB recovery image) and re-run Autopilot/pre‑provisioning. Note: Reset/repair flows can fail if the servicing stack was impacted by the update — if Reset fails you’ll need to reimage/redeploy.
• If the device is managed and still reachable in Intune:
  • Try an Autopilot Reset from the Intune device actions (if the device completes the network check and MDM channel is up). If the device cannot be reached, you’ll need local WinRE / reimage steps as above.

Short‑term fixes (prevent this happening to more devices you reseal/ship)

1. Audit and change your ESP profile(s) in Intune:
   • Path: Microsoft Intune admin center → Devices → Enrollment → Enrollment Status Page → edit the ESP profile → Settings → set “Install Windows quality updates (might restart the device)” = Off for any profile assigned to pre‑provisioned / resealed device groups. New ESP profiles created after the servicing change default to Enabled, so check any recently created profiles.
2. Ensure ESP assignment + Update Rings are aligned:
   • Assign Update Rings / WUfB policies to the same Autopilot groups as your ESP so the OOBE update check picks up your tenant deferrals/pauses (or so it won’t apply updates if you don’t want it to).
3. For pre‑provisioning workflows where you must reseal devices:
   • Either disable OOBE quality updates for the specific Autopilot group, or do not reseal/ship devices that still need to complete the OOBE update step (i.e., ship immediately or reimage with the latest servicing payload included). The latter avoids an in‑field OOBE update reboot that breaks the autologon handoff.

Operational mitigations (policy & process)

• Pilot first: run small cohorts with “Install Windows quality updates = On” to measure OOBE times, failure rates, and token expiry impact (TAPs can expire during long OOBE).
• Extend enrollment token / TAP lifetime if you enable OOBE updates (longer OOBE = token expiry risk).
• Use Delivery Optimization, local caching, or staged image(s) containing required SSU/LCU payloads to avoid large downloads at first boot.
• Maintain recovery media and a documented runbook for WinRE / reimage when OOBE updates fail — this change raises the bar for recovery readiness.

What to collect / send if you want further help

• For a single failed device: collect Windows Update logs, Event Viewer entries (Shell‑Core, WindowsUpdateClient), and Autopilot/ESP enrollment logs. These help determine whether the update completed then disabled autologon or whether the update broke a servicing component.
• Tell me: whether you use Intune or a third‑party MDM, whether you’re Entra (Azure AD) joined or hybrid, and whether these devices were imaged with the June 2025 servicing payload (or received the August OOBE ZDP). With that I can give a concrete Intune / ESP profile change set and step‑by‑step recovery commands.

Short summary / recommendation

• For shipped, resealed Autopilot pre‑provisioned devices: set the ESP profile for those device groups to NOT install Windows quality updates during OOBE (turn that toggle off), or avoid resealing devices until they have completed OOBE updates. Audit new ESP profiles (they default to enabled). If devices are already stuck, use WinRE/reset or reimage; Autopilot Reset is an option when Intune connectivity exists.

If you want, post:

• Which Intune/Autopilot groups you use for pre‑provisioning and whether you want a one‑page Intune checklist I can paste (exact menu clicks and JSON for a profile), and I’ll give it to you. Or, if you have a sample stuck device, tell me what you see on the screen and I’ll walk you through the WinRE steps.