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.

Cannot Apply Remote Access Setup Wizard Settings in Windows Server 2012 R2

When configuring Windows Server 2012 R2 DirectAccess with a dedicated network location server, the Remote Access Setup Wizard may fail with the following error:

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

However, the name can be resolved successfully and when stepping through the remote access setup, validation of the network location server is successful.

Windows Server 2012 R2 DirectAccess Name Resolution Issue

This has been identified as an issue with the DNS client in Windows Server 2012 R2. Microsoft has now released a hotfix to resolve this problem. For more information, click here.

Windows Server 2012 DirectAccess Network Location Server Not Working Properly

After configuring a Windows Server 2012 DirectAccess server to use an intranet-based Network Location Server (NLS), you may notice that the operations status in the remote access management console indicates a critical problem with NLS, when in fact you can browse the NLS server from the DirectAccess server.

DirectAccess Network Location Server Issue

The issue here is that the DirectAccess server, in addition to being able to successfully connect to the NLS using an HTTP GET, must also be able to ping the NLS server. However, inbound ICMP is often blocked on web servers which results in the DirectAccess server marking the service as failed. The issue can be quickly resolved by modifying the host firewall policy to allow inbound ICMPv4 echo requests. For example, in my test lab I’m using a Microsoft Windows Server 2012 server with Internet Information Services (IIS) installed. A new access rule can be added to the Windows Firewall with Advanced Security (WFAS) by executing the following PowerShell command:

New-NetFirewallRule -Name “Allow Inbound ICMPv4 Echo Request” -DisplayName “Allow Inbound ICMPv4 Echo Request” -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 172.16.1.241, 172.16.1.242 -Profile Domain -Action Allow -Enabled True

Note that my lab server is domain joined, so I’ve specified the WFAS profile to be the Domain profile. In addition I’ve included the IPv4 addresses assigned to the internal network interfaces of my two DirectAccess servers. You’ll need change the command as required to work in your environment.