Since the release in 2017 of Windows Autopilot we’ve been able to provision devices using cloud technologies and joining them to Azure Active Directory. Organizations have shown great interest in Autopilot but one of the deployment blockers have been that they can’t perform a traditional Active Directory join. This is now changing when Microsoft is introducing a new capability for Autopilot that was announced at Microsoft Ignite 2018, configuring devices to join Azure Active Directory as Hybrid Azure AD joined devices. This means that Microsoft Intune and Autopilot now supports joining devices to an on-premise Active Directory and also registering the devices in Azure Active Directory enabling the benefits of the cloud along with traditional management capabilities.

NOTE: This blog post contains features that are currently in public preview and may be subject to change in a future release of Microsoft Intune.

Requirements

In order to successfully perform an Hybrid Azure AD join for a Windows Autopilot device using Intune, the following infrastructure requirements have to be setup and configured:

  • Hybrid Azure AD join configured in your environment
  • Automatic enrollment for Microsoft Intune enabled in Azure AD
  • On-premise Active Directory and a Windows Server joined to the domain running the Intune Connector software
  • Windows Autopilot enabled devices with a deployment profile assigned
  • Domain Join device configuration profile configured in Microsoft Intune

In addition, these requirements must be met on the device:

  • Windows 10 version 1809 and above
  • Access to the internet
  • Access to Active Directory (access through a VPN connection is not supported)
  • Go through the Out-of-Box Experience (OOBE)

Prepare Active Directory

In order to deliver an offline domain join blob file from Microsoft Intune down to the devices after they’ve been enrolled, there needs to be a way for that traffic to go through. The Intune Connector for Active Directory enables this functionality and is required to be installed locally in your on-premise infrastructure on a Windows Server.

Permissions for the computer account where the connector is installed needs to be delegated to a specific organizational unit in Active Directory to allow it to create computer accounts for the enrolling Windows Autopilot devices that’s configured for Hybrid Azure AD join. In this scenario I’ve created a specific Autopilot organizational unit to make it easier to differentiate where the computers are coming from. However, depending on your current design and structure, this might not be the ideal configuration.

  • Open the Active Directory Users and Computer management console.
  • Right-click a desired organizational unit in your directory where you want the Autopilot devices to be placed when they join the domain and select Delegate permissions.

  • Click Next in the wizard that appears.
  • Select Create a custom task to delegate and click Next.

  • Choose Only the following objects in the folder and select Computer object from the list. Check both the Create and Delete selected objects in the folder and click Next.

  • Select the Full control permissions to ensure the computer account gets all the access it requires and click Next.

  • Click Finish in the wizard to complete the delegation of permissions.

Active Directory has now been prepared for joining Windows Autopilot devices to the chosen organizational unit.

Azure AD Dynamic Group for all Autopilot devices

There are various dynamic query rules that can be used to create groups containing the Autopilot enabled devices. In order to assign an deployment profile for Autopilot, you’ll need at least one group that for instance collects all devices enabled for Autopilot. This can be accomplished by creating a simple dynamic group in Azure AD using the following query:

(device.devicePhysicalIDs -any _ -contains "[ZTDId]")

Below is a screenshot of the query is used:

There’s additional ways that you can narrow down more specific devices, for instance a group containing all of your Autopilot devices with a specific order ID:

(device.devicePhysicalIds -any _ -eq "[OrderID]:179887111881")

Another group could contain all of your Autopilot devices with a specific Purchase Order ID:

(device.devicePhysicalIds -any _ -eq "[PurchaseOrderId]:76222342342")

However you choose to create a dynamic group, it’s important to highlight that there needs to be at least one group containing the Autopilot devices for assignment of the deployment profile.

Configure the Intune Connector for Active Directory

