I already talked about user-driven mode with Azure AD Join – that’s the easiest scenario.  Now let’s talk about user-driven mode with Hybrid Azure AD Join.  For those who have no idea what Hybrid Azure AD Join means, let’s start with a simple explanation:  Hybrid Azure AD Join devices are joined to Active Directory and then register themselves with Azure AD so that users who sign into the device using Active Directory accounts can get additional Azure AD benefits, such as single sign-on and conditional access.  Let’s go through a few misconceptions too while we’re at it:

• A Hybrid Azure AD Joined device is not joined to both Active Directory and Azure Active Directory, at least from the local computer’s perspective.  A Windows 10 device can only be joined to one or the other; they are mutually exclusive.
• You cannot sign into a Hybrid Azure AD Joined device using Azure AD.  You always sign in using an Active Directory account, and the password is always validated by an Active Directory domain controller (unless using cached credentials of course, but that just means an AD DC had previously validated the account).
• You cannot sign into a Hybrid Azure AD Joined device over the internet, at least not without establishing VPN connectivity.  (See the previous item, sign-ins are always validated by an AD DC, and you better not have one of those directly on the internet.)

Also carefully review the limitations in the table in the Hybrid Azure AD Join docs, primarily to make sure your environment is able to support Hybrid Azure AD Join.  A few key points:

• There are limitations with non-routable DNS domain names (e.g. contoso.local), unless you are using federation (e.g. ADFS).
• If you are using third-party federation providers, they need to do certain specific things to support Hybrid Azure AD Join (e.g. support for WS-Federation and WS-Trust).  Ask your vendor what it takes to make this work.
• Make sure your DNS domain has been added to Azure AD and verified (a process that requires adding a DNS TXT record to your DNS domain, proving to Azure AD that you own the domain in question).
• Make sure your devices/users can actually access the required Azure AD URLs.  (The Hybrid Azure AD Join process will not work otherwise.  Proxy servers can be OK if configured correctly.)

Nothing I’ve mentioned up until this point has anything to do with Windows Autopilot – but if this stuff isn’t set up correctly, there’s no chance Windows Autopilot will be able to successfully complete a Hybrid Azure AD Join deployment.

Now let’s review the Windows Autopilot requirements, from the official documentation for Windows and Intune:

• You need to install and configure the Intune Connector for Active Directory (which you’ll also see referenced as the “ODJ Connector”) on a Windows Server 2016 or later server in your environment.  This connector, which runs as a service, will listen for requests from Intune to create new computer objects in Active Directory.  All network activity is outbound using HTTPS.  If you have a proxy server in place, you may need to configure the service to use it.  The service will run as LocalSystem on the device, so make sure the computer account has the needed rights to create computer objects in any OU that you configure.
• You need to create a “Domain Join” device configuration profile and target it at the desired devices.  This profile is used by the Intune service (and never actually sent down to Intune devices, so don’t worry about targeting this to “All Devices” – it is only used during a Windows Autopilot user-driven Hybrid Azure AD Join deployment) to figure out the Active Directory domain and OU that the computer object should be created in.  This profile also specifies the naming prefix to use for created devices (and no, you can’t yet use variables in that name – it will append random letters and numbers to the prefix that you specify, no other options are available.)
• You need to create a Windows Autopilot user-driven Hybrid Azure AD Join profile and assign it to a group of devices.  (If using Windows Autopilot for existing devices, you would convert this profile to a JSON file.)
• You should enable the enrollment status page (ESP).

You can read more about this setup from the blog I posted when Windows 10 1809 originally shipped.  This time, I want to go even deeper…

I have created a new virtual machine and registered it with Windows Autopilot.  We can see the registration in Intune and the associated Azure AD device (on the right, toward the bottom), as well as the Windows Autopilot profile that has been assigned to the device (via the group membership of the Azure AD device – I waited until that assignment was complete, can take a few minutes):

The Azure AD device object (created automatically when the device was added to the Windows Autopilot deployment service, see this blog for details) is named with the serial number of the computer.  If I click on that Azure AD device name, it will take me to the object itself:

where I can see that the device is disabled.  Everything looks good, so it’s time to deploy.  Here’s what the process looks like:

• Just like user-driven AAD Join, the device will start off by asking for the user’s e-mail address (UPN) and password to authenticate to Azure AD. 
  

  

• If you have configured multi-factor authentication to join Azure AD, the user will be prompted to complete that process.
  

  

• If you have enabled terms of use, the user will need to accept those.
  

  

