Always On VPN IKEv2 Policy Mismatch Error

Always On VPN IKEv2 Policy Mismatch ErrorThe Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice for Windows 10 Always On VPN deployments where the highest levels of security and assurance are required. However, as I’ve written about in the past, often the default IKEv2 security settings are less than desirable. Before using IKEv2 VPN in a production environment the administrator will need to update these security settings accordingly.

Connection Failure

When configuring Windows Server Routing and Remote Access Service (RRAS) or a third-party VPN appliance to support IKEv2 using custom security policies, the administrator may encounter a scenario in which a connection cannot be established due to a policy mismatch error. When the connection attempt fails, an error will be recorded in the Windows Application event log from the RasClient source with Event ID 20227. The error message states the following:

“The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 13868.”

Always On VPN IKEv2 Policy Mismatch Error

Error Code 13868

Error code 13868 translates to ERROR_IPSEC_IKE_POLICY_MATCH. Essentially this error indicates that the IKEv2 security policy on the client did not match the configuration on the server.

Server Configuration

To view the current IKEv2 IPsec policy configuration, open an elevated PowerShell command window and run the following command.

Get-VpnServerIPsecConfiguration

Always On VPN IKEv2 Policy Mismatch Error

Client Configuration

To ensure interoperability, the VPN client must be configured to use the same IKEv2 security policy as defined on the sever. To view a VPN client’s currently configured IKEv2 security policy, open an elevated PowerShell command window and run the following command.

Get-VpnConnection -Name [connection name] | Select-Object -ExpandProperty IPsecCustomPolicy

Always On VPN IKEv2 Policy Mismatch Error

Note: If this PowerShell command returns no output, the VPN connection is not using a custom IKEv2 IPsec security policy.

Updating Settings

Guidance for configuring IKEv2 security policies on Windows Server RRAS and Windows 10 can be found here.

Summary

IKEv2 policy mismatch errors can be resolved easily by ensuring both the VPN server and client are configured to use the same IPsec security policies. Use the PowerShell commands in the above referenced above to validate settings and make changes when necessary.

Additional Information

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Features and Limitations

Show-VpnConnectionIPsecConfiguration PowerShell script on Github

Set-IKEv2SecurityBaseline PowerShell script on Github

Deploying Always On VPN with Intune using Custom ProfileXML

Deploying Always On VPN with Intune using Custom ProfileXMLWhen deploying Windows 10 Always On VPN using Microsoft Intune, administrators have two choices for configuring VPN profiles. They can use the native Intune user interface (UI) or create and upload a custom ProfileXML. The method chosen will depend on which features and settings are required.

Microsoft Intune

Intune has an intuitive user interface (UI) that can be used to configure and deploy Always On VPN profiles to Windows 10 clients. Guidance for using the UI to deploy Windows 10 Always On VPN with Microsoft Intune can be found here. However, Intune does not expose all Always On VPN settings to the administrator, which can be problematic.

Missing from Intune

At the time of this writing, the following Always On VPN settings cannot be configured natively using the Intune UI.

To implement any of the above features or settings the administrator must create and upload a custom ProfileXML.

ProfileXML

ProfileXML is a node within the VPNv2 Configuration Service Provider (CSP). When configuring Always On VPN using the Intune UI, each setting is configured individually. By contrast, the ProfileXML node includes all Always On VPN settings in a single configuration file. It can be deployed using Intune or PowerShell. Sample ProfileXML files for both user and device tunnels can be downloaded from my GitHub repository.

ProfileXML and Intune

I’ve already documented how to deploy an Always On VPN device tunnel configuration using Intune, so this post will focus on deploying the user tunnel using ProfileXML.

Once ProfileXML has been configured, open the Intune management console and follow the steps below to deploy it using Intune.

Create Profile

