ISATAP on 2019 Direct Access Server doesn't work RRS feed

  • Question

  • Try to build an easy "Direct Access Manage Out" solution for accessing connected DA clients, according and other guides. Have done that before on earlier server versions, and it worked from the start.

    But on server 2019, there seems to be a problem with the ISATAP router. 

    • get-NetIsatapConfiguration tells me that the ISATAP router is enabled
    • netsh interface ipv6 show interface shows two connected ISATAP interfaces: One with the name "isatap.domain.local", the other with the name "isatap.{GUID}". The GUID corresponds to the GUID of the Interface of the internal NIC of the DA server.
    • But despite all that, the ISATAP interface with the name "isatap.domain.local" has no IPv6 address (except the link local address). 

      Have examined the same on a working 2012 R2 direct access server. The very same interface has a valid IPv6 address assigned:

    Have posted this question in the server general forum, and then in the Hyper-V forum as well. From this post, I got answers from several users that ISATAP adapters are never visible in device manger of server 2019. In earlier server versions, the ISATAP adapters were always visible on any server system when selecting "show hidden devices" in device manager.

    So I just know that this ist normal in server 2019, but still havn't got any solution for the problem since about a week.

    Any advice? Thank you in advance for any help.


    Wednesday, March 18, 2020 3:38 PM

All replies

  • Hi,

    Thank you for your question.

    I am trying to involve someone familiar with this topic to further look at this issue.

    There might be some time delay. Appreciate your patience.

    Thank you for your understanding and support.

    Best regards,


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact

    Thursday, March 19, 2020 9:13 AM
  • Hi FranzSchenk,

    +1 We have the same issue with a new deployment - we replaced a 2012 R2 DA with 2019... having issues with manage out and came across your post.  Same symptom the DA server does not show a IPv6 address on ISATAP.

    Have you made any progress by chance?  Seems like a bug in 2019 maybe?

    I will update this post if we work it out in the meantime :)



    Tuesday, March 31, 2020 11:13 AM
  • We're having a similar problem, our VMM 2019 server installed on Windows Server 2019 can't get an ISATAP address from the 2012 DA server which is configured as the ISATAP router via group policy. So it appears to be a global problem with Server 2019 not actually assigning the ISATAP address at all.

    All of our 2016 and below systems get and use ISATAP config from the same DA server via the same group policy no problem and manage out works fine on those. But our new VMM2019  on 2019 server won't/can't get its ISATAP adapter going.

    Tuesday, March 31, 2020 6:42 PM
  • Because we couldn’t bring up the ISATAP router at all on our 2019 DA server, we opened a PSS Call for this issue.

    We really tried to insist, but Microsoft is extremly unwilling to provide any support, they write that ISATAP is no longer supported at all on server 2019, regardless of all Microsoft documentation that states otherwise.

    Some quotes from the Microsoft support engineers:
    – “Per reccommondation of our escalation engineers I need to inform you again that ISATAP is not recommedend to be used in Direct Access. Instead NAT64 or Native should be used. The article clearly states that ISATAP will automatically configure itself. But still if the router doesn’t work properly, it is not supported.”
    – “We have confirmed internally that public article will be changed/updated and this will take some time. The goal you are trying to achieve is not supported by Microsoft.”

    Friday, May 1, 2020 2:57 PM
  • I have a single DA Windows Server 2019 build 17763.1282 (with a one NIC) server deployed and I’m able to “manage out” from several other internal Windows 2019 servers but I have had to implement a couple of work arounds to make things consistently happy.

    First it appears that for some reason the DA server (Running Server 2019) forgets to “advertise”, and “forward” on the ISATAP interface after reboot.  So as a work around I created the following batch file that I run as a startup script in separate group policy (don't include it in the DirectAccess Server Settings GPO) on the DA server so each time it reboots it re-enables all of these settings on the ISATAP Interface:

    Example command (change the GUID in the command below to the ISATAP interface in your DA server):

    netsh int ipv6 SET int interface="isatap.{3B504BDA-6047-4ED0-941D-6D79C4A05B21}" advertise=enabled forwarding=enabled advertisedefaultroute=enabled

    The other issue I have seen is to make sure the IPv6 routing table is configured with the correct route on the ISATAP interface and that it is set as a “published" route.

    If the routing table entry is missing you will never get an IPv6 address on the ISATAP interface of the DA server.  So add in the route using the netsh command.  Make sure to reference the correct IPv6 subnet address for your ISATAP interface and correct GUID for the ISATAP interface on your DA server and then reboot the DA server.

    Example routing table command (change to your IPv6 ISATAP subnet and ISATAP GUID for the interface):

    netsh interface ipv6 add route fda7:d5d4:cc51:1::/64 “isatap.{3B504BDA-6047-4ED0-941D-6D79C4A05B21}” publish=yes store=persistent

    To determine what your IPv6 ISATAP subnet should be look at the current routing table entry for the "Ethernet" adapter in the DA server.  For example when I ran netsh interface ipv6 show route the Ethernet adapter was fda7:d5d4:cc51::/48 (this is typcailly the third from the top entry) so then in this case the ISATAP Interface should use fda7:d5d4:cc51:1::/64

    After a reboot of the DA server wait for the Remote Access management services to fully come online.  This can take a minute or two then re-run netsh interface ipv6 show route to make sure the routing table looks good and it kept the route added.  Then run ipconfig and make sure the ISATAP interface has the correct IPv6 address

    If the route didn’t “stick” you won’t get an IP address on the ISATAP interface so you could consider adding the netsh command that sets the route on the ISATAP interface into the second line of the startup script.

    Then finally on my “Manage Out” servers which are also running Server 2019 I’m pushing ISATAP router and state settings via group policy so I run a gpupdate, if they don’t pull an IPv6 address on their ISATAP interface right away sometimes it will require a reboot of those other servers.

    Its a little ugly but so far, these workarounds seem to be working well for me and fingers crossed no upcoming Windows Update Breaks something… 🤞

    Sunday, June 28, 2020 10:14 PM