• The device will enroll in Intune.  It will then wait impatiently for an ODJ blob to be passed to it from Intune.  (It tries to find and ping an AD DC, even before it knows what AD domain it is going to join.  And it does this so frequently, several times a second, that a single-processor VM will be unresponsive – make sure you always add a second virtual processor.) 
  

  

• While the device is waiting for an ODJ blob, Intune is working on creating that ODJ blob:
  • Intune will notice that the device is performing a Hybrid Azure AD Join deployment (joining Active Directory).
  • Intune will locate a “Domain Join” device configuration profile targeted to the device being deployed.  It will get the AD domain, OU, and naming prefix from that profile and send that information to the Intune Connector for Active Directory.  (Note that if Intune can’t find a “Domain Join” device configuration profile for the device it will just never respond.  And because the client is constantly trying to contact a “null” domain, it will eventually time out with an 80070774, reporting that the domain controller could not be found.  Well, sure, because the device never received an ODJ blob with domain details.)
  • The Intune Connector for Active Directory will attempt to create a computer object in the specified OU, using the naming prefix specified and padding the rest of the name with random characters and numbers.  (If it fails to create that device object for any reason, the client will also time out with an 80070774 error, because it will again never get an ODJ blob response.)
• Once the device receives the ODJ blob from Intune, it gets applied.  The polling process should then be able to figure out the domain controller for the domain and ping it – as soon as it can do that successfully, the device will reboot.
  

  

• If you have enabled the Enrollment Status Page (ESP), it will appear to process the device preparation steps.  The most significant of these steps is the last one, “Preparing your device for mobile management.”  For this step, the client device is waiting for a response from the MDM service to tell it what needs to be done.
  
  

  

• Once the device preparation steps complete, the “Device setup” phase starts.  This will initially show “Identifying” until the MDM service (Intune) tells it what policies need to be applied and tracked.  These are then processed by the client device until all have been processed.  If any of them fail, the ESP will report the failure (with options to reset or continue anyway, if you’ve enabled those in the ESP settings).
  

  

• Assuming all device-targeted apps and policies were applied successfully, the device will once again make sure that it can identify and ping the DC for the AD domain.  As long as it can, the logon/lock screen will be displayed.  The user then needs to sign on with their AD credentials.  (If they have the same UPN in AD, e.g. their e-mail address, they could sign in using that too.)
  

  

  
  

  

• The first sign-in animation (FSIA) will be displayed.
• The user ESP will then be displayed.
  

  

  
  Two things could happen here:
  • If the device ESP ended up taking long enough, the Hybrid Azure AD Join process could have completed in the background.  (If you are using ADFS, this can be quick.  If using passthrough or password hash authentication, it could take up to 30 minutes to sync the device from AD to AAD using AAD Connect.) If the process has completed, the AD user will be able to get an AAD user token when they first sign into the device.  That will enable the user ESP to quickly sync with Intune.
  • If the device ESP didn’t take long enough, the user ESP will wait for the Hybrid Azure AD Join background process to complete.  The user ESP will then force an Azure AD sign-on prompt in order to get an Azure AD user token (since the user didn’t get one when they initially signed on).  Only after that can the device sync with Intune.
• Once the device has synced with Intune, the user ESP will track the user-targeted apps and policies.  Once those are done, the desktop will appear.

A few additional notes:

• Make sure you target the “Domain Join” device configuration profile properly.  For a “brand new” device (e.g. a newly-created VM or a device that’s never been synced into AAD), you can target the pre-created Azure AD device object.  But if you were to redeploy or reset the device, you would need to instead target the synced Hybrid Azure AD Join device.  That’s probably worthy of a blog of its own, but let me offer a few specific suggestions until then:
  • Target the “Domain Join” profile to “All devices.”  That way you can’t miss.  This has no impact on existing machines as this policy is never sent to the client – it’s only used by the Intune service to create the ODJ blob.
  • Understand that the “80070774” error can mean a few different things.  Be able to tell the difference between “Intune never found a domain join policy” and “Intune failed to create a device object.”  Check out the ODJ Connector event log to see if there was even a request received.
• The user presently needs to have rights to join a device to Azure AD, even though the intent is to join the device to Active Directory.  If they don’t have rights to join Azure AD, the process will fail early on.
• Yes, you will end up seeing two devices in Azure AD when this process completes:  The pre-created Azure AD Join device objects (which ends up getting enabled and renamed as part of this process) and the synced Hybrid Azure AD Join device object.  Keep both of these objects around – never delete the original pre-created Azure AD device object.

As with the user-driven Azure AD Join process, the flow is different when using Windows Autopilot white glove pre-provisioning.  I’ll cover that in a later post.