Removing Always On VPN Connections

Removing Always On VPN ConnectionsMuch has been written about provisioning Windows 10 Always On VPN client connections over the past few years. While the preferred method for deploying Always On VPN is Microsoft Intune, using PowerShell is often helpful for initial testing, and required for production deployment with System Center Configuration Manager (SCCM) or Microsoft Endpoint Manager (MEM). That said, there will invariably come a time when an administrator has to remove an Always On VPN connection. It is not as simple as you might think.

Important Note! The PowerShell script mentioned in this post is broken in Windows 11 and some later versions of Windows 10. This is due to an apparent bug whereby the MDM_VPNv2_01 WMI class can’t be enumerated. Microsoft is aware of the issue and hopefully it will be resolved in the near future.

PowerShell

There are a variety of ways to remove an existing Always On VPN connection, with the quickest and simplest being PowerShell and the Remove-VpnConnection cmdlet.

Get-VpnConnection -Name ‘Always On VPN’ | Remove-VpnConnection -Force

There are several limitations to this method, however.

Active Connections

Administrators will quickly realize that PowerShell fails to remove a VPN connection that is currently connected. As shown here, attempting to remove an active VPN connection will return the following error message.

“The VPN connection [connection name] cannot be removed from the local user connections. Cannot delete a connection while it is connected.”

Removing Always On VPN Connections

Registry Artifacts

Removing Always On VPN connections using PowerShell commonly leaves behind registry artifacts that can potentially cause problems. For example, there are several Always On VPN-related registry entries in several locations including the HKLM\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked hive that may not be deleted when removing an Always On VPN connection. When provisioning a new Always On VPN connection after deleting one with the same name previously, the administrator may encounter the following error message.

“Unable to create [connection name] profile: A general error occurred that is not covered by a more specific error code.”

Removing Always On VPN Connections

Note: This error can also be caused by improperly formatted XML configuration files. More details here.

Remove-AovpnConnection Script

Veteran Always On VPN administrators are likely familiar with PowerShell scripts I’ve created called New-AovpnConneciton.ps1 and New-AovpnDeviceConnection.ps1, which are hosted on my GitHub. These scripts are adapted from code samples published by Microsoft to which I have included additional functionality. To address the limitations highlighted in this article I have published a new PowerShell script called Remove-AovpnConnection.ps1. It will remove any Always On VPN connection, even those that are currently active. It also includes logic to remove known registry artifacts common to Always On VPN. Download the script from GitHub and use the following syntax to remove an Always On VPN connection, established or not.

.\Remove-AovpnConnection.ps1 -ProfileName [connection name]

Running this PowerShell command will forcibly remove an Always On VPN connection. Use the -DeviceTunnel switch when removing a device tunnel connection (requires running in the system context). I have also included a -CleanUpOnly switch to remove registry artifacts when the VPN connection was previously removed using another method.

Updated Installation Scripts

I have also updated New-AovpnConnection.ps1 to include these registry clean up steps. This will prevent future errors when provisioning an Always On VPN client where a connection of the same name was removed previously.

Note: New-AovpnConnection.ps1 has also been updated to support device tunnel deployments. As such, I have deprecated New-AovpnDeviceConnection.ps1. Simply use New-AovpnConnection.ps1 with the -DeviceTunnel switch to deploy an Always On VPN device tunnel.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Troubleshooting Always On VPN Unable to Create Profile General Error

Renew DirectAccess Self-Signed Certificates

Renew DirectAccess Self-Signed CertificatesImportant! Updated April 29, 2020 to resolve an issue where the DirectAccess RADIUS encryption certificate was not published to the DirectAccess Server Settings GPO in Active Directory.

When DirectAccess is deployed using the Getting Started Wizard (GSW), sometimes referred to as the “simplified deployment” method, self-signed certificates are created during the installation and used for the IP-HTTPS IPv6 transition technology, the Network Location Server (NLS), and for RADIUS secret encryption. Administrators may also selectively choose to use self-signed certificates for IP-HTTPS, or when collocating the NLS on the DirectAccess server. The RADIUS encryption certificate is always self-signed.

Renew DirectAccess Self-Signed Certificates

Certificate Expiration

These self-signed certificates expire 5 years after they are created, which means many DirectAccess administrators who have used this deployment option will need to renew these certificates at some point in the future. Unfortunately, there’s no published guidance from Microsoft on how to accomplish this. However, the process is simple enough using PowerShell and the New-SelfSignedCertificate cmdlet.

PowerShell Script on GitHub

The PowerShell script to renew DirectAccess self-signed certificates has been published on GitHub. You can download Renew-DaSelfSignedCertificates.ps1 here.

Important Considerations

When the IP-HTTPS certificate is renewed using this script, DirectAccess clients outside will be immediately disconnected and will be unable to reconnect until they update group policy. This will require connecting to the internal network locally or remotely using another VPN solution. The NLS and RADIUS encryption certificates can be updated without impacting remote users.

In addition, internal clients that are not online when this change is made will be unable to access internal resources by name until they update group policy. If this happens, delete the Name Resolution Policy Table (NRPT) on the client using the following PowerShell command and reboot to restore connectivity.

Get-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig” | Remove-Item -Confirm:$false

Additional Information

PowerShell Recommended Reading for DirectAccess Administrators

Top 5 DirectAccess Troubleshooting PowerShell Commands

 

 

Always On VPN and DirectAccess Scripts and Sample Files on GitHub

Always On VPN and DirectAccess Scripts and Sample Files on GitHubIf you’re looking for specialized configuration scripts for Windows 10 Always On VPN, Windows Server Routing and Remote Access Service (RRAS), or DirectAccess then have a look at my GitHub page! There I’ve uploaded a few tools I’ve created (with the help of my good friend Jeff Hicks!) along with some sample ProfileXML files. Here’s a sample of what you’ll find there today.

Always On VPN

This repository includes PowerShell scripts and sample ProfileXML files used for configuring Windows 10 Always On VPN. These scripts have been adopted from those provided by Microsoft and modified to work with a separate XML file. These scripts can be used for local testing and for deploying Always On VPN connections using System Center Configuration Manager (SCCM). The ProfileXML files can be helpful for those administrators looking for real world configuration examples.

https://github.com/richardhicks/aovpn

SstpOffload

This repository includes a PowerShell script to enable TLS offload for Windows Server RRAS Secure Socket Tunneling Protocol (SSTP) VPN connections when the public SSL certificate can’t be installed on the RRAS server. TLS offload for SSTP can be enabled in scenarios where better security, performance, and scalability are desired.

https://github.com/richardhicks/sstpoffload

DirectAccess

This repository includes the PowerShell script Move-DaInboxAccountingDatabase which can be used to move the DirectAccess inbox accounting database files. The default location of the database files is on the C: drive, and many administrators have encountered disk space issues, especially in large scale deployments. This script will relocate the database files to the location of your choice.

https://github.com/richardhicks/directaccess

More to Come!

Be sure to check my GitHub site for more PowerShell script and sample files on a regular basis. Or better yet, give me a follow! I’ll be sure to post more as time goes on. In addition, I’ll be going through my older articles where I’ve provided PowerShell code samples and will include them in the repository too.

Standard Disclaimer

All the sample files and PowerShell scripts I’ve shared on GitHub are provided as-is. Although they’ve been thoroughly tested, I can’t be certain I’ve accommodated every deployment scenario. Please use caution when running these scripts on production machines.

Additional Information

Always On VPN Hands-On Training Classes 2019

Jeff Hicks’ Blog

%d bloggers like this: