Always On VPN and Device Sharing

Always On VPN client configuration settings are typically deployed in the user’s context. However, this presents a unique challenge when sharing a single device with multiple users who have an Always On VPN profile assigned to them. By design, Windows designates only a single user profile on a shared device to be “always on”. When multiple users with assigned Always On VPN profiles share the same machine, it could yield unexpected results.

Auto Trigger Profile

When an Always On VPN profile is provisioned to a user, Windows records information about this profile in the registry. Specifically, the Always On VPN profile’s name and GUID are recorded, as well as the user’s Security Identifier (SID) and the path to the rasphone.pbk file that contains the Always On VPN profile.

Multiple Users

When a new user logs on to a shared device and receives their Always On VPN profile, Windows overwrites this existing data in the registry with the current user’s information. Each time this user logs on, their Always On VPN connection will establish automatically. Any other users with Always On VPN profiles configured on the same shared device will no longer connect automatically after this. The most recently deployed Always On VPN profile will be designated the “always on” profile.

Connect Automatically

In the above scenario, any user with an assigned Always On VPN profile on the shared device can take over the “always on” designation by opening the VPN connection properties and checking the “Connect automatically” check box.

When this happens, this user will now own the “always on” profile, and other users on the shared device will no longer connect automatically.


If multiple users share a single device requiring Always On VPN connectivity, you have a few options.


If you are deploying Always On VPN client configuration settings using Intune, you must use the Custom device configuration profile template. Specifically, as shown here, you must deploy your XML configuration file using the ./Device/Vendor/MSFT/VPNv2/ OMA-DM URI.

Unfortunately, the native Intune VPN template does not support deploying Always On VPN profiles in the “all users” context.


When using PowerShell, either natively or with SCCM or another software deployment tool, administrators can use my Always On VPN deployment PowerShell script with the -AllUserConnection parameter.


When using PowerON Platforms’ Dynamic Profile Configurator (DPC) to deploy Always On VPN client configuration settings using on-premises Active Directory or via Intune, no changes are required. DPC deploys Always On VPN user profiles in the “all users” context by default.

Additional Information

New-AovpnConnection.ps1 PowerShell Script on GitHub

PowerON Platforms’ Dynamic Profile Configurator (DPC)

Always On VPN DPC with PowerON Platforms’ DPC

Always On VPN with Active Directory Group Policy

Windows Always On VPN is a workload explicitly designed to be implemented and managed using Microsoft Endpoint Manager/Intune. While this is the best way to deploy and manage Always On VPN client configuration settings, it is not the only way. Administrators can also use System Center Configuration Manager (SCCM) by deploying a PowerShell script and XML configuration file to configure Always On VPN. Of course, it’s always possible to run the PowerShell script on individual machines.

Group Policy

Until now, there have been few options for deploying and managing Windows Always On VPN using Active Directory and group policy. This presents a challenge for administrators who still rely on group policy to manage their endpoints. It is possible to deploy the PowerShell script and XML configuration file using a group policy startup script. However, there are many limitations to this approach. Administrators must learn to properly configure the XML file and manage any configuration updates post-implementation.

Always On VPN DPC

The folks at PowerON Platforms have developed the Always On VPN Dynamic Profile Configurator (DPC) to address these shortcomings. Always On VPN DPC allows administrators to deploy and manage Always On VPN client configuration settings using Active Directory and group policy. Their software comes with Active Directory group policy templates that include all the necessary settings and client software that manages the configuration on the endpoint.

Advanced Features

Always On VPN DPC includes advanced features not included in Microsoft Endpoint Manager/Intune or XML. Here’s a sample of helpful custom settings that can be configured using Always On VPN DPC.

  • VpnStrategy
  • Interface metrics
  • Route metrics
  • Dynamically updated Office 365 exclusion route list
  • IKE mobility settings
  • IPv6 routes
  • And more…

DPC and Intune

Microsoft recently announced support for importing custom ADMX files to Intune. This allows administrators to leverage Always On VPN DPC using Microsoft Endpoint Manager/Intune. More details here.


I’ve created a brief introduction video for PowerOn Platforms Always On VPN DPC on YouTube. Soon I’ll be releasing additional videos that cover the installation and configuration of Always On VPN DPC and some of its advanced features, so be sure to subscribe to my YouTube channel.

Learn More

Are you interested in learning more about PowerON Platforms Always On VPN DPC? Fill out the form below, and I’ll contact you with more information. In addition, you can visit to register for an evaluation license.

Special Thanks

I want to extend a special thank you to Leo D’Arcy and the entire team at PowerON Platforms for allowing me to preview this software before its wide release. Also, I’m honored that you have graciously accepted my input and feedback for this solution. I’m consistently amazed at how rapidly you’ve corrected issues and implemented new features at my behest. You are all amazing. Thanks again! 😁

Additional Information

Introducing PowerON Platforms Always On VPN DPC on

What’s New in Always On VPN DPC 3.0

Always On VPN DPC and Microsoft Endpoint Manager/Intune

Always On VPN Client Routes Missing

Choosing an Enterprise VPN

When configuring Always On VPN for Windows 10 and Windows 11 clients, administrators may encounter a scenario where an IPv4 route defined in Microsoft Endpoint Manager/Intune or custom XML is not reachable over an established Always On VPN connection. Further investigation indicates the route is added to the configuration on the endpoint but does not appear in the routing table when the connection is active.

Routing Configuration

When split tunneling is enabled, administrators must define routes to IP networks that are reachable over the Always On VPN connection. The method of defining these routes depends on the client configuration deployment method.

Endpoint Manager

Using Microsoft Endpoint Manager, administrators define IP routes in the Split Tunneling section of the configuration settings for the Always On VPN device configuration profile. Routes are defined by entering the destination prefix and prefix size. In this example, the and IPv4 networks are defined for routing over the Always On VPN tunnel.

Custom XML

Using custom XML deployed using Microsoft Endpoint Manager, System Center Configuration Manager (SCCM), or PowerShell, routes are defined in the XML file using the following syntax.

Client Configuration

Validate the routing configuration has been implemented on the endpoint successfully by running the following PowerShell command.

Get-VpnConnection -Name <Connection Name> | Select-Object -ExpandProperty Routes

As you can see here, the IPv4 routes and are included in the client’s Always On VPN configuration, as shown below.

Missing Route

However, after establishing an Always On VPN connection, the network is not reachable. To continue troubleshooting, run the following PowerShell command to view the active routing table.

Get-NetRoute -AddressFamily IPv4

As you can see above, the only IPv4 route in the VPN configuration added to the routing table is the network. The IPv4 route is missing.

Network Prefix Definition

IPv4 routes missing from the Always On VPN client’s routing table result from incorrect network prefix definition. Specifically, the IPv4 route used in the example here is not a valid network address. Rather, it is a host address in the network, as shown below.

The Get-Subnet PowerShell cmdlet is part of the Subnet PowerShell module. To install this module, run the following PowerShell command.

Install-Module Subnet


Using the example above, enabling access to the subnet would require defining the IPv4 prefix in the routing configuration as The moral of this story is always validate routing prefixes to ensure they are, in fact, network addresses and not host addresses.

Additional Information

Always On VPN Routing Configuration

Always On VPN Default Class-based Route and Microsoft Endpoint Manager/Intune