Creating a Network Load Balanced Cluster for the Client Access Server and Hub Transport Server Roles Hosted on the Same Server



In Exchange 2003, it was very common for admins to create a Network Load Balance (NLB) cluster out of their Front End servers.  The reason was that Front End Servers usually where their to provide internet access to internal resources.  Instead of having OWA URL’s like this:

A company could have just, and create a NLB cluster of it’s internal Front End servers.  Since FE servers are essentially web servers in that their data is static, they lend themselves very well NLB clusters.

In Exchange 2007, the Front End server is replaced by the Client Access Server role.  It still makes sense to create a NLB cluster out of these roles because they server a similar purpose to Exchange 2003 Front End servers.  In order to save on hardware costs, many companies place their Hub Transport server roles on the same server as Client Access servers.

In Exchange 2007 RTM, it was supported to NLB the Client Access Server, even if the Hub Transport role was installed on the same server, you just couldn’t NLB the Hub Transport server. Now there are many arguments as to why you wouldnt need to load balance the HT role.  First, Mailbox servers, as long as they dont have a HT role installed, automatically load balance against any HT server in the same AD site, so why do you care?

One positive is if you use an application that can only specify a single smarthost as its manner of sending email.  If you specify one server, and that server goes down, you have a disruption to your application.  You could use Round Robin DNS, but it is not nearly as efficient as NLB, as it requires requests to fail often before it fails over.  There is no way that DNS will stop sending requests that the IP that’s down.  It will continue to send requests, wait for it to time out, wait for the client to send the request again and then send it to the working server.

Another positive is if you have gateway SMTP servers (sorry Microsoft, we don’t ALL use Edge Transport servers) that forward email to an internal smarthost?  Use the NLB cluster IP, and dont worry if one server has to go down for maintenance, expected or unexpected.  There will be no disruptions in mail flow.

In Exchange 2007 SP1, it is now supported to have a NLB between nodes that have both the CAS role and the HT role installed on them.

Here is our test environment:

  1. NYDC01.ponzeka.test (Domain Controller) –
  2. Exchange2003.ponzeka.test (Exch2003) –
  3. NYHT01.ponzeka.test (Exch2007 HT and CAS) –
  4. NYHT02.ponzeka.test (Exch2007 HT and CAS) –
  5. NYMB01.ponzeka.test (Exch2007 MB) –

You can create a NLB out of any version of Windows Server 2003, Enterprise Edition is not needed.

The first thing you need to do is actually install Exchange 2007 on all the servers.  Remember, the first role you should install should be the Client Access Server, then the Hub Transport, and finally the Mailbox Server.  In our case, we have an existing Exchange 2003 environment.  Current NYHT01 is the bridgehead server between the 2007 and 2003 routing groups:

ScreenHunter_02 Dec. 01 21.43

After we have installed all of Exchange 2007, updated it, done all our restarts, we are ready to install the NLB.  I will not go into the proper steps for the migration of an Exchange 2003 environment, as that has been covered by numerous people.  We are keeping the 2003 environment to show how it would interact with the NLB cluster.

The first thing we want to do is create the DNS alias for our NLB cluster, ours will be mail.ponzeka.test pointing to IP address  This IP isn’t in use yet, but we will assign it to the IP of the cluster once its created.

ScreenHunter_03 Dec. 01 21.53

Now, there are two types of communications for NLB cluster, Unicast and Multicast.  In multicast the hearbeat is sent over the same NIC as production data with a changed MAC address, and in Unicast, there are two network adapters, one is dedicated to production, the other to the hearbeat network, we will use Unicast.

Assign NYHT01’s Heartbeat NIC the IP address and a subnet of  Leave the gateway and DNS blank.  Assign NYHT02’s heartbeat NIC

ScreenHunter_04 Dec. 01 21.57

Make sure that each server can ping the other’s hearbeat IP address, this is what the servers will use to send information regarding their status in relation to the cluster over:

ScreenHunter_05 Dec. 01 22.01

Now on each servers, go to Control Panel –>Network Connections->Advanced->Advanced Settings.  Make sure the Production network is the highest in the binding order:

ScreenHunter_06 Dec. 01 22.02

Now we need to install Network Load Balancing on the heartbeat adapters.  On NYHT01, right click the Heartbeat connection and select properties.  Select the check box next to Network Load Balancing:

ScreenHunter_07 Dec. 01 22.04

Select Network Load Balancing and hit Properties. Under Cluster IP Config, the IP address is the one for the NLB cluster, which before in DNS we stated was and the Full Internet (DNS) name, which is mail.ponzeka.test.

ScreenHunter_08 Dec. 01 22.08

Now select the Host Parameters Tab.  Here, enter in the IP address for the Heartbeat NIC for NYHT01, which is

ScreenHunter_13 Dec. 01 22.51

Now select the Port Rules Tab.  Here is where you specify with ports the NLB cluster will listen, and react to.  As you can see by default it listens to EVERYTHING.  We don’t want that.  Remove the default rule.

