Trying out Windows Autopilot User-Driven Hybrid Azure AD Join

  • Article

With Windows 10 1809 now available, we’ve added new scenarios to Windows Autopilot.  You can read about them in the announcement blogs:

I wanted to dive a little deeper into the user-driven scenario for Hybrid Azure AD Join, the last link above.  To summarize that blog:

  • You need to set up/install the Offline Domain Join connector on a server on your internal network.  (It makes an outbound connection to the Intune service, waiting for the service to send it requests to create device objects in Active Directory.)
  • The device must be on the corporate network (no support for VPNs).  We need line of sight to a domain controller for the user to sign in to Active Directory, to apply GPOs, etc.
  • You need to create and assign a new user-driven Hybrid Azure AD Join Autopilot profile.
  • You need to create and assign a new Domain Join (Preview) device configuration profile that specifies the domain name, OU, and computer name prefix to use.  (These settings are not part of the Autopilot profile, so you could have different device configuration profiles, e.g. for different OUs, targeting different device groups, with one overall Autopilot profile.
  • You need to enable the enrollment status page (ESP for short, more on that later).

Let’s take a look at what the end-to-end process ends up looking like with this time-compressed video:

Let’s review the steps that this goes through:

  • The device boots up and connects to the network.  (This is a VM with an Ethernet connection, so it connects right away.)
  • It downloads the Autopilot profile.
  • It asks for Azure AD credentials (0:00:54), which are used to enroll the device in Intune.  (The device does not join Azure AD.)
  • The device enrolls in Intune.  Using the “Domain Join” device configuration profile settings, the device will request an Offline Domain Join blob from Intune.  Intune passes this request to the Offline Domain Join connector service (running on a device on your internal network) and gets back the ODJ blob.  That blob is passed back to the client PC.
  • The client PC applies the ODJ blob and then reboots to complete the Active Directory join process (0:01:45).  (The computer won’t reboot if it can’t find a domain controller.  Instead, you would see a “Something went wrong” screen with error 0x80070774.)
  • After the reboot, the enrollment status page (ESP) will be shown to process the device configuration (apps, settings, etc.).  (You don’t see this in my video because I didn’t have anything to wait on.)
  • Now, the user will be asked to sign in again (0:02:00), but this time using their Active Directory credentials.  Notice that I type in the same account (anna@contosocm.com) and password that I did for the initial AAD sign-in, which makes sense:  Both accounts have the same UPN and are synchronized using AAD Connect.  (In my case, I am using passthrough authentication.)  You could specify DOMAIN\USER instead (e.g. CONTOSO\Anna) in this case (but not for AAD).
  • The AD account signs on, goes through the first sign-on experience (pulsing blue screens), and then sees the desktop (0:02:19).  Notice that the enrollment status page (ESP) isn’t displayed for the user (again, more on that later).

The whole process would have taken 20-25 minutes without editing the video (longer if you had more configuration to apply and apps to install).

The Offline Domain Join process

Now, let’s talk a little about the offline domain join process.  For those that aren’t familiar with that, it was introduced years ago (with Windows Server 2008 R2 I believe) to join devices to Active Directory without the device needing to talk to an Active Directory domain controller.  You could create these offline domain join blobs using DJOIN.EXE, then tell Windows to use them via an unattend.xml or other methods.  Not surprisingly, there are also APIs available to do the same thing, which is what Intune is using to request the ODJ blob from AD, and what the Windows 10 client is using to apply that blob to the computer.

The Offline Domain Join Connector, provided by Intune, runs on a server on the internal network, where it can talk to the domain controller using the same APIs previously mentioned.  Those APIs actually create an account in Active Directory, either in the OU you specified or in the default OU for the domain (or the Computers container if you haven’t configured a default).  In order for that to work, you have to grant the computer account rights to create objects in the OU or container that you specified.  The service, named “Intune ODJConnector Service," runs as SYSTEM, hence the need to grant the computer account (e.g. SERVERNAME$) access to create objects.

To see what the ODJ Connector service is up to you can check the event log at “Application and Services Logs –> ODJ Connector Service”.  You’ll see two events created every minute with event IDs 30121 and 30150; ignore those because they aren’t useful.  (You might want to make that event log bigger, maybe by a factor of 100, so those not-useful events don’t push out the useful ones.)  Look for event ID 30130 or 30140 to see each request that it processes, including the name that was assigned to each computer that was added to AD:

ODJ event viewer

To filter out those every-minute events, you can also specify an event filter that specifies “-30121,-30150” and you’ll be left with only the more interesting events.

If by chance you don’t target the device with a Domain Join device configuration profile, the offline domain join will fail because the device won’t know what domain to join, obviously.  But the error that you will see is a little less obvious, as it will try for about 25 minutes before failing with a “Something went wrong” error screen with an error 0x80070774, which translates to network error 1908, “Could not find the domain controller for this domain.”  (Technically, the offline domain join doesn’t require connectivity to the corporate network, but since after the reboot the user will need to sign in with Active Directory credentials, it won’t let the machine reboot if it can’t talk to a DC.  So you could see that same 0x80070774 error when a proper Domain Join profile is received but a DC can’t be located.)

The Device ESP process

As I mentioned previously, the computer will reboot to complete the offline domain join process.  After the reboot, it should display the enrollment status page (if enabled – highly recommended) to complete the device configuration.  Once that is complete, the user should be asked to sign on.

The user sign-on

After the device enrollment status page (ESP) completes, you’ll see the lock screen.  The process isn’t really complete yet because no user policies from Intune have been applied yet.  Ideally, these would be applied immediately after the user signs in with their Active Directory credentials.  (Remember, this is an AD-joined device, so the user is putting in AD credentials to be verified by a domain controller, hence the “on the corporate network” requirement.)

But I hinted before that there was more to know about the ESP.  More specifically, the user ESP won’t work – it will typically time out waiting for policies to be received.  But why does that happen?  Well, this goes back to the Hybrid Azure AD Join process.  The device is initially joined to Active Directory, but not yet registered with Azure AD.  That registration process (tied to AAD Connect) could take some time, maybe 30 minutes.  Until that happens, the user can’t get an Azure AD token, and without that Azure AD token it can’t authenticate to Intune so it can’t get any user-targeted policies.  So the ESP could time out, or just sit there for a very long time waiting for that stuff to happen in the background.

Since most users would rather get to the desktop to at least be somewhat productive with the device, it is possible to disable the user ESP, while leaving the device ESP enabled.  To do this via Intune, you do need to use a custom OMA-URI policy, as that setting isn’t exposed otherwise.  To do that, create a device configuration profile in Intune, specifying Windows 10 and above and a type of “Custom.”  You can give the profile a name (e.g. “Disable user ESP”), and then add one custom OMA-URI setting:

  • Name:  SkipUserStatusPage (or whatever you want)
  • Description:  (whatever you want)
  • OMA-URI:  ./Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage
  • Data type:  Boolean
  • Value:  True

That ends up looking like this:

image

And that’s it.  Let us know if you have any burning questions, have suggestions for improvements, or are running into any issues.  Also be sure to check out the documentation links:

Windows Autopilot user-driven mode for hybrid Azure Active Directory join Deploy hybrid Azure AD joined devices using Intune and Windows Autopilot (Preview)