Skip to main content

Load Balancing Exchange 2007 Client Access Servers using Windows Network Load-Balance


How to load-balance Exchange 2007 Client Access Servers (CAS) using Windows Network Load Balancing (WNLB) technology.

In this article I will show you how you can load-balance Exchange 2007 Client Access Servers (CAS) using Windows Network Load Balancing (NLB) technology. By implementing a load-balancing solution, you can distribute client workload among multiple servers and thereby increase performance and decrease downtime by eliminating the single point of failure that exists in a topology with only one single Client Access server.

Bear in mind that a load-balancing solution can also be accomplished using a 3rd party load-balancing solution, but as mentioned we will base this article on the NLB component in Windows Server 2003. NLB works well and should be a suitable solution for most enterprise organizations.

What is Network Load Balancing and how does it Work?

Network Load Balancing (NLB) technology can be used to distribute client requests across a set of servers. Windows NLB is often used to ensure that stateless applications such as IIS-based web servers can be scaled out by adding additional servers as client load increases. Doing so makes sure that clients always experience acceptable performance levels. In addition, it reduces downtime caused by a malfunctioning server as the end-users will never know that a particular member server in the Windows NLB is or has been down.
Windows NLB clusters can provide scalability for services and applications based both on TCP and UDP. On top of that you can have up to 32 servers in a Windows-based NLB cluster.
Windows NLB is included in both the Windows Server 2003 Standard and Enterprise edition (even the Web edition includes this component), and because Windows NLB is a standard component, it does not require you to use any special or specific server hardware for each member server in the NLB cluster.
When Windows NLB has been properly configured, all servers in the NLB cluster are represented by a single virtual IP address and by a fully qualified domain name (FQDN). When a client request comes in, it will be sent to all servers in the Windows NLB cluster. The client will then be mapped to a particular server and the request to the other servers will be dropped. Having said that, you can use affinity to direct specific client request to particular member servers. You can even configure each member server with a priority.
Figure 1.1 below shows a very simple setup consisting of two Exchange 2007 Client Access servers configured in a Windows NLB. Both Client Access servers accept the client requests and send them to the respective back-end servers depending on the type of request.

Figure 1.1: Load-Balanced Exchange 2007 Client Access Server topology

Unicast and Multicast Mode

A Windows NLB cluster can be configured in either unicast or multicast mode, where unicast is the default mode.
Unicast Mode
With the WNLB cluster configured in unicast mode, the MAC address of each server’s network adapter will be changed to a virtual cluster MAC address, which is the MAC address that will be used by all servers in the Windows NLB cluster. When unicast mode is enabled, clients can only connect to the servers using the cluster MAC address.

Multicast mode
With the Windows NLB cluster configured in multicast mode, a multicast MAC address is added to the cluster adapter of each server in the cluster. Note that I write “is added”, as each server will retain their original MAC addresses.

A Windows NLB cluster, no matter what mode it is configured in, works with just a single network adapter installed in each server, but it is recommended to install a second network adapter in each server, in order to achieve optimal performance, and to separate ordinary and cluster related network traffic.
So what mode should I use for my Exchange 2007 Client Access solution and how many network adapters should I install in each Client Access server? Well, best practice recommendations are to install two network adapters and use unicast mode, so that the host and cluster network traffic are each separated in their own respective network adapter.
In addition to Windows NLB, you also have the option to use DNS round robin mechanisms to load balance the Client Access servers in your Exchange 2007 messaging environment, but the Windows NLB is recommended over DNS round robin as the latter only provides a minimum level of fault tolerance. The reason being that if a particular Client Access server does not respond to client requests, the client requests must be repeated until a server responds as information about client connections and unavailable Client Access servers are not maintained. Because the Windows NLB component is included in both the Windows Server 2003 Standard and Enterprise edition, there is really no excuse for choosing DNS round robin over WNLB.

Although the above might make it sound complex and time consuming to deploy a Windows NLB-based load-balancing solution, it is actually relatively easily to accomplish, as I will show you throughout this article series.
Purpose of the Client Access Server

Before we dive into the configuration part of Windows NLB clusters, I thought it would be a good idea to give you a brief description of what purpose Client Access servers have. This will give you a better understanding of why it is important to load-balance this Exchange 2007 server role.
The Client Access Server replaces the front-end server we know from Exchange 2000 and 2003 and adds some additional functionality. The Client Access server provides mailbox access for all types of Exchange clients except Outlook MAPI clients, which as most of you are aware, connect directly to the Mailbox Server. This means the Client Access server manages access for any user who accesses their mailbox using Outlook Anywhere (formerly known as RPC over HTTP), Outlook Web Access (OWA), Exchange ActiveSync (EAS), POP3 and last but not least IMAP4.
In addition to providing client access, the Client Access server is also responsible for providing access to things such as automatic profile configuration, free/busy information, Out of Office (OOF) messages, the Offline Address Book (OAB) as well as Unified Messaging (UM), but only with respect to Outlook 2007 and Outlook Web Access 2007 (and Windows Mobile 6.0 devices sometime in the future). These are the only two clients, which can take advantage of the new web-based Exchange Autodiscover and Availability service, which are responsible for providing access to the above mentioned client features.

