In this post, you shall learn more about a support tip- “Understanding the architectural flow behind Hybrid Azure AD Join AutoPilot deployment from Intune.”
My name Saurabh Sarkar and I am an Intune engineer in Microsoft. I have a YouTube channel and you can subscribe to the same to learn more about Microsoft Intune.
Introduction – Hybrid Azure AD Join AutoPilot
The entire flow has been explained in my below YouTube post-
- There is always something magical about getting a new box, unwrapping it, powering it ON and the laptop knowing who we are, and the laptop getting into the business ready state.
- That is what Windows AutoPilot does.! The Autopilot solution helps the Admin deploy and provision devices without any admin intervention and helps us get the devices into a business ready state.
- It in a way truly embodies the essence of M365, by combining Windows 10, Azure, Intune and MS Office into a single cohesive experience and makes the device a “smart device”
NOTE! – For more details on AutoPilot and how to configure the same from Intune, please refer to – https://docs.microsoft.com/en-us/intune/enrollment-autopilot
Now, with Windows 10 1809+, Microsoft has taken the Autopilot deployment from Intune to the next level by introducing Hybrid Azure AD-joined Autopilot functionality.
For background details on the same, please refer to- https://docs.microsoft.com/en-us/intune/windows-autopilot-hybrid
In this article I would like to explain the background flow that happens during the entire Hybrid Azure AD-joined Autopilot deployment via Intune. Once we understand the flow, this article should help us understand the use of the various components involved and the troubleshooting approach we may follow in case we run into issues with Hybrid Azure AD Join AutoPilot deployment.
- Windows 10 1809 end devices having access to both intranet and internet.
- Server 2016 joined to local domain to install the Intune ODJ connector with access to internet.
- Hybrid Azure AD join configured via Azure AD Connect tool.
- If behind a firewall, the device must meet the Windows Auto Pilot network requirements as under- https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/windows-autopilot-requirements#networking-requirements
- Device has to be in the direct line of sight with the DC. This solution does not work over a VPN, however the same would be possible soon(in July 2020 release of Intune service) and there would be a different blog on the same once it is supported.
- Not a mandate- the recommendation is to have a DHCP running in on-prem infra as well.
The above can be implemented on a virtual machine in our lab environment as well! We would have to create 2 virtual switches (Internal and external).
- The Windows 10 device would have an adapter from both the switch, once used for connection with the Intune service while the other would be used for contacting the on-prem DC.
- The 2k16 server hosting the connector would also have 2 NICs (once from each switch defined above)
- If we wish to implement the same using a single NIC in our lab environment, the same can be achieved by installing/configuring the NAC role in the on-prem server.
- If we don’t have DHCP configured in our environment, we can still achieve this deployment. We would have to press SHIFT + F10 during the first oobe screen in the device. This would open the command prompt. From cmd we can open the NIC adapters and configure the internal NIC with appropriate IP address/default gateway/subnet mask and ensure that it is able to communicate with the DC.
(The entire flow explanation is present in- https://www.youtube.com/watch?v=M9rCbtO4aFQ&t=5763s )
Once the Hardware Hash are uploaded, it talks with the Device Discovery Service (DDS) and a unique Zero Touch Deployment Id (ZTDId) is created for each hardware hash entry.
Flow Explained in Steps:(Refer to the step number in the diagram)
- The Intune admin does the below-
- Extracts the Hardware Hash from the device and uploads it to the Intune portal.
- (Microsoft Intune>Device Enrollment-Windows Enrollment>Windows AutoPilot Devices>Import)
- Creates/deploys an AutoPilot Hybrid Azure AD Join profile.
- Creates/deploys a device configuration profile (ODJ)
- In an on-prem 2k16 server installs the ODJ connector
- The DDS calls the Device registration Service (DRS) of Azure AD and pre-creates a Device Object in Azure AD (AAD). This entry is made with the device serial no.
- => An AADJ entry for the device is now created Azure AD Devices even though the device is offline and has never been powered on yet.
- The end user Powers On The device for the very first time> The Autopilot.dll contacts the DDS Service>Realizes that this is not a normal device but autopilot device>Autopilot profile with customized oobe is deployed to the device. The device should have an internet connectivity at this point and the firewall should not block anything)
- The customized company branding is displayed>User is provided with the username/password field.(User name is pre-filled if the admin has assigned a user beforehand to the device from the portal)
- The user enters the creds>Request is sent to Azure for auth>The device is azure ad joined and enrolled to Intune. (The device should be able to reach out to the Intune service and the MDM scope should be set correctly for the user)
- As the device is now enrolled, Intune would start push profiles/policies to the device. Offline Domain Join is one of the profiles which is targeted to the device and the same is deployed.
- The device receives the ODJ config policy and it requests an ODJ blob from Intune Service.
- Intune service locates the respective tenant’s Intune Active Directory Connector which was installed by the Intune admin on a Windows Server 2k16 and forwards to it the ODJ request by the client.
- The 2k16 server reaches out to the Domain Controller and creates a computer object in the delegated OU. The OU and the naming convention of the computer object is as mentioned in the ODJ profile created in Intune.
- This object will be synced to the cloud by the AAD Connect.
- Using DJOIN.EXE, the blob is created, the connector uploads the ODJ Blob to the Intune Service. For more details on the process, please refer to- (show the log in eventvwr)
- Intune service delivers the ODJ blob to the client machine.
- The device restarts and does a ping to the on-prem domain controller. At this point a check is made if the machine can reach out to the DC.
- The device is successfully joined to the on-prem domain. Now any on-prem user can log into the device. Upon login, the GPOs from the DC flows down.
Final State of the device:
Let’s check what is the final state of devices which are Hybrid Azure AD joined. Hope you have a better understanding the flow behind Hybrid Azure AD Join AutoPilot deployment from Intune.
- #AAD Joined
- #On-prem Domain Joined=>The state is referred to as Hybrid Azure AD Joined
- #Intune enrolled
- #Apps/policies pushed down from Intune
- #GPOs pushed down from on-prem DC