So I’m guessing that you may have tried AutoPilot in the past. Maybe your expectations didn’t match up to what the product was touted to offer. Microsoft’s initial approach to AutoPilot was to move you straight into an Azure AD Joined world with your devices using Intune as the management engine. Based on customer feedback they adapted it for Hybrid customers. There was a major problem that caused a disjointed and poor end-user experience for Hybrid Azure AD Join (HAADJ) Autopilot deployments.
As customers have performed PoC’s of AutoPilot, the consistent feedback we have received and observed is that Intune doesn’t account for the time required for the AutoPilot process until the actual Hybrid AD Join process has been completed. This drops the user into a Desktop that is not yet ready for use. This doesn’t provide an experience like what customers have today when they deploy a PC using a Configuration Manager Task Sequence.
The whole process revolves around creating an Offline Domain Join Blob (ODJB)… that gets sent to an on-premises AD Domain Controller… which then in turn must be synced to Azure AD… all before the user tries to log in to the device. Sounds complicated and very prone to failure if everything doesn’t line up perfectly, doesn’t it? Under the hood per se, there are really two separate processes in play that are running asynchronously that make AutoPilot for Hybrid Azure AD Joined devices.
- Microsoft Intune takes care of the device enrollment in Intune and sends the ODJB to on- premises AD.
- Azure AD Connect then performs the Hybrid Azure AD Join process for the device.
These two are in no way “tied together,” as you can see from the illustration below.
The problem lies in the timing of the end-to-end process. How do we slow the users' ability to sign in to the device before the device receives the Azure AD devices certificate? In most environments, the administrator supporting Azure AD Connect has chosen a sync interval and which OUs are getting synced to Azure AD. This occurs outside of the Intune administrator's AutoPilot configuration and operation. So how do we produce an experience that will allow for a successful Autopilot of a Hybrid Azure AD Joined devices that has an acceptable end-user experience?
The answer is, we need a way to stall/prevent the users from getting to the Login screen until the HADDJ is completed (but not long enough to cause the Device ESP to timeout). Since we cannot use the AutoPilot ESP, we’re going to have to come up with something outside of the standard process in Intune.
Thankfully, a Microsoft Community MVP (Joymalya Basu Roy) has come up with a very well-polished solution using a variety of scripts packaged as Win32 apps. He has accomplished this by adding a custom splash screen after the device ESP has processed to hold the device in a “locked” state until the HAADJ process has been completed. This solution can be adapted for both customers who are using Configuration manager and are Comanaged and those that are not.
A screenshot of the custom OOBE screen in action.
The above illustrates how the custom OOBE screen is locking the AutoPilot process while the Hybrid Azure AD Join process is completed.
If you recall the previous flow where HAADJ was failing and causing an interrupted AutoPilot deployment, this method illustrates the successful completion of a HAADJ device using AutoPilot.