Intune Enrollment Error Codes: Complete Troubleshooting Reference for IT Admins

Published 27 June 2026 · 12 min read · Microsoft Intune · Windows Enrollment · Autopilot

Intune enrollment failures are among the most time-consuming issues an endpoint administrator can face. The error codes Windows surfaces during MDM enrollment are often cryptic hexadecimal values with little immediate context. This reference guide consolidates the most common enrollment errors, their root causes, and the exact remediation steps to resolve them — saving you the hours of documentation diving that would otherwise be required.

Microsoft MVP Peter van der Woude has extensively documented many of these Intune enrollment errors on his blog over the years, and his analysis informed several of the resolutions covered here. Where relevant, the guidance below aligns with official Microsoft documentation on troubleshooting Windows enrollment errors.

Quick Reference: Enrollment Error Code Table

The table below provides a fast lookup for the most common Intune and MDM enrollment error codes encountered in Windows environments.

Error 0x80180026 — Device Join Fails During MDM Enrollment via Entra

This error surfaces when a device attempts to enroll into Intune via an Entra ID (formerly Azure AD) join and the MDM enrollment step fails. It is one of the most frequently encountered errors in corporate Autopilot and bulk enrollment scenarios.

Root Causes

• Auto MDM enrollment GPO not configured or misconfigured. Group Policy must enable automatic MDM enrollment for users in scope. The setting lives at Computer Configuration > Administrative Templates > Windows Components > MDM > Enable automatic MDM enrollment using default Azure AD credentials. If this is set to User Credential instead of Device Credential, enrollment will fail for devices without a logged-in user (such as during OOBE).
• Device limit in Entra ID reached. Each user account in Entra has a configurable maximum number of devices they can join. The default is typically 50, but tenant-specific limits may be lower. Navigate to Entra admin center > Devices > Device settings > Maximum number of devices per user to verify and increase as needed.
• Intune client or service endpoint unreachable. The device must reach enrollment.manage.microsoft.com and enterpriseregistration.windows.net. Proxy configurations, SSL inspection, or firewall rules blocking these endpoints will cause 0x80180026.

Resolution Steps

1. Verify the MDM auto-enrollment GPO is correctly configured and applied using gpresult /r.
2. Check the device count for the enrolling user in Entra admin center > Users > [User] > Devices. Remove stale device registrations.
3. Confirm the Intune MDM scope includes the user. In Intune > Devices > Enroll devices > Windows enrollment > Automatic Enrollment, ensure the MDM user scope is set to All or includes the enrolling user's group.
4. Test network connectivity to Microsoft enrollment endpoints from the device.

Error 0x80070774 — Autopilot Hybrid Join Timeout

This error is particularly insidious because it has three distinct root causes that all produce the same error code. Rudy Ooms (Call4Cloud) has written in depth about this error and the "Assign user" pitfall — his analysis is essential reading for anyone managing Hybrid Azure AD Join Autopilot deployments.

Cause 1: "Assign User" Feature Performing Entra Join Before Domain Join

When an IT admin pre-assigns a user to an Autopilot device profile in the Intune portal, Windows attempts an Entra ID join in the background before completing the on-premises domain join. In Hybrid Join scenarios, this ordering is fatal — the domain join must complete first, and the premature Entra join causes the timeout and subsequent 0x80070774 error.

Cause 2: Intune Connector Installed on Wrong Domain

The Intune Connector for Active Directory (the ODJ connector service) must be installed on a domain-joined server in the same domain where the computer objects will be created. If your environment has multiple AD domains or forests and the connector is installed in the wrong domain, the Offline Domain Join (ODJ) blob will target the wrong domain and the join will time out.

Verify the connector health in Intune > Devices > Windows > Windows enrollment > Intune Connector for Active Directory. Each connector shows its domain and last check-in time. Ensure a healthy connector exists for every target domain.

Cause 3: TLS / PKCS Registry Fix Required

On some Windows Server versions hosting the Intune Connector, TLS 1.2 may not be properly enforced for .NET applications, causing the connector's outbound HTTPS communication to fail silently. This produces enrollment timeouts that manifest as 0x80070774 on the client.

Apply the following registry settings on the server running the Intune Connector for Active Directory:

