Effortlessly Conquor Common Microsoft MDM Enrollment Errors

It’s been a while since I’ve blogged here but it’s certainly not for lack of content, but rather for lack of time! I’ve been working on tons of modern endpoint projects transitioning clients to Intune, or better put, Endpoint Manager. In the throws of these projects, I’ve created some fun Powershell scripts over on Github that you should check out!

As a long-awaited follow-up to The Hybrid AD Device Management Troubleshooting Guide, when Hybrid AD & Intune enrollment work well, they work really nicely for management and device security. But when it comes to failures enrolling devices into Intune, it’s not uncommon that I hear customers ask “How do I know that enrollment failed”? There are a number of scenarios but I’ll share the one at the heart of the content below:

  • My devices can’t deploy apps or policies from Intune
  • My machines aren’t properly Hybrid AD joining, which in turn…
  • My devices won’t adhere to Conditional Access rules (or cause failures)
  • I’m just a savvy admin and I see error codes in the event log

If you said the last one, you get a prize! And that price is the content below that will help decipher the WHY behind error codes and how to resolve them easily.

To find these errors, hop over to Event Viewer and drill down into:



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

But the easiest way to get there is running this from a Run / Command Prompt (or better, a desktop shortcut)


You see a myriad of events, which we wont get into the details of the workflow on MDM processing, but i encourage just tabbing up and down to look at the events after a machine boots to see how MDM processes against AAD / Intune

But without further adieu, here is my compendium of troubleshoot for MDM enrollment


0x82aa002a error


The device has trouble talking thru Conditional Access to authentication (even though CA is setup to allow exceptions)

0x82aa002b error


In order for Intune to register, and named user that has an Intune license needs to log in to finish enrollment.

0x82aa002b info


You are logged in as a user that does not have an Intune license, so MDM registration cannot occur.

Log in with a named and account licensed with a minimum of Azure AD P1 and Intune

0x82aa0008 Error

When you run an NSLOOKUP on the device after it is joined to the target AD, DNS servers reporting are source AD environment


Hard code network adapters with target AD DNS.

Machines reference the enterpriseenrollment DNS CNAME when performing MDM registration. When DHCP has DNS still pointed to the source AD environment, its forwards enterpriseregistration record requests to the source tenant using an target tenant credentials.

Pointing the machine to the target tenant enterpriseregistration DNS CNAME sends it to the correct tenant, and after a minute you should see the normal barrage of enrollment informational messages

0x80180005 error

When you attempted to authenticate you receive a “There is a problem” error message followed by generic error or Device error messages


This is usually indicative of greater DNS issues and communication – I’ve seen this with Hybrid AD and AutoPilot as well (either MDM permission or DNS issues)

Troubleshooting Windows Autopilot Hybrid Azure AD Join – Out of Office Hours (oofhours.com)

Intune Hybrid Domain Join Error 80180005 – Modern Deployment IT Blog

The system tried to delete the JOIN of a drive

This means that Hybrid AD join has not completed because we do not see the target tenant name / id or a certificate thumbprint.


In most cases a second reboot should help the first time after a device is synced to AAD, but Ive observed that when a machine is connected to source AD’s DNS it cannot resolve the target tenant’s enterpriseentrollment CNAME in DNS.

After a reboot, or fixing DNS, you should see the certificate information and the tenant name

Impersonation Result: An attempt was made to a token that does not exist

Machines cannot find an the Enterprise Enrollment endpoints during MDM registration. This is typically found in environment that has split brain DNS, and the internal DNS zone does not have the appropriate entries that Enterprise Enrollment references


Solution A:

Add in the following 2 DNS records


Alias: enterpriseregistration

Canonical name: enterpriseregistration.windows.net


Alias: enterpriseenrollment

Canonical name: enterpriseenrollment.manage.microsoft.com

Verify you can ping enterpriseregistration.<domain> and enterpriseenrollment.<domain>


MDM Enroll: Authentication failed. Failed to get token from STS

You have a conditional access policies that blocks Intune Enrollment that occurs via GPO and is unable to authenticate


If you perform this process manually via Access Work or School > Enroll in device management, you get prompted for MFA and upon hitting cancel are able to see the authentication box


In Conditional Access you can see the failed attempt by the user



(Whats funny is if you do it manually, it shows IE 11 as the user agent string)



In your Conditional Access rules where the condition / OS = Windows and Condition / Apps = Desktop and Browser, under Apps add Microsoft Intune and Microsoft Intune Enrollment to the Exclude list.



The reason we are bypassing conditionally access in this case is because the device is performing unattended enrollment, which considers the device as Corporate enrolled. If a user is attempting to enroll via the GUI, the Enrollment device platform restrictions will see that as a Personal enrollment and is blocked!


Auto MDM Enroll: Device Credential Failed (Access Denied)

When you have SCCM in your environment and are moving to a CoManaged state with Hybrid AD Join, you encounter an enrollment failure

MDM GPO under

Computer Configuration > Policies > Administrative Templates > Windows Components/MDM

We have Enable automatic MDM enrollment using default Azure AD credentials set to User Credential



Thanks to Auto MDM Enroll Impersonation Failure (Unknown Win32 Error code: 0x82aa0008) – How to Fix! (brookspeppin.com) it shed some light that

If you are using SCCM Co-Management, then this is always going to be “Device Credential” and the SCCM agent itself will facilitate the enrollment.

In this case we updated the Enable automatic MDM enrollment using default Azure AD credentials GPO updated to Device Credential


After a reboot of the PC (or GPUPDATE), enrollment proceeded as normal


Chris Blackburn

Learn More →

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.