Optimizing SMTP traffic with Exchange Server 2010 and WAN Optimizer devices (Part 2)

If you would like to read the first part in this article series please go to Optimizing SMTP traffic with Exchange Server 2010 and WAN Optimizer devices (Part 1).

Introduction

In the last article we finished the technical settings required to disable TLS for SMTP Traffic however, if we need to do some troubleshooting in this new environment it may be hard to identify to which Receive Connector we are connecting from a remote location. The main reason is that if the connector that we have created does not work properly then, we will connect to the less restrictive which is Default <Server-Name> Receive Connector, right?

You may be thinking of enabling debug on just that guy and you are right, but I’m a lazy guy and in order to save some time and make sure that I’m connecting to the right Receive Connector we will be changing the Banner of that receive Connector. This way any remote connection to it will show a different banner and we will know right off the bat that we are in the right place. So, we can run the following cmdlet to configure the banner:  Set-ReceiveConnector <ServerName\Connector-Name> -Banner “220 Your-String-Here”, as shown in Figure 01.

Figure 01

Okay, we are good to go, let’s go to the remote site (POA) and try a simple telnet 10.60.200.10 25 and here we go (Figure 02). The banner is giving me the hint that our Receive Connector is working like a charm!

Figure 02

Sometimes you want to refresh things and you may want to restart the Microsoft Exchange Transport on both servers just to be sure. When you send a message between sites you will have the same Queue behaviour which is connected to the remote site and deliver the message, as shown in Figure 03. If you have any Retry status on items related to remote sites you may have missed something from our previous article, please go back there and double check.

Figure 03

As usual I was using my technological Swiss-knife (Network Monitor) and using the same filter, we don’t have any SSL or whatsoever in the capture, as shown in Figure 04.

Figure 04

The same thing applies to the log files of the Receive Connector, bear in mind that we created a new connector and you need to disable the connector on the Default <Server-name> and enabled on the new one otherwise you won’t be looking at the right spot.

Using Sites, Services and Exchange to force communication between sites…

The subject was already discussed here at MSExchange.org, but in this section we are going over only the portion of the content that is related to this article. The first concept is to understand that by default Exchange Server uses Active Directory for message routing. Each Active Directory site is the boundary for the Hub Transport Servers, and the IP Site Links are the paths between sites which by default are the same for message routing between sites.

As administrators, we have the resource of a Hub Site which basically relays messages when it exists in the least routing of a message from sender to destination. If there are two paths with the same cost and in one of them there is a Hub, then that one will be used. This becomes a nice feature when we have the scenario shown in Figure 05. If the Regional Office sites are configure as Hubs, then any message to the local offices will go through those sites (if the site costs are right) which is good for us because that traffic would be optimized. After all we don’t want the Main Site or Backup Site trying to connect straight to the Local offices because that would defeat the purpose of WAN optimization, right?

Figure 05

In order to enable a site as Hub Site in Exchange, we just need to run the following cmdlet Set-ADSite <site-name> -HubSiteEnabled $true, and in the same way the Get-ADSite will list all your current Active Directory sites and if they are Hub enabled.

If you have your Active Directory Sites and Services configured properly we should be more than fine just by enabling the Hub Sites when necessary. In order to build your Active Directory Sites and Services properly, the first step is to make sure that you have all sites listed and an IP Subnet associated to them, that is the main principle and that solves a lot of issues. In Figure 06, we can see a couple of sites and that each subnet has a site associated to it.

Figure 06

If you don’t have a network where all sites are able to communicate to each other or you don’t want the KCC to be computing all possible connection among several sites, you can disable the Bridge All Site links and then you will be in control how the replication will flow in your environment. After creating all sites, you can start building the Replication path using IP Inter-Site Transports. In Figure 07 we can see that the cost is going to be 10 and sites participating will be Main Site and Backup Site, while replication will take place every 30 minutes.

Figure 07

So, before you start creating connections like crazy, a good practice is to draw your sites and how they are placed in the network. Then start playing around with AD costs to guarantee that in a normal situation the message flow will respect your standards. We are going to use the same environment that we saw previously to design Active Directory. An easy way to understand costs in Active Directory is that the source site to get to the target site will use the least path as possible.

In the figure below (Figure 08) we are going to use black lines for primary connections and gray lines for backup connections. The main site will have a cost of 50 to connect to any of the Regional Offices. Just in case we are going to create a different set of Site Links between the Backup-site and the regional offices using the cost of 100, in regular operations any communication between Backup Site and a regional would have the cost of 100 (going through the main site). However, if that site is down then the backup route will be used. Also, the connections between Regional Offices and Local Offices is going to be done between tier 2 and tier 3 of our topology which means that all traffic coming from the main site is sent to the Regional Sites and from there they replicate to the Local Offices.

Figure 08

Let’s imagine that our MX are located in the main site while, the secondary in the Backup Site. Any new message will be sent to the regional and from there delivered to the local office (in case they have Exchange Server).

Bear in mind that from an Exchange perspective we need to run Set-ADSite <site-name> -HubSiteEnabled $true on those sites that will relay messages, in the previous design it would be Main office, Backup Office and all Regional Offices.

If you want to overwrite an existent Active Directory cost we can configure a field called ExchangeCost on the Active Directory Site Link to bypass Active Directory costs (Figure 09). When we run Get-ADSiteLink and from Exchange Management Shell we can notice that ExchangeCost is always empty. If you want to configure it, then run Set-ADSiteLink –Identity <Site-Link-Name> -ExchangeCost <Cost>

Figure 09

Conclusion

In this final article we went over the banner configuration for the Receive Connector, and have seen the expected results using Network Monitor and IIS logs. Also, we have seen an example of how to build Active Directory sites to narrow down the replication and then taking advantage of the replication created with WAN Optimizers.

If you would like to read the first part in this article series please go to Optimizing SMTP traffic with Exchange Server 2010 and WAN Optimizer devices (Part 1).