10 Things You Need to Know about Hybrid Azure AD Join and Intune

I recently embarked on a large Hybrid Azure AD and Intune project with over 40k devices. I spent a lot of time pouring through Microsoft documentation, chatting with folks on Twitter and Reddit, and working with our Microsoft reps.

Here are 10 things I learned while going through it.

Understand the SCP

In order for a client to “Hybrid Domain Join” it needs the Service Connection Point (SCP) configured.

This tells the client about which Azure tenant is needs to communicate with. It contains your Azure AD Tenant ID and Name. It can get this information in two ways:

Targeted Deployment

This method allows you to roll out hybrid join at your own pace. You first need to clear the SCP from Active Directory otherwise ALL clients will be able to see this info and attempt to hybrid join. Then apply these two registry keys to your clients:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]
"TenantID"="11111111-d3b4-4a69-a0ae-bd3e3884f7fa"
"TenantName"="mycompany.com"

You can also do it with PowerShell

$path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD"
New-Item $path -ErrorAction SilentlyContinue
New-ItemProperty -Path $path -Name TenantID -Value "11111111-d3b4-4a69-a0ae-bd3e3884f7fa" -PropertyType string -Force
New-ItemProperty -Path $path -Name TenantName -Value "mycompany.com" -PropertyType string -Force

Note: Your “TenantName” should be the domain name after your email address like “user1@company.onmicrosoft.com“. It isn’t the “TenantName” listed in Azure AD properties as that is the friendly name and may contain a space. The “TenantName” in the SCP configuration should NOT have a space.

After they have these keys installed, the client will attempt to hybrid domain join on the next cycle. The default triggers for this are on user logon and event ID “4096” in the Microsoft-Windows-User Device Registration/Admin log. You can also initiate this process yourself.

SCP in Active Directory

This is the easiest method but gives you the least amount of control. You can enable this by going through the Azure AD Connect wizard or by manually inputting it into ADSI Edit on your domain. You can basically reverse the steps to clear it outlined here.

Keep in mind that devices will automatically attempt to hybrid join if you have this in your environment and AAD Connect is enabled to synchronize devices. In my case, we will just enable this toward the end after we have rolled out the majority of the devices.

“userCertificate” on the Computer Object

Once the device has the SCP and the “Automatic-Device-Join” scheduled task runs (more on that later), it will talk with Azure AD and get a certificate. Then it will save the public key of this certificate to its own computer object under the “userCertificate” attribute. After this happens, the device is now eligible for syncing to Azure via Azure AD connect.

Without this cert, the devices will not sync even if you have syncing turned on at that particular OU.

You can also get this via running a PowerShell command (with ADUC tools installed):

get-adcomputer -Identity "desktop-12345" -properties UserCertificate

Filtering objects with AAD Connect

If you want more filtering, you can enable additional filtering rules. You can filter by “OU” or other “Attributes”. This is useful for testing so that you can control which devices are allowed to sync. You can read more about AAD Connect filtering options here.

As we were playing around with these filtering rules we came across one important realization:

Enabling an entire OU to sync with AAD Connect does NOT automatically sync all objects!

We were told incorrectly by our Microsoft reps that once we enabled device synchronization on our main production OU with over 40k devices that ALL devices would start syncing immediately. I was very concerned about the performance impact of this and we went back and forth a lot trying to understand the impact.

The best MS could say was “If you do this after hours, AAD Connect should have plenty of time to complete the full synchronization before the next morning”. So that’s what we did.

We planned for the change after hours and went to sleep assuming we would see all of our devices synced into Azure the next morning. The next morning arrives and I looked in Azure and couldn’t find any devices synced. Huh. Did we do something wrong? My colleague then noticed that the “userCertificate” attribute was also enabled as part of the filtering rules (this is by default). How does a device get this we wondered?

By enabling the SCP on the client.

Wow. So even with synchronization enabled on the OU, it will only sync objects that have the SCP installed and attempt the device registration process. Since we were doing the targeted deployment we had full control over this. Only as we deployed the SCP to waves of devices would they then synchronize in.

Have SCCM(MEMCM)? Setup Cloud Attach and Co-Management

If you have SCCM in your environment, you are going to want to set up “Cloud Attach” beforehand. This is for a few reasons:

1. It will facilitate Intune enrollment automatically
2. It will enable workloads to come down via Intune

You will need to have someone with Azure AD Global Admin do the sign-in-to-Azure part as it will actually create an Azure App that allows SCCM and your Azure tenant to talk to one another.

You can control both the Intune Enrollment and the various workloads via collection.

