locked
NRPT becomes corrupt if client updates Group Policy during UAG DirectAccess GPO writing RRS feed

 , 
 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hello,

    We have installed UAG RTM on a 2008 R2 server and have configured DA to work in our organization.  Things work great, in general, but there is one thing that has caused some seriuos problems:  when we use the UAG DA wizard and make any policy changes (such as adding or removing a DC from the list of infrastructure servers), it takes about an hour after clicking "apply" for the wizard to write all of the GPO settings.  During that time, if anyone refreshes their GP settings (via reboot, gpupdate, etc.), their NRPT becomes corrupt and all DNS resolution fails.  This bricks the machine, and the user or an admin must manually edit the registry to remove the corrupt entries and then restart the DNS client service to get the machine working again.  Does anyone know why this is happening?

    As a side note, I worked with the DA product group and we used to have GPO writes that would take several hours.  I don't recall this ever happening during those long GPO writes, which suggests to me that this is related to the way UAG is writing the info to the GPOs.  But I don't really know for sure and any help would be appreciated.

    Thank you!
    Friday, February 12, 2010 7:56 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi Justin,

    Please write to me at tomsh@online.microsoft.com

    *remove "online"

    Thanks!
    Tom
    MS ISDUA Anywhere Access Team
    Saturday, February 13, 2010 2:51 PM
    Moderator

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi Justin,

    Please write to me at tomsh@online.microsoft.com

    *remove "online"

    Thanks!
    Tom
    MS ISDUA Anywhere Access Team
    Saturday, February 13, 2010 2:51 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    I've had this happen also.

    My workaround was to export HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig from a working client and import to the client not working.

    Kveðja,
    Nóri
    Wednesday, March 17, 2010 10:57 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I am curious why it takes so long for the gpo to be written.  Can you eleborate on the corruption seen from the perspective of how to detect?

    Thanks,

    Don Murphy
    Wednesday, March 17, 2010 11:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    You will know when it happens!!!! The client loses all DNS name resolution so cannot even talk to the local domain...killer :(
    Jason Jones | Forefront MVP | Silversands Ltd
    Wednesday, March 17, 2010 11:40 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Exactly.  If you need any further evidence of corruption, you can run "netsh name show policy" or "netsh name show effective" from an elevated command prompt and it will return "The Name Resolution Policy Table is corrupt..." 

    I'm curious why the GPO takes so long too.  The long ones at MS were due to the fact that we had several hundred IPv6 addresses (of domain controllers) in the consec rules of the policy.  But the policies that we're writing here are tiny, only about eight IPv6 addresses.  So hopefully this gets fixed soon.

    Thank you for the workaround, Nori.  That approach has worked for me as well.  In fact, I have found that another way to fix it is to navigate to HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig and delete all of the entries there.  Then do a gpupdate (once the policy write has completed :-) ) and it will fix up the NRPT. 

    Thank you.
    Thursday, March 18, 2010 12:18 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    But I guess you need to have the connectivity to the DC for the gpupdate to fix the NRPT?

    I noticed tonight that I couldn't deploy the policy on the first try. It complained that files were already in use and I had to log off and on again for it to work.

    It takes also a very long time to update my policy. And I have only a few IPv6 addresses. My environment is very small, we only have two DCs for example.

    Kveðja,
    Nóri


    Thursday, March 18, 2010 1:07 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    You guys on native IPV6 or ISATAP?
    Thursday, March 18, 2010 3:06 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi Nori,

    What do you  mean when you say that you only have a few IP addresses?

    Thanks!
    Tom
    Thursday, March 18, 2010 11:07 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    @Tom: I was basically saying that I have a very small environment with only a few servers defined in the Infrastructure Server part of the UAG DirectAccess configuration.

    @Don: I'm using ISATAP.

    Kveðja,
    Nóri
    Thursday, March 18, 2010 11:23 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Exactly.  If you need any further evidence of corruption, you can run "netsh name show policy" or "netsh name show effective" from an elevated command prompt and it will return "The Name Resolution Policy Table is corrupt..." 

    I'm curious why the GPO takes so long too.  The long ones at MS were due to the fact that we had several hundred IPv6 addresses (of domain controllers) in the consec rules of the policy.  But the policies that we're writing here are tiny, only about eight IPv6 addresses.  So hopefully this gets fixed soon.

    Thank you for the workaround, Nori.  That approach has worked for me as well.  In fact, I have found that another way to fix it is to navigate to HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig and delete all of the entries there.  Then do a gpupdate (once the policy write has completed :-) ) and it will fix up the NRPT. 

    Thank you.

    I used the same fix; deleting the corrupt keys will get a local machine back online DNS wise after a reboot (or DNS client service restart I think).

    For external users, I had to get them to VPN in using a traditional VPN method in order to run the gpupdate. Once they did, DA was back online after stopping the VPN.
    Jason Jones | Forefront MVP | Silversands Ltd
    Thursday, March 18, 2010 1:09 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    But I guess you need to have the connectivity to the DC for the gpupdate to fix the NRPT?

    I noticed tonight that I couldn't deploy the policy on the first try. It complained that files were already in use and I had to log off and on again for it to work.

    It takes also a very long time to update my policy. And I have only a few IPv6 addresses. My environment is very small, we only have two DCs for example.

    Kveðja,
    Nóri


    That is the usual scenario that can lead to corruption...MS are aware of the problem and have a fix.
    Jason Jones | Forefront MVP | Silversands Ltd
    Thursday, March 18, 2010 1:11 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Is the fix public?
    Thursday, March 18, 2010 2:48 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    No, not yet, but I believe it will be soon...a call to MS would be free if you are desperate...
    Jason Jones | Forefront MVP | Silversands Ltd
    Thursday, March 18, 2010 3:16 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Jason,

    Do you know if this issue would apply to DA with TMG over the top or just UAG?

    Don
    Thursday, March 18, 2010 7:33 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I think just UAG, but not 100% as haven't had much exposure to native DA...Tom?
    Jason Jones | Forefront MVP | Silversands Ltd
    Thursday, March 18, 2010 8:01 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Don:  I've only seen it with UAG so far, but I haven't used native DA for over six months so things may have changed.

    Also, to answer your previous question about native v6 vs. ISATAP, we have been using 100% NAT64 and DNS64 so far. 

    Jason:  Yes, thank you for catching the last step in the workaround procedure: restarting the DNS Client service.

    Justin
    Thursday, March 18, 2010 9:01 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    We are just testing DA and UAG with DA. UAG DA caused us a couple of problems that DA alone does not.

    1. The corruption of the Name Resolution Policy Table.

    2. Group Policies created by UAG DA are security filtered to the defined Security Group which is correct, but additionally to Authenticated Users group. This was a major for us as all machines that received the policy lost DNS capability because of the above issue.

    When is this fix going to be available? Anyone got more info about this problem?

    Thanks,

    Andrew

    Friday, July 30, 2010 10:47 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Andrew,

    1. This is fixed with UAG Update 1 - make sure you use that in production

    2. UAG doesn't apply the policies to the Authenticated Users group - just the Direct Access Clients security group. Something else must have caused that. I just confirmed that in my lab setup.

    HTH,

    Tom

     

    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 30, 2010 12:53 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    I thought update 1 also fixed problem 2 too...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Saturday, July 31, 2010 12:02 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Jason,

    I've never seen problem 2. Have you seen it?

    Thanks!

    Tom

    MS ISDUA/UAG DA Anywhere Access Team
    Monday, August 2, 2010 3:06 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Problem 2 is a known issue as well.

    It was fixed in UP1 though

    Tuesday, August 3, 2010 10:46 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Yaniv,

    Thanks! I guess I've been lucky.

    Tom

    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, August 3, 2010 11:26 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    I can confirm UP1 fixes both issues. Thanks!
    Tuesday, August 3, 2010 8:47 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Great!

    Good to hear you got working and thanks for the follow up!

    Tom

    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Thursday, August 5, 2010 12:57 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Mr. Thomas,

    I faced the issue like unable to connect to any network (LAN or Wireless). Getting the error msg : the name resolution table policy corrupted... i think i need to un install or remove the DA (direct access) from the machine and check.. Please suggest me on this. Thanks in advance.

    Thursday, August 30, 2012 6:03 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    You can find the NRPT settings by opening gpedit.exe on the client and browsing here: Computer Configuration > Windows Settings > Name Resolution Policy

    Then on the right look for "Name Resolution Policy Table" - you can delete the entries from here.

    Thursday, August 30, 2012 6:41 PM