Legacy clients such as Outlook 2003 and earlier, and Windows mobile 5.0 devices cannot use Autodiscover or availability service.


If you want to deploy the solution explained in this article series in your own lab environment, you will need the following:
  • 1 server acting as Domain Controller (with the Microsoft CA component installed)
  • 2 servers with the Client Access server roles deployed (two NICs in each)
  • 1 server with the Mailbox and Hub Transport server roles deployed
  • 1 Windows XP/Vista client with Outlook 2007 installed
Depending on your specific hardware specifications, you could install the Mailbox and Hub Transport server roles on the domain controller, but even in lab environments it is a good idea to keep the roles separated.
To get up to speed as quickly as possible, I recommend you use a virtual environment, and make use of a parent disk. This makes it a breeze to get your servers up and running by using linked clones.
You now know what a NLB cluster is all about and can begin to set up your lab environment. This will enable you to be ready for the next part of this article series which will provide you with step-by-step instructions to configure a Windows NLB cluster.


Popular posts from this blog

Recreating a missing VMFS datastore partition in VMware vSphere 5.x and 6.x

    Symptoms A datastore has become inaccessible. A VMFS partition table is missing.   Purpose The partition table is required only during a rescan. This means that the datastore may become inaccessible on a host during a rescan if the VMFS partition was deleted after the last rescan. The partition table is physically located on the LUN, so all vSphere hosts that have access to this LUN can see the change has taken place. However, only the hosts that do a rescan will be affected.   This article provides information on: Determining whether this is the same problem Resolving the problem   Cause This issue occurs because the VMFS partition can be deleted by deleting the datastore from the vSphere Client. This is prevented by the software, if the datastore is in use. It can also happen if a physical server has access to the LUN on the SAN and does an install, for example.   Resolution To resolve this issue: Run the  partedUtil  command on the host with the issues and verify if your output

ما هى ال FSMO Roles

  بأختصار ال FSMO Roles هى اختصار ل Flexible Single Operation Master و هى عباره عن 5 Roles فى ال Active Directory و هما بينقسموا لقسمين A - Forest Roles 1- Schema Master Role و هى ال Role اللى بتتحكم فى ال schema و بيكون فى Schema Master Role واحد فى ال Forest بيكون موجود على Domain Controller و بيتم التحكم فيها من خلال ال Active Directory Schema Snap in in MMC بس بعد ما يتعمل Schema Register بواسطه الامر التالى من ال Cmd regsvr32 schmmgmt.dll 2-Domin Naming Master و هى ال Role المسئوله عن تسميه ال Domains و بتتأكد ان مفيش 2 Domain ليهم نفس الاسم فى ال Forest و بيتم التحكم فيها من خلال ال Active Directory Domains & Trusts B- Domain Roles 1-PDC Emulator و هى ال Role اللى بتتحكم فى ال Password change فى ال domain و بتتحكم فى ال time synchronization و هى تعتبر المكان الافتراضى لل GPO's و هى تعتبر Domain Role مش زى الاتنين الاولانيين و بيتم التحكم فيها من خلال ال Active directory Users & Computers عن طريق عمل كليك يمين على اسم الدومين و نختار operations master فى تاب ال PDC Emu

Unlock the VMware VM vmdk file

  Unlock the VMware VM vmdk file Kill -9 PID Sometimes a file or set of files in a VMFS become locked and any attempts to edit them or delete will give a device or resource busy error, even though the vm associated with the files is not running. If the vm is running then you would need to stop the vm to manipulate the files. If you know that the vm is stopped then you need to find the ESX server that has the files locked and then stop the process that is locking the file(s). 1. Logon to the ESX host where the VM was last known to be running. 2.  vmkfstools -D /vmfs/volumes/path/to/file  to dump information on the file into /var/log/vmkernel 3.  less /var/log/vmkernel  and scroll to the bottom, you will see output like below: a. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)FS3: 130: <START vmware-16.log> b. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)Lock [type 10c00001 offset 30439424 v 21, hb offset 4154368 c. Nov 29 15:49:17 vm22 vmkernel: gen 664