What’s New in Always On VPN DPC v5.4.0

A new edition of the popular Always On VPN Dynamic Profile Configurator (DPC) is now available. Version 5.4.0, released on May 5, 2026, includes some new features, reliability improvements, and additional miscellaneous fixes.

What’s New in DPC v5.4.0

The following new features and improvements are included in the latest release of DPC.

Signed Binaries

Beginning with release v5.4.0, all binaries, including the installer, are digitally signed. This streamlines the installation process and allows DPC to better integrate with application controls.

EAP-TLS

By popular demand, EAP-TLS support has been added as an authentication option in DPC. Historically, DPC strictly adhered to security best practices and only allowed Protected EAP (PEAP). However, many administrators required EAP-TLS to better integrate with non-Microsoft VPN services.

Additional Enhancements

Other changes include better profile change comparison and a new logo. In addition, the DPC ADMX files are now publicly accessible on ADMScope.

Summary

Administrators running earlier versions of DPC are encouraged to upgrade to v5.4.0 as soon as possible.

Additional Information

Always On VPN DPC v5.4.0 on GitHub

Midwest Management Summit (MMSMOA) 2026

I’m excited to be presenting two sessions at the upcoming Midwest Management Summit at Mall of America (MMSMOA), taking place May 3-7, 2026, at the Radisson Blu in Bloomington, MN. This is the premier systems management event in the U.S., offering unrivaled access to Microsoft and industry professionals from around the world.

Cloud PKI for Intune

My first session, Zero to Certificates in 5 Minutes with Cloud PKI for Microsoft Intune, covers how to quickly configure and deploy certificates using Cloud PKI for Microsoft Intune. This session is ideal for anyone looking to streamline certificate management without the traditional heavy infrastructure burden.

Entra Private Access

My second session, Moving to Zero Trust: Entra Private Access for Always On VPN Administrators, explores the transition from traditional Always On VPN to Microsoft’s Entra Private Access, highlighting practical steps, architectural differences, and the benefits of maintaining secure access in a modern Zero Trust environment. I will also share important migration tips, tricks, and best practices.

Let’s Connect!

Looking forward to diving into these topics with everyone there. I hope to see some familiar faces and meet new ones, too! If you are attending the event, be sure to say hello!

Additional Information

Midwest Management Summit at Mall of America (MMSMOA)

Cloud PKI for Microsoft Intune on RunAs Radio

Microsoft Entra Private Access on RunAs Radio

The Myth of the Publish Certificate in Active Directory Setting

Certificate templates in Microsoft Active Directory Certificate Services (AD CS) provide powerful, preconfigured settings that enable administrators to issue certificates tailored for specific purposes. For example, a certificate template could allow a user to authenticate to a Wi-Fi network or VPN gateway. Another template might control policies for enrolling for web server certificates in the enterprise. Templates define settings such as cryptographic parameters (key algorithm and length), validity period, application policies, enrollment requirements, and more. While there are myriad settings to choose from, one in particular is often enabled unnecessarily. And while it works without issue, there can be some hidden downsides to enabling this setting.

Publish Certificate in Active Directory

When creating a certificate template, there’s an option on the General tab called Publish certificate in Active Directory. From experience, this is one of the most misunderstood settings for certificate templates.

Certificate template General tab with the Publish certificate in Active Directory option

Intuitively, it would make sense to check this box on all published certificate templates. After all, I want the users or devices targeted by this certificate template to find them in Active Directory (AD) so they can enroll. Many administrators believe that enabling this setting is required to ‘see’ the published certificate template on the endpoint, as shown here.

Active Directory Users and Computers Published Certificates tab listing certificates published for a user

However, enabling the Publish certificate in Active Directory option is not required for enrollment. To ‘see’ certificates available for enrollment, the user or device must only have the Enroll permission on the template.

What Is It For?

So, what does the Publish certificate in Active Directory setting do? When this option is enabled, the issuing CA adds the certificate to the requesting principal’s Active Directory account. There are two common scenarios where this is required.

S/MIME

