I am having to venture away from F5 BIG-IP news on this one folks.  I have recently been working a lot on Microsoft Direct Access and I came across an issue that I wanted to highlight for all those bashing their heads against a brick wall trying to come up with a fix.

NRPT – Name Resolution Policy Table.  If you have messed around with Direct Access much at all you have to had come across this term at some point.  It basically tells your Direct Access clients how to behave when it comes to DNS queries.  Think host file on steroids…

I recently discovered that the NRPT pushed out via Group Policy can EASILY be corrupted if the script that applies the GPO’s fails during it’s activation.  How did I figure this out?  Well I had about 62 NRPT entries to push out, so I queued them all up, hit the apply button and walked away for lunch.  Thinking happily to myself that I would grab some lunch, come back, my updates will have been pushed out and I can jump back onto a little F5 BIG-IP project I am working on.  Imagine the look on my face when I arrived back from lunch and all of my “Test” subjects (aka co-workers) were mentioning that they could no longer access any LAN resources!  I sheepishly hunkered down into my cube and furiously began working on a fix.

Well Microsoft promised this couldn’t happen as of UAG/DA update 1, but I am running UAG/DA update 2 and I can assure you, it can still happen.  The fix is easy enough though as long as you have a computer that is running Direct Access and it has not pulled down a corrupt NRPT table.  The problem generally happens when a computer checks in with the Domain Controllers and does a GP refresh.  This happens periodically and it is hard to tell when a machine might check in.  If you are in the middle of pushing out a new NRPT or it halted in the middle of an update when the client checks in, poof!  Corrupt NRPT.

The fastest way to tell if you have a corrupt NRPT is to open a command line and type:

netsh name show effective policy

If you get back the dreaded message of: “Name resolution policy table has been corrupted. DNS resolution will fail until it is fixed. Contact your network administrator.”  Then welcome to can’t do anything on the LAN land.

So how do you fix it?  On the computer that has a valid NRPT table go and export the following registry key, save it to a thumb drive and sneakernet it over to victims PC.  The key you want to export is “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig”.  Then on the victims PC open up the same spot in the registry and remove the subkeys UNDER the DnsPolicyConfig key.  Don’t change anything in that particular key, just delete the ones underneath it.  They will usually all have a name similar to UAGDA Rule 1, UAGDA Rule 2… you get the idea.

Once you have all of those deleted out, import the good registry key which contains the NRPT and then reboot the PC.  And that’s it!

Share

5 comments so far

Add Your Comment
  1. A reboot of the client isn’t necessary, a simple cycle of the DNS client service will do the job and will allow you to verify DA functionality if you are remotely fixing a user.

  2. Thanks for the tip Andrew Fidel. I have noticed in doing that though that it causes the DirectAccess Connectivity Assistant to appear as though DA functionality is not working. You could also reset the DA Connectivity Assistant service, find the dcatray.exe file and run it to get the DA Assistant going again, but the reboot does all of that.

    The reboot also has the side effect of clearing out any stored DNS entries that may cause issues with DA or the DA Connectivity Assistant from working properly.

  3. You saved a lot of working hours for me with this posting. Thanks a lot! It worked like a charm, even though I had to use the help of colleagues to get the reg-file via mail to my smartphone and then mount it on my netless laptop as a usb drive :-)

  4. i came to your website early this year, and saving me from the DA implementation on Server 2012. And now I’m trying again on Server 2012 R2 hoping there’s a new improvement, and still I’m facing the same issue. Accessing the internal resource is working excellent with DA, but problem is from inside. Your solution to delete the registry entry saved me again.
    Thanks a lot!!

  5. This help me out very much as well. Someone was installing direct access, and didn’t notice that the group policy set the DNS server as incorrect. Through the entire network into a huge tailspin. I found the problem, and used this article to fix it by changing the reg entry manually. (as changing the group policy was fruitless when the machines will no longer resolve the domain)
    So thank you!