Fix Autopilot Pre-Provisioning Error 0x80180005 in Intune

Windows Autopilot pre-provisioning error 0x80180005 usually shows up at the worst point in the workflow. The hardware hash is imported, the deployment profile looks assigned, the technician presses the Windows key five times, and the device still stops with We couldn’t finish MDM enrollment. In many cases, the device-side log adds an even more useful clue: ZTD Profile was not assigned to ZTD Device.

That combination tells you to stop treating 0x80180005 as a generic Windows enrollment failure. In pre-provisioning, it is usually an Intune targeting or readiness problem first, and a device rebuild problem second. Microsoft Learn and Microsoft Q&A point to the same pattern: verify the Autopilot deployment profile assignment, confirm the device is really recognized as an Autopilot device, collect the MDM diagnostics, and only then chase network or hybrid join prerequisites.

This guide is for Desktop Engineers and Intune admins who hit 0x80180005 during Windows Autopilot pre-provisioning, white-glove deployment, or vendor-led bench provisioning.

What 0x80180005 usually means during pre-provisioning

Microsoft’s Autopilot documentation does not present 0x80180005 as one single root cause. Instead, the surrounding guidance makes the repair path clear:

• The Autopilot troubleshooting FAQ tells you to review failure diagnostics collected from the device.
• The pre-provisioning article requires the Autopilot deployment profile and the Enrollment Status Page (ESP) profile to be targeted to the device.
• The hybrid Autopilot guidance adds extra prerequisites such as Intune Connector for Active Directory health, domain controller reachability, supported VPN behavior, and successful Microsoft Entra hybrid join preparation.
• Microsoft Q&A cases for this exact error show device logs with ZTD Profile was not assigned to ZTD Device, which points directly at Autopilot profile targeting rather than a random local OS problem.

So in practice, 0x80180005 in pre-provisioning means one of four things:

1. The device does not have a usable Autopilot deployment profile at the moment pre-provisioning starts.
2. The device record is stale, reused, blocked, or otherwise not matching the expected Autopilot object.
3. The ESP or enrollment path is not ready for the deployment mode you selected.
4. In hybrid scenarios, the join prerequisites are incomplete even though the pre-provisioning screen started.

If your log says ZTD Profile was not assigned to ZTD Device, start with targeting. Do not start by reimaging the laptop.

Quick triage checklist

Use this order before you wipe or reseal the device again:

1. In Intune admin center > Devices > Windows > Windows enrollment > Devices, find the Autopilot record by serial number.
2. Confirm the record exists only once and matches the current hardware.
3. Verify the intended Autopilot deployment profile is assigned to the device.
4. Wait for dynamic group membership and profile assignment to settle if the device was imported recently.
5. Confirm an Enrollment Status Page profile is targeted to the device, because Microsoft documents that ESP must be targeted for pre-provisioning.
6. If the device was previously used, reset, resealed, or recycled from another test, check whether it is blocked or has stale records tied to the old deployment.
7. Collect diagnostics from the failed device before retrying.
8. If this is a hybrid join profile, validate the Intune Connector for Active Directory, line of sight to a domain controller, and any VPN dependencies.
9. Retry on one pilot device after you correct the Intune-side issue.
10. Only broaden the fix after one device completes pre-provisioning end to end.

That order saves time because most bench failures happen above the OS layer. The device is often healthy. The assignment chain is not.

Fix 1: Prove the device really has an Autopilot profile

The most actionable clue from Microsoft Q&A is the event text ZTD Profile was not assigned to ZTD Device. When you see that, assume the device entered Autopilot flow before Intune considered the deployment profile fully assigned.

Check these items carefully:

Confirm the Autopilot object is correct

Open the Autopilot devices list and compare:

• Serial number
• Group tag if you use one
• Assigned deployment profile
• Last contact or import timing
• Whether there are duplicate records for the same hardware

A newly imported device can appear in the portal before every dependent assignment is ready. If you imported a CSV, changed group tags, or moved the device between deployment groups shortly before testing, give profile targeting time to settle.

Check dynamic group logic

Many Autopilot setups depend on dynamic Entra groups based on group tag, purchase order ID, or physical IDs. If the device enters OOBE before that membership finishes processing, Intune can still behave as though the device has no usable ZTD profile.

Practical checks:

• Confirm the device object is in the expected assignment group.
• Confirm the deployment profile is assigned to that exact group.
• Confirm no newer profile assignment is waiting on a different group.
• Avoid changing group tags and immediately starting pre-provisioning.

If you want a fast proof, temporarily assign the intended deployment profile directly to a narrow test group that contains only the affected device. If the device succeeds, your root cause is the targeting chain, not the hardware.

Fix 2: Verify ESP targeting and deployment mode readiness

Microsoft’s pre-provisioning documentation is explicit that the Enrollment Status Page profile must be targeted to the device. If it is missing, mis-scoped, or assigned only to users when the bench flow expects device targeting, your pre-provisioning run can fail in messy ways.

Check the following:

• The device receives the expected ESP profile.
• The ESP profile is intended for the same Windows enrollment scenario.
• Required apps or scripts in ESP are still valid and not referencing removed content.
• Any blocking app tracked by ESP is still assigned to the device context you are testing.

