locked
Adding DNS domains/servers causes NRPT corruption RRS feed

  • Question

  • Well, my UAG test setup is a LOT closer to perfect.  The basic DirectAcess functionality is now working correctly.

    On my test LAN, I have two AD domains... let's call them local.foo and local.bar.  There are two AD DCs (which are also DNS servers for the domain), a Web server, a TMG firewall that provides the Internet connection, and the UAG server in the local.foo domain.  My test client is a member of the local.foo domain.  It can successfully ping and access resources in the domain (including e.g. the Web server) as expected.

    Now I would like to add access to the local.bar domain as well.  The local.bar domain has its own DC/DNS pair, Web server, and TMG firewall on the same LAN segment.  My assumption is that, by adding references to the local.bar domain and its DNS servers to my UAG configuration, I should be able to access local.bar resources from my client (assuming it has suitable permissions).

    In the UAG DirectAccess Configuration screen, I go to the Infrastructure Servers wizard's DNS Suffixes panel.  There, I see only the expected two entries (*.local.foo, which is served by [DNS64], and webserver.local.foo, which is [Excluded]).  The selected local name resolution option is #2 (Fall back to local if name does not exist in DNS when client is on private network).

    I double-click to add an entry, add my DNS suffix (local.bar), and choose "Other DNS server IPv4 address(es)" (because my UAG server is in a different DNS domain than the local.bar systems and cannot resolve those entries).  I add the IPv4 addresses for the two local.bar DNS servers and verify them.  I then generate and activate the policy, and this SEEMS to work OK (or at least without any errors)...

    However, when my client receives a Group Policy update with the new DA policy in place, the NRPT gets corrupted.  Every time.  If I remove the local.bar entries and recreate/activate the policy, clean the NRPT on the client, and apply the "old" policy, things work again.

    The only reference I have seen to NRPT corruption was due to clients attempting to update their Group Policy while UAG was still in the process of applying it.  To eliminate this as a cause, I specifically waited 12 hours (!!!) after activating the policy on UAG before updating the client... and the NRPT still gets corrupted.

    Is this a known problem?  Is there a fix?  Or am I doing something boneheaded in my config?

    Thanks for any insights...

     

    tkarp

    Saturday, April 10, 2010 3:55 PM

Answers

  • Thank you both for the pointer!  I downloaded and installed Update 1... and it didn't fix the problem.  :(

    Fortunately, I *did* stumble upon a "fix".  After applying Update 1, I looked at the newly-updated-but--still-not-working NRPT entries... now (after installing Update 1) all of the NRPT entries looked valid and had reasonable values, but "netsh dns show state" still complained about corruption.  You may recall that my two AD domains on the LAN each had two AD/DNS servers, but for the local.foo domain (of which the UAG server is a member) there is only one DNS server in the config -- the UAG server itself via [DNS64] -- while the "additional" domain, local.bar, had both of its DNS servers listed via their IPv4 addresses.  On a whim, I changed things so that local.bar showed only one DNS server (via its IPv4 address).  I rebuilt/activated the config, cleared the NRPT cache on the client, reloaded the group policy... and things work perfectly.

    This behavior is 100% reproducible for me, and therefore I believe it is a bug.  To reproduce, try adding support for a new DNS suffix and add more than one DNS server for it -- the multiple-DNS-servers-per-domain thing seems to cause the NRPT corruption.

    I also found that, while I could now reach the DNS servers in the local.bar domain via IPv6 addresses, I could not achieve DNS lookups for that domain from the client.  The reason: the local.bar domain is all Windows Server 2003 systems with no IPv6.  I surmise that if I wanted things to work as I had intended to configure them, I would have to roll out IPv6 and IPv6 DNS throughout the local.bar domain, something which will be impractical when I move this to production (the "real" local.bar domain is indeed WS2K3 and IPv4 only).

    A solution was to add a stub zone for local.bar to the local.foo DNS servers and then adjust my DirectAccess config such that both local.foo and local.bar DNS lookups were being provided by my UAG server via [DNS64].  This all works correctly.

    Again, I thank all of you for your help in getting this far.  If indeed the multiple DNS server thing may be a bug, I would be happy to work with you to provide more detail to help to squash it.

     

    tkarp

    • Marked as answer by Erez Benari Wednesday, April 14, 2010 12:25 AM
    Tuesday, April 13, 2010 8:43 PM

