That’s the short title. The long title should really be something like this:
The first day in the life of a Hybrid Azure AD Joined device has lasting implications on the rest of the device’s life, at least from an Intune management perspective.
And with that, we have both a blog topic and the most common challenge that customers have with Windows Autopilot and user-driven Hybrid Azure AD Join deployments. You might get it to work once, but then for some reason you can’t get it to work again, you get frustrated and curse at Microsoft, and give up – for a while. Eventually, maybe you figure out that it works for new devices, so great, lets treat all devices like new devices: remove then from Azure AD, Intune, Autopilot, maybe even AD, and then re-add them to Windows Autopilot. And presto, it works again. Once. Before you have to repeat the whole process again.
I’ve talked about this basic problem in past blogs, but given that this is still the #1 question with Windows Autopilot, it’s worth digging in a little deeper. Let’s start from the beginning, with a brand new device being added to Windows Autopilot. After you do that, you’ll see that there’s a Windows Autopilot device, and an associated Azure AD device object. Because the device has not yet enrolled in Intune, there is no Intune object. Because the device has never joined Azure AD, the Azure AD device object is disabled and named using the serial number of the device.
I put the device into a group that has a Hybrid Azure AD Join profile associated with it, and that same group is used to assign the Domain Join device configuration profile that specifies what AD domain and OU the device should use when joining AD. Once the Windows Autopilot profile assignment is complete (that takes a few minutes after adding the device to the group), the device is ready to deploy.
The device will boot up and ask for Azure AD credentials. These will be used to to enroll the device into Intune. Now you’ll see the Windows Autopilot device links to an Intune object:
Notice that the device name is still the Windows default random name. If you checked the Azure AD device, you would see that it is still disabled. The name will change a little later in the process:
Intune will then generate an offline domain join blob (using the Intune Connector for Active Directory) and send that to the client PC. It will install that blob and reboot. At that point, the device will pick up the new name. Eventually Intune will see that new name.
After a period of time (up to 30 minutes), the newly-created Active Directory device will sync from AD into Azure AD. At that point you can see two devices in Azure AD for the machine, one that is Azure AD Joined and the other Hybrid Azure AD Joined.
This is the point where things get interesting: As soon as Intune sees the Hybrid Azure AD Join device object, it will start using that one for device-targeted policies. And more importantly, it will stop using the Azure AD device object for policy targeting at the same time. So remember the group that you placed that Azure AD device into, and the policies that are targeted to that device? Now they are no longer applicable. So if you were to reset, reimage, or otherwise redeploy the device from scratch, you’ll find that it will only use the policies targeted to the Hybrid Azure AD Join device object.
Want some proof? Follow the link from the Windows Autopilot device to the Intune device and see what policies are targeted to the device. Also, notice that the Windows Autopilot device still points to the Azure AD device object, not the Hybrid Azure AD device.
The most important device configuration profile for the Hybrid Azure AD Join process is the Domain Join profile. If the device being deployed does not have a Domain Join profile assigned to it, it will fail – the device will time out and eventually display an 80070774 error, indicating that it can’t contact a domain controller. That’s kind of deceptive, because it doesn’t even know what domain controller it needs to contact, because it never joined Active Directory in the first place. So how do you work around that? If you have a simple environment (like me) you can just target the Domain Join device configuration profile to “All devices” – then which device Intune uses doesn’t matter, all are in scope. If you have a more complex environment, you might have a dynamic group that you are using, maybe “All Autopilot devices.” You can modify that query to select both objects by looking for any devices with ZTDID set, as well as any devices whose name starts with your AD device naming prefix. In my case, my devices are all named starting with “AD-” so I can use a query like this:
Note that the simple editor at the top isn’t always good at editing a query that has “-any _” in it, so you might need to edit the text manually by clicking the Edit link toward the bottom right.
Either way, we need to make sure that the Domain Join profile, as well as any other device-targeted profiles, is targeted to both the original Azure AD device (for the initial deployment scenario) as well as the new Hybrid Azure AD Join device (for subsequent deployments – with a new object created each time).
Longer term, our goal is to have Azure AD merge the two device objects together – that avoids all sorts of confusion, and ensures that group-based targeting isn’t affected by the flip from the Azure AD device object to the Hybrid Azure AD device object.
Categories: Windows Autopilot