New for Windows Autopilot: VPN support and ESP device targeting

Published 06-25-2020 12:04 PM 15.7K Views

With the latest Microsoft Intune updates, we've opened up key new capabilities for Windows Autopilot thanks to your feedback and the requirements you've expressed.

User-driven Hybrid Azure AD Join now supports VPN

Many organizations want to leverage Windows Autopilot to provision new devices into their existing Active Directory environments. This capability has been available beginning with Windows 10, version 1809, but with an important restriction: devices needed to have connectivity to the organization’s network in order to complete the provisioning process.

Now, this restriction has been removed. By leveraging VPN clients (Win32 apps) delivered by Intune during device enrollment, devices can instead be sent directly to the end user, even when they are only connected to the internet, and they can still provision the device.

To implement this, a new “Skip AD connectivity check” option has been added to the Windows Autopilot Hybrid Azure AD Join profile. When enabled, the device will go through the entire provisioning process, up to the point where the user needs to sign into Windows for the first time, without needing any corporate network connectivity.


As part of device enrollment status page (ESP) tracking, Windows Autopilot and Intune can ensure that the needed VPN configuration is put in place before the user needs to sign in. Depending on the VPN client’s capabilities, this could be automatic or it might take an additional action by the end user to initiate the connection before logging on directly from the Windows logon screen, as shown below:


For specifics on how to enable this new VPN scenario, consult the updated Windows Autopilot documentation.

Enrollment status page device targeting

The ESP is a key part of the Windows Autopilot provisioning process, enabling organizations to block access to the device until it has been sufficiently configured and secured.

For those that are familiar with the targeting of ESP profile settings, you will recall that there were two options: targeting a group of users or targeting a special "default" ESP profile to all users and groups. This was challenging as some scenarios (self-deploying and white glove, for example) do not have users, and, even when there are users (e.g. user-driven scenarios), it can be difficult to ensure that the settings are only used as part of the Windows Autopilot provisioning process (since you can use ESP without Windows Autopilot too).

With this month’s new Intune functionality, you can now target ESP profiles to groups containing devices. Intune will first look at device membership, then user membership, before using the "default" ESP profile in any other case. There are no visible changes in the Intune portal, just a change in the targeting behavior. The Intune documentation for ESP has been updated to reflect this change.

Try out the new Windows Autopilot capabilities

Every enhancement we make in Windows Autopilot is in response to feedback from our customers and partners that are using this as a key part of their Windows provisioning process. We encourage you to try out these new enhancements and provide feedback on not only these features, but any other challenges that you encounter. You can leverage the Microsoft Endpoint Manager UserVoice site, Tech Community, or your favorite social media service.

For additional assistance with implementing Windows Autopilot, Intune, or any other component of Microsoft Endpoint Manager, contact your Microsoft account team or

Occasional Contributor

Targeting the ESP to a deivce group is great news! However, I have seen a number of cases now where it does not seem to pick up the ESP assigned to the device, and as a result, Autopilot finishes almost immediately with no apps/policies installed yet. This never happend when targeting users......wondering if anybody else has run into this....

Valued Contributor

It might be one yes/no but it is super helpful.

Thank you for sharing these new features.

Not applicable

Same here, targetint devices don't work, no applications are installed... applications are set correctly with the correct device group..;


If you are using Hybrid Azure AD Join, make sure the ESP is targeted to a group that contains the pre-created AAD device as well as the Hybrid AADJ device created after an initial deployment.  If you don't do that, the first time through will work (ESP targeted to the AAD device), but for the second time through Intune will use the Hybrid AADJ device (ESP still targeted to the AAD device) and it won't work.  You would have to make sure that all the devices (AAD and HAADJ) are in a group that has an ESP profile targeted.

Occasional Contributor

@Michael Niehaus I am targeting the ESP to the same device group that is used to assign the Autopilot profile, pure AAD cloud scenario only. The issue was intermittent, so in some cases it worked as expected. I will run additional tests come Monday and raise through the right channels if necessary. Was just curious if others are seeing the same. 

Occasional Contributor

Ran tests today by reprovisioning the same device from scratch a total of 4 times.
2 times I did get the ESP, 2 times I did not get the ESP. Case opened: #20686817‎

Occasional Contributor

@Jan Gutjahr This sounds like another timing issue. Try waiting longer/force a AAD Sync or double check that the new computer name has been added to the dynamic AAD group before continuing... It sounds like the same exact issues I constantly have with testing the autopilot service. I will be testing this out today myself. But I have been working on a AAD profile for my company since Covid has made Hybrid Deployments almost impossible without this feature. And since there are less delays with the AAD autopilot vs the HAADJ autopilot and we have no internal apps that require AD auth we might be sticking with it. Good Luck!


@Michael Niehaus With this addition does it mean that AutoPilot Reset might be on the horizon for HAADJ?

Occasional Contributor

@Andrew Allston my scenario is pure AAD Autopilot, so no sync required and the AAD object is always part of the AAD device group that I target the ESP to. It's actually the same device group I target the Autopilot profile to, and that one always works.

Occasional Contributor

@Jan Gutjahr Gotcha, but I would still check the Dynamic Group, they can take a while to update. I would think they should use an object ID vs the Display Name on the backend, but they don't seem to do that. One would think that if an AutoPilot Record has an Object ID of 111 then even if the name was changed (like in the AutoPilot flow) the membership of the dynamic group shouldn't need to reevaluate to grant policies and whatnot to the devices in the group since the ID doesn't change. There is probably some issue preventing them doing that now, but I would like to think they are working on that...


Again this is what it seems to happen from what I can tell. I noticed that with my testing of AAD vs HAADJ with my autopilot records. I have my main Dynamic Group that pulls all AutoPilot records into itself and Assigns a HAADJ Profile then I have a static group of test devices which is excluded from the Main AP Group that enables my AAD join profile. When the flow changes the name of my Test AAD device, depending on timing, I can see the default HAADJ profile get assigned to the AutoPilot record then it will go back to the AAD profile after the groups all update and AutoPilot syncs again. If this is true for everything not just Autopilot then I can see this being the issue you are seeing.

Occasional Contributor

@Jan Gutjahr Oh Apologies, I see what you are saying, don't mind my ramblings above :) . Just curious are you using White Glove? Or is this just the standard Autopilot flow from OOBE? 

Occasional Contributor

@Andrew Allston Just standard AAD only Autopilot from OOBE, no HAADJ or WhiteGlove.

Version history
Last update:
‎Jun 25 2020 12:04 PM
Updated by: