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 [email protected] to [email protected]. 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 (27)

  • 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 :D

    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


    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
      • Andrea Mero Reply

        Hi all,
        I am just encountering an issue whereby an AAD machine with autopilot is coming up with unable to login upon restarting. I can then punch in the password and I can login. My environment is fully hybrid and I have started testing a new autopilot aad only. I can join the domain, everything seems to be working fine but upon every restart I get this annoying problem. Is it possible that the issue here is to do with the fact that the account I am using to login was created on prem?

        February 14, 2024 at 4:01 pm
  • 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.


    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:

      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.


    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 - Reply

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

    April 9, 2022 at 5:41 am
  • Ahmet Reply


    I have a problem. I think i finished all steps but there is a error on cmd.

    | SSO State |

    AzureAdPrt : ERROR
    AzureAdPrtAuthority : ERROR
    EnterprisePrt : ERROR
    EnterprisePrtAuthority : ERROR


    DeviceAuthStatus : FAILED. Error:90090311

    I do not find any fix for this.

    June 9, 2022 at 1:38 am
    • Iain Stephen Reply

      Did you find a solution Ahmet? We have the same error 90090311…

      November 30, 2022 at 3:07 pm
  • LuKe Reply

    Hi guys, that was a nice read.
    I’m currently fighting what was a “Zombie” case for an Azure AD Joined PC. I probably made a mistake because I tried dsregcmd /leave and now it seems I cannot login anymore whith my Global Admin AD User via RDP. It used to work, now it somehow succeeds the NLA but then the RDP session asks for another Azure AD User profile’s password and always says it’s incorrect, even if I select “other user” and I fill in Global Admin creds again. I guess the problem is that it’s not trusting anymore the NLA tokens from the Azure AD controller. As far as I can understand I should now sign on with a local admin to trigger the re-registration but there is no local admin account on that machine which was Autopilot’ed to have no local admin rights to assigned user.

    Do you think the Global Admin Azure AD User would still be able to login from the local console?
    Cheers, LuKe

    June 16, 2022 at 4:59 am
    • Alex Fields Reply

      No, you must always have a local account if you are going to use dsregcmd /leave — once it is disjoined from the directory you cannot sign back in using Azure AD accounts. Probably best to factory reset that sucker back to OOBE and start again.

      June 16, 2022 at 10:54 am
  • Aaron Hall Reply

    The scenario that annoys me the most is the Azure AD Registered stuff. At my company, we have a lot of computers that managed to do this during OneNote for Windows 10 or Teams signins, and they chose the default “Manage my device” options not knowing better. I implemented a GPO to prevent this going forward, however, that doesn’t undo the damage already done.

    Is there truly no other way than manually going into settings and removing the account? Shame on Microsoft for not having a scriptable solution for this. At least I can catch this scenario in dsregcmd /status by using this in a script:

    $ENTCHECK = dsregcmd /status | Where-Object { $_ -match ‘WorkplaceJoined : ‘ } | ForEach-Object { $_.Trim() } | ConvertFrom-String -PropertyNames ‘Name’,’Value’ -Delimiter ‘ : ‘
    If ($ENTJOINVALUE -eq “YES”) {
    Write-Host “WARNING: User account is AAD registered. Please correct this before continuing.” -ForegroundColor Yellow

    This way the techs working our migrations can be warned and have the script halt progress. I’m sure there’s more elegant ways to do this, but this is what I’m going with for now unless I find another option.

    July 5, 2022 at 8:33 am
    • Alex Fields Reply

      I know, right? Your solution looks decent. I instruct techs to check for it, but agree a script to check *and remove* would be even better. Not aware of a way to do that from the command line yet. If someone out there reading these comments knows better though, let us know!!

      July 5, 2022 at 10:05 am
  • Chris R Reply

    Hi Alex – great article. Have you ever come across the scenario where you have an AutoPilot deployed device (Windows 10 version 10.0.19043.1503) that shows up in Azure AD as ‘Azure AD Registered’ and you see the user of the device listed as the owner and the registered & activity dates are correct, however, there is a second occurrence of the device that doesn’t show as AutoPilot deployed (it has the normal device icon), a join type of ‘Hybrid Azure AD joined’, N/A for the owner, the Registered column is ‘Pending’ and the activity is N/A? Both devices have two different object & device IDs. It’s almost like AutoPilot missed the step to domain join the device (we have the Intune connector deployed) and then at a later time it synced the device to Azure AD a second time and this time set it as Hybrid AAD joined. Very confusing, and we aren’t sure what to do because we have a couple of cases of this. We did try to delete the non-AutoPilot version of the device that is Hybrid AD Joined and a short while later is appeared back in AAD Devices again as Hybrid AAD joined and registered = pending.

    July 20, 2022 at 11:55 pm
    • Alex Fields Reply

      I was told by a msft engineer that you should not do Hybrid AAD Join with autopilot. Yes, it is supported but they strongly discourage it. In his words, “For the love of all that you call holy, do not use autopilot for hybrid join: prove to me that regular aad join does not work for you first.” I believe there are something like 30+ steps to HAADJ vs only like 4-5 with normal AAD. Much easier to troubleshoot. Anyway, you do not need to deploy an Intune connector and set up GPO’s etc. in order to do autopilot without hybrid join. I would pick either hybrid join (without autopilot) or autopilot (aadj without hybrid). Does that make sense?

      August 5, 2022 at 12:23 pm
  • Charlotte Reply

    We are getting the 8018000a when we try to Azure AD join machines, because of previously registered workplace joins. In the enrollments section of the registry, are there any downsides to deleting all the GUIDs? Might that cause other problems?

    September 12, 2022 at 7:08 pm

Leave a Reply

Back to Blog

Helping IT Consultants Succeed in the Microsoft Cloud

Have a Question? Contact me today.