Fix Autopilot Re-Enrollment Error 0x80180014 in Intune

Windows Autopilot error 0x80180014 is one of those failures that looks generic on the device but points to a narrow set of Intune enrollment controls. The usual symptom is a reset or reused device that reaches OOBE, starts enrollment, then fails with a message like Your organization does not support this version of Windows or a re-enrollment failure during self-deploying or pre-provisioning mode. If the hardware is valid and the tenant was working yesterday, do not start by rebuilding the image. Start with the Autopilot device record, Windows MDM platform restrictions, and the enrollment logs.

Microsoft documents two common causes for 0x80180014 in Autopilot scenarios: the device can be blocked during reuse in self-deploying or pre-provisioning mode, or Windows MDM enrollment can be disabled by an Intune enrollment restriction. The fix is usually in the Intune admin center, not on the OEM image.

What 0x80180014 means in Autopilot

In a plain Windows enrollment flow, Microsoft maps the message There was a problem. Your organization does not support this version of Windows. (0x80180014) to Windows MDM enrollment being disabled in the tenant. In the Intune admin center, that means the Windows MDM platform is blocked by a device platform restriction.

In Autopilot, the same code can show up when a previously enrolled device is reused, reset, or redeployed. Microsoft changed the self-deploying mode and pre-provisioning mode experience so reused devices may need the Intune-created device record handled correctly before another deployment. In the Autopilot troubleshooting FAQ, Microsoft says to use Unblock device for the affected Autopilot device, then redeploy the profile.

That distinction matters. If you only wipe the disk, you can repeat the same failure for an hour. If you only edit enrollment restrictions, you might miss the fact that the device is blocked because it was reused after a prior provisioning run. Treat the code as an enrollment authorization failure and prove which control is blocking the device.

Use these source points when you brief the service desk:

• Microsoft Learn lists 0x80180014 under Windows enrollment errors and ties it to Windows MDM enrollment being disabled.
• The Autopilot FAQ lists 0x80180014 for re-enrolling a previously enrolled device and gives an Unblock device workflow.
• Intune enrollment restrictions can block by platform, OS version, device manufacturer, device ownership, or device count.
• Microsoft warns that enrollment restrictions are not security features. They are a best-effort enrollment control, so they should not replace Conditional Access or compliance policy.

Quick triage checklist

Work through this order before you reset the device again:

1. Confirm the device is running Windows Pro, Enterprise, or Education. Windows Home is not supported for Autopilot enrollment.
2. In Intune, open Devices > Enrollment > Windows Autopilot > Devices and search by serial number.
3. If the device is blocked, select it and use Unblock device.
4. Confirm the device has the expected Autopilot deployment profile assigned.
5. Open Devices > Enrollment restrictions > Device platform restrictions.
6. Check the default restriction and any higher-priority restriction assigned to the user or device group.
7. Confirm Windows (MDM) is set to Allow for the matching restriction.
8. If personal Windows enrollment is blocked, confirm the device is authorized for corporate enrollment through Autopilot, GPO enrollment, co-management automatic enrollment, a bulk provisioning package, or a device enrollment manager account.
9. Collect MDM diagnostics from the device before wiping it again.
10. Retry enrollment only after the Intune-side control has been corrected.

The most common mistake is checking only the default restriction. Intune applies higher-priority enrollment restrictions to assigned groups. A pilot restriction assigned to a small test group can block Windows MDM for the exact admin account used at the bench, while the default All Users policy looks fine.

Fix 1: Unblock the reused Autopilot device

Use this path when the device was previously enrolled, reset, resealed, returned from repair, or reused for another Autopilot test.

1. Sign in to the Microsoft Intune admin center.
2. Go to Devices.
3. Under By platform, select Windows.
4. Go to Enrollment.
5. Under Windows Autopilot, select Devices.
6. Search for the serial number or hardware hash record.
7. Select the affected device.
8. Choose Unblock device.
9. Redeploy or reassign the intended Autopilot deployment profile.
10. Wait for profile assignment to settle, then reset the device and test again.

Microsoft notes that a success message may not always display after selecting Unblock device. Do not assume the action failed only because the portal did not give a satisfying confirmation banner. Refresh the device record, verify the profile assignment, and then run a clean test.

If the Autopilot object was deleted from Microsoft Entra ID but still exists in Autopilot, fix the identity anchor problem before another test. Microsoft warns that the Microsoft Entra device object acts as an anchor for Autopilot group membership and targeting. If it was deleted, delete and reimport the device as a Windows Autopilot device so the associated Microsoft Entra object is recreated.

Fix 2: Allow Windows MDM in enrollment restrictions

Use this path when the device shows the Your organization does not support this version of Windows wording, or when multiple devices start failing after an enrollment restriction change.