1. In the navigation pane click Device Configuration.
2. Click Profiles.
3. Click Create Profile.
4. Enter a descriptive name for the new VPN profile.
5. Select Windows 10 and later from the Platform drop-down list.
6. Select Custom from the Profile type drop-down list.

Custom OMA-URI Settings

1. In the Custom OMA-URI Settings blade click Add.
2. Enter a descriptive name in the Name field (this name will appear in the Windows UI on the client).
3. Enter ./User/Vendor/MSFT/VPNv2/Always%20On%20VPN/ProfileXML in the OMA-URI field. I’ve used Always On VPN as an example here, but you can use any text you like. If it includes spaces they must be escaped using %20, as shown here. Also, don’t forget to include the leading “.“.
4. Select String (XML file) from the Data type drop-down list.
5. Click the folder next to the Select a file field and select your ProfileXML file.
6. Click Ok.

Deploying Always On VPN with Intune using Custom ProfileXML

Important Note: The File contents window must show the contents of your ProfileXML. If the contents are unreadable the XML file contains encoding that will not work. If this happens, copy the contents of your ProfileXML to another new text file and upload again.

Assign Profile

Follow the steps below to assign the Always On VPN profile to the appropriate user group.

1. Click Assignments.
2. Click Select groups to include.
3. Select the group that includes the target users.
4. Click Select.
5. Click Save.

Deploying Always On VPN with Intune using Custom ProfileXML

Demonstration Video

A demonstration video with guidance for deploying a Windows 10 Always On VPN user tunnel using the native Microsoft Intune UI as well as custom ProfileXML can be found here. The custom ProfileXML guidance starts at 7:52.

Additional Information

Deploying Windows 10 Always On VPN with Microsoft Intune

Deploying Windows 10 Always On VPN Device Tunnel using PowerShell

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN LockDown Mode

Windows 10 Always On VPN Scripts and Sample ProfileXML Files on GitHub

Always On VPN Device Tunnel and Certificate Revocation

Always On VPN Device Tunnel and Certificate RevocationRecently I wrote about denying access to Windows 10 Always On VPN users or computers. In that post I provided specific guidance for denying access to computers configured with the device tunnel. To summarize, the process involved exporting the device certificate from the issuing Certification Authority (CA) server and placing it in the Untrusted Certificates certificate store on each VPN server. In theory, simply revoking the device certificate should be all that’s required to prevent device tunnel connections.

Revocation Check Failure

As it turns out, a bug in Windows Server Routing and Remote Access prevents this from working as expected. Windows Server 2012 R2, 2016, and 2019 all fail to check the Certificate Revocation List (CRL) for IKEv2 VPN connections using machine certificate authentication (for example an Always On VPN device tunnel).

Update for Windows Server

Microsoft recently made a fix for this issue available for Windows Server 2016. It is included in the June 18, 2019 update KB4503294 (build 14393.3053). A fix for Windows Server 2019 is forthcoming. Windows Server 2012 R2 will not be updated. It is recommended that you upgrade to a later version of the Windows Server operating system to  address this issue.

Note: This fix is now available for Windows Server 1903 (semi-annual channel). It is included in the June 27, 2019 update KB4501375 (build 18362.207).

Enable Revocation Check

Additional configuration is required to enable support for CRL checking. Microsoft published guidance for configuring CRL revocation checks for IKEv2 VPN connections using machine certificate authentication here. Specifically, administrators must enable the RootCertificateNameToAccept parameter and set a registry key to enable this functionality.

Open an elevated PowerShell window and run the following commands to enable CRL checking for IKEv2 VPN connections using machine certificate authentication.

$Thumbprint = ‘Root CA Certificate Thumbprint’
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\’ -Name CertAuthFlags -PropertyTYpe DWORD -Value ‘4’ -Force

Restart-Service RemoteAccess -PassThru

Always On VPN Device Tunnel and Certificate Revocation

A PowerShell script to update the RootCertificateNameToAccept parameter on multiple VPN servers can be found here.

