ISATAP Recommendations for DirectAccess Deployments

From a client perspective, DirectAccess is an IPv6 only solution. The client communicates with the DirectAccess server and intranet resources using IPv6 exclusively. To enable communication between DirectAccess clients and IPv4 only resources on the Intranet, Windows Server 2012 DirectAccess (as well as Forefront UAG/DirectAccess) includes two important protocol translatorsDNS64 and NAT64. Unfortunately DNS64 and NAT64 provide only inbound protocol translation, so another measure is required for communication initiated outbound to connected DirectAccess clients. To support outbound communication originating from the Intranet to connect DirectAccess clients, the DirectAccess server is configured as an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router. ISATAP is an IPv6 transition protocol that allows hosts on the intranet to initiate outbound communication to DirectAccess clients on the Internet by tunneling IPv6 communication over the internal IPv4 network. ISTAP is enabled by populating internal DNS with a host record called ISATAP that resolves to the IPv4 address assigned to the Internal network adapter on the ISATAP router, in this case the DirectAccess server (don’t forget to remove ISATAP from the DNS global query block list!). When a client resolves ISATAP to an IP address successfully, it enables an ISATAP tunnel adapter and assigns itself an ISATAP IPv6 address. Once enabled, any host with an ISATAP tunnel adapter configured can initiate outbound communication to DirectAccess clients on the Internet.

When configured and enabled, ISATAP opens up new and interesting network communication scenarios. For example, a helpdesk engineer can proactively initiate a remote desktop session to a remote client connected via DirectAccess to troubleshoot an application. Systems management engineers can push software out to DirectAccess clients without requiring an agent on the remote client to “phone home” to receive software updates. This model is often referred to as “manage out”.

In the early days of DirectAccess with Windows Server 2008 R2 and Forefront UAG, configuring and enabling ISTAP as described above was standard operating procedure. However, we soon learned that there are some serious drawbacks to deploying ISATAP. While the DirectAccess manage out scenario is an important and frequently requested feature of a DirectAccess implementation, it often causes more trouble than it solves. In its default configuration, ISATAP is a global change that affects all hosts that can resolve the hostname ISATAP to an IP address. The challenge here is that this change can break or impair normal network communication for some hosts on the Intranet. For example, if an Intranet host is able to resolve a public hostname to an IPv6 address, it may attempt to connect to the site via ISATAP. Unfortunately, in this scenario ISATAP does not lead to the public Internet. Rather, ISATAP is used to provide network connectivity exclusively for our DirectAccess clients. Since IPv6 is preferred in most modern operating system’s networking stacks, it can lead to failed or seriously delayed communication to Internet resources. In addition, once ISATAP is enabled globally there will be a lot of IPv6 communication taking place on the network, which in large enterprise networks can be a source of confusion for those individuals with the responsibility for monitoring the network.

ISATAP also suffers from a lack of robust monitoring tools for this very essential service. Additionally, ISTAP turns the OSI model upside down. ISATAP relies on upper-layer protocols (DNS) to provide its service. If there are issues with DNS that prevent proper name resolution, ISTAP routing will cease to function, which is fundamentally backward.

As I mentioned earlier, by default, ISATAP is a global setting. However, in most environments there will only be a few systems that will require the ability to initiate outbound communication from the Intranet to DirectAccess clients. Typically these will be helpdesk administrators’ workstations or management systems. Today we are recommending that you deploy IPv6 on any internal systems that will participate in any DirectAccess manage out scenarios. Unfortunately this will not be possible in many cases, as additional network changes are often required to support IPv6 on the Intranet. In these cases we recommend that instead of configuring ISATAP in DNS globally, you target individual systems for ISATAP configuration as required. This can be accomplished in a number of ways.

