Troubleshooting weird Azure AD Join issues

June 30, 2020

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.

Technical Azure AD, Azure AD Join, hybrid, Hybrid Azure AD Join, troubleshooting 27 Comments

Troubleshooting weird Azure AD Join issues