Learn about how Microsoft simplified the number of namespaces needed for Exchange Server and how to use that improvement to load balance Client Access services.
- [Instructor] In large exchange deployments it becomes important to manage the traffic handled by the exchange servers. Exchange Server 2016 has built in load balancing features that have changed quite a bit since Exchange 2010. In this chapter, we're going to take a look at how they work, including some new benefits and some new concerns. Let's start with namespace A very old school method of load balancing your servers is to assign each server a different namespace and then ask different collections of users to use the different server addresses.
Executives, for example, would use corpmail.landonhotels.com, and the sales department would use mail1 and the support staff would use mail2. There's a problem with this. If all users are at the same site, the proxy feature of Exchange 2016 will make each namespace function just fine for any user. Now that may not sound like a problem until your users start comparing experiences and engineering their own solutions to problems that may or may not exist.
Imagine that one use complains about the speed of their email connection and another employee says, well mine is fine, so long as I use corpmail instead of mail1. Because Exchange will proxy that client request back to the mailbox database, this could lead to a rash of people all moving to the executives' namespace. Say goodbye to any load balancing. Another solution is a single namespace and a simple DNS Round Robin. DNS Round Robin is easy to set up and it will do a decent job of load balancing between servers under some conditions.
For those less familiar with it, it can be accomplished inside the administrative tool for DNS. So here we are on the domain controller and DNS server and under the tools menu, I'm just gonna open the DNS tool. When I expand out the forward lookup zone for our landonhotels.com domain, I'm going to right-click and add a new host. You can't do an alias or some other type of record for this. It does need to be a host record.
The name we're going to use is the namespace we're going to ask all users to type in. If we want all users to be able to type in mail.landonhotels.com, then we simply put a host name of mail. It will verify what the FQDN will be, and then I'm going to add the IP address of the first email server. Since we have DNS open right here it's easy to move this off to the side and verify what that IP address will be.
Exchange 01 is using 10.3.66.122. After I add that host, you'll notice that the new host box has not closed. I can make an additional host entry for the same host name, mail, and this time put in the IP address of the second exchange server, which is 10.3.66.123.
I could continue to do this for every exchange server in a large organization, but once I'm done, I'm going to close out of this new host box and I'm going to look at the properties of the server itself. In the properties dialogue, I'm going to take a look at the advance tab. I'm checking to see that Round Robin is enabled. It's generally enabled by default but this is where you can check if you need to be sure. With this configuration in place, clients that request mail.landonhotels.com will be rotated through the various IP addresses assigned to that host.
Now this is a simple load balancing trick that can be helpful if a couple of conditions are met. First, all users are querying this DNS server. If a user is accessing mail from home, and their router or ISP caches DNS requests then everyone connecting from that path is going to use the same IP every time until the cache expires. The next condition is that all addresses in the Round Robin provide an equivalent experience.
If two servers in the Round Robin are located at our Los Angeles data center and a third is at our Phoenix data center, every third request will be slower, as they're directed over the WAN link. Think of how much more pronounced it becomes if that third server isn't in Phoenix it's in say, Munich. This is where addressing in multiple namespaces does become a bit more useful. Using URLs of mail.na for North America and mail.eu can help direct people to the mail server near them to be authenticated.
When we talked about proxy versus redirection it was mentioned that when a user's mailbox is in a different active directory site the user could be redirected to an appropriate location. The benefit of this set up can be illustrated by this scenario where an employee from southern California travels to Germany. Outlook on their laptop is configured to access corpmail.na.landonhotels, but one of the local employees tries to tell them to use the EU namespace instead because that server is closer.
When the employee tries to logon to the corpmail.eu address Exchange queries active directory and finds that the mailbox is located in North America. The user is redirected to authenticate to the corpmail.na server for their best experience. Now these separate namespaces have effectively maintained the best user experience by comparing the lag time between authenticating in Europe and getting to the mailbox in North America or just reaching across the ocean to login to the North America servers.
In addition to maintaining this user experience, they've load balanced the client request to maximum efficiency of the wide area network. In the coming segments we're going to explore more sophisticated load balancing options that consider both transport and application layer information.
- Planning namespaces
- Managing proxies and redirection
- Configuring client access
- Working with online servers
- Managing address lists and offline address books
- Allowing, blocking, and quarantining access
- Load balancing namespaces
- Troubleshooting POP/IMAP connectivity
- Troubleshooting Outlook Anywhere
- Resilient namespaces and URLs
- Configuring certificates for failover