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.