The transition from traditional to the modern managed workplace is not only a transition that involves changes in tools and/or modes of management, but also a change in the organization’s approach towards IT.
The journey from on-premises to being cloud-native requires embracing a lot of changes – changes in processes that have been followed for a long time. The hardest obstacle is to make people unlearn the old ways of doing things and instead start following the new ways.
And this has been the exact reason for many organizations transitioning from traditional to the modern managed workplace, to go the Hybrid Azure AD join path, just because it seems to offer the best proposition initially – you get to keep your current environment but at the same time adopt the modern world.
But I have said it before and I will say it again
Hybrid Azure AD join with Windows Autopilot is a pain for your IT support team.
For the existing Windows 10 devices in the environment that are domain-joined and are still left with time before they will be refreshed, configuring Hybrid Azure AD join becomes a really good choice as it instantly gives you the benefits of modern management for those devices (if you wish to consume) while comfortably continuing with the traditional management.
But if you decide to go the Hybrid Azure AD join way even for new devices coming into the environment (new purchase plus devices getting refreshed), then you may(?) want to give a quick rethink to your modern journey strategy.
Ask any modern management enthusiast and you would probably hear them advising you to stay away from doing Hybrid Azure AD Join with Windows Autopilot unless it’s really the last resort.
However, if for some valid reasons (see my previous blog post on AADJ vs HAADJ), you decide to go with Hybrid Azure AD join for new devices to be provisioned via Windows Autopilot service, then this blog post is for you.
💡 This post deals with Hybrid Azure AD join with Windows Autopilot for a Managed Domain environment only.
💡 If your environment is FEDERATED, then review the detailed process diagram for hybrid join in a federated environment as provided by Microsoft to help understand the HAADJ process in a federated environment.
Table of Contents
Hybrid Azure AD join via Windows Autopilot – Complex Architecture, More Breakpoints.
It’s important that you understand the possible breakpoints of Hybrid Azure AD Join with Windows Autopilot for a MANAGED domain environment so that you are well aware of what you are getting yourself into.
The additional components required to pull of Hybrid Azure AD Join with Autopilot contribute to the complexity of the underlying process and as a result, adds in more breakpoints.
Understanding the breakpoints of the entire process will eventually help you to troubleshoot and overcome the failures that you may face.
For your reference, I am adding below a sample HLD diagram for Hybrid Azure AD Join with Autopilot in a Managed Domain Environment.
The pains of doing Windows Autopilot Hybrid Azure AD Join in a Managed Domain environment
Consider that the infrastructure required to support Hybrid Azure AD join with Windows Autopilot is in place, along with all the necessary configuration required in Intune.
OEM registers devices to Windows Autopilot for the Organization and ships device to end-user, or end-user collects device from local IT.
Post receiving the device, the end-user
- unboxes it,
- plugs it to a network cable and
- powers it on.
If the Autopilot profile is configured to set the region, the device skips the initial OOBE screens (set Region and Keyboard) to directly present the user with the company-branded Azure sign-in page.
💡 If the device is not connected to a wired network, then the Autopilot check happens post the device is connected to a wireless network. In such a scenario, the OOBE setup will display the Region and Keyboard screen before showing the Network screen where the user gets to select the Wireless network to connect.
Windows Autopilot Hybrid Azure AD Join – Breakpoint #1
If the user does not get the company-branded sign-in screen, then the device has failed the autopilot check.
This failure or breakpoint is more related to the Windows Autopilot service and as such is common for both Azure AD Join as well as Hybrid Azure AD Join. If the network requirements are not met, irrespective of the join state configured/desired, the device can fail the Autopilot activation check.
Make sure that the device is connected to a network (either plugged-in or select a wi-fi network from within OOBE) when doing the provisioning. Ensure that the autopilot network requirements are met if doing provisioning using corporate network.
Post successful user auth, the provisioning is taken over by the Hybrid Azure AD join mechanism.
The OOBE setup process briefly displays the screen as shown below. This is the time when the device requests an ODJ blob from Intune and waits for the same.
Windows Autopilot Hybrid Azure AD Join – Breakpoint #2
If Intune cannot find a domain join profile targeted to the device, the device provisioning process will time-out here at this stage, waiting for the ODJ blob.
Make sure you have the Domain Join profile deployed correctly.
Intune gets the ODJ blob created for the device from the domain controller via the Intune ODJ Connector (officially named the “Intune Connector for Active Directory”) and sends it to the device. As the device receives the ODJ blob and applies it, if the applied Autopilot profile has “skip connectivity check” setting enabled, the device will immediately reboot.
Windows Autopilot Hybrid Azure AD Join – Breakpoint #3
If the “skip connectivity check” setting is not enabled in the Autopilot profile, the device starts to ping the connected network to check the existence for a domain controller.
As the device receives the ODJ blob from Intune and applies it, before rebooting to complete the process, it will try to ping the domain to ensure connectivity. The device provisioning process will time out here at this stage if the device ping test does not succeeds.
Ensure the “Skip Connectivity Check” is enabled in the assigned Autopilot profile.
Post restart the device comes up to the Windows ESP screen to show the device provisioning progress.
On completion of the ESP device setup phase, the end-user gets prompted for a Windows sign-in.
Windows Autopilot Hybrid Azure AD Join – Breakpoint #4
This Windows sign-in is to the domain and as such requires a VPN connection to be established to get “line-of-sight” connectivity to AD if on the Internet. If the user is unable to establish a VPN connection from the Windows login screen, the process will not succeed.
Ensure to have the proper VPN setup in place to support Hybrid Azure AD Join Autopilot over the Internet.
Considering user ESP is disabled (which should be the case for Hybrid AADJ Autopilot in a managed domain environment), the user gets presented with the Desktop screen post Windows login process.
And this is where we arrive at the most significant breakpoint of the entire process.
Only if the Hybrid join process gets completed before the device ESP phase completes (that is AAD Connect picked up the on-prem computer object that is created by the Intune ODJ connector and synced it to AAD BEFORE device ESP completes), we can be assured that the device will get the required AzureAD PRT on the initial user sign-in to Windows that is presented to the user post the device ESP phase.
By default, the AAD Connect syncs every 30 minutes, and thus with the default sync cycle, can add up to a 30-minute delay to the Hybrid join process (worst case scenario).
Generalized, this adds a 15 min delay to the process. This means the device needs to be in the device ESP phase for long enough to buffer this sync delay on the backend.
Windows Autopilot Hybrid Azure AD Join – Breakpoint #5
If the device does not stay locked in the device ESP phase for long enough to buffer this backend sync delay, then the user sign-in event (login to Windows post completing device ESP) won’t fetch the device the required user token (Azure AD PRT).
Considering the fact that the device is yet to complete that backend AAD sync process, which is generally true (unless you have enough apps to install during the device ESP to mask the sync delay), the device at this stage is not yet in a production-ready state, even though the user is presented with the Desktop.
And this is where things start getting inconsistent from the end-user experience perspective.
- At this point, the device will not receive the policies targeted to the user.
- OneDrive sync does not gets automatically configured, even if you have the related Intune policies in place.
- None of the Office apps get automatically signed-in with the user account on start.
- Bitlocker encryption wont kick off, even if you have Intune policy targeted to the device.
- End-user gets this annoying Work or school account problem notification.
- Further if you try to sync device, the sync action will not succeed.
All of the behavior as mentioned above is only due to the fact that the device HAS NOT received the user token (Azure AD PRT) that IS REQUIRED for the device to start communicating with Intune and the rest of the M365 services.
The Windows Autopilot service and Microsoft Intune only take care of getting the device joined to Active Directory and enrolled in Intune. The Hybrid Azure AD Join in itself is a separate process that happens in the background, and for a managed domain environment, is dependent on the sync schedule of AAD Connect.
Till the time AAD connect syncs this device to Azure, the device fails the Azure AD DRS process.
The Azure AD DRS process gives the device an identity vide the Azure AD device certificate.
It is after the AAD Connect syncs the on-prem device object to Azure, is when the Azure DRS process of automatic registration succeeds, thereby fetching the device its much-needed Azure AD device certificate. Only after this, when the user does a fresh sign-in to the device, is when the device receives the Azure AD PRT and can start communicating with the Microsoft cloud services for proper functioning.
All of the breakpoints as discussed above are by design of how Hybrid AAD Join works with Autopilot.
Thus, as stated earlier,
For a Managed Domain environment, you cannot assure the device to be in a production-ready state when the user gets to the Desktop screen after completing the Device ESP for Hybrid AADJ Autopilot.
Still want to continue doing Hybrid Azure AD Join Autopilot?
Even though at the first thought, it may seem that you may want to proceed with Hybrid Azure AD Join because of the flexibility it offers, if you carefully evaluate and consider the requirements, in most cases, you will find that you can very well adopt the cloud-native Azure AD Join path.
The troubles that you get to face with Hybrid Azure AD Join Autopilot may actually outweigh the advantages that it has to offer over Azure AD Join.
If you still decide to go the Hybrid way, then you may want to wait for my next post on this series, which will showcase a custom solution that can overcome the Azure AD PRT issue as discussed in this post.
Teaser for the next post…
Stay tuned!
Got me engaged, tuned in for the next chapter 🙂
Thanks for taking the time to read and leave a comment as well.
This is cool. Waiting for the next article.
looking forward to next post! This was a great write up.