Intune Enrollment Error Codes: Complete Troubleshooting Guide

Windows MDM enrollment failures are among the most time-consuming issues an endpoint administrator faces. The hex error codes that surface during enrollment or OOBE — 0x80180026, 0x80070774, 80180018, and a handful of others — are cryptic without context. This post consolidates the most common ones: what each means, where to look in the logs to confirm the diagnosis, and the exact steps to fix it.

The problem:

The device is stuck. Either it's hung at the OOBE "Setting up your device for work" spinner, it threw an error screen mid-enrollment, or it enrolled but the Intune portal shows it as non-compliant with no policies applied. The screen — or the event log — shows a hex error code. The error alone doesn't tell you whether it's an Azure AD token problem, a network issue, a TPM fault, or something left over from a previous enrollment that wasn't cleaned up. All of those produce different codes, and they each need a different fix.

Why it happens:

Windows MDM enrollment is a multi-stage pipeline. Every stage must succeed for the device to reach the "Managed by Intune" state. The stages, in order:

1. Azure AD Join (or Hybrid Join) — the device authenticates to Azure AD and receives a device object. Hybrid Join also requires the on-premises Entra Connect sync to have processed the computer account first.
2. MDM Terms of Use acceptance — for user-driven flows, the user must accept the Terms of Use presented by the MDM authority.
3. MDM auto-enrollment trigger — Windows reads the MDM enrollment URL from Azure AD, then schedules an auto-enrollment task using the Task Scheduler Schedule created by enrollment client task under Microsoft\Windows\EnterpriseMgmt.
4. MDM enrollment session — the Windows MDM client (dmclient.exe) opens an HTTPS session to the Intune service, exchanges device certificates, and receives the initial policy payload.
5. Policy application — the received payload is applied: compliance policies, configuration profiles, app assignments. The device is marked enrolled in the Intune portal only after this completes.

A failure at any stage produces a specific error code. The table in The fix section below maps each code to its pipeline stage.

How to verify:

Before touching any settings, pull the diagnostic data from the device. Two sources cover the full enrollment pipeline:

Event Viewer path

The primary log for MDM enrollment events is:

A typical enrollment attempt that fails at the MDM session stage looks like this:

Export the log and run MdmDiagnosticsTool

For a clean offline export that you can share with Microsoft Support, run both of the following (elevated PowerShell):

# Export the MDM enrollment event log to a CSV you can sort/filter
Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Export-Csv -Path "$env:TEMP\MDMEnrollment_$(Get-Date -Format yyyyMMdd_HHmm).csv" -NoTypeInformation

Write-Host "Log exported to $env:TEMP"

# Run the built-in MDM diagnostics collector (generates a ZIP with logs, ETLs, registry exports)
MdmDiagnosticsTool.exe -out "$env:TEMP\MdmDiag_$(Get-Date -Format yyyyMMdd_HHmm)"
Write-Host "MdmDiagnosticsTool output in $env:TEMP"

The fix:

Quick reference

Error 0x80180026 — MDM auto-enroll policy not configured

This error means one of three things: (1) the GPO or Settings Catalog policy that tells Windows to auto-enroll into MDM is missing or hasn't applied, (2) the Azure AD device limit for the user has been reached, or (3) the MDM enrollment endpoint is unreachable from the device's network segment.

CSP / OMA-URI note: This policy doesn't have a device-side CSP toggle you can deploy as a custom OMA-URI profile. Instead, configure it via the Settings Catalog in Intune by searching for:

GPO path (on-premises / hybrid):

Registry key the GPO sets (verify it landed on the device after a gpupdate /force):

Fix steps:

1. Sign in to intune.microsoft.com and create a Settings Catalog profile targeting the MDM auto-enroll setting above, OR link the GPO to the correct OU and confirm gpupdate /force applies it.
2. In Entra ID (entra.microsoft.com), go to Devices › Device settings and check Maximum number of devices per user. If the user has hit their limit, either raise it or remove stale device objects for that user.
3. Confirm the device can reach enrollment.manage.microsoft.com and fef.msua01.manage.microsoft.com (or the regional equivalent) on port 443. A proxy or firewall blocking MDM endpoints produces the same error code.

Error 0x80070774 — Hybrid Join timeout

