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.
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:
- The Move History, a summary report that describes the essential parameters for the mailbox move.
- 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.
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 exserver2.contoso.com 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] 'contoso.com/Users/Administrator' created move request.
9/9/2010 4:14:01 PM [ExServer2] The Microsoft Exchange Mailbox Replication service '
ExServer2.contoso.com' (14.1.218.11 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 'EXSERVER1.contoso.com' 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 'EXSERVER1.contoso.com' 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 (2data
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 exserver2.contoso.com 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 'Ex2003.contoso.com' 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 DataMoveReplicationConstraint 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.
contoso.com'.
9/9/2010 4:31:50 PM [ExServer2] Mailbox data after finalization:
AcceptMessagesOnlyFrom:
AcceptMessagesOnlyFromDLMembers:
AcceptMessagesOnlyFromSendersOrMembers:
ActiveSyncAllowedDeviceIDs:
ActiveSyncBlockedDeviceIDs:
ActiveSyncEnabled: True
AddressBookFlags: 1
AddressListMembership: \Mailboxes(VLV); \All Mailboxes(VLV); \All Recipients(VLV); \
Default Global Address List; \All Users
AggregationSubscriptionCredential:
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.
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 documented in my Microsoft Exchange Server 2010 Inside Out book. Very much “thoughts of an idle mind”!
Follow Tony @12Knocksinna
Pingback: The very useful ExFolders utility | Thoughtsofanidlemind's Blog
Pingback: Clearing out mailbox move requests | Thoughtsofanidlemind's Blog
Pingback: Batching Exchange 2010 mailbox moves | Thoughtsofanidlemind's Blog
Hi Tony,
Thank you very much for the excellent article. I am just testing out inter-forest moves from on-premise Exchange 2010 to Microsoft’s Office 365 beta of Exchange Online. This article really helps with my understanding of the logs and the move process.
John
Pingback: Mailbox verschieben in Exchange 2010 – Wofür steht die Prozent-Anzeige? « Robert Willes Welt
Pingback: Accessing Exchange 2010 mailbox move history data
Expanding on what Tony wrote above: If you wanted to get something like $MoveHistory.CompletionTimestamp to a string you could do it like so:
$mailbox = Get-Mailbox -Identity joeblow
$MoveHistory = (Get-MailboxStatistics $mailbox -IncludeMoveHistory).MoveHistory
$CompletionTimeStamp = $MoveHistory[0].CompletionTimeStamp.ToString()
“The mailbox move for {0} completed at: {1}” -f $mailbox.DisplayName, $CompletionTimeStamp
Is it possible to list the move history of every exchange mailbox at once ? instead of indivdual mailbox’s?
Well, you could pipe the output from Get-Mailbox to Get-MailboxStatistics to generate a report for every mailbox but I’d be wary of doing that due to the length of time that such a command might take on a large server or inside a large organization.
Tony
Got your Exchange Server 2010 Inside Out, kindle edition. Great stuff! Should have sprung for the extra $ though to get a hard copy. search isn’t the best tool for that medium, yet. . . My question on the above: what about move history for all mailboxes within a single database at a time? I just stepped into a new job as the sys admin and I would like to have a record of what was moved within recent history before my coming on board. When I try to add the -IncludeMailboxHistory param to the get-mailboxstatistics -database “dbname” command, I get the error “AmbiguousParameterSet,Get-MailboxStatistics” Everything I have been able to find online gives my exact shell command verbatum as an example with options of using -server, -database or -identity as getmailboxstats parameters. The only one that actually doesn’t spit out the ambiguous error is the -identity parameter. Thanks, Bobby.
Ambiguous parameters means that you’ve tried to pass something to the cmdlet that it doesn’t know how to deal with. If you look at the TechNet help for Get-MailboxStatistics, it shows three sets of parameters depending on if you’re fetching data for a mailbox, database, or server. The mailbox is the only one that supports mailbox history, as in:
Get-MailboxStatistics -Identity [-Archive ] [-DomainController ] [-IncludeMoveHistory ] [-IncludeMoveReport ]
So, if you want to fetch information about multiple mailboxes, you’ll have to use Get-Mailbox to create a set of objects and then pipe that to Get-MailboxStatistics…
TR
Pingback: E2K10 – Mass move mailboxes from E2K3 to E2K10 | Jonson Yang
I’ve found a case where Get-MailboxStatistics -IncludeMoveReport doesn’t quite cut it… when trying to look at a failed move from Ex2003 to Ex2010. In this case, the mailbox does not have the move history information because it is still Ex2003. Get-MoveRequestStatistics -IncludeReport is the missing ingredient, and then I am back on track in your excellent explanation.
Thanks Rod…
Tony, I came across you article while troubleshooting an issue that we are having with moving mailboxes from an exchange 2007 to 2010 environment, that are in a child domain. I now have a much better understanding of what the process of the moves is -your article is excellent!-, and can see that it is during the final incremental synchronization where we are having problems. The test moves are successful (empty mbxs), but hang at the 95% completion mark for 10.5 minutes. The entire move only takes 11 minutes, though. Any thoughts on this? The parent and child domains have both been prepped. I’d appreciate any insight on this. Thanks!
Are there any clues in the mailbox move report that might indicate why the mailbox move is stalling at the final synchronization?
TR
Hi Tony, thank you for getting back to me. I ended up finding that although the CAS/HUB server could communicate properly with the DCs on the child domain, the MBX server could not. After getting the network team to get the proper firewall rules in place, the test moves take under 50 seconds. I appreciate you taking time to respond!
I have a question. I have a user who was taking a long time to migrate. It complained about the CAS replication service taking a long time. I suspended before completion and then removed the move request. I would like to move the user but the remote move is not available. I have refreshed several times and his box icon is green. How can I force the mailbox to do a remote move again thru shell since the EMC appears stuck. It has removed the move request so I am assuming after waiting an hour, I would be able to start a fresh move back to the Office 365 environment. Any assistance greatly appreciated. All other moves are going smoothly.
Hi Valerie,
You don’t really provide enough data to allow any sort of reasonable guess as to what’s going on here. For example, this sounds like you’re trying to move a mailbox from an Exchange 2010 on-premises serrevr to an Office 365 domain. Is that right? What happens when you use EMS to run a Get-MoveRequest command for the mailbox? What do you see in the mailbox move report? Have the AD properties updated by the move been cleared (to allow a new move request to be created)? EMC is based on the same set of PowerShell cmdlets as EMS, so we have to find out what the current situation is with the mailbox and any associated move request to begin to make progress.
TR
Excellent post! tnx! 😉
This is an excellent blog site. Thanks to Tocny for the accurate tips.
Great contribution! I am new to Exchange PowerShell and stumbled onto this information. I’d like to run a command that generates a move report for a given set of users. Was trying something like:
$MoveReport = (Get-Content C:\Scripts\Exchange_Migration_Users.txt | Get-MailboxStatistics -IncludeMoveReport).MoveReport
$MoveHistory[0] | Out-file -FilePath `c:\Scripts\Move_History.Log’
But that fails with: “Cannot index into a null array. At line:1 char:14”
Clearly I am missing something obvious….
I think you’ll need a ForEach loop to do what you want to here. Loop through a list of mailboxes, use their identity to make sure that you’re fetching the move report and then append the move report to a text file.
TR
All our servers are at the same patch level (Exchange 2010 SP2 RU4), but I have just today noticed a bit of a (significant?) mismatch in version numbers when I was performing a mailbox move.
Extract of move status cmdlet
—
[PS] C:\Windows\system32>Get-MoveRequestStatistics -id USERID|fl *ver*
SourceVersion : Version 14.2 (Build 318.0)
TargetVersion : Version 14.2 (Build 247.0)
SourceArchiveVersion :
TargetArchiveVersion :
TargetDeliveryDomain :
OverallDuration : 00:16:03
MRSServerName : HUBCASBOX.DOMAIN.com
—
[PS] C:\Windows\system32>Get-MailboxServer SOURCESERVER |fl *ver*
SubmissionServerOverrideList : {}
AdminDisplayVersion : Version 14.2 (Build 247.5)
ServerRole : Mailbox
ExchangeLegacyServerRole : 0
ExchangeVersion : 0.1 (8.0.535.0)
OriginatingServer : DOMAINCONTROLLER.DOMAIN.com
[PS] C:\Windows\system32>Get-MailboxServer DESTINATIONSERVER |fl *ver*
SubmissionServerOverrideList : {}
AdminDisplayVersion : Version 14.2 (Build 247.5)
ServerRole : Mailbox
ExchangeLegacyServerRole : 0
ExchangeVersion : 0.1 (8.0.535.0)
OriginatingServer : DOMAINCONTROLLER.DOMAIN.com
[PS] C:\Windows\system32>Get-ClientAccessServer HUBCASBOX |fl ExchangeVersion
ExchangeVersion : 0.1 (8.0.535.0)
[PS] C:\Windows\system32>Get-ClientAccessServer HUBCASBOX |fl ExchangeVersion
ExchangeVersion : 0.1 (8.0.535.0)
—
The Console always shows a bit of a differece in version number compared to what is shown in the Shell (247.0 vs 247.5), but why do I see a ‘bigger’ version difference between 318.0 and 247.0 in the Source & Target machines for this mailbox move? Is the move getting the Source & Target versions from somewhere else?
Thanks,
Conor.
Hi Conor,
I think what you’re seeing here is some evidence of version mismatch reported by different components of Exchange 2010. I guess the various teams that build parts of the server aren’t always aligned when they increment versions, something that’s easy to understand when coping with a very large and complex product composed of many moving parts that’s patched through service packs and roll-up updates. The issue has been discussed before in other forums (see http://social.technet.microsoft.com/Forums/sr-Latn-CS/exchange2010/thread/4880fabb-c7e1-4f5c-897e-81d9f14b264d for example) and the conclusion was that it really doesn’t matter as long as “everything just works”.
I also note http://dougg.co.nz/2012/09/20/exchange-2010-sp2-target-database-build-is-lower-than-source-sp1-database-build/, which concluded that the “the Source shows as the SP+RU and the Target simply shows as the SP level”. I think this makes sense, so you should be all set.
TR
Thanks Tony!
If I’d posted this question before last week I could’ve thanked you personally in Wreckers Bar at MEC last week 🙂
Thanks again,
Conor.
Great content but the images make viewing it hard. I would consider removing the rock images and having them just at the header.
Hi Luke, Some others who have reported the same problem have found that some images from wordpress.com have been blocked or otherwise interfered with and that distorts what’s shown on screen. Maybe you’ve the same problem?
TR
Pingback: Exchange Server 2010/2013 Mailbox Move History
I think, there is a typo…
“DataMoveReplicationConstraint”, not “DataMoveReplicationConstrant”
Thanks. Fixed.