ExchangeBytes

d Balancing Exchange 2010 Client Access Roles has never been easier with today technologies. When you load balance Exchange by creating 1 big rule for all ports or even a rule for each port sometimes it is not always the best course of action. With a few simple changes and a lot of IP address an Exchange administrator can build a greater degree of availability into ones environment.

Most all Exchange admins know that more and more Exchange services are moving to web driven services. Services like Outlook Web Access, Exchange Web Services, and ActiveSync all are just a few examples. Like most web services these application rely on either port 443 or port 80. Most load balancers will tell you when a port is up or down and if it is down will remove it from the pool so that users do not get random failures for port 80. Again the scope of you reporting on these protocols is that they are up or down and not which one of the services using the protocol is up or down. Having a single rule for each of these protocols limits the ability of an administrator to know what each services is doing and if it is responding properly. Take the following example.

Environment:
You have 5 servers in a load balanced cluster. You have a hardware load balancer handling all traffic for port 443 and port 80. A rule has been created for each protocol and each of the servers has been configured as the “Real Server” for the above rule. You create an A record in DNS and point it to your load balanced IP address for your CAS Servers. You then configure each of your exchange services to use the A record for web service using the name webmail.domain.com.

Problem: ActiveSync is not functioning for some Users
Users in your environment are reporting that they are randomly unable to receive email on their mobile device. There appears to be no reason why the device works one minute and not the next. In trouble shooting you find that the ActiveSync Service on server 2 is not responding properly to request. Since you have created one rule for port 443 you were never made aware of the situation because port 443 was responding but the service was not.

Solution: Check Port/Check URL
The ability of Load balancers to use both a check port and check parameter on that port will allow you to not only create a rule that checks to ensure that the port is alive but that the requested url is also function properly. To achieve this configuration 1 must create a unique IP address and port combination for each protocol selected. For example, an administrator would create a Virtual IP address (VIP) for each Exchange related web service and assign each web service a rule in the load balancer with port 443 and the proper check url parameter for each web service. Each respective VIP would then have an associated DNS A record for the required service IE (owa.domain.com, oab.domain.com, ActiveSync.domain.com, and EWS.domain.com). Now when a particular services is experiencing a problem it is remove from the pool of available servers automatically for non-response to the check url and users don’t receive random failures