Adding a user’s certificate to their AD account makes the public key centrally discoverable, allowing Outlook and other S/MIME-enabled clients to automatically find recipients’ certificates for secure email encryption and signature validation. Without the certificate published in AD, users must manually exchange certificates, breaking seamless S/MIME encryption in most enterprise environments.

Encrypting File System (EFS)

Publishing a user’s EFS certificate to their Active Directory account allows Windows to locate the correct public key automatically when encrypting files. It ensures recovery agents and key archival processes function properly. Without the certificate in AD, EFS can fail to encrypt data consistently across machines or prevent access to encrypted files when users roam or recover profiles.

Drawbacks

There are very few scenarios outside of S/MIME and EFS that require the Publish certificate in Active Directory option to be enabled. However, enabling it doesn’t necessarily break anything, and this setting is often enabled by default (or carried over from the source template when duplicating), so administrators may miss this option. Issuing certificates in this way introduces some potential problems.

AD Database Bloat

Adding a certificate to each principal’s AD object increases the size of each object, thereby increasing the total size of the AD database. For organizations with large directories with hundreds of thousands or even millions of accounts, adding unnecessary data to each account can be very expensive in terms of database size, replication traffic, backup storage, and overall domain performance. Making matters worse, certificates published to AD live perpetually. They are not removed automatically when certificates are revoked or expire.

Service Accounts

Service accounts used for certificate enrollment, such as the Microsoft Intune Certificate connector, can be especially challenging. Here, if the Publish certificate in Active Directory setting is enabled on the Intune certificate template, the CA will add a certificate to the service account for every certificate it issues. While you can have many certificates associated with a single account, there is an upper limit, approximately 1250, based on my testing. After that, certificates will continue to be issued, but adding them to AD will fail.

Remediation

The following recommendations can help administrators correct this misconfiguration and limit its impact in their environment.

Disable Unnecessary Certificate Publishing

Administrators should clear the Publish certificate in Active Directory setting on all certificate templates that do not explicitly require it, such as those used for S/MIME or Encrypting File System (EFS). This prevents new certificates from being written to user or computer objects and does not require certificates to be reissued.

Remove Published Certificates

Administrators can remove unnecessary certificates from user, computer, and service account objects in AD to reduce object and overall AD database sizes. Perform the following steps to remove unneeded certificates.

  1. Open the Active Directory Users and Computers management console (dsa.msc) and double-click the target principal.
  2. Select the Published Certificates tab.
  3. Select a certificate (or all certificates) and click Remove.
Removing published certificates from the Published Certificates tab in Active Directory Users and Computers

Important Note: Use extreme caution when deleting certificates! Do not delete any certificates unless you are certain they are not required.

Managed Service Accounts

Managed Service Accounts in AD do not have a Published Certificates tab. Administrators can use the Attribute Editor to remove individual certificates from the userCertificate attribute on the account.

Attribute Editor for a managed service account showing the userCertificate attribute

Managed Service Account Attribute Editor

userCertificate attribute entries for a managed service account

Managed Service Account userCertificate Entries

Unfortunately, there is no option to view the certificate in the UI for Managed Service Accounts. To view detailed certificate information, see the PowerShell section below.

Existing Certificates Are Not Removed Automatically

Disabling the Publish certificate in Active Directory setting only stops future certificates from being published in AD. Certificates already written to Active Directory are never removed automatically, even after they expire or are revoked. In environments where this setting has been enabled for an extended period, large numbers of stale certificates often accumulate and continue to increase the AD database size.

Intune Certificate Connector Considerations

This issue is especially problematic for high-volume enrollment scenarios that use service accounts, such as the Microsoft Intune Certificate Connector. When publishing is enabled for Intune certificate templates, certificates issued on behalf of users are added to the service account, quickly leading to excessive certificate accumulation and potential attribute limits.

ADPrincipalCertificate PowerShell Module

Manually performing this cleanup at scale is impractical. To assist administrators with cleaning up unnecessarily published certificates, I’ve created the ADPrincipalCertificate PowerShell module. This module includes functions to enumerate AD accounts that include certificates, show and optionally export certificates for AD accounts, and remove published certificates. The module also includes a function to enumerate published certificate templates that include the Publish certificate in Active Directory option enabled. You can install the ADPrincipalCertificate PowerShell module from the PowerShell gallery by running the following command.

Install-Module -Name ADPrincipalCertificate -Scope CurrentUser

See the ADPrincipalCertificate GitHub repository for detailed usage information.

Summary

While the Publish certificate in Active Directory option is helpful for S/MIME and EFS deployments, it is unnecessary for most other scenarios and is often enabled when it isn’t needed. This results in the unnecessary addition of certificates to AD accounts, causing individual objects and the entire AD database to grow without benefit. Sadly, many vendor guides indicate that this setting is required when it often isn’t, so many environments suffer from this misconfiguration. Administrators should review the certificate template configuration and disable this setting when it isn’t needed. Additionally, use the ADPrincipalCertificate PowerShell module to perform cleanup, if required.

Additional Information

Enterprise PKI with Microsoft Active Directory Certificate Services

ADPrincipalCertificate PowerShell Module on GitHub

ADPrincipalCertificate PowerShell Module in the PowerShell Gallery

Windows Server 2016 End of Life January 2027: Plan Your AD CS Migration Now

Happy New Year, everyone! As the calendar rolls over to 2026, it’s time to start planning the migration of workloads hosted on Windows Server 2016. Mainstream support ended for Windows Server 2016 on January 11, 2022, after which it entered extended support. However, extended support for Windows Server 2016 ends on January 12, 2027, at which point it will be end of life and no longer supported. Running production workloads on Windows Server 2016 beyond this date exposes organizations to significant security risk, as it no longer receives security updates, leaving these systems vulnerable to exploits.

Active Directory Certificate Services

Many organizations are still running critical infrastructure on Windows Server 2016. Administrators often delay upgrading Microsoft Active Directory Certificate Services (AD CS) due to its complexity. However, a well-planned AD CS migration not only reduces risk but also provides an opportunity to modernize cryptography, certificate templates, and operational practices.

Certificate Authorities

Administrators must carefully migrate Certificate Authorities (CAs) running on Windows Server 2016 to minimize downtime. In environments where ongoing CA maintenance has been limited, migrating the CA database can be especially challenging. If the CA is installed on a domain controller, now is a good time to consider separating these services to ensure reliable operation. Also, it’s a good idea to evaluate the CA’s configuration and security posture during migration to enhance security and improve service resilience.

NDES Servers

Microsoft Network Device Enrollment Services (NDES) servers, commonly deployed to facilitate certificate enrollment via Microsoft Intune, pose a unique challenge during migration. Unfortunately, configuring NDES is exceedingly complex and error-prone. NDES relies on a delicate combination of specialized IIS configuration, AD service accounts, custom certificate templates, and CA permissions, making even minor changes risky without proper planning. Not surprisingly, administrators are often hesitant to touch these systems as they are notoriously difficult to troubleshoot when problems arise.

Pro Tip: We spend an entire day covering NDES configuration in the Mastering Enterprise PKI Certificates with Microsoft Intune training course. The next session is March 10-12, 2026. Register now!

Intune Certificate Connectors

Don’t overlook Windows Server 2016 servers with the Intune Certificate Connector installed. Fortunately, this is one of the more manageable workloads to migrate. All that’s required is to install new connectors on supported servers and delete the old ones.

Summary

With extended support for Windows Server 2016 ending on January 12, 2027, organizations running production workloads—especially critical infrastructure such as Active Directory Certificate Services (AD CS), Certificate Authorities (CAs), and NDES servers—face significant security risks from unpatched vulnerabilities once the OS reaches end-of-life. Careful migration planning to newer versions such as Windows Server 2022 or 2025 is essential to minimize downtime, improve security posture, and ensure long-term resilience.

Start Planning Now

Don’t leave these mission-critical infrastructure services to the last minute! Begin planning your migration today. If you’d like expert guidance, I have many years of experience migrating these workloads. I have developed specialized tools and techniques to ensure a smooth, secure, and successful transition. Fill out the form below to schedule a free one-hour consultation to assess your Windows Server 2016 AD CS workloads, identify migration risks, and outline next steps.

