By default, the Exchange 2010 Mailbox Replication Service (MRS) keeps the last two logs for moves performed on a mailbox.  Each log occupies approximately 300KB and, if desired, you can increase the number of logs that MRS keeps by editing its configuration file (MSExchangeMailboxReplication.exe.config), which is kept in the Exchange binaries folder on CAS servers. Like many of the Exchange configuration files, this is an XML document that you can edit with a text editor (NotePad is just fine).  The setting you want to change is MaxMoveHistoryLength, which can be set to any value between 0 (zero) and 100.
Editing the MRS configuration file to amend the number of mailbox logs that can be kept
Remember that Exchange 2010 CAS servers do not share MRS configuration details, so if you amend the configuration file, you have to make the same changes on all CAS servers if you want to have the same behavior on all servers.
The mailbox move logs are stored in a hidden folder in the user’s mailbox and can be retrieved using the Get-MailboxStatistics cmdlet to gain an insight into the work done by MRS to move a mailbox (and perhaps its personal archive) between servers. Two different reports can be extracted:
  1. The Move History, a summary report that describes the essential parameters for the mailbox move.
  2. The Move Report, a detailed report that contains a much more detailed view of the mailbox move.
The move history can be generated with this command. The important point is to specify the –IncludeMoveHistory parameter when we run Get-MailboxStatistics. As you can see, we pipe the output into a variable.
$MoveHistory = (Get-MailboxStatistics –Identity ‘Redmond, Tony’                            –IncludeMoveHistory).MoveHistory
The variable contains all of the move reports that are available for the mailbox in an array. The most recent report is available in the first element in the array, so we can extract it as follows and pipe the output through the Out-File cmdlet to Notepad.
$MoveHistory[0] | Out-file –FilePath ‘c:\Temp\MRS-History.Log’ | Notepad ‘c:\Temp\MRS-History.Log’
So good, so far. The information available in a move report is shown below.


Status                           : Completed
Flags                            : IntraOrg, Pull, MoveOnlyPrimaryMailbox
RequestStyle                     : IntraOrg
Direction                        : Pull
IsOffline                        : False
SourceDatabase                   : DB3
SourceVersion                    : Version 14.1 (Build 218.0)
SourceArchiveDatabase            :
SourceArchiveVersion             : Version 0.0 (Build 0.0)
TargetDatabase                   : DB1
TargetVersion                    : Version 14.1 (Build 218.0)
TargetArchiveDatabase            :
TargetArchiveVersion             : Version 0.0 (Build 0.0)
BadItemLimit                     : 0
BadItemsEncountered              : 0
QueuedTimestamp                  : 9/9/2010 4:13:59 PM
StartTimestamp                   : 9/9/2010 4:14:24 PM
InitialSeedingCompletedTimestamp : 9/9/2010 4:29:46 PM
FinalSyncTimestamp               : 9/9/2010 4:29:46 PM
CompletionTimestamp              : 9/9/2010 4:31:51 PM
OverallDuration                  : 00:17:45
TotalFinalizationDuration        : 00:02:04
TotalSuspendedDuration           :
TotalFailedDuration              :
TotalQueuedDuration              : 00:00:02
TotalInProgressDuration          : 00:17:42
TotalStalledDueToHADuration      : 00:00:30
TotalTransientFailureDuration    :
MRSServerName                    :
TotalMailboxSize                 : 483.4 MB (506,878,889 bytes)
TotalMailboxItemCount            : 9194
TotalArchiveSize                 :
TotalArchiveItemCount            :


This report tells us that:
  • The move completed successfully
  • The move only involved the primary mailbox (in Exchange 2010, you can move the primary mailbox or its archive separately, or the two together)
  • The move was within an organization (IntraOrg) and it was between Exchange 2010 servers (Pull – when a move occurs between Exchange 2010 and legacy servers, the Store on the Exchange 2010 server has to push the content to the legacy server).
  • The source database is DB3, the target database is DB1.
  • The source and target servers both run Exchange 2010 SP1 (MRS identifies itself as build 218.0)
  • No corrupt (bad) items were encountered. This is good, because the tolerance limit for bad items was set to zero, so any corrupt item would have forced MRS to halt the move.
  • Only 25 seconds elapsed between the move request being queued and the time when the MRS running on started to process the move.
  • The initial seeding of the new mailbox on the target server took about 15 minutes for 9194 items occupying approximately 483MB. Your mileage will vary when you move data depending on server and network load.
  • After the initial seeding, the final incremental synchronization and clean-up took another two minutes. It’s at this time that Exchange switches the Active Directory pointers to relocate the user’s mailbox on the target server.
  • A small stall of 30 seconds took place due to high availability (HA) requirements. This only occurs when the target server is in a DAG and was probably due to a replication queue building on that server. The stall allows the server to clear the queue before it proceeds to finalize the mailbox move.
