Craig Wall
Public sector systems admin, specializing in device management, mobility and deployment.
GitHub
My Endpoint Manager List on Twitter
Co-Management MDM Enroll Error: Device Credential (0x0), Failed (Unknown Win32 Error code: 0xcaa9001f)
I recently setup an SCCM Co-Management home lab.
When testing the MDM enrollment to Intune of an AD-joined device, I ran into a 0xcaa90014 error. The failure showed up in two places:
In Windows Event Viewer, it shows up in DeviceManagement-Enterprise-Diagnostics-Provider as:
Event ID 76: Auto MDM Enroll: Device Credential (0x0), Failed (Unknown Win32 Error code: 0xcaa9001f)
A separate error shows up in the client’s Co-Management logs, found under %WINDIR%\CCM\Logs\CoManagementHandler.log:
The reason for the 0xCAA9001F error is that the device is not logged in with a credential that Azure AD recognizes.
My home lab was using an unverified domain — my home lab was using a domain like test.contoso.com, but since it’s unverified, the user accounts were synced to Azure AD as walldev.onmicrosoft.com.
I was logged into my test client VM as CONTOSO\USER when I had to sign in as an AAD user — as a @walldev.onmicrosoft.com user.
Solution: Create an Alternative UPN Suffix in Active Directory Domains and Trusts
On your AD domain, load Active Directory Domains and Trusts.
Right-click the “Active Directory Domains and Trusts” heading and click Properties.
Under “Alternative UPN Suffix”, add in the domain that your Azure AD tenant is using. In my case this was walldev.onmicrosoft.com:
Then we need to configure your user account to use this alternate UPN suffix.
On your AD domain, start AD Users and Computers
Search for the user account you’re using to login to your AD client for MDM enrollment. Right-click it and go to Properties.
Go to the Account tab.
Under User Logon name, there’s a pulldown box next to your username that shows the local domain.
Click the pulldown and select the alternate UPN suffix that now shows up there.
Click Apply and then exit.
Once I did this, I was able to login to my VM domain client as USER@walldev.onmicrosoft.com instead of CONTOSO\USER.
And almost immediately after that login completed, the MDM enrollment succeeded.
If this doesn’t do the trick for you, then see the linked MS Docs article at the bottom of this post, which runs through another possible solution (enabling both AD User Discovery and Azure AD User Discovery)
The M365 Developer Program Makes This Setup Free, By the Way
Intune licenses normally require an E3/A3 or E5/A5 license.
However, sign up for the M365 Developer Program, which is free, and you get Azure AD plus 25 licenses at the A5/E5 level to test with!
The only drawback: It doesn’t come with any Azure credits.
So if you want to implement the next logical step for testing — a Cloud Management Gateway — the resources it sets up will cost money.