Additional Information

Windows Server 2016 Lifecycle Policy

PKI Fundamentals with Microsoft Active Directory Certificate Services (AD CS) Online Training Course

Mastering Enterprise PKI Certificates with Microsoft Intune Online Training Course

Resolving PKCS Certificate Mapping Issues in Windows Autopilot Hybrid Join Deployments

Microsoft Windows Autopilot streamlines device provisioning through Intune, allowing IT administrators to preconfigure new Windows devices with minimal hands-on effort. However, when combined with Hybrid Entra Join and PKCS certificate deployment, specific challenges arise—particularly with certificate mapping and authentication.

Hybrid Entra Join

During autopilot provisioning, administrators may also choose to join the device to their on-premises Active Directory domain, a deployment model called Hybrid Entra join. Hybrid Entra join presents some unique challenges when using Autopilot to remotely provision devices. Specifically, the user must have connectivity to a domain controller to perform the first logon, as they do not have a user profile on the endpoint.

Device Tunnel

To support offline Hybrid Entra join during Autopilot provisioning, administrators can deploy the Always On VPN device tunnel to provide pre-logon connectivity to domain controllers. A device tunnel connection enables users to log on to their newly provisioned device remotely.

Requirements

The following prerequisites must be met to support the Always On VPN device tunnel.

  • The endpoint must be running Windows Enterprise edition.
  • An Always On VPN device tunnel profile must be assigned to the device.
  • A machine certificate must be deployed to the endpoint that includes the Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2).

Note: If you plan to use the subscription step-up upgrade from Windows Professional to Windows Enterprise, the device tunnel will not connect automatically after provisioning is complete, which prevents the user from logging in. More details and a workaround for this issue can be found here.

Strong Certificate Mapping

Microsoft knowledge base article KB5014754, released in May of 2022, introduced changes to domain controllers to require strong certificate mapping when using certificates to authenticate to Active Directory (AD). It was initially deployed in compatibility mode, only warning administrators when certificates are used for authentication that aren’t strongly mapped. However, full enforcement is mandatory beginning with the September 2025 security updates. This requirement introduces some challenges when issuing certificates to the device using PKCS during Autopilot provisioning.

Intune PKCS Certificates

When using PKCS certificates and the Intune Certificate Connector, the endpoint’s on-premises AD security identifier (SID) is not added to the issued certificate during Autopilot. Interestingly, this does not happen when using SCEP certificates. If the device certificate is not strongly mapped, the Always On VPN device tunnel will still authenticate successfully because Always On VPN does not use AD to authenticate device connections. Instead, Always On VPN simply verifies the certificate (e.g., that it is not expired or revoked) and allows authentication if the certificate passes the validation.

However, enterprise Wi-Fi access may fail without strongly mapped certificates if device authentication is required. Also, there may be other scenarios where a device authentication certificate without strong mapping may cause authentication to fail.

Workarounds

There are a few ways to work around this limitation. Consider the following options.

Native Entra ID Join

The simplest way to avoid the challenges of PKCS certificates and Hybrid Entra join is to avoid it altogether in favor of native Entra join. However, this may not be an option for everyone.

Use SCEP

For some reason, certificates issued with SCEP do not suffer from this limitation. In my testing, SCEP certificates are always strongly mapped. However, deploying SCEP certificates is much more complex than using PKCS. (Pro tip: Cloud PKI for Intune uses SCEP and requires no configuration! It’s definitely something to consider.)

Short-Lived Certificates

Another option is to deploy temporary, short-lived certificates (valid for only a few days) using PKCS to ensure the Always On VPN device tunnel works, and then deploy a permanent, long-term certificate post-deployment that includes the strong mapping. To do this, administrators can leverage dynamic group assignments in Intune. For example, the administrator can assign the short-lived certificate to an Autopilot Provisioning devices group and later assign a long-term certificate to the Hybrid Joined devices group.

Here’s an example of the dynamic group membership configuration.

Autopilot Provisioning Devices:

(device.devicePhysicalIDs -any (_ -contains “[ZTDId]”)) -and (device.deviceTrustType -ne “ServerAD”)

