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.
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
- See this URL for more details: https://docs.microsoft.com/azure/active-directory/devices/hybrid-azuread-join-managed-domains
- 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 supported from Intune service release 2006 and onwards)
- 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.
Thanks a lot for this post, very helpful. There is one thing I do not quite understand though:
Why is “Hybrid Azure AD join configured in your environment” a requirement for this? My understanding is, that your device is joining Azure Active Directory first and is then registered for Intune MDM automatically, while at the same time, the Intune Connector makes sure, the object is also being created and joined to your on-premise infrastructure.
Why do I need to have Azure AD Connect running somewhere on-premise for that?
Thank you for elaborating, it is much appreciated.
Simply because you’re computer account needs to be synchronized to perform the last step’s of the process. You’re actually only joining the device to Active Directory, the AAD Connect in joint effort with the Workplace Join scheduled task takes care of the registration in Azure AD for you, and for that, the computer account needs to be synchronized.
I was able to resolve one of such issue.
The cx was using Windows 10 v 1803.
We upgraded to 1809 and the issue was resolved.
This all works great, but I’m now trying to get this working without having to import the HWIDs by using the injected profile JSON method. However it always skips the AD Domain join process even though I only have one profile and it’s a Hybrid Domain Join one. Has anyone had any luck with this? Thanks
Do you have a non-routable domain name domain? Such as .local. Please check https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-plan at the bottom to see if your environment is supported.
Hi Nickolaj, you say the requirement on the device must be 1809 but can 1803 be too? We are willing to move onto hybrid AD but not with Autopilot but wit co-management with SCCM on premise.
Nope, 1809 is currently the only version supported afaik.
Hi, awesome detailed post. We’ve setup everything, but it seems that the intune connector doesn’t show up afterward.
We’ve giving the account and EMS license and he’s intune Admin, but where I try to see the connector, nothing shows up.
Do you know where I could start looking to troubleshoot and/or I can start over?
I’ve never run into that issue, but I’d start in the normal places, log files/event logs. Also, ensure that you register a case with Microsoft, because they’ll be better at helper you with this issue.
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.
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
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
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.
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)?
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.
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 ?
Great blog entry as always. Hoping you might know where we are going wrong.
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?
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.
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.
Did you find a solution to this? got the same issue.
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.
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.
we have exactly the same error, did you get this resolved?
did you had a VPN connection to the on premise domain controllers in place as mentioned as a requirement in the official docs?
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.
I have the exact same issue without ADFS.
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)
We are using the very same setup and I’m also getting the very same error (80004005). Any update on your end by chance?
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?
Thanks for the post. This will be huge for AD on-prem env(s)
– 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?
#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.
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”
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.
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?
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.
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..
Hey Tony, did you end up fixing your problem? Currently experiencing the same issue, any update you can provide would be appreciated.
Tony. Did you ever figure out why this was happening. I am noting the exact same thing with my device set ups.
Hi Tony and Roy,
I am having the same issue currently. Were you guys able to find a solution?
Did you manage your behavior ? I have the same here, it’s stuck for a while, but after minutes I receive a prompt for an new authentication with the user/password, and it seems that the enrollment finish after this credential popup… No idea why, but afterwards everything goes fine…
Did you also try to wait for a long time ? Or everything works fine for you right now ? Thanks
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
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?
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..?
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!
Whoops, must have missed the “account” in “computer account”. Thanks!