Revoking Certificates

To prevent a Windows 10 Always On VPN device tunnel connection, the administrator must first revoke the certificate on the issuing CA. Next, open an elevated command window an enter the following commands. Repeat these steps on each VPN server in the enterprise.

certutil -urlcache * delete
certutil -setreg chain\ChainCacheResyncFiletime @now

Additional Information

Denying Access to Windows 10 Always On VPN Users or Computers

Blocking VPN Clients that use Revoked Certificates

PowerShell Script to Configure RootCertificateNameToAccept on GitHub

 

 

Always On VPN Users Prompted for Certificate

Always On VPN Users Prompted for CertificateWhen deploying Windows 10 Always On VPN using Protected Extensible Authentication Protocol (PEAP) authentication with client certificates, administrators may find the VPN connection does not establish automatically. In this specific scenario the client is prompted to select a certificate to use to authenticate to the VPN server.

Always On VPN Users Prompted for Certificate

Multiple Certificates

This can occur when certificates from multiple Certification Authorities (CAs) are issued to the user that include the Client Authentication Enhanced Key Usage (EKU). When this happens, the user is forced to select the correct certificate to use for VPN authentication.

Clearly this is less than ideal, as it not only breaks the seamless and transparent nature of Always On VPN, the user may select the wrong certificate resulting in authentication failure. Ideally the client should be configured to select the correct certificate without user interaction.

Certificate Selection

Follow the steps below to configure automatic certificate selection for VPN authentication.

  1. On a VPN client, right-click the Always On VPN connection and choose Properties.
  2. Select the Security tab.
  3. In the Authentication section click Properties below Use Extensible Authentication Protocol (EAP).
  4. In the Select Authentication Method section click Configure.
  5. In the When connecting section click Advanced.
  6. Check the box next to Certificate Issuer.
  7. Select the root CA used to issue client authentication certificates for VPN authentication.
  8. Click Ok four times to save the configuration.

Always On VPN Users Prompted for Certificate

Once complete, export the EAP configuration to XML from the VPN client and paste the new settings in Intune or in your custom ProfileXML.

Certificate Purpose

By default, a client certificate requires only the Client Authentication EKU to establish a VPN connection. In some cases, this may not be desirable. For example, consider a deployment where Client Authentication certificates are issued to all users for Wi-Fi authentication. Depending on the Network Policy Server (NPS) configuration, these certificates may also be used to authenticate to the VPN.

VPN Specific Certificate

Follow the steps below to create a user authentication certificate template to be used exclusively for VPN authentication.

Certificate Template

  1. On the CA server, open the Certificate Templates management console (certtmpl.msc).
  2. Right-click the certificate template configured for VPN authentication and choose Properties.
  3. Select the Extension tab.
  4. Highlight Application Policies and click Edit.
  5. Click Add.
  6. Click New.
  7. Enter a descriptive name for the new application policy.
  8. Copy the Object identifier for later use and click Ok four times to save the configuration.

    Always On VPN Users Prompted for Certificate

  9. If certificate autoenrollment is configured and the certificate is already provisioned to users, right-click the certificate template and choose Reenroll All Certificate holders.

Client Configuration

  1. On the VPN client, follow the steps outlined previously to configure certificate selection.
  2. In addition to choosing a certificate issuer, select Extended Key Usage (EKU).
  3. Uncheck All Purpose.
  4. Select Client Authentication and the following EKUs.
  5. Click Add.
  6. Click Add once more.
  7. Enter the name of the custom EKU policy created previously.
  8. Enter the custom EKU object identifier copied previously from the custom policy.

    Always On VPN Users Prompted for Certificate

  9. Click Ok twice.
  10. Uncheck AnyPurpose and the following EKUs.
  11. Click Ok four times to save the configuration.

Always On VPN Users Prompted for Certificate

Once complete, export the EAP configuration to XML from the VPN client and paste the new settings in Intune or in your custom ProfileXML.

