Intune GPO Enrolment not populating details in Hybrid Azure AD joined record

Question

Hi everyone,

We have slowly started to perform GPO enrollment to users in our organization. My understanding with GPO enrolment was the machine needs to be an Azure AD joined before we perform the silent /GPO enrolment. All this time we never synced on prem devices to our Azure AD. As part of the pre-requisite for GPO enrollment we started to sync devices to Azure AD in order to make sure that these machines complete Azure AD join. So once the sync happens in Azure AD connect we see two entries for every machine one is Azure AD registered (which was already present which I believe is due O365 logins) and other is Hybrid Azure AD Joined ( in pending registration state).

Now once the machine completes the Azure AD join, the Hybrid Azure AD joined record on Azure gets updated. After we confirm this we push the GPO to the machine and let it perform the silent enrollment to Intune MDM. Once this is complete on the Hybrid Azure AD joined record we see that owner and MDM field is populated and Intune is referencing to this record. Even the Azure AD registered record also gets updated. I believe so far this has been the normal scenario in our testing cases.

As we go to production we saw a different behavior, where Intune is populating only Azure AD registered device and left Hybrid Azure AD registered unpopulated. Even though when we perform the dsregcmd /status on the client the result show up with device id referencing the Hybrid Azure Ad joined record. Though everything is working fine, I want to understand if this is common behavior? This so far has only happened to one machine out of 3 machines which we performed.

Answer 1

@Rookie{} , Based on my research, I find if the Windows 10 or newer domain joined devices are Azure AD registered to your tenant, it could lead to a dual state of hybrid Azure AD joined and Azure AD registered device. We recommend upgrading to Windows 10 1803 (with KB4489894 applied) or newer to automatically address this scenario
https://learn.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state

For our situation, i would like to confirm which version our windows client is with? Is it above Windows 10 1803 (with KB4489894 applied) or newer?

In general, the Azure AD registered record needs to be removed before we plan to do Hybrid Azure AD join. And the GPO enrollment needs to be done after that. For our situation, to avoid any issue in the future, we suggest to unenroll the affected device, remove the records in Azure AD. Then do Hybrid Azure AD join again. After these are completed, apply GPO to enroll them into Intune.

Hope it can help.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Hi @Crystal-MSFT , thank you for the response. So right now we have synced about another 5 set of on prem AD computer objects to Azure. Right now they are in dual state as you mentioned but their respective Hybrid Azure AD Joined records has been in pending state for registration, so what you are suggesting is that we first remove their Azure AD registered record and then push the GPO for auto enrolment to these users right.

Also another thing is how long would it take for a device to join Azure AD, we have a different UPN on Azure compared to our on prem, but the Azure UPN is an alternate UPN on our on prem AD and we have on the backed AD switched to their UPN's to match the Azure AD UPN's. This has worked in terms of having the machine Azure AD joined, but the production machines have not yet become Azure AD joined though we have left the machine more than a day connected to internet. Should we manually join them to Azure AD using the dsregcmd /join command ?

Answer 3

Sorry I missed to answer the Windows 10 version of the affected client, it is 10.0.19044.1645