Hybrid Entra Join Devices:

(device.deviceTrustType -eq “ServerAD”)

In this configuration, the initial PKCS certificate is deployed without the strong mapping when the endpoint is enrolled to Autopilot but has not yet joined the domain. During this time, the endpoint will only be a member of the Autopilot Provisioning Devices group and will receive the short-lived, temporary certificate. Later, once the endpoint has successfully joined the domain, the device will move from the provisioning group to the Hybrid Entra Join Devices group. When this happens, a permanent, strongly mapped long-term certificate is enrolled on the device.

Manual Certificate Mapping

Certificates can be manually mapped via the altSecurityIdentities property of the computer object in AD. Obviously, this doesn’t scale well, so my good friend Steve Prentice published a PowerShell script to automate this process. You can find more details and the script here.

Summary

Windows Autopilot streamlines device provisioning with Intune, but Hybrid Entra Join introduces challenges when PKCS certificates lack strong mapping during initial deployment, potentially disrupting VPN and Wi-Fi authentication. Administrators can avoid this by switching to native Entra join or by using workarounds such as switching to SCEP, using short-lived certificates, or manually mapping certificates.

Additional Information

KB5014754 – Certificate-based authentication changes on Windows domain controllers

How To: Map a user to a certificate via all methods available in the altSecurityIdentities attribute

Hybrid Autopilot: Automating altSecurityIdentities

Configure Microsoft Entra hybrid join

Overview: Cloud PKI for Microsoft Intune

Entra Private Access Channels Are Unreachable

Administrators deploying Microsoft Entra Private Access may encounter a scenario in which the Global Secure Access (GSA) agent reports an error. However, the client continues to work without issue, and all internal resources remain reachable via the Entra Private Access connection. This issue occurs only when the Private Access forwarding profile is enabled alone. It does not happen if the Microsoft traffic forwarding profile is also enabled.

GSA Status Error

When this happens, the Private access channel status is Connected, but the Entra access channel is Disconnected. Also, you will see the following error message when clicking on the GSA client in the notification area.

Some channels are unreachable

Global Secure Access has some channels that are unreachable

Health Check

To investigate further, click the Troubleshooting tab, then click Run tool in the Advanced diagnostics tool section. In the Health check section, you will see the following error message.

Diagnostic URLs were not found in forwarding policy

Scrolling down the list also reveals the following error messages.

Magic IP received = False

Tunneling succeeded Entra Authentication = False

Root Cause

Several months ago, Microsoft made changes to the health check probes that required enabling the Microsoft traffic forwarding profile to work. Some essential health-check probes were not accessible via the Private Access channel, resulting in the error messages shown above when only the Private Access forwarding profile is enabled.

Resolution

Microsoft is rolling out changes to address this issue at the time of this writing (late October 2025). If you encounter this error, it will most likely resolve itself soon. Alternatively, administrators can enable the Microsoft traffic forwarding profile, which will also fix this issue.

Additional Information

Microsoft Entra Private Access

Microsoft Entra Global Secure Access (GSA)

Microsoft Security Service Edge (SSE) Now Generally Available

Microsoft Entra Security Service Edge (SSE) on RunAs Radio

Certificate Connector for Microsoft Intune Agent Certificate Renewal Failure

The Certificate Connector for Microsoft Intune is a vital component that allows administrators to issue and manage enterprise PKI certificates to endpoints managed by Microsoft Intune. The connector is installed on a Windows server with access to the on-premises Certificate Authority (CA). It is registered with Intune and can be used by any PKCS or SCEP device configuration profiles defined by Intune administrators.

Agent Certificate

When you install the Certificate Connector for Intune, a certificate issued by the Microsoft Intune ImportPFX Connector CA is automatically enrolled into the local computer certificate store of the server where the connector is installed. This certificate authenticates the connector to Intune and is valid for one year from the date of issuance. This certificate is automatically renewed in most cases. However, some configurations prevent this from happening.

Failed To Renew

Administrators may find event log errors with event ID 2 from the CertificateConnectors source in the Microsoft-Intune-CertificateConnectors operational event log with the following information.

