DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

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.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

In addition, a route to the DirectAccess client’s IPv6 prefix is also present in the routing table.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

Nevertheless, attempts to connect to the remote DirectAccess client by name fail.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

The DirectAccess client is reachable by its IPv6 address, however.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

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

Implementing DirectAccess with Windows Server 2012 R2 Book

DirectAccess Consulting Services

Deploying DirectAccess in Microsoft Azure

Introduction

DirectAccess Now a Supported Workload in Microsoft AzureMany organizations are preparing to implement DirectAccess on Microsoft’s public cloud infrastructure. Deploying DirectAccess in Azure is fundamentally no different than implementing it on premises, with a few important exceptions (see below). This article provides essential guidance for administrators to configure this unique workload in Azure.

Important Note: There has been much confusion regarding the supportability of DirectAccess in Azure. Historically it has not been supported. Recently, it appeared briefly that Microsoft reversed their earlier decision and was in fact going to support it. However, the Microsoft Server Software Suport for Microsoft Azure Virtual Machines document has once again been revised to indicate that DirectAccess is indeed no longer formally supported on Azure. More details can be found here.

Azure Configuration

The following is guidance for configuring network interfaces, IP address assignments, public DNS, and network security groups for deploying DirectAccess in Azure.

Virtual Machine

Deploy a virtual machine in Azure with sufficient resources to meet expected demand. A minimum of two CPU cores should be provisioned. A VM with 4 cores is recommended. Premium storage on SSD is optional, as DirectAccess is not a disk intensive workload.

Network Interfaces

It is recommended that an Azure VM with a single network interface be provisioned for the DirectAccess role. This differs from on-premises deployments where two network interfaces are preferred because deploying VMs in Azure with two NICs is prohibitively difficult. At the time of this writing, Azure VMs with multiple network interfaces can only be provisioned using PowerShell, Azure CLI, or resource manager templates. In addition, Azure VMs with multiple NICs cannot belong to the same resource group as other VMs. Finally, and perhaps most importantly, not all Azure VMs support multiple NICs.

Internal IP Address

Static IP address assignment is recommended for the DirectAccess VM in Azure. By default, Azure VMs are initially provisioned using dynamic IP addresses, so this change must be made after the VM has been provisioned. To assign a static internal IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Private IP address settings section choose Static for the assignment method.
  8. Enter an IP address for the VM.
  9. Click Save.

Deploying DirectAccess in Microsoft Azure

Public IP Address

The DirectAccess VM in Azure must have a public IP address assigned to it to allow remote client connectivity. To assign a public IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Public IP address settings section click Enabled.
  8. Click Configure required settings.
  9. Click Create New and provide a descriptive name for the public IP address.
  10. Choose an address assignment method.
  11. Click Ok and Save.

Deploying DirectAccess in Microsoft Azure

Deploying DirectAccess in Microsoft Azure

Public DNS

If the static IP address assignment method was chosen for the public IP address, create an A resource record in public DNS that resolves to this address. If the dynamic IP address assignment method was chosen, create a CNAME record in public DNS that maps to the public hostname for the DirectAccess server. To assign a public hostname to the VM in Azure, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Overview.
  4. Click Public IP address/DNS name label.Deploying DirectAccess in Microsoft Azure
  5. Under Settings click Configuration.
  6. Choose an assignment method (static or dynamic).
  7. Enter a DNS name label.
  8. Click Save.

Deploying DirectAccess in Microsoft Azure

Note: The subject of the SSL certificate used for the DirectAccess IP-HTTPS listener must match the name of the public DNS record (A or CNAME) entered previously. The SSL certificate does not need to match the Azure DNS name label entered here.

Network Security Group

A network security group must be configured to allow IP-HTTPS traffic inbound to the DirectAccess server on the public IP address. To make the required changes to the network security group, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click Network security group.
  6. Click the network security group assigned to the network interface.
  7. Click Inbound security rules.
  8. Click Add and provide a descriptive name for the new rule.
  9. Click Any for Source.
  10. From the Service drop-down list choose HTTPS.
  11. Click Allow for Action.
  12. Click Ok.

