Always On VPN Updates to Improve Connection Reliability

Always On VPN Updates to Improve Connection ReliabilityA longstanding issue with Windows 10 Always On VPN is that of VPN tunnel connectivity reliability and device tunnel/user tunnel interoperability. Many administrators have reported that Always On VPN connections fail to establish automatically at times, that only one tunnel comes up at a time (user tunnel or device tunnel, but not both), or that VPN tunnels fail to establish when coming out of sleep or hibernate modes. Have a look at the comments on this post and you’ll get a good understanding of the issues with Always On VPN.

Recent Updates

The good news is that most of these issues have been resolved with recent updates to Windows 10 1803 and 1809. Specifically, the February 19, 2019 update for Windows 10 1803 (KB4487029) and the March 1, 2019 update for Windows 10 1809 (KB4482887) include fixes to address these known issues. Administrators are encouraged to deploy Windows 10 1803 with the latest updates applied when implementing Always On VPN. Windows 10 1809 with the latest updates applied is preferred though.

Persistent Issues

Although initial reports are favorable for these updates and based on my experience the effectiveness and reliability of Windows 10 Always On VPN is greatly improved, there have still been some reports of intermittent VPN tunnel establishment failures.

Possible Causes

During my testing, after applying the updates referenced earlier both device tunnel and user tunnel connections are established much more consistently than before the updates were applied. I did encounter some issues, however. Specifically, when coming out of sleep or hibernate, VPN connections would fail to establish. Occasionally VPN connections would fail after a complete restart.

NCSI

After further investigation it was determined that the connectivity failure was caused by the Network Connectivity Status Indicator (NCSI) probe failing, causing Windows to report “No Internet access”.

Always On VPN Updates to Improve Connection Reliability

Cisco Umbrella Roaming Client

In this instance the NCSI probe failure was caused by the Cisco Umbrella Roaming Client installed and running on the device. The Umbrella Roaming Client is security software that provides client protection by monitoring and filtering DNS queries. It operates by configuring a DNS listener on the loopback address. NCSI probes are known to fail when the DNS server is running on a different interface than is being tested.

Resolution

Microsoft released a fix for this issue in Windows 10 1709. The fix involves changing a group policy setting to disable interface binding when perform DNS lookups by the NCSI. You can enable this setting via Active Directory group policy by navigating to Computer Configuration > Administrative Templates > Network > Network Connectivity Status Indicator > Specify global DNS. Select Enabled and check the option to Use global DNS, as shown here.

Always On VPN Updates to Improve Connection Reliability

For testing purposes this setting can be enabled individual using the following PowerShell command.

New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\” -Name UseGlobalDNS -PropertyType DWORD -Value 1 -Force

Third-Party Software

As Always On VPN connectivity can be affected by NCSI, any third-party firewall or antivirus/antimalware solution could potentially introduce VPN connection instability. Observe NCSI operation closely when troubleshooting unreliable connections with Always On VPN.

Additional Information

Windows 10 1803 Update KB4487029

Windows 10 1809 Update KB4482887

Cisco Umbrella Roaming Client Limited Network Connectivity Warning

Network Connectivity Status Indicator (NCSI) Operation Explained

Always On VPN Device Tunnel Missing in Windows 10 UI

Always On VPN Device Tunnel Missing in Windows 10 UIUnlike DirectAccess, Always On VPN connections are provisioned to the user, not the machine. Beginning with Windows 10 release 1709 Microsoft introduced the device tunnel option to provide feature parity with DirectAccess. The device tunnel provides pre-logon network connectivity to support important deployment scenarios such as logging on without cached credentials and unattended remote systems management.

Device Tunnel Configuration

Guidance for creating and deploying a device tunnel connection can be found here. It’s important to note that the device tunnel is always on by default. Also, there can only be a single device tunnel configured per device. You must remove an existing device tunnel before configuring a new one.

Known Issues

After configuring a Windows 10 Always On VPN device tunnel the administrator may notice two anomalies. First, the device tunnel is missing in the Windows UI after it is created. Second, viewing the status of the device tunnel connection using PowerShell indicates the connection is “disconnected” even though it is connected.

Device Tunnel Missing

As you can see below, event though both a device and user tunnel have been provisioned, the Windows UI reports only a single Always On VPN connection, that being the user connection.

Always On VPN Device Tunnel Missing in Windows 10 UI

However, the device tunnel does appear in the Network Connections control panel applet (ncpa.cpl), as shown here.

Always On VPN Device Tunnel Missing in Windows 10 UI

