Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2012-01-16
In Microsoft Exchange Server 2010, the Receive connector and load-balancing concepts remain the same as in Exchange Server 2007. Here’s a quick review of those concepts. In Exchange 2007, Receive connectors are used to accept incoming messages. By default, when an Exchange Server 2007 Hub Transport server receives an e-mail message via SMTP over TCP port 25, it's processed by the Receive connector named “Default Receive connector”.
In addition, Exchange 2007 automatically load-balances all intra-organization message traffic between Edge Transport, Hub Transport, and Mailbox servers using enhanced DNS. However, this functionality doesn't cover the load-balancing of messages received from non-Exchange sources, such as external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization, line-of-business (LOB) applications, and POP-based or IMAP-based e-mail clients.
For more information about how you configure load balancing for messages received from non-Exchange sources, see Understanding SMTP Failover and Load Balancing in Transport.
If you place a load-balancing solution in front of your Hub Transport servers, you need to create a separate Receive connector for that purpose and make sure that only traffic processed by that specific connector is subject to load balancing. This is achieved by adding an additional IP address to the Hub Transport server and associating this IP address with the new Receive connector.
Changes in Behavior with Exchange 2010
Exchange 2010 introduces the shadow redundancy feature which provides redundancy for messages for the entire time they’re in transit. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery.
Because shadow redundancy is an Exchange 2010 feature, shadow redundancy is only supported by Exchange 2010 servers. If an Exchange 2010 transport server receives messages from a previous version of Exchange Server or a non-Exchange source, the source server can’t send the expected XSHADOW command. Therefore, shadow redundancy isn’t used. Non-Exchange sources include external mail servers, third-party anti-spam or antivirus solutions, any internal mail servers outside your Exchange organization or line-of-business (LOB) applications the source server.
However, when an Exchange 2010 transport server receives a message from a non-Exchange 2010 source, Exchange attempts to achieve shadow redundancy by delaying the acknowledgement to the sending server until it verifies that the message has been successfully delivered to all next hops internally. This way, if the Exchange 2010 server fails, the sending server assumes that the message was never delivered to Exchange and attempts delivery again.
The delayed acknowledgement time-out is controlled by the MaxAcknowledgementDelay attribute of each Receive connector. The default value is 30 seconds.
For more information about shadow redundancy, see Understanding Shadow Redundancy.
Customers who have upgraded from Exchange 2007 to Exchange 2010 and use dedicated Receive connectors for the purpose of relaying messages from sources such as line-of-business (LOB) applications may see a significant decrease in SMTP throughput. This decrease in throughput is because of the default delayed acknowledgement time-out of 30 seconds configured for a Receive connector. To increase the SMTP throughput for the relay Receive connector, we recommend you either lower the time-out value for the delayed acknowledgement attribute or disable it completely. Whether you should lower or disable the time-out value depends on the amount of messages that go through the relay Receive connector. A good approach is to first lower the value and then verify whether SMTP throughput still suffers and, if it does, then disable the feature completely.
|Although disabling delayed acknowledgements for a Receive connector increases SMTP throughput, it also means that you no longer benefit from the features provided by shadow redundancy. For this reason, we recommend the use of storage hardware redundancy for transport servers for which delayed acknowledgements are disabled.|
Use the Shell to configure the maximum acknowledgement delay on a Receive connector
You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Receive connectors" entry in the Transport Permissions topic.
|You can't use the Exchange Management Console to configure the maximum acknowledgement delay on a Receive connector.|
This example lowers the time-out value for a Receive connector named “SMTP Application relay” from 30 to 15 seconds.
Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 15
This example disables delayed acknowledgement on the Receive connector.
Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 0
|It isn’t possible to disable shadow redundancy for a Receive connector. Instead, you must do this on the Exchange organization level. For detailed syntax and parameter information, see Set-TransportConfig.|
Message Throttling Policy Considerations
When relaying application server SMTP traffic through an Exchange 2010 transport server, there are Receive connector specific message throttling policy options that may need to be adjusted, so the overall SMTP throughput doesn’t suffer. For example, the MessageRateLimit parameter specifies the maximum number of messages that a Receive connector accepts from a single IP address per minute. On Hub Transport servers, this parameter is set to a value of Unlimited, which means SMTP throughput won’t be affected. But, for an Edge Transport server, it’s set to accept 600 messages per minute. Depending on the relay application server SMTP traffic in your specific environment, you may need to raise this limit.
This example raises the message rate limit for a Receive connector named “SMTP Application relay” from 600 to 2000.
Set-ReceiveConnector "SMTP Application relay" -MessageRateLimit 2000
Another Receive connector specific option that can have an impact on overall SMTP throughput from a relay application server is expressed in the value of the MessageRateSource parameter. With this parameter, you specify how the message submission rate is calculated. It can be set to None, IPAddress, User, or All. By default, the parameter is set to IPAddress, which means the message submission rate is calculated for sending hosts. If this parameter has a negative impact on SMTP throughput from your relay application servers, you should consider setting the value to None.
This example disables the MessageRateSource parameter for a Receive connector named “SMTP Application relay”.
Set-ReceiveConnector "SMTP Application relay" -MessageRateSource None
If you’re planning to use a dedicated transport server for relay application server SMTP traffic, you should also consider increasing the maximum number of connections that a Receive connector will serve at the same time from a single IP address. This is done using the MaxInboundConnectionPercentagePerSource parameter. The value for this parameter is expressed as the percentage of available remaining connections on a Receive connector. By default, the value is set to 2 percent.
This example changes the value of MaxInboundConnectionPercentagePerSource for a Receive connector named “SMTP Application relay” from 2 to 30 percent.
Set-ReceiveConnector "SMTP Application relay" - MaxInboundConnectionPercentagePerSource 30
For detailed syntax and parameter information for the above Receive connector specific parameters, see Set-ReceiveConnector.