Windows Autopilot enrollment hangs indefinitely on the Enrollment Status Page

[spalmesano0]

• Centralized internal Slack thread.

Fleet versions

• Discovered: 4.86.2
• Reproduced: 4.89.0 (Dogfood)

Web browser and operating system: N/A

---

💥 Actual behavior

During Windows Autopilot enrollment, the Enrollment Status Page ("Setting up your organization's device") gets stuck indefinitely, with tracking sub-items frozen on "Identifying" / "Waiting." The device's MDM session is working throughout (it syncs successfully with Fleet and profiles can still be delivered to it), but the ESP never advances.

Reported by preston across multiple customer tenants, with 56 affected customers tracked on their side.

🛠️ Expected behavior

The Enrollment Status Page should complete once Fleet finishes provisioning the device, allowing the device to proceed past the ESP screen.

🧑‍💻 Steps to reproduce

These steps:

• Have been confirmed to consistently lead to reproduction in multiple Fleet instances.
• Describe the workflow that led to the error, but have not yet been reproduced in multiple Fleet instances.

1. Enroll a Windows device via Autopilot to Fleet.
2. Let the device proceed through OOBE to the Enrollment Status Page.
3. ESP intermittently hangs on "Identifying" / "Waiting" and never completes, even though the device continues to check in with Fleet successfully.

🕯️ More info (optional)

• Internally, Andrey reproduced it on 4.89.0 with a completely blank fleet (no setup experience software/scripts/profiles configured). One of two identically-configured test devices got stuck while the other enrolled successfully.
• @AndreyKizimenko provided a workaround. Load this script into setup experience for the fleet:

<#
    Fleet setup-experience workaround: ESP account-setup release delay
    ------------------------------------------------------------------
    Purpose:
      Windows Autopilot ESP hangs on "Account setup" because Fleet fires the
      user-scope DMClient release (.../FirstSyncStatus/ServerHasFinishedProvisioning)
      immediately when a team has no setup-experience work to wait on. The device
      rejects that early user-scope write with SyncML 405 and the phase strands.

      Adding a setup-experience item forces handleESPRelease to hold the release
      across check-ins until the item reaches a terminal state. This script does
      nothing but sleep, giving the user-scope MDM context time to become writable
      before Fleet sends the release -> the write acks 200 and the device proceeds.

    Behavior:
      Sleeps for $DelaySeconds (default 60s / 1 min), then exits 0 (success) so
      the ESP is not failed or blocked.

    Notes:
      - Runs as SYSTEM during the account-setup phase.
      - Keep the delay under Fleet's setup-experience script timeout.
#>

$DelaySeconds = 60

Write-Output "[$(Get-Date -Format o)] Fleet ESP delay: sleeping $DelaySeconds seconds to let the user-scope ESP node initialize..."

Start-Sleep -Seconds $DelaySeconds

Write-Output "[$(Get-Date -Format o)] Fleet ESP delay complete; exiting 0."
exit 0

[spalmesano0]

@lukeheath Requesting a P1 as it's preventing Windows enrollment across multiple environments.

[AndreyKizimenko]

Windows Autopilot ESP hangs on "Account setup" — user-scope ServerHasFinishedProvisioning returns 405 (race in ESP user-node creation)

Summary

On Windows Autopilot / Entra OOBE enrollment, devices intermittently get stuck on the Enrollment Status Page (ESP) at "Account setup → Working on it…" and never reach the desktop (until the 3-hour ESP timeout).

Fleet has already run the ESP lifecycle to completion on its side (awaiting_configuration = None), but the user-scope ESP release command fails on the device with SyncML status 405, so the user phase never receives its completion signal.

Root cause is a race: the user-scope DMClient Provider/Fleet node is only created (via Add) while the enrollment's host_uuid is still empty. If host_uuid is linked (by orbit enroll / osquery ingest) before the first Pending-phase MDM management session runs, the Add is skipped, the node is never created, and the later release Replace on that node returns 405.

This matches the observed "sometimes a host goes through, sometimes it doesn't."

Environment

• Fleet version: 4.89.0 (rc-minor-fleet-v4.89.0)
• Hosts: Windows 11 Pro 25H2 10.0.26200.8655, ARM (Parallels ARM VMs)
• Enrollment: Windows Autopilot / Entra automatic enrollment during OOBE
• Team: No team (Unassigned) — no config profiles, software, OS updates, or disk encryption configured

Impact

Device is stuck at the OOBE ESP "Account setup" screen and cannot be used until the 3-hour ESP timeout expires. Intermittent, so it passes QA/first-boot inconsistently. No setup-experience items are required for this to happen.

Steps to reproduce

1. Configure Windows Autopilot/Entra automatic MDM enrollment into Fleet.
2. Enroll a Windows 11 device via OOBE (fleetd delivered as a required MSI during ESP).
3. Observe the ESP. Intermittently, the device hangs on Account setup → Working on it… and never completes.

Evidence

Both stuck hosts show Fleet-side ESP as fully released, yet the user-scope release command failed on-device.

1. Enrollment state — Fleet thinks ESP is done

