DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Introduction

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic ManagerTo provide geographic redundancy, DirectAccess can be deployed in a multisite configuration. In this scenario, Windows 8.x and Windows 10 clients are aware of all entry points in the enterprise and will automatically select the nearest available entry point to connect to. The nearest entry point is defined as the one that responds the quickest. When a Windows 8.x or Windows 10 client attempts to establish DirectAccess connectivity, an HTTP GET is sent to all entry points and the client will select the one with the shortest Round Trip Time (RTT) for the request.

Note: Windows 7 clients can be provisioned when DirectAccess is configured for multisite access, but they must be assigned to an individual entry point.

Challenges

There are a number of challenges that come with the default multisite configuration. Choosing an entry point based solely on network latency is rather simplistic and can often produce unexpected results. It also lacks support for granular traffic distribution or active/passive configuration.

GSLB

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic ManagerFor the best experience, DirectAccess can be configured to use a Global Server Load Balancing (GSLB) solution to enhance transparent site selection and failover for Windows 8.x and Windows 10 clients. Commonly this is implemented using an on-premises appliance (Citrix NetScaler, F5 Global Traffic Manager, Kemp LoadMaster, A10 Thunder, etc.). These solutions offer exceptional control over DirectAccess traffic distribution, but they add expense and complexity.

Azure Traffic Manager

Azure Traffic Manager is a cloud-based GSLB solution that is a simple and cost-effective alternative to dedicated on-premises appliances. While it does not offer all of the features that GSLB appliances provide, it does provide better traffic distribution options than the default configuration. Importantly, it enables active/passive failover, which is a common requirement not supported natively with DirectAccess.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Traffic Manager Configuration

In the Azure portal (the new one, not the old one!) click New, Networking, and then Traffic Manager profile.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Provide a name and select a Routing method.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Routing method options are Performance, Weighted and Priority.

  • Performance. Select this option to enable clients to connect to the entry point with the lowest network latency.
  • Weighted. Select this option to enable clients to prefer some entry points more than others. Assign a weight value of 1 to 1000 for each entry point. Higher values have more preference. Values for entry points can be the same, if desired.
  • Priority. Select this option to enable clients to connect to a primary entry point, then fail over to a secondary or tertiary entry point in the event of an outage. Assign a priority value of 1 to 1000 for each entry point. Lower values take precedence. Each entry point must be assigned a unique priority value.

Click Create when finished. Next click Settings for the new traffic manager profile and click Configuration. Change Protocol to HTTPS, Port to 443, and Path to /IPHTTPS. Click Save when finished.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Next click Endpoints and click Add. Select External endpoint from the drop down list, provide a descriptive name, and then enter the Fully-Qualified Domain Name (FQDN) of the first DirectAccess entry point. When using the Performance routing method, choose a location that best represents the geography where the DirectAccess entry point is located. When using the Weighted or Priority routing methods, specify an appropriate value accordingly. Click Ok when finished. Repeat these steps for each entry point in the organization.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

DirectAccess Configuration

In the Remote Access Management console, highlight DirectAccess and VPN below Configuration in the navigation tree and then click Configure Multisite Settings below Multisite Deployment in the Tasks pane. Click Global Load Balancing and choose Yes, use global load balancing. Enter the FQDN of the Azure Traffic Manager profile and click Next, and then click Commit.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Note: An SSL certificate with a subject name matching that of the GSLB FQDN is not required.

In some cases, the management console may report that global load balancing addresses cannot be identified automatically for some or all entry points.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

If this occurs, it will be necessary to run the Set-DAEntryPoint PowerShell cmdlet to assign GLSB IP addresses to each entry point. The GSLB IP address is the public IPv4 address that the entry point public hostname resolves to.

Set-DAEntryPoint -Name [entrypoint_name] -GslbIP [external_ip_address]

For example:

Set-DAEntryPoint -Name "US West" -GslbIP 203.0.113.195
Set-DAEntryPoint -Name "US East" -GslbIP 198.51.100.21

Summary

DirectAccess includes native functionality to enable geographic load balancing for Windows 8.x and Windows 10 clients. The site selection process used by DirectAccess clients in this scenario is basic, and has the potential to yield unexpected results. Azure Traffic Manager is a simple, cost-effective alternative to dedicated on-premises GSLB appliances. It can be integrated with DirectAccess to address some of the shortcomings with the native entry point selection process.

Additional Resources

 

 

 

DirectAccess NLS Deployment Considerations for Large Enterprises

Introduction

For a DirectAccess deployment, the Network Location Server (NLS) is an infrastructure component that allows DirectAccess clients to determine if they are inside or outside of the corporate network. If the DirectAccess client can successfully connect to the NLS, it is on the internal network and DirectAccess is not used. If the NLS cannot be contacted, the client is outside of the network and will attempt to establish remote corporate network connectivity using DirectAccess.

High Availability

It is recommended that the NLS be made highly available by deploying at least two servers in a load balanced configuration to avoid potential service disruptions for DirectAccess clients inside the corporate network. While this approach is sufficient for networks that are contained in a single physical location, it does present some challenges for large organizations with internal networks that span multiple physical locations.

NLS Challenges

For DirectAccess, only a single NLS URL can be configured per DirectAccess deployment, as shown here.

DirectAccess NLS Deployment Considerations for Large Enterprises

