Exchange 2016 is Microsoft's latest enterprise level messaging and collaboration server. It has been designed for simplicity of scale, hardware utilization, and failure isolation. This has greatly simplified both the deployment process and the implementation of a load balancer.
The CAS role that used to be in Exchange 2010 and 2013 has now been merged into the Mailbox role. Exchange 2016 has been consolidated into two roles: the Mailbox Server role and the Edge Transport Server role. In Exchange Server 2016, the Mailbox Servers form the DAG.
The Exchange 2016 mailbox role includes the same proxied functionality that was in Exchange 2013, meaning that if two servers host different mailboxes they will proxy traffic for each other when required. The mailbox server hosting the active copy of the mailbox will serve the user accessing it, even if the user connects to another mailbox server.
Finally, all client traffic from native Exchange clients like Outlook connect over HTTP/HTTPS. No client connectivity directly via MAPI is allowed. One of the main differences from Exchange 2010 is that all client connections are made using HTTPS. Outlook 2013 SP1 and all later versions of Outlook use MAPI over HTTPS to access their mailbox. Older versions of Outlook do not support MAPI over HTTPS and use RPC over HTTPS (Outlook Anywhere).
Load balancing considerations
Correctly configuring Exchange 2016 as a cluster is a lot easier than the older versions of the product. However, you still need to think about your basic network architecture, your health checks and SSL offloading.
Load balancer deployment method
Exchange 2016 can be deployed using either layer 4 or layer 7 methods. At layer 4, either DR (Direct Return) or NAT mode can be used. Layer 7 utilizes SNAT mode.
For simplicity we recommend using layer 7 SNAT mode. This mode requires no changes to the Exchange Servers and enables the Exchange Servers to be located on any route-able network.
However, for very large deployments supporting many 1000s of mailboxes, layer 4 DR mode can be leveraged to provide maximum load balancing performance.
One-arm layer 4 DR mode is the fastest and most scalable option so where possible this is recommended. If this is not feasible for any reason – for example, the Exchange Servers are located on a different subnet to the VIP - then two-arm layer 4 NAT mode is suggested as this also offers high performance.
Recommended deployment
We've recently changed our recommended deployment mode from layer 4 DR -> layer 7 SNAT. This change was made for several reasons: Layer 7 is easy to configure, the servers can be positioned on any routeable network, no Exchange Server configuration changes are required to handle the ARP problem. But most importantly layer 7 now has ample performance for even the largest Exchange deployments.
Exchange 2016 Health-checks
To ensure that load balancers do not route traffic to a Mailbox server that Managed Availability has marked as offline, load balancer health probes must be configured to check a specific URL for each service in the format:
https://<External FQDN>/<protocol>/healthcheck.htm
For example with the Outlook Web Access service you would use:
https://your.domain.com/owa/healthcheck.htm
Note that healthcheck.htm does not actually exist within the virtual directories; it is generated in-memory based on the component state of the protocol in question.
If the load balancer health probe receives a 200 status response, then the protocol is up; if the load balancer receives a different status code, then Managed Availability has marked that protocol instance down on the Mailbox server. As a result, the load balancer should also consider that end point down and remove the Mailbox server from the applicable load balancing pool.
Persistence (aka Server Affinity) requirements
Due to Exchange 2016's new architecture, all sessions to the Mailbox servers are stateless and therefore persistence/affinity is no longer required on the load balancer.
Virtual Server/Service (VIP) requirements
To provide load balancing and HA for Exchange, the following VIPs are required:
- HTTPS & HTTP (the HTTP VIP is only required for redirecting to HTTPS)
- SMTP
- IMAP4 (If used/required)
- POP3 (If used/required)
Port requirements
The following table shows the port list that must be load balanced. Some services such as IMAP4 or POP3 may not be used in your environment.
| TCP Port | Role(s) | Uses |
|---|---|---|
| 25 | CAS | Inbound SMTP |
| 110 | CAS | POP3 clients |
| 143 | CAS | IMAP4 clients |
| 443 | Mailbox | HTTPS (Outlook Web App, AutoDiscovery, Web Services, ActiveSync, MAPI over HTTP, RPC over HTTP – a.k.a. Outlook Anywhere, Offline Address Book, Exchange Administration Center) Note: Outlook Web App has been renamed as Outlook on the Web in Exchange 2016 |
| 993 | CAS | Secure IMAP4 clients |
| 995 | CAS | Secure POP3 clients |
Deployment architecture
Layer 7 SNAT (without SSL Offload) — Recommended
Layer 7 SNAT Mode (with SSL Offload)
More information
For more information please refer to our complete deployment guide: http://pdfs.loadbalancer.org/Microsoft_Exchange_2016_Deployment_Guide.pdf
