Does your exchange hybrid architecture need to have redundancy? How about an active/passive solution using Azure Traffic Manager elimating the need for a HLB device in your DMZ.

Currently there is a few topologies for configuring Hybrid Exchange with Office 365;

  1. Single Hybrid Server
  2. 2+ Hybrid Server behind a load balancer
  3. 2+ Hybrid Server with DNS round robin

A simple solution to make a redundant Hybrid Exchange design without using a HLB is to leverage Azure Traffic Manager to monitor and service the DNS namespace configured in on-premises Exchange and Office 365 configuration.

Traffic Manager offers:

  • It works at the DNS level, routing traffic between one or more hybrid public endpoints that sit behind the common DNS service name
  • Traffic management policy profiles like failover and performance metrics rather than DNS round robin and TTL.

In my scenario we will make the Primary Hybrid Server the responding IP until the event of a failure. We do this via pro-actively probing the health check page on a web services virtual directory on each Hybrid Server where NTLM challenge authentication is not required for the anonymous probe. If we think about all the services offered across exchange virtual directories that are exposed, Outlook Web Access with forms based authentication seems to be the standout. OWA has a health check page that can be used by load balancers to check for service outages and degredation.


If in the event that this service becomes unresponsive, Traffic Manager will start responding with the secondary server endpoint IP until services resume. We have comfort in knowing that if the OWA page is unresponsive we can be assured that the Exchange Web Services (EWS) virtual directory probably is aswell.

New-AzureTrafficManagerProfile -Name "HybridExchange" -DomainName "" -LoadBalancingMethod "Failover" -Ttl 30 -MonitorProtocol "Https" -MonitorPort 443 -MonitorRelativePath "/owa/healthcheck.htm" | Add-AzureTrafficManagerEndpoint -DomainName "" -Status "Enabled" -Type "Any" | Add-AzureTrafficManagerEndpoint -DomainName "" -Status "Enabled" -Type "Any" | Set-AzureTrafficManagerProfile

Create a CNAME for the hybrid namespace configured with Office 365 to For the example outlined in this blog, I would create a CNAME in my public DNS Zone for with ‘’ to ‘’.



In this solution you will know that the primary Exchange Hybrid Server will always respond to Office 365 web services requests until the event of a failure. This will include free/busy lookups and also mailbox migrations. The benefits of using an active/passive hybrid namespace rather than a HA pair is that the through put of mailbox migration is much higher as EWS requests maintain a persistent connection with the originating Hybrid Server and no load balancer is intercepting/redirecting the traffic. We also have control on the failover/failback timings versus true DNS load balancing with round robin which could take longer to resolve.

This is a simple solution using a cloud service for eliminating the need of any fancy layer 7 load balancing and improving on the simplicity of DNS round robin.

Hot Tip: If you have a Database Availability Group (DAG) on-premises with mailboxes being migrated to Exchange Online. It would be of benefit for your active Hybrid Server to be closer to the mailbox server with the active copy to reduce mailbox move traffic on your local network links during synchronisation.


Azure Infrastructure, Exchange
, , , , , , ,

Join the conversation! 3 Comments

  1. How do you handle autodiscover requests to the hybrid environment in that scenario?

    • Hi Thomas, depending on how your current autodiscover is configured you could move it to the current hybrid boxes or leave it where it might be currently. A reason for moving it to the same solution as the Hybrid namespace might be cause that your Hybrid Servers are current release of Exchange and your CAS/MBX fleet of servers could be of older versions. At the end of the day you just want a XML post message for further details of where the user request should be sent too next and All CAS servers in the organisation will be able to achieve this.

  2. Very nice blog entry. I was looking about the difference about Azure LB an the traffc manger. Now everything is clear. Thank you very much 🙂

    Autodiscover normaly has a static configuration, so you can publish the Autodiscover XML on a webserver.

    If you like it dynamic use the http redirection like in a multi-tenand environment.

    here is a nice blog entry about http redirection:

    Kind regards Philipp

Comments are closed.