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.
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
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.
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.
Now expand the Forward Lookup Zones container and right-click on the respective forward lookup zone for your Active Directory. On the context menu select New Host (A), then type the name you want to use. As you can see in Figure 2.1, I used MAIL for the purpose of this setup. Then type the IP address you want to use as the Windows NLB cluster IP address (this should be an IP address on the same subnet as the NLB member servers).
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.
Figure 2.2: Entering the DNS name and IP address
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
Now open the Property page for the NLB LAN adapter, then configure the TCP/IP settings as shown in Figure 2.4. As you can see you should only specify an IP address and a Subnet mask. When ready click OK.
Figure 2.4: Configuring the TCP/IP Settings for the NLB LAN
We now have to change the binding order for the network connections. This is done by clicking Advanced > Advanced Settings in the Network Connections window shown back in Figure 2.3. Under the Adapters and Bindings tab, make sure the Public LAN connection is listed first as shown in Figure 2.5 then click OK.
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 Access server to the NLB cluster in the next section. So let us open the property page of the NLB LAN adapter, then check Network Load Balancing as shown in Figure 2.6. With Network Load Balancing selected click the Properties button.
Figure 2.6: Enabling Network Load Balancing
Under the Cluster Parameters tab (Figure 2.7), enter the IP address, subnet mask and full Internet name for the NLB cluster. Next make sure Unicast is selected under Cluster operation mode.
Figure 2.7: Configuring the Cluster Parameters
Now, click the Host Parameters tab and enter the IP address and subnet mask configured for the network adapter (Figure 2.8). Let the other settings stay at default.
Figure 2.8: Configuring the Host Parameters
Click the Port Rules tab then select the default port rule and click Remove.
We now need to add a port rule for each of the ports the NLB cluster should accept client requests on. To do so, click the Add button, then enter the respective port under Port range (Figure 2.9). Also make sure Affinity is set to Single. Finally click OK to add the port rule.
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:
If you support other types of Internet clients such as POP3 and IMAP4, you would also need to add port 110 and 143 respectively.
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
Now add the new virtual cluster IP address under the TCP/IP property page of the network adapter as shown in Figure 2.12.
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 Network Load Balancing Manager by clicking Start > Run and typing NLBMGR.EXE (or click Administrative Tools > Network Load Balancing Manager). This will open the Network Load Balancing Manager shown in Figure 2.13.
Figure 2.13: Network Load Balancing Manager
To add the second server to the NLB cluster, click Cluster in the menu, then Add Host. In the appearing window, type the name of the second Client Access server then hit Connect (Figure 2.14). Select the respective cluster and click Finish.
Figure 2.14: Adding the Second Client Access Server to the NLB Cluster
Next, type the IP address and subnet mask of the network adapter that should be associated with the NLB cluster then click Finish (Figure 2.15).
Figure 2.15: Configuring the Host Parameter Settings for the Second Client Access Server
Now wait for a little while in order for the server to be added and configured accordingly (Figure 2.16).
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.
Testing the Load-Balanced Client Access Server Setup
Before we continue with the remaining configuration steps, now would be a good time to test whether we have an NLB cluster that works as expected. To do so, open a browser on one of the servers or a client if you prefer, then type the FQDN for the NLB Cluster, in my setup this is https://mail.ehlo.dk/owa. As can be seen in Figure 3.1 below, we’ll get a couple of security alerts, since we’re trying to access OWA 2007 via the NLB cluster name. This is because the FQDN isn’t included in the self-signed SSL certificate that is installed on each Client Access server during the Exchange 2007 setup. We’ll fix this problem later, for now let’s just click Yes.
Figure 3.1: Certificate Security Warning
The familiar OWA 2007 forms-based authentication logon page will now appear, and we can access OWA by logging on with a username and password as shown in Figure 3.2.
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:
The NLB LAN adapter should be disabled on the first Client Access server in the NLB cluster as this is the server that has the highest priority. Also note that if you’re connected to this Client Access server using a remote desktop connection, you’ll get disconnected.
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!
Although configuring the Client Access server role in a Windows NLB on servers with both the Client Access and Hub Transport server roles works perfectly, the scenario is unsupported by 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
Because the FQDN used to access the Client Access servers in our NLB cluster doesn’t match the FQDN specified in the common name field nor the subject alternative names field in the default self-signed SSL certificate that automatically is installed on each Client Access server during Exchange 2007 setup (Figure 3.5 and 3.6), we must create a new certificate.
Figure 3.5: Subject Alternative Names on CAS01 Certificate Property page
Figure 3.6: Subject Alternative Names on CAS01 via the Exchange Management Shell
For the purpose of this article series, we’ll generate a new certificate using an internal Microsoft certificate authority server, but in a corporate production environment, you would in most situations want to submit the certificate request to a 3rd party certificate authority.
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
After hitting Enter, you should see the old and new value as in Figure 3.8.
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 certificate (Figure 3.10).
Figure 3.10: Microsoft Certificates Welcome page
On the Request a Certificate page, click advanced certificate request (Figure 3.11).
Figure 3.11: Requesting a Certificate
On the Advanced Certificate Request page, click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file (Figure 3.12).
Figure 3.12: Selecting the second option on the Advanced Certificate Request page
Now paste the content of the certificate request file into the Base-64-encoded window as shown in Figure 3.13. Then select Web Server in the certificate template drop-down menu and click Submit.
Figure 3.13: Submitting the Certificate Request
The certificate has been issued and you can download a DER or Base 64 encoded version by clicking Download certificate or Download certificate chain. Let’s select Base 64 encoded followed by clicking Download certificate chain (Figure 3.14).
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:
Get-ExchangeCertificate -Thumbprint | FL
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 -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
To import the SAN certificate on the second Client Access server in the NLB cluster, we first need to export it from the first Client Access server. When doing so, we need to make sure we export the certificate with its private key. This is done by opening the Certificates snap-in. To open the Certicates snap-in, click Start > Run and type mmc.exe to first open an empty MMC window. Now click File > Add/Remove Snap-in > Add > Select Certificates > Click Add > 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
In the Certificate Export Wizard, click Next. On the Export Private Key page, select Yes, export the private key as shown in Figure 3.19 then click Next.
Figure 3.19: Exporting the private key
On the Export File Format page, select Personal Information Exchange – PKCS #12 (.PFX) and tick Include all certificates in the certificates path if possible as shown in Figure 3.20. Click Next.
Figure 3.20: Selecting the format to use
Enter a password and click Next (Figure 3.21).
Note:
Make sure you remember this password as you need it when importing it on the second Client Access server.
Figure 3.21: Enter a password in order to protect the private key
Now specify the path to where you want to save the .PFX file (Figure 3.22), then click Next.
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
When pressing Enter, you’ll be prompted for the password you specified earlier on as shown Figure 3.23. It doesn’t matter what username you specify as this isn’t used in this type of authentication.
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):
Enable-ExchangeCertificate –Thumbprint -Services “IIS, POP, IMAP”
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.
Figure 3.26: Accessing OWA 2007 without security warnings
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:
If the client doesn’t trust the root CA certificate, you’ll get one or two security warnings during this process.
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.
After a little while, you will be informed whether the URLs to the different Outlook features, that are dependent on the Autodiscover service, are valid and working correctly. As can be seen in Figure 3.29, Outlook AutoConfiguration, Out of Office (OOF), the Offline Address Book (OAB) and Unified Messaging are all dependent on the Autodiscover service.
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).
Figure 3.30: Autodiscover XML file used by the Outlook profile
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
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 | FL
Okay we have reached the end of part three, which was the last in this three part article series on how you deploy Client Access server in a NLB setup, install valid SAN certificates and finally test client connectivity. I hoped you enjoyed it!
