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

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


Some medium and large companies that invest a lot of money in links and bandwidth optimization devices, see no gain in Exchange Server 2007 SMTP traffic because it was designed to use TLS (Transport Layer Security) at all times. This means that all SMTP traffic between sites is not optimized. In Exchange Server 2010 this is not an issue anymore, and now we can finally disable TLS between Hub Transport Servers and leave the WAN Optimizers to have fun with the SMTP traffic.

Before we go to the technical and fun side of this article, we need to understand where and how we can take advantage of the WAN Optimization devices. Besides the knowledge of the current infrastructure, we also need to play with Active Directory Site design to make sure that we force non-TLS communication between sites that have WAN Optimizers.

The first rule about WAN Optimizers is that they work in pairs which means that we want to disable TLS only in those sites where we can take advantage of WAN Optimization. A good example is a company that has one main location and a few additional sites as shown in Figure 01. Here, a couple of locations have a WAN Optimizer and some don’t so, in this scenario we should only disable TLS in the Main Site, Branch Office 01 and Branch Office 02. Since Branch Office 03 does not have a Wan Optimizer, that site shouldn’t be listed on the Receive Connectors that will be configured for that purpose.

Figure 01

Another example is when a large environment has Primary and Backup sites (Figure 02), and a second tier (which could be Regional level) with several small offices connected to it. In this scenario the WAN Optimizers are only located on the first two tiers hence here TLS can occur in the third level because they are not using Wan Optimizers, got the idea?

Figure 02

To start our article, we have two servers (POAEX05 and TOREX01) and the first three letters identify the city/site of the servers where POA is Porto Alegre and TOR is Toronto. Both servers are using the default settings when you install a new Exchange Server, as shown in Figure 03. For the sake of simplicity, let’s delete the Client <ServerName> receive connector, since we are not going to allow relay on port 537 on those servers.

Figure 03

Validating the mail flow with TLS enabled…

In order to show the changes that will occur when you change the TLS behaviour with Hub Transport Servers in Exchange Server 2010, we are going to send a message from POA (Porto Alegre) site to TOR (Toronto). In order to see what is really happening we are going to configure the Protocol Logging Level to Verbose on the Default <Server-Name> receive connector located in TOR site which is going to be our receiver, as shown in Figure 04.

Figure 04

Now, with logging enabled we are going to send a message from POA to TOR and the result can be seen in the Queue Viewer of a server located in POA (figure 05). We can see that an entry called Toronto and the Delivery Type of that is SMTP Relay to Remote Active Directory Site is Ready, which means that the message went through already.

Figure 05

I also used Network Monitor during the test above to show you what is going on at packet level. I used an SMTP filter (you can type SMTP in the Display Filter area and then click Apply to have similar results) and you can see that the SMTP communications starts and then it is changed to SSL (Figure 06), so far so good you haven’t changed anything, just to make a point.

Figure 06

We can also check the log files generated after our initial change in X:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive (where X: is the drive where you installed Exchange), and see that TLS is being used by a single glance at a couple of the lines listed below.

2011-11-15T14:04:38.111Z,TOREX01\Default TOREX01,08CE71A3485C8561,2,,,>,”220 TOREX01.apatricio.local Microsoft ESMTP MAIL Service ready at Tue, 15 Nov 2011 09:04:36 -0500″,

2011-11-15T14:04:38.126Z,TOREX01\Default TOREX01,08CE71A3485C8561,3,,,<,EHLO POAEX05.apatricio.local,

2011-11-15T14:04:38.126Z,TOREX01\Default TOREX01,08CE71A3485C8561,4,,,>,250-TOREX01.apatricio.local Hello [],

2011-11-15T14:04:38.126Z,TOREX01\Default TOREX01,08CE71A3485C8561,21,,,*,,Sending certificate

2011-11-15T14:04:38.126Z,TOREX01\Default TOREX01,08CE71A3485C8561,22,,,*,CN=TOREX01,Certificate subject

2011-11-15T14:04:38.126Z,TOREX01\Default TOREX01,08CE71A3485C8561,23,,,*,CN=TOREX01,Certificate issuer name

2011-11-15T14:04:38.126Z,TOREX01\Default TOREX01,08CE71A3485C8561,24,,,*,30C673A7E404649349A88A627DB766D3,Certificate serial number

2011-11-15T14:04:38.126Z,TOREX01\Default TOREX01,08CE71A3485C8561,25,,,*,C87311669DAA41AE8078043A093859F4F67046D5,Certificate thumbprint

2011-11-15T14:04:38.142Z,TOREX01\Default TOREX01,08CE71A3485C8561,26,,,*,TOREX01;TOREX01.apatricio.local,Certificate alternate names

Configuring SMTP Optimization..,

Receive Connectors must be unique on the same server and in one of the following components: IP Address (Listening), Port Number or Remote IP Address. We are going to create specific Connectors, one on each site, to make sure that they are used only by the servers that will be part of the servers configured to disable TLS. This means that we will be taking advantaging of the WAN Optimization devices.

The first step is to configure the Hub Transport Servers that will be part of the communication without TLS. Then enable them to use legacy Exchange Server Authentication, and this can be done using the cmdlet Set-TransportServer <Server-Name> -UseDowngradeExchangeServerAuth $True as shown in Figure 07.

Figure 07

Now it’s time to create the Receive Connector that will make sure that all connections coming from the site with another WAN Optimizer will be connecting to, and this can be done using the following steps:

  1. Log on to the Exchange Management Console
  2. Expand Exchange on-premises
  3. Expand Server Configuration
  4. Click on Hub Transport
  5. Click on New Receive Connector located in the Toolbox Actions
  6. On the Introduction page, let’s name our new connector as TOR-WOC and in the connector type select Internal (this is important because it will make sure that all Authentication and Permissions are set properly during the installation process) as shown in Figure 08, then click Next.

Figure 08

  1. On the Remote Network Settings page, we need to add the remote IPs that will be connecting on this server. We should add only the IPs of the Hub Transport Servers that are behind a WAN Optimizer in a different site (since this is Toronto Site the server listed is the only Hub Transport located in the POA site), after all, this connector is just for optimization purposes. Then click Next (Figure 09).

If there is more than one Hub Transport on the other side, they should be all listed in this page. You can always go back and add new IPs.

Figure 09

  1. On the New Connector page, a summary of all decisions that we have done so far will be listed, hit New button to create the new Receive Connector.
  2. On the Completion page, the results of the operation will be displayed, and the cmdlet with its parameters used to create the new receive connector will be displayed, then click Finish.

Are we done? Not yet, the next step is to Supress Anonymous TLS in the Receive Connector that we have just created, using the following cmdlet: Set-ReceiveConnector <Server\Connector-Name> -SupressXAnonymousTls $True as shown in Figure 10

Figure 10


In this initial article we saw how we can take advantage of a WAN Optimizer using Exchange Server 2010 and how we configure the servers to disable TLS for internal communication. In the next article we will see how to identify the WOC connector with a simple configuration.

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

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