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.
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
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
Register IP addresses with internal DNA: Enable
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.
After entering in the account name we are prompted for a password.
