Log in



Network Load Balancing recommended for Exchange 2010 CAS public facing (internet facing) and internal

Wednesday, October 21st, 2009 by

I was reading an interesting note on the Client Access Server role in Exchange 2010 and ActiveSync.  When ActiveSync connects to a CAS it will constantly use that same connection for receiving emails and communication.  What occurs in the event the CAS server goes off line?  The Mobile device will continue to try to connect to that same server.  This means that if you have an outage for an extended period of time users will not be able to receive email on their mobile.   In order to resolve this issue Microsoft recommends to NLB the Client Access Servers both internally and externally (internet facing).  When a device is proxied to the proper CAS it will maintain that connection.  If you point the URL/IP to a NLB device the mobile will use the NLB information rather than the server information.  What this means then is that when a CAS is off line that is behind a NLB device users will use the NLB information and connect to the remaining server rather than trying to connect to the down server. 

MS Provided a nice diagram of Proxying for NLB CAS:

In an organization that has multiple Active Directory sites and multiple Client Access servers in each site, you can use Network Load Balancing (NLB) to optimize traffic among the Client Access servers in each site. We recommend that you include only Client Access servers within the same Active Directory site in a load-balancing array. You can deploy NLB in an Internet-facing Active Directory site and in a non-Internet-facing Active Directory site. The following figure shows two Active Directory sites that implement NLB.

 

As a note it appears that the Hub Transport Server in 2010 is not supported for NLB:  “In many deployments, the installation of the Client Access server role and the Hub Transport server role are on the same computer. In this topology, you can configure NLB for the Client Access server role separately from the Hub Transport server role. Currently NLB isn’t supported on the Hub Transport server role. However, it’s supported for the Client Access server role.”

More info:  http://technet.microsoft.com/en-us/library/bb310763(EXCHG.140).aspx

4 Responses to “Network Load Balancing recommended for Exchange 2010 CAS public facing (internet facing) and internal”

  1. Frank Wang says:

    Hi Scott,
    “As a note it appears that the Hub Transport Server in 2010 is not supported for NLB,in many deployments”

    But if I install dedicate HUB server, can I deploy NLB?
    Thanks.

  2. Scott says:

    Hi Frank,
    I’m going to say yes, with a HW load balancer you should be able to load balance the SMTP inbound traffic. Keep in mind however that this is only four inbound SMTP traffic from the internet or a relay. Internal Exchange communciation should continue to use the IP address of the actual Exchange Server.

    NLB can be used to provide high availability in the following scenarios:
    Load balancing of inbound SMTP connections for POP and IMAP client connections to the default Receive connector named “Client ” that is created only on Hub Transport servers.

    –Load balancing of inbound SMTP connections for applications that submit e-mail to the Exchange organization.

    –NLB should not be used to distribute connections for internal routing between Hub Transport servers.

  3. Julio says:

    Se puede configurar NLB en servidores con el rol CAS en ubicaciones físicas distintas?, como se realiza?.

    Si tuvieran el conocimiento de algun sitio, el cual me guien en este proceso!

    Gracias por su aporte.

  4. Scott says:

    Julio,

    My spanish is very poor. As for your question: A CASArray is restricted to the Active Directory Site it is located in. For example, if you have an AD Site called Home that site can have one CASArray. If the AD Site Home stretched between two different geo sites you could load balance if your networking equipment could do it. However, if the CASArray was stretched between sites users in either site could be directed to either Client Access Server in the CASArray.

    In your instance you would be better off having the CASArray within one AD Site and deploy a secondary AD Site with new CAS in that site and create another CASArray.

    Hope this helps.

    —–

    Julio,

    Mi español es muy pobre. En cuanto a tu pregunta: Un CASArray se limita a la del sitio de Active Directory que se encuentra in Por ejemplo, si usted tiene un sitio de AD llamada Home ese sitio puede tener un CASArray. Si el DC principal del sitio se extendía entre dos lugares geográficos diferentes que podrían equilibrar la carga de si su equipo de red podría hacerlo. Sin embargo, si el CASArray se extendió entre los usuarios de los sitios en cualquier sitio puede ser dirigida a cualquier servidor de acceso de cliente en el CASArray.

    En la instancia que sería mejor tener la CASArray el plazo de un AD de la web e implementar un sitio secundario de AD con el nuevo CAS en ese sitio y crear otro CASArray.

    Espero que esto ayude.

Leave a Reply