Deploying DirectAccess in Microsoft Azure

Note: It is recommended that the default-allow-rdp rule be removed if it is not needed. At a minimum, scope the rule to allow RDP only from trusted hosts and/or networks.

DirectAccess Configuration

When performing the initial configuration of DirectAccess using the Remote Access Management console, the administrator will encounter the following warning message.

“One or more network adapters should be configured with a static IP address. Obtain a static address and assign it to the adapter.”

Deploying DirectAccess in Microsoft Azure

This message can safely be ignored because Azure infrastructure handles all IP address assignment for hosted VMs.

The public name of the DirectAccess server entered in the Remote Access Management console must resolve to the public IP address assigned to the Azure VM, as described previously.

Deploying DirectAccess in Microsoft Azure

Additional Considerations

When deploying DirectAccess in Azure, the following limitations should be considered.

Load Balancing

It is not possible to enable load balancing using Windows Network Load Balancing (NLB) or an external load balancer. Enabling load balancing for DirectAccess requires changing static IP address assignments in the Windows operating system directly, which is not supported in Azure. This is because IP addresses are assigned dynamically in Azure, even when the option to use static IP address assignment is chosen in the Azure management portal. Static IP address assignment for Azure virtual machines are functionally similar to using DHCP reservations on premises.

Deploying DirectAccess in Microsoft Azure

Note: Technically speaking, the DirectAccess server in Azure could be placed behind a third-party external load balancer for the purposes of performing SSL offload or IP-HTTPS preauthentication, as outlined here and here. However, load balancing cannot be enabled in the Remote Access Management console and only a single DirectAccess server per entry point can be deployed.

Manage Out

DirectAccess manage out using native IPv6 or ISATAP is not supported in Azure. At the time of this writing, Azure does not support IPv6 addressing for Azure VMs. In addition, ISATAP does not work due to limitations imposed by the underlying Azure network infrastructure.

Summary

For organizations moving infrastructure to Microsoft’s public cloud, formal support for the DirectAccess workload in Azure is welcome news. Implementing DirectAccess in Azure is similar to on-premises with a few crucial limitations. By following the guidelines outlined in this article, administrators can configure DirectAccess in Azure to meet their secure remote access needs with a minimum of trouble.

Additional Resources

Implementing DirectAccess in Windows Server 2016
Fundamentals of Microsoft Azure 2nd Edition
Microsoft Azure Security Infrastructure
DirectAccess Multisite with Azure Traffic Manager
DirectAccess Consulting Services

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 Consulting Services Now Available

Microsoft Certified Solutions Associate (MCSA)For the last five years I’ve been helping organizations large and small deploy DirectAccess. During that time I have amassed a wealth of knowledge and experience with this unique technology. DirectAccess is not trivial to install, configure, or troubleshoot. Also, it’s easy to make mistakes in the planning and design phase that can turn in to serious issues later in the deployment. To make matters worse, many organizations are deploying DirectAccess for the first time, and without essential guidance they are prone to making common mistakes or choosing configuration options that are less than optimal both in terms of supportability and performance.

Having deployed DirectAccess for some of the largest companies in the world, there isn’t much I haven’t already encountered. If you are looking for the best chance of success for your DirectAccess deployment, consider a consulting engagement with me. I can provide assistance with all facets of DirectAccess implementation including planning and design, installation, configuration, and troubleshooting. Consulting services at reasonable rates are available for all types of DirectAccess work including:

  • New DirectAccess installations
  • Migration from previous versions of DirectAccess
  • Upgrade or expansion of existing DirectAccess deployment
  • Enterprise planning and design for large-scale, multisite DirectAccess deployments
  • DirectAccess high availability (local and geographic)
  • Manage-out for DirectAccess with external hardware load balancers and/or multisite configuration
  • Multisite DirectAccess with geographic redundancy for Windows 7 clients
  • Existing DirectAccess design review and security assessment
  • Windows Server 2012 R2 client-based VPN configuration
  • DirectAccess client connectivity troubleshooting
  • DirectAccess training

Additionally, consulting services are available for a variety of security solutions as well as on-premises and cloud networking technologies such as:

  • Azure networking and infrastructure
  • Cross-premises connectivity to Azure
  • Certificate services (PKI)
  • IP address management
  • ISA Server and Forefront Threat Management Gateway (TMG) migration

All services can be performed on-site or remotely. If you are interested in obtaining my services, fill out the form below and I’ll contact you.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

For DirectAccess manage out scenarios, it is necessary to configure the Windows firewall on the DirectAccess client to allow any required inbound communication from the corporate network. For example, if management hosts on the internal network need to initiate Remote Desktop sessions with remote connected DirectAccess clients, the Remote Desktop – User Mode (TCP-In) Windows firewall rule will need to be enabled for the Public and Private profiles.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

While enabling this rule will allow remote desktop connections to be made from the corporate network, its default configuration will also accept remote desktop connections from any network. From a security perspective this is not desirable.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

A better solution is to restrict access to connections originating only from the corporate network. To do this it will be necessary to identify the ISATAP prefix used internally. To determine the corporate ISATAP prefix, run the ipconfig command on a management workstation that is configured for ISATAP. The ISATAP prefix will be the first 96 bits of the IPv6 address assigned to the ISATAP tunnel adapter (essentially everything with the exception of the embedded IPv4 address).

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

On the DirectAccess client, right-click the firewall rule and choose Properties. Choose the Scope tab and then select These IP addresses . Click Add and then enter the ISATAP prefix as shown here.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

Once the firewall rule is configured to restrict access to the ISATAP prefix, only corporate management workstations on the internal network will have access to remote DirectAccess clients.

Active Directory IP Subnets for DirectAccess Clients

Introduction

When deploying Windows Server 2012 R2 DirectAccess I’m often asked which Active Directory (AD) site a client is associated with when it establishes DirectAccess connectivity. The answer depends on the client’s operating system. Windows 8.x and later clients automatically associate themselves with the site to which the DirectAccess server they are connected to belongs. Windows 7 clients lack this capability, and depending on current AD configuration, Windows 7 clients may associate with an incorrect site. This can lead to potential problems such as slow logon times and mapped drive failures. To address this issue it is important to configure IP subnets in AD for DirectAccess clients to eliminate any potential problems. In this article I’ll demonstrate how to create IP subnets in AD and how to identify IPv6 subnets used by DirectAccess clients.

Active Directory IP Subnets

Configuring IP subnets in AD is relatively straightforward. In the Active Directory Sites and Services management console, right-click Subnets and choose New Subnet. Enter the IP subnet prefix and select the AD site where the DirectAccess server for this subnet resides.

Active Directory IP Subnets for DirectAccess Clients

IPv6 Subnets for DirectAccess Clients

To configure AD IP subnets for DirectAccess clients, it will be necessary to identify all potential IP subnets that may be in use. IP subnets used by DirectAccess clients depend on the IPv6 transition protocols supported by the DirectAccess configuration. DirectAccess supports 6to4, Teredo, and IP-HTTPS for client to server communication, and the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) for manage-out connectivity. Any or all of these protocols may be used for a particular DirectAccess configuration.

  • 6to4 – Supported if the DirectAccess server is edge-facing with a public IPv4 address assigned to its external network interface.
  • Teredo – Supported if the DirectAccess server is edge-facing with two consecutive public IPv4 addresses assigned to its external network interface.
  • IP-HTTPS – Supported in all deployment scenarios, and is used exclusively if the DirectAccess server is located behind a NAT device in a perimeter or DMZ network.
  • ISATAP – Optionally used when manage out is enabled and configured.

IP subnets should be configured in AD for all IPv6 transition protocols supported for the DirectAccess deployment.

Identify the 6to4 IPv6 Subnet

Note: Information for the 6to4 protocol is provided here for completeness. However, it is generally recommended that 6to4 be disabled for DirectAccess deployments, making this configuration unnecessary. More information about disabling 6to4 can be found here.

The 6to4 IPv6 transition protocol is only supported when the DirectAccess server is edge-facing with a public IPv4 address assigned to its external network interface. 6to4 IPv6 addresses are assigned using the 2002::/16 prefix. For single site DirectAccess deployments, an administrator should create an IP subnet in AD using this prefix and assign it to the AD site where the DirectAccess server resides. If public IPv4 addressing is used internally and the 6to4 transition protocol has not been disabled, it is essential that more specific IP subnets for internal 6to4 clients also be configured.

6to4 and DirectAccess Multisite Challenges

The 6to4 IPv6 transition protocol presents a challenge for multisite DirectAccess deployments. When a client creates a 6to4 IPv6 address, it appends the 2002::/16 prefix with its public IPv4 address represented in hexadecimal using the form WWXX:YYZZ::WWXX:YYZZ. For example, if the DirectAccess client’s public IPv4 address is 198.51.100.83, its 6to4 address would be 2002:c633:6453::c633:6453. Since this IPv6 address is created using only the client’s IPv4 address, there is no way to associate the client to a specific entry point. This is one of the reasons why 6to4 is not recommended for use in DirectAccess deployments. If you must support the 6to4 IPv6 transition protocol in a multisite configuration, assign the 2002::/16 IP subnet to the most centrally located AD site.

Identify the Teredo IPv6 Subnet

The Teredo IPv6 transition protocol is only supported when the DirectAccess server is edge facing with two consecutive public IPv4 addresses assigned to its external network interface. Teredo IPv6 addresses begin with 2001: followed by the primary public IPv4 address (represented in hexadecimal) of the DirectAccess server. For example, if the DirectAccess server’s primary public IPv4 address is 203.0.113.240, the DirectAccess client will be assigned a Teredo IPv6 address using the 2001:cb00:71f0::/48 prefix. An administrator should create an IP subnet in AD using this prefix and assign it to the AD site where the DirectAccess server resides. For multisite deployments, repeat these steps for each DirectAccess entry point.

Identify the IP-HTTPS IPv6 Subnet

The IP-HTTPS IPv6 transition protocol is supported in all DirectAccess configurations and its IPv6 subnet should always be assigned to an AD site. The IP-HTTPS IPv6 prefix assignment differs between single site and multisite deployments.

Single Site Deployment

For single site deployments, a /64 IPv6 prefix is assigned for DirectAccess clients. To identify this subnet, run the Get-RemoteAccess PowerShell command on the DirectAccess server and locate the value of ClientIPv6Prefix

Active Directory IP Subnets for DirectAccess Clients

Multisite Deployment

For multisite deployments, a unique /64  IPv6 subnet is assigned to single node entry points. If load balancing is enabled, a /59 IPv6 subnet is assigned to the entry point, and each server within the entry point is assigned a /64 prefix for DirectAccess clients. To identify the IPv6 prefixes for each entry point, highlight DirectAccess and VPN below the Configuration node in the Remote Access Management console, and then select the DirectAccess entry point.

Active Directory IP Subnets for DirectAccess Clients

For edge facing deployments with a public IPv4 address assigned to the external network interface, the IPv6 prefix assigned to DirectAccess clients is from the 2002::/16 globally unique address (GUA) range. If the DirectAccess server is configured using a private IPv4 address with a single network interface or with two network interfaces behind a NAT, the IPv6 prefix assigned to DirectAccess clients will be from the fd00::/8 unique local address (ULA) range. An administrator should create an IP subnet in AD using this prefix and assign it to the AD site where the DirectAccess server resides.

Note: Uninstalling and reinstalling DirectAccess will result in a new IP-HTTPS network ID being created. If these changes are made, be sure to update AD IP subnets accordingly.

Identify the ISATAP IPv6 Subnet

Although this article focuses primarily on the IPv6 subnets used by remote DirectAccess clients, it is also important not to overlook AD IP subnet configuration for internal clients if ISATAP is configured for manage out. IP subnets used by ISATAP clients vary depending on the network configuration of the DirectAccess server.

Edge Deployment

For edge deployments, ISATAP addresses are assigned from the 2002::/16 GUA range. This is appended with the public IPv4 address of the DirectAccess server in hexadecimal using the form WWXX:YYZZ:1:0:5efe and the IPv4 address of the ISTAP client in familiar dotted-decimal notation. For example, if the DirectAccess server’s primary public IPv4 address is 203.0.113.240 and the client’s IP address is 172.16.1.77, the DirectAccess client will be assigned the ISATAP address 2002:cb00:71f0:1:0:5efe:172.16.1.77. The subnet to be created by the administrator in AD will then be 2002:cb00:71f0:1:0:5efe::/96 plus the IPv4 network prefix. For example, if the client’s IP address uses a /24 prefix, the AD IP subnet would be configured using 2002:cb00:71f0:1:0:5efe:172.16.1.0/120. This IP subnet should be assigned to the same site where the corresponding IPv4 subnet is assigned.

Perimeter/DMZ Deployment

For perimeter/DMZ deployments, ISATAP addresses are assigned randomly from the fd00::/8 ULA range and begin with fdXX:XXXX:XXXX:1:0:5efe followed by the IPv4 address of the ISTAP client in dotted-decimal notation. For example, if the DirectAccess client’s IP address is 172.16.1.77, its ISATAP address might look like fdca:3ce5:b0a:1:0:5efe:172.16.1.77. The subnet to be created by the administrator in AD will then be fdca:3ce5:b0a:1:0:5efe::/96 plus the IPv4 network prefix. If the clients’ IP address uses a /24 prefix, the AD IP subnet would be configured using fdca:3ce5:b0a:1:0:5efe:172.16.1.0/120. This IP subnet should be assigned to the same site where the corresponding IPv4 subnet is assigned.

Summary

The configuration of Active Directory IP subnets for DirectAccess clients is an often overlooked aspect of DirectAccess deployments. Proper IP subnet mapping to AD sites is critical, especially for large enterprise deployments with complex networks spanning multiple physical locations. It ensures that Windows 7 DirectAccess clients communicate with the closest AD domain controller when they establish a DirectAccess connection, which can eliminate potential issues. In addition, it is recommended to disable 6to4 for DirectAccess clients to avoid the pitfalls that come with the use of this IPv6 transition protocol. Also, don’t forget to configure IP subnets for any internal clients that use ISATAP for manage out.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Update: Microsoft is no longer supporting DirectAccess in Azure. More details here.

Recently I wrote an article for CloudComputingAdmin.com about how to configure a basic test lab in Microsoft Azure using Windows Server 2012 R2. After I completed the article, I decided to investigate whether DirectAccess could be configured successfully in Azure. To begin, I looked through the list of unsupported roles and, unfortunately, DirectAccess is on the list. However, just because it isn’t supported doesn’t mean it won’t work, so I proceeded to set up a Windows Server 2012 R2 DirectAccess server to see what would happen. Based on my experience, I can tell you that it does indeed work. However, I quickly learned why it is not supported. There are a number of things unique to the Azure hosting environment that prevent DirectAccess from working without interruption. Although these challenges might prevent you from using DirectAccess in a production environment in Azure, it is certainly viable for short-term testing and evaluation of DirectAccess in Windows Server 2012 R2. Be advised that not all DirectAccess deployment scenarios can be configured in Azure. For example, it is not possible to configure DirectAccess in a public-facing edge configuration. In fact, Azure virtual machines can have only a single NIC, which limits the deployment model to NAT/DMZ configuration. In addition, broadcast and multicast traffic are not supported in a conventional way in Azure, preventing load-balanced clusters and manage out functionality using ISATAP from working correctly.

Configuring the DirectAccess Server in Azure

Note: The DirectAccess server must be joined to a domain, so the assumption is that you’ve configured at least one domain controller somewhere. It can be located in Azure itself, or on-premises with site-to-site VPN established between the on-premises network and the Azure virtual network. Guidance for deploying a Windows Server 2012 R2 domain controller in Azure can be found here. Guidance for configuring site-to-site VPN to Azure using Windows Server 2012 R2 can be found here.

To begin, provision a Windows Server 2012 R2 virtual machine in Microsoft Azure, and be sure to assign a static IP address to the VM using PowerShell as described here. Once the VM is provisioned and available, join it to your domain, install your certificates, and then install the DirectAccess-VPN role. When you first open the Remote Access management console you’ll receive the following errors:

The server does not comply with some DirectAccess prerequisites.
Resolve all issues before proceeding with DirectAccess deployment.

Warning : One or more network adapters should be configured with a static
IP address. Obtain a static address and assign it to the adapter.

Error: The client cannot connect to the destination specified in the
request. Verify that the service on the destination is running and is
accepting requests. Consult the logs and documentation for the
WS-Management service running on the destination, most commonly IIS or
WinRM. If the destination is the WinRM service, run the following
command on the destination to analyze and configure the WinRM service:
"winrm quickconfig".

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

As long as you’ve configured the VM with a static IP address in Azure you can disregard the warning about static IP address assignment. Static IP address assignment in Azure works effectively like a dynamic IP address reservation which will not change, and is sufficient for our purposes here. To resolve the second error, open an elevated command prompt and enter the following command:

winrm quickconfig

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Click on Check prerequisites again and you’ll find that the warning about static IP address assignment still persists, but you can now click Next to proceed with configuring DirectAccess.

http://azure.microsoft.com/blog/2014/05/14/reserved-ip-addresses/

In the Azure management portal, note the Public Virtual IP (VIP) address assigned to the VM. Configure public DNS with the hostname you entered when configuring DirectAccess (which is used by clients to connect to the DirectAccess server) to resolve to this IP address.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

To configure external access to the VM for DirectAccess clients click Endpoints and click Add. Select the option to Add a standalone endpoint and then select HTTPS and TCP. Accept the defaults of 443 for both the public and private ports.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Provisioning DirectAccess Clients

At this point you should now be able to provision DirectAccess clients. If you’ve configured your DirectAccess lab entirely in Azure, you’ll need to use the offline domain join tool to provision clients. Once you’ve successfully provisioned DirectAccess clients, they should be able to establish connectivity through the DirectAccess server.

Azure DirectAccess Issues

Turning off the DirectAccess virtual machine is when the problems begin. Specifically, stopping the virtual machine and deallocating it, which happens when you choose to shut down the VM via the Azure management portal, tends to break things. However, stopping the DirectAccess server from within the virtual machine itself (using Stop-Computer, shutdown.exe, or the GUI) does not cause any problems, and the DirectAccess server can remain shut down (but not deallocated) for an extended period of time without issue.

When you restart a VM that was previously stopped and deallocated, you may find that the Remote Access management console fails to connect, returning the following error message:

Configuration Load Error

A connection cannot be established to server . Check that the server
is available, the Remote Access role is installed, and that you have
permissions to access the server.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Running winrm quickconfig again restores access to the management console. You’ll notice, however, that DirectAccess is not functioning in spite of the fact that the management console states it is. You’ll also find that there are a number of services in an unknown state.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

This happens because the after the VM is restarted after being deallocated, it receives a new virtual NIC. When the system starts, the DirectAccess configuration is not bound to this network interface. To resolve this issue, go to the DirectAccess and VPN Configuration in the management console and click Edit in the Remote Access Server configuration and choose Network Adapters. You’ll see that the adapter connected to the internal or perimeter network is blank. From the drop-down menu, select the network interface and choose Next,Finish, and then apply the configuration once again.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Changes to Public DNS

When the DirectAccess server is deallocated, the public IPv4 address assigned to it is released. If the VM is deallocated for an extended period of time, you will not get your originally assigned public IP address again and a new one is assigned upon restart. You’ll need to update your public DNS record to reflect this change of IP address. It is possible to reserve a public IP address using PowerShell. However, it does require that you reserve the public IP address prior to creating the virtual machine. In addition, you’ll need to create the virtual machine using PowerShell to leverage the reserved public address. As of this writing, reserving public IP addresses is not available through the Azure portal GUI. For more information about reserving public IP addresses in Azure, click here.

Summary

Although it is technically possible to configure DirectAccess on Windows Server 2012 R2 hosted in the Microsoft Azure public cloud, it is formally unsupported and there are a number of factors that make its use potentially problematic. It might be possible that future changes could make this better, but for now it does work in some scenarios if you accept the workarounds. Proceed at your own risk!

Remote Assistance to Windows 7 SP1 DirectAccess Client Fails

Microsoft recently made available a hotfix to address an issue where Remote Assistance connections to remote DirectAccess clients fails. The issue occurs specifically when Windows 7 clients connect to a Windows Server 2012 DirectAccess server using the IP-HTTPS IPv6 transition protocol. In this scenario, DirectAccess clients are assigned a Unique Local IPv6 Address (ULA) using the prefix FD00::/8 for which Remote Assistance service would not listen on. If you are planning to support Windows 7 clients on your Windows Server 2012/R2 DirectAccess server and you need Remote Assistance functionality, you’ll definitely want to ensure that this hotfix is applied to all of your Windows 7 DirectAccess clients.

For more information and to download the hotfix, please refer to Microsoft Knowledge Base article KB2912883.

Disabling Unused IPv6 Transition Technologies for DirectAccess Clients

From a client perspective, DirectAccess is an IPv6-only solution and requires IPv6 connectivity end to end. To enable the solution to work on IPv4-only networks, DirectAccess makes use of one of several IPv6 transition technologies – 6to4, Teredo, or IP-HTTPS. By leveraging these IPv6 transition technologies, a DirectAccess client can communicate with the DirectAccess server when they are both connected to the public IPv4 Internet, which is the most common deployment scenario today.

The first two IPv6 transition technologies, 6to4 and Teredo, both require that the DirectAccess server be directly connected to the public Internet. Beginning with Windows Server 2012, placing the DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is now supported. However, in this deployment model only the IP-HTTPS IPv6 transition protocol can be utilized. In this scenario, it is recommended to disable the unused IPv6 transition protocols to prevent potential connectivity issues. You can disable them on a per-host basis using PowerShell, which is fine for individual client testing purposes, or globally using Active Directory Group Policy Objects (GPOs), which is recommend for enterprise-wide production deployment.

To disable unused IPv6 transition protocols on a per-host basis on Windows 8 clients using PowerShell, open an elevated PowerShell prompt and execute the following commands:

Set-Net6to4Configuration –State disabled
Set-NetTeredoConfiguration –Type disabled
Set-NetIsatapConfiguration –State disabled

To disable unused IPv6 transition protocols on a per-host basis on Windows 7 client using netsh, open an elevated command prompt and execute the following commands:

netsh interface 6to4 set state disabled
netsh interface teredo set state disabled
netsh interface isatap set state disabled

To disable unused IPv6 transition protocols using Active Directory GPO, open the Group Policy Management Console (GPMC) and create a new GPO. Edit the GPO by navigating to Computer Configuration / Policies / Administrative Templates / Network / TCP/IP Settings / IPv6 Transition. Double-click Set 6to4 State and enable the policy, then select Disabled State from the list of states. Repeat these steps for Teredo and ISATAP.

Disable DirectAccess IPv6 Transition Protocol using GPO

Change the security filtering for the GPO and specify the security group for your DirectAccess clients. Once complete, link the new GPO to the domain.

Disable DirectAccess IPv6 Transition Protocol using GPO

As a reminder, the steps above are for disabling unused IPv6 transition protocols in a deployment scenario where the DirectAccess server is running Windows Server 2012/R2 and is deployed behind a NAT device. If your DirectAccess server is connected directly to the public Internet, disabling these IPv6 transition protocols is not required.

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!

%d bloggers like this: