Managing Modern IT systems: Autopilot and the User Driven Profile with VPN: Hyper-V lab

Introduction

Autopilot really is one of Intune's great features. A device can be shipped directly from the OEM to a user and, providing the user has an internet connection, all she or he needs to do is power up the device and sign into the device. Autopilot takes over and completes the required build, enrolling the device to Azure Active Directory and installing the required applications and configuration profiles. For this scenario there is no requirement for any on premise infrastructure.

And if the user's organisation requires the device to be also joined to an on-premise Active Directory - this too can be handled by Autopilot. At some point however the device needs to communicate with an on-premise domain controller. Thus here we have a requirement for the device to undergo at least part of the Autopilot operation while connected to the on-premise infrastructure. This does involve additional costs for an organisation, having to maintain for instance a remote LAN at a provisioning partner's premise. This can be avoided if the Intune Connector for Active Directory is installed on an on-premise server: this enables a domain join without any connection to the corporate network. But the device's designated user will need to travel into a location where they can sign into the device, and be authenticated by an on-premise domain controller. Microsoft refer to these situations with the term - Hybrid Azure AD joined profile.

The User Driven with VPN profile, in preview at the time of writing, gets around these requirements using, as the name suggests, a VPN connector so the user can sign into the device, cache his or her credentials, and without having to visit an office location.

In this article I demonstrate how to test this feature in a Hyper-V lab environment using only the Windows native VPN and PPTP tunnelling. It is not a start to finish set of steps - it begins from an assumption that the engineer already has the Hybrid Azure AD joined Autopilot scenario working.

I will cover:

1) A Brief Overview of my environment.

2) The Hyper-V Virtual Switch requirements.

3) The Routing and Remote Access configuration.

4) Creating a native Windows VPN connection.

5) Creating an Extensible Authentication Protocol (EAP) xml file.

6) Creating the Autopilot VPN profile.

7) The User Driven Deployment Mode profile configuration.

8) The Domain Join profile configuration.

A Brief Overview of my Lab Environment

For this exercise the lab environment consists only of two virtual devices.

One is the DC Controller and it has installed on it the following: DHCP and a 10.11.12.0/24 scope, the Intune Connector for Active Directory and the Routing and Remote Access Server feature. There are two Network Adapters attached to this device - one for internet connectivity and one for the internal AD environment. It has the Windows Server 2019 Operating System installed on it. Its NetBIOS name is Server1

The second device is the workstation that will receive the Autopilot deployment. It has only one network adapter and this is connected to the internet. There is no way for this device to connect to the internal Active Directory domain apart from via an VPN connection.

The workstation OS will be Windows 10 with the 21H2 feature release. It has two virtual processes and 5GB of ram. Its NetBIOS name is determined by the Intune Domain Join profile and is prefixed by MDCS followed by a series of random characters - to be detailed later in this article.

Important: The autopilot recipient needs to have >4GB ram and it needs to have two virtual processors assigned. This is to address an issue outlined in the following article

https://docs.microsoft.com/en-us/mem/autopilot/known-issues

Namely: "Virtual machine failing at "Preparing your device for mobile management"

The Hyper-V Virtual Switches

I have two Virtual switches configured in my lab for this exercise. There is an internet facing switch that connects to the ethernet adapter in my laptop (the host) and this connects to my broadband router. The name of this switch is: Lab1ExternalEthernet. Its network ID is 192.168.1.0/24.

Each of the two virtual devices have a network adapter attached to this switch.

The other virtual switch is a private network and is named Lab1PrivateNW. Its network ID is 10.11.12.0/24 and it represents an on premise network. Only the domain controller (server1) has a network adapter connected to this switch.

The Routing and Remote Access configuration

It will be a collaborative task to determine your corporation's security and VPN requirements and there are multitudes of options to consider. Here I present the configuration for a PPTP VPN approach that worked in my Hyper-V lab. You can copy this by installing the RRAS feature, using your preferred method - and then opening the RRAS console. Right click on your server and select Configure the Routing and Remote Access Server. You are then presented with various options and my case I selected the Remote access (dial-up or VPN) option. Here is an overview of my configuration.

If I select the properties of my RRAS server you can see I have enabled an IPv4 Router for LAN and demand-dial routing.

On the IPv4 tab I have enabled IPv4 forwarding and selected the option to allow the DHCP service to delivered our internal IP addresses.

