Planning Redundancy for a DirectAccess Server

  • Article

Applies To: Windows 7, Windows Server 2008 R2

Important

This topic describes design considerations for DirectAccess in Windows Server 2008 R2. For the design considerations of DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see the Forefront UAG DirectAccess Design Guide (https://go.microsoft.com/fwlink/?LinkId=179988).

To provide service redundancy for DirectAccess, use Forefront UAG for scalability, high-availability, and enhanced management for a DirectAccess deployment. For more information, see UAG and DirectAccess (https://go.microsoft.com/fwlink/?LinkId=159955).

To provide hardware redundancy, DirectAccess can be configured inside a Hyper-V Failover cluster. The recommended configuration consists of two Hyper-V hosts with failover clustering supporting a single shared DirectAccess server in a virtual machine. The two Hyper-V hosts protect the system from a single node failure for the DirectAccess server.

In addition to the DirectAccess Setup Wizard, you need the following configuration:

  • The Hyper-V servers must be using identical server hardware.

    • Each Hyper-V server must have at least three physical network adapters to support Internet, intranet, and Failover Clustering connectivity. Network adapter teaming is not supported.

    • A fourth network adapter is a requirement if the Hyper-V clustering solution is using iSCSI interfaces.

    • The Hyper-V servers are joined to the domain and connected to the appropriate networks.

  • Ensure that the Hyper-V nodes are enabled to support Data Execution Prevention and Processor Virtualization.

Make the following Hyper-V configuration settings:

  • To improve overall performance, configure the following in the properties for the virtual machine in Failover Cluster Manager:

    • Do not set a preferred owner.

    • Set Failback to Prevent Failback. If Failback is enabled, unnecessary outages may occur when the DirectAccess VM resource is migrated or recovers from a node failure.

  • To speed up client reconnection in the event of a quick migration or node failure, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\ Oakley\NLBSFlags registry value to 1 on the DirectAccess virtual machine for faster idle timeout of IPsec security associations (SAs). With the NLBSFlags registry value set to 1, the total time it takes for IPsec to fail over is two minutes; one minute for the idle time to expire plus one minute for IKE to renegotiate SAs. The Hyper-V nodes do not need this configuration change.

With Hyper-V and Failover Clustering the primary failover mechanisms are the following:

  • Live migration

    There should be no discernable client connectivity outage when the clustered DA server is live migrated.

  • Quick migration

    With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a quick migration should be less than two minutes.

  • Resource move

    With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a manual resource move should be less than two minutes.

Hyper-V and Failover Clustering also support automatic recovery from a single node failure. When failover occurs a client should be reconnected within two minutes; there is no action needed from the user. If the NLBSFlags registry value is set to 1 and the host is back online in less than two minutes, the maximum client connectivity outage on a mode failure should be less than two minutes.