Also verify you are using the right deployment mode for the profile:

• Microsoft Entra joined pre-provisioning has simpler dependency paths.
• Hybrid Microsoft Entra joined pre-provisioning adds connector, domain join, and network complexity.

If the device is expected to be hybrid joined, do not trust the fact that OOBE reached the Autopilot screen. Microsoft documents that hybrid deployments still depend on the Intune Connector for Active Directory and successful line of sight to the domain controller at the right stage.

Fix 3: Clean up reused or stale device state

Reused Autopilot hardware creates confusing failures because the screen looks new while the tenant record is not. Microsoft’s Autopilot troubleshooting guidance already warns admins to handle reused devices carefully in self-deploying and pre-provisioning scenarios.

Investigate these conditions:

• The same device was pre-provisioned earlier and then reset for another user.
• The Microsoft Entra device object was deleted but the Autopilot record remained.
• The Intune-managed device object from the last run still exists and is interfering with the new flow.
• The device was imported again, creating duplicate or mismatched records.

What to do:

1. Record the serial number and current Autopilot object details.
2. Compare the Autopilot record, Intune managed device record, and Microsoft Entra device object.
3. Remove only the stale records that clearly belong to the failed older enrollment.
4. Reconfirm the device receives the intended Autopilot profile after cleanup.
5. Retry on the same test device before touching the wider batch.

Do not mass-delete Autopilot records because one technician bench run failed. Clean up only the object chain for the affected serial number.

Fix 4: Validate hybrid join prerequisites when applicable

If your deployment profile is Microsoft Entra hybrid joined, 0x80180005 can be the last visible symptom of a prerequisite gap that began earlier in the process.

Microsoft’s hybrid Autopilot documentation calls out several dependencies that matter here:

• The Intune Connector for Active Directory must be installed and healthy.
• The environment must already support Microsoft Entra hybrid joined devices.
• The device must be able to reach the domain controller when the domain join portion occurs.
• If a proxy is in use, required proxy behavior such as WPAD support must be correct.
• VPN design matters. Microsoft lists tested and unsupported client behavior for Autopilot hybrid flows.

For hybrid failures, verify these in order:

1. Connector server health and service status.
2. Connector logs in Event Viewer.
3. OU and domain join profile settings.
4. Reachability to a domain controller from the network used during provisioning.
5. Whether the device is bench-tested on a network path different from the one used in production.

A common enterprise miss is that the vendor or bench team can reach Intune and Autopilot services, but cannot satisfy the domain join leg required by the hybrid profile. In that case the device appears close to success until enrollment fails.

Collect the evidence before retrying

Microsoft’s Autopilot FAQ recommends reviewing diagnostics collected from the failed device. That is the right move here because 0x80180005 without logs is too broad.

From a command prompt on the failed device, collect MDM diagnostics:

mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"

Then inspect these locations first:

Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin

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

You are looking for timestamps and messages that answer these questions:

• Did the device say the ZTD profile was not assigned?
• Did enrollment start before profile assignment settled?
• Did the device fail at app provisioning, device preparation, or hybrid join?
• Did the failure line up with a recent group, profile, or ESP change in Intune?

If you have one successful device and one failed device from the same batch, compare their Autopilot assignment path first. That comparison is often faster than reading every event in the CAB.

Practical remediation workflow that works in the field

When a bench technician calls with 0x80180005, use this workflow:

1. Pause more resets. Repeated retries hide the original evidence.
2. Export the diagnostics package from one failed device.
3. Confirm the Autopilot record, deployment profile, and ESP assignment by serial number.
4. Check dynamic group membership and any recent tag or assignment changes.
5. If reused hardware is involved, clean up stale records for that serial number only.
6. If hybrid join is involved, validate connector health and domain controller reachability.
7. Wait for assignment consistency if you just changed targeting.
8. Retry pre-provisioning on one device.
9. If it succeeds, release the rest of the batch.
10. If it fails again with the same ZTD message, escalate with the diagnostics package and exact event text.

That gives you a defensible service desk process and prevents the classic mistake of calling it a random Autopilot outage.

Limitations and caveats

0x80180005 is still a generic enough enrollment code that you should avoid overpromising one magic fix. The same screen can appear for profile targeting delays, stale device objects, hybrid dependency failures, and broader enrollment readiness issues.

Also be careful with timing. A profile can look assigned in the admin center while the device is still early for a dependable pre-provisioning test. If the hardware was just imported, just moved to a new group, or just had its tag changed, your first remediation may simply be to let targeting finish.

Finally, do not copy a working fix from a Microsoft Entra joined device to a hybrid joined profile without checking the deployment mode. The hybrid path has more dependencies and deserves its own validation.

Conclusion

Autopilot pre-provisioning error 0x80180005 is usually not solved by starting over from scratch. It is solved by proving whether the device truly had a valid ZTD deployment profile, an ESP assignment, clean device records, and the right prerequisites for its join mode.

If your logs show ZTD Profile was not assigned to ZTD Device, believe the log. Fix the targeting chain first. Once the Autopilot object, deployment profile, ESP, and enrollment path all line up, the same hardware often completes pre-provisioning without any image change at all.