If a WAN outage occurs on an internal network that spans multiple physical locations, internal DirectAccess clients in locations other than where the NLS resides will mistakenly believe they are outside of the corporate network. This can lead to degraded performance and potential loss of connectivity. NLS reliability can still be improved when the internal network spans multiple physical locations by deploying NLS at each physical location and configuring clients to use a local NLS. This will keep traffic off of the WAN and prevent service disruptions in the event of a WAN outage.

Redundant NLS

There are several strategies that can be used to configure internal DirectAccess clients to use a local NLS, including DNS round robin, a network load balancer, or Active Directory Group Policy. Using DNS or a load balancer requires only a single NLS URL. Using Active Directory Group Policy requires a unique NLS URL per physical location.

DNS

The simplest way to enable DirectAccess clients to use a local NLS is to use DNS round robin and take advantage of subnet prioritization. To do this, create an “A” resource record in DNS that resolves to the IPv4 address for each NLS. On the DNS server, open the DNS Manager, right-click the DNS server and choose Properties. Click the Advanced tab and select the options to Enable round robin and Enable netmask ordering.

DirectAccess NLS Deployment Considerations for Large Enterprises

This will ensure that name resolution requests for the NLS FQDN will be returned with the nearest NLS. More information about DNS netmask ordering can be found here.

Load Balancer

A Global Server Load Balancing (GSLB) solution can also be employed to route requests to a local NLS. Examples include F5 Global Traffic Manager (GTM) and Kemp Technologies LoadMaster GEO. Prescriptive guidance for configuring the Kemp LoadMaster for this scenario can be found here.

Group Policy

This method involves creating unique NLS URLs per site and overriding the default DirectAccess client configuration using Active Directory Group Policy. Separate Group Policy Objects (GPOs) are created and linked to Active Directory Sites to assign a local NLS to internal DirectAccess clients. To accomplish this, create a new GPO for each location where NLS will reside. Edit the GPO and navigate to Computer Configuration/Policies/Administrative Templates/Network/Network Connectivity Status Indicator. Double-click Specify domain location determination URL, choose Enabled, and then enter the URL that corresponds to the NLS for that location.

DirectAccess NLS Deployment Considerations for Large Enterprises

In the Remote Access Management Console, edit the Infrastructure Server Setup (Step 3) and add the FQDN for each NLS. Do not specify a DNS server. This effectively creates a Name Resolution Policy Table (NRPT) exemption so the NLS cannot be reached when the DirectAccess client is connected remotely.

DirectAccess NLS Deployment Considerations for Large Enterprises

In the Group Policy Management Console right-click on Sites and choose Show Sites.

DirectAccess NLS Deployment Considerations for Large Enterprises

Select each Active Directory site where NLS will reside.

DirectAccess NLS Deployment Considerations for Large Enterprises

Link the GPOs for each NLS to the corresponding site, then right-click the linked GPO and choose Enforced.

DirectAccess NLS Deployment Considerations for Large Enterprises

Note: Do not install the NLS on a domain controller! By design, the NLS is not reachable remotely by DirectAccess clients. This can lead to potential authentication issues and may prevent DirectAccess clients from connecting successfully.

Client Testing

To confirm that a client computer has been configured to use a local NLS, verify the currently associated Active Directory site by issuing the following command on the DirectAccess client computer:

nltest /dsgetsite

Next, confirm the setting of the NLS by issuing the following command:

Get-NCSIPolicyConfiguration

As a reference, here are examples from two DirectAccess clients in two different internal physical locations:

DirectAccess NLS Deployment Considerations for Large Enterprises

DirectAccess NLS Deployment Considerations for Large Enterprises

Summary

The limitation of a single Network Location Server (NLS) URL for a DirectAccess deployment presents some challenges for DirectAccess architects seeking to eliminate single points of failure in their design. Using the techniques described in this article, administrators can ensure that DirectAccess clients will always connect to a local NLS, eliminating potential failure points and improving the overall reliability of the solution.

Additional Resources

DirectAccess Network Location Server (NLS) Guidance

Configure KEMP LoadMaster Load Balancer for DirectAccess Network Location Server (NLS)

Configure Citrix NetScaler for DirectAccess Network Location Server (NLS)

Configure F5 BIG-IP for DirectAccess Network Location Server (NLS) 

Configure F5 BIG-IP for DirectAccess NLS

Recently I wrote about the Network Location Server (NLS) and its importance for DirectAccess deployments. As I described previously, the NLS is nothing more than a web server with an SSL certificate installed. It should also be made highly available to prevent potential service disruption caused by planned or unplanned NLS server downtime. Any web server can serve as the NLS. In addition, if you have the F5 BIG-IP Local Traffic Manager (LTM) in your environment, you can easily configure the LTM to serve as the NLS.

To accomplish this, import the SSL certificate for the NLS and create an SSL client profile using its certificate and private key. Next, create a new iRule that contains the following code.

when HTTP_REQUEST {
HTTP::respond 200 
}

Configure F5 BGIP for DirectAccess NLS

Finally, create a new virtual server listening on TCP port 443 and assign this iRule as a resource for the virtual server. Once NLS reachability has been verified, update the DirectAccess configuration using the Remote Access Management console or the Set-DANetworkLocationServer PowerShell cmdlet.