Partager via

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)

Comments

  • Anonymous
    November 22, 2018
    Hi Michael,As usual, your article is so precise and detailed that we could not ask more from you. To be honest, I've rushed to test Hybrid AD Join as soon it came up on my demo tenant and I'm struggling to make it work :-(I never get to the ODJ step though my connector is active in Intune, Hybrid AD Join configuration profile is defined using correct OUs... AAD "standard" join works great on my test devices but when assigning Hybrid AD Join Autopilot deployment, I get an error 0x80180005.I do not see any event raised in ODJ Connector event viewer logs stating ti has been contacted though...Any help or guidance would be appreciated.Regards
    • Anonymous
      November 22, 2018
      Houra, it now works. My issue was on the connector itself. I relocated onto another server (rather than the DC itself).I'm not 100% sure if it was related but i suddenly worked...
    • Anonymous
      November 27, 2018
      Hi David,Good to see you again! I encountered the same error as you, this one seems generic because if I look at the event logs more closely I have another error related to the version of the operating system MENROLL_E_DEVICENOTSUPPORTED 0x80180014.By changing the iso the problem seems solved (I took the 1809 version Enterprise version).See you next time ;-)
  • Anonymous
    November 22, 2018
    Hi Michael,If we hybrid azure ad join via Autopilot will both GPO and Intune Profiles be applied ?
    • Anonymous
      November 22, 2018
      Yes. The device is joined to Active Directory, so it gets GPOs. And it's enrolled in Intune, so it can also received policies and apps from Intune. (The "hybrid" part makes sure the device gets registered with Azure AD so the user gets a token that can be used for single sign-on to cloud-based services, including Intune.)
  • Anonymous
    November 22, 2018
    Hello Michael,Sadly my experience has been a little bumpy. The "Please wait while we setup your device" screen sits for a long time and many times will time out. If I'm lucky to get passed that I seem to get stuck at ESP step 3. At this point let's perform a CTRL-ALT-DEL and reboot it because why not. But it seems things were actually successful because I now see the familiar Windows log in screen and it's domain-joined! But why were we getting stuck at ESP? And why is the Autopilot enduser experience taking so long?Can't wait to iron this out because I really love the idea of Autopilot.Sincerely,The IT Dept
    • Anonymous
      November 22, 2018
      The comment has been removed
      • Anonymous
        November 26, 2018
        Apologies Michael. You actually said some words referring to my problem in the above article which I apparently glossed over. At any rate Hybrid Autopilot GOLD was achieved today on not one or two but THREE physical machines of varying age and situations. The future truly is here.Sincerely,The IT Dept
  • Anonymous
    November 22, 2018
    Hello Michael,works like a charm, keep up the good work.Best,Daniel
  • Anonymous
    November 22, 2018
    Hi Michael, we were waiting long for this feature to become available. Thanks for all your work getting this up and running in a public preview.We‘ve already identified yesterday the issue, the device get registered as Hybrid Azure AD Joined due to AAD Connect specifications after approx 30 minutes after the users signs in for the first time.We have a large deployment here and want to eliminate the need the IT prepares the computers. So this is currently a limitation for us as when users enroll the devices, they must wait 30 minutes before they can start use services like OneDrive for business because those are configured by conditional access policies to allow access from managed or compliant devices only. I hope you guys can find any kind of solution to streamline the process so the Hybrid Azure AD Join happens immediately after user sign in and the user can start all services without limitations.Thanks for your great explanations!
  • Anonymous
    November 22, 2018
    Thanks for a great article. Have the same issue as David. Takes long time preparing comupter and ends with error 0x80180005. No error in odj connector, shows success in eventid 30130 and 30140and the pc is created in the OU as specified. Any good advice?
    • Anonymous
      November 22, 2018
      Got this errormessage now, tranlated from norwegian: Confirm that you are using the correct login information and that your organization uses this feature. Please try again or contact the system administrator and enter the error code 80004005
      • Anonymous
        November 22, 2018
        The computer is shown as a device in intune, naming as set in device configuration profile. Installs applications deployed thru client apps. Why the inital error?
        • Anonymous
          November 26, 2018
          We have the same error. Hybrid Azure AD Join & AutoPilot. Get that error after about 15 minutes of the spinning icon. Microsoft support have been engaged but they had no answers initially and are investigating further.
  • Anonymous
    November 22, 2018
    Works well as documented, .... but what about devices not connected to the corporate network at the time of deployment, any solution in sight regarding that?
  • Anonymous
    November 22, 2018
    Thanks for the article mate. What's the best approach for allowing un-managed devices access to the internet (for autopilot) via the corporate network for this solution to work end to end?
    • Anonymous
      November 25, 2018
      The marketing behind Autopilot is for the user to receive the device directly from the OEM. The current hybrid domain join solution does not allow for this. The end user can only be assumed to have an Internet network connection.
      • Anonymous
        November 25, 2018
        Which is why this works great in a lab environment. Last time I checked, enterprises aren't super willing to allow un-enrolled/un-managed devices internet access on the corporate network.
  • Anonymous
    November 26, 2018
    Thank you Michael for explaining some details in this process.We have a few problems/issues today and I hope you can clearify some of them.1. When the ESP shows for the user, and the 30 minutes have passed, we get prompted to add a workaccount to Windows. This screen started to show last week. Did not see this the first week we tested.2. We puch the Company Portal App. Sometimes the Company Portal App says it is not configured with an account. When we select to add the current account the App says it is already added to Windows.3. This is a bad one. We see alot of machines getting the error 'The trust relationship between this workstation and the primary domain failed' and after this, we are not able to login with any account.Best RegardsOlof
    • Anonymous
      November 26, 2018
    1. I would expect to see that if you have targeted a Hello for Business policy.2. I haven't seen that issue. If (after the 30 minute process of waiting for the hybrid sync) you log out and back in again, do you see the same behavior?3. If you are seeing this routinely (and don't have any scripts running that remove computer accounts from AD, or any policies or scripts that are renaming the device), please contact support - that shouldn't be happening.
      • Anonymous
        November 28, 2018
        Thanks for your reply Michael.I am really struggling to understand the first issue. I have now removed all policies, application, scripts and hello for business. No luck, still get the screen to add a windows account and then if I want to let my Company manage my device.Any chance there is a log or event log to check? I have no more ideas what to test.RegardsOlof
        • Anonymous
          December 04, 2018
          Ok so I think I finally figured this one out. If I make sure that AD-connect has synced the new machine account before I do the first domain logon everthing seems to be working. If I logon before the ad connect sync is done, I do not have SSO to M365 and I guess that is why I see this logon screens.
  • Anonymous
    November 26, 2018
    What does ESP stand for? It is referenced multiple times but not able to see what it stands for anywhere. Also trying search engines didn't find any useful suggestions or mentions in other Microsoft documentation.Thanks!
    • Anonymous
      November 26, 2018
      ESP = Enrollment Status Page. (I'll edit the blog to make that more clear.)
      • Anonymous
        November 26, 2018
        Oh now it makes sense. Thanks Michael. Issue that maybe specific to us but we have done the demo autopilot with a Hyper-V VM with the Azure AD join steps and works as expected however we like to have the serial number in the computername for support reasons so I tried using https://www.petervanderwoude.nl/post/rename-a-device-via-windows-10-mdm/ to rename the computer.When checking This PC -> Properties it shows Computer name: (will change to after restarting this computer).After restarting the local computer name is changed however the computer object in Active Directory is not. Group Policy (1006 and 1129) and NETLOGON (5721) errors show in the System Event Log even though I can ping the DCs, it complains that the DC doesn't have an account for the new computer name. Can anyone reproduce this?
  • Anonymous
    November 27, 2018
    Hi MichaelThanks for this article it is really helpful. My question is to which group I can assign the Disable User ESP profile. Can it be assigned to the default dynamic group I have created for Autopilot devices or does it need to be assigned to a user group?regards, Jeroen Dijkman
  • Anonymous
    November 27, 2018
    Hi Michael,Thanks for the great info on this. We've been looking forward to hybrid join through Autopilot. Is it expected behavior for a device that is hybrid joined to be listed twice in the AAD device list? The device is only listed once for the Intune device list, but there are two entries (with different device ID's) in the AAD list. One is listed as AAD Joined while the second is listed as Hybrid Joined. Thanks again!
  • Anonymous
    November 28, 2018
    Hi Michael,Do you have a solution that allows you to remove misguided Intune connectors?Thank you in advance.
  • Anonymous
    December 05, 2018
    Anyone else experiencing problems since approx. Monday this week?We identified, when users open the Company Portal App on their Windows 10 devices, the device is not longer recognized as enrolled. It displays a message telling this device has not been registered for corporate usage yet. However, the device is still displayed in Intune and the management works fine.Looking further to Azure, we identified the devices are not longer linked to the user in Azure AD and that's the reason why the Company Portal app is telling the device is not registered. This happened for all devices we registered/enrolled in the last 1-2 weeks, but also occurs on newly enrolled devices as well. We didn't change anything, so I was wondering if somebody else experience the same.Thanks
  • Anonymous
    December 12, 2018
    Hi Michael,Thanks a lot for this great and super detailed article.Currently I am testing the Hybrid AD Join in my test lab. Everything is working fine, with the exception of some little strange "issues".1. Some of the installed machines (not all) are listed two times in Azure AD2. In the Company App an error like the following is shown "The device is not registered for corporate use."If I try to register the device manually I get the error, that the device is already registered.The software deployment of required apps is working without any problems. Security policies, Wi-Fi profiles and Always On VPN are also working.Maybe someone is having the same issues or knows something about it.Thanks and best regardsLukas