Overall, the history paints a picture of a mailbox move that proceeded smoothly and has completed without meeting any great problems. If we want to confirm this impression with a higher level of detail, we can replace the –IncludeMoveHistory parameter with –IncludeMoveReport. You can output the result to a text file using the same commands as shown above.
$MoveReport = (Get-MailboxStatistics –Identity ‘Redmond, Tony’                              –IncludeMoveReport).MoveHistory
The detailed move report begins with the same summary information that you see in the move summary. It then starts to list all of the actions taken to set up and then move the mailbox. An edited version follows:
Report                           : 9/9/2010 4:13:59 PM [ExServer1] '' created move request.
9/9/2010 4:14:01 PM [ExServer2] The Microsoft Exchange Mailbox Replication service '' ( caps:07) is examining the request.
9/9/2010 4:14:01 PM [ExServer2] Connected to target mailbox 'Primary (2a0e48f1-ca39-
4efa-9ae6-23bb2fb917c8)', database 'DB1', Mailbox server '' Ver
sion 14.1 (Build 218.0).
9/9/2010 4:14:01 PM [ExServer2] Connected to source mailbox 'Primary (2a0e48f1-ca39-
4efa-9ae6-23bb2fb917c8)', database 'DB3', Mailbox server '' Ver
sion 14.1 (Build 218.0).
9/9/2010 4:14:02 PM [ExServer2] Request processing started.
9/9/2010 4:14:02 PM [ExServer2] Mailbox signature will not be preserved for mailbox
'Primary (2a0e48f1-ca39-4efa-9ae6-23bb2fb917c8)'. Outlook clients will need to resta
rt to access the moved mailbox.
9/9/2010 4:14:24 PM [ExServer2] Source Mailbox information before the move:
Regular Items: 883, 68.72 MB (72,062,206 bytes)
Regular Deleted Items: 8295, 414.7 MB (434,816,683 bytes)
FAI Items: 16, 0 B (0 bytes)
FAI Deleted Items: 0, 0 B (0 bytes)
9/9/2010 4:14:25 PM [ExServer2] Initializing folder hierarchy in mailbox 'Primary (2
a0e48f1-ca39-4efa-9ae6-23bb2fb917c8)': 91 folders total.
9/9/2010 4:14:38 PM [ExServer2] Folder hierarchy initialized for mailbox 'Primary (2
a0e48f1-ca39-4efa-9ae6-23bb2fb917c8)': 91 folders total.
9/9/2010 4:14:38 PM [ExServer2] Stage: CreatingInitialSyncCheckpoint. Percent comple
te: 15.
9/9/2010 4:14:41 PM [ExServer2] Stage: LoadingMessages. Percent complete: 20.
9/9/2010 4:14:48 PM [ExServer2] Stage: CopyingMessages. Percent complete: 25.
9/9/2010 4:14:48 PM [ExServer2] Copy progress: 0/9195 messages, 0 B (0 bytes)/483.4
MB (506,878,755 bytes).
We can see these actions:
  • The move request is initiated
  • The MRS running on server picks up the request and begins to process it.
  • MRS connects to the source and target mailboxes on the respective servers. Note the build number that’s reported. In this case, we can see that it’s 218.0, which is the version reported by the MRS on an Exchange 2010 SP1 server. Other versions are reported with different information. For example, an Exchange 2003 server might show up like this:
    9/23/2010 9:15:17 PM [ExServer1] Connected to source mailbox 'Primary (4502f638-d741-4a39-9239-cf17454a8738)', database 'Ex2003\First Storage Group\Database1', Mailbox server '' Version 6.0 (Build 7654.0).
  • A warning is flagged that the mailbox signature cannot be preserved during the move, which means that Outlook clients have to reconnect after the new mailbox is set up. Microsoft hoped to introduce code to preserve mailbox signatures during mailbox moves in Exchange 2010 SP1 but this didn’t happen. I expect this code to appear in the future to eventually eliminate the need for Outlook clients to restart after mailbox moves. Non-MAPI clients will continue to have to reconfigure their settings to connect to the moved mailbox.
  • The contents of the source mailbox are enumerated. Regular items (items in user-visible folders), the dumpster (preserved on moves involving Exchange 2010 servers), and FAI (folder associated items – hidden items that hold data such as rules)  are noted for transfer.
  • The folder hierarchy is initialized in the new mailbox.
  • A checkpoint is created and then the Store starts to transfer information by pulling it from the source mailbox to build up the content in the new mailbox.
We then see a note to tell us that the move stalled because the target database (DB3) does not satisfy HA requirements because the DataMoveReplicationConstrant is not satisfied. This is a setting on mailbox databases that tells MRS how to proceed if the database is mounted in a DAG. The idea is to make sure that the replication activity provoked to process all the transaction logs generated by mailbox moves does not interfere with the normal operations of the DAG. The default (SecondCopy) is that at least one copy of the target database should be up to date before the mailbox move can proceed. If there is a backlog, Active Manager lets MRS know that it should stall for 30 seconds to see if the condition clears, which is what happens here. In this case, after 30 seconds, the stall lifts because the replication constraint is satisfied and the move can proceed. If the constraint is not satisfied within fifteen minutes, MRS will fail the move.
9/9/2010 4:15:57 PM [ExServer2] Move for mailbox '/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Redmond, Tony' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'DB1' (agent MailboxDatabaseReplication). Failure Reason: Database 1ec5194c-90b9-43d8-aae1-01a5374438f2 does not satisfy constraint SecondCopy. There are no available healthy database copies. Will wait until 9/9/2010 4:30:57 PM.
9/9/2010 4:16:27 PM [ExServer2] Request is no longer stalled and will continue.
After all the items originally enumerated are copied to the new mailbox, MRS performs a final incremental synchronization to copy any items that have been created in the mailbox since the move operation began.
9/9/2010 4:29:46 PM [ExServer2] Stage: IncrementalSync. Percent complete: 95.
9/9/2010 4:29:46 PM [ExServer2] Final sync has started.
9/9/2010 4:29:47 PM [ExServer2] Changes reported in source 'Primary (2a0e48f1-ca39-4
efa-9ae6-23bb2fb917c8)': 0 changed folders, 0 deleted folders, 0 changed messages.
9/9/2010 4:29:47 PM [ExServer2] Incremental Sync 'Primary (2a0e48f1-ca39-4efa-9ae6-2
3bb2fb917c8)' completed: 0 changed items.
9/9/2010 4:30:09 PM [ExServer2] Stage: FinalIncrementalSync. Percent complete: 95.
9/9/2010 4:30:09 PM [ExServer2] Waiting for mailbox changes to replicate.
9/9/2010 4:31:09 PM [ExServer2] Waiting for mailbox changes to replicate.
At this point, the mailbox attributes are updated in Active Directory to switch the mailbox over. The move history reports all of the Active Directory attributes for the mail-enabled account before and after the switch to validate that nothing has been changed. This is of less interest for intra-organization moves but it becomes a very useful source for debugging information when you move mailboxes between organizations and want to be sure that the new mail-enabled account accurately reflects the source data.
9/9/2010 4:31:50 PM [ExServer2] Mailbox was updated using domain controller 'ADRoot.'.
9/9/2010 4:31:50 PM [ExServer2] Mailbox data after finalization:
ActiveSyncEnabled: True
AddressBookFlags: 1
AddressListMembership: \Mailboxes(VLV); \All Mailboxes(VLV); \All Recipients(VLV); \
Default Global Address List; \All Users
Alias: TRedmond
We’re on the down slope now and the new mailbox is established. MRS performs some final clean up and we’re good to go.
9/9/2010 4:31:51 PM [ExServer2] Move has completed and final clean up has started.
9/9/2010 4:31:51 PM [ExServer2] Target mailbox 'Primary (2a0e48f1-ca39-4efa-9ae6-23b
b2fb917c8)' was successfully reset after the move.
9/9/2010 4:31:51 PM [ExServer2] MBI cache of the target mailbox 'Primary (2a0e48f1-c
a39-4efa-9ae6-23bb2fb917c8)' database was successfully seeded after the move. If the
target mailbox was on an Exchange 2003 or Exchange 2007 Mailbox server, this operat
ion isn't supported and wasn't performed.
9/9/2010 4:31:51 PM [ExServer2] Source mailbox 'Primary (2a0e48f1-ca39-4efa-9ae6-23b
b2fb917c8)' was successfully cleaned up after the move.
9/9/2010 4:31:51 PM [ExServer2] Target mailbox information after the move:
Regular Items: 883, 68.72 MB (72,062,206 bytes)
Regular Deleted Items: 8295, 414.7 MB (434,816,683 bytes)
FAI Items: 16, 0 B (0 bytes)
FAI Deleted Items: 0, 0 B (0 bytes)
9/9/2010 4:31:51 PM [ExServer2] Request is complete
Details are also captured if MRS encounters problems during the move. For example, here’s an edited extract from a move report with an error that indicates that a problem was met when MRS attempted to process some rule information from the mailbox (see the bolded information below). A number of sites have reported problems with rules when moving mailboxes from Exchange 2003 to Exchange 2010. Some administrators have fixed the problem by opening the problem mailbox with the MfcMapi utility and looking for suspect rules (for instance, a rule with a blank name). Another idea is to run Outlook against the problem mailbox with the /CleanRules switch to see if that cleans up the rules sufficiently to allow the move to proceed. Still another idea is a suggestion to have the user add another rule to force an update in the rules set in the mailbox to see if that cures the problem. If all fails, remember to spread magic dust in a circle and chant for a while in the hope that whatever is stopping the move simply goes away.
9/10/2010 11:29:14 PM [ExServer1] Fatal error MapiExceptionInvalidParameter has occurred.
Error details: MapiExceptionInvalidParameter: Unable to modify table. (hr=0x80070057, ec=-2147024809)
Diagnostic context:
Lid: 55847   EMSMDBPOOL.EcPoolSessionDoRpc called [length=192]
Lid: 43559   EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=652][latency=0]
Lid: 23226   --- ROP Parse Start ---
Lid: 27962   ROP: ropModifyRules [65]
Lid: 17082   ROP Error: 0x80070057
Lid: 27745
Lid: 21921   StoreEc: 0x80070057
Lid: 27962   ROP: ropExtendedError [250]
Lid: 26849
Lid: 21817   ROP Failure: 0x80070057
Lid: 29150
Lid: 20446   StoreEc: 0x80070057
at Microsoft.Mapi.MapiExceptionHelper.ThrowIfError(String message, Int32 hresult, SafeExInterfaceHandle iUnknown, Exception innerException)
at Microsoft.Mapi.MapiModifyTable.ModifyTable(ModifyTableFlags flags, ICollection`1 rowList)
at Microsoft.Mapi.MapiFolder.AddRules(Rule[] rules)
at Microsoft.Mapi.MapiFolder.SetRules(Rule[] rules)
As you can see from this discussion, the detailed move history is sufficiently detailed to provide a real insight into the workings of Exchange 2010 move requests. One more small detail – the Exchange 2010 SP1 version of EMC allows you to view a move log as a move request progresses. Click on Move Requests in the Mailbox node and then select a mailbox that is being moved, then click on Properties and then the Log tab. The information presented here (see example below) is very similar to the detailed move report – the sole difference is that it doesn’t come from the user’s mailbox unless the move is complete. When a move is in progress, Exchange keeps the move report data in the system mailbox of the target database unless the move operates in push mode, in which case the data is kept in the system mailbox of the source database. When the move completes, MRS moves the data from the system mailbox into the user’s mailbox.
Viewing the move log from EMC
A final point about the completion percentage reported in move reports. The first 20% of the work done to move a mailbox is in the preparatory phase to create the new mailbox and enumerate the content in the source mailbox. The majority of the work is done between 20% and 95% as the content is moved from source to new mailbox. MRS reports progress as items are moved and increases the reported percentage from 20% onwards based on the amount of mailbox data moved from the source. Once all the source data that was originally enumerated has been moved MRS halts and reports 95% completion. A final incremental synchronization to move any changed content and to flip the mailbox settings in Active Directory is all that’s required to get us to 100%.
So there you are – lots of information about mailbox move requests! This is the kind of information that we get into during the Exchange 2010 maestro training sessions, or indeed as documented in my Microsoft Exchange Server 2010 Inside Out book. Very much “thoughts of an idle mind”!
– Tony