I have been doing quite a few projects involving Hybrid Azure AD Join lately and have learnt a lot about it and how you should begin your troubleshooting journey.

What is Hybrid Azure AD Join?

Hybrid Azure AD Join means that your computers are joined to your on-premises Active Directory, but is also “registered” to Azure Active Directory. This way you can also use your on-prem computers in Active Directory to leverage Conditional Access, enroll them into Intune, use Autopilot for provisioning and much more.

It is a very simple thing to do but opens you up to so many cool capabilities of Microsoft 365.

Implementing Hybrid Azure AD Join is pretty straight forward and can be configured using Azure AD Connect. The steps for a managed domain are different that those for a federated domain.

The AADC wizard creates a Service Connection Point in Active Directory in the Path ‘Configuration – Services – Device Registration’. The “keywords” attribute holds two values ‘AzureADid’ and ‘AzureADName. Here you will find your TenantID and TenantNam respectively.

During this post, I will focus on the managed domain scenario.

Controlled roll-out

Above instructions both tell you how to implement Hybrid Azure AD Join for all your devices at once. Preferably, we would like to test the roll-out on a subset of our devices.

It’s possible to configure this using two simple registry keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD] "TenantId"="TenantID" "TenantName"="TenantName.onmicrosoft.com"

These keys have the same effect as configuring it through Azure AD Connect. They have the same prequisites as the other implementation methods. Two of them are often forgotten:

The OU where the devices resides need to be sync’ed in Azure AD Connect

Firewall & Proxy should be configured to allow the discovery traffic.

Inside Hybrid Azure AD Join

What exactly happens when you configure a device to start his Hybrid Azure AD Join?

Windows actually activates the task ‘Automatic-Device-Join’ that is located in ‘Microsoft – Windows – Workplace Join’.

This task attempts to join to Azure Active Directory and tries to find out what the TenantID & TenantName is he needs to use. He will search in two places:

Registry with Path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]

SCP in Active Directory

If we look into the triggers of this task, there are two different triggers:

If a user logs into the device

Or if event ‘4096’ is logged. What is event 4096? If we go looking, we can find it in event viewer with as path ‘Microsoft – Windows – User Device Registration – Admin’.

This event is triggered (on what seems to me) like a random schedule. It’s triggered by the Network Service. But I haven’t found out how it’s trigged exactly. 1 day it is triggered 3 times, other times it’s only triggered once a month.



So if you want to troubleshoot an Hybrid Azure AD Join, you can manually trigger this task to speed up the process.

What does the scheduled task do? It executes the dsregcmd command!

dsregcmd

During Hybrid Azure AD Join projects, the dsregcmd command is your best friend. This commando can help you find out if a device is already registered, unjoin a device or manually start the join process.

/status

/status is the easiest to use parameter of the command and will show you if a device is already Hybrid Azure AD Joined.

The PC in the output below isn’t Hybrid Azure AD Joined yet, because you can see the ‘AzureADJoined’ status is ‘No’.

The output of an Hybrid Azure AD Joined looks like this. As you can see, here the value of ‘AzureADJoined’ is Yes. Further down you can also find information about the Azure Primary Refresh Token, which is used for Single Sign-on.

/leave

If you are experiencing unexpected issues with the Hybrid Join or you want roll back. You can execute the dsregcmd /leave commando. This will not unjoin the computer from the on-premises domain, it will only unjoin the computer from Azure AD.

/join

If you want to manually join the computer to Azure AD, you can execute the dsregcmd /join command. This command should be run in SYSTEM context (using psexec for example) and will force an attempt to Azure AD.

If you couple this parameter with the ‘/debug’ parameter. You are able to see error codes why this process is failing.

I don’t use this option very often . I tend to start the scheduled task to force an attempt and check the Event Viewer for errors.

Event viewer

When troubleshooting an Hybrid Azure AD Join, the Event Viewer provides you with loads of information. All Join information is stored in ‘Microsoft – Windows – User Device Registration – Admin’

What are some common Event ID and how can these help you troubleshoot your implementation?

306 – Automatic Registration succeeded Your device has been Joined :). You are all set! Validate using the dsregcmd /status command or in the Azure AD portal.

212 – Error happened while accessing registry This error will occur when you haven’t configured the registry values that I mentioned in Controlled roll-out. If you are using the SCP in Active Directory to publish your tenant info, you will also receive this error. But in that case, there is nothing to worry about.

100 – Discovery Request Sent In this step the computer sends a request to Azure AD. If you are seeing errors in the event viewer that happen seconds later this event, it means the computer is having trouble sending this discovery request. This points to network issues most of the times.

101 – Discovery Operation was Successful This means your computer has contacted Azure AD successfully. If you see this, your network engineer has done his job!

102 – Initialization of join request was successful In here you will find your DomainName. If this information isn’t correct or it is empty, there is something wrong with your SCP or registry keys.

105 – Complete Join Response was successful The join has been finalized

106 – Post Join Tasks for the AAD Authentication Package completed successfully Your device is being doing some more work after the join (sending device info etc).

111 – Registration status has been successfully flushed to disk Registration was successfully saved to your computer.



The following errors are all related to network issues. If you are having issues, verify that you have configured the proxy to allow these requests and that the firewall isn’t blocking the Microsoft URLs. All the URLS can be found here.

223 – WINHTTP_STATUS_CALLBACK_REQUEST_ERROR – Error Code 0x80072ee2

201 – Discovery Operation Failed with exit code 0x80072ee2

309 – Failed to discover Azure DRS Service. Exit code 0x801c0021

304 – Automatic registration failed at join phase. 0x801c0021

Then there is another error I have seen a lot ‘0x801c03f2’. This error can be seen in two different situations. The first one makes sense, the other one… not so much.

The device is excluded in the sync of Azure AD Connect due to filtering

The user hasn’t logged back in since the previous join step.

These two problems are fairly easy to fix.

For the first one: configure you Azure AD Connect correctly so the OU of the device is included and the object not filtered out because of a customer rule.

I have seen the same issue while the device was in the right OU and I was 100% sure it was being sync’ed. For this, I have found that starting the ‘Automatic-Device-Join’ task resolves this issue. In my understanding, this error is shown because the computer has done all the discovery steps and told AzureAD it’s ready to join, but AzureAD hasn’t sync’ed the device yet. So if you are seeing this issue on a subset of your devices. Just take a coffee, take a long sip, wait until the next day and follow-up once more!

The $ in the device name

If you are renaming your device on-prem, it’s possible the device shows up with a ‘$’ after it’s name. Check out this blog post for more information.

These are the most common errors I have seen. If I find some more, I will update this blog post to keep this article updated.

Having issues with your Join process? Feel free to reach out to me through Twitter or in the comments.