Fix Windows Autopilot Report False Failure After a Successful Deployment

If the Windows Autopilot report in Intune flips a device from In progress to Failed, but the laptop actually reached the desktop and the user can work normally, stop treating it like a real provisioning outage until you prove the device-side evidence.

Microsoft documents this as a known reporting issue: the Windows Autopilot report automatically changes a deployment from In progress to Failed after four hours if Intune never receives a final success or failure status. That means a device can finish successfully, get powered off, lose network at the wrong moment, or never post the final report update back in time, and the portal still shows Failed.

That distinction matters in enterprise operations. False failures trigger needless rebuilds, duplicate tickets, bad rollout metrics, and the wrong root-cause story in CAB reviews. The right response is to verify what the device actually did, not to trust the first red label in the portal.

Quick Fix Checklist

Use this sequence before you wipe the device or reopen the Autopilot profile:

1. Confirm the device really reached the desktop and completed the expected provisioning outcome.
2. Compare the portal status against local evidence from the device.
3. Pull the Autopilot event log from ModernDeployment-Diagnostics-Provider\Autopilot.
4. Check whether the report sat in In progress for hours and then changed to Failed without matching device-side failure evidence.
5. Export the Intune report with AutopilotV1DeploymentStatus to capture DeploymentState, FailureDetails, FailureReason, and timing fields.
6. Query the deviceManagementAutopilotEvent Graph resource if you need record-level evidence for one serial number or device ID.
7. If the device is healthy, document the incident as a false reporting failure, not a rebuild candidate.
8. Keep the device online until final status sync completes when validating future pilot runs.
9. Use one pilot rerun only if the device-side logs show a real ESP or enrollment failure.

What This Issue Actually Means

Microsoft’s current Windows Autopilot known issues page says:

The Windows Autopilot report automatically updates deployment status from In progress to Failed after 4 hours if Intune didn't receive a success or failure status. It's possible that the report didn't receive the latest status from the device before the device is powered off which results in an incorrect Failed status, even when the deployment is successful.

That wording is more useful than it looks.

It tells you four important things:

• the problem is in the reporting path, not automatically in device provisioning
• the trigger is a missing final status message to Intune
• the timeout window is four hours
• powering off or dropping network before the status posts can create a false Failed state

So when admins search this symptom, the first question is not “Which Win32 app broke?” It is “Did the device actually fail, or did Intune miss the final state update?”

Root Cause

The root cause is usually not a broken Autopilot profile. It is a reporting mismatch between device completion and cloud status ingestion.

In practice, the pattern often looks like this:

1. Device enrolls and runs through OOBE.
2. ESP finishes or the user reaches the desktop.
3. The machine is shut down, disconnected, or otherwise stops talking to Intune before the final deployment state is recorded.
4. The Intune report keeps the record as In progress.
5. At four hours, the service marks it Failed because no terminal status was received.

That is why this symptom is so misleading. The record looks identical to a real failure unless you compare it with endpoint evidence.

How to Tell a False Failure From a Real One

A false failure usually has this profile:

• user reached the desktop
• required identity join and MDM enrollment completed
• no matching fatal ESP or Autopilot error in the local event logs
• the portal status changed later, not during the live provisioning window
• Graph or export data has weak or empty failure detail compared to real blocking incidents

A real failure usually has one or more of these:

• the device never reached the expected desktop state
• ESP visibly stalled or failed
• event logs show concrete Autopilot, TPM attestation, or enrollment errors
• required apps or policies never completed
• FailureReason, FailureDetails, EspDeviceSetupFailureDetails, or EspUserSetupFailureDetails point to a real blocking stage

Logs and Where to Check

1. Check the local Autopilot event log first

Microsoft’s Autopilot troubleshooting FAQ says Windows Autopilot logs to:

Application and Services Logs -> Microsoft -> Windows -> ModernDeployment-Diagnostics-Provider -> Autopilot

Pull the last 200 events:

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 200 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Sort-Object TimeCreated |
  Format-List

What you want to know:

• did the profile download succeed?
• was there a real device-side failure code?
• do the timestamps show a normal deployment flow followed by later cloud-side failure labeling?

If the device reached the desktop and this log does not show a matching fatal condition, the report entry deserves skepticism.

2. Capture Autopilot diagnostics before cleanup

If the device is still available, grab a CAB before anyone resets it:

mkdir C:\Temp -Force
Mdmdiagnosticstool.exe -area Autopilot -cab C:\Temp\autopilot-report-false-failure.cab

That gives you ticket evidence before the machine gets repurposed.

3. Review the Intune export, not only the portal grid

Microsoft documents the exportable report name AutopilotV1DeploymentStatus for the standard Windows Autopilot report under:

• Devices > Windows > Enrollment > Windows Autopilot

The available properties Microsoft lists for that report include:

• DeploymentState
• DeploymentStartDateTime
• DeploymentEndDateTime
• DeploymentDuration
• DeploymentTotalDuration
• FailureDetails
• FailureReason
• EspDeviceSetupFailureDetails
• EspUserSetupFailureDetails
• DeviceSerialNumber
• UPN

That export is usually more useful than a screenshot of the portal.

4. Query the Autopilot event resource through Graph

Microsoft Graph’s deviceManagementAutopilotEvent resource exposes fields such as:

