Troubleshooting weird Azure AD Join issues

Back to Blog

Troubleshooting weird Azure AD Join issues

If you are starting to do more Azure AD Join (or disjoin/rejoin) operations, you may run into some issues at times where the computer reports an error. These can take several forms, but generally the message is, “Sorry dude, but you can’t join/register this device.”

Here are a few scenarios that I have run into, and what I found the most effective fix was. (Spoiler alert: basically, a lot of this boils down to: if the cloud disagrees about the device state compared to the local computer, you will have issues.)

The Zombie

If someone deletes the computer object in the cloud, but the device still thinks it is Azure AD joined, then you will end up with a “Zombie-Joined” device presenting with inexplicable issues including authentication and SSO issues.

Further, let’s say you that go to disconnect the account from Azure AD under Settings > Accounts > Work and school. You might get an error that basically says you can’t do that. If I recall this correctly, it will ask for a local admin credential, and even if you know you typed in the credential correctly, it will tell you that your info is incorrect.

To see this issue another way, when you run dsregcmd /status, it will say AzureAdJoined: YES under Device State, and yet, under Device Details just below that, you will see this message:

DeviceAuthStatus : FAILED. Device is either disabled or deleted

As well, you will not find the object in the Azure AD devices list, or if you do find an object representing this device, it will most likely be a stale record (just remove it). The fix for this is simple: dsregcmd /debug /leave. Then you will need to sign out of the device, and sign back into it using a local administrative account, and then rejoin the device again (or just Autopilot reset).

One other possibility that I have seen is that the device object does not exist in the cloud, and as well, the device appears to agree that it is not joined to an Azure AD domain (or even registered for that matter). Nevertheless, the client computer is still holding on to “something” that says otherwise. In that case you can get an error similar to:

This device is already enrolled. You can contact your system administrator with the error code 8018000a.

One way you can try flushing out the device, assuming the /debug /leave switches aren’t working for you, is to navigate to this area in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments

Delete everything that looks like a GUID and keep everything else: Context, Ownership, Status, and ValidNodePaths.

Didn’t you know I was already Joined? (Or Registered?)

This is extremely common–being unable to join Azure AD when you are disjoining legacy AD domains and re-joining–especially if you are not using Autopilot reset or otherwise starting from scratch on the device.

When you attempt to Join Azure AD you might get a message saying that the device is already joined or already registered. Even if the computer was formerly joined to a traditional AD domain, the user may have registered their computer against Azure AD at some point. This happens per user profile, and so the only way to undo the tangle is to re-join the old domain, go back into the user’s profile, and then disconnect the account from Settings > Accounts > Work or school.

If there is nothing important about the device and no profile data worth saving, you can also factory reset the whole thing, clear the old objects from Azure AD and/or Intune, and then perform the join from the OOBE simply by identifying the device as work or school. Or, you can pre-populate devices by registering them with Autopilot and subsequently perform Autopilot reset, which is even better (and if you have done a really good job with Intune then all your software will come to your device, and you won’t have to do anything else).

The case of the modified user name

Let’s say you have a user whose name is Sally Maidenfair. Sally gets married, now she’s Sally Bobslastname. Her Azure AD identity changed from SallyM@companyname.com to SallyB@companyname.com. Or, this can also happen when a person moves from one primary domain suffix to another (switching companies or business units under a larger umbrella corp/tenant).

What happens to the Azure AD joined computer? Well, interestingly it seems you can continue logging into the desktop machine just fine with the old name (at least for the present time). Why? I dunno, but I don’t trust it–and so I suggest that the user should sign in using their new name just to make sure everything is square. This should be all that is required… but guess what?

I have reports that there can be lingering issues–and I am not sure if this is due to a user profile thing or what (I have only had this reported to me, and did not troubleshoot it myself). I suspect it comes down to the local device not agreeing about the UPN vs. the cloud…. maybe? Regretfully, I do not have the output of dsregcmd /status in this case (I’ll watch for it in the future), but the fix appears to be fairly straightforward: disconnect from Azure AD and then rejoin again using the new name. Dumb.

Computer changes hands

This has just recently changed, and thank goodness. In the not too distant past, when a person leaves an organization, and someone takes over their old device, guess what? The “primary user” is still going to show up as the departed employee. And the only fix (until recently) was to disjoin and rejoin the device using the new UPN.

But thankfully, we now have the ability to Change primary user from the cloud portal, so this ridiculous process should not be necessary anymore (however, I have not tested this function out myself since it landed a couple months ago–I just trust that they got this right since it was a hugely popular request on uservoice).

Unable to Hybrid Azure AD Join

This problem presents itself in a couple of different ways.

In the first instance, you may see that computers keep showing up in the Azure AD portal as Azure AD Registered, instead of Hybrid Azure AD Joined, even though you know you completed the process correctly.

In the second instance, you may see the status update to Hybrid Azure AD Joined, however it is stuck in a Pending state, which shows up under the Registered column.

There is not just one fix for either of these issues. But here are some things you should check.

Won’t move from Registered to Hybrid Join:

After you ran the wizard in Azure AD Connect, did you also deploy the GPO? Is the GPO applied to the endpoints (they must have line of sight to DC’s)? Make sure the new policy has applied properly.

As well, check to ensure that you have the computer objects in the scope of your sync–if your computers OU is not syncing to Azure AD, then fix that–even if you completed the wizard to created the SCP, AND you have your GPO in place (and confirmed it successfully applied), you also need to have this part done, or it won’t work.

Won’t move from Pending state

