As organizations migrate on-premises server workloads to public cloud-hosted infrastructure, providing secure remote access to data and applications hosted there is an important consideration. If a traditional Active Directory domain infrastructure is implemented, leveraging DirectAccess in Windows Server 2016 and Windows 10 is an excellent choice as it provides seamless and transparent, always on, bidirectional network connectivity for managed Windows devices. DirectAccess can be deployed in Amazon Web Services (AWS) Elastic Compute Cloud (EC2) infrastructure, or any number of third-party cloud hosting providers. DirectAccess can be deployed in Microsoft Azure, but it is not a formally supported workload.
Load Balancing Limitations
Implementing DirectAccess in the cloud is fundamentally no different than it is on-premises, with one important limitation. When implementing DirectAccess in the cloud, load balancing using native Windows Network Load Balancing (NLB) or external load balancers (ELB) are not supported. This is due to limitations imposed by the underlying cloud infrastructure. Enabling load balancing for DirectAccess involves changing the IP address assigned to the VM, which is not supported in the cloud.
Eliminating Single Points of Failure
Without support for creating load-balanced clusters of DirectAccess servers in the cloud, the only option to eliminate the DirectAccess server as the single point of failure is to implement a multisite* configuration and place another DirectAccess server in a separate cloud region. If a DirectAccess server is offline for any reason, planned or unplanned, Windows 8.x/10 will automatically fail over to a DirectAccess server in another location.
*Note: Windows 7 clients do not fully support DirectAccess multisite. Windows 7 clients can be deployed in a multisite scenario, but they must be assigned to a specific entry point. They will not fail over to another location if their assigned entry point is unavailable.
While implementing DirectAccess multisite eliminates a crucial single point of failure in the DirectAccess architecture, it brings with it some unique challenges. The native site selection process is rudimentary, and often yields unexpected results. Commonly, DirectAccess clients will connect to entry points that are less than ideal. For example, a client may be in a region where an entry point is available, but instead it will establish a connection to an entry point in another region that is farther away.
Enhanced Multisite with GSLB
To deliver a better multisite experience and provide granular control of traffic distribution, a Global Server Load Balancer (GSLB) such as the KEMP LoadMaster GEO can be deployed. GEO can be implemented on premises or in Azure or AWS. GEO is configured to monitor the health and status of the DirectAccess servers and provides intelligent responses to DNS requests for clients establishing DirectAccess connections. In addition, GEO can be configured to use a geolocation IP address database to provide more accurate site selection for Windows 8.x/10 DirectAccess clients.
Configuring GEO for DirectAccess
Detailed guidance for configuring the LoadMaster GEO can be found in section 4 of the KEMP LoadMaster Windows Server 2012 R2 DirectAccess deployment guide.