All replies

  • Hi Tom,

    Have you called CSS on this?

    I'll see what I can find out.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, April 12, 2010 1:57 PM
  • Tom,

    No, I have not contacted CSS (yet).  I try to mine the Internet knowledge vein before resorting to direct contact.  :)  More importantly, I like to ensure that I have a "real" problem on my hands, and am not simply doing something boneheaded or already documented somewhere, before involving CSS.

    TIA for your help.

     

    tkarp

    Monday, April 12, 2010 2:48 PM
  • I believe there is a private fix for NRPT corruption issues, so CSS should be able to help free of charge ;)
    Jason Jones | Forefront MVP | Silversands Ltd
    Monday, April 12, 2010 4:24 PM
  • I just contacted Microsoft Support using my MSDN-Premium-provided support incidents (if necessary) to investigate this, and after quite awhile on hold was politely told that I could not get support for my UAG because it is in "RTM but not commercially released" status.  :(  I was also politely told that if, as Jason suggests, there is a private fix available, they would make it available to me, but only if I had a KB number to reference and the fix wasn't available online through the KB article.

    I have searched and cannot find any related KBs.  Tom and/or Jason, can you provide any more info, pointers, help, etc?

    Thanks!

     

    tkarp

    Monday, April 12, 2010 5:22 PM
  • Hi Tom,

    Update 1 for UAG has just been released - I believe this fix is included.

    http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a862c57f-5c27-4cd0-8528-91b3cc5cd758

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd
    Tuesday, April 13, 2010 7:54 AM
  • Yes! UP1 includes the fix. Go get it!

    :)

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, April 13, 2010 3:50 PM
  • Thank you both for the pointer!  I downloaded and installed Update 1... and it didn't fix the problem.  :(

    Fortunately, I *did* stumble upon a "fix".  After applying Update 1, I looked at the newly-updated-but--still-not-working NRPT entries... now (after installing Update 1) all of the NRPT entries looked valid and had reasonable values, but "netsh dns show state" still complained about corruption.  You may recall that my two AD domains on the LAN each had two AD/DNS servers, but for the local.foo domain (of which the UAG server is a member) there is only one DNS server in the config -- the UAG server itself via [DNS64] -- while the "additional" domain, local.bar, had both of its DNS servers listed via their IPv4 addresses.  On a whim, I changed things so that local.bar showed only one DNS server (via its IPv4 address).  I rebuilt/activated the config, cleared the NRPT cache on the client, reloaded the group policy... and things work perfectly.

    This behavior is 100% reproducible for me, and therefore I believe it is a bug.  To reproduce, try adding support for a new DNS suffix and add more than one DNS server for it -- the multiple-DNS-servers-per-domain thing seems to cause the NRPT corruption.

    I also found that, while I could now reach the DNS servers in the local.bar domain via IPv6 addresses, I could not achieve DNS lookups for that domain from the client.  The reason: the local.bar domain is all Windows Server 2003 systems with no IPv6.  I surmise that if I wanted things to work as I had intended to configure them, I would have to roll out IPv6 and IPv6 DNS throughout the local.bar domain, something which will be impractical when I move this to production (the "real" local.bar domain is indeed WS2K3 and IPv4 only).

    A solution was to add a stub zone for local.bar to the local.foo DNS servers and then adjust my DirectAccess config such that both local.foo and local.bar DNS lookups were being provided by my UAG server via [DNS64].  This all works correctly.

    Again, I thank all of you for your help in getting this far.  If indeed the multiple DNS server thing may be a bug, I would be happy to work with you to provide more detail to help to squash it.

     

    tkarp

    • Marked as answer by Erez Benari Wednesday, April 14, 2010 12:25 AM
    Tuesday, April 13, 2010 8:43 PM