# Enable TLS 1.2 for .NET Framework on the Intune Connector server
# Run on the server hosting the Intune Connector for Active Directory

$regPaths = @(
    'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319'
)

foreach ($path in $regPaths) {
    if (-not (Test-Path $path)) {
        New-Item -Path $path -Force | Out-Null
    }
    Set-ItemProperty -Path $path -Name 'SchUseStrongCrypto' -Value 1 -Type DWord
    Set-ItemProperty -Path $path -Name 'SystemDefaultTlsVersions' -Value 1 -Type DWord
    Write-Host "Applied TLS 1.2 settings to: $path" -ForegroundColor Green
}

# Restart the Intune ODJ Connector Service
Restart-Service -Name 'IntuneODJConnectorSvc' -Force
Write-Host "Intune Connector service restarted." -ForegroundColor Cyan

After applying these registry keys, restart the Intune Connector service and re-attempt enrollment.

Error 80180018 — Device Already Enrolled in Another MDM

This error indicates the device has an active MDM enrollment with a different provider — or a stale Intune enrollment record that was not properly cleaned up. It is common when devices are migrated from a third-party MDM (such as VMware Workspace ONE, JAMF, or MobileIron) to Intune, or when a device is re-enrolled without a proper wipe.

Resolution

1. On the device, navigate to Settings > Accounts > Access work or school and disconnect any existing MDM enrollment.
2. In the Intune portal, locate the device record and perform a Retire action (not Delete) to ensure the server-side enrollment is cleanly removed before re-enrolling.
3. Check the registry key HKLM:\SOFTWARE\Microsoft\Enrollments for orphaned enrollment GUIDs from previous MDM vendors and remove them.
4. For bulk migrations, Microsoft's Troubleshoot device enrollment in Intune documentation outlines the correct sequence for clean re-enrollment.

Error 8018000a — User MDM License Not Assigned

This is one of the most straightforward errors to diagnose but is surprisingly common in large enterprise environments where license assignment is automated or delegated. The enrolling user does not have a valid Intune license — either it was never assigned, was removed due to a group membership change, or the license pool is exhausted.

Resolution

Verify and assign the license using the following PowerShell snippet (requires Microsoft Graph PowerShell SDK):

# Check if a user has an Intune license assigned
# Requires: Connect-MgGraph -Scopes 'User.Read.All','Directory.Read.All'

$userUPN = 'user@contoso.com'

$user = Get-MgUser -UserId $userUPN -Property AssignedLicenses, DisplayName
$licenses = Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -match 'INTUNE|EMS|SPE_E3|SPE_E5|M365' }

foreach ($lic in $licenses) {
    $assigned = $user.AssignedLicenses | Where-Object { $_.SkuId -eq $lic.SkuId }
    if ($assigned) {
        Write-Host "[ASSIGNED] $($lic.SkuPartNumber)" -ForegroundColor Green
    } else {
        Write-Host "[MISSING]  $($lic.SkuPartNumber)" -ForegroundColor Yellow
    }
}

# Available units remaining
foreach ($lic in $licenses) {
    $available = $lic.PrepaidUnits.Enabled - $lic.ConsumedUnits
    Write-Host "$($lic.SkuPartNumber): $available units available"
}

Error 801c0003 — User Not Authorized to Join Devices

This error occurs when the user attempting to join a device to Entra ID has either reached their per-user device limit or is not in the set of users permitted to perform device joins. Jan Ketil Skanke (Microsoft MVP, CloudWay) has highlighted this as a common oversight in tightly governed Entra environments.

Resolution

• In Entra admin center > Devices > Device settings, confirm that Users may join devices to Azure AD is set to All or that the user is in the selected group.
• Check the Maximum number of devices per user setting and increase it if the user has hit their limit. You can also clean up old device records for that user.
• For Autopilot deployments, consider using device-based enrollment flows that are not subject to the per-user join limit.

Error 0x80090016 — TPM Not Available or Not Ready

This error appears in Autopilot and Entra Join scenarios that require device attestation via the Trusted Platform Module. It typically surfaces on virtual machines, legacy hardware without TPM 2.0, or physical devices where the TPM has not been provisioned.

Root Causes and Fixes