This error is specific to Hybrid Azure AD Join scenarios. Three causes account for almost all occurrences:

1. "Assign user" ordering — in Autopilot, the device was pre-assigned to a user before the on-premises computer account had synced to Azure AD. The MDM enrollment fires before the Hybrid Join is complete.
2. Wrong connector domain — the Azure AD Connect connector is joined to a different domain than the one where the device computer account lives, so the Hybrid Join request never reaches a DC that can service it.
3. TLS registry issue — legacy TLS settings in the registry prevent the AAD Connect connector from completing the HTTPS handshake to Azure AD endpoints.

For the TLS registry issue, apply this fix on the server running the Azure AD Connect connector:

# Run on the Azure AD Connect / Entra Connect server — fixes TLS 1.2 enforcement
# that can block the connector's HTTPS session to Azure AD

$tlsPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

# Ensure TLS 1.2 is explicitly enabled for client connections
$tls12Client = "$tlsPath\TLS 1.2\Client"
if (-not (Test-Path $tls12Client)) { New-Item -Path $tls12Client -Force | Out-Null }
Set-ItemProperty -Path $tls12Client -Name 'Enabled'         -Value 1 -Type DWord
Set-ItemProperty -Path $tls12Client -Name 'DisabledByDefault' -Value 0 -Type DWord

# Ensure .NET uses TLS 1.2 by default (required for the connector's managed code)
$net64 = 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'
$net32 = 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319'
foreach ($path in $net64, $net32) {
    Set-ItemProperty -Path $path -Name 'SystemDefaultTlsVersions' -Value 1 -Type DWord
    Set-ItemProperty -Path $path -Name 'SchUseStrongCrypto'       -Value 1 -Type DWord
}

Write-Host "TLS 1.2 registry values applied. Restart the connector service or the server to take effect."

Fix steps for the ordering issue: In Autopilot, do not pre-assign the user until after the computer account has synced to Azure AD. Confirm sync with Get-MsolDevice -DeviceName <computername> in the MSOnline module — if the object isn't there yet, wait for the next sync cycle (default 30 minutes) before proceeding with enrollment.

Error 80180018 — Prior MDM enrollment not cleaned up

The device has stale MDM enrollment objects from a previous enrollment that wasn't properly unenrolled. The enrollment pipeline finds these and fails rather than overwriting them.

Fix steps:

1. On the device, open Settings › Accounts › Access work or school and disconnect any existing work/school account shown there before attempting re-enrollment.
2. Delete the stale enrollment keys from the registry (run elevated):

# Remove stale MDM enrollment registry keys — run elevated
# Review the keys before deleting; each GUID is one enrollment object

$enrollmentRoot = 'HKLM:\SOFTWARE\Microsoft\Enrollments'
Get-ChildItem $enrollmentRoot | ForEach-Object {
    $key  = $_
    $type = (Get-ItemProperty $key.PSPath -Name 'EnrollmentType' -ErrorAction SilentlyContinue).EnrollmentType
    $state = (Get-ItemProperty $key.PSPath -Name 'EnrollmentState' -ErrorAction SilentlyContinue).EnrollmentState
    Write-Host "GUID: $($key.PSChildName)  Type: $type  State: $state"
    # State 1 = Enrolled, State 6 = Failed/stale — remove State 6
    if ($state -eq 6) {
        Write-Host "  -> Removing stale enrollment $($key.PSChildName)"
        Remove-Item $key.PSPath -Recurse -Force
    }
}
Write-Host "Done. Re-enroll the device via Settings > Accounts > Access work or school."

3. Also remove the corresponding task scheduler entries under Microsoft\Windows\EnterpriseMgmt\<EnrollmentGUID> if they are still present after the registry cleanup.
4. In the Intune portal, go to the device object and select Retire (not Wipe) to remove the Intune management relationship before re-enrolling.

Error 8018000a — Licence not assigned

The user account doesn't have an Intune licence (or a Microsoft 365 licence that includes Intune). The MDM service rejects the enrollment at the session stage.

# Check whether a user has an Intune or M365 licence assigned
# Requires Microsoft.Graph module: Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes 'User.Read.All', 'LicenseAssignment.Read.All'

$upn = 'user@contoso.com'   # replace with the affected user's UPN
$user = Get-MgUser -UserId $upn -Property AssignedLicenses, DisplayName

if ($user.AssignedLicenses.Count -eq 0) {
    Write-Host "No licences assigned to $($user.DisplayName)" -ForegroundColor Red
} else {
    # List SKU IDs — Intune standalone is 'INTUNE_A', M365 E3/E5 includes it
    $skus = Get-MgSubscribedSku | Where-Object { $_.SkuId -in $user.AssignedLicenses.SkuId }
    $skus | Select-Object SkuPartNumber, CapabilityStatus | Format-Table
}

# Intune-specific SKU part numbers: INTUNE_A, SPE_E3, SPE_E5, M365_F1, M365_F3

Fix steps: In Entra ID, navigate to the user › Licences › Assignments and assign either an Intune P1 standalone licence or a Microsoft 365 plan that includes Intune (E3, E5, F1, F3, Business Premium). Licence propagation to the MDM service takes up to 15 minutes — wait before retrying enrollment.

Error 801c0003 — User not authorised to Azure AD Join

The user's account isn't permitted to join devices to Azure AD. This is a tenant-level setting in Entra ID Device settings.

Fix steps:

1. Sign in to entra.microsoft.com.
2. Go to Identity › Devices › Device settings.
3. Under Users may join devices to Azure AD, either set it to All or select Selected and add the user or their group.
4. If using Autopilot with a pre-assigned user, also confirm the user is in the Autopilot deployment profile assignment scope.

Error 0x80090016 — TPM not ready

The device's TPM chip isn't in a usable state. MDM enrollment on Windows 11 requires a functioning TPM 2.0 for device certificate operations.

Common causes:

• TPM not provisioned — factory-new or re-imaged device where the TPM wasn't initialised after the OS install.
• TPM ownership conflict — a previous OS instance held TPM ownership; the current OS can't claim it without clearing.
• Firmware TPM (fTPM) in bad state — AMD fTPM devices have had known issues across certain firmware versions where the fTPM reports ready but fails key operations.

Fix steps:

1. Run tpm.msc on the device and check the status. If it shows "The TPM is ready for use" but enrollment still fails, the fTPM may need a firmware update.
2. If the status shows any other state, select Clear TPM in tpm.msc (ensure BitLocker is suspended first and recovery keys are escrowed).
3. Reboot into UEFI/BIOS and confirm the TPM is enabled and set to version 2.0.
4. After reboot, Windows will re-provision the TPM automatically on next startup.

Proof it worked:

Two checks confirm the device is genuinely enrolled — not just that the enrollment task ran.

1. Event ID 72 in the MDM log

Event ID 72 in the DeviceManagement-Enterprise-Diagnostics-Provider/Admin log is the "MDM session started successfully" event. It appears after a successful enrollment, not just after an attempt. Run this to confirm it's there (illustrative output — run on the actual device after enrollment):

# Confirm enrollment success via Event ID 72 in the MDM log
# Run on the enrolled device (no elevation required)

$log = 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'

$events = Get-WinEvent -LogName $log -MaxEvents 200 |
    Where-Object { $_.Id -eq 72 } |
    Select-Object TimeCreated, Id, Message

if ($events) {
    Write-Host "Enrollment success events found:" -ForegroundColor Green
    $events | Format-Table -AutoSize
} else {
    Write-Host "No Event ID 72 found in last 200 MDM log entries — enrollment may not have completed." -ForegroundColor Red
}

# Illustrative output on a successfully enrolled device:
# TimeCreated              Id  Message
# -----------              --  -------
# 2026-06-27 09:31:44     72  Auto MDM Enroll: Device Credential (0x0), hr=0x0
# (hr=0x0 means success — any non-zero hr value indicates the session failed)

2. Intune portal showing "Managed by Intune"

In the Intune admin center, the device should appear with a Managed by Intune status and a last check-in time within the last few minutes:

Also verify the enrollment key exists in the registry at the expected path:

References

• Microsoft Learn — Troubleshoot Windows enrollment errors in Intune
• Microsoft Learn — Troubleshoot device enrollment in Microsoft Intune
• Microsoft Learn — Windows Autopilot troubleshooting FAQ
• Intune Customer Success — Using MdmDiagnosticsTool.exe in Intune