Additional Information

Windows 10 Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Get-EapConfiguration PowerShell Script on GitHub

Windows 10 Always On VPN Hands-On Training

Renew DirectAccess Self-Signed Certificates

Renew DirectAccess Self-Signed CertificatesImportant! Updated July 15, 2019 to support all versions of Windows Server including Windows Server 2012 and 2012 R2. Also added functionality to renew self-signed certificates individually.

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 and NLS scripts above are executed, DirectAccess clients outside will be immediately disconnected and will be unable to reconnect until they update group policy (the RADIUS encryption certificate can be updated without impacting users). This will require connecting to the internal network locally or remotely using another VPN solution. 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 Device Tunnel Configuration using Intune

Always On VPN Device Tunnel Configuration using IntuneA while back I described in detail how to configure a Windows 10 Always On VPN device tunnel connection using PowerShell. While using PowerShell is fine for local testing, it obviously doesn’t scale well. In theory you could deploy the PowerShell script and XML file using System Center Configuration Manager (SCCM), but using Microsoft Intune is the recommended and preferred deployment method. However, as of this writing Intune does not support device tunnel configuration natively. The administrator must create a ProfileXML manually and use Intune to deploy it.

Device Tunnel Prerequisites

I outlined the Always On VPN device tunnel prerequisites in my previous post here. To summarize, the client must be running Windows 10 Enterprise edition and be domain-joined. It must also have a certificate issued by the internal PKI with the Client Authentication EKU in the local computer certificate store.

ProfileXML

To begin, create a ProfileXML for the device tunnel that includes the required configuration settings and parameters for your deployment. You can find a sample Windows 10 Always On VPN device tunnel ProfileXML here.

Note: Be sure to define a custom IPsec policy in ProfileXML for the device tunnel. The default security settings for the IKEv2 protocol (required for the device tunnel) are quite poor. Details here.

Intune Deployment

Open the Intune management console and follow the steps below to deploy an Always On VPN device tunnel using Microsoft Intune.

Create Profile

1. Navigate to the Intune portal.
2. Click Device configuration.
3. Click Profiles.
4. Click Create profile.

Define Profile Settings

1. Enter a name for the VPN connection in the Name field.
2. Enter a description for the VPN connection in the Description field (optional).
3. Select Windows 10 and later from the Platform drop-down list.
4. Select Custom from the Profile type drop-down list.

Always On VPN Device Tunnel Configuration using Intune

Define Custom OMA-URI Settings

1. On the Custom OMA-URI Settings blade click Add.
2. Enter a name for the device tunnel in the Name field.
3. Enter a description for the VPN connection in the Description field (optional).
4. Enter the URI for the device tunnel in the OMA-URI field using the following syntax. If the profile name includes spaces they must be escaped, as shown here.

./Device/Vendor/MSFT/VPNv2/Example%20Profile%Name/ProfileXML

5. Select String (XML file) from the Data Type drop-down list.
6. Click the folder next to the Select a file field and chose the ProfileXML file created previously.
7. Click Ok twice and then click Create.

Always On VPN Device Tunnel Configuration using Intune

Assign Profile

Follow the steps below to assign the Always On VPN device tunnel profile to the appropriate device group.

1. Click Assignments.
2. Click Select groups to include.
3. Select the group that includes the Windows 10 client devices.
4. Click Select.
5. Click Save.

Always On VPN Device Tunnel Configuration using Intune

Demonstration Video

A video demonstration of the steps outlined above can be viewed here.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN IKEv2 Security Configuration

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Missing in the UI

Video: Deploying Windows 10 Always On VPN User Tunnel with Microsoft Intune

Always On VPN SSTP Connects then Disconnects

