You start a user-driven Autopilot deployment that joins the device to on-premises Active Directory and Microsoft Entra ID, and instead of finishing, the Enrollment Status Page (ESP) reports a timeout with error 0x80004005. In February 2026 Microsoft documented this as a Windows known issue that is fixed by specific cumulative updates. In this post I'll go through exactly what the official page says, how to confirm a device is on an affected build, how to get the fix onto devices that haven't enrolled yet, and how to verify the result.
Status (October 2026): Microsoft added this issue to the Windows Autopilot known issues page on 9 February 2026. It affects Microsoft Entra hybrid join Autopilot deployments on Windows 11 and is listed as resolved in KB5065789 or later (25H2), KB5065426 or later (24H2) and KB5070312 or later (23H2). Status entries change, so re-check the official page before you act on this post.
Symptoms#
- The Autopilot deployment profile has Join to Microsoft Entra ID as set to Microsoft Entra hybrid joined. Cloud-native (Entra join only) deployments aren't part of this known issue.
- The deployment stalls and then fails with a timeout that carries error code
0x80004005. Microsoft's page describes the symptom only as "timeout errors with error code 0x80004005 in the deployment process" and doesn't name a specific ESP step. - The device is running a Windows 11 build older than the fixed builds listed below. Devices on a current build don't hit this issue.
One word of caution: 0x80004005 is the generic E_FAIL HRESULT ("Unspecified error"). On its own it doesn't prove you're looking at this known issue, which is why the build check in the fix section matters.
Why it happens#
Microsoft hasn't published a root cause beyond stating that the issue is resolved by Windows cumulative updates, so this is a client-side defect in Windows rather than an Intune or connector problem. Because cumulative updates are, well, cumulative, any update released after the ones listed also contains the fix. I pulled the build numbers from the KB articles so you can compare them with what a failing device reports:
| Windows 11 version | Fix listed by Microsoft | OS build from the KB article | Released |
|---|---|---|---|
| 25H2 | KB5065789 or later | 26200.6725 | 29 September 2025 (preview) |
| 24H2 | KB5065426 or later | 26100.6584 | 9 September 2025 |
| 23H2 | KB5070312 or later | 22631.6276 | 20 November 2025 (preview) |
Preview updates roll into the following month's security update, so for 25H2 any October 2025 or later cumulative update qualifies, and for 23H2 the December 2025 security update or later does.
How to fix it#
- Rule out the usual hybrid join suspects first. A hybrid join deployment also times out when the device can't reach a domain controller, when the Intune Connector for Active Directory is inactive or can't create computer objects in the target OU, or when a VPN scenario is missing Skip AD connectivity check in the Autopilot profile. Check Devices › Windows › Enrollment › Intune Connector for Active Directory shows the connector as Active, and on the connector server review Applications and Services Logs › Microsoft › Intune › ODJConnectorService.
- Check the build on the failing device. At the ESP error screen press Shift+F10, type
powershelland run:IfPowerShellGet-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object DisplayVersion, CurrentBuild, UBRCurrentBuild.UBRis lower than the fixed build for that version in the table, the device is on an affected build. - Collect logs before you change anything. From the same command prompt run
mdmdiagnosticstool.exe -area Autopilot -cab C:\autopilot.caband copy the file to a USB drive. On Windows 11, if your ESP profile has Turn on log collection and diagnostics page for end users set to Yes, Ctrl+Shift+D opens the Autopilot diagnostics page. The DeviceManagement-Enterprise-Diagnostics-Provider › Admin event log inside the cab is where enrollment and policy errors land. - Get the fixed update onto devices before they reach OOBE. This is the real fix, and you have a few options:
- OEM devices: ask your OEM which cumulative update is in the shipping image. Images built after late 2025 normally include the fix already.
- Your own media: add the current cumulative update to the image offline. The KB articles document the command, which is
DISM /Image:<mountdir> /Add-Package /PackagePath:<update>.msuwith the package downloaded from the Microsoft Update Catalog. Microsoft also publishes installation media with the latest cumulative update included in the Microsoft 365 admin center. - A handful of devices on your desk: at the first OOBE screen press Shift+F10, install the .msu with
DISM /Online /Add-Package, restart and then start the deployment. Test this on one device before relying on it.
- Retry the deployment on the updated build. If it still times out with the same code, you're looking at something else; go back to step 1 with the logs you collected.
Watch out: don't count on the ESP setting Install Windows quality updates (might restart the device) to rescue these devices. It installs updates after the ESP completes, which is after the point where this issue fails, and it's subject to a separate known issue of its own: on hybrid joined deployments the update scan can time out so devices don't get the updates (affects KB5041571 and later, resolved in KB5079473 and later). Expedited quality updates in Intune also only apply once the device is enrolled, so they help the fleet but not a device stuck in OOBE.
Verify the fix#
- The PowerShell check above returns a build at or above the fixed build for the device's version.
- The ESP completes both the device and the account setup phase, and the device lands on the desktop with no error page.
- In the Microsoft Intune admin center, the Windows Autopilot deployment report under Devices › Monitor shows the deployment as successful. Microsoft notes a known reporting quirk here: the deployment duration includes the time the user spends signing in at the lock screen if a reboot happened during OOBE, so don't read a long duration as a failure.
- On the finished device,
dsregcmd /statusshowsDomainJoined : YESandAzureAdJoined : YES, and the computer object exists in the OU named in your Domain Join profile. - Expect two device objects in Microsoft Entra ID for a hybrid deployment (one pre-created at Autopilot registration, one from the hybrid join) and a compliance state of N/A until a user signs in. Both behaviours are documented as by design.
Prevent it next time#
- Treat the cumulative update level of your deployment images as a deliverable. Refresh OEM and custom images at least quarterly and record the build you expect to see at OOBE.
- Subscribe to the RSS feed linked at the top of the Windows Autopilot known issues page so new entries reach you without checking manually.
- Pair this with the Install Windows quality updates ESP setting only after your images include
KB5079473or later, otherwise hybrid deployments may skip the updates anyway. - Longer term, Microsoft's own guidance on the hybrid join page is to deploy new devices as cloud-native Microsoft Entra joined. Every hybrid-only known issue on the page, including this one, is a reason to plan that move.