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

 

 

 

Leave a comment

29 Comments

  1. Craig

     /  April 4, 2016

    Great article, we are in Azure so this might work for us. Going by this article it will only work for IPHTTPS?

    Reply
  2. Hallo Mr. Richard, I would like to ask, how to install direct access in full server core? , could you give me some reference about it, thank you very much

    Reply
  3. Simon

     /  April 27, 2016

    Hmm, If I change my deployment to a Global Load Balancing deployment from a regular multi-site deployment will the configuration of each of DirectAccess entry point be modified to only accept connections via the GSLB?

    My question is with regards to the fact that I have a live deployment and if I make the change, I want my clients that are currently working remotely to still be able to connect directly to the gateways until they pick up the new Group Policy.

    If not, then it looks like I will be starting a fresh parallel deployment.

    Reply
    • No, not at all. This change only instructs the clients to resolve the GSLB to an IP address, for which the clinet then maps to an entry point. No changes are made to the DirectAccess server configuration. It is completely non-disruptive.

      Reply
  4. Great article. My team has stood up a comprehensive global multisite topology based on your write up. We’ve signed up for a trial of traffic manager and have added our external end points. Unfortunately we are unable to get our endpoint a to come online consistency. They consistently sit in a degraded state flipping online on occasion. All endpoint are new 2012r2 builds fully patched. We are natting through 443 through a Cisco ASA. One of our nodes is directly connected to our public segment with no firewall in front of it on a gigabit internet path. We have been struggling to troubleshoot why we are not signaling a 200 ok to traffic manager. We’ve been unable to find good troubleshooting tools whether in traffic manager or on the server itself. Any guidance on how to get traffic manager to get our endpoints to register online? We are servicing DA connections perfectly fine from this topology. People love it. All services are green across all 5 endpoints.

    Reply
    • John

       /  April 12, 2017

      Were you able to determine why your endpoint wouldn’t come online. Were running into a similar issue. One endpoint is online and the other is degraded.

      Reply
    • Roman

       /  April 12, 2017

      Hi gavenk,

      Have you been able to resolve this issue with ATM?
      I’ve got exactly the same problem and I ran out of ideas how to fix it…

      Richard,

      Have you any ideas on this?

      Reply
    • Ed

       /  June 7, 2017

      We’re having the exact same issue, just wondering if anyone solved this?

      Reply
    • VinoG

       /  August 8, 2017

      We are also running into same issue now. Any one found solution for this issue?

      Reply
  5. Hi Richard, Great article just interested under what circumstances would you need to use this? The HTTP get seems to work well for us granted we’re quite small with only 2 locations in one country but even in a larger org when would the lowest RTT not be the most preferred? Thanks.

    Reply
    • For small deployments such as yours the native site selection process is probably fine. However, for large global deployments this is often a serious issue. I have numerous customers where Windows 10 DirectAccess clients frequently select a suboptimal entry point. For example, recently a customer I was working with had entry points around the world. A client in the UK would connect to an entry point in Hong Kong, when in fact there was an entry point in London.

      If everything is working well for you now, I’d say leave it as is. If not, look at Azure Traffic Manager or, even better, the GEO feature of the KEMP LoadMaster load balancer. I recently did a webinar on this topic in fact. You watch the recording here.

      Reply
  6. AeroRooms

     /  February 8, 2017

    Hi Richard
    Great article. I’m currently trying to setup this with Server 2016 but I fail as I cannot figure out what to enter in the field “Type the global load balancing IP address for this entry point”. Which address must I enter here? The one of the first DA-Server or the trafficmanager.net? Where can I find this address? Thanks

    Reply
  7. Does multi site DA only work with IPv6 on the internal corporate network? We’ve got a single site with load balanced cluster working fine with KEMP, now we have introduced another entry point, technet tells us we MUST use IPv6 on the corp network, editing step 2 the remote access console suggests that also as it asks for an internal prefix. Is there any way to get multi-site working with IPv4 on the corporate network?

    I setup this all up in a lab with IPv4 on both NIC behind a HTTPS NAT and strangely I can connect to the management servers even though they are on IPv4 – however he second tunnel doesn’t come up. I can’t reach the webprobehost nor connect to anything (they work fine not connected from all sources). Seems strange the infrastructure tunnel works but the user tunnels don’t.

    Reply
    • No, not at all. DirectAccess works just fine with IPv4 everywhere on the internal network, even for load-balanced and multisite deployments. In fact, deploying IPv6 internally can sometimes cause more problems than it solves, at least for DirectAccess anyway. 🙂

      Reply
      • Amayacitta

         /  December 22, 2018

        Ok thanks, I’ll follow this up with Microsoft 🙂 cheers for the heads up.

  8. Chris H

     /  April 3, 2020

    Hi. I have a couple questions.

    What would happen if the Traffic Manager goes down and the DNS entry for it is unreachable? Will the machines fail back to using the entry point addresses?

    Can a CNAME be used to point to the Azure Traffic Manager DNS entry?

    Thanks.

    Reply
    • I think the likeliehood of Azure Traffic Manager failing is pretty low, so probably not a scenario to worry about much. However, in the case of DirectAccess, yes the client will simply try to connect to an entry point directly. Also, yes you can use a CNAME entry to point to Azure Traffic Manager. Have a look at the DNS records for directaccess.richardhicks.net. 🙂

      Reply
      • Chris H

         /  April 3, 2020

        Thanks for the very quick reply Richard. Very helpful info.

        BTW looking forward to your talk on the 9th April. The DirectAccess setup I implemented at my company took a lot of info from here. It’s been invaluable. Thanks very much.

      • No problem. Glad you’re finding the site helpful for sure! 🙂

  9. Hi, is it possible just to do a cname of a already configured GSLB name and point that to the trafficmanager name? Then there is no need to change anything on the da config…

    Reply
  1. Deploying DirectAccess in Microsoft Azure | Richard Hicks' DirectAccess Blog
  2. DirectAccess Now a Supported Workload in Microsoft Azure | Richard Hicks' DirectAccess Blog

Leave a Reply to Jonas LindqvistCancel reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading