You wipe or reset a Windows device that has been through Autopilot before, start the deployment again, and it stops at MDM enrollment with error 0x80180014. In this post I'll explain the two causes Microsoft documents for this error, how to tell them apart, and how to get the device through Autopilot again without touching its Autopilot registration.
Symptoms#
The device downloads its Autopilot profile, but enrollment into Intune fails. You'll typically see some combination of the following:
- In self-deploying mode or the pre-provisioning technician flow, the device preparation phase of the Enrollment Status Page fails at Register your device for mobile management with
0x80180014. - In other enrollment paths the same code appears on an error page. For a manual Microsoft Entra join, Microsoft documents the message as "Your organization does not support this version of Windows. (0x80180014)".
- The device enrolled fine the first time. The failure starts after it was wiped, reset, handed to someone else, or had its profile redeployed.
- Event tracing (ETW) logs for MDM enrollment can show a
DeviceNotSupportedfault with the reasonEnrollment blocked for AP device by SDM One Time Limit Check.
Why it happens#
The Windows Autopilot troubleshooting FAQ describes two scenarios behind 0x80180014 on a previously enrolled device. Both can produce the same log entry, so check for both:
- The old Intune device record blocks reuse. For self-deploying and pre-provisioning deployments, Intune requires the device record created by the previous enrollment to be cleared before the same hardware can enroll again. That applies whether the device is being reused, reset, or redeployed.
- Windows MDM enrollment is blocked. If a device platform restriction that applies to the enrollment has Windows (MDM) set to Block, enrollment fails with the same code.
Microsoft's known-issues page also lists a second workaround for the reuse scenario: allowing personally owned Windows (MDM) devices in the enrollment restriction. Most organizations block personal Windows enrollment on purpose, so treat that option as a last resort.
What is not the problem: the Autopilot registration (the hardware hash) and the Microsoft Entra device object that was created when the hash was imported. That Entra object is Autopilot's anchor for group membership and profile targeting, and Microsoft warns that deleting it can lead to Entra join errors. Leave both alone.
How to fix it#
- Rule out a platform block. In the Microsoft Intune admin center, go to Devices › Windows › Enrollment › Device platform restriction. Open each Windows restriction, starting with All Users, select Properties, then Edit next to Platform settings. Confirm that Windows (MDM) is set to Allow. If other restrictions are assigned to groups, make sure the device or user isn't in a group whose restriction blocks Windows (MDM).
- Unblock the device for reuse. Go to Devices › Windows › Enrollment and, under Windows Autopilot, select Devices. Find the device by serial number, select it, and choose Unblock device in the toolbar. Don't wait for a success banner; the FAQ notes that one might not appear even though the device is ready to be used again.
- Alternatively, delete the stale Intune record. The known-issues page documents deleting the device record in Intune and then redeploying. In Devices › Windows, open the old record, check the serial number so you remove the right one, and select Delete. This removes the device from Intune only; the Autopilot registration and the Entra object stay where they are.
- Use the personally owned workaround only if you must. Allowing personally owned Windows (MDM) devices in the restriction also clears the error, but it opens personal Windows enrollment for everyone that restriction covers. If you go this way, scope it narrowly and switch it back afterwards.
- Redeploy. Reset the device and run the deployment again. For pre-provisioning, restart the technician flow by pressing the Windows key five times during OOBE.
Watch out: Don't "clean up" by also deleting the device from Windows Autopilot or from Microsoft Entra ID. If the Entra object that Autopilot created is deleted, the documented recovery is to delete and re-import the device as an Autopilot device, which costs far more time than the original error.
Verify the fix#
- The device gets past Register your device for mobile management and continues into device setup.
- A new record shows up in Devices › Windows with the right serial number, Corporate ownership and a current last check-in time. Don't judge by the Enrolled date column: Microsoft lists a known issue where it shows the Autopilot registration date rather than the enrollment date.
- The Autopilot deployment report under Devices › Monitor shows the new attempt as successful. The earlier failed attempt can stay in the report as a separate row.
If the error comes back, collect logs before you change anything else. Press Shift+F10 during OOBE and run:
mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\autopilot.cabThen recheck both causes: confirm you unblocked or deleted the record that matches this serial number, give the change a few minutes to process, and look again at every restriction that could apply to the device or the enrolling account.
Prevent it next time#
- Make "unblock or delete the Intune record" a fixed step in your reuse runbook for self-deploying and pre-provisioned devices, done before the device boots back into OOBE.
- Remove only the Intune object when you recycle hardware. Keep the Autopilot registration and its Entra device object so group tags, dynamic groups and profile assignment keep working.
- Keep Windows (MDM) allowed in every restriction that can apply to Autopilot enrollments, and recheck restriction priority whenever you add a new one.
- If personal Windows enrollment is blocked by design, fix reuse with unblock or delete rather than loosening the restriction.