User not recieveing MDM url for Intune automatic enrollment

Question

Hey everyone,

We have been going through the process of enrolling our existing Windows domain joined machines to Intune MDM, we had about 180 users and most of them have been enrolled fine. These are all Hybrid AAD Joined machines.
A quick summary of procedure we followed:

• Made sure we had the machine object in Azure AD as Hybrid Joined and registered (this is how we check if the machine is Azure AD joined)
• Check on the machine for dsregcmd /status and see if the MDM url is populated
• Apply the Automatic enrollment GPO on the machine

We have had most success when we have followed the above method.
But we have one machine which is failing at the second point where it is not getting the MDM url. I have checked and made sure that the user who is logged into the machine has an Intune license. I understand this usually takes time, but for this user it has been more than two weeks. The machine is joined to Azure AD successfully, it has an hybrid Azure AD record with a registered date and an activity date. This is the first user among 150+ users we have enrolled who is having this issue.

I have noticed with previous enrolments that without MDM url, the machine won't automatically enroll into intune even if the intune automatic enrollment GPO is applied on the machine.

What we have done for troubleshooting:

• Remove/unjoin the machine from Azure AAD using dsregcmd /leave
• Made sure the Hybrid Azure AD object was deleted
• Rejoined the machine back to Azure AD

This process didn't help, it has been 5 days since we did this troubleshooting steps.

Any help would be appreciated.

Answer 1

First, don't conflate hybrid AAD join (HAADJ) with [full] AAD join (AADJ), they are two very different things. I know we sometimes lump these two together for simplicity purposes, but at a technical level, they are very different and saying/writing AADJ in place of HAADJ is not valid.

Thus, when you say "Rejoined the machine back to Azure AD", how exactly did you do this?

Also, have you reviewed the event logs on the device in question? Specifically the "Workplace Join" log?

Have you reviewed all of the info at https://learn.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-hybrid-join-windows-current?

Answer 2

Hi @Jason Sandys ,

Thank you for the response and informing me about the usage of HAAD vs AADJ. Still a bit confused on how to use these terminologies.

when you say "Rejoined the machine back to Azure AD", how exactly did you do this?
I used dsregcmd /leave command so that I can have "AzureADJoined: No" in the Device State section of the dsregcmd /status command. So this removed the object from Azure AD. After which I resynced the object and let the workplace join happen again.

[So just to put it right, the machine in question is joined to Local Active Directory. Just to give you a step deeper in our process, what we do is we have a specific OU in our Active Directory for computer objects which sync to our Azure instance. As part of general process we move these machine to that specific OU which would then sync to Azure and object in Azure AD will be registered as "Hybrid Azure AD joined"]

The Workplace log doesn't has only logs until the device state is changed to "AzureADJoined: Yes". After this I don't see any logs in Workplace Join.

In terms of the link shared for troubleshooting

• The machine passes the evaluation phase with the following
  DomainJoined: Yes
  WorkplaceJoined: No
  AzureADJoined: Yes

The missing items in device data is TenantName, MDMurl, MDMtoURL. However I do see that there is a Tenant ID, which matches with our Tenant.

Answer 3

HAADJ is really just an on-prem domain join + an AAD registration at the device level (more or less as you've called out). Very little changes about the behavior of the system, users log in with their on-prem AD credentials. As you've seen, for the device registration in AAD to happen, this requires a sync of the device objects involving AAD Connect.

AADJ is a full join to AAD and has no direct involvement or interaction with your on-prem AD. Users login with their AAD credentials (which could be synced using AAD connect if they still need access to anything on-prem that requires authentication by your on-prem AD).

Unfortunately, for "reasons" (that I have no control over), the dsregcmd tool does say "AzureADJoined" but this doesn't actually mean it is truly joined to AAD, just registered in this case when it is also "DomainJoined".

Does the user have an AADP1 license assigned to them?

Is the user included in the MDM scope as detailed at https://learn.microsoft.com/en-us/mem/intune/fundamentals/deployment-guide-enrollment-windows#automatic-enrollment-administrator-tasks (screenshot at https://techcommunity.microsoft.com/t5/image/serverpage/image-id/376733i9A641F312A4000D3/image-size/medium?v=v2&px=400)?

Answer 4

Thank you for clarification @Jason Sandys

Ohh I see so even with "AzureADJoined: Yes" it may not be fully joined. On the Azure Ad side, on checking the object it does have a registered date, until now I was using this field to determine whether machine is with the device "AzureADJoined: Yes" without interacting with the user.

The user has an E3 license , which I believe includes Azure AD P1 license and the user has intune license.
I can definitely confirm the user is MDM scope as we use the same group to assign Intune License and be part of MDM scope.

The setup we have had worked for every user until now, close 140 users. This is the first user whom I am having an issue like this. I have tried to compare certain computer object attributes between a successfully enrolled machine and this machine, also compared a successfully enrolled user profile with this user's profile and no major difference.

Now what I have done is I have went ahead and applied the GPO for the users machine to perform automatic enrolment knowing it would fail because based on my understanding it will try to look for these mdm url and compliance url before enrolling the machine and it will fail there. I was just trying to be hopeful with this move.

Answer 5

The user has an E3 license , which I believe includes Azure AD P1 license and the user has intune license.

Assuming you mean EMS E3 or M365 E3, then yes. If you mean O365 E3 then no. Make sure this is properly assigned in Azure. Also, when you run dsregcmd /status, if the user getting a PRT?