Welcome to our blog on troubleshooting Windows Device Enrollment errors. In this post, we will guide you through resolving issues that may arise when enrolling an existing Entra ID Joined or Hybrid Entra ID Joined device into Intune.

1. MAM Instead of MDM

When your device was previously enrolled with MAM instead of MDM, you could run into the famous “device is already being managed by an organization” error! If you ever stumble upon this issue, you need to clean up the lingering registry keys first and then run the deviceenroller.exe.

$EnrollmentsPath = "HKLM:\SOFTWARE\Microsoft\Enrollments\"
 
$Enrollments = Get-ChildItem -Path $EnrollmentsPath
  
$DiscoveryServerFullUrls = @("https://wip.mam.manage.microsoft.com/Enroll")
 
Foreach ($Enrollment in $Enrollments) {
      $EnrollmentObject = Get-ItemProperty Registry::$Enrollment
      if ($EnrollmentObject."DiscoveryServiceFullURL" -in $DiscoveryServerFullUrls ) {
            $EnrollmentPath = $EnrollmentsPath + $EnrollmentObject."PSChildName"
            Remove-Item -Path $EnrollmentPath -Recurse
            &  "C:\Windows\System32\deviceenroller.exe /c /AutoEnrollMDM"
      }
}

2. The 80180026 error

When you have a device previously enrolled in SCCM, you could end up with a situation where there is still one lingering registry key that could block the enrollment. When that specific key is stuck, you will end up with the error 80180026 and, of course, as always, the message indicating that something went wrong!

Open the registry and open this key: SOFTWARE\Microsoft\Enrollments

Please ensure the “ExternallyManaged” key doesn’t exist or is configured to zero and NOT to 1 as shown above! It is good to know that Microsoft is also mentioning this error in their own version of troubleshooting device enrollment errors.

3. The 0x80180026 Error

Most of the time this nice 0x80180026 error only occurs at HAADJ devices. The first place to start looking at what is going on should always be the “Devicemanagement-Enterprise-Diagnostics-Provider” event log. As shown below, it will show you the error that it failed to enroll with RegisterDeviceWIthManagementUsingAADDeviceCredentials

This error can be resolved easily by making sure the “Disable MDM Enrollment” is not preventing your MDM Enrollment. I guess the name says it all

4. The 0x8018002a | 0x80070003 Error

As shown below, when trying to enroll your existing Azure Ad Joined device into Intune, you could end up with the 0x8018002a or the 0x80070003 Error.

auto mdm enroll: device credential (0x0), Failed (the system cannot find the path specified) code 0x80070003

This error could be due to a lot of reasons, but the 0x8018002a | 0x80070003 error is probably due to some Conditional Access rules you configured to make sure MFA is always required.

As shown above, this Conditional Access rule is targeted at “All Cloud Apps”. When we fix this error, we need to make sure we EXCLUDE the “Microsoft Intune Enrollment” Cloud app.

If you don’t want to exclude that Microsoft Intune Enrollment Cloud App (which makes sense), you need to open the shared experiences. In the Shared experiences center, you will notice that it is now telling you that some of your accounts require attention. If you click on Fix Now, it will guide you through authentication and will fix the issue.

5. The famous 0x8018002b Error

Yes, why not? Another error we could encounter when enrolling a device into Intune.

The above error 0x8018002b could be thrown at you for multiple reasons. Let’s take a look at some of them

• UPN ISSUES
• MDM Scope
• User License
• Patience
• Previously AADR enrolled

5.1 UPN Issues

Let’s start with some good old UPN issues!. When you didn’t configure the User Principal Name the right way! You will need to make sure the user his UPN matches your routable domain!

5.2 MDM Scope

It sounds obvious but when you didn’t configure the MDM scope or the user isn’t in the scope you will also run into this error. So please configure the MDM scope to “All” or “Some” (make sure the user is in that group!)

5.3 User License

