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.

Workarounds

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

Intune

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.

PowerShell

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.

PowerON DPC

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 DPC Demonstration

Recently I wrote about PowerON Platforms’ Always On VPN Dynamic Profile Configurator (DPC). This software solution enables administrators to natively provision and manage Always On VPN client configuration settings using Active Directory and group policy. In that post, I provided some high-level details about the product, along with a brief overview of its advanced features.

Demonstration Video

I have recorded a video demonstrating how to install and configure Always On VPN DPC and use its basic features. You will find that demonstration video here.

Advanced Features

Soon I will share more details about Always On VPN DPC and using its advanced capabilities to solve some common challenges faced by Always On VPN administrators. Stay tuned!

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 aovpndpc.com to register for an evaluation license.

Additional Information

Always On VPN with Active Directory Group Policy

Always On VPN Dynamic Profile Configurator (DPC)

Windows Clients Do Not Receive DirectAccess Configuration Changes

Windows Clients Do Not Receive DirectAccess Configuration Changes

A scenario can occur in which changes to the DirectAccess configuration made using the Remote Access Management console or at the command line using PowerShell are not reflected on the DirectAccess client, even after receiving the latest group policy updates. The issue occurs for DirectAccess clients that are provisioned with the Offline Domain Join (ODJ, or djoin.exe) tool.

When the ODJ provisioning package is initially created, it does not add the new computer account to the DirectAccess security group. The ODJ-provisioned client receives all DirectAccess configuration settings at the time of provisioning, but it will not receive subsequent changes to the DirectAccess configuration made after it was originally provisioned.

To resolve this issue, be sure to proactively add the DirectAccess client’s computer account to the appropriate DirectAccess security group in Active Directory after provisioning with ODJ using Active Directory Users and Computers (ADUC), the Active Directory Administrative Center (ADAC), or by executing the following PowerShell command:

Add-ADGroupMember -Identity [DirectAccess Client Security Group] -Members [computername]

Once the DirectAccess client has been added to the security group and restarted, it will then receive DirectAccess configuration settings changes going forward.