Windows Autopilot

Windows Autopilot user-driven Hybrid Azure AD Join over the internet using a VPN

It has taken a long time, and there have been plenty of bumps along the way, but it’s finally available in public preview:  You can perform a user-driven Hybrid Azure AD Join deployment over the internet, using a VPN connection to establish connectivity so the user can sign into the device.  Before we get into the detail on that, it’s worth reading up on the Hybrid Azure AD Join process – see my previous blog on that subject.  The key takeaways:

  • Windows Autopilot orchestrates the process for getting the device joined to Active Directory.
  • After the device has joined Active Directory, a background process will eventually complete the Hybrid Azure AD Join device registration process.  This is not driven by Windows Autopilot, it just “happens.”  Depending on your specific configuration (e.g. ADFS vs. non-ADFS), this can take a while.

There are a number of steps performed by Windows Autopilot to complete the Active Directory join process:


Here’s an overview of each step:

  1. The device identifies itself to the Autopilot service using its hardware hash.  (There are multiple parts to this process, so this is a simplified view.)
  2. The device receives its Autopilot profile details, which indicates that the device should perform an Active Directory join.  (The Autopilot settings includes the Azure AD tenant info, but nothing about the Active Directory domain or OU.  All of that is managed by Intune.)
  3. The device will use the Azure AD user credentials provided by the user to complete the Intune MDM enrollment.  It will indicate to Intune that it wants to perform an offline domain join (ODJ).
  4. Intune will determine the “Domain Join” profile for the device, which specify the Active Directory domain name, OU, and naming prefix.  An ODJ Connector request will be generated with these details.  An ODJ Connector periodically polls for these requests, downloading them from Intune and processing them.  (It’s always an outbound connection from the ODJ Connector to Intune, never the other way around.)  Using a Windows API, the ODJ Connector creates a computer account in Active Directory, and gets an opaque “ODJ blob” that represents the computer account.
  5. The ODJ Connector will upload the resulting ODJ blob to Intune.
  6. On the next MDM sync, the device will receive the ODJ blob from Intune.

This same process has been in place since the Autopilot Hybrid Azure AD Join process was put in place, so nothing has changed here.  What’s changed is what happens after the ODJ blob is received by the device.  Prior to the new feature we added, there was another step between #6 and #7, done before the device would reboot to complete the join process: Autopilot would attempt to ping the domain controller (using information from the ODJ blob to figure out what to ping).  That was done so that we would “fail fast” – if there was no connectivity, why continue on only to end up with a device where the user couldn’t log on?

That’s the key change we made:  You can now choose to skip this ping test by checking the new box:


With that option checked, the device will reboot as soon as the ODJ blob is received and applied.  After the reboot, the device ESP will be displayed, tracking all the apps, certs, and policies targeted to the device.  This is where the VPN configuration needs to be performed.  Typically, this would involve installing a Win32 VPN app (“fat client”), e.g. Cisco AnyConnect, with any other configuration needed (e.g. a machine cert) to support VPN authentication.  The basic VPN requirements:

  • The VPN connection either needs to be automatically established (e.g. “always on”) or it needs to be one that the user can manually initiate from the Windows logon screen.
  • The needed VPN configuration needs to be applied during device ESP.

There’s nothing special about the VPN setup here – you just need to make sure that there is connectivity so the user can sign into Active Directory, which requires validating credentials against the AD domain controller.  It’s exactly the same scenario that you would need to support for a password change.  Imagine an employee went on vacation and forgot their password, then called the helpdesk to have it reset.  If they weren’t on the corporate network, how would they sign into Windows with the new password?  If you’re already able to solve that challenge, you’re probably good to go already (with some caveats – more on that later).

Assuming you’ve pushed the needed configuration to the device using Intune during device ESP, then the user can proceed to step #7:  Signing into Windows using their Active Directory credentials.  If you are using an auto-connecting VPN, this will “just work.”  If you are using a VPN client that requires manually connecting, that can be done using the network icon that is added to the logon screen:


See the official documentation for the requirements for this feature, and the recommended process for validating that everything works fine.  (Basically, don’t try to do everything at once, be methodical as you are working on trying this out.)  At a high level, this works with Windows 10 2004 out of the box, or if using Windows 10 1903 or 1909, after you install the December cumulative update (or later) on the device.

It’s worth mentioning that this exact same process was always available for white glove pre-provisioning scenarios.  The technician phase of the process never requires connectivity to an AD domain controller because a user never needs to sign on, hence the ping check was always skipped for this scenario.  (So the entire implementation of this new VPN feature just enables the same “non-logic” for user-driven scenarios.)  Since the technician phase could already provision the VPN client and any other requirements (e.g. machine certs), the device would already be “ready for connectivity” by the time the user received it.

Categories: Windows Autopilot

6 replies »

  1. Its mentioned everywhere that we need to install intune connector on Server 2016 or later but its system requirements are not mentioned anywhere. Can you please share that.
    Also what is the role of WPAD? If WPAD is there, do we need to mention the proxy server details in intune connector files? And if WPAD settings are not there, what is the next step.


  2. Michael, I am at the end of configuring a new Intune Tenant for an organization that will be using White Glove provisioning to Hybrid Azure AD join their devices using us as the vendor to provide White Glove provisioning. I have everything configured and had the warehouse test the White Glove process a few weeks ago and everything worked fine and they got the Green Screen. I had them test a littel over a week ago with a base load of applications being delivered (had to re-work some MSI applications to Win32 dellivery) and everything worked (Green Screen). We are now ready to do a mass deployment of ALL devices, but they did a last test two days ago and they are no longer getting Green Screen, they are going straight to the user login screen. Did the Technical Workflow for White Glove change?


  3. How does this work in combination with an Always On VPN Device Tunnel ?
    I can create a win32 app which deploys the VPN Device tunnel, but for the device tunnel the Windows 10 edition should be an Enterprise edition.
    Windows 10 Pro is default deployed with AutoPilot, when a users signs in with a Microsoft E3 license it will be upgraded to an Enterprise edition.
    But I can’t logon because I don’t have a working VPN Device Tunnel after the deployment.

    Liked by 1 person