With Active Directory prepared and a dynamic group created for Autopilot enabled devices, we can go ahead and install the Intune Connector for Active Directory.

  • Log in to the Azure portal using a Global Admin or Intune Service Administrator account.
  • Go to the Device Enrollment blade and select Windows Enrollment.
  • Click on Intune Connector for Active Directory.

  • Click Add.

  • Click on the link to download the on-premise Intune Connector for Active Directory.

  • On the Windows Server that has been delegated permissions to create computer accounts in Active Directory in accordance to the preparation steps mentioned above in this post, install the connector.

  • When the installation has completed, click Configure Now.

  • In the Enrollment tab that appears in the new application that opens up, click Sign In. Global Administrator or Intune Administrator roles are required for the user signing in for the connector enrollment to successfully complete.

  • Once the enrollment of the connector has successfully completed, click OK in the prompt that appears.

  • The Intune Connector for Active Directory has now successfully been installed.
  • Back in the Azure portal, we can now see the connector showing up. The connector name shows the name of the Windows Server where it was installed. In the image below the name has been redacted.

With the connect setup successfully what’s left to configure is a Windows Autopilot deployment profile.

Create Windows Autopilot deployment profile

A Windows Autopilot deployment profile is used to configure the devices enabled for Autopilot. In this profile the option to select how the devices will be joined, either to Azure Active Directory or through a Hybrid Azure AD join among other configuration settings. This part of the post will not go through all the different configuration options for a Windows Autopilot deployment profile, only the required configuration for successfully configuring devices for a Hybrid Azure AD join.

  • In the Azure portal, go to Device Enrollment – Windows Enrollment. Select Deployment Profiles and click Create profile.

  • Name the profile accordingly and ensure that you select Hybrid Azure AD join under the Join Azure AD as.

  • Configure the remaining settings for the deployment profile and finally click Create.
  • Finally, assign the deployment profile to the group created earlier to assign it to devices.

Create a Domain Join profile

The last piece of the puzzle is to create a Domain Join profile. In this profile we specify the device naming prefix, the domain the devices will be joined to and optionally the desired organizational unit where the devices will be placed into inside Active Directory.

  • In the Azure portal, go to Device Configuration – Profiles and click Create profile.
  • Name the profile accordingly and select Windows 10 and later under Platform. As for the Profile type select Domain Join. Under the Settings blade, configure the required settings. In this example I’ve configured the computer name prefix to be CL and also specified the fully qualified domain name of the domain that the devices will be joined to. Optionally, the distinguished name of the organizational unit has been specified as well. Click Create.

  • Assign the profile the same way you have assigned the Windows Autopilot deployment profile, to the dynamic group created earlier.

  • Before you continue to attempt to provision a device using Autopilot, ensure that the device has been assigned the desired deployment profile in Device Enrollment – Windows Enrollment – Devices, like shown in the picture below.

Results and summary

With all of the configuration pieces in place, an organization can now provision devices with Windows Autopilot that’s not joined to the on-premise Active Directory and registered in Azure Active Directory. For the testing purposes of this new capability, I’ve been using a Windows 10 Insider Preview build 10.0.18272 since the Windows 10 version 1809 release was postponed.

The first difference that you’ll notice during OOBE is that the device is taking a while longer spinning at the step where it used to perform an Azure Active Directory join. At this point the offline domain join blob is sent down to the device and it’s being joined to the on-premise Active Directory. We can see that because during this step the device appears in the desired organization unit configured in the domain join profile:

After the successful domain join, the device needs to be restarted, which is shown by the following screen during OOBE:

Once rebooted, the Enrollment Status page appears and the remaining device specific configuration is performed. At the end, when everything has completed successfully, we are presented with the login screen where it’s quite obvious that we’re now domain joined:

When a user signs in at this point, user specific configuration is performed on the device which is shown again through the Enrollment Status page:

That’s all, I hope you’re as excited about this new capability with Windows Autopilot and Intune as I am.

(7629)