Pki Create Service:

Failed to renew agent certificate

System.Security.Cryptography.CryptographicException: Access is denied.

Root Cause

Agent certificate renewal fails when the Certificate Connector for Intune is running under a service account that is not a member of the local administrators security group. You will not encounter this error if the connector services are running in the SYSTEM context, however.

Resolution

There are a few different ways to resolve this issue. Here are some options to consider.

Grant Admin Rights

Adding the service account under which the connector service runs will allow the agent certificate to renew automatically. However, this may not be desirable from a security perspective. To address this, administrators may temporarily grant local administrative access to renew the agent certificate, then revoke this permission once the certificate has been successfully renewed. However, this is a manual process that doesn’t scale well and requires annual administrative intervention.

Reinstall

Uninstalling and reinstalling the Certificate Connector for Intune will force a new certificate enrollment during the registration process. You can delete the old certificate after completing the installation.

Switch to SYSTEM

Changing from a service account to SYSTEM will also resolve this issue. However, it is not recommended to make these changes directly on the services themselves. Instead, administrators should remove and reinstall the Certificate Connector for Intune, selecting the SYSTEM option rather than the service account method.

Note: Using the SYSTEM account for the Certificate Connector for Intune should be avoided when using PKCS. Details here.

Summary

The Certificate Connector for Intune agent certificate renewal fails when the service is configured to run as a service account without local administrative rights. The best way to resolve this is to add the service account to the local administrators group on the server where the connector is installed. However, this isn’t always ideal. Although running the connector in the SYSTEM context is acceptable when using SCEP, it should be avoided when using PKCS. Administrators will have to accept the risk of the service account having local administrative rights or accept that they’ll have to reinstall the connector annually.

Additional Information

Certificate Connector for Intune Service Account and PKCS

Strong Certificate Mapping for Intune PKCS and SCEP Certificates

Intune Strong Certificate Mapping Error

Intune PKCS and SCEP Certificate Validity Period

Certificate Connector for Intune Failure

Certificate Connector for Intune Configuration Failed

Troubleshooting Intune Failed PKCS Request

Always On VPN DPC Commercial Support

The Always On VPN Dynamic Profile Configurator (DPC) is a free, open-source solution that helps administrators deploy and manage Always On VPN client configuration settings using Active Directory, Group Policy, or Microsoft Intune. Since version 5.0, DPC has been publicly available and widely adopted. Until now, support has been limited to the community Discord channel. Many organizations, however, require formal support before they can deploy software, even open-source solutions. To meet this need, Leo D’Arcy and I are now offering a commercial support option for DPC.

Why Commercial Support Matters

Enterprises rely on accountability and timely assistance to ensure business-critical services run smoothly. Open source provides flexibility and cost savings, but it often lacks the reliability guarantees companies require. Commercial support bridges that gap—delivering confidence, faster resolutions, and compliance with internal support standards.

Customer Success Story

A UK National Health Service (NHS) Trust, an early customer of the support program, praised the impact of DPC on its remote access strategy. An infrastructure engineer at the NHS trust has this to say about DPC and commercial support:

“We have recently transitioned from SSL VPN to AOVPN and took the opportunity to use DPC to manage our configuration and deployment. We’ve previously experimented with Microsoft’s officially documented process, but DPC really simplifies and streamlines the implementation and management of the AOVPN tunnels.

During rollout, we discovered an issue that caused the user tunnel config to become corrupt. Being able to directly communicate and troubleshoot with Leo and the team meant that we were quickly able to have a fix and a new version of the client ready for deployment.

We are now running DPC and AOVPN on around 4000 endpoints with around 2000 concurrent connections each day. Feedback from users is very positive, and DPC simplifies ongoing management.”

Value Added

This real-world experience highlights the two most significant benefits of DPC with commercial support: rapid issue resolution (direct access to the people who build the software) and confidence at scale (thousands of endpoints, thousands of daily connections).

What DPC Commercial Support Includes