Always On VPN SSTP Connects then DisconnectsWhen Always On VPN clients are configured to use the Secure Socket Tunneling Protocol (SSTP) with Windows Server Routing and Remote Access Service (RRAS), administrators may encounter a scenario in which a client can establish a VPN connection using SSTP successfully, but is then disconnected immediately. The system event log contains an entry with Event ID 6 from the RasSstp source that includes the following error message.

“The SSTP-based VPN connection to the remote access server was terminated because of a security check failure. Security settings on the remote access server do not match settings on this computer. Contact the system administrator of the remote access server and relay the following information.”

Always On VPN Connect and Disconnect with SSTP

Common Causes

The two most common causes of this issue are when SSTP is configured for SSL offload, and when a VPN client is on a network where SSL inspection is taking place.

SSTP Offload

The most common cause of this issue is when SSL offload is configured for SSTP on an external load balancer or application delivery controller (ADC). To prevent interception from a Man-in-the-Middle attack, the VPN client sends the certificate hash of the SSL certificate used when the VPN connection was established. If this information does not match what is configured on the RRAS server, the connection is assumed to be compromised and the connection is immediately dropped.

SSL Inspection

Another scenario where this issue may occur is when a VPN client is behind a network device configured to perform SSL deep-packet inspection (DPI). SSTP VPN clients will be unable to connect to the VPN server in this scenario.

Resolution

When offloading SSL to another device, the RRAS server must be configured to know which SSL certificate is being presented to remote clients. This information is stored in the following registry key.

HKLM:\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters\SHA256CertificateHash

However, this registry entry requires a binary value, which makes it a challenge to configure manually. To resolve this problem, it is recommended that the same SSL certificate installed on the load balancer/ADC also be installed on the VPN server (even though SSL will be offloaded). To do this, first import the SSL certificate and private key in to the Local Computer certificate store, then open the RRAS management console and perform the following steps.

  1. Right-click the VPN server and choose Properties.
  2. Select the Security tab.
  3. Uncheck Use HTTP in the SSL Certificate Binding section.
  4. Select the appropriate SSL certificate from the Certificate drop-down list (click View to verify).
  5. Click Apply.

This will add the correct SSL certificate information to the registry. Next, re-enable HTTP for SSL offload by performing the following steps.

  1. Check Use HTTP in the SSL Certificate Binding section.
  2. Click Apply.

PowerShell Configuration

If the SSL certificate cannot be installed on the VPN server, or to automate this configuration across multiple servers remotely, download and run the Enable-SstpOffload PowerShell script from my GitHub repository here and run the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

For example…

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Additional Information

Windows 10 Always On VPN Load Balancing and SSL Offload

Windows 10 Always On VPN SSTP Load Balancing with F5 BIG-IP

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

 

Always On VPN ProfileXML Editing and Formatting with Visual Studio Code

Always On VPN ProfileXML Editing and Formatting with Visual Studio CodeWindows 10 Always On VPN is designed to be implemented and managed using a Mobile Device Management (MDM) platform such as Microsoft Intune. With Intune specifically, there is an option to configure an Always On VPN profile in the UI. However, it provides only limited support and does not include all settings and options required for many deployments. Crucially, IKEv2 advanced security settings cannot be configured using the Intune portal. Also, there is currently no option for configuring a device tunnel with Intune. In these scenarios the administrator must manually create a ProfileXML file and provision it using Intune, System Center Configuration Manager (SCCM), or PowerShell.

ProfileXML

ProfileXML includes all settings that define the Always On VPN connection. The options and settings available are documented in the VPNv2 Configuration Service Provider (CSP) reference on Microsoft’s web site. ProfileXML is formatted using elements and settings within those elements. The formatting and syntax are critical to ensuring proper operation. Any error in syntax or formatting can result in an error, such as those described here.

XML Readability

Formatting is also important for readability, which is often helpful when reviewing configuration settings or troubleshooting syntax errors. For example, an element may be defined correctly but may be nested wrong. Often XML files are created with all text being left-justified, or with everything on a single line, making the content difficult to read. Using a file editor that recognizes XML files can be beneficial.

Visual Studio Code

To create, edit, and review ProfileXML it is recommended that a proper editing tool be used. I recommend using Microsoft’s Visual Studio Code. It is free, and it is especially helpful when editing XML files. Visual Studio Code can be downloaded here.

XML Tools VS Code Plug-In

To further enhance Visual Studio Code’s XML editing and formatting capabilities I recommend installing the XML Tools plug-in. This tool extends the native features of VS code for handling XML files. One important thing it adds is a formatting feature that will make your ProfileXML much easier to manage. The XML Tools plug-in for VS Code can be downloaded here.

XML Formatting

Once the XML Tools plug-in for VS code has been installed, formatting XML for readability is straightforward. Simply right-click anywhere in the document and choose Format Document.

Always On VPN ProfileXML Editing and Formatting with Visual Studio CodeOnce complete, the XML document will be formatted with proper indenting and nesting of elements, as shown here.

Always On VPN ProfileXML Editing and Formatting with Visual Studio CodeSummary

Formatting and syntax must be strictly adhered to when creating a ProfileXML file for Windows 10 Always On VPN. Using Visual Studio Code with the XML Tools plug-in allow the administrator to create and edit XML with proper formatting, which greatly improves readability and allows for streamlined configuration review and troubleshooting.

Acknowledgements

Special thanks to Colin, an avid reader of the articles on this web site for this tip. Thanks, Colin! 🙂

Additional Information

Always On VPN and DirectAccess Scripts and Sample Files on GitHub

Always On VPN IKEv2 Security Configuration

Always On VPN Device Tunnel Step-by-Step Configuration using PowerShell

Always On VPN Hands-On Training Classes in 2019

Always On VPN Unable to Create Profile General Error

Always On VPN Unable to Create Profile General ErrorWhen configuring a Windows 10 Always On VPN profile connection using the Microsoft-provided MakeProfile.ps1 PowerShell script or my PowerShell Always On VPN deployment script, the creation of a new connection may fail and 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.

Always On VPN Unable to Create Profile General Error

This error message is, of course, terribly ambiguous and provides no real actionable information for the administrator to resolve the problem with. This makes troubleshooting this error somewhat challenging.

Probable Cause

In my experience, this error message is almost always related to a syntax error in ProfileXML. For example, to generate the error message above, my XML file included the following error.

Always On VPN Unable to Create Profile General Error

In this example, the setting should be True or False. The setting “foo” is unrecognized and causes the ambiguous error message. It can also happen if mutually exclusive configuration settings are defined. For example, it can occur if the DisableClassBasedDefaultRoutes element is set to true when the RoutingPolicyType element is set to ForceTunneling.

Error Resolution

The only way to resolve this error is to ensure there are no configuration errors for any defined elements in ProfileXML. Review the file carefully for errors such as typos or elements that are out of place. Refer to the VPNv2 Configuration Service Provider (CSP) ProfileXML XSD for detailed syntax examples. In addition, I have some sample ProfileXML configuration files that can be used for reference on my GitHub page.

XML Format Validation

To ensure ProfileXML is properly formatted, it is recommended that an XML editor be used when generating or editing the configuration file. This will ensure that all defined elements are well-formed, and that all tags are properly closed. Use caution though, because some XML editors (including some popular online formatting tools) will insert XML version and encoding information at the beginning of the file. This information must be removed from ProfileXML prior to deployment.

Additional Information

Windows 10 VPNv2 Configuration Service Provider (CSP) Reference

Windows 10 VPNv2 Configuration Service Provider (CSP) ProfileXML XSD Native Profile Examples

Windows 10 Always On VPN PowerShell Scripts and Sample ProfileXML Configuration Files on GitHub

Free Online XML Formatter

Windows 10 Always On VPN Hands-On Training Classes for 2019

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: