MSExchange.org Monthly Newsletter of February 2010 Sponsored by: Red Gate
Welcome to the MSExchange.org newsletter by Henrik Walther, Exchange MVP, MCA: Messaging (Exchange Ranger) Apprentice, MCTS Windows Server 2008, MCITP Exchange 2007, MCSE 2003 Messaging/Security. Each month we will bring you interesting and helpful information on Exchange Server. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: firstname.lastname@example.org
1. Exchange 2010 RPC CA arrays - A word on load balancing
Welcome to the February edition of the MSE Newsletter! This month I want to clarify a few things when it comes to load balancing the RPC traffic going from internal Outlook MAPI clients to an Exchange 2010 RPC Client Access array (RPC CA array). There seems to be some confusion on how to properly load balance the RPC traffic going to an RPC CA array. More specifically, the confusion is based mostly around whether or not you can use a reverse proxy server such as ISA, TMG, or UAG to load balance the RPC traffic. Especially SMORGs (small and medium organizations) want to have a highly available Exchange 2010 solution consisting of a total of two physical or virtual machines. As I have explained in a previous MSE newsletter (back in June 2009), you can, unlike in Exchange 2007, combine the HT, CAS, and MB roles on the same server even when the server is a DAG member. However, when doing so you cannot use Windows NLB to load balance and provide high availability for a RPC CA array. This is because WNLB and Failover clustering is not supported on the same server as it can result in hardware sharing conflicts (read more about this here).
Although you now can get a fully redundant Exchange 2010 solution consisting of only two machines, each with the CAS, HT, and MB roles installed, you still need to invest in an external software or hardware based load balancer solution as well. SMORGs that already have a load balanced and highly available proxy server solution based on ISA, TMG, or UAG would likely want to use this existing solution as the load balancer for the Exchange 2010 CAS array even though this would result in sending HTTPS and RPC traffic from the internal network to the reverse proxy server solution located in the perimeter network/DMZ. The reason for this is pretty simple. Limited budgets mean that they would need to find alternative solutions which do not involve spending hard cash on new soft/hardware
So is this a supported scenario by the Exchange Product group? The short answer is no. The long answer is that it is not supported by the Exchange Product group since ISA, TMG, or UAG cannot load balance RPC traffic (more specifically port 135/TCP (endpoint mapper) and the dynamic RPC port range 1045-65535). These products are only capable of load balancing Internet protocol traffic such as HTTPS. This means that you can use ISA, TMG, or UAG to load balance all web based Exchange clients and services including Outlook Anywhere (since Outlook Anywhere encapsulates RPC traffic in HTTPS packet), but not RPC traffic from internal Outlook MAPI clients.
There is currently an idea floating around in both the MCM (the Exchange and Exchange MVP community, and possibly other places as well) on how you can build a two-Exchange 2010 server solution and load balance traffic to the CAS array without using an external load balancer. The idea is to use the cluster core resources (that are created and used by DAG) to load balance traffic to the CAS array. Although the idea is interesting it is important to bear in mind that at the time this article was written this approach is both unsupported and untested by the Exchange Product group. Time will tell whether this will change, but for now please don’t go down this path.
Some folks also thought about using DNS round robin with a low TTL value for the RPC CA/CAS array records, but this is not recommended since using DNS round robin to load balance traffic would not provide the affinity required for OWA, ECP, EWS, OA etc.
In order to load balance traffic going to the RPC CA/CAS array, you should use a “real” software or hardware based load balancer. Remember, you need two in order to avoid introducing a single point of failure. But as I will show you in an upcoming multi-part article of mine, a powerful hardware-based load balancer of high quality does not have to cost thousands of dollars.
BTW if you noticed that the Two-Member DAG in Single Datacenter/Active Directory Site section in the Exchange 2010 online documentation on Microsoft TechNet seems to state you can use ISA for this purpose, do not believe it!? I already made the Exchange Product group aware of this doc bug and it will be fixed in the near future.
Until next month,
2. Order Henrik Walther's Exchange Server 2007 book
3. MSExchange.org Learning Zone Articles of Interest
We have a great group of articles in the Learning Zone that will help you get a handle on your most difficult configuration issues. Here are just a few of the newer and more interesting articles:
4. KB Articles of the Month
Below, you will find the Exchange 2003 and 2007 related KB articles that were published since the last MSE newsletter.
Exchange Server 2010
There are no Exchange 2010 specific KB articles this month.
Exchange Server 2007
Exchange Server 2003
5. MSExchange News of the Month
6. Ask Henrik Walther a question
I need to establish GAL synchronization between an Exchange 2010 organization (target org) and two Exchange source organizations - one Exchange 2003 and one Exchange 2007.
Can I use IIFP in order to synchronize GALs between these organizations?
It's not recommended to use IIFP as this product does not have support for Exchange 2010 provisioning. The only provisioning tools that support Exchange 2010 is ILM 2007 FP1 Service Pack 1 and FIM 2010 RC1 Update 3.
If you want to use IIFP, you need to manipulate the contact objects using Set-Contact once they have been replicated to either an Exchange 2007 or Exchange 2010 organization. Read more here.
The contact objects created by IIFP work fine with Exchange 2000. So you don’t have to manipulate them after they have been synchronized to the Exchange 2003 organization.