As I have blogged about a lot, there are a bunch of hoops to be jumped through and prerequisites to be met for a successful hybrid Azure AD join and automatic, GPO-invoked Intune enrollment. But sometimes, you have to go back to the basics when you’re banging your head off the table, and laugh off the embarrassment of not checking the fundamentals.
I was recently setting up hybrid Azure AD join and Intune enrollment, as I’ve done hundreds of times before, but this time I was hitting a strange problem. Hybrid Azure AD join went fine, but for the Intune MDM enrollment, I was getting nowhere. Devices showed in the Azure AD admin centre, but never showed an MDM, and therefore never showed in Endpoint Manager.
On the device itself, the go-to command to begin troubleshooting this, for me, is dsregcmd /status. This is mostly for checking the domain status, but it spits out a bunch of MDM information too. Yet, everything looked good:
As you can see, it’s pulled down the MdmUrl and all the other key data you’d expect. This confirmed a couple of other prerequisites were definitely set up properly: user scope and licensing. I’ve heavily documented prerequisites, and the general process flow of all this, in my blog before, available here.
Where to now?
Event Viewer logs Windows’ attempt to MDM enrol within Applications and Service Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider, and this is where we get into more detail about specific errors. And boy there were a few:
You’ll see we have two error event IDs: 71 and 76. Interestingly enough, some of these had different error codes: 0x80192ee7, 0xcaa70004, and 0x82aa0008.
So, I next do what every sensible person does: Google it! Unfortunately, I’m left scratching my head: all the results are generic reports of the prerequisites I’ve already mentioned; specifically licensing. To further infuriate things, Microsoft’s MDM Registration Error Values page (here) lists none of these error codes. If some can adequately explain to me how Microsoft can get away with creating error codes but not documenting them online, please do.
Back to basics. The user account exists, can log in, has licenses assigned, is correctly linked from on-prem to Azure AD via AD Connect, and is within MDM scope as specified in Azure AD’s mobility options. Time to go even further back to basics. Can you see where this going yet?
As already seen in the results of dsregcmd /status, and confirmed within Azure AD, the address we need connectivity to for enrollment is https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc:
Getting there! From the above, at first, it looks like general network connectivity and DNS are fine because I can ping yahoo.com. Personally, I always test first using Yahoo because I’m confident enough it won’t be used that it won’t be in the DNS cache :-). Processing, though, and I can see that a ping to enrollment.management.microsoft.com. Completely fails, not even resolving to an IP address. Now it looks like we know the problem, because it’s always the problem: DNS.
Not being a DNS expert by any means, I stumbled into the DNS settings, which were on a Windows Server 2019 server. Looking at the server properties, the forwarding server was the server itself. Forwarders are servers that resolve DNS if the server itself cannot. My expectation, therefore, was that the forwarding server couldn’t resolve enrollment.manage.microsoft.com, but the root hints would allow it do to so, but that obviously wasn’t working. As soon as the forwarding servers were updated to include an alternative server, we got a result. You’ll not the ping doesn’t respond, but that could just be because the server doesn’t it. Importantly, we have an IP.
Back on the hybrid Azure AD joined device, automatic enrollment is attempted roughly every five minutes, and sure enough, the errors are replaced in Event Viewer by informational events. Key among these, event 72: MDM enroll: succeeded.
To sum up, errors 0x80192ee7, 0xcaa70004, and 0x82aa0008 for Intune enrolment were, in this case, DNS. Of course! But the moral of the story, for me, is to start with the fundamentals: using OSI, work your way up. I wasted time looking into a whole bunch of intricate prerequisites, none of which mattered, and I knew were set up correctly (due to earlier success) but still double and triple checked.
Hopefully, this blog will also help anyone else doing what every sensible person does: Googling it!