• TPM disabled in BIOS/UEFI: Boot into firmware settings and enable the TPM. On Intel platforms this may be labelled PTT (Platform Trust Technology); on AMD platforms, fTPM.
• TPM not provisioned: Open tpm.msc on the device. If the TPM shows as "Not ready for use", click Prepare the TPM and follow the wizard. A reboot is typically required.
• TPM attestation failure in Autopilot: If the device is registered in Autopilot but fails hardware attestation, check Windows Autopilot troubleshooting FAQ for TPM attestation-specific guidance. Rudy Ooms has written extensively about TPM attestation failures in hybrid environments on his Call4Cloud blog.
• Virtual machines: Unless the VM platform supports vTPM (Hyper-V Generation 2 VMs with vTPM enabled, or VMware with vTPM), Autopilot flows requiring attestation will fail. Enable vTPM in the VM configuration if your platform supports it.

General Troubleshooting Steps

1. Event Viewer — DeviceManagement-Enterprise-Diagnostics-Provider

The most direct source of MDM enrollment error detail on the device itself is the dedicated ETW log for device management. Navigate to:

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

Filter for Error and Warning events. The Event IDs most relevant to enrollment failures are in the 72xxx and 74xxx ranges. The full error codes and sub-codes are surfaced here before they are summarised into the hexadecimal values shown to the user.

# Export last 50 MDM enrollment events from the diagnostic provider log
$logName = 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'
$events = Get-WinEvent -LogName $logName -MaxEvents 50 -ErrorAction SilentlyContinue

if ($events) {
    $events | Select-Object TimeCreated, Id, LevelDisplayName, Message |
        Format-Table -AutoSize -Wrap
} else {
    Write-Warning "No events found or log not accessible. Ensure you are running as Administrator."
}

2. Collect MDM Diagnostic Logs

Windows includes a built-in MDM log export capability accessible without administrative elevation:

Settings > Accounts > Access work or school > [Connected account] > Info > Export your management logs

This exports a ZIP archive to %USERPROFILE%\Documents\MDMDiagnostics containing MDM enrollment logs, policy application results, certificate store snapshots, and WMI bridge query results. The MDMDiagReport.html file inside the archive is particularly useful for reviewing policy assignment status at a glance.

You can also trigger this from an elevated command prompt:

# Export MDM diagnostic report to a specified output path
$outputPath = "C:\Temp\MDMDiag_$(Get-Date -Format 'yyyyMMdd_HHmmss')"
New-Item -ItemType Directory -Path $outputPath -Force | Out-Null

$mdmDiag = "$env:SystemRoot\System32\MdmDiagnosticsTool.exe"

if (Test-Path $mdmDiag) {
    # -area is comma-separated; DeviceEnrollment captures enrollment-specific logs
    Start-Process -FilePath $mdmDiag `
        -ArgumentList "-area DeviceEnrollment;Autopilot -zip `"$outputPath\MDMDiag.zip`"" `
        -Wait -NoNewWindow
    Write-Host "Diagnostics exported to: $outputPath\MDMDiag.zip" -ForegroundColor Green
} else {
    Write-Warning "MdmDiagnosticsTool.exe not found. Minimum Windows 10 1903 required."
}

3. Windows Autopilot Diagnostics Page

During OOBE on Windows 11 (build 22H2 and later) and on devices running the Windows Autopilot diagnostics update for Windows 10, you can access an interactive diagnostics overlay by pressing Ctrl+Shift+D during the Autopilot provisioning flow. This page displays real-time status of each provisioning phase — device registration, Entra join, MDM enrollment, and ESP policy application — making it significantly faster to identify exactly which phase is failing without needing to wait for a full failure and then review logs post-mortem.

For more detail on Autopilot-specific troubleshooting, the Windows Autopilot troubleshooting FAQ on Microsoft Learn is the authoritative starting point. Michael Niehaus, the creator of Windows Autopilot, also maintains a wealth of deep-dive content on the deployment sequence at Out of Hours (oofhours.com).

Additional Resources

• Troubleshoot Windows device enrollment problems in Intune — Microsoft Learn
• Troubleshoot device enrollment in Intune — Microsoft Learn
• Windows Autopilot troubleshooting FAQ — Microsoft Learn
• Support Tip: Using MdmDiagnosticsTool.exe in Intune — Microsoft Tech Community
• Understanding the Windows Autopilot diagnostics page — Microsoft Support