Purchasing a commercial support package provides:

  • 1 year of support services (renewable)
  • Direct access to Leo D’Arcy, lead developer of DPC
  • Support from Richard Hicks for DPC-related queries
  • Enhanced troubleshooting beyond community channels
  • Prioritized bug fixes
  • Early consideration for new feature requests
  • Dedicated private channels for secure communication

Don’t Wait

With a commercial support package, your organization gains expert guidance, faster issue resolution, and direct access to the team that builds and maintains DPC. DPC commercial support ensures smooth deployments, reduced risks, and compliance with internal support requirements

Learn More

Interested in a commercial support contract for Always On VPN DPC? Email us at [email protected] or complete the form below, and we’ll get back to you with more information.

Additional Information

Always On VPN DPC Open Source

Always On VPN DPC Features

Always On VPN DPC Advanced Features

Migrating from Always On VPN DPC Commercial to Open Source

Always On VPN DPC with Microsoft Intune

Always On VPN Discord Channel

Workplace Ninjas Conference U.S. 2025

I’m excited to announce I’ll be presenting at the inaugural U.S. Workplace Ninjas Conference! This two-day event takes place December 9-10, 2025, in Dallas, Texas. Much like the popular Workplace Ninjas Conference held in Switzerland, this event focuses on systems management and endpoint security with Microsoft technologies. It features an impressive lineup of speakers from around the world.

Session Topics

The conference will feature more than 50 deep-dive sessions on a variety of topics, including:

  • Microsoft Intune
  • Microsoft Entra
  • Microsoft Security
  • Windows 11
  • Cloud Security
  • Automation

Why You Should Attend

The Workplace Ninja Conference is a must-attend event for IT pros to dive into endpoint management, cybersecurity, and Microsoft innovations through expert sessions and networking. Attendees will benefit from the following:

  • Practical Learning: Engage in over 50 expert-led sessions, hands-on labs, and real-world demos focused on Microsoft Intune, Entra, Windows 11, and more.
  • Networking Opportunities: Connect with Microsoft MVPs, peers, and top vendors in a collaborative environment, including the Expo Hall.
  • Specialized Tracks: Benefit from dedicated sessions on Women-In-Tech and Neurodiversity-In-Tech, alongside core topics like cybersecurity and automation.

Register Now

Registration for this two-day event is open now. Be sure to reserve your spot today. I look forward to seeing you there!

Always On VPN Servers and Failover

When configuring Microsoft Always On VPN, one of the first and most crucial settings is defining the public hostname of the VPN server to which clients connect. If you’re deploying Always On VPN client configuration settings using Intune—either with the native VPN policy template or a custom XML profile—you’ll see that multiple server entries are supported. Intune even allows administrators to define a “default server.” At first glance, this might suggest that the client will try the default server first and automatically fail over to the others if it’s unavailable. Unfortunately, that’s not how it works.

Intune VPN Template

When using the native Intune VPN device configuration template, administrators will find multiple entry fields for the servers in the Base VPN section.

In the example below, the Global VPN entry is marked as ‘default’.

Custom XML

When defining VPN settings using XML configuration, administrators can also list multiple servers.

Interestingly, the VPNv2 CSP used by custom XML profiles doesn’t support the concept of a “default server” at all.

How It Really Works

Defining multiple servers in the Always On VPN profile does not enable automatic failover. The client connects only to the first server in the list. The so-called “default server” setting in Intune is ignored, and the GUI even allows you to mark all servers as default, which is meaningless.

However, the configuration isn’t entirely useless. If you define multiple servers, they’ll appear on the client side as manual options. If the first server becomes unavailable, the user can open the Settings app, navigate to the advanced settings of the Always On VPN profile, and select an alternate server to connect manually.

Summary

Although Intune and XML configurations allow multiple VPN servers, Always On VPN does not provide automatic failover. Clients only attempt to connect to the first server in the list, and the “default server” setting in Intune has no effect. Multiple entries are still useful, but only for manual server selection by end-users when the primary server is down. For true automated high availability and redundancy, consider an external solution such as Azure Traffic Manager.

Additional Information

Always On VPN Load Balancing

Always On VPN Multisite with Azure Traffic Manager