Resolving DirectAccess Connectivity Issues (The easy solution)

DirectAccess is a relatively new approach to remote connectivity for domain connected devices. It is basically an always on VPN that utilizes IPSec Tunneling to allow access to external client machines. There is no need to deploy or create VPN profiles or handle RADIUS authentication and other such complexities, but the system does utilize PKI (Public Key Infrastructure) to enable a secure VPN tunnel. DirectAccess is also always available for external clients, meaning you don’t have to open a VPN session manually, and it starts *prior* to logon, which means the annoying issues of remote user password resets are easier to handle. However, there are situations where DirectAccess can fail, leaving you without DNS functionality and a lot of headaches.

The NRPT

Direct Access utilizes a feature called the Name Resolution Policy Table (NRPT). This basically controls the way DirectAccess handles name resolution for specific Domains. Entries in the NRPT control where client machines look for name resolution on specific domains and allow finer control of what happens when client machines are utilizing DirectAccess for connectivity. For instance, you can utilize the NRPT to force client machines to look to external DNS servers for resolution on some hostnames or domain zones, while looking to internal DNS for everything else and vice versa. There are really only two ways to modify the NRPT, through the Registry (I don’t recommend modifying the NRPT through the registry), and through group Policy using the Name Resolution Policy node. Technet has some information on how to handle NRPT here: http://technet.microsoft.com/en-us/library/ee649207%28v=ws.10%29.aspx

he Problem with DirectAccess Failures

Usually when DirectAccess stops communicating, it stops working because the NRPT isn’t configured properly. If this happens, you may run into a situation where some systems are unable to ping domain controllers or other systems by using NetBIOS names or through FQDNs. This can be a huge problem, because if DirectAccess fails, systems will typically no longer be able to communicate with the Domain to retrieve corrected NRPT information, since this information is deployed via GPO.

Fixing the Communication Issue

If something causes your DirectAccess configuration on a client machine to corrupt or if Direct Access isn’t properly configured, it may be necessary to reset the NRPT on the client machine to fix the problem. The only way to modify the NRPT on a client machine is through the registry. If you’re experienced enough with DirectAccess, you may be able to resolve the issue directly in the registry. However, it is usually easier to just remove the existing NRPT entries on the client machine entirely. This has to be done in the registry at the following location: HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DNSPolicyConfig (Pictured below)

Note the two entries there. Both are composed of DA-{GUID}. DA stands for DirectAccess. Remove any entries that have that DA- prefix and reboot. Once this is done, the system will begin communicating without DirectAccess and will have the ability to connect to the domain to retrieve new NRPT information if it is available.