Group Policy – This is best way to deploy ISATAP settings to systems that require DirectAccess manage out functionality. It is the easiest to manage and the most scalable as well. It involves creating a unique ISATAP hostname and assigning it to individual systems via group policy. Thankfully my buddy Jason Jones has already documented that process here, saving me the time and effort of doing it myself. Why reinvent the wheel, right? : )

PowerShell – Using PowerShell is an alternative method of configuring an individual system to use ISATAP. Although not as scalable as the group policy method, it is still very effective. On the system that requires network connectivity to DirectAccess clients, from an elevated PowerShell prompt execute the following command:

Set-NetISATAPConfiguration -Router <NameOrIPAddress>

Netsh – Another command line method for configuring the ISATAP is to use netsh.exe. From an elevated command prompt execute the following command:

netsh interface isatap set router <NameOrIPAddress>

HOSTS file – This is the least desirable way to configure ISATAP, but I’ll mention it here because it is quick and simple and does work. On any system that requires ISATAP for DirectAccess manage out, simply edit the HOSTS file in C:\Windows\System32\Drivers\Etc and add a host record for ISTAP that resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. Obviously this is the least scalable alternative and should only be used in test environments or very small production networks.

As you can see there are numerous drawbacks to configuring ISATAP on a global scale. Fortunately there are simple and effective workarounds that allow you to target specific systems for ISTAP configuration. Choose the one that works best for you and have fun managing your DirectAccess clients!

Network Interface Configuration for Multihomed Windows Server 2012 DirectAccess Servers

When preparing a Windows Server 2012 DirectAccess server with two network interfaces, proper configuration of the network interfaces is vital to the operation and security of the remote access solution, especially in edge-facing scenarios. Preparing a server with two network interfaces might seem trivial, but there are some important and often overlooked settings that may lead to trouble. In this post I’d like to outline the proper network interface configuration for a Windows Server 2012 DirectAccess server in an edge-facing deployment scenario. It is important to note that you should configure your network interfaces prior to installing and configuring DirectAccess.

The first step is to rename the network interfaces with intuitive names that identify their role. Typically I use Internal and External. This will make DirectAccess configuration much easier, as you will see when you are configuring DirectAccess using the deployment wizards. To rename the network interfaces, open the Networking and Sharing Center from the Control Panel and choose the option to Change adapter settings. Optionally you can simply highlight the network interface you wish to rename and hit F2. Assign new names to the network interfaces as appropriate.


Next, right-click the Internal network interface and choose Properties. Enter an IPv4 address, subnet mask, and DNS servers as required. Notice that I have not entered a default gateway here. This is absolutely critical and one of the most common mistakes made when configuring a multihomed DirectAccess server. On a server with multilple network interfaces there can be only one default gateway, and the gateway must reside on the External network interface.


In the absence of a default gateway on the Internal network interface, static routes will be required to reach any remote internal subnets. To add a static route, open an elevated PowerShell command prompt and add any necessary routes using the following syntax:

New-NetRoute -InterfaceAlias <Interface_Name> -DestinationPrefix <SubnetID/Mask> -NextHop <Gateway_Address>

For example, my lab network has a remote subnet of that is reachable through a router interface of

New-NetRoute -InterfaceAlias Internal -DestinationPrefix -NextHop

It’s also a good idea to unbind any protocols that are not required. For example, in my implementation I will not be leveraging QoS or NIC teaming, nor will I require the Link-Layer Topology Discovery services so I’ve unchecked those boxes accordingly.


Perform this same exercise for the External network interface. Enter an IPv4 address and subnet mask, and this time be sure to include the default gateway for the External network. Notice that I have not entered any DNS servers here. Resist the urge to enter the DNS servers provided by your ISP. They are not required here.


Since this DirectAccess server will be edge-facing and connected directly to the public Internet, it is a good idea to unbind all protocols from the network interface with the exception of IPv4 and IPv6.


In addition, uncheck the option to Enable LMHOSTS lookup and also chooseDisable NetBIOS over TCP/IP.


