If you missed the first part in this article series please read Load Balancing Exchange 2007 SP1 Hub Transport Servers using Windows Network Load Balancing Technology (Part 1)
This is the second and last article in the two part article series where I explain how you provide fault tolerance as well as load balance Exchange 2007 SP1 Hub Transport servers using Windows Network Load Balancing technology. I know many of you are eager to get going from where we left off in part one, so I won’t bother you with a long introduction.
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 <server> receive connector in the work pane as shown in Figure 2.1 below.
Figure 2.1: Opening the property page for the default <server> receive connector
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 <server> receive connector
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 <server> Receive connector in a default Exchange 2007 Hub Transport server).
Let’s also try to telnet the Hub Transport servers using the default <server> receive connector by using the FQDN of the servers themselves (in this case ht01.ehlo.dk and ht02.ehlo.dk). This should result in a slightly different ESMTP banner as shown in Figure 2.10.
Figure 2.10: Telenetting to the default <server> receive connector
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.
If you missed the first part in this article series please read Load Balancing Exchange 2007 SP1 Hub Transport Servers using Windows Network Load Balancing Technology (Part 1)