As mentioned before, the enrollment is user-based so please make sure the user is licensed to use Intune! The best option you have to make sure the user is licensed to use Intune is running the “troubleshooting + support” tool in Intune

5.4 Patience

As mentioned in the blog about enrolling an existing device into MDM, it could really take a whole day before your device is enrolled. So have some patience when the device isn’t being enrolled into Intune on the fly

5.5 Device previously AADR enrolled

Sometimes, when a device was previously enrolled with AADR, you could also encounter the 0x8018002b error. To solve it, we could remove the lingering enrollments in the registry with this PowerShell script

$RegistryKeys = "HKLM:\SOFTWARE\Microsoft\Enrollments", "HKLM:\SOFTWARE\Microsoft\Enrollments\Status","HKLM:\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked", "HKLM:\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled", "HKLM:\SOFTWARE\Microsoft\PolicyManager\Providers","HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts", "HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Logger", "HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Sessions"

$EnrollmentID = Get-ScheduledTask -taskname 'PushLaunch' -ErrorAction SilentlyContinue | Where-Object {$_.TaskPath -like "*Microsoft*Windows*EnterpriseMgmt*"} | Select-Object -ExpandProperty TaskPath -Unique | Where-Object {$_ -like "*-*-*"} | Split-Path -Leaf

		foreach ($Key in $RegistryKeys) {
				if (Test-Path -Path $Key) {
					get-ChildItem -Path $Key | Where-Object {$_.Name -match $EnrollmentID} | Remove-Item -Recurse -Force -Confirm:$false -ErrorAction SilentlyContinue
	}
}
$IntuneCert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {
		$_.Issuer -match "Intune MDM" 
	} | Remove-Item
if ($EnrollmentID -ne $null) { 
	foreach ($enrollment in $enrollmentid){
			Get-ScheduledTask | Where-Object {$_.Taskpath -match $Enrollment} | Unregister-ScheduledTask -Confirm:$false
			$scheduleObject = New-Object -ComObject schedule.service
			$scheduleObject.connect()
			$rootFolder = $scheduleObject.GetFolder("\Microsoft\Windows\EnterpriseMgmt")
			$rootFolder.DeleteFolder($Enrollment,$null)
} 
} 

$EnrollmentIDMDM = Get-ScheduledTask | Where-Object {$_.TaskPath -like "*Microsoft*Windows*EnterpriseMgmt*"} | Select-Object -ExpandProperty TaskPath -Unique | Where-Object {$_ -like "*-*-*"} | Split-Path -Leaf
		foreach ($Key in $RegistryKeys) {
				if (Test-Path -Path $Key) {
					get-ChildItem -Path $Key | Where-Object {$_.Name -match $EnrollmentIDMDM} | Remove-Item -Recurse -Force -Confirm:$false -ErrorAction SilentlyContinue
	}
}
if ($EnrollmentIDMDM -ne $null) { 
	foreach ($enrollment in $enrollmentidMDM){
			Get-ScheduledTask | Where-Object {$_.Taskpath -match $Enrollment} | Unregister-ScheduledTask -Confirm:$false
			$scheduleObject = New-Object -ComObject schedule.service
			$scheduleObject.connect()
			$rootFolder = $scheduleObject.GetFolder("\Microsoft\Windows\EnterpriseMgmt")
			$rootFolder.DeleteFolder($Enrollment,$null)
} 
$IntuneCert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {
		$_.Issuer -match "Microsoft Device Management Device CA" 
	} | Remove-Item
}	
Start-Sleep -Seconds 5
$EnrollmentProcess = Start-Process -FilePath "C:\Windows\System32\DeviceEnroller.exe" -ArgumentList "/C /AutoenrollMDM" -NoNewWindow -Wait -PassThru

6.  The 0x80180001 Error

When enrolling your devices with the GPO or PowerShell script I showed you, you could run into the 0x80180001 error (failed to receive or parse certificate enroll response)

This error would only occur if you configured the credential type to use: Device Credential

