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.

Important:
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.

Note:
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.

	Copy Code
Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 15

This example disables delayed acknowledgement on the Receive connector.

	Copy Code
Set-ReceiveConnector "SMTP Application relay" -MaxAcknowledgementDelay 0

Important:
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.

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.

	Copy Code
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”.

	Copy Code
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.

	Copy Code
Set-ReceiveConnector "SMTP Application relay" - MaxInboundConnectionPercentagePerSource 30

For detailed syntax and parameter information for the above Receive connector specific parameters, see Set-ReceiveConnector.