This is expected and by design. The device tunnel is not displayed to the user in the Windows UI as it is provisioned to the machine, not the user. It appears on the Control Panel because the applet is capable of enumerating both user and system connections.

Device Tunnel Disconnected

The status of the Windows 10 Always On VPN device tunnel connection can be viewed by running the Get-VpnConnection -AllUserConnection PowerShell command. However, at the time of this writing, PowerShell always reports the connection status as “Disconnected”. This appears to be a bug; one which Microsoft is hopefully working to address.

Always On VPN Device Tunnel Missing in Windows 10 UI

Summary

The Windows 10 Always On VPN device tunnel option allows administrators to enable scenarios previously supported with DirectAccess, including logging on without cached credentials and unattended remote support. Not all deployments require a device tunnel, but it is an important option available to administrators to address specific use cases.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN RasMan Device Tunnel Failure

Deleting a Windows 10 Always On VPN Device Tunnel

 

DirectAccess Inbox Accounting Database Optimization

DirectAccess Inbox Accounting Database OptimizationRecently I wrote about an issue with DirectAccess servers exhibiting high SQL Server CPU usage. In that article I demonstrated a way to resolve the issue by adding a crucial index to a table in the remote access inbox accounting database. The process was a bit involved and required downloading third-party tools to make configuration changes on the DirectAccess server.

Going forward, making these changes will now be much easier. Microsoft has published guidance for optimizing the remote access inbox accounting database using PowerShell. They’ve also provided scripts to back up the database and to confirm that optimization has been implemented.

For more information and to download the remote access inbox accounting database optimization PowerShell scripts, click here.

Windows 10 November Update Available Today

Windows 10 November Update Available TodayToday Microsoft announced the availability of the November Update (formerly Threshold 2) for Windows 10. With this update, Microsoft is now touting Windows 10 build 1511 as “enterprise ready”, with a number of key features and enhancements designed to drive enterprise adoption for the client operating system.

  • Performance Improvements – According to Microsoft, the Windows 10 November Update includes important improvements in performance, improving boot time almost 30% over Windows 7 installed on the same system.
  • Windows Update for Business – Windows Update for Business enables IT to control Windows update within their organization, allowing administrators to roll out updates on their schedule. New features with this service include creating device groups and enabling phased deployment of updates across the organization
  • Windows Store for Business – The Windows Store for Business provides IT with a mechanism to provision and manage apps for Windows 10 devices, both from the Windows Store and their own line-of-business apps.
  • Telemetry Control – Beginning with Windows 10 build 1511, enterprise customers will now have the ability to completely disable all Windows telemetry. Although not recommended, this feature is essential for many organizations to maintain the highest levels of security.

Since Windows 10’s release in late July of this year, enterprise customers have deployed Windows 10 on more than 12 million business PCs. Many organizations who have not yet upgraded are in the planning and pilot stages today, or will be soon. The enterprise adoption rate for Windows 10 continues to accelerate, and no doubt will do so even more with the release of Windows 10 build 1511.

Don’t forget that Windows 10 already includes a number of important security advancements such as Credential Guard to mitigate various credential theft attacks, Device Guard to prevent installation of malicious software, and Windows Hello to strengthen authentication with the use of biometrics. These features, along with the new capabilities and services introduced today, continue to make Windows 10 a compelling client operating system in the enterprise.

Of course the perfect complement to Windows 10 in the enterprise is DirectAccess. To learn more about how to maximize your investment in Windows 10 with DirectAccess, here are some essential references.

In addition, DirectAccess consulting services are also available. More details here.

Unable to Install DirectAccess Hotfix KB2953212 to Disable NRPT

Last year I wrote about Microsoft hotfix KB2953212 that that allowed users to disable the Name Resolution Policy Table (NRPT) on a DirectAccess client. This hotfix addressed a specific scenario where a DirectAccess client on the internal corporate network could not connect to local resources due to Network Location Server (NLS) unreachability.

When installing this update, you many encounter the following error message:

Windows Update Standalone Installer
The update is not applicable to your computer

Unable to Install DirectAccess Hotfix KB2953212 to Disable NRPT

This occurs because the KB2953212 hotfix was included in KB3000850, the November 2014 update rollup for Windows 8.1 and Windows Server 2012 R2. You can verify this by opening the Control Panel and selecting Programs and then clicking View installed updates under Programs and Features.

Unable to Install DirectAccess Hotfix KB2953212 to Disable NRPT

If you have the November 2014 update rollup installed there is no need to install KB2953212, as that hotfix is already included in the rollup.

Hotfix Available to Disable NRPT on Windows 8.x DirectAccess Clients

Updated April 9, 2015: The hotfix referred to in this article is now included in the November 2014 update rollup for Windows 8.1 and Windows Server 2012 R2. You will receive an error message when installing this update on Windows 8.x clients with the update rollup installed. More details here.

The Network Location Server (NLS) is a critical infrastructure component for DirectAccess deployments. The NLS is used by DirectAccess clients to determine if the client is located inside or outside of the corporate network. If the NLS becomes unavailable, DirectAccess clients that are already outside the corporate network are unaffected. However, DirectAccess clients that are inside the corporate network will mistakenly believe that they are outside and the Name Resolution Policy Table (NRPT) will be enabled, forcing name resolution requests for hosts in the internal namespace to be sent to the DNS64 service running on the DirectAccess server. If the DirectAccess server is unreachable from the internal network (a common scenario for a variety of reasons), DirectAccess clients inside the corporate network will be unable to connect to any local network resources by name until the NLS is once again reachable.

Configuring the Network Connectivity Assistant to Allow DirectAccess clients to use local name resolution does not resolve this issue. Although it sounds intuitive, it doesn’t resolve this specific issue where the NLS is unreachable.

Hotfix Available to Disable NRPT on Windows 8.x DirectAccess Clients

When the option to Allow DirectAccess clients to use local name resolution is enabled, the client can only choose to disconnect (use local name resolution) after it has successfully established a connection to the DirectAccess server. If the DirectAccess connection shows that it is still connecting, the option to disconnect is not available.

Hotfix Available to Disable NRPT on Windows 8.x DirectAccess Clients

To address this issue, Microsoft has released update KB2953212 for Windows 8.x clients that allows the disabling of the NRPT regardless if the client has successfully established a DirectAccess connection. With this update, if a DirectAccess client is located on the corporate network and is unable to reach the NLS, the user will be able to disable the NRPT (effectively disconnect DirectAccess) and once again connect to resources on the corporate network.
Hotfix Available to Disable NRPT on Windows 8.x DirectAccess Clients

This update is certainly no excuse not to deploy your NLS in a highly-available configuration using Windows Network Load Balancing (NLB) or a third-party external load balancer (hardware or software), but it can be a life-saver if your NLS becomes unavailable for any reason. I’d recommend deploying this update to all of your Windows 8.x DirectAccess clients soon.

For more information and to download the hotfix, click here.

Error 0x80040001 When Using OTP on Windows 7 SP1 DirectAccess Clients

Microsoft recently released a hotfix to resolve an issue where Windows 7 SP1 DirectAccess clients fail to connect to a DirectAccess server with the IP-HTTPS IPv6 transition protocol and using One-Time Password (OTP) authentication via the DirectAccess Connectivity Assistant (DCA) 2.0. In this scenario you may receive an HTTP 403 error from the DirectAccess server in response to the certificate signing requests and a 0x80040001 error after entering the OTP.

You can learn more about the hotfix for DCA 2.0 on Windows 7 SP1 and download the associated hotfix here.

Rules Update Available for Windows Server 2012 R2 RRAS Best Practice Analyzer

Microsoft recently published knowledge base article KB2928193, announcing the availability of a Routing and Remote Access Service (RRAS) rules update for the Best Practices Analyzer (BPA) in Windows Server 2012 R2. If you are using Windows Server 2012 R2 for client-based remote access VPN or site-to-site VPN, you are encouraged to install this update prior to executing a BPA scan. You can download the update here.

Hotfix Available for Windows Server 2012 R2 DirectAccess Configuration Issue

A while back I wrote about an issue that I encountered when attempting to configure DirectAccess in Windows Server 2012 R2 using a dedicated Network Location Server (NLS). In this deployment scenario, the Remote Access Setup Wizard would fail and return the following error message:

The configuration was rolled back successfully. The URL specified for the network location server cannot be resolved to an IP address.

Windows Server 2012 R2 DirectAccess Name Resolution Issue

Upon further investigation, the NLS server name does indeed resolve correctly, and clicking validate when defining the NLS works without issue. Originally I proposed a workaround that involved changing a registry setting. However, after working with Microsoft to identify the issue they have released a hotfix to resolve this issue correctly. You can download the hotfix here.

Windows Server 2012 Remote Access Management Service Memory Leak

When Windows Server 2012 is configured for DirectAccess or client-based remote access Virtual Private Networking (VPN), a memory leak may occur in the Remote Access Management service when remote clients access the Internet using the DirectAccess or VPN connection. Microsoft knowledgebase article KB2895930 describes the issue in detail and includes a link to the hotfix to resolve this issue.

Microsoft Windows Server 2012/R2 DirectAccess

%d bloggers like this: