Introduction
Exchange Server 2007 (RTM and SP1) Hub Transport servers are resilient by default. This means that if you install more than one Hub Transport server in an Active Directory (AD) site and one fails, the other(s) will continue to accept connections. In addition, when you have more than one Hub Transport server deployed in an AD site, connections will be load balanced automatically between the Hub Transport servers. There is only one exception to this rule, and that is when a Hub Transport server role is installed on a server also holding the Mailbox server role. In this specific scenario the Hub Transport server local to the Mailbox server will always be preferred over other Hub Transport servers in the AD site.
The resilient behavior that by default is built into the Hub Transport server works just fine for many organizations, but there are situations where you as an Exchange messaging administrator or consultant, for example, have a line of business (LOB) application, Microsoft Office SharePoint Server 2007 (MOSS 2007) portal, or perhaps a System Center Operations Manager 2007 (SCOM 2007) service management solution which, in order to submit messages to an Exchange organization must use a SMTP relay as these applications cannot log on to a mailbox using MAPI and then send the messages as that mailbox.
So what are your options in these types of scenarios? Well, with the Exchange Server 2007 RTM version, it was not supported to load-balance Hub Transport servers using Windows Network Load Balancing (WNLB) technology. This meant that if you had an application which needed to use your Exchange 2007 messaging environment to relay messages, you either had to specify two SMTP servers in the application (often not possible), use DNS round robin (not as intelligent as NLB) or MX records (not viable if the application only allows you to specify a smart host).
As mentioned load balancing Hub Transport servers in Exchange 2007 RTM was not a supported scenario, but now that Exchange Server 2007 Service Pack 1 (SP1) has been released guess what? Yes you’re right, it’s supported to load balance Hub Transport servers using a hardware load balancer or standard WNLB technology.
Although it’s now supported to configure Hub Transport servers in an NLB, please note that it isn’t supported to load balance connections between Hub Transport servers on your internal corporate production network using this method. You should only use NLB to load balance inbound SMTP connections from applications (such as LOB application, MOSS, and SCOM 2007 etc.) and other non-Exchange sources as well as client connections (in order to send messages, POP & IMAP clients uses the default client receive connector on a Hub Transport server).
In this article series, I’ll show you step by step how you configure Hub Transport servers in a NLB using WNLB. We’ll also verify things works as expected as well as take a look at how fault tolerance and load balancing works for outbound message flow (messages leaving the Exchange organization).
Environment used in this article
If you want to deploy and test the solution explained in this article series in your own environment (you should of course always start out in your lab environment), you will need the following:
- 1 x Windows 2003 Server SP2 Domain Controller and Global Catalog (DC01)
- 1 x Windows 2003 Server SP2 with Exchange 2007 SP1 Mailbox and Client Access Server role installed (Mailbox01)
- 2 x Windows 2003 Server SP2 with Exchange 2007 SP1 Hub Transport Server role installed (HT01 & HT02)
Note:
Because the NLB cluster configured in this article series is configured in unicast mode, you need to install two network interface cards (NICs) in each Hub Transport server.
Creating the Alias (FQDN) for the NLB Cluster in DNS
With the environment up and running the very first thing you want to do is to create an 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 1.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 1.1: Creating a DNS Record for the Windows NLB Cluster name in the DNS Manager
Now click Add Host (Figure 1.2) then OK and Done. Close the DNS Manager.
Figure 1.2: Entering the DNS name and IP address
Configuring Network Settings for each NLB Cluster Node
Although not required (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 on each Exchange 2007 Hub Transport server, open Network Connections and give each LAN connection a meaningful name as shown in Figure 1.3.
Figure 1.3: Naming the Network Connections
Now open the Property page for the NLB adapter and then configure the TCP/IP settings as shown in Figure 1.4. As you can see you should only specify an IP address and a Subnet mask. When ready click OK.
Figure 1.4: Configuring the TCP/IP Settings for the NLB NIC
Enabling Network Load Balancing on the First Hub Transport Server
Okay, it’s time to enable NLB on the first Hub Transport 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 Hub Transport server to the NLB cluster in the next section. So let us open the property page of the NLB LAN adapter, and then check Network Load Balancing as shown in Figure 1.5. With Network Load Balancing selected click the Properties button.
Figure 1.5: Enabling Network Load Balancing
Under the Cluster Parameters tab (Figure 1.6) 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 1.6: Configuring the Cluster Parameters
Now, click the Host Parameters tab and enter the IP address and subnet mask configured for the network adapter (Figure 1.7). Let the other settings stay at their defaults.
Figure 1.7: 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 1.8). Also make sure Affinity is set to Single. Finally click OK to add the port rule.
Figure 1.8: 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 1.9 depending on what client access services you want to allow in your organization.
Figure 1.9: List of Configured Port Rules
Click OK and OK again to the Information message you receive (Figure 1.10).
Figure 1.10: 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 1.11.
Figure 1.11: Adding the NLB Cluster IP Address on the TCP/IP Settings Page
Finally click Add then OK. We have now setup a Windows NLB cluster with one member server.
Adding the Second Hub Transport Server to the NLB Cluster
What good is a NLB cluster with only one member server? Correct not very good. So let’s add the second Exchange 2007 Hub Transport 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 1.12.
Figure 1.12: 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 Hub Transport server then hit Connect (Figure 1.13). Select the respective cluster and click Finish.
Figure 1.13: Adding the Second Hub Transport 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 1.14).
Figure 1.14: Configuring the Host Parameter Settings for the Second Hub Transport Server
Now wait for a little while in order for the server to be added and configured accordingly (Figure 1.15).
Figure 1.15: Second Hub Transport Server added to the NLB Cluster
Close the Network Load Balancing Manager. We have now load-balanced the Hub Transport servers in our lab environment, but there are still a couple of configuration steps to do.
Creating an addition receive connector on the Hub Transport servers
As mentioned back in part 1 of this article series, it’s only supported to load balance inbound SMTP connections coming from applications (such as LOB application, MOSS 2007, SCOM 2007 etc.) and other non-Exchange sources using WNLB technology. In order to not affect intra-org communication (aka Hub Transport server to Hub Transport server communication), we must create a new receive connector that listen on port 25/SMTP using the virtual IP address we specified when we created the NLB cluster. To do so launch the Exchange Management Console and then click Server Configuration followed by Hub Transport. Now select the first Hub Transport server in the result pane and then open the property page for the default
Figure 2.1: Opening the property page for the default
Click the Network tab and configure the IP address to the internal non-cluster IP address (Figure 2.2).
Figure 2.2: Specifying a non-clustered IP address for the default
Now create a new receive connector (type Custom) and name it Inbound SMTP relay (WNLB), then click Next (Figure 2.3).
Figure 2.3: Naming the new Receive WNLB receive connector
On the Local Network Settings page (Figure 2.4), configure the receive connector, so it only listens on port 25 on the NLB cluster address, which in the example is 10.10.1.194. Although optional, it’s also a good idea to enter a FQDN for the connector. Click Next.
Figure 2.4: Configuring the receive connector to listen on the virtual NLB cluster IP address
Now enter the IP addresses that should be allowed to relay through the receive connector. Make sure not to specify a ranger here, but only the specific IP addresses configured on the servers running the applications that must submit messages to the Exchange 2007 organization via this receive connector (Figure 2.5). Then click Next.
Figure 2.5: IP address that should be allowed to submit messages to this receive connector
Finally click New and then Finish to create the new receive connector (Figure 2.6).
Figure 2.6: Completion page
Now open the property page for the new receive connector, and then click the Permission Groups tab. Under the Permission Groups tab, tick Anonymous users and nothing else as shown in Figure 2.7.
Figure 2.7: Allowing anonymous users to submit message to the receive connector
Next we must grant the permissions required in order for the specified remote IP addresses to be able to relay through this receive connector. To do so, open the Exchange Management Shell and type the following command:
Get-ReceiveConnector "Inbound SMTP relay (WNLB)" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"
Figure 2.8: Granting the necessary permissions to the new receive connector
Now perform the exact same steps on the second Hub Transport server.
Testing Hub Transport Server Connectivity via NLB Cluster FQDN
Now that the two Hub Transport Servers has been added as nodes in our WNLB cluster as well as new receive connectors have been created specifically for the WNLB virtual IP address, we should be able to telnet to port 25 and 587 using the NLB cluster FQDN, which for the purpose of this article is mail.ehlo.dk. To do so open a command prompt window on a remote server (the server that should be able to submit messages to the Exchange 2007 organization using the NLB FQDN) and type:
Telnet mail.ehlo.dk 25
You should now get the ESMTP banner from one of the Hub Transport servers as shown in Figure 2.9 below.
Figure 2.9: ESMTP Banner from HT01’s WNLB dedicated receive connector
Telnetting to port 587 should result in similar ESMTP banner (port 587 is the port used by the Client
Let’s also try to telnet the Hub Transport servers using the default
Figure 2.10: Telenetting to the default
So far so good, we have now verified we can submit messages using the new receive connector using the NLB cluster FQDN (mail.ehlo.dk).
Testing Hub Transport Server NLB-based Resiliency
Let’s now see whether the remote server (non-Exchange sources such as a LOB application, MOSS 2007, or SCOM 2007) that needs to submit messages to the Exchange 2007 organization in fact can do so, when one of the nodes in the NLB cluster is down. In order to test this works, let’s drainstop the first node, which in this article is HT01. We do this by opening the NLB Manager and right-clicking on the first node where we select Drainstop in the context menu as shown in Figure 2.11.
Figure 2.11: Drainstopping the first node in the NLB Cluster
When the node is fully drainstopped, the icon will turn red (Figure 2.12) and we can perform our testing.
Figure 2.12: HT01 is drainstopped
Let’s try to telnet to port 25 using the NLB cluster FQDN again. As you can see in Figure 2.13, we’re now connected to HT02, which is the second node in our NLB cluster.
Figure 2.13: Telnetting NLB Cluster FQDN result in an ESMTP connection to mail.ehlo.dk
Alright we have now verified, we have a fully working resilient Hub Transport server setup configured using WNLB technology both when speaking intra.org communication as well as communication from non-Exchange sources to the Hub Transport servers. Although it’s outside the scope of this article, you can of course also use a hardware based load balancing solution or if you have multiple ISA Servers configured in an ISA Server array, perform the load balancing on the ISA Servers in your organizations perimeter network.
Providing Fault Tolerance and Load Balancing for Outbound Messages
Now that we have covered how you can provide resiliency for messages submitted from a LOB application using WNLB, I thought it would be a good idea to move on and explain how you load balance as well as provide fault tolerance for outbound mail flow (that is messages leaving the Exchange organization). Actually this is very easily accomplished. You just have to make sure you add more than one Hub Transport server under the Source Server tab of the Send Connector which routes messages on to the Internet (or perhaps to a set of SMTP gateways in your perimeter network). However, bear in mind that load balancing doesn’t work for the particular Send connector unless the Hub Transport servers under the Source Server tab are all from the same Active Directory site.
So in order to add additional Hub Transport source servers to your Send Connector, you need to open the Exchange Management Console (EMC), and then expand the Organization Configuration work center node in the navigation tree in the left side of the EMC. Here you should select Hub Transport and then click the Send Connector tab. Now open the property page for the respective Send Connector, and then click the Source Server tab as shown in Figure 2.14 below. Next, add the required Hub Transport servers by clicking the Add button and apply the settings.
Figure 2.14: Multiple Source Servers on the Internet Send Connector
All outbound messages will now be load balanced between the source servers and if one is down for maintenance etc. the Hub Transport server that needs to deliver messages to recipients outside of the organization will select the next source server in a round robin fashion. There’s one thing you should be aware of though, and that is that if the Hub Transport server that are relaying messages to the Internet also is listed under the Source Server tab of the Send Connector, load balancing will not occur as the local servers proximity always takes precedence overactive directory site proximity.
If the Send Connector that routes messages out of your organization is configured to deliver the messages to a smart host, please be sure to add multiple smart hosts, so that you eliminate all single point of failures in your outbound message routing topology.
If you were using subscribed Edge Transport servers as the anti-spam and/or anti-virus filtering solution in your perimeter network, you would instead of Hub Transport servers add the subscribed Edge Transport servers under the Source Server tab as shown in Figure 2.15. This makes sure that all outbound messages are load balanced between the Edge Transport servers in the perimeter network.
Figure 2.15: Subscribed Edge Transport Server listed under the Source Server tab
Note that only one Edge Transport server is listed in Figure 21, this is simply because I only have one Edge Transport server subscribed to the Exchange organization in the lab environment used for the purpose of this articles series. When using subscribed Edge Transport servers in your Exchange organization, the Send connector settings will automatically be propagated to the Edge Transport servers listed under the Source Server tab.
Testing Fault Tolerance and Load Balancing for Outbound Messages
Okay, let’s verify that the fault tolerance and load balancing mechanisms works as expected. We’ll do so by sending a test message from the 3rd Exchange 2007 server in our lab environment. This server has the Mailbox, Client Access and Hub Transport server roles installed, and although this server is a Hub Transport server it’s not added as source server on the Send Connector, which means that it should deliver the outbound test message to either HT01 or HT02. Figure 2.16 shows the Internet Mail header of the test message in the external recipient’s Mail client.
Figure 2.16: HT01.ehlo.dk is the source server in the Internet Mail Header
Okay it’s now time to turn off the first Hub Transport server (HT01) and then send one more test message, so that we can see HT02 actually takes over. As you can see in Figure 2.17 it does, so our tests were successful.
Figure 2.17: HT02.ehlo.dk is the source server in the Internet Mail Header
That was it for this time. I hope you enjoyed the reading.
No comments:
Post a Comment