One of the great changes in Exchange 2010 over Exchange 2007 is the ability to combine both CAS & Hub roles on mailbox servers configured as DAG, this gives you the flexibility to have a highly available solution with just 2 servers.

Note that you can still combine the UM role on the same servers however it’s not recommended because of the performance impact…

The challenge is that if you are having a requirement for load balancing the CAS or Hub traffic among the two servers you will not be able to use the Windows load balancing service “WLBS” and this is because simply it’s not supported to enable both WLBS and Clustering services on the same server. So the question now is how can you provide the required high availability to the CAS and Hub roles while maintaining the DAG and without using WLBS? to answer this question let’s split the roles.

Hub role:

Hub servers are automatically load balanced by Exchange 2010 for any servers to server submissions, you don’t need to configure any type of load balancing mechanism to load balance the mail submission traffic among the Exchange servers, however some of the environments are having SMTP clients or applications that use Hub servers to send/relay email to either internal users or to external users. To load balance these clients traffic there are two methods that you can use:

1. Use a hardware load balancer and configure it to load balance the SMTP traffic across the Hub servers (preferred)
2. Use DNS round robin (not preferred, and this is due to the fact that if one of the servers is experiencing a failure there will be a possibility that one of the clients will get this server IP as a response to the DNS query and will not be able to send the email however the mail will be released with the next retry attempt)

Note that by any method you will choose it’s a must that you don’t use the selected load balancing method to load balance the server to server communication…

CAS role:

CAS servers traffic can be load balanced using any of the below methods:

1. Use a hardware load balancer and configure it to load balance the CAS traffic “Web & MAPI-RPC”
2. Use ISA/TMG web farm publishing to publish and load balance the traffic for internal users however this will work only with the CAS web services such as OWA, Outlook Anywhere, etc… but not with the Outlook MAPI-RPC traffic if you are configuring your CAS servers in a CAS Array
3. Use DNS round robin however as mentioned before, clients can get a DNS response for a failed server and then they have to re-attempt the connection to receive the next answer from DNS

If we will have a quick analysis to the above options, using a hardware load balancer is definitely the recommended option if you are going to combine the CAS/Hub with a DAG.

In Exchange 2007 we introduced the concept of proxying and redirection to manage the multi sites deployments (Internet facing & Non-Internet facing). In transitioning to Exchange 2010 CAS it’s a must now to use a new legacy Exchange environment with a new URL for OWA & EAS “mostly we use legacy.contoso.com” and which Exchange 2010 will use to serve the non-migrated mailboxes OWA/EAS requests through either redirection or proxying, so the concept of proxying and redirection is still there however they play a much more important role in a coexistence phase with Exchange 2003 or Exchange 2007. Ross posted a great article for transitioning CAS to Exchange 2010 at http://msexchangeteam.com/archive/2009/11/20/453272.aspx and which explain in depth the role of both in the transitioning process. To make it simpler there is a summary at the end of the article which I’m copying below and which is listing when we do proxying and when we do redirect.

To understand why we are introducing a new namespace for the legacy Exchange environment, it is important to understand what the Internet client behavior will be by introducing Exchange 2010.

• For Outlook Web Access, Exchange 2010 CAS does not support rendering mailbox data from legacy versions of Exchange.  Exchange 2010 CAS does one of four scenarios depending on the target mailbox's version and/or location:
• If the Exchange 2007 mailbox is in the same AD Site as CAS2010, CAS2010 will silently redirect the session to the Exchange 2007 CAS.
• If the Exchange 2007 mailbox is in another Internet facing AD Site, CAS2010 will manually redirect the user to the Exchange 2007 CAS.
• If the Exchange 2007 mailbox is in a non-Internet facing AD site, CAS2010 will proxy the connection to the Exchange 2007 CAS.
• If the mailbox is Exchange 2003, CAS2010 will silently redirect the session to a pre-defined URL.
• For Exchange ActiveSync, Exchange 2010 CAS does not support rendering mailbox data from legacy versions of Exchange.  Exchange 2010 CAS does one of four scenarios depending on the target mailbox's version and/or location, and device capabilities:
• If the Exchange 2007 mailbox is in the same AD Site as CAS2010 and the device supports Autodiscover, CAS2010 will notify the device to synchronize with CAS2007.
• If the Exchange 2007 mailbox is in the same AD Site as CAS2010 and the device does not support Autodiscover, CAS2010 will proxy the connection to CAS2007.
• If the Exchange 2007 mailbox is in a non-Internet facing AD site, CAS2010 will proxy the connection to the Exchange 2007 CAS.
• If the mailbox is Exchange 2003, CAS2010 will proxy the connection to the Exchange 2003 mailbox server.
• For Outlook Anywhere, you are going to move the Outlook Anywhere endpoint from the Exchange 2003 Front-End or Exchange 2007 CAS to the Exchange 2010 CAS.  Exchange 2010 CAS will always proxy the Outlook MAPI RPC data that is embedded in the RPC-HTTPS packet to the target legacy mailbox server (regardless of AD site or version) or to the appropriate Exchange 2010 CAS