Troubleshooting Hybrid Azure AD Join issue

I've been working with a customer this week to configure Hybrid Azure AD Join and co-management. In the first phase (HAADJ), most of my test devices successfully registered in Azure AD. However there were some stragglers. These devices didn't even show up as "Pending" in Azure AD. They just didn't appear at all.

It was time for troubleshooting. What is the best way to find out what is wrong? There are many things you can check.

Service Connection Point

As some of the domain joined devices had successfully registered in Azure AD already, it seemed unlikely that there was a problem with the Service Connection Point. However I had a look at it.

Beginning with version 1.1.819.0, Azure AD Connect provides you with a wizard to configure hybrid Azure AD join. Azure AD Connect deploys a Service Connection Point (SCP) into your Active Directory environment. A service connection point in AD is essentially an object that points to a specific service. The Azure AD Service Connection Point includes information on the following items in its keywords attribute:

• azureADId; The Azure Active Directory tenant ID
• azureADName; The Azure Active Directory tenant’s verified custom DNS domain name, or the *.onmicrosoft.com DNS domain name if no verified custom DNS domain name exists for the Azure AD tenant

 The Service Connection Point format is as follows:

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration, CN=Services, CN=Configuration,DC=domain,DC=tld

 Follow this procedure to verify the Service Connection Point in Active Directory.

• Launch ADSI Edit as an Enterprise Administrator.
• Connect to the Configuration Naming Context of the domain.
• Browse to CN=Configuration,DC=contoso,DC=com > CN=Services > CN=Device Registration Configuration
• Verify that the leaf object CN=62a0ff2e-97b9-4513-943f-0d221bd30080 exists (this is the same CN value for every organization)
• Select Properties
• Select keywords from the Attribute Editor window and click Edit
• Verify the value of azureADId
• Verify the value of azureADName

This was all good for me.

OU Sync

The next step is to check that the device is in an OU which is synchronized to Azure AD. This is a configuration in Azure AD Connect. 

Navigate to the Domain and OU filtering screen and verify that the OU is selected for sync. I didn't find any problem here.

DSREGCMD

The next step was to have a look at one of the devices. You can get a lot of information using the DSREGCMD /STATUS cmdlet

In the Device State section I could see AzureADJoined = No. However the Diagnostics Data section gave me valuable information.

Failed to schedule Diagnostics Task. Error: 0x80041326

DSREGCMD /DEBUG /JOIN is also useful.

Cannot start Task: 0x80041326

Failed to schedule Join Task. Error: 0x80041326

This told me exactly where to find the problem. The issue was with the Workplace Join scheduled task.

Task Scheduler

Sure enough, I launched Task Scheduler and navigated to Microsoft > Windows > Workplace Join. I could see that all the tasks were disabled. In my experience some external configuration was preventing Azure AD registration on the device.

SCCM

ConfigMgr client settings was a good place to start. However automatic Azure AD registration was allowed (Cloud Services).

Group Policy

The next place to look was group policy, it's always a GPO, right?

A Resultant Set of Policy query showed me exactly where the problem was.

Computer Configuration > Administrative Templates > Windows Components > Device Registration > Register domain joined computers as devices was disabled.

What did this setting do? The description showed that this setting allowed devices to be silently registered in Azure AD. Disabling it obviously had the reverse effect and prevented the registration.

Solution

The solution was to remove this GPO setting from the affected devices.

I hope this helps. Until next time.....

Configuration Manager co-management considerations

Co-management allows you to cloud-attach your Configuration Manager infrastructure. Essentially it enables you to manage Windows 10 devices with the ConfigMgr agent and Intune MDM at the same time. Implementing co-management gives you instant access to invaluable features like conditional access.

I just want to share some information on co-management that I find useful.

Co-management scenarios

My previous understanding was that, without co-management, it was not possible to manage a Windows 10 device with ConfigMgr and Intune at the same time. However, as I recently discovered on a customer site, that is only partially true. It depends on the order.

On a recent customer engagement, I had configured co-management with a pilot collection.

I was very surprised to see co-managed devices in the Azure portal that were not members of the pilot collection. I now understand that it depends on the scenario.

If the ConfigMgr agent is running on a device and the device becomes Azure AD joined, no attempt is made to enrol in Intune, even if automatic Intune enrolment is configured. When co-management is configured, then automatic Intune enrolment kicks in and enrols the device in Intune.

However, what happens if the device is MDM enrolled first? In this case you can install the ConfigMgr agent. The device will be co-managed but will not receive any workloads if it hasn’t been added to a co-managed collection.

In this case you will see a co-management capability of 1, which is what I saw on my customer site. This means that the device is co-managed but hasn’t received any policy. The “real” co-managed devices had a capability of 45. 

Intune automatic enrolment

What happens if my devices are already Azure AD joined but I haven’t configured automatic Intune enrolment? 

I was concerned that automatic enrolment was a one-time thing i.e. when the device is joined to Azure AD it is automatically enrolled in Intune (if that is configured). I was concerned that if automatic enrolment is not configured first then the Intune enrolment doesn’t try again as the device will already be joined to Azure AD.

MDM URLs must be populated on the client before it can be successfully enrolled. These URLs are populated by the automatic Intune enrolment user scopes. When co-management is configured, the ConfigMgr agent periodically checks for these URLs and keeps retrying until they are populated. At that point, the device is enrolled in Intune. It is not a one-time thing.

ConfigMgr client settings

Hybrid Azure AD join, and automatic Intune enrolment are among the prerequisites for co-management. What happens if you configure hybrid AADJ using Azure AD Connect? Do you still need to configure this in ConfigMgr client settings (Automatically register new Windows 10 domain joined devices with Azure Active Directory to = Yes)?

The answer is no. You do not need it. This is a throwback to when you needed a GPO to tell devices to perform a hybrid AADJ. Current supported versions of Windows 10 will automatically join Azure AD if they find a Service Connection Point in Active Directory.

However, this is the default setting and you should leave it alone. If you turn it off, you may block devices from competing the AAD join.

GPO

As stated above you no longer need to configure a GPO to force a hybrid AAD join. For current supported Windows 10 devices, this should happen automatically.

Co-management display changes (April 2020)

There are some changes in the 2004 service release. On the All devices page, the entries for the Managed by column have changed:

• Intune is now displayed instead of MDM
• Co-managed is now displayed instead of MDM/ConfigMgr Agent

Learn more about co-management in the official Microsoft docs

I hope this helps you to understand and configure co-management. Until next time…..