Direct Access R2 Setup


  • Hi,

    I'm been following the Direct Access documentation (step-by-step and early adopter guide) and setting up Direct Access in a test environment (across the Internet) and am getting an error that states on the DA server itself

    "None of the internal DNS Servers 2002:xxxxxxx:IPv4 that DirectAccess client computers use for name resolution is responding. This prevents DirectAccess clients from resolving names in the internal namespace and connecting to the internal network. Make sure the DNS Servers are online

    My test client establishes an IP-HTTPS tunnel correctly, but it looks like the above error is preventing clients connecting correctly.

    - I can't ping internal addresses
    - I have an ISATAP A record registered for the DA server done using the DNSCMD /ADDRECORD command
    - My NRPT table (via NETSH NAME SHOW POLICY) shows the GPO correctly setting a Direct Access (DNS Server) setting pointing to 2002:xxxxxxx:IP Address of my R2 DC. DirectAccess (IPsec) is set to disabled and Proxy settings are set to bypass. The CA settings points to my internal root CA as a trust anchor.

    - Do all DCs need to be R2?
    - What is the above error and are there any troubleshooting steps I should follow to resolve this?
    - The documentation alludes to forest functional level being R2 but is this really necessary or can I run in 2008 Forest functional mode?

    Many thanks,
    Saturday, May 23, 2009 7:29 PM


  • I'm having the exact same problem...also tried to rebuild several times with no luck.

    And now I'm running out of ideas...
    Ilja Godau
    • Marked as answer by Mylo Wednesday, June 03, 2009 7:51 PM
    Monday, June 01, 2009 10:56 PM

All replies

  • hi mylo,

    direct access is a feature for windows 2008 R2 .

    please follow the below document which might be helpful.


    sainath windows driver development.
    Wednesday, May 27, 2009 11:35 AM
  • Sainath,

    "direct access is a feature for windows 2008 R2"

    Indeed it is... I've not been testing on a Windows for Workgroups box :0)

    As I stated in my original post, i've been following the Direct Access documentation and yes I'm familiar with the Technical Overview document. As you can see from the questions, I'm a little bit further in my exploration of DirectAccess .....

    Is there any particular aspect of the above document that you may feel is relevant to my questions?

    Wednesday, May 27, 2009 4:58 PM
  • I'm experiencing a similar issue here.  On your client, can you ping any FQDN's of your internal network?    After the DA group policy is applied, I can no longer ping my domain fqdn Ex:  Corp.Contoso.local or dc1.corp.contoso.local.  I can stil ping DC1 with no issues. 

    This is also an issue with my DA Server.  Once the DA group policy is applied, DNS stops responding and I am unable to get any policy updates due to not being able to communicate with the dc.  If I manually add entries for dc1.corp.contoso.local and corp.contoso.local to the host file, I'm able to get user policy updates, but not computer.   Unfortunately I rebuilt the Win7 box and haven't tested adding anything to the hosts files on it.  I'll post results later.

    I receive the following event in the event log on the DA1 server

    Warning 5/30/2009 9:45:13 AM DNS Client Events 1006 None

    The client was unable to validate the following as active DNS server(s) that can service this client. The server(s) may be temporarily unavailable, or may be incorrectly configured. 2002:6325:2aa1:1:0:5efe:x.x.x.x

    But as you can see I can ping the server without any issue 

    C:\>ping 2002:6325:2aa1:1:0:5efe:x.x.x.x
    Pinging 2002:6325:2aa1:1:0:5efe:x.x.x.x with 32 bytes of data:
    Reply from 2002:6325:2aa1:1:0:5efe:x.x.x.x: time=2ms
    Reply from 2002:6325:2aa1:1:0:5efe:x.x.x.x: time=2ms
    Reply from 2002:6325:2aa1:1:0:5efe:x.x.x.x: time<1ms
    Reply from 2002:6325:2aa1:1:0:5efe:x.x.x.x: time=3ms
    Ping statistics for 2002:6325:2aa1:1:0:5efe:x.x.x.x:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 3ms, Average = 1ms


    Steps to reproduce the issue: 

    1. Build a fresh Win 7 RC box and leave it out of your Direct Access Group
             a) Ping your DNS server by Netbios - DC1
             b) Ping your DNS server by FQDN - DC1.Corp.Contoso.local
             c) Ping the Domain FQDN - corp.contoso.local
        DNS seems to work fine and all should resolve normally at this point 

    2. Add the DA Client machine to the DA group and do a GPupdate /force and Reboot
             a) Ping your DNS server by Netbios - DC1
             b) Ping your DNS server by FQDN - DC1.Corp.Contoso.local
             c) Ping the Domain FQDN - corp.contoso.local
        DNS stops responding once the DA policy is applied and you are no longer able to update group polices

    Did I miss configure a setting somewhere that's blocking internal DNS traffic?  I've rebuilt the lab in a Hyper-V environment from scracth 3 times now and had the same results all 3 times.

    If anyone else can verify or resolve the above issues I would appreciate it very much


    • Edited by Jerry Dismukes Saturday, May 30, 2009 3:09 PM forgot to add a reboot after the client policy update.
    Saturday, May 30, 2009 3:05 PM
  • I'm having the exact same problem...also tried to rebuild several times with no luck.

    And now I'm running out of ideas...
    Ilja Godau
    • Marked as answer by Mylo Wednesday, June 03, 2009 7:51 PM
    Monday, June 01, 2009 10:56 PM
  • Jerry,

    Yes ... I'm having similar problems to yourselves as mentioned in your posts. I can ping the DC from the DA server OK. I've tinkered with the GPO and FW settings and disabling the 3 DA GPOs and doing a GPUPDATE /FORCE ... and the DNS Monitoring test in the DA management console then works ok...  reverting back to the GPOs being enabled again ... kills the DNS test from the console.

    Selectively enabling/disabling the GPOs doesn't appear to make much difference.

    I had synthetic NICS configured too (having read your link) and replaced these with Legacy NICs and re-running the DA Wizard ... sadly... no difference.

    I've tried registering IPv6 Reverse Lookup Zones and ensuring PTR records register correctly in the 2002 zone in the hope that perhaps DA was doing reverse-lookups as part of the DNS test... this also does not appear to make a difference.

    Likewise, modifying the DA GPO and adding firewall rules opening up the DA-->DC connection also doesn't seem to make any difference.

    I'm going to:

    (a) have a look at the firewall rules for each respective GPO and see what's going on.. it looks like the GPMC doesn't capture all the changes settings in the summary settings (and admits as such) .. hopefully this is something that will be remedied before RTM for R2.

    (b) slap a network sniffer on the DA box tomorrow..

    I'm in Central Europe and it's late..... on the up-side... solidarity.. at least you're not alone ;-)

    Wednesday, June 03, 2009 10:04 PM
  • I just noticed another issue on the client machine.  After you force a policy update restart the firewall.  You will probably get an error when it tries to start again.  This seems due to the policy adding a reg key under
    hklm\software\policies\microsoft\windowsfirewall\phase2authenticationsets.  The actual keyname is different in both my hyper-v and vmware setup.  Also, I havent been able to find the setting in GPman, but the method of authentication is userkerb.  I removed all 4 connection security rules from the client policy and that value stays behind.  As long as I remove that reg key the firewall will restart on the client.

    I'm using Win7 build 7100 32bit for the client, but it shouldnt make a difference.  I'm going to rebuild the lab from scratch once more and add a 64 bit client to see if it makes any difference.

    Thanks for the response, hopefully we will have a few others with the same issue and one of us find a work around for it soon.

    Wednesday, June 03, 2009 10:19 PM
  • Jerry,

    Interesting.. Did you try restarting the IPsec Policy Agent service as well on the client?

    I'm just concentrating on the DA server stuff at the moment.. I haven't fired up the W7 client yet (thx for the info) because of the DNS error on the DA server. Likewise I'm on Win7 7100 build (and yes it's also an x86 build). I need to get a handle on the two domain-level GPOs as they're the ones that are applying to the w7 clients ... my DA server is in a separate OU with it's own DirectAccess GPO (it looks like the wizard finds the DN of the DA server and the OU under which the DA server is located and creates the GPO accordingly for the DA server).

    Wednesday, June 03, 2009 10:35 PM
  • I went in to the DA console and reapplied the setings from there and now the firewall starts without error on both sites after a gpupdate.  Oh well, back to the drawing board. 
    Wednesday, June 03, 2009 11:03 PM
  • erk :-)
    Wednesday, June 03, 2009 11:13 PM
  • I have the same issue (DNS) as you guys have. Unfortunately i did so many changes to my vmware test environment that i have to setup a clean environment again before i can do some troubleshooting :-)

    I would really like to get this working as imo DA is the most interesting and most important improvement in R2 and i want to set this up for business testing in our company as soon as the final R2 and Win7 is out.

    Thursday, June 04, 2009 2:29 PM
  • Same here.
    I've stopped the Windows firewall (on all the profiles) on both DA and DC and the DNS looks green on the monitoring page.
    Andrei Ungureanu
    Thursday, June 04, 2009 8:24 PM
  • Just had a bit time to build a new test lab. Same issue as before.

    "None of the internal dns servers ...blabla"

    I really dont have any idea what this could be as dns is working fine if i test it in the network.
    If anyone has an idea (no matter how crazy it sounds) please let me know.

    Friday, June 05, 2009 5:20 PM
  • Yes..same here. Stopping the firewall and then it looks green on the monitoring page.

    But, what about the clients? Can you get them to work?

    Unfortunately no luck here.
    Ilja Godau
    Friday, June 05, 2009 11:07 PM
  • Yes..same here. Stopping the firewall and then it looks green on the monitoring page.

    But, what about the clients? Can you get them to work?

    Unfortunately no luck here.
    Ilja Godau

    Nope... stopping the firewall causes the lights to get green but the clients can't connect anyway.
    I wonder if there is anyone out there who managed this?
    Monday, June 08, 2009 3:54 PM
  • Hi all,

    Just thought I'd add some more testing notes:

    Enabling Allow Outbound (Default) on the Domain profile for the firewall had the same effect for me with green-lighting the DNS test from the DA console. Of course, the assumption that all 3 GPOs are still disabled here applies (as per Jerrys testing)..

    There are a lot of configuration options subsumed into the DA configuration that cannot be seen with the GPMC Console (and the console warns to this effect), so "possible" offending configurations that aren't visible in the GPMC may be being set in DirectAccess Policy-{GUID} policies at the domain-level. In particular, I'd be interested in knowing what unseen changes these rules are making:

    - DirectAccess Policy-DaServertoCorp
    - DirectAccess Policy-DaServertoDnsDC

    In my case there are also policies that are not active because I haven't stipulated settings in the DA wizard.

    - DirectAccess Policy-ClientToMgmt
    - DirectAccess Policy-ClientToAppServer

    Doing a netsh dump to file identities that the wizard sets the appropriate settings for the ipv4 and ipv6 settings for interfaces, together with Internet/LAN/6to4/Teredo/ISATAP/IPHTTPS and DA forwarding/advertising settings.  I'm still non-plussed at what the actual DNS test is doing, as I don't any configuration reference to it.

    I'm using a 2-Tier PKI with an enterprise subordinate CA and have tried trusting the intermediate or the Root CA to no avail.

    I'd repeat Stefan's question:

    Question: Is DirectAccess broken in RC Build 7100?

    I'd appreciate some response from Microsoft before spending more signficant time/effort on this..... It's been extremely quiet :-)


    Tuesday, June 09, 2009 5:47 PM
  • If DC does not appear on the DNS of the IPV6 address of DC, you can try to use DNS server to resolve  dnscmd /config /globalqueryblocklist wpad and restart the DNS service

    Thursday, June 11, 2009 3:00 AM
  • Kevin,

    The DC does have an IPv6 address in DNS. The dnscmd /config .... and the service restart has no effect. AFAIK everyone on this thread continues to has this problem

    "None of the internal DNS Servers 2002:xxxxxxx:IPv4 that DirectAccess client computers use for name resolution is responding. This prevents DirectAccess clients from resolving names in the internal namespace and connecting to the internal network. Make sure the DNS Servers are online"

    I'm starting another thread "Is Direct Access broken in R2 RC1 (7100)?".. hopefully we can get someone from the DA team to respond.

    Thursday, June 11, 2009 7:30 AM
  • Hi Mylo,

    As we speak I have some time today to give you a hint. I you do not succed I'll will make next week a little presentation and i will post it here.

    The problem is with the legacy network connection.

    First solution: I use bridge connections there are more "fast and furious" so, after you assign an internal network to the virtual machine with a specific name (to know who is in the real enviroment), you select on the real machine the internal adapter and the external network card and you connect toghether as a bridgge with right mouse click. So your network adapter will be no more in Legacy mode and will work with full options.

    The second solution: I use on the real host machine with server 2008 r2 the role ofnetwork and remote access to reansform the real machine in a router I write in the routing path the coresponding routing and what filtering I need between the phisical network card and the internal network card of the virtual machine i use in virtual enviroment to connect to from internet with DA.

    In both situation it works for me.
     The first one is quicker the second one is more secure you can control everything from the server router.

    Now I am very busy to can make the presentation for that but i hope next week I'll do it for you if you can't fix your problem


    Friday, June 19, 2009 7:56 AM
  • Hi Alex,

    Nice to meet you at the MCT Summit and thanks for responding.

    Most of the people from what I can gather are testing DA under Hyper-V. I'm using Legacy Network Adapters rather than Synthetic ones as it's been blogged that the latter may cause problems. In the test machine I'm using at the moment I'm fairly restricted with adapters. I'm going to move the test environment out onto another Hyper-V multi NIC system tomorrow just in case this is causing issues. Right now the configuration is:

    Single Hyper-V Host:

    Internet Interface (Hyper-V Interface bound to physical NIC)
    - R2 Direct Access Server ( and
    - ISP DNS Server (
    - Windows 7 Router ( with ICS enabled

    LAN Interface (Hyper-V Internal Interface)
    - R2 Direct Access Server (
    - R2 DC/CA (
    - R2 Application Server (

    Client LAN (Hyper-V interface Private)
    - Windows 7 Router (
    - Windows 7 Client (192.168.137.x - provided by W7 Router ICS)

    Connectivity is find between all segments and I can route from the ICS subnet OK to the Internet subnet, at least in ipv4. ipv6 is something else entirely ;-)

    Just to confirm (as I read it), the Internet registered DNS records for (crl.contoso.com and da.contoso.com), i.e. the two contiguous public addresses, must point to the first of the two public addresses, with the second being used by DA itself (as seen in the DA Management Console during the setup wizard).

    So using the above example:
    6to4 and Teredo and IP-HTTPS bind to, which has an A record registered for both crl.contoso.com (CDP/AIA) and da.contoso.com is used by Direct Access and this is consumed by the setup wizard.

    I'm using made up IP address for public, so if you see any anomolies it's probably a typo <g>

    Friday, June 19, 2009 8:28 PM
  • I have run the Step by Step guide many times now and I am having variations of the same problems discussed above. I have witnessed the DNS issues above many times and it appears that the client will often refuse to start resolving DNS again when back in the Domain once it has been exposed to the internet.

    The event message as above:
    "None of the internal DNS Servers 2002:xxxxxxx:IPv4 that DirectAccess client computers use for name resolution is responding. This prevents DirectAccess clients from resolving names in the internal namespace and connecting to the internal network. Make sure the DNS Servers are online"
    Keeps appearing on the DA server.

    Can someone at MS please run through the Step by Step guide themselves and attempt to verify if there is more that can be done. Get someone who has not set it up before to test it.

    I have now worked on this for the best part of a week.. I was up until 2am last night!!! I have followed the SBS with a fine tooth comb. I am using RTM of both 2008 R2 and Win7.

    Unfortuantely I will not be demoing this at TechEd in Australia now and due to the many caveots I have experienced I will not be recommending this to any clients yet! I was excited about this product and being able to showcase it but I am now disapointed.

    Please reply ASAP. Thanks heaps.
    Friday, September 04, 2009 12:10 AM
  • Are you using physical or virtual machines for your lab?  If you are using Hyper-V, you have to install the OS from media on all your servers.  If you used sysprep, I think it breaks the isatap adapter somehow.  I went through 3 or 4 tries using a syspreped image and then decided to start from scratch.

    Run netsh int ipv6 show int on your DNS server and see if the isatap interface shows up as isatap.domain.whatever or if it is something different.

    I was able to setup DA using the RTM version sof both 2008 R2 and Win 7 when it RTM'ed. 

    It's not much, but I do know it does work.  


    Friday, September 04, 2009 12:43 AM
  • Thanks heaps for your advice Jerry..

    Yes I am using Hyper-V.

    I can't see myself trying this in the near future but as soon as I do I'll get back to you.


    Saturday, September 05, 2009 12:25 PM
  • Hi

    I had the same problem, and like Jerry says its related to using Syspreped imaged (fast and easy, but sadly it does do something to the isatap drivers)
    The strange thing is that the problem was a bit different in my 2 tries, first time I could IPv6 ping local resources from "internet", but no name resolution, the second time the ping also failed.

    Have had a working "beta" version running before I knew it should be working, the only thing I could think about that was different was that the beta was clean installed without sysprep

    Building the lab from clean DVD install fixed it, everything are now running perfect her :-)

    If anybody know a solution to "reinstall" isatap that might do the trix.


    Saturday, September 05, 2009 10:34 PM
  • Hi

    I am having the same issue. I have 2 Win7 laptops that are having the same dns resolving errors. UAG DA was set up 3 weeks ago, the 2 laptops were OK & had no issues until Monday this week.

    Hyper-v environment, all win2k8 R2 ent servers, all fresh buildsn no sysprep...this is a real PITA.

    Cmon Microsoft get a grip here.....
    Thursday, January 14, 2010 9:49 PM

  • Are you getting the issue in the DA management console?   If it was running at one point and quit working, then it may not be a server related issue.  I've had DA not work while in one hotel and it was because I didnt specify give me a public IP when it setup the proxy to connect. 

    Open your network & sharing options, then you should see a troubleshoot problems link.  CLick on it and you can tell it to troubleshoot connecting to a workplace via directaccess. 

    Run Netsh int IPv6 show int from a command prompt to make sure everything on the client end is connected.  Teredo, 6to4, iphttpsinterface and isatap.  After that, there are lots of NETSH commands to run to see if everything is running correctly on the client side. 

    Hope that helps some
    Thursday, January 14, 2010 10:19 PM
  • Steve,

    Since my original post way back (time flies), I'm using UAG  under Hyper-V to demonstrate DA at the moment and it's working fine. I sidestepped the IPv6 integration issues by configuring the UAG server as an ISATAP router (with the appropriate A record registered in DNS pointing back to the UAG box). In addition, because of DNS64/NAT64, I haven't had to do anything with internal resources IPv6-wise, i.e. I haven't configured IPv6 on the internal interface of the UAG server. The configuration wizard identifies that IPv4 is only configured on the internal adapter......

    Tuesday, January 19, 2010 12:26 AM
  • So have you made it?Can you explain it more detailedly? Thanks very much!

    Monday, January 25, 2010 10:54 AM
  • If you're testing DA, you might want to investigate the UAG. It will make it a bit easier to configure, and supports more scenarios that you'll want to support in your production deployment.


    Anywhere Access Team
    MS ISDUA Anywhere Access Team
    Monday, January 25, 2010 11:43 AM
  • Thanks,Tom
    I followed the "step by step"document to make my DA test without UAG,but when connect the win7 client to internet . The question is the same with this :http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2networking/thread/00efa0f5-d8b8-456c-81b6-6747b57ff7c0
    do you have some ideas about this ?

    Tuesday, January 26, 2010 4:16 AM