comments
  • Goat Shadow
    Posted at 18:00 November 7, 2018
    Goat Shadow
    Reply
    Author

    In the Delegation of Control Wizard at the beginning, it asks to select users and groups to whom we want to delegate control. Should this be a service account for Intune or..?

    • Nickolaj Andersen
      Posted at 18:14 November 7, 2018
      Nickolaj Andersen
      Reply
      Author

      Hi, like it states in the text for that section it should be the computer account of the server where the connector is installed. Hope this helps!

      Regards,
      Nickolaj

      • Goat Shadow
        Posted at 19:03 November 7, 2018
        Goat Shadow
        Reply
        Author

        Whoops, must have missed the “account” in “computer account”. Thanks!

  • Edward Haynes
    Posted at 18:50 November 7, 2018
    Edward Haynes
    Reply
    Author

    Apologies if I missed this in the article, but can you explain how this relate to co-management? I thought that didn’t work with hybrid join?

  • Lionel
    Posted at 10:27 November 8, 2018
    Lionel
    Reply
    Author

    Thanks for the article. Then I have 2 questions.
    Once join how the configuration settings are applied? I mean if there is a conflict between GPO and intune profiles, who wins? What is the device / user behavior?
    Secondly, the user need to login with the on-prem username or AAD user? If it’s on-prem AD the apps deployment per user in intune works?
    Thanks for clarification

  • Roy
    Posted at 13:54 November 8, 2018
    Roy
    Reply
    Author

    We did an test with this new functionality and are stuck on the last step in the Autopilot enrollment (Account setup in Setting up your device for work). The laptop is already created in local ad and logging in with local domain account succeeded. After the login, the process is stuck in the step “Joining your organization’s network”.

    Any ideas why and what it is doing?

    • Nickolaj Andersen
      Posted at 00:19 December 8, 2018
      Nickolaj Andersen
      Reply
      Author

      Hi Roy,

      Since this is a preview functionality, I’d advice that you contact Microsoft if you’re running into issues. It’s hard for me to know what could possibly be wrong with your setup.

      Regards,
      Nickolaj

      • Tony
        Posted at 09:02 December 10, 2018
        Tony
        Reply
        Author

        Hi Roy
        I’m having the exact same issue with the connecting to your organisation bit. Will try raise it with the intune guys today. I’ve found you can force a shutdown and log back in to continue the setup but it’s not right and doesn’t feel like to in a finished state. Driving me nuts..
        Tony

  • Ian Wright
    Posted at 18:07 November 8, 2018
    Ian Wright
    Reply
    Author

    Nikolaj,

    Did you have any installation issues? When I try to install I get

    “0x80070658 – Error applying transforms. Verify that the specified transform paths are valid”

    Thank you

    • Nickolaj Andersen
      Posted at 02:38 December 5, 2018
      Nickolaj Andersen
      Reply
      Author

      Hi Ian,

      There’s been reports where the connector can not be installed when the server system locale is set to English UK, it needs to be English US for now. Hopefully this will change when it goes out of preview.

      Regards,
      Nickolaj

  • Scott
    Posted at 17:12 November 9, 2018
    Scott
    Reply
    Author

    Thanks for the post. This will be huge for AD on-prem env(s)

    Questions

    – Is there a path for machines already deployed in the domain to get enrolled here so policies can be pushed (like bitlocker…) or is this still only for new machines?
    – since the new machines need to be put in a autopilot designated OU – once they are deployed can they be moved to a normal machine OU where your traditional computer based GPOs are deployed and enforced?
    – any clue if/when this will go from preview to production? Any list I can get on to monitor the developement of it?

    Thanks,

    • Nickolaj Andersen
      Posted at 02:36 December 5, 2018
      Nickolaj Andersen
      Reply
      Author

      Hi Scott,

      #1 You can either gather all the hardware-hash values using ConfigMgr or manually (yuk) running the PowerShell script provided by Microsoft and upload that using Intune to the Autopilot service. There’s a report in ConfigMgr that I can’t remember the name of right now though. That’d be my recommendations where you get that data and manually import it for existing devices. Another approach would be to either setup Co-management and have ConfigMgr automatically enrolling the existing devices into Intune and that way deploy an Autopilot deployment profile to the devices that have been enrolled and enable the new feature to automatically have Intune grab the hardware-hash putting it into Autopilot. These existing machines would now be Autopilot ready whenever they’re reset.

      #2 Yes, of course. It doesn’t need to be a specific Autopilot OU, you can specify any OU you want where you’ve delegated the proper permissions.

      #3 I can’t say unfortunately. And there’s unfortunately no list. The best you get is to have a look out on the weekly updated “What’s new” section in the docs for Intune.

      Regards,
      Nickolaj

  • Victor Karlsson
    Posted at 00:14 November 10, 2018
    Victor Karlsson
    Reply
    Author

    Hey! I’ve set this up with AD FS with several federated domains. During the update of Azure AD Connect the AD FS Claim rule: “Issue issuerid when it is not a computer account” got changed, and I had to change it back to get the federation and sso working again.

    Computers are synced up (windows 10) automatically to Azure AD. But when I try to Auto-Pilot roll computers i get error message:

    “Confirm you are using the correct sign-in information and that your organization uses this feature. You can try to do this again or contact your system administrator with he error code 80004005”

    If i use Auto Pilot without the preview, it works fine. Maybe its the AD FS Claim rules?
    Do you guys have any idea, there is no error in AD FS log.

    • Martin
      Posted at 13:18 November 13, 2018
      Martin
      Reply
      Author

      I have the exact same issue without ADFS.

    • Wesley
      Posted at 12:35 November 15, 2018
      Wesley
      Reply
      Author

      Hi Victor,

      Same issue here with an environment with a federated setup (ADFS). I haven’t been able to troubleshoot the issue yet. Hybrid Azure AD join with AutoPilot works fine when connected through our corporate network. Outside the corporate network (with guest wifi for example) I get the very same error (80004005)

    • Wesley
      Posted at 08:35 November 23, 2018
      Wesley
      Reply
      Author

      Hi Victor,

      We are using the very same setup and I’m also getting the very same error (80004005). Any update on your end by chance?

      • Nickolaj Andersen
        Posted at 22:10 November 26, 2018
        Nickolaj Andersen
        Reply
        Author

        Have you made sure that you’ve clear line of sight to the domain controller, meaning being on a network where it can reach it?

        Regards,
        Nickolaj

  • Christian Küver
    Posted at 09:42 November 15, 2018
    Christian Küver
    Reply
    Author

    did you had a VPN connection to the on premise domain controllers in place as mentioned as a requirement in the official docs?

  • ckuever
    Posted at 11:03 November 15, 2018
    ckuever
    Reply
    Author

    @Victor Karlsson:

    we have exactly the same error, did you get this resolved?

  • Wesley Hader
    Posted at 22:56 November 15, 2018
    Wesley Hader
    Reply
    Author

    Thanks for the write up! I’ve been testing this lately and I have one comment and one (or more) question(s).

    First the comment: When setting up the Intune Connector, the Global/Intune Admin account you use must have an Intune license assigned. Knowing this would have saved us several hours yesterday:).

    As for the question(s): What is best practice for initial OOBE sign-in in user-driven mode? This is the account that kicks off the Autopilot deployment but may not be the intended user account for the PC? Should we use an account with Azure AD Admin Role, Intune Enrollment Manager, or the end user account? This is still confusing to me.

    Thanks!

    • Nickolaj Andersen
      Posted at 02:30 December 5, 2018
      Nickolaj Andersen
      Reply
      Author

      Hi Wesley,

      The account that are signing in during OOBE in a user-driven scenario is the user that’ll be the primary user of that device. You as an administrator is not really supposed to login at that point, the point is that the device is given to the end user and when he or she signs in, the device is being provisioned where device specifics configurations are applied including user specific assignments of applications and other.

      Regards,
      Nickolaj

  • Donny van Huizen
    Posted at 22:45 November 20, 2018
    Donny van Huizen
    Reply
    Author

    Hi Nikolaj,

    I have setup everything. But When the User login te proces get stuck on the enrollment status page on the step “joining your organization network” under the account setup.

    So i hope you can help me with that.

    • Nickolaj Andersen
      Posted at 02:26 December 5, 2018
      Nickolaj Andersen
      Reply
      Author

      Hi Donny,

      I’ve not seen that issue myself in my lab testing for this new functionality, unfortunately. It’d contact Microsoft support to get their assistance with this issue.

      Regards,
      Nickolaj

  • TechDog
    Posted at 18:39 November 21, 2018
    TechDog
    Reply
    Author

    Hi,
    Great blog entry as always. Hoping you might know where we are going wrong.

    Booted device
    ran the powershell Get-Autopilot info script
    Imported CSV to AutoPilot devices in Intune
    Assigned Device Enrolment profile to a Dynamic Security group based on the search rule:
    (device.devicePhysicalIDs -any _ -contains “[ZTDId]”)

    However, when looking in the AutoPilot devices page, the Profile Status does not show Assigned.
    It only changed to Assigned if I booted the device, signed in with a work account and then reset the device so that it is back to OOBE ready for shipping.

    After that when I boot to OOBE (to simulate the end user) it runs the AutoPilot.

    So the question is, what am I missing about AutoPilot profile assignment that would negate me having to sign in to the device with a work account before the device is shipped to an end user for them to run OOBE?

  • Bilal Baydoun
    Posted at 05:23 November 22, 2018
    Bilal Baydoun
    Reply
    Author

    I’m having the same error as Victor : error 80004005. I’m using password hash sync and not adfs.
    Did you manage to correct this issue ?

  • tony
    Posted at 14:37 November 22, 2018
    tony
    Reply
    Author

    hi victor / nickolaj

    im getting the same error code 80004005 during the auto pliot setup process – did you manage to figure this out or resolve ? i can see my device in my on-prem OU no issue there

    for info – im trying from home (not on the corp lan) just over wifi
    thanks tony

    • Nickolaj Andersen
      Posted at 02:22 December 5, 2018
      Nickolaj Andersen
      Reply
      Author

      Hi Tony,

      That’s why you’re getting this error, cause you need to have an established VPN connection when you’re doing this outside of your corporate network. The current implementation for this scenario requires free line of sight to your domain controllers in your corporate network.

      Regards,
      Nickolaj

      • turbomcp
        Posted at 17:49 December 6, 2018
        turbomcp
        Reply
        Author

        when are you supposed to establish this vpn connection(i notice they said its unsupported)
        you can only establish it at the login screen right?(after it already did offline join)?

        • Nickolaj Andersen
          Posted at 00:11 December 8, 2018
          Nickolaj Andersen
          Reply
          Author

          Hi,

          I wouldn’t know at this point to be honest. Documentation says that the device needs to be on the corporate network to complete the on-premise domain join. Perhaps this will change in the future.

          Regards,
          Nickolaj

  • tony
    Posted at 14:51 November 22, 2018
    tony
    Reply
    Author

    hi victor

    did you manage to fix the issue / error code 80004005 – ive just tried to setup a device and get the same error message
    i can see the device in my on-prem OU just fine

    thanks tony

  • Ishwariya
    Posted at 07:05 November 29, 2018
    Ishwariya
    Reply
    Author

    Hi,
    While setting up intune connector getting the message as successfully enrolled. But I am not able to view it in Azure portal and also I can view the following error in event viewer:

    Failed to get a value for Key: OdjServiceBaseUrl.The given key was not present in the dictionary.

  • Leave a Reply to Goat Shadow
    Cancel Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.