Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 8)

If you would like to read the other parts of this article series please go to:


In part 7 of this multi-part article, we added the 4 Exchange 2010 multi-role servers to our newly created DAG. After the DAG members had been added to the DAG, we collapsed the DAG networks, enabled database availability coordination (DAC) and redistributed the active database copies across the two Exchange 2010 multi-role servers located in the primary datacenter.

In this part 8, we’ll finish the configuration of our four Exchange 2010 multi-role servers. More specifically we will configure the Hub Transport server role in a redundant fashion.

Hub Transport Server SMTP Failover and Load Balancing

With Exchange 2010 all intra-organization message traffic is automatically load balanced between Hub Transport, Edge Transport and Mailbox servers in an Active Directory site. This is accomplished using enhanced DNS.

As mentioned this is for intra-organization message traffic between these Exchange server roles. In order to load balance inbound message traffic from non-Exchange sources such as external mail servers, third party anti-spam or anti-virus solutions, any internal non-Exchange mail servers, internal LOB application, network devices such as network printers and POP or IMAP, you would need to use a load balancer solution or DNS round robin.

In this multi-part article, we will use hardware based load balancing as we already have hardware based load balancing solution in place in each datacenter. In addition, since we use multi-role servers that are part of a DAG, we cannot use Windows NLB since it isn’t supported to combine Windows Failover Clustering and Windows NLB on the same server. Furthermore it’s important to take note of the following limitations, when it comes to using load balancing using Windows NLB:

  • As already mentioned, Windows NLB can’t be used on Exchange servers where the Hub transport and Mailbox server roles coexist and the server also participates in a DAG. This is because the WNLB feature is incompatible with Windows Failover Clustering. If you are using an Exchange 2010 DAG and you want to use WNLB, you need to have the Hub Transport server role and the Mailbox server role running on separate machines. In addition, Windows NLB would impact message routing when the DAG member and Hub Transport role coexist on the same server hardware.
  • It’s not recommended to put more than eight Hub Transport servers in an array that’s load balanced using WNLB. If you need to load balance more than 8 Hub Transport servers, you should deploy a hardware based solution.
  • Windows NLB doesn’t detect service outages. It only detects server outages by IP address. This means if the Exchange Transport service fails, but the server is still functioning, Windows NLB won’t detect the failure and will still route incoming e-mail messages to that Hub Transport server. Manual intervention is required to remove the Hub Transport server experiencing the outage from the load balancing pool.
  • Windows NLB configuration can result in port flooding, which can overwhelm networks. This is because Windows NLB has been designed in such a way that it simultaneously delivers all incoming client packets to all switch ports. Although this behavior enables Windows NLB to deliver very high throughput, it may cause high switch occupancy.

It’s important to stress out that it isn’t supported to load balance message traffic between Exchange servers using a load balancer. This means that you must exclude message traffic between any Exchange servers in the organization from any load balancing solution you use in your environment. Some would probably feel tempted to just associate the VIP of the SMTP virtual service on the load balancer solution with the default receive connector on the Hub Transport servers. But that’s not the way to do it as you will see in this article.

Exchange 2010 DAG Members with Hub Transport Role installed

As you know we use four Exchange 2010 multi-roles servers as the basis for the site resilient solution covered in this multi-part article. As you also know all four servers is part of a DAG. With Exchange 2010 introduces shadow redundancy which is a feature that protects messages in transit inside the Exchange organization. Also, when using a DAG we still use the transport dumpster functionality to resubmit any messages that were lost during a database failover occurred where one or more log files were lost.

What if the Hub Transport role is installed on a server that is also part of a DAG? Won’t this introduce a potential single point of failure (SPoF) since the Microsoft Exchange Mail Submission service always prefers the local Hub transport server over any other Hub Transport server in the AD site? Well at first this may seem like a SPoF since Mailbox servers normally prefers the local Hub Transport server over any other Hub Transport servers in the design.

Fortunately this isn’t the case when the server is part of a DAG. To get around this potential SPoF, the Exchange Product group made a design change. More specifically if the Exchange Mail Submission service on a Mailbox server detects that it’s running on a mailbox server part of a DAG, it will never prefer the local Hub Transport role. Instead, it will load balance across other Hub Transport servers in the same Active Directory site. If it doesn’t find any, it will fall back to the local Hub Transport server.

So please don’t worry when it comes to Exchange 2010 multi-role servers. Bear in mind though that if they are virtual you can potentially introduce a SPoF if two or more multi-role servers are running on the same virtual host. However this topic is outside the scope of this article.

Creating the SMTP Namespace in DNS

The first step on our journey to load balance inbound message traffic is to create the SMTP namespace we want to use in DNS. If you’re using Active directory integrated DNS, you must open the DNS Manager on a domain controller and then enabled “Advanced” under “View” in the menu. Now expand “Forward Lookup Zones” and right-click on the zone in which you want to create the SMTP namespace. In the context menu select “New Host (A)”.

Enter the namespace you want to use. In this article we’ll use “smtp”. Now enter the VIP you plan to use for the SMTP virtual service on the load balancer solution in the primary datacenter. In this article I use the same VIP as I used for the CAS related virtual services. Lastly, make sure the “Time to live (TTL)” value is set to 5 minutes. This is so the DNS cache expires in a reasonable time if/when we need to point the record at the VIP associated with the SMTP virtual service on the load balancer solution in the failover datacenter.

Click “Add Host” and exit the DNS Manager.

Figure 1: Adding the SMTP namespace in DNS

Creating the Virtual SMTP Service on the Load Balancer Solution

Next step is to create the virtual SMTP service on the load balancer solution in each datacenter. I won’t go into the specific details on how to do this since this varies depending on which load balancer solution you are deploying in your infrastructure. In this test environment, the virtual service can be seen in Figure 2 (primary datacenter) and Figure 3 (failover datacenter).

Notice that the virtual SMTP service is “down”. Also notice that the IP addresses for the target servers (real servers) are different from those the other virtual services point to. The service is considered down because these IP addresses aren’t yet added to the Exchange 2010 servers which means the load balancers of course doesn’t receive any answer when doing port 25 health checks.

Figure 2: Creating SMTP Virtual Service on Load Balancing in Primary Datacenter

Figure 3: Creating SMTP Virtual Service on Load Balancing in Failover Datacenter

Adding an additional IP Address to each Exchange 2010 Server

Okay now is the time to add an additional IP address to each of the four Exchange 2010 servers. To do so we’ll open up “Network Connections” on each server. Here will open the property page for the PROD network interface followed by opening properties for “Internet Protocol Version 4 (TPC/IPv4)”.

Figure 4: Properties of the PROD Network Interface

Now let’s click “Advanced” and then “add”.

Figure 5: Clicking “Advanced” on the TPC/IPv4 Property page

Enter the IP address you used as the target IP address on the load balancer and click “OK” twice.

Figure 6: Adding an additional IP address to the PROD Network Interface

Modifying the Default Receive Connector

Now that we have assigned an additional IP address to the four Exchange 2010 multi-role servers, we need to modify the configuration of the default receive connector. More specifically, we must change the connector so that it only listens on a specific IP address instead of all IP addresses.

To get to the default receive connector, open the Exchange Management console (EMC) and then expand “Server Configuration”. Under server Configuration select “Hub Transport”. Now click on the first server listed in the result pane. Under “Receive Connectors” in the work pane take properties for the default receive connector (in this case “Default EX01”).

Figure 7: Opening the Property Page of the Default Receive Connector

Click the “Network” tab then open the edit page for “All Available IPv4)”.

Figure 8: Property Page of the Default Receive Connector

On the “Edit Receive connector Binding” page, select “Specify and IP address:” and then enter the primary IP address assigned to the PROD network interface (not the IP address we added in the previous section). Click “OK” twice to exit the property page of the default receive connector.

Figure 9: Changing Receive Connector Bindings for the Default Receive Connector

Make sure to repeat the above steps on all four Exchange 2010 multi-role servers. Just make sure that you use a unique IP address (from the subnet the server belongs) for on each server.

Create a New Receive Connector SMTP Load Balancing

Now we can create a new receive connector on each Exchange 2010 multi-role server. This receive connector will be used specifically for load balancing message traffic that comes from non-Exchange sources.

To create a new receive connector, right-click on the first Exchange 2010 server and select “New Receive Connector” in the context menu (Figure 10).

Figure 10: Selecting “New Receive Connector” in the context menu

On the Introduction page name the connector something that makes the purpose of it easy to identify and then click “Next”. 

Figure 11: Creating an new Receive Connector for Load Balancing Mail Traffic from non-Exchange sources

On the “Local Network Settings” page, click “Edit” and then specify the new IP address that you added to the server back in the “Adding an additional IP Address to each Exchange 2010 Server” section. If you wish to have all servers have a SMTP banner such as make sure to enter it here as well. Click “Next”.

Figure 12: Assigning the new IP address to the Receive Connector

On the “Remote Network settings” page, leave the defaults (unless you want to limit what can submit messages to this connector) and then click “Next”.

Figure 13: Remote Network Settings

On the “Configuration Summary” page, click “New” to create the receive connector.

Figure 14: Configuration Summary for the new Receive Connector

Now open the property page for the new receive connector and select the “Permissions Groups” tab. If you want non-authenticated sources to be able to use the connector, the “Anonymous users” option should be checked.

Figure 15: Enabling “Anonymous users” on the new Receive Connector

Click “OK” to exit the property page.

Make sure to repeat the steps in this section on all four Exchange 2010 multi-role servers.

Creating a Send Connector

If you haven’t already done so, you should also create a send connector in the Exchange 2010 organization. To do so open the EMC and then expand “Organization Configuration”. Click Hub Transport and then the “Send Connector” tab. Launch the “New Send Connector” wizard. On the “Introduction” page name it something like “To Internet (Primary Datacenter)” and make sure “Custom” is selected in the drop-down menu. Then click “Next”.

Figure 16: Creating the Send Connector

On the “Address space” page, add a SMTP address space with an address of “*” and then click “Next”.

Figure 17: Address Space page

On the “Network settings” page leave the defaults as they are unless you need to route outbound messages through a smart host. Click “Next”.

Figure 18: Network Settings page

On the “Source Server” page, add the two Exchange 2010 multi-role servers located in the primary datacenter as source servers and click “Next”.

Figure 19: Source Server page

On the “Configuration Summary” page, click New to create the send connector.

Figure 20: Configuration Summary page

Repeat the above steps in order to create an additional send connector. Just make sure you name it “To Internet (Failover Datacenter”) and add the two servers in the failover datacenter as source servers.

Figure 21: Send Connectors

Okay our Exchange 2010 multi-site environment has now been fully configured. In the next part of this multi-part article, we’ll talk about switchovers and failovers as well as begin playing with database and site failovers to see how this affects end users.

If you would like to read the other parts of this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top