How to Get the Intune Enrollment errors Outta Your Ass

Last Updated on December 22, 2023 by rudyooms

This blog will be about troubleshooting the Intune enrollment when using a GPO or a PowerShell script to enroll an existing Azure Ad Joined OR Hybrid Azure Ad Joined device into Intune.

I decided to pull this part from my Enroll existing devices into the Intune MDM blog because it was becoming too large after trying to answer some posts on Reddit and other forums 😉

I will divide this blog into multiple parts

  • The first part will show you how to fix the enrollment when it was MAM enrolled instead of MDM enrolled.
  • The second part will show you how to fix the 80180026 error when a device was previously enrolled with SCCM
  • The third part will show you how to fix the 0x80180026 error when the scheduled task is executed
  • The fourth part will show you how to fix the 0x8018002a error when the scheduled task is executed
  • The fifth part will show you how to fix the 0x8018002b error when the scheduled task is executed
  • The sixth part will show you how to fix the  0x80180001 error when the scheduled task is executed.
  • The Seventh part will show you how to fix the 0x80192ee2/ 0x82aa0008 error when the scheduled task is executed
  • The Eighth part will show you how to manually create the Schedule to enroll in MDM from AAD
  • The Ninth Part will show you how to deal with 0x80180005 when your device is having issues enrolling into Intune
  • The Tenth Part will show you how to deal with 0x8018000a when your device is having issues enrolling 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 run the deviceenroller.exe afterward.

$EnrollmentsPath = "HKLM:\SOFTWARE\Microsoft\Enrollments\"
$Enrollments = Get-ChildItem -Path $EnrollmentsPath
$DiscoveryServerFullUrls = @("")
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 that was 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!

3. The 0x80180026 Error

Most of the time this nice 0x80180026 error is only occurring 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.

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.

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

  • 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 sometimes before your device is enrolled. So have some patience when the device isn’t being enrolled into Intune on the fly

Be Patient GIFs - Get the best GIF on GIPHY

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"

$IntuneCert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {
		$_.Issuer -match "Intune MDM" 
	} | Remove-Item

$EnrollmentID = Get-ScheduledTask | Where-Object {$_.TaskPath -like "*Microsoft*Windows*EnterpriseMgmt*"} | Select-Object -ExpandProperty TaskPath -Unique | Where-Object {$_ -like "*-*-*"} | Split-Path -Leaf
Get-ScheduledTask | Where-Object {$_.Taskpath -match $EnrollmentID} | Unregister-ScheduledTask -Confirm:$false
			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

			Start-Sleep -Seconds 30
$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.

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/ 0x82aa000 Errors

When you have SCCM co-management in place for your HAADJ devices you could notice the 0x82aa000 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 are noticing 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 and if you don’t want to wait, just use the device enroller again! but this time with the AADeviceCredential paremeter

%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="">
    <Author>Microsoft Corporation</Author>
    <URI>\Microsoft\Windows\EnterpriseMgmt\Schedule created by enrollment client for automatically enrolling in MDM from AAD</URI>
    <Principal id="Author">
  <Actions Context="Author">
      <Arguments>/c /AutoEnrollMDM</Arguments>