As shown above, you need to configure the credential type to use: User Credential because Device Credential is only supported with Co-management or Azure Virtual Desktop. As shown in part 5 you needed to configure the MDM scope because the enrollment user-based NOT device-based

7. The 0x80192ee2/ 0x82aa0008 Errors

When you have SCCM co-management in place for your HAADJ devices you could notice the 0x82aa0008 error in the event log. Normally, when you have configured the Auto MDM enroll GPO to use Device Credentials, you are good to go!

But as shown below, you could still run into the “Impersonation failure” error

If you notice this error, please make sure that a user is logged in! Even when using device credentials, it seems to fail when no user is logged in.

So please make sure a user is logged in on the device. If you don’t want to wait, just use the device enroller again, but this time with the AADeviceCredential parameter.

%windir%\system32\deviceenroller.exe /c /AutoEnrollMDMUsingAADDeviceCredential

8. Schedule to enroll in MDM from AAD not created

Sometimes, when we are trying to enroll our device into Intune, a schedule named Schedule Created by enrollment client for automatically enrolling in MDM from AAD Properties will not be created automatically.

If, for some reason, that schedule isn’t created, you could always manually create the schedule, right?

$TaskScheduleName ="Schedule created by enrollment client for automatically enrolling in MDM from AAD"
$Date = Get-Date -Format "yyyy-MM-dd"
$Time = (Get-date).AddMinutes(5).ToString("HH:mm:ss")
 
$task = @"
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Author>Microsoft Corporation</Author>
    <URI>\Microsoft\Windows\EnterpriseMgmt\Schedule created by enrollment client for automatically enrolling in MDM from AAD</URI>
    <SecurityDescriptor>D:P(A;;FA;;;BA)(A;;FA;;;SY)(A;;FRFX;;;LS)</SecurityDescriptor>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT5M</Interval>
        <Duration>P1D</Duration>
        <StopAtDurationEnd>true</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>$($Date)T$($Time)</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>Queue</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>true</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>true</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>false</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT1H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>%windir%\system32\deviceenroller.exe</Command>
      <Arguments>/c /AutoEnrollMDM</Arguments>
    </Exec>
  </Actions>
</Task>
 
"@
  
(Register-ScheduledTask -XML $task -TaskName $TaskScheduleName -Force) | Out-null

9. 0x80180005:

When you are trying to onboard your device with Autopilot and somehow the Intune enrollment is not succeeding: “Mismatch between ZTD Profile and enrollment request intent” 0x80180005

When this is the case, the solution is really simple, you need to delete the Autopilot configuration file that was deployed to your device.

You will find this file in the corresponding Windows Management service folder.

c:\windows\servicestate\wmansvc\AutopilotDDSZTDFile.json

Delete the file and retry the enrollment!

10. 0x8018000A:

If you end up with the error: 0x8018000a as shown below, you need to make sure there aren’t any lingering enrollments.

For example, if your device is already enrolled with Sophos Mobile MDM, enrolling the same device into Intune isn’t going to work.

The device already has an active enrollment, so you must remove it from Sophos Management first!

After the device has been removed from the old MDM, you can enroll it into Intune!

11. 0x80180031/ 0x8007052

If you get the 0x80180031 MDM Not Configured or 0x8007052 Failed to find MDM Information error during Intune enrollment, it likely points to missing MDM URLs or scope misconfigurations. The solution involves checking MDM scope settings, confirming DNS CNAMEs, and reviewing registry entries related to MDM enrollment. For a step-by-step breakdown of troubleshooting this error, including using dsregcmd /status and applying a PowerShell fix, check out the full blog”

0x80180031 | Mobile Device Management is not configured (call4cloud.nl)0

Conclusion

Enrolling your device into Intune/MDM is always a smart thing to do but sometimes you could run into some weird failures. Hopefully, this blog showed you how to deal with some of them. If you have any additions feel free to send me a PM