device_name | host_uuid                             | awaiting_configuration | awaiting_configuration_at   | not_in_oobe
autopilot1  | 46D45D16-4B46-4ACE-B71F-465447F5D0F9  | 0 (None)               | 2026-07-10 15:19:02.513248  | 0
autopilot2  | A07685D7-5E78-4A24-ADA1-73B95F31F4BF  | 0 (None)               | 2026-07-10 15:20:00.531997  | 0

awaiting_configuration_at is non-null (only the Automatic + OOBE path sets it) and awaiting_configuration = 0 with the timestamp preserved = a completed Pending → Active → None release cycle.

2. ESP command results — user-scope Replace fails with 405

device      | target_loc_uri                                                                        | status_code
autopilot1  | ./Device/.../EnrollmentStatusTracking/DevicePreparation/.../Fleet/InstallationState   | 200
autopilot1  | ./User/Vendor/MSFT/DMClient/Provider/Fleet/FirstSyncStatus/ServerHasFinishedProvisioning | 405   <-- FAIL
autopilot1  | ./Device/Vendor/MSFT/DMClient/Provider/Fleet/FirstSyncStatus/ServerHasFinishedProvisioning | 200
autopilot2  | ./User/Vendor/MSFT/DMClient/Provider/Fleet/FirstSyncStatus/ServerHasFinishedProvisioning | 405   <-- FAIL
autopilot2  | ./Device/.../EnrollmentStatusTracking/DevicePreparation/.../Fleet/InstallationState   | 200
autopilot2  | ./Device/Vendor/MSFT/DMClient/Provider/Fleet/FirstSyncStatus/ServerHasFinishedProvisioning | 200

Device-scope ServerHasFinishedProvisioning = 200 (node exists by default). User-scope = 405 (node was never created). "Account setup" is the user ESP phase, so it hangs.

3. Command queue — the user-scope Add was never sent

The queue for both hosts contains the user-scope ServerHasFinishedProvisioning Replace, but no ./User/Vendor/MSFT/DMClient/Provider/Fleet Add. The MSI that installs fleetd (EnterpriseDesktopAppManagement/MSI/.../DownloadInstall) was acked at 15:19:05, ~72s before the release commands at 15:20:17 — i.e. fleetd installed and linked host_uuid before the first Pending-phase ESP hold session could run.

Root cause

The user-scope DMClient Provider/Fleet node (+ its FirstSyncStatus child) is created by Add commands emitted only while host_uuid == "" in the Pending phase — handleESPHoldOrTransition (server/service/microsoft_mdm.go, ~L2262). Once host_uuid is linked, the code transitions straight to Active and never sends those Adds.

But host_uuid can be linked by three paths, two of them out-of-band from the MDM session:

1. Orbit enroll — UpdateMDMWindowsEnrollmentsHostUUID (server/service/orbit.go ~L334)
2. SMBIOS-serial reply over MDM (server/service/microsoft_mdm.go ~L1969) — the intended primary path
3. osquery directIngestMDMDeviceIDWindows backstop (~10s)

When fleetd installs and links host_uuid (path 1/3) before the first Pending-phase MDM poll runs the hold commands, the user-scope Add is skipped. The Active-phase release (buildESPReleaseCommands, server/service/microsoft_mdm.go ~L2826) then issues:

Replace ./Device/.../FirstSyncStatus/ServerHasFinishedProvisioning = true   (200 — device node exists)
Replace ./User/.../FirstSyncStatus/ServerHasFinishedProvisioning   = true   (405 — user node missing)

The user-scope Replace lands on a nonexistent node → 405 → the user ("Account setup") phase never completes → device hangs until the 3-hour OS ESP timeout.

The intermittency is exactly this race: whichever wins between (a) the ~1-minute MDM ESP poll sending the Add, and (b) fleetd linking host_uuid.

Proposed fix

Decouple user-scope node creation from the host_uuid == "" gate so the release always lands on an existing node:

• In buildESPReleaseCommands (and the block-path builder), prepend idempotent Adds for ./User/Vendor/MSFT/DMClient/Provider/Fleet and .../FirstSyncStatus immediately before the user-scope Replace. The Adds return 418 Already Exists harmlessly when the node already exists (as they already do in the hold phase), so this is safe whether or not the Pending-phase Adds ran.

This guarantees the release/finalize Replace on the user-scope node succeeds regardless of who wins the host_uuid linking race.

Workaround

None clean for end users. The device self-recovers only after the 3-hour ESP timeout (force-release). For QA, re-running OOBE can land on the "poll wins the race" path and succeed.

[getvictor]

I agree that Fleet must not consider the ESP finished until the user-scope ServerHasFinishedProvisioning Replace has acked 200 (or the existing timeout/block paths fire). Just doing another Add+Replace on a 405 response should be a sufficient quick fix.

There's also some cleanup and investigation around this issue that could be useful. For example, it seems that the original Add ./User/Vendor/MSFT/DMClient/Provider/Fleet may be failing if the user session doesn't exist yet. But Windows may create that node later using a different mechanism.

[lukeheath]

@spalmesano0 Agreed on P1. I'll get this prioritized during standup tomorrow.