Testing DirectAccess on Hyper-V? Use Legacy NICs

Testing DirectAccess on Hyper-V? Use Legacy NICs

  • Comments 2
  • Likes

We recently released the DirectAccess Step by Step Guide and many customers are using it to start understanding and testing DirectAccess in their labs, which is great. However, if you're planning to virtualize your lab environment on Hyper-V, you should ensure you're using Legacy Network Adapters for the child partition where you're running the DAS. Using the default synthetic NICs is OK for all the other resources in the test lab, but for the DAS itself, it's important to have both the Internet and Corpnet NICs as legacy ones, to ensure proper passing of traffic between both sides of the DAS. If you use the default synthetic adapters, you may end up in a situation where traffic doesn't properly flow from the outside to the inside, even though all your IPsec, 6to4, Teredo, and IP-HTTPS settings are correct. Basically, you'll be in a situation where connectivity will fail at a basic level, with you not even being to successfully ping the internal DNS server using its ISATAP address.

If you've already built your lab on Hyper-V using the synthetic adapters, the fix is pretty simple. Just replace them with legacy ones, reconfigure the IP addressing as specified in the guide and rerun the DirectAccess wizard, again supplying all the information specified in the guide. After doing so, all your traffic should flow properly.

  • morello

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I'm using legacy nic's and still having the issue with not being able to communicate with DNS.  I've disabled the DA GPO's for esting.  

    I had dns setup only on my DC and for testing purposes and found that as soon as I enabled DA and forced a policy update that I lost all connectivity with DNS and gpo would not update again due to not being able to find the DC.  After that it's a rebuild or reapply a snapshot that was taken prior to policy being applied.

    To get around that issue, I've installed DNS on my DA Server as a secondary zone and use it for all the DNS settings.  At this point the the monitoring tab shows that DNS is fine.  As soon as I enable the DA server GPO DNS shows as failing in DA monitoring.  As soon as I disable GPO and force a policy update DNS shows it it running properly.  

    I've narrowed the settings down to the three connection security rules, but at this point I am unsure if I just have a configuration issue or if there is an issue with the way DA configures the actual policies.

    I have yet to start troubleshooting the Win 7 client policy, but the same thing happens on the client.  With the exception that as soon as policy is applied you can not ping anything internal by fqdn, but you can ping by netbios.  At that points it's revert to a previous snapshot.

    I've rebuilt the Hyper-V lab 3 times now using the guide linked above.  I did leave out the inet server since i have static ip's from my isp already.  I'm assuming that shouldn't be an issue at this time considering I can't get the internal communication up and running yet.

    Any suggestions for me offhand?  I've responded to a similar post on Technet under Server 2008 R2 Networking to see if anyone else is having the same issue.

    http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2networking/thread/4ae72bee-0590-4f56-beed-ea6265329f74  

    Thanks for any help you may have to offer

  • Maybe an update to the DA guide would help others? It would have helped me save the 4 days troubleshooting this.