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
- 1 0x82aa002a error
- 2 0x82aa002b error
- 3 0x82aa0008 Error
- 4 0x80180005 error
- 5 The system tried to delete the JOIN of a drive
- 6 Impersonation Result: An attempt was made to a token that does not exist
- 7 MDM Enroll: Authentication failed. Failed to get token from STS
- 8 Auto MDM Enroll: Device Credential Failed (Access Denied)
The device has trouble talking thru Conditional Access to authentication (even though CA is setup to allow exceptions)
In order for Intune to register, and named user that has an Intune license needs to log in to finish enrollment.
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
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
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)
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
Add in the following 2 DNS records
Canonical name: enterpriseregistration.windows.net
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