First, I would check to ensure that your domain controllers’ time is not far off from NTP time–and if you need to fix NTP issues on your domain, see this article. If it is off by more than a couple of minutes you will have this issue completing the Hybrid Join process.

However, another common fix for this issue is like before–and it has to do with previous registrations going stale (I believe) and the local device and Azure AD not agreeing on the state of the registration. So, you guessed it: dsregcmd /debug /leave to the rescue! Reboot and confirm status updates. Remember you don’t have to manually perform a join afterward if you have a GPO telling the computer to do this for you.

There are a bunch of other possible causes and solutions for Hybrid Join issues, some of which are documented in this article. But I have personally run into everything I mentioned above.

Comments (17)

  • Richard Swart Reply

    Hi Alex, thanks for another interesting read. Another issue we seem to face is when a user has signed in or is syncing a personal Microsoft account that uses their work email for their personal account. You have to disconnect these accounts first and go back to a local account and then join AzureAD, otherwise you also get a bunch of random joining issues.

    June 30, 2020 at 1:41 pm
    • Alex Reply

      Ah this is good to know, and one we don’t often see, since my baseline security policy will block the use of personal Microsoft accounts on corporate joined workstations. But that is not always a requirement for businesses, so very good to know that!

      June 30, 2020 at 6:11 pm
  • Ru Campbell Reply

    Hey Alex, good writeup! My understanding is that the GPO ‘Register domain-joined computers as devices’ is only required if the Windows 10 version is <1607. I've tested this in my lab and was able to HAADJ a 1909 VM without it. Any thoughts on this? Finding the documentation on this specific GPO a bit lacking. Thanks!

    July 2, 2020 at 7:01 am
    • Alex Reply

      That could be right–I’ve been doing it for so long it’s just part of my process. In that case it also doesn’t seem to hurt anything to leave it in there, but good to know that it works without.

      July 2, 2020 at 1:02 pm
  • 345P Reply

    You’re a goddamn life saver! Never would have thought the machine would just ‘fake leave’! Thanks a million 😀

    June 1, 2021 at 3:39 pm
  • RT Reply

    Seriously thank you so much for this. This really helped me, and I appreciate you doing this for people.

    Will look to support this site how i can.

    June 4, 2021 at 4:37 pm
  • Troy Hedgepeth Reply

    I have been beating my head against the wall with the 8018000a error (device already enrolled).
    I did the registry key deletion mentioned above and rebooted. IT WORKED!
    Thank you so much!

    June 17, 2021 at 9:36 am
  • Nam Reply

    Hi,

    I have aa user who is joined in MDM Intune but device registration still shows pending. dsregcmd /debug /leave this command will help? Will it affect the user functioning?

    July 14, 2021 at 2:07 pm
    • Alex Reply

      I think you could still do the leave command; you should be able to re-register afterwards.

      July 16, 2021 at 11:58 am
  • James Pepper Reply

    Hi Alex,

    Quick question have you ever seen an issue where azure ad joined windows 10 devices show the same duplicate accounts when looking at Settings > Accounts > Access work and school

    A few devices I have connected will then have issues licensing office 365 because of this duplicate Azure AD join. Pulling the device off azure ad onto a workgroup and then re-joining the device to Azure AD doesn’t seem to fix it.

    Thanks

    July 15, 2021 at 6:54 am
    • Alex Reply

      I am not sure I follow; each device should only be able to make a single Azure AD Join (you cannot join twice). However you can be registered against multiple accounts, but only one join. Then there may be a separate limit: total number of devices allowed per user license (e.g. 5 devices), and you could be running into that if the cloud still sees devices that are no longer present. You could clean up stale devices in the portal this way: https://docs.microsoft.com/en-us/azure/active-directory/devices/manage-stale-devices

      On the device, unregister/disconnect/disjoin and then rejoin the device again, after the portal clean-up is done.

      July 16, 2021 at 12:03 pm
    • Curtis Stuart Reply

      We are having the same issue with duplicate work accounts showing up in Windows 10 causing headaches with Office 365. Ever find a solution to this ?

      October 6, 2021 at 3:04 pm
  • fox23 Reply

    Hi, I have an issue after Joining the two devices on Azure it won’t get connect to the recent Server we need to Map the drive and connect to the installed printer? Appreciate your feedback.

    Thanks

    September 3, 2021 at 1:54 pm
    • Alex Reply

      If you want to use a traditional server then you should use hybrid join not Azure AD join, that is simplest way.

      September 4, 2021 at 11:25 am
  • Mark W Reply

    Is it normal behavior for Hybrid Azure AD Joined Windows laptops to not check in with Azure AD and show a recent timestamp under the Activity column in Azure AD>Devices unless they are connected via VPN? I know there is an SCP that was created during the process that directs the computer to the proper Azure AD tenant. Considering that info is stored in ADSI I would imagine each laptop must have line of sight to the DC for that reason specifically, is that correct? Would an alternative measure be to push out the registry objects/manual workaround for the Azure AD values so the laptops do not need to see an AD domain controller to reach Azure AD?

    October 14, 2021 at 2:03 pm
    • Alex Reply

      They need to see the DC only the first time they register, after that the benefit of hybrid is that you do not have to be on-prem (including no need for VPN) to get SSO to cloud resources and be recognized as a corporates device.

      October 15, 2021 at 3:25 pm
  • this device is already registered az - howbr.com Reply

    […] Troubleshooting weird Azure AD Join issues – ITProMentor […]

    April 9, 2022 at 5:41 am

Leave a Reply

Back to Blog

Helping IT Consultants Succeed in the Microsoft Cloud

Have a Question? Contact me today.