(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 intent0x80180005

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.


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 will need to make sure you are removing the device from Sophos Management first!

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


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

Failure GIFs | Tenor

19 thoughts on “How to Get the Intune Enrollment errors Outta Your Ass

  1. I am trying to deploy an Azure AD Joined AVD with intune enrolment and I can’t find what I am doing wrong.
    If I deploy the same AVD without Intune enrolment it works but I can’t depend of the user to enrol it.

    I tried to use create the AutoEnrolment manually but it will fail on both, User or Device.
    We have 100s of devices enrolled and I have no idea what might be causing only the AVDs to fail the enrolment

    User Credential enrolment failure:
    “Mobile Device Management (MDM) is not configured. (0x90180031)”

    Device Credential enrolment error:
    “The license of the user is in bad state blocking enrollment. (0x80180018)”

    1. I assume you made sure the prereqs are all valid

  2. On some (few) of our HAAD device enrolled into Intune by group policy, we are seeing the 0x8018002a Error.

    To solve it we exclude the “Microsoft Intune Enrollment” app from our MFA CA policy.

    I have only been able to try this on one machine, and at that point, I also exclude the “Microsoft Intune” app from the CA policy.

    Is it enough to only exclude “Microsoft Intune Enrollment”?

    After searching the Internet, I have a hard time understanding the difference between the two…

    Another thing that makes me confusef is that we do not have “Microsoft Intune Enrollment” under Mobility (MDM and MAM), only Microsoft Intune…

    Is that different from the cloud apps you can exclude in CA policies?

    In older threads I see it explained like:
    – Microsoft Intune: This represents Intune as a whole (and your Windows Intune subscription), and most of the configuration is in this application
    – Microsoft Intune Enrollment: This only represents Intune enrollment as a security principal in AAD. All user based enrollments in Intune will be forced to authenticate against “Microsoft Intune Enrollment”. If the admin wants to configure AAD CA policies (e.g. 2FA) that only apply to enrollment, they should be done here.

    In a slightly newer thread its explained like:
    “Microsoft Intune” covers both the MDM and MAM scenarios. So whenever users hit MDM discovery URL “” or the MAM URL “” then a CA policy covering “Microsoft Intune” will be applied.

    So my question is, if we want to avoid the 0x8018002a Error, is it enough to just exclude “Microsoft Intune Enrollment”? Can you please advise?


  3. im getting error Auto MDM Enroll: Device Credential (0x0), Failed (Unknown Win32 Error code: 0xcaa20003)

    not listed there

    1. Hi.. Nope as I didnt stumbled upon that error until now. Could you tell something more about your environment? by the looks of it, its an authentication error.
      Haadj? Adfs?

  4. Can you post some troubleshooting for below error
    Auto MDM Enroll: Device Credential (0x0), Failed (Unknown Win32 Error code: 0xcaa82ee2)
    specific to error code 0xcaa82ee2

  5. Hi, I have Azure joined devices (not hybrid), and users with Intune licenses. I followed the steps (using powershell method) and prerequisites in the original guide. But the scheduled task is not being created am getting the following event viewer error when trying to run: C:\Windows\system32\deviceenroller.exe /c /AutoEnrollMDM

    “Auto MDM Enroll: Device Credential (0x0), Failed (A specified logon session does not exist. It may already have been terminated.)”

  6. Thank you so much!
    I was getting “Auto MDM Enroll: Device Credential (0x0), Failed (Unknown Win32 Error code: 0x80180026)” and the fix for number 2 error 80190026 did it for me! The ExternallyManaged key was set to 1. Set it to 0 and it worked like a charm!

  7. Script doesnt seem to be working for me, have deployed a few times over 2 days but none are appearing in endpoint manager.

    When I ask users to use company portal app they get the error “Your device is already connected to your organization” yet it shows MDM none and AAD joined in AAD.

    Anything I can check when I dont have anything except CLI access to the devices or any thoughts?

  8. Hi,
    I’m a sys admin trying to enroll my devices into the Company Portal then to Intune, Company Portal has my sign in, but when I go to enroll, the set up your device page appears. On it, the first step, Add corporate account to this device (which is already signed in) has a yellow exclamation point. I’m not sure how to get Company Portal to detect my corporate account. When I hit next and add work account, opens a microsoft login window where I enter my email and it says this device is already connected to your organization.

  9. Hello !

    Thank you for the vast information on this topic, you are really doing great work :).

    I have the following problem: We have domain joined devices that have the Microsoft Endpoint Configuration Manager Client installed on it during setup which is conducted using an image. The MECM is used to manage these devices (only clients, no servers). Moreover, we have hybrid Entra joined them using Entra Connect Sync (Azure AD Connect Sync). Theses devices are then enrolled into Intune per GPO. The GPO is set to be using user credentials and the enrollment scope in Intune is set to group containing the licensed users. The MECM and Windows versions are always kept current. Users are licensed with M365 E3.

    A new requirement now is that we can use device compliance using Microsoft Intune for conditional access. Therefore we would configure Cloud attach and use co-management where the workload for compliance is set to Intune and the rest would be set to MECM.

    My question now is if it is possible to just configure cloud attach and co-management for these devices in their current enrollment state or if the gpo enrollment into intune is a problem therefore? Moreover, if the GPO is no road blocker, should it be configured to use device or user credentials ?

    I am a bit confused because in the official MS docs for the GPO enrollment the following is stated:
    “In Windows 10, version 1903 and later, the MDM.admx file was updated to include the Device Credential option to select which credential is used to enroll the device. The default behavior for older releases is to revert to User Credential.
    Device Credential is only supported for Microsoft Intune enrollment in scenarios with Co-management or Azure Virtual Desktop multi-session host pools because the Intune subscription is user centric. User credentials are supported for Azure Virtual Desktop personal host pools.”

    However, in the Cloud Attach docs no GPO enrollment is mentioned …

    My guess would be to delete the group policy setting including the Intune enrollment configuration, then do a gpupdate on all devices, delete the devices from the Intune admin center and then configure cloud attach with co-management for these devices to re-enroll them with a clean state.

    My hope would be to just configure cloud attach and co-mamangement and either switch the GPO to use device credentials or delete the GPO at all …

    Thank you for your time !

  10. Hello, I’m getting this error when I attempt to run the improved script you created:

    Get-Item : Cannot find path ‘HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\TenantInfo’ because it does not exist.

    Does anyone know how to fix this? Do I need to create that key entry? I’m very new to Intune so I’m flying blind here…

  11. Thanks for the article, really useful. I was trying to enrol am existing Hybrid joined device. The scheduled task exists and the error I get is Auto MDM Enroll: Device Credential (0x0), Failed (Mobile Device Management (MDM) is not configured.). Does the user need to be logged into the computer for it to work?


Leave a Reply

Your email address will not be published. Required fields are marked *

8  +  2  =