Microsoft released KB5065848 on August 29, 2025 — a targeted Out‑of‑Box Experience (OOBE) update for
Windows 11, version 24H2 and
Windows Server 2025 — that changes how device provisioning and enrollment behave during first‑time setup and supplies updated management/enrollment components used during OOBE. The KB is installed only during the OOBE process (when a network connection exists), updates a set of device‑management and enrollment binaries, and is the 24H2 branch counterpart to the broader OOBE servicing work Microsoft has been rolling out across 2025.
Background / Overview
Microsoft has been actively reworking the Windows setup flow in 2024–2025 to close the “day‑one patch gap” and to make Autopilot/Intune provisioning less error‑prone. That broader initiative includes two related threads:
- A new administrative capability to install Windows quality updates during the final OOBE page for eligible, managed devices, surfaced as a toggle in the Autopilot Enrollment Status Page (ESP). This capability intends to deliver devices to users already patched to the tenant’s approved quality update level.
- A set of targeted Out‑of‑Band (OOB) SSU+LCU packages that repair regressions introduced by the August 2025 cumulative rollups (notably failures in Reset / Cloud Reinstall / RemoteWipe flows). Those OOB packages and the OOBE servicing payloads are the platform plumbing that enables the ESP behavior and fixes recovery regressions experienced earlier in August. (bleepingcomputer.com)
KB5065848 is the service package for the 24H2 branch that updates OOBE components (MDM/enrollment binaries, the enrollment diagnostics tool, policy manager, and related files) so the OOBE state machine and enrollment flows behave correctly for the newest 24H2 images. The KB’s file manifest shows updated device‑management components (for example, DeviceEnroller.exe, MdmDiagnosticsTool.exe, and related DLLs), confirming its enrollment/OOBE focus.
What KB5065848 actually does
One‑line summary
KB5065848 updates the Windows OOBE payload for
Windows 11 24H2 and
Windows Server 2025 so that enrollment and management‑related behaviors during initial setup are corrected and ready for the newer OOBE quality‑update orchestration Microsoft is enabling for managed fleets. (
support.microsoft.com, techcommunity.microsoft.com, techcommunity.microsoft.com, petri.com, support.microsoft.com,
bleepingcomputer.com)
Operational guidance — how to prepare and roll this out safely
The change shifts risk from post‑handoff patching into pre‑handoff provisioning. Follow a staged, conservative approach:
- Validate prerequisites
- Confirm devices run Windows 11, version 22H2 or later (this KB targets 24H2 specifically). Verify device SKU (Pro, Enterprise, Education, SE) and that devices will be Entra‑joined / Entra hybrid‑joined and managed by Intune (or an MDM that supports ESP).
- Ensure images include required payloads
- Devices should be imaged with the June 2025 non‑security setup payload or have received the August OOBE zero‑day package; otherwise, the ESP quality‑update toggle may not appear. Update golden images used for Autopilot or device preparation so the OOBE payloads are present.
- Pilot with a narrow hardware matrix
- Run a pilot across representative hardware models (light ultrabooks, heavier older machines, network‑constrained sites). Monitor update time, failures during OOBE, and whether authentication methods (TAP, Web Sign‑In) work end‑to‑end.
- Tune Enrollment Status Page (ESP) profiles
- Edit new/existing ESP profiles in Intune: the setting is under Devices → Enrollment → Enrollment Status Page and is labeled Install Windows quality updates (might restart the device). New ESPs default to enabled; existing profiles default off. Check assignments and defaults before scaling.
- Adjust authentication windows
- If you rely on Temporary Access Pass (TAP) for first sign‑in, extend the TAP lifetime to accommodate longer OOBE times, or change workflow to ensure the user sign‑in happens after updates complete. Test Web Sign‑In behavior across builds before mass rollout. (patchmypc.com)
- Monitor telemetry and recovery paths
- Collect DeviceManagement and ESP logs (DeviceManagement‑Enterprise‑Diagnostics Provider, mdmdiagnosticstool outputs). Maintain tested recovery runbooks for devices that fail provisioning; ensure you can reimage quickly or trigger an out‑of‑band fix if a quality update causes hardware‑specific issues. Remember August 2025 taught the industry that recovery regressions can be operationally severe. (bleepingcomputer.com)
- Plan bandwidth and scheduling
- Use Delivery Optimization, peer caching, and scheduled provisioning windows to avoid WAN saturation when large numbers of devices simultaneously download updates. Consider local caching or staging to reduce peak load.
Risks and caveats — what can go wrong
- Longer OOBE times increase chance of failure. Any quality update that contains a regression could cause many devices to fail during setup, magnifying the blast radius because the failure happens before the device reaches the desktop. Microsoft and independent outlets warn that this front‑loaded failure surface means pilot testing and staged rollouts are crucial. (windowsforum.com)
- Authentication/TAP expiry and Web Sign‑In fragility. Short TAP lifetimes or Web Sign‑In mismatches can leave users unable to complete enrollment if OOBE lasts longer than expected; extend TAP windows or adapt enrollment workflows. Community reports show this is a common friction point when cumulative updates are applied during provisioning. (patchmypc.com)
- MDM/restore CSP mismatch risk. For older images, Microsoft introduced an ApplicationVersion +1 signal so MDMs can detect whether a device is “restore‑capable” after receiving the OOBE package. If MDMs push restore CSPs blindly to devices that lack the code, enrollment can fail and devices can become stuck in OOBE. Administrators must implement detection logic in their MDM servers before pushing restore flows. This nuance is important for Intune/third‑party MDM vendors.
- Rollback complexity with SSU+LCU OOB packages. Servicing Stack Updates (SSUs) combined with LCUs complicate uninstallation; you cannot simply uninstall an SSU. If an OOB package includes an SSU to fix a recovery regression, planned rollback strategies must rely on imaging or snapshots, not simple uninstall commands.
- Image drift and missing payloads. Devices imaged from older gold images without OOBE payload updates may not expose the ESP toggle and will not participate in the quality‑update‑during‑OOBE flow — leading to inconsistent provisioning behavior across a fleet unless images are standardized.
Where Microsoft has not published deep technical postmortems about root causes (for example, the precise servicing metadata mismatch that led to the August recovery regression), treat community forensic analyses as plausible but not definitive. Administrators should rely on Microsoft guidance for remediation and consider community writeups as investigative input, not authoritative cause statements. (
bleepingcomputer.com)
Practical checklist for IT teams (copyable)