After the April 2024 Microsoft security updates were released, many Always On VPN administrators noticed that the device tunnel suddenly stopped connecting automatically for many, if not all, their endpoints.
Note: There were additional problems with the April 2024 security update that affected the Always On VPN device tunnel. Details here.
Troubleshooting
When this problem occurs, administrators can establish the device tunnel connection successfully if it is initiated manually. This indicates that there are no issues with the IKEv2 VPN connection or security configuration.
Subscription Activation
The root cause of this issue is related to a subscription activation issue broken in the April 2024 security updates. In this case, Windows 10/11 Enterprise Edition devices that were initially provisioned using Professional Edition and used a step-up upgrade (subscription activation) to Enterprise Edition are reverting to Professional Edition. The Always On VPN device tunnel requires Enterprise Edition to work correctly. Although you can deploy a device tunnel to Windows Professional, it will not connect automatically. It will, however, connect manually.
KB5040527
On July 25, 2024, Microsoft released a preview of updates (KB5040527), including a fix for this subscription activation issue. Administrators experiencing problems with Always On VPN device tunnels where their devices revert to Professional Edition can install this update to resolve this issue.
Always On VPN administrators deploying on-premises enterprise PKI certificates using Microsoft Intune with PKCS may encounter a scenario where a certificate fails to be issued to a user or device. In this post, I’ll share some things to investigate when troubleshooting this issue.
Event 1001
To begin, open the Event Log and navigate to Applications and Services > Microsoft > Intune > CertificateConnectors > Admin. You will likely find an event ID 1001 from the CertificateConnectors source with the following error message.
Failed to process PKCS request.
Prerequisites
Validate the following prerequisites have been met on the issuing Certification Authority (CA) server.
Certificate Template
Ensure the certificate template used for PKCS has the correct permissions and is published on an issuing CA server. Open the Certificate Templates management console (certtmpl.msc), right-click the certificate template, choose Properties, and then click on the Security tab. The certificate template must grant the Intune Certificate connector server’s computer account (or the PKCS connector’s service account if running as a service and not SYSTEM) the Read and Enroll permissions on the template.
CA Permissions
In addition to the permissions on the certificate template, ensure the correct permissions have been configured on the issuing CA itself. Right-click on the CA in the Certification Authority management console (certsrv.msc) and choose Security. Ensure the Intune Certificate connector server’s computer account (or the PKCS connector’s service account, if running as a service and not SYSTEM) is granted The Issue and Manage Certificates and Request Certificates permissions.
Intune Policy
Ensure the Intune device configuration policy is configured correctly. These three fields are critical and can result in failed PKCS certificate deployment if misconfigured.
Certification Authority
Enter the fully qualified domain name (FQDN) of the on-premises issuing CA server in this field.
Certification Authority Name
Enter the common name of the issuing CA in this field. You will find this information by running the following command on any domain-joined Windows system.
certutil.exe -dump
Certificate Template Name
Enter the name of the certificate template in Active Directory. Be aware that the template name and template display name are two different things. The template name is usually the template display name without spaces. However, that’s not a guarantee. On the General tab of the certificate template, look at the template name field on the certificate template to confirm.
Summary
This article is not a comprehensive troubleshooting guide for problems associated with failed PKCS certificate deployment using the Microsoft Intune Certificate connector and PKCS. However, it covers some of the more common problems administrators will likely encounter. If you cannot provision PKCS certificates correctly, drop me a note and I’ll provide further guidance.
In Windows, each network interface identified by the operating system is assigned a metric value. Interface metrics are settings that determine the priority or preference of network interfaces when there are multiple active network connections. The Windows networking stack uses these metrics to determine which network interface should be used for routing traffic when multiple network interfaces are available. Network interface metrics are critical for Always On VPN administrators to understand because they can impact how name resolution requests are processed when an Always On VPN connection is established.
Metric Values
By default, Windows automatically assigns metric values to network interfaces (including VPN interfaces) based on various factors, including the connection speed, link state, and interface type. It tries to select the most suitable interface for general internet connectivity.
Metrics and DNS
Windows will also use the network interface with the lowest metric value as the preferred interface for sending DNS queries by default. This means that DNS queries will be routed through the network interface with the lowest metric value, assuming it is available and connected. When an Always On VPN connection is established, DNS queries may fail or return unexpected results if the network interface metrics are not configured optimally.
Split DNS and Wired Ethernet
Split DNS (sometimes called ‘split brain DNS’) is when the DNS namespace is the same internally and externally. The most common scenario where interface metric settings interfere with DNS operation is when using split DNS and the endpoint is connected to the Internet with a wired Ethernet connection. In this scenario, the Ethernet interface will be assigned the same or lower interface metric value as the Always On VPN interface, which can yield unexpected results.
Viewing Metrics
Always On VPN administrators can view currently assigned interface metric values by running the following PowerShell command.
Most Always On VPN administrators will never have to change interface metric settings. However, if your implementation uses split DNS and some of your endpoints connect using wired Ethernet connections, you may need to update the interface metric settings to ensure proper DNS operation. Choose a setting for the interface metric value that is lower than the wired Ethernet interface. I’ve used a value of ‘3’ without issue for many years. Use one of the following methods to update the interface metric for Always On VPN connections.
PowerShell
Updating interface metric settings in Windows can be accomplished by running the Set-NetIpInterface PowerShell command.
Note: Using PowerShell to assign the interface metric is not persistent! While this method is suitable for local validation testing, you should use one of the following methods to implement this change permanently.
Rasphone.pbk
To assign the interface metric permanently, Always On VPN administrators can edit the following settings in the rasphone.pbk configuration file.
IpInterfaceMetric=3
Ipv6InterfaceMetric=3
Administrators can automate updating this setting using the Update-Rasphone.ps1 PowerShell script. In addition, the following scripts can be used with Microsoft Intune remediation.