Click Add, and uncheck the box “All”, enter in the Cluster IP address manually.  If you select ALL, in our case it accomplishes the same thing.  You can have multiple Cluster IP’s, and choose which cluster IP responds to what port. The other option you need to change is Affinity.  If the service is coming from the internal network, it should be Single.  If it’s originating from the internet, Class C.  If in our case, it will be doing both, we can set the ones that will be accessed by the internet to Class C, and others to internal.  In our case we will leave everything to Class C.  Your final screen should look like this:

ScreenHunter_10 Dec. 01 22.25

The ports are as follows:

  1. 25 – Default SMTP Port, should be allowed (HT)
  2. Port 80 – Default HTTP Port, should be allowed (CAS)
  3. Port 110 – Default POP3 Port, should be allowed (CAS)
  4. Port 143 – Default IMAP Port, should be allowed (CAS)
  5. Port 443 – Default HTTPS Port, should be allowed (CAS)
  6. Port 587 – Default SMTP with TLS Port, should be allowed (HT)
  7. Port 993 – Default Secure IMAP Port. should be allowed (CAS)
  8. Port 995 – Default Secure POP Port, should be allowed (CAS)
  9. Port 465 – Default Implicit SSL SMTP Port, should be disabled (CAS) as Exchange cannot use

After you hit OK, hit OK to the warning, and add the Cluster IP as a secondary IP to each cluster nodes heartbeat NIC:

ScreenHunter_14 Dec. 01 22.52

Hit OK, and you know have a NLB cluster working with one node, which makes NO SENSE!  We need to add the second node to the cluster.  We do this using Network Load Balancing Manager.

After loading, select “Connect to Existing” , enter the IP address of the cluster:

ScreenHunter_12 Dec. 01 22.36

To add the second node, right click mail.ponzeka.test and select add host to cluster:

ScreenHunter_15 Dec. 01 22.56

Select Next.  Make sure the priority number is unique in the cluster, select finish. All of the configurations we made on NYHT01, should now be made on NYHT02. Now the cluster is up!

There are some changes we need to make, specifically to the Hub Transport part of the cluster.  Open Exchange Management Console, navigate to Server Configuration –> Hub Transport, select NYHT01, and then right click Default NYHT01 and select properties.  on the Network tab, select “All Available IPv4 address” and select edit:

ScreenHunter_16 Dec. 01 23.05

Change it to an IP address, and specify the IP address of NYHT01, NOT THE CLUSTER.

ScreenHunter_17 Dec. 01 23.05

The default receive connector is used for communications between the Hub Transport servers themselves.  We do not want the NLB cluster dealing with this, as it is crucial for mail flow that each HT server participate in this process on its own.  Repeat this process for NYHT02.

Now you may ask, hey, I can no longer connect to the cluster on port 25, which defeats a BIG purpose of why I did this:

ScreenHunter_18 Dec. 01 23.10

What we are now going to do, is create a new receive connector on port 25, and have it listen on the cluster IP address.  You will need to do this for each node in the cluster.

Still under Server Configuration-> Hub Transport->NYHT01, click “Create new Receive Connector”

Name it NLB Relay, leave as custom:

ScreenHunter_19 Dec. 01 23.11

Change the IP address to only listen on the NLB cluster IP, and change the FQDN to that of the cluster, mail.ponzeka.test:

ScreenHunter_20 Dec. 01 23.12

Set the “receive mail from” according to your internet security settings, select next, and click new to create.  Repeat for NYHT02. Now we can telnet to the cluster on port 25:

ScreenHunter_21 Dec. 01 23.15

Notice how the SMTP banner reads mail.ponzeka.test the name of the NLB cluster.

Grant any required permissions for the receive connector by right clicking on it, selecting properties and navigating to the “Permission Group” tab.

Now lets see if the cluster actually works.  We need to stop NYHT01, and see if NYHT02 takes over.  I will shutdown NYHT01, and see if we can still telnet to the cluster.

With NYHT01 down, we are still able to telnet to the cluster:

ScreenHunter_22 Dec. 01 23.21 .

So we are pretty much all set.  Some words of advice though.  Outgoing emails, there isnt a need to load balance because you load balance HT servers on the Send Connector Source Server properties Tab.  This ensures that if one HT is down, its routed through the other one.  This feature is native to Exchange 2007 and need’s no additional configuration. 

For the Client Access Server, we see that if we access the OWA page at https://mail.ponzeka.test/owa, we are presented with the OWA page.  Keep in mind NYHT01 is still down:

ScreenHunter_23 Dec. 01 23.24

Since a NLB is used with static data, such as a web server, make sure you configure items identically on each CAS server, such as certificates.  You should try to use Subject Alternative Name (SAN) certificates whenever possible, but remember if your OWA is facing the internet, make sure that you got the subject name for the page internet users will be accessing it on.  The certificates will need to be requested by, imported on, and assigned by each CAS server.

Stay tuned for the next article which will cover the CAS part of the cluster in more depth.  I’ll show you how to create certificates for the CAS servers, and ensure they work across the cluster.


P.S. Lot of thanks to Henrik Walther over at for a lot of great info regarding the HT part of the clustering!  Great site, head on over and check it out.

Leave a Reply

Your email address will not be published. Required fields are marked *