Microsoft has quietly pushed three Out‑of‑Box Experience (OOBE) servicing packages — KB5065813, KB5065847, and KB5065848 — that change how Windows 11 (22H2/23H2/24H2) and Windows Server 2025 are provisioned at first boot, enabling day‑one quality updates and delivering emergency fixes to recovery and enrollment flows.
The Windows setup flow has been evolving beyond a cosmetic first‑run wizard into a managed provisioning checkpoint where security posture and compliance can be enforced before the first user sign‑in. Microsoft’s recent servicing work surfaces a new OOBE step — controlled via Autopilot’s Enrollment Status Page (ESP) and equivalent MDM/GPO surfaces — that can check Windows Update during the final OOBE screen and install applicable quality updates (combined SSU+LCU packages) when the device is online. This approach is explicitly scoped to quality updates and critical zero‑day patches; it deliberately excludes feature upgrades and mass driver rollouts to limit risk during provisioning.
Why Microsoft is doing this is straightforward: freshly imaged or factory‑fresh devices often ship months behind on cumulative fixes. Moving quality updates into OOBE reduces the exposure window between first boot and first secured sign‑in and reduces immediate post‑provisioning update churn across large fleets. Administrators must weigh those benefits against longer provisioning times, bandwidth and authentication timing challenges, and the operational need to refresh images and test policies.
Recommended defensive measures documented by Microsoft and community guidance include:
However, the operational burden for IT is real. Immediate action items for IT teams are clear:
Microsoft’s approach demonstrates a shift: first impressions are now security checkpoints. The fixes shipped in KB5065813, KB5065847, and KB5065848 make that shift operationally feasible, but only when administrators treat OOBE as a controlled, tested phase of deployment rather than a moment of convenience.
Source: Windows Report Microsoft rolls out KB5065848, KB5065847, and KB5065813 OOBE updates for Windows 11
Background
The Windows setup flow has been evolving beyond a cosmetic first‑run wizard into a managed provisioning checkpoint where security posture and compliance can be enforced before the first user sign‑in. Microsoft’s recent servicing work surfaces a new OOBE step — controlled via Autopilot’s Enrollment Status Page (ESP) and equivalent MDM/GPO surfaces — that can check Windows Update during the final OOBE screen and install applicable quality updates (combined SSU+LCU packages) when the device is online. This approach is explicitly scoped to quality updates and critical zero‑day patches; it deliberately excludes feature upgrades and mass driver rollouts to limit risk during provisioning.Why Microsoft is doing this is straightforward: freshly imaged or factory‑fresh devices often ship months behind on cumulative fixes. Moving quality updates into OOBE reduces the exposure window between first boot and first secured sign‑in and reduces immediate post‑provisioning update churn across large fleets. Administrators must weigh those benefits against longer provisioning times, bandwidth and authentication timing challenges, and the operational need to refresh images and test policies.
What Microsoft shipped: KB5065813, KB5065847, KB5065848
KB5065813 (Windows 11 22H2 / 23H2)
- Published in late August 2025 (reported August 26, 2025), KB5065813 is an OOBE servicing package for Windows 11 versions 22H2 and 23H2. It both enables the platform capability to download and apply quality updates during OOBE for eligible managed devices and delivers an emergency combined Servicing Stack Update (SSU) + Latest Cumulative Update (LCU) to repair recovery‑flow regressions introduced by the August 2025 cumulative rollups. Administrators are advised to match the OOB package to the exact OS build before relying on it.
KB5065847 (Windows 11 24H2 and Windows Server 2025)
- Reported on August 29, 2025, KB5065847 is the OOBE quality‑update rollout for Windows 11, version 24H2 and Windows Server 2025. It surfaces the OOBE quality‑update step on the final setup page for eligible, managed devices, ties that behavior to Autopilot/ESP controls in Intune, and may install combined SSU+LCU payloads as required. Expect one or more automated reboots during the OOBE flow when the package applies.
KB5065848 (Enrollment & enrollment stack update for 24H2)
- Also published around August 29, 2025, KB5065848 targets Windows 11, version 24H2 and Windows Server 2025 and updates enrollment and management components used during OOBE. The KB’s file manifest shows updated enrollment binaries such as DeviceEnroller.exe, MdmDiagnosticsTool.exe, and policymanager.dll, confirming a focus on the enrollment plumbing so Autopilot/ESP workflows behave correctly for newer 24H2 images. This package is applied only during OOBE when network connectivity exists.
How the OOBE update flow works (step‑by‑step)
- Device boots into OOBE and proceeds through setup until it reaches the final screen that triggers the OOBE update check.
- If the device meets eligibility criteria (Windows 11 22H2 or later, the correct SKU, Microsoft Entra‑joined or Entra hybrid‑joined and MDM‑managed), and the tenant’s ESP profile allows the behavior, the device connects to Windows Update and checks for applicable quality updates and any required SSU packages.
- If updates are found, the system downloads and installs them during OOBE. Combined SSU+LCU payloads may require one or more reboots before the first sign‑in completes.
- Upon successful installation, OOBE resumes and the first user signs in to a device that is ideally at the tenant’s approved patch baseline.
- The OOBE update step runs only when the device is connected to the internet during setup.
- The flow targets quality updates (monthly cumulative security/reliability fixes) and critical zero‑day patches; it does not install feature upgrades or broad driver rollouts during OOBE.
- New ESP profiles created after the necessary servicing payloads are present will default to enabling the OOBE quality‑update step; existing profiles default to off and must be edited to opt in.
What’s inside these KBs — technical highlights
- KB5065848 updates enrollment stack binaries used during OOBE; manifests list specific files and versions (for example, enrollment artifacts showing 10.0.26100.x builds in manifests), which demonstrates an enrollment‑focused scope rather than a broad cumulative package.
- KB5065813 contains an OOB SSU+LCU combo for the 22H2/23H2 branches designed to repair Reset this PC, Cloud Reinstall (Fix problems using Windows Update), and RemoteWipe regressions that appeared after the August 2025 cumulative rollups. These are high‑impact fixes for managed fleets.
- KB5065378 (a separate Setup Dynamic Update published the same window for 24H2/Windows Server 2025) refreshes setup binaries and SafeOS components used by feature updates; administrators that build offline media must fetch this from the Microsoft Update Catalog or let WSUS sync it. That dynamic update class is how Microsoft reduces setup failures and keeps older media resilient.
Practical impact: benefits and tradeoffs
Clear benefits
- Day‑one patched devices. When prerequisites are met, a new or freshly imaged machine can arrive to the user already patched to the tenant’s current quality baseline, reducing immediate reboots and help‑desk tickets.
- Reduced first‑week update churn. For large fleets, applying quality updates during OOBE reduces the typical early‑life update waves that disrupt users and help desks.
- Targeted recovery fixes. The combined OOB SSU+LCU packages were pushed to repair specific recovery regressions that would otherwise break Reset / cloud reinstall / remote wipe flows — an operationally important win for enterprise IT.
Tradeoffs and operational costs
- Longer provisioning times. Field reports and Microsoft guidance point to OOBE runs that can add tens of minutes to setup — an average of approximately 20 minutes is commonly cited — depending on update size, network speed, and hardware. That’s meaningful for schools, distribution centers, or large onboarding events.
- Network and bandwidth planning. Tens or hundreds of new devices pulling updates simultaneously can stress public egress or distribution points. Administrators should plan staged rollouts or local caching (Delivery Optimization / peer caching / WSUS) to reduce impact.
- Authentication timing and enrollment fragility. Extended OOBE runs can cause Temporary Access Pass (TAP) codes and other short‑lived enrollment credentials to expire before the user reaches the desktop, leaving devices stranded in OOBE. This requires policy or credential adjustments.
Risks, failure modes and interoperability concerns
Stuck devices and enrollment mismatches
A concrete real‑world issue arises from an enrollment reporting change documented in KB5065083: some older devices that receive specific OOBE packages will report an ApplicationVersion value equal to BuildVersion + 1 in the enrollment request to signal that they are restore‑capable. If an MDM assumes the restore CSP is present and pushes restore policies to a device that lacks the restore code, the device can become stuck in OOBE and require manual recovery or reimaging. Administrators and MDM vendors must update detection logic and be conservative about blindly pushing restore CSPs.Recommended defensive measures documented by Microsoft and community guidance include:
- Treat ApplicationVersion == BuildVersion + 1 as a positive signal before sending restore CSPs; do not push restore CSP blindly.
- Implement idempotent, tolerant restore CSP pushes with bounded retries and exponential backoff so a failed push does not block enrollment indefinitely.
- Collect ESP logs and mdmdiagnosticstool CABs when troubleshooting stuck devices, and retain logs for 30–90 days to correlate incidents.
Image drift and the need to refresh provisioning media
If deployment images are stale (they lack the OOBE servicing payloads), newly provisioned devices may not expose the ESP toggle or might fail to install the OOBE packages, causing inconsistent behavior across the fleet. The solution is to either refresh images with the necessary OOBE packages or apply the KBs to devices used as provisioning sources. Microsoft explicitly recommends matching OOB packages to exact OS builds and refreshing images where possible.Telco & international bandwidth exposure
Organizations that provision devices across geographies should plan CDN, cache, or WSUS topologies carefully. Pulling SSU+LCU combos over slow or metered links will materially lengthen OOBE. The ability to stage or locally host the required packages reduces risk.Deployment checklist and recommended steps for IT
- Inventory and map your fleet: verify which devices are Windows 11 22H2 / 23H2 / 24H2 and whether they are Microsoft Entra (Azure AD) joined or hybrid, and enrolled in Intune or a compliant MDM.
- Refresh provisioning images: ensure Autopilot images, WIMs, and golden devices include the OOBE servicing payloads or plan to apply the OOBE KBs to provisioning sources.
- Pilot the ESP toggle: create a small pilot ESP profile in Intune that enables “Install Windows quality updates (might restart the device)” and validate behavior on representative hardware. New ESP profiles default to enabled after the servicing payload is present; older profiles default to off.
- Adjust TAP and enrollment lifetimes: extend Temporary Access Pass validity or sequence enrollment so short‑lived credentials don’t expire during extended OOBE runs.
- Implement local caching / Delivery Optimization / WSUS: avoid hammering internet bandwidth by staging packages locally for large onboarding events.
- Update MDM detection logic for restore flows: treat ApplicationVersion == BuildVersion + 1 as a restore‑capable signal, make restore CSP pushes idempotent and tolerant, and add telemetry flags to track outcomes.
- Monitor OOBE logs and telemetry: collect ESP traces and DeviceManagement logs during pilots and early rollout; keep logs available for escalation.
- Communicate to procurement and field teams: longer OOBE times must be baked into roll‑out timelines and user onboarding guides.
Consumer impact vs enterprise focus
These OOBE servicing packages are primarily aimed at managed enterprise and education scenarios — devices that are Microsoft Entra‑joined or hybrid‑joined and MDM‑enrolled. Consumer Home devices are not the primary target for the ESP‑driven OOBE quality update behavior, although dynamic updates and setup fixes continue to benefit general reliability across all channels when appropriate. That said, any device that reaches OOBE and is online could theoretically receive OOBE packages if vendor images and serviceable conditions match, so administrators and OEMs must coordinate.Critical analysis — strengths, gaps, and long‑term implications
Strengths
- The move to apply quality updates during OOBE is pragmatic and security‑minded: it reduces the window when brand new hardware is vulnerable, which is especially useful for high‑turnover environments and zero‑trust initiatives.
- Publishing targeted OOB SSU+LCU combos to fix acute recovery failures demonstrates Microsoft’s ability to push fast, narrowly scoped fixes into the setup flow without waiting for the next cumulative cycle. That responsiveness is valuable for enterprise resiliency.
Gaps and risks
- The policy and telemetry surface is thin where it matters most: OOBE runs that fail can strand users or devices before an operator notices, and the default behavior for new ESP profiles (enabled after servicing payload arrival) requires administrators to actively verify their enrollment profiles to avoid accidental rollout.
- The ApplicationVersion +1 change is a good pragmatic signal but introduces a brittle detection surface for MDMs that do not update enrollment logic quickly; the resulting enrollment failure mode is painful (devices stuck in OOBE). The recommended mitigations — careful detection, idempotent pushes, and pilots — are operationally heavy but necessary.
Long‑term implications
- OOBE has shifted from a cosmetic first‑run into a controllable provisioning checkpoint. Over time this reduces the lifecycle gap between imaging and patch compliance, but it also ties provisioning success to network availability, update infrastructure, and careful MDM logic. Organizations will need to treat OOBE as a first‑class operational process in deployment runbooks.
Final verdict and recommended posture
Microsoft’s OOBE servicing push (KB5065813, KB5065847, KB5065848, and companion dynamic updates such as KB5065378) is a necessary, pragmatic step toward closing the day‑one patch gap and repairing pressing recovery and enrollment regressions. The architectural choices — restricting OOBE to quality updates and emergency ZDPs, surfacing control via Autopilot/ESP, and publishing targeted SSU+LCU combos — show cautious, enterprise‑first design.However, the operational burden for IT is real. Immediate action items for IT teams are clear:
- Update provisioning images and test OOBE flows in a lab.
- Pilot ESP settings and monitor ESP/log telemetry closely.
- Update MDM enrollment logic to handle ApplicationVersion +1 safely.
- Plan bandwidth, local caching, and staged rollouts for large deployments.
Microsoft’s approach demonstrates a shift: first impressions are now security checkpoints. The fixes shipped in KB5065813, KB5065847, and KB5065848 make that shift operationally feasible, but only when administrators treat OOBE as a controlled, tested phase of deployment rather than a moment of convenience.
Source: Windows Report Microsoft rolls out KB5065848, KB5065847, and KB5065813 OOBE updates for Windows 11