On the Security tab and clicking on Authentication methods I have selected EAP, MS-CHAP v2 and CHAP.

Launching the Network Policy Server console by right clicking on the Remote Access Logging and Policies node I have modified the existing default policy to Grant Access.

Note: In my case I chose to use the PPTP protocol for my client VPN connections really to keep it as simple as possible, and removing a dependency on certificates.

Creating a native Windows VPN connection

Having configured the server side of the VPN connection, naturally we want to test that it works. And in fact, as we shall see later, we really need to do this in order to produce an EAP.xml file.

If you are using Hyper-V and are using a similar configuration to mine, then you can test it by creating a VPN on your host laptop - following these steps if you are using Windows 10.

1) From Settings navigate to Network & Internet and then to VPN

Click on Add a VPN connection. For the VPN provider select Windows (built-in). Enter a Connection name - here I enter in domain1. Enter in the server ip address - in my case it is 192.168.1.66. For the VPN type field enter in Point to Point Tunnelling Protocol (PPTP). For the Type-of sign-in info field I select Username and password. I leave the Username and Password fields empty and click on Save.

The VPN domain1 connection now appears.

When I click on the domain1 connection I have the option to click on Connect - which is what I need to do. I am then requested to enter in my credentials after being informed that the blank credentials have failed.

After entering in the credentials I am connected - a good sign and reassurance that all is working well.

Creating an Extensible Authentication Protocol (EAP) xml file

An Extensible Authentication Protocol (EAP) configuration xml file is required when we create the Intune VPN connection profile. Thus, having now created the VPN connection we can use PowerShell to produce the xml file. Here is the process:

1) Open a command prompt and enter PowerShell - powershell.exe -executionpolicy unrestricted

2) Type $a=get-vpnconnection -name <name of your VPN connection> and press Enter.

3) Type $a.eapconfigxmlstream.innerxml >> c:\<folder name>\<name of xml file and press Enter

The EAP.xml content is now ready to load into the Intune VPN profile properties.

<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><EapMethod><Type xmlns="http://www.microsoft.com/provisioning/EapCommon">26</Type><VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId><VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType><AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId></EapMethod><Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1"><Type>26</Type><EapType xmlns="http://www.microsoft.com/provisioning/MsChapV2ConnectionPropertiesV1"><UseWinLogonCredentials>false</UseWinLogonCredentials></EapType></Eap></Config></EapHostConfig>

Creating the Autopilot VPN profile

Now that we have the EAP.xml content we are able to create the VPN profile in Intune. This is done by navigating to Devices\Windows\ Configuration Profiles in the Microsoft Endpoint Manager admin center (Intune Portal). The platform will need to be Windows 10 and later and the Profile type will be Templates. The Template name is VPN.

My configuration is as follows:

Use this VPN profile with a user/device scope: Device

Connection Type: PPTP (Native type)

I then configure the Base VPN as follows:

Connection name: Domain1

Servers: IP address on external Hyper-V switch, which is 192.168.1.66

Always On: Enable

Remember credentials at each logon: Enable

Authentication method: Derived credential

Open the EAP xml file, as detailed in the previous section, with notepad, and copy the contents into the EAP XML box.

Be sure to save this profile and assign it to the group to which your Autopilot Deployment profile is also assigned to.

The User Driven Deployment Mode Profile

Your User Driven profile with the Hybrid Azure AD joined setting will need to be modified. The User Driven with VPN Autopilot deployment is designed to handle a situation without direct connectivity to an on site domain controller. Therefore we have to set the Skip AD connectivity check (preview) setting to Yes - otherwise this will fail without a corporate connection in place.

Note: If you have an Enrolment Status Page profile configured - you may need to create a custom OMA-URI policy if the ESP freezes on Joining you organization's network (Working on it...).

See the following article:

https://community.spiceworks.com/topic/2196102-windows-autopilot-hybrid-domain-join-not-fully-working.

The Domain Join profile configuration

In this configuration the option of selecting to Apply device name template is not available in the Windows Autopilot deployment profile. Therefore, if we desire to use such a template - we can do so in the Domain Join profile. In my profile I specify a prefix of MDMCS. Intune then completes the NetBIOS name by adding random characters so that the complete name is 15 characters long.

The AutoPilot User Driven with VPN Experience

Now that we have all our requirements in place, let's look at what this type of Autopilot deployment looks like in practise. We start with Welcome To <Name of Tenant> sign in page.