• deploymentState
• deviceSetupStatus
• accountSetupStatus
• deploymentStartDateTime
• deploymentEndDateTime
• deploymentDuration
• deploymentTotalDuration
• enrollmentFailureDetails

Microsoft also documents deployment states such as:

• success
• inProgress
• failure
• successWithTimeout
• successOnRetry

Those states help when you need hard evidence that the reporting layer and the actual deployment outcome do not line up cleanly.

PowerShell and Graph Commands

Export the Intune Autopilot report

Microsoft documents the export API endpoint as:

https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs
https://graph.microsoft.com/v1.0/deviceManagement/reports/exportJobs

A practical export request for this case is:

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All,DeviceManagementConfiguration.Read.All"

$body = @{
  reportName = 'AutopilotV1DeploymentStatus'
  format = 'json'
  select = @(
    'DeviceName',
    'DeviceSerialNumber',
    'UPN',
    'DeploymentState',
    'DeploymentStartDateTime',
    'DeploymentEndDateTime',
    'DeploymentDuration',
    'DeploymentTotalDuration',
    'FailureDetails',
    'FailureReason',
    'EspDeviceSetupFailureDetails',
    'EspUserSetupFailureDetails'
  )
} | ConvertTo-Json -Depth 5

$job = Invoke-MgGraphRequest -Method POST -Uri 'https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs' -Body $body -ContentType 'application/json'
$jobId = $job.id

Do {
  Start-Sleep -Seconds 5
  $status = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs/$jobId"
  $status.status
} Until ($status.status -eq 'completed')

$status.url

Download the file from the returned URL and compare the serial number row against the endpoint evidence.

Query Autopilot event records directly

Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"

$serial = 'SERIAL-NUMBER-HERE'
$uri = "https://graph.microsoft.com/beta/deviceManagement/autopilotEvents?`$filter=deviceSerialNumber eq '$serial'"
Invoke-MgGraphRequest -Method GET -Uri $uri

Look at:

• deploymentState
• enrollmentState
• deploymentStartDateTime
• deploymentEndDateTime
• enrollmentFailureDetails

Pull local enrollment evidence

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Enrollments\*' -ErrorAction SilentlyContinue |
  Select-Object PSChildName, EnrollmentType, ProviderID

And confirm the device is still actively managed:

dsregcmd /status

That helps separate “reporting said failed” from “join or enrollment actually broke.”

Practical Remediation Workflow

Scenario 1: Device is healthy, report says Failed

This is the classic false-failure case.

1. Confirm the user can sign in and the expected management state exists.
2. Pull the local Autopilot log.
3. Export AutopilotV1DeploymentStatus.
4. Document the row values and timestamps.
5. Keep the case as a reporting defect unless you find real device-side failure evidence.

Do not wipe a healthy device just to make the dashboard look prettier.

Scenario 2: Report says Failed and ESP details show a real blocker

If export data or event logs point to a real failure reason, pivot immediately to the real problem:

• blocking app install
• device setup timeout
• account setup timeout
• TPM attestation failure
• join or enrollment issue

At that point, the false-failure article is no longer your root cause. It only explains why the report looked confusing.

Scenario 3: Pilot metrics are polluted by false failures

If you are validating a new rollout and getting several healthy machines marked Failed, change the bench process:

1. Leave the pilot device powered on longer after desktop arrival.
2. Make sure the network path remains open until reporting completes.
3. Export the report instead of relying on the grid.
4. Track pilot outcome with both endpoint evidence and report evidence.

That keeps rollout decisions from being driven by a cloud-side lag artifact.

Prevention

The best prevention is operational discipline around the final reporting window.

Keep devices online long enough to post final state

Microsoft explicitly says the bad state can happen when the device is powered off before the latest status is received. That makes shutdown timing part of the troubleshooting story.

For pilot and bench workflows:

• do not power off the device immediately after first desktop
• avoid yanking Ethernet as soon as the tech sees the desktop
• avoid judging success only from the grid in the first few hours

Use export data in every Autopilot review

The portal grid is convenient. The export is defensible.

Build your review around:

• DeploymentState
• FailureReason
• FailureDetails
• EspDeviceSetupFailureDetails
• EspUserSetupFailureDetails
• start and end timestamps

Teach the team the four-hour timeout behavior

If the service auto-flips In progress to Failed after four hours with no final status, then first-line engineers need to know that behavior exists. Otherwise they will escalate healthy devices as broken devices.

What Not to Do

For this exact symptom, these are usually the wrong first moves:

• wiping the device before checking the local event log
• deleting and reimporting the Autopilot record just because the portal is red
• blaming the ESP app list with no device-side evidence
• assuming every Failed state in the report is a true provisioning failure
• using only screenshots instead of report exports and logs

Those moves turn a reporting mismatch into unnecessary work.

Conclusion

A false Failed status in the Windows Autopilot report is usually a reporting completion problem, not automatic proof that provisioning broke.

Microsoft’s own wording is clear: the report can switch from In progress to Failed after four hours if Intune never receives the final state, including cases where the deployment was actually successful.

So the fastest path is:

1. verify the device really completed
2. pull the local Autopilot log
3. export AutopilotV1DeploymentStatus
4. compare DeploymentState, timing, and failure-detail fields
5. classify the incident correctly before you rebuild anything

If you do that consistently, you stop wasting healthy devices on fake failures and keep your Autopilot metrics honest.