One thing to note though: SCCM is not very fast at enabling automatic Intune enrollment. Once SCCM detects the system is in the collection for Intune enrollment and the device is Azure AD joined, then it will create a scheduled task to try the MDM enrollment. This can happen over several days though.

You can speed it up on a system by running the machine policy cycle and these configuration baselines:

Azure AD “Mobility (MDM and MAM)” groups are not required (if using SCCM)

Azure Active Directory has a section called “Mobility (MDM and MAM)” and this is where you can control which groups are allowed for Intune MDM or MAM enrollment.

When you are using SCCM co-management and enabling automatic Intune enrollment, these can both be set to “None”. SCCM will still get the MDM URLs from this section (via the cloud attach configuration), so make sure they are populated. You can click “Restore default MDM URLs” if they are not there.

The nice thing is that you don’t have to create and manage AD/AAD groups to enable MDM enrollment. You can control it all from the SCCM side.

You will still need these enabled though when doing Autopilot and/or BYOD since the device will talk directly to Azure in order to enroll and not go through SCCM. Additionally, you will also need to set these groups up if you don’t have SCCM and plan on using the GPO to enroll into Intune.

Monitor Co-Management

SCCM has a dashboard under Monitoring > Co-management where you can track the progress of rolling out co-management and Intune. It also gives a rollup of any errors as well.

PRTs and WS-Trust ?

A PRT, or Primary Refresh Token, is a special type of web token that is generated when Azure joining or registering. It’s an important piece of doing single sign-on (SSO) to various cloud resources (like O365). This is the final “piece” to complete the Hybrid Azure AD Join process.

It’s not technically “required” as I have been able to complete HAADJ and Intune enrollment without it. But is important for single-sign-on so it’s best to ensure you have this working.

This particular piece requires the “WS-Trust” protocol. If your Azure environment is federated with a third-party IDP such as Ping or Okta, you will need to ensure that this protocol is allowed in the authentication rules. It should be noted that this protocol should not be exposed on the internet and should be internal-only.

Once that is opened up, you should be able to see it when running the dsregcmd /status command:

Task Scheduler and Event Viewer

Hybrid Join

The main scheduled task for initiating and completing the Hybrid Join process is “Automatic-Device-Join” under \Microsoft\Windows\Workplace Join.

You can run this task manually (right click > run), via the command “dsregcmd /join”, or via this PowerShell command:

Start-ScheduledTask -TaskName Automatic-Device-Join -TaskPath "\Microsoft\Windows\Workplace Join"

The corresponding log for this task is under Event Viewer > Application and Services Logs\Microsoft\User Device Registration\Admin.

Intune Enrollment

If you are using SCCM and enrolling into Intune via co-management there isn’t a scheduled task in Task Scheduler that you can trigger. SCCM handles this on its own. There are a few ways to speed things up and attempt to manually trigger it.

Run (click “Evalutate”) the “CoMgmtSettingsPilotAutoEnroll” or “CoMgmtSettingsProd” baseline.

The log to track this is in the “CoManagementHandler.log” under C:\Windows\CCM\logs.

If you are using the GPO to enroll into Intune, a new scheduled task will appear under \Microsoft\Windows\EnterpriseMgmt called “MDMMaintenenceTask”. You can run this one manually as well.

The logs for Intune enrollment and its connectivity to the server is under Event Viewer > Application and Services Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Admin.

Troubleshooting

Here are a few troubleshooting articles that I found to be very helpful:

Hybrid Join

Co-management

Intune Enrollment

Conclusion

Let’s summarize the items here:

1. Clients need the SCP in order to Hybrid Join. They can get this via registry or from Active Directory
2. AAD connect will only synchronize devices that have a userCertificate
3. AAD connect can also have additional filtering rules such as by OU or by other attributes.
4. Since AAD connect will only sync devices with a userCertificate, enabling syncing on an OU with a large amount of device won’t immediately sync all devices nor will it put a straight on AAD connect itself.
5. If you have SCCM, don’t forget to setup Cloud Attach.
6. Additionally, if you use SCCM to enable Intune enrollment, you don’t need to configure groups under the Mobility (MDM and MAM) section of Azure.
7. SCCM has a dashboard to monitor co-management progress.
8. If you have a third party IDP, you’ll need to allow the WS-Trust protocol in order to get PRTs to come down.
9. Task scheduler and event viewer are where the majority of activities are run and logged.
10. There are a number of helpful troubleshooting articles available.

My hope is that this helps you on your journey to Hybrid Azure AD join and Intune enrollment. Good Luck!