1. In the Intune admin center, open Devices > Enrollment.
2. Under Enrollment options, select Device platform restrictions.
3. Open the relevant restriction. Start with All Users, then check higher-priority policies.
4. Select Properties.
5. Next to Platform settings, select Edit.
6. Find Windows (MDM).
7. Set Windows (MDM) to Allow.
8. Select Review + save, then Save.
9. Repeat the review for any restriction assigned to the affected user, enrollment account, or pilot group.

Pay attention to policy priority. If the default policy allows Windows MDM but a higher-priority policy blocks it for a group, the higher-priority policy wins for matching users. This is why one technician can enroll the same device while another gets 0x80180014.

Also check device ownership restrictions. Blocking personally owned Windows devices is a common control, but Microsoft lists the enrollment methods that are considered authorized for corporate enrollment. Autopilot enrollment is one of them. If a device is not registered correctly with Autopilot, or if the Autopilot record is stale, the enrollment can be treated differently than you expect.

Collect evidence from the failed device

Do not wipe the failed device until you have at least one diagnostic package. For Autopilot and MDM enrollment problems, the built-in Windows diagnostic tool is enough for first-pass evidence.

Run this from an elevated command prompt after the failure screen if you can get to a command shell:

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

Microsoft documents that this package includes Autopilot ETLs, provisioning ETLs, MDMDiagHtmlReport.html, MDMDiagReport.xml, registry dumps from common MDM locations, and event logs. The admin event log to review is:

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

For Autopilot-specific flow details, also check:

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

Look for the timestamp where enrollment failed, then map that timestamp to Intune portal changes. Useful questions:

• Did someone add or reprioritize an enrollment restriction?
• Was the device recently reset after a pre-provisioning test?
• Was the Microsoft Entra device object deleted during cleanup?
• Is the device in more than one Autopilot assignment group?
• Is the user over a device limit restriction?
• Is Windows MDM blocked only for a pilot group?

The goal is not to collect every log in the tenant. The goal is to prove whether the failure came from a device reuse block, a Windows MDM platform block, or a targeting problem.

PowerShell checks for the service desk

If your team uses Microsoft Graph PowerShell, these checks help keep the triage consistent. Run them from an admin workstation with the right Graph permissions.

Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All", "DeviceManagementConfiguration.Read.All", "Device.Read.All"

$Serial = "DEVICE-SERIAL-HERE"

Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -All |
  Where-Object { $_.SerialNumber -eq $Serial } |
  Select-Object Id, SerialNumber, GroupTag, EnrollmentState, DeploymentProfileAssignmentStatus

Use the output to confirm that the device has an Autopilot identity and that the expected profile assignment is present. If your tenant has many Autopilot records, filter server-side where possible in your own scripts. The point here is to give the bench team a repeatable check, not to replace the portal.

For enrollment restrictions, document the current policy state in the change record. If a restriction was changed to fix an outage, record the affected group, the old Windows MDM state, the new Windows MDM state, and the time the next successful enrollment completed.

Common caveats

There are a few traps that make 0x80180014 take longer than it should.

First, do not confuse it with an ESP app install failure. If the device already enrolled and is stuck installing apps, you are in the Enrollment Status Page or Intune Management Extension layer. 0x80180014 is earlier. It blocks the device from getting through enrollment authorization.

Second, do not assume the Windows edition check is the only check. Windows Home causes Autopilot enrollment problems, but a supported edition can still fail when Windows MDM is blocked or the reused device is blocked.

Third, do not delete random device records during a live incident. The Autopilot device identity, Intune device object, and Microsoft Entra device object have different jobs. Deleting the wrong one can break assignment targeting and make the next enrollment attempt less predictable.

Fourth, remember that restriction assignment is user-aware in many enrollment paths. The device on the bench may not be the real variable. The enrollment account, group membership, or device enrollment manager status may be the difference between success and failure.

Prevention plan

After the immediate fix, add a small runbook so the error does not become tribal knowledge.

• Keep a standard Autopilot reuse process: retire or wipe in the right order, unblock when required, then redeploy the profile.
• Limit who can edit enrollment restrictions and require a change note for Windows MDM platform changes.
• Create a break-glass enrollment test account that is assigned to the same restrictions as normal technicians.
• Add 0x80180014 to the bench checklist with the two main branches: reused device block and Windows MDM restriction.
• Train the service desk to collect MDMDiagReport.zip before repeated wipes.
• Review stale Autopilot records monthly, especially devices used in labs, loaner pools, and repair workflows.

The fastest fix is usually simple: unblock the reused Autopilot device or allow Windows MDM in the matching enrollment restriction. The hard part is proving which one applies before another reset hides the evidence. Treat 0x80180014 as an Intune enrollment authorization problem, capture the logs once, fix the portal-side control, then retest with the same serial number and enrollment account.