DirectAccess Manage Out from Windows 10 Does Not Work

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.

For DirectAccess manage out deployments using ISATAP, you may encounter a scenario in which you are unable to initiate outbound connections to connected DirectAccess clients from a Windows 10 computer. Outbound connections using ISATAP from Windows 7, Windows 8, Windows Server 2008/R2, or Windows Server 2012/R2 systems work without issue.

DirectAccess Manage Out from Windows 10 Does Not Work

As it turns out, there is a bug in the Windows 10 DNS client code that prevents manage out using ISATAP from a Windows 10 client from working correctly. Thanks to the diligent effort of DirectAccess administrators Mike Piron and Jason Kuhns, a workaround has been identified. To deploy the workaround, it will be necessary to implement registry changes to alter the default behavior of the DNS resolver in Windows 10. You can implement these changes on a Windows 10 DirectAccess manage out machine by using the following PowerShell commands:

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 1 -Force

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 1 –Force

Once these registry changes have been made, you should now be able to use ISATAP for DirectAccess manage out connections from a Windows 10 machine.

DirectAccess Client and Server Settings GPOs Deleted

Microsoft Windows Server Active DirectoryFor DirectAccess deployments where domain controllers are running Windows Server 2003 or Windows Server 2003 R2 using the File Replication Service (FRS) for replication, DirectAccess client and server settings Group Policy Objects (GPOs) may be deleted. If these GPOs are deleted, DirectAccess connectivity will be disrupted. If the GPOs cannot be recovered via backup, it will be necessary to rebuild the entire DirectAccess deployment from scratch.

Microsoft recently updated their DirectAccess Unsupported Configurations documentation to reflect new guidance for DirectAccess deployments where the FRS is used for the distribution of Active Directory GPOs. DirectAccess is no longer supported in environments where FRS is used for SYSVOL replication.

What this means is that if you plan to deploy DirectAccess, domain controllers must be running Windows Server 2008 or later, and Distributed File System Replication (DFS-R) must be used for replication.

More details can be found here.

DirectAccess DNS Records Explained

After installing and configuring DirectAccess with Windows Server 2012 R2, several new host records appear automatically in the internal DNS (assuming dynamic DNS is supported, of course). One of them is directaccess-corpConnectivityHost and the other is directaccess-WebProbeHost. These DirectAccess DNS entries are used by Windows 8 and later clients for connectivity checks at various stages of DirectAccess connection establishment.

DirectAccess DNS Records Explained

Figure 1 – DirectAccess DNS records for IPv4-only network.

DirectAccess DNS Records Explained

Figure 2 – DirectAccess DNS records for dual-stack IPv4/IPv6 network.

Here is a detailed description for each of these DirectAccess DNS entries.

directaccess-corpConnectivityHost – This DNS host record includes both A and AAAA records when deployed on IPv4-only networks. Its A host record resolves to 127.0.0.1, which is the IPv4 loopback address. Its AAAA host record resolves to an IPv6 address that is a combination of the DirectAccess NAT64 IPv6 prefix and 7F00:1 (the hexadecimal equivalent of 127.0.0.1). When DirectAccess is configured on a network with native IPv6, the directaccess-corpConnectivityHost DNS record will only include a single AAAA record resolving to ::1.

This host record is used by the DirectAccess client to determine if name resolution for the corporate namespace is working after the IPv6 transition tunnel (6to4, Teredo, or IP-HTTPS) has been established. It does this by attempting to resolve the hostname directaccess-corpConnectivityHost.<corp_fqdn> (e.g. directaccess-corpConnectivityHost.corp.example.net) to an IPv6 address that it expects (the organization’s NAT64 prefix + 7F00:1 or ::1). If it does not resolve, or resolves to a different address, the client will assume that the transition tunnel was not established successfully and, if possible, fall back to another IPv6 transition protocol and repeat the process until it is successful.

Note: The DirectAccess client does not attempt to connect to the IP address resolved by directaccess-corpConnectivityHost. It simply compares the IP address returned by the query to the expected address (NAT64 prefix + 7F00:1 or ::1).

directaccess-WebProbeHost – This DNS host record includes only A records and resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. If load balancing is enabled, this host record will resolve to the virtual IP address (VIP) of the array. For multisite deployments there will be directaccess-WebProbeHost A host records for each entry point in the organization.

This host record is used by the DirectAccess client to verify end-to-end corporate network connectivity over the DirectAccess connection. The client will attempt to connect to the directaccess-WebProbeHost URL using HTTP. If successful, the DirectAccess connectivity status indicator will show Connected.

If any of these DirectAccess DNS records are missing or incorrect, a number of issues may arise. If the directaccess-corpConnectivityHost host record is missing or incorrect, DirectAccess IPv6 transition tunnel establishment may fail. If the directaccess-WebProbeHost record is missing or incorrect, the DirectAccess connectivity status indicator will perpetually show Connecting. This commonly occurs when an external load balancer is used and a virtual server isn’t created for the web probe host port (TCP 80). In addition, these DirectAccess DNS entries are not static and may be deleted if DNS scavenging of stale resource records is enabled on the DNS server.