Load Balancing Exchange 2007 Client Access
Servers using Windows Network
Load-Balancing 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 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: 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
Note:
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.
Note:
Legacy clients such as Outlook 2003 and earlier, and Windows mobile 5.0 devices cannot use Autodiscover or availability service.
Prerequisites
• 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.
Creating the FQDN for the NLB Cluster in DNS
With the environment up and running, the very first thing you want to do is to create a record for the NLB cluster name in DNS. To do so log on to the domain controller in your Active Directory forest, then open the DNS manager by clicking Start > Run and type dnsmgmt.msc.
Figure 2.1: Creating a DNS Record for the Windows NLB Cluster name in the DNS Manager Now click Add Host (Figure 2.2) then OK and Done. Close the DNS Manager.
Important:
In order for clients on the Internet to connect to the specified Internet name, you must also create a record on the DNS servers hosting your domain. This task is typically done on the DNS servers located at your ISP.
Configuring the Network Settings
Although not necessary (as explained earlier), we will use unicast mode with two network adapters installed in this setup (this gives us the most optimal performance). To configure the second network adapter in each Exchange 2007 Client Access server, open Network
Connections and give each LAN connection a meaningful name as shown in Figure 2.3.
Figure 2.3: Naming the Network Connections
Figure 2.4: Configuring the TCP/IP Settings for the NLB LAN
Figure 2.5: Changing the binding order for the Network Connections
Enabling Network Load Balancing on the First Client Access Server
Okay it is time to enable NLB on the first Client Access server in our setup. This can be done via the property page of the network adapter, or by using the Network Load Balancing Manager. I will enable it via the property page of the network adapter, and then add the second Client
Figure 2.6: Enabling Network Load Balancing
Figure 2.7: Configuring the Cluster Parameters
Figure 2.8: Configuring the Host Parameters
Click the Port Rules tab then select the default port rule and click Remove.
Figure 2.9: Configuring the NLB Cluster Port Rules
Do this for each required port, so you get a list of rules similar to what is shown in Figure 2.10 depending on what client access services you want to allow in your organization.
Note:
Figure 2.10: List of Configured Port Rules
Click OK and OK again to the Information message you receive (Figure 2.11).
Figure 2.11: Informational dialog box
Figure 2.12: Adding the NLB Cluster IP Address on the TCP/IP Settings Page Finally click Add then OK
We have now set up a Windows NLB cluster with one member server.
Adding the Second Client Access Server to the NLB Cluster
What good is a NLB cluster with only one member server? Correct, not very good. So let us add the second Exchange 2007 Client Access server to the cluster as well. To do so open the
Figure 2.13: Network Load Balancing Manager
Figure 2.14: Adding the Second Client Access Server to the NLB Cluster
Figure 2.16: Second Client Access Server added to the NLB Cluster Close the Network Load Balancing Manager.
We have now load-balanced the two Client Access servers in our lab environment. But there are still quite a few configuration steps to do, but we will take a look at those in part three of this article series.
Testing the Load-Balanced Client Access Server Setup
Figure 3.1: Certificate Security Warning
Figure 3.2: OWA 2007 Forms-based Logon Page
Because of the certificates issue, Exchange ActiveSync and Outlook Anywhere will not work yet, so there’s no reason to test access from those clients at this stage (we will do so later in the article).
Simulating Downtime of the First Node in the NLB Cluster
Accessing OWA 2007 using the NLB cluster name didn’t show us much else than that we were able to connect to the first Client Access server in our NLB cluster. To test whether the single point of failure that exists in organizations with only one Client Access server deployed have been eliminated, let’s try to simulate a malfunctioning Client Access server. We can do this by disabling the NLB LAN network adapter on the first server as shown in Figure 3.3.
Note:
Figure 3.3: Disabling the LAN Connection
With the network adapter disabled, let’s try to access OWA 2007 once again. If the NLB cluster has been configured correctly, a nice OWA 2007 forms-based logon page should appear and things looks good so far.
With that we can conclude the NLB cluster works as expected.
Considerations when running the Hub Transport Server role on the NLB
Cluster Nodes
For economical reasons, many organizations choose to install both the Client Access and Hub Transport server roles on the same physical boxes in order to keep the total number of Exchange 2007 servers as low as possible. If you plan on following a similar approach, and at the same time want to load-balance the Client Access servers using NLB, you must make sure SMTP (and if used secure SMTP aka TLS) are excluded under the Port Rules tab on the NLB property page (Figure 3.4). The reason for this is that Exchange 2007 Hub Transport servers have been
designed with resiliency built in (that is if one Hub Transport server doesn’t respond to an SMTP connection, another Hub Transport server in the site will respond), and therefore shouldn’t be load-balanced using NLB.
Important Note:
If you use other ports for SMTP communication, these should also be excluded in the NLB cluster configuration.
Warning!
Microsoft. The reason is this scenario wasn’t tested extensively using the Exchange 2007 RTM version. It will instead be supported with Exchange Server 2007 SP1.
Figure 3.4: Port Rules Definitions
Creating a new SSL certificate on the First Node
Figure 3.5: Subject Alternative Names on CAS01 Certificate Property page
Figure 3.6: Subject Alternative Names on CAS01 via the Exchange Management Shell
Note:
Because we need a certificate in which multiple FQDNs have to be specified, we must use a subject alternative name (SAN) certificate. At the time of this writing only a handful 3rd party CAs offer these types of certificates, most of which are listed in the following KB article: http://support.microsoft.com/kb/929395.
As we’re going to generate a request for a new SAN certificate, we must use the New-ExchangeCertificate cmdlet for this purpose, as the IIS Manager isn’t capable of creating requests for SAN certificates. To do this launch the Exchange Management Shell, then type the following command (replace the names with your own):
New-ExchangeCertificate –GenerateRequest –SubjectName “C=dk, O=EHLO organization, CN=mailehlo.dk” –DomainName mail.ehlo.dk, autodiscover.ehlo.dk, cas01.ehlo.dk,
cas02.ehlo.dk –FriendlyName “CAS SAN Certificate” –KeySize 1024 –Path c:\CAS_SAN_cert.req –PrivateKeyExportable:$true
After hitting Enter, the thumbprint for the new certificate request will be listed as shown in Figure 3.7.
Figure 3.7: Generating a request for a new SAN Certificate
Submitting the SAN Certificate to a Microsoft Certificate Authority
With the SAN SSL certificate request generated, we can submit it to our Microsoft CA, or almost that is. The reason I why I say so, is because by default a Microsoft CA cannot handle
certificates with the SAN field properly. To fix this issue log on to the Domain Controller and open a command prompt window, then type the following command:
Certutil –setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Figure 3.8: Changing the EditFlags on the Microsoft CA
Now restart Certificate Services (CertSVC) service on the Microsoft CA server (Domain Controller) in order to have the changes applied (Figure 3.9).
Figure 3.9: Restarting the Microsoft Certificate Service
We’re now ready to submit the certificate request to the Microsoft CA. One way to do this is to open a browser and type http://dc_name/certsrv. On the Welcome page, click Request a
Figure 3.10: Microsoft Certificates Welcome page
Figure 3.11: Requesting a Certificate
On the Advanced Certificate Request page, click Submit a certificate request by using a encoded CMC or PKCS #10 file, or submit a renewal request by using a
Figure 3.12: Selecting the second option on the Advanced Certificate Request page
Figure 3.13: Submitting the Certificate Request
Figure 3.14: Downloading the issued Certificate
It’s time to import the issued certificate using the Import-ExchangeCertificate cmdlet. We do this by typing the following command:
Import-ExchangeCertificate –Path c:\certnew.p7b
The certificate has now been imported to the personal certificate store.
Figure 3.15
To verify the certificate looks like expected, let’s now type the following command:
Figure 3.16: SAN Certificate - Detailed Information
Finally we need to enable the certificate for the client services, our end-users will use to connect to their mailboxes. In this setup I’ll enable the certificate for OWA, EAS, Outlook Anywhere, POP3 and IMAP4. To do so we need to type:
Enable-ExchangeCertificate –Thumbprint <thumbprint> -Services “IIS, POP, IMAP”
Figure 3.17: Enabling the SAN certificate
The certificate has now been enabled for these services but only on the first Client Access server in our NLB cluster.
Importing and Enabling the SAN SSL certificate on the Second Client Access
Server in the NLB Cluster
Select Computer Account > Click Next > Finish > Close and finally OK. Expand Certificates (Local Computer) > Personal, then right-click on the certificate that should be exported. On the context appearing menu, select All Tasks > Export (Figure 3.18).
Figure 3.18: Selecting Export on the Context Menu
Figure 3.19: Exporting the private key
Figure 3.20: Selecting the format to use
Enter a password and click Next (Figure 3.21). Note:
Figure 3.21: Enter a password in order to protect the private key
Figure 3.22: Specifying the path for the .PFX file Finally click Finish.
Okay with the certificate exported, let’s copy it to the C: drive of the second Client Access server, and then open the Exchange Management Shell on that server. To import the certificate, type the following command:
Import-ExchangeCertificate –Path c:\exported_cert.pfx –Password:(Get-Credential).password
Figure 3.23: Importing the certificate
After clicking OK, the certificate has been imported (Figure 3.24).
Figure 3.24: Certficate imported
Now copy the certificate thumbprint to the clipboard, then enable the certificate for the required services by typing the following command (just like we did on the first Client Access server):
Figure 3.25: Enabling the SAN certificate on the second Client Access Server
The SAN certificate has now been properly enabled on both servers, and if the clients trust the root CA from our internal Microsoft CA, we should no longer get security warnings, when accessing OWA via the NLB cluster name as shown in Figure 3.26.
Testing Outlook 2007 Connectivity
Now that we have verified OWA 2007 access works as expected, let’s move on and test
connectivity using Outlook 2007. In order to do so, let’s switch to the client machine and launch Outlook 2007. On the Auto Account Setup page, enter the name, E-mail address and password for a mailbox-enabled user in your setup then click Next.
Figure 3.27
Using the Exchange 2007 Autodiscover service, Outlook 2007 will now try to configure your Outlook profile settings automatically. If everything goes well, the configuration should
complete within a minute and you should see a screen similar to the one shown in Figure 3.28. Note:
Figure 3.28: Outlook configuration completed successfully
Now that the Outlook profile has been configured properly, click Finish in order launch Outlook 2007. With Outlook open, let’s see whether the autodiscover service works properly. We can do this by right-clicking on the Outlook icon in the System tray, while holding down the CTRL key, then in the context menu selecting Test E-Mail AutoConfiguration. On the Test E-mail AutoConfiguration page, enter your E-mail address and password, then clear Use Guesssmart and Secure Guesssmart Authentication and click Test.
Figure 3.29: Autodiscover dependent features works as expected
If we click on the XML tab, we can see the content of the Autodiscover XML file used by the respective Outlook profile (Figure 3.30).
Testing Exchange ActiveSync Connectivity
In this article we won’t use a Windows Mobile device to test whether Exchange ActiveSync (EAS) works as expected. Instead we’ll use the Test-ActiveSyncConnectivity cmdlet which allows us to simulate a full synchronization from a Windows mobile device against a specified mailbox.
To test Exchange ActiveSync connectivity via a specific Client Access server type:
Test-ActiveSyncConnectivity –ClientAccessServer <name of CAS>
As can be seen in Figure 3.31 below Exchange ActiveSync connectivity to a mailbox works fine via both Client Access servers (the latency is of course not acceptable, but this is a test lab).
Figure 3.31: Testing Exchange ActiveSync Connectivity For more detailed test results type:
Test-ActiveSyncConnectivity –ClientAccessServer <name of CAS> | FL
