CAS Load-Balancing Best Practices (Part 1)

  • Article

There just isn't much in the way of How-to / Best Practices type of information regarding load Balancing Client Access Servers in Exchange 2007.  Soon we should be releasing additional Technet content relating to the deployment of Autodiscover and Web Services in the form of an Autodiscover White Paper, but this content doesn't include any information regarding best practices around load balancing Autodiscover and Exchange Web Services.  This information will be crucial for most medium to large companies migrating to Exchange 2007. 

Below are my thoughts on some best practices when it comes to load balancing these Client Access Web Services.  I will be posting a series of posts dedicated to this topic.

CAS Load Balancing Best Practices (Part 1: Internet-facing: NLB, Authentication, InternalUrls, ExternalURLs, Certificates):

Background:
AD Sites that contain Exchange 2007 servers should be thought of in two ways.  Internet-facing sites and intranet (non-Internet facing sites). 

Best Practice #1: ALL Client Access Servers within the same Internet-facing site should be:

  • In an NLB of some sort. Whether Windows NLB, ISA 06 NLB, or Hardware NLB.
  • Have ALL ExternalURL's exactly the same with the public name of the NLB.
  • Have ALL InternalURL's exactly the same with the private name of the NLB.
  • ALL be configured for the same types of authentication for each HTTP based service.

Why do all of them have to be in the NLB?

The real answer here is to eliminate confusion.  Many Exchange 2007 Services (such as Autodiscover) choose Client Access Servers at random for clients to connect to.  If they are all in the same site, they basically server the same function and thus should be in the same place.  If you have some extenuating circumstance like needs to have 2 NLB's (one for internal OWA and one for external OWA), this guidance may not apply to you.  However, you should adhere to the guidance below of having a different private name for each NLB of Client Access Servers.

What is this public name versus private name stuff?

Public Name: This should be the name that the outside world uses to access your Outlook Web Access, Exchange Activesync, and/or Outlook Anywhere services for mailboxes in this Internet Facing site. This would be a manually created DNS entry in your public DNS zone. For instance: **https://usamail.contoso.com/EWS/Exchange.asmx** might be my ExternalUrl for all my WebServicesVirtualDirectory objects in Contoso Corp's USA Site.

Private Name: This should be a manually created DNS name within your internal DNS zone.  This will primarily be used for Exchange Web Services, so you may want to choose a name like ews.ad.contoso.com or websvcs.ad.contoso.com (Notice ad.contoso.com is within my internal DNS namespace). Likewise: https://ews.ad.contoso.com/EWS/Exchange.asmx might be the InternalUrl for all the WebServicesVirtualDirectory objects in Contoso Corp's USA Site.  If you have two different NLB's within the same site for different purposes, you should have two different private names with the InternalUrl's on the corresponding CAS's modified accordingly.

What about certs?

The only real way to do this is to obtain a 3rd party certificate that supports Subject Alternative names.  For a list of Certificate Authorities offering these type of certificates, check this KB article: https://support.microsoft.com/kb/929395/en-us. In most cases, you will only need 3 Subject Alternative Names on a certificate. I suggest:

  • mail.contoso.com (or whatever name you want to use for OWA, EAS, and RPC/HTTP. This should also be the "Issued to" or common name)
  • autodiscover.contoso.com (you will need one of these for every primary SMTP address domain in your organization).
  • ews.ad.contoso.com (one Subject Alternative Name that exists in your internal DNS namespace).

For more information on generating the certificate request see: Creating a Certificate or Certificate Request for TLS on Technet.

What do you mean by have the same authentication for every HTTP service?

For each Virtual Directory in IIS, you should have consistent authentication methods selected for every CAS in your NLB.  If you don't, you'll run into goofy issues when a client that was talking to a certain CAS gets load-balanced to a different CAS.  This doesn't mean that just because you use Basic Auth for OWA that you have to use Basic for Outlook Anywhere.  It just means that if you use Basic on Outlook Anywhere on one CAS, you need to make sure that Basic is configured for every other CAS in the NLB.  This should be common-sense.

I'll cover additional topics such as Client Affinity, Intranet CAS Deployments, etc in later posts.

For the next post in this series, see: CAS Load-Balancing Best Practices (Part 2)