Note: The issue described in this article has been resolved in Windows 10 version 1703 (Creators Update). Making these changes is no longer required after installing the Creators Update release of Windows 10.
Introduction
For organizations that have implemented DirectAccess manage out using the Intrasite Automatic Tunnel Addressing Protocol (ISATAP), you may find connecting to remote DirectAccess clients by hostname using Windows 10 or Windows Server 2016 fails. Connections to remote DirectAccess clients using Windows 7, Windows 8.x, Windows Server 2008/2008R2, and Windows Server 2012/2012R2 work without issue.
Troubleshooting
On a Windows 10 or Windows Server 2016 host configured to use ISATAP for DirectAccess manage out, the remote DirectAccess client resolves to an IPv6 address correctly.
In addition, a route to the DirectAccess client’s IPv6 prefix is also present in the routing table.
Nevertheless, attempts to connect to the remote DirectAccess client by name fail.
The DirectAccess client is reachable by its IPv6 address, however.
Known Issue
There is a known issue with Windows 10 and Windows Server 2016 DNS client that prevents manage out using ISATAP on these operating systems from working correctly. A while back I wrote about implementing some registry entries as a workaround for this issue on Windows 10. Recently, Karsten Hentrup brought another effective workaround to my attention that also involves adding a registry entry on the ISATAP client machine. This method is preferred as it requires only one registry entry and does not adversely affect existing DNS operation. To make this change, on each machine that requires DirectAccess manage out functionality open an elevated PowerShell command window and run the following command.
New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name AddrConfigControl -PropertyType DWORD -Value 0 -Force
Summary
When using ISATAP, ensure that this workaround is implemented on any Windows 10 or Windows Server 2016 machine that will require manage out functionality to remote DirectAccess clients.
Additional Resources
ISATAP Recommendations for DirectAccess Deployments
DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out
Ryan Arnold
/ March 31, 2017Thank you! Was wondering why my server 2016 was having issues connecting to remote clients.
John2
/ April 21, 2017Seems like a kludgy workaround.
Is this a bug Microsoft knows about that will be fixed in an update for Server 2016 and Windows 10?
Richard M. Hicks
/ April 25, 2017Agreed. Microsoft is aware of the issue. Not sure when/if a fix is forthcoming. ISATAP is not commonly used and Microsoft may decide not to fix it.
Keith Krus
/ April 26, 2017I am experiencing this exact issue with my Help Desk clients trying to connect to Deployed Staff thats is connected via Direct Access. We are a majority Windows 10 shop. Sometimes the Help Desk is able to connect to Direct Access clients via SCCM and sometimes they’re not able to connect. The only common denominator that I have been able to find is the way the manage out client is resolving the DNS name of the DA client. If the manage out client is able to resolve the workstations via IPv6 address, then SCCM and PING works with no issues. If the workstation is unable to resolve via IPv6 then the manage out client is obviously not able to connect to the Direct Access client. Not sure why, but DNS resolving flip flops IPv4 and IPv6. I will try your registry entries and see if that corrects the issue.
Richard M. Hicks
/ April 27, 2017IPv6 must be used to communicate outbound to remote connected DirectAccess clients, no doubt about that. If the management server can’t resolve the client’s hostname to an IPv6 address, it won’t work. Keep in mind also that if the client restarts, it will often get a new IPv6 address and there may be a period of time in which internal DNS records may be stale. However, if you are trying to manage out from a Windows 10 or Windows Server 2016 box you’ll definitely need to implement the workaround outlined in this article for sure. 🙂
Andrew
/ September 25, 2017Not sure if anyone else is, but I’m seeing this in Win 10 1703 15063.608. The reg entry did not resolve the issue however. In SCCM Remote Control, it will only connect to the remote machine if I use the IPV6 address. When I ping the remote machine in the command prompt, it resolves to the IPV6 address and replies just fine. Config Manager version is 1706.
Richard M. Hicks
/ October 16, 2017This is a known issue where the SCCM server does not use the typical name resolution request process. Instead it attempts to connect to the IPv4 address obtained from the latest DDR scan. If you force a new DDR scan while the client is connected via DirectAccess, it should work after that. 🙂
Justin
/ October 1, 2018“ISATAP is not commonly used”
If that’s the case then for Win10 and Srv2016 scenarios what is the recommended method for managing out? I couldn’t get anything inside to connect with my outside clients until I turned ISATAP back on but even then only the DA server. Nothing else will connect to them.
Richard M. Hicks
/ October 4, 2018Microsoft’s formal guidance is to deploy IPv6. However, that’s not always feasible so ISATAP can be used to support manage out for DirectAccess clients.
kelemvor33
/ April 21, 2020I just went through the post to set up ISATAP and thought I might be having this issue. I can run all the commands fine but cannot ping over the IPv6 address. I simply get Transmit failed. General failure.
I’m trying to set this up so we can use PDQ Inventory to manage our remote users when on DA since we’ve been unable to do that up until now.
I tried enabling the Remote Desktop firewall rule but it didn’t help. Is there a firewall rule that allows pings to go through? Also, is the Win10/2016 issue still an issue or has it been resolved already?
Thanks!
Richard M. Hicks
/ April 22, 2020The issue described in this post has long since been resolved. If you are having ISATAP connectivity issues it most certainly isn’t related to this update.
Dit
/ February 9, 2021Seems Windows Server 2019 and Direct Access, ISATAP doesn’t give an IPv6 to their configured clients. Is there anything to add or workaround? It is Enabled but ni IPv6. Works correct and seamlessly in 2016.
Richard M. Hicks
/ February 10, 2021Correct. ISATAP has been deprecated and isn’t enabled by default in Windows Server 2019. You can enable it (which happens if you isntall DirectAccess) but I’ve found that advertising and forwarding often get disabled when the server restarts. You’ll likely have to enable those to restore ISATAP functionality. You can find a script to do that here: https://github.com/richardhicks/directaccess/blob/master/Reset-DaIsatapConfiguration.ps1.
Chris H
/ September 25, 20236 years later and it’s still an issue. And here is Richard once again saving my bacon. Just upgraded a bunch of 2012 R2 servers to 2016 and found this little issue.
Thanks again!
Richard M. Hicks
/ September 25, 2023Good times! 😉 Microsoft has no plans to fix this (ISATAP is deprecated, after all) but it still works. 🙂