One of the more important changes for the Mailbox Replication service (MRS) in Exchange 2013 that I discovered when researching content for “Microsoft Exchange 2013 Inside Out: Mailbox and High Availability” is how the function of the MRS configuration file has changed. As you might recall from the steps taken to tweak MRS processing in Exchange 2010, the MRS configuration file dictates parameters such as how many concurrent mailbox moves can be performed to a single target database or single target server. It also dictates how many move reports are stored for a mailbox.

You can find the MRS configuration file (MSExchangeMailboxReplication.exe.config) in the \Exchange\V15\Bin directory on multi-role or mailbox servers (for Exchange 2010, the configuration file is in the \V14\bin directory on multirole or CAS servers). The file remains text-based so it can be opened with Notepad. The information that controlled MRS behavior in Exchange 2010 is in the section shown below:

Mailbox Replication Service configurationSetting Name - Default, MinValue, MaxValue

MaxRetries - 60, 0, 1000
MaxCleanupRetries - 480, 0, 600
RetryDelay - 00:00:30, 00:00:10, 00:30:00
MaxMoveHistoryLength - 5, 0, 100
MaxActiveMovesPerSourceMDB - 20, 0, 100
MaxActiveMovesPerTargetMDB - 20, 0, 100
MaxActiveMovesPerSourceServer - 100, 0, 1000
MaxActiveMovesPerTargetServer - 100, 0, 1000


Many of the values for settings like MaxMoveHistoryLength (the number of move reports stored for a mailbox) are increased in Exchange 2013. Most interestingly, the values for MaxActiveMovesPerTargetMDB (maximum number of concurrent moves to a single target database) increases from 2 to 20 while MaxActiveMovesPerTargetServer (maximum concurrent moves to an individual target server) increases from 20 to 100.

You might conclude that the increase is evidence of either radically improved efficiency on the part of MRS in terms of its ability to process mailbox moves or that the newly rewritten managed Store in Exchange 2013 is so much better at dealing with I/O. Some improvements have been made in I/O but the real reason why the new limits exist is that they now act as a backstop for MRS processing.

Instead of being constrained by hard limits, the Exchange 2013 version of MRS is flexible and uses a technique called dynamic throttling to note what’s happening on a server by reference to Exchange’s workload management system. When MRS starts to process mailbox moves, it observes the amount of system resources that it uses and the overall level of system health. If mailbox moves flow well and system resources are not limited, MRS will increase the number of mailbox moves that it processes concurrently. On the other hand, if system resources begin to become scarce, MRS throttles back and processes less work until availability of resources improves.  Although it is unlikely that MRS will ever hit the maximum values defined in its configuration file when processing mailbox moves on production servers, it’s possible that it might on test servers or when systems are running in periods of ultra-low demand.

From Exchange 2013 CU3 onward, you can force MRS to revert to using the limits set in its configuration file by adding a line to the MRS configuration file to disable dynamic throttling. The line is:

DisableDynamicThrottling = “true”

I wouldn’t be in a rush to disable dynamic throttling as, in effect, you then allow MRS to move mailboxes with little real regard for the other workload running on a server. Some more mailboxes might be moved in a shorter period. However, those moves might degrade the responsiveness of the server to client connections. Workload management is designed to arbitrate between competing workloads, favoring critical demands such as those needed to serve users and giving less to background system processes, like mailbox moves. Moving mailboxes is important, but delivering good response to users is even more important.

Workload management exerts a very big influence over Exchange components. This is a good development because it means that the work done by components like MRS can flex in line with available resources instead of being constrained by rigid limits that are acceptable in periods of peak demand but take no account of the valleys that also occur in resource demand.

Follow Tony @12Knocksinna