One last change that needs to be made, and perhaps the most critical and often overlooked setting, is the network interface binding order. This change can be made by pressing the Alt key on the keyboard to display the drop-down menu and choosing Advanced Settings.


Make certain that the Internal network interface is listed first in the list of connections.


So that’s it! You can now proceed with installing and configuring DirectAccess in full confidence that your network interfaces are configured properly!

DirectAccess on the Microsoft Surface Pro

At Microsoft TechEd North America 2013 I had the privilege of (finally!) acquiring both a Microsoft Surface RT and a Surface Pro. I’d been wavering back and forth on which one to purchase for many months. As it turned out, my indecision (and admittedly some procrastination!) paid off. As you are probably aware, Microsoft was offering the Surface RT 64GB for $99.00 USD and the Surface Pro 128GB for $399.00 USD to TechEd attendees and third-party speakers. Needless to say I purchased both! I love the Surface RT for general Internet use like web browsing, e-mail, etc. The battery life is great and having Office apps is tremendously productive. However, as a technology geek I really like the power and flexibility that the Surface Pro offers. Since it is a full-fledged PC, I can install whatever software I like on it.

Being able to join a domain and enable DirectAccess would, of course, be the icing on the cake. The Surface Pro comes pre-installed with Windows 8 Professional, which means I can join a domain but unfortunately it doesn’t support DirectAccess. My plan was to wipe the device and reload Windows 8 Enterprise when I returned from the conference. As luck would have it, I ran in to my good friend and fellow Microsoft MVP Jordan Krause, and I was surprised to find that he had already upgraded his Surface Pro to Windows 8 Enterprise, joined it to his domain, and had enabled DirectAccess right there at TechEd! How did he do this so quickly? It turns out that it is as simple as mounting the Windows 8 Enterprise ISO and performing an in-place upgrade by launching setup.exe. And no, contrary to what some have said, you can’t simply input your Windows 8 Enterprise license key and magically turn Windows 8 Professional in to Windows 8 Enterprise. It will of course activate, but it will still be Windows 8 Professional unless and until you perform the actual upgrade to Windows 8 Enterprise using the installation media.

So, upon returning home from TechEd I promptly upgraded my Surface Pro to Windows 8 Enterprise using the steps Jordan outlined here. Worked like a charm! I was able to join my lab domain and successfully establish DirectAccess connectivity on the Surface Pro. I did encounter a few issues when I attempted to refresh the device, however. To reset the device, I clicked Settings on the charms menu (swipe-in on the right or Window Key+C) and clicked Change PC Settings. Next I selected General and chose the option to Refresh your PC without affecting your files and received the following error message:

Insert media. Some files are missing. Your Windows installation or
recovery media will provide these files.

Insert Media on the Surface Pro

Selecting the option to Remove everything and reinstall Windows yielded the same error. Fortunately it was easy enough to resolve. To begin, I created a folder on the C: drive called WinRec. Next, I mounted the Windows 8 Enterprise ISO, navigated to the \Sources folder and copied install.wim to C:\WinRec. Finally, I opened an elevated command prompt and executed the following command to register this file as a recovery image:

reagentc.exe /setosimage /path C:\WinRec /target C:\Windows /index 1

Now when I select the option to Refresh your PC without affecting your files or Remove everything and reinstall Windows the process continues normally. Once the process is complete, there will be a few drivers missing which you can download here. After that everything was good to go! Obviously the solution I’ve described here is only really effective for one-off deployments of Windows 8 Enterprise on the Surface Pro. If you’re considering an enterprise-wide deployment, have a look at the Surface Pro Enterprise Deployment Guide [PDF], which includes detailed, prescriptive guidance for deploying Windows 8 Enterprise on the Surface Pro.

Disconnecting DirectAccess Clients on Windows Server 2012

DirectAccess provides seamless and transparent, always-on remote network connectivity. It does this without requiring action from the user. While this is an important feature and benefit of a DirectAccess remote access solution, it can also present a challenge for security administrators when a DirectAccess client device is lost or stolen.

To prevent a DirectAccess device from establishing remote network connectivity, simply disable or delete the device’s computer account in Active Directory. This will prevent the establishment of the IPsec tunnels, which are authenticated in part using the computer account and Kerberos. The caveat here is that this will not terminate a session that is already established. In this scenario it will be necessary to also proactively disconnect the already established IPsec tunnels from the client in question. To accomplish this, open an elevated PowerShell prompt on the DirectAccess server and execute the following command:

Get-NetIPsecMainModeSA | where {$_.RemoteFirstId.Identity –like “*computer_name*”} | Remove-NetIPsecMainModeSA

For example, to terminate established IPsec tunnels for a computer name CLIENT1 the command would look like this:

Get-NetIPsecMainModeSA | where {$_.RemoteFirstId.Identity –like “*client1*”} | Remove-NetIPsecMainModeSA

When the client attempts to reestablish its connection it will fail to authenticate because its computer account is no longer valid in Active Directory. Now the trick is to get those users to tell us immediately when they’ve lost their laptops. That’s an entirely different problem, however. 😉

Special thanks for my good friend Jason Jones for his input on this solution. Thanks JJ!

The Drawbacks of Supporting Windows 7 Clients with Windows Server 2012 DirectAccess

Windows Server 2012 DirectAccess includes many new features to enhance scalability and performance. To take full advantage of many of these capabilities you must use Windows 8 Enterprise edition for your DirectAccess clients. Windows 7 Enterprise and Ultimate clients are supported, but there are a few important features that can’t be leveraged. Here are some examples:

IP-HTTPS Improvements – Windows Server 2012 supports NULL encryption for the IP-HTTPS IPv6 transition protocol. This eliminates the performance penalty and negative scalability caused by needlessly redundant encryption of DirectAccess client communication (IPsec encrypted traffic encrypted again with SSL/TLS). Windows 8 clients only request these NULL encryption cipher suites when establishing DirectAccess connectivity. However, Windows 7 clients do not support NULL encryption and will instead request an encrypted cipher suite when performing SSL/TLS negotiations.

Automatic Site Selection for Multi-Site – With Windows Server 2012 the administrator can configure multiple DirectAccess gateways to provide geographic redundancy for DirectAccess clients. Windows 8 clients are configured to intelligently select the nearest entry point and automatically reconnect to another gateway if the connection to the originally selected entry point fails. In contrast, Windows 7 clients can be configured for only a single entry point. The Windows 7 client is unaware of any other entry points and if the original connection becomes unavailable for any reason it will not have corporate network access until that entry point is back online.

Public Key Infrastructure (PKI) – The removal of the requirement to have an internal PKI to support DirectAccess clients is a popular feature for many organizations wanting to deploy DirectAccess (I don’t necessarily agree with this, but that’s the subject of another post!). Although Windows Server 2012 DirectAccess can be configured to use self-signed certificates, this deployment model is only supported for Windows 8 clients. If you plan to provide support for Windows 7 clients you will need a working internal PKI.

DirectAccess Connectivity Assistant – The Windows 8 client includes native functionality to indicate the status of DirectAccess connectivity and also includes a facility with which to quickly gather detailed log data for troubleshooting. Windows 8 clients can also establish DirectAccess connectivity when they are located behind an authenticating web proxy. For Windows 7 clients, the DirectAccess Connectivity Assistant (DCA) provides some of this functionality, but it is an optional component that must be deployed separately. Even with the DCA installed, Windows 7 clients cannot establish DirectAccess connections when a web proxy server requires authentication.

Although Windows 7 Enterprise and Ultimate editions are supported for DirectAccess when connecting to a Windows Server 2012 DirectAccess server, Windows 8 Enterprise clients should be deployed whenever possible to ensure the best and most complete experience.

%d bloggers like this: