Clearing out mailbox move requests

After you’ve run Exchange 2010 for a while, you’ve probably moved a few mailboxes around and have accumulated some completed mailbox move requests.

When it begins to move a mailbox, the Mailbox Replication Service (MRS) stamps the user object for the mailbox with six attributes that it uses to indicate that the mailbox is being moved and the progress of the move. To reduce the interaction with Active Directory, only one of these attributes (the status) is updated during the move. The statistics for the move such as number of items moved, bytes moved, and so on are maintained in the XML coded move request that MRS updates in the system mailbox of the target database. Data used to construct the move report is also stored in the same place.

Once a move is completed, MRS copies the move report from the system mailbox to a hidden folder in the user’s mailbox. You might assume that the attributes are also removed (or cleaned up) in Active Directory, but this doesn’t happen. I believe that the logic here is that it’s up to the administrator to decide when the move request is no longer required, at which point they can explicitly go ahead and remove the request. The logic is valid but given the fact that most administrators don’t realize that move requests are silently piling up and not being removed, the end result is an accumulation of move requests just like calcium forming in a kettle in an area that enjoys hard water.

The first time when an administrator is likely to realize that move requests are retained and not cleaned out is when they attempt to move a mailbox that was previously moved by MRS. At this point, they’ll be told that a move request already exists for the mailbox and they will have to clear the move request before they are able to proceed. The Exchange Management Console (EMC) attempts to bring the fact that a mailbox has a move request registered to the attention of administrators by displaying a different icon for the mailbox, but as you can see below, it’s all too easy to miss this subtlety.

Spot the difference in the icons

Of course, EMC provides a separate section to allow administrators to work with move requests, so you can switch over there to discover what mailbox move requests are known to Exchange. As shown below, it’s easy to select all the move requests and then click “Clear Move Request” in the action pane. EMC will then clear the AD attributes from the selected mailbox objects and you’ll be able to create new move requests for them.

Getting ready to clear mailbox move requests

Of course, you don’t have to do this with EMC as Exchange 2010 provides a comprehensive set of cmdlets to work with mailbox move requests. The Get-MoveRequest cmdlet reveals the set of known move requests and we can filter the command so that EMS only reports the set with a completed status.

Get-MoveRequest -MoveStatus Completed

The other status values you can look for include the following:

  • CompletedWithWarning: Although the mailbox was moved successfully, something happened during the move that an administrator needs to check by reviewing the move report.
  • CompletionInProgress: Exchange is finalizing the move by resetting the Active Directory to reflect the new location for the mailbox.
  • Failed: Whoops… not a good sign. Time to check the move report to discover what happened to stop the mailbox moving. Hopefully it’s something simple such as the mailbox quota for the target database being too low to accommodate the mailbox that you want to move. Another common problem is when some “bad items” are encountered in the source mailbox. These are items that Exchange considers to be corrupt or incomplete for some reason (often a bad MAPI property). You can force MRS to continue processing and ignore the bad items by setting a reasonable value (something higher than zero and lower than 10) for the BadItemLimit parameter when you create a move request. MRS is able to resume failed moves at the last checkpoint. Note that if you state a bad item limit higher than 50, you have to specify the AcceptLargeDataLoss parameter when you create the move request with the New-MoveRequest cmdlet. This is because MRS won’t write corrupt items into the new mailbox and each bad item is therefore dropped. You may just want to know what these dropped items contained! On the upside, they may be old calendar items that the user won’t care about. On the downside, they might be items relating to the latest corporate strategic plan…
  • AutoSuspended: MRS has moved the bulk of the mailbox to the target database and is now paused waiting for an administrator to release the move request and allow MRS to perform a final synchronization to bring the new mailbox completely up to date and then switch the mailbox in Active Directory. Effectively, the move request is suspended before it enters the “CompletionInProgress” phase. You can resume processing with the Resume-MoveRequest cmdlet. You can instruct MRS to auto-suspend a mailbox move by passing the SuspendWhenReadyToComplete parameter to the New-MoveRequest cmdlet.
  • Queued: The move request is queued and awaiting an MRS instance in its home site to “pick up” the request and take responsibility for its processing.
  • InProgress: MRS is busy moving content from the source database to the target database to build the new mailbox. MRS spends most of the time processing a mailbox move in this status.
  • Suspended: The move request has been suspended for some reason with the Suspend-MoveRequest cmdlet and is waiting for an administrator to release it. A move request can only be suspended before it reaches the final completion phase as once Exchange starts to update Active Directory, it’s too late to go back.

Once we have obtained a set of mailbox move requests, we can clear them with the Remove-MoveRequest cmdlet. To be most effective (and if you’re sure that you won’t remove any request that you want to keep), we can pipe the objects found with Get-MoveRequest to Remove-MoveRequest as follows:

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

It’s a royal pain to have to perform this kind of housekeeping that Exchange should really be able to do on an automatic basis. I fully appreciate that some administrators may want to keep some mailbox move requests for an extended period, but it should be possible to have a parameter for the New-MoveRequest cmdlet to allow administrators to state an expiry time for a successful move request. Better again, maybe a new organization-wide configuration setting that applies to all successful move request with the ability for an administrator to override the organization wide setting so that a move request can be retained for a particular mailbox. Something like this would be good.

To set a 30 day automatic expiry for successful move requests:

Set-OrganizationConfig -DefaultExpirySuccessfulMR 30.0:00:00

To define that a move request does not automatically expire:

New-MoveRequest -DoesNotExpire $True

Of course, the official health warning is that I have no idea whether these enhancements will ever appear in a future version of Exchange. Christmas is coming and you never know what the Exchange developers have up their collective sleeves. We wait in hope…


Follow Tony @12Knocksinna

For more information about the Mailbox Replication Service and how mailbox moves work in Exchange 2010, see Microsoft Exchange Server 2010 Inside Out, also available at


About Tony Redmond

Lead author for the Office 365 for IT Pros eBook and writer about all aspects of the Office 365 ecosystem.
This entry was posted in Exchange, Exchange 2010 and tagged , , , , , , , , , , . Bookmark the permalink.

30 Responses to Clearing out mailbox move requests

  1. Pingback: Tweets that mention Clearing out mailbox move requests | Thoughtsofanidlemind's Blog --

  2. Pingback: Batching Exchange 2010 mailbox moves | Thoughtsofanidlemind's Blog

  3. Neill Tinlin says:

    The price discrepancy between and is insane. $37.79 or £39.09?

  4. Pingback: Tweaking the Mailbox Replication Service configuration file | Thoughtsofanidlemind's Blog

  5. says:

    hi Tony,
    here’s a case were -suspendwhenreadytocomplete was used however the final sync failed with “Transient error MapiExceptionNotEnoughMemory has occurred.” (hr=0x8007000e, ec=0)
    do u suggest to run Remove-MoveRequest and then issue a New-MoveRequest again?
    what happens to the source MBX (as the MRS as already copied 95%)?

    • Well, the error reported is “transient”, so you’d assume that it’s caused by some condition that might not exist anymore. Can you resume the move request?

      If not, I would try a new mailbox move (yes, you’ll have to remove the existing request to allow the new one to proceed). If possible, have the new request serviced by a different CAS, just to make sure that there’s nothing screwy going on in the CAS that has reported the error. The “new” mailbox that failed will be cleaned up by Exchange.


  6. says:

    Tony thx for replying!!

    While i read your other blog, it reads “A carefully orchestrated sequence then occurs to connect to the source and target database, enumerate the contents of the source mailbox, create the new mailbox, and **move** the contents from the source mailbox to the target database. ”
    Does that mean if the resume mailbox still fails for whatever reason and then if I proceed to run Remove-MoveRequest, the user will be accessing his old E2K7 MBX but the contents are already moved to Ex2010 new MBX? Meaning data-loss?

    I wish to get the user access either his E2K7 or Ex2010 MBX with full contents ASAP.
    my PoA is to run the following

    Get-MoveRequest -MoveStatus ‘Failed’ -BatchName ‘Users’ | Resume-MoveRequest
    Get-MoveRequest -MoveStatus ‘CompletionInProgress’ -BatchName ‘Users’ | Resume-MoveRequest
    If this still fails then get user to old condition by removing the move request (assume the contents were copied and not Moved)
    Get-MoveRequest -MoveStatus ‘Failed’ | Remove-MoveRequest

    Also, Ex2010SP1 has new feature Soft-Deleted Mailboxes. Does this apply to E2K7 source MBX as well.

    • The user still accesses his original mailbox until a mailbox moves completes and the Active Directory pointers are switched by MRS. Thus, if the resume mailbox request fails (for whatever reason), the user is unaffected because they are still using the old mailbox. When you run Remove-MoveRequest, this just serves to nullify the move request and restore things to the state they were before the mailbox move started. No data loss is incurred.

      I might try to resume the failed move requests one at a time just to see how things progress before I attempted to try a complete batch.

      The Exchange 2010 SP1 feature is there to ensure that a mailbox can be recovered in case something catastrophic occurs following a move. It’s a form of defense mechanism that shouldn’t be required in any but extreme circumstances as MRS is quite careful to check that everything is ready to go before it switches the AD pointers to complete a move. AFAIK, it should apply to Exchange 2007 source mailboxes. But I haven’t tried it with one!


      • Ryan Sadorus says:

        Tony, good article. We have recently ran into an issue where some cross forest moves were suspended, then cancelled all together. For some reason the mailboxes in the source forest still show up as they have a move request attached to them, but we can’t find the requests anywhere, via EMC or powershell. It’s almost as if the mailbox (as you stated above) may have a flag set on it somewhere which says that it is moving, even though it isn’t. Is there some back end way to go in and clear this? Any advice greatly appreciated. Regards, Ryan

  7. Ryan Sadorus says:

    I guess I just found the answer on my own to the above question and thought I’d share. There was an AD attribute that gets populated in the source forest that can be cleared out, assuming there isn’t a valid move request somewhere. Once i cleared the attribute on that specific account, I was able to initiate a new move request for that mailbox. Regards, Ryan Sadorus

    • Hi Ryan,

      Which AD attribute are you referring to? MRS populates a few attributes that should be cleared when you run Remove-MoveRequest. I’m curious as to which one “lingered”!


      • Ryan Sadorus says:

        Hey there Tony. Sure, the attribute that once cleared, helped me out was “msExchMailboxMoveRemoteHostName”. This attribute just had the remote AD domain name in there. Once I simply cleared this option out (didn’t delete the entire attribute), then the account became available to perform another “remote move request”. The icon was green before and then changed back to a normal look, giving me more options when right clicking. Hopefully this helps someone else… this one was a bit challenging to track down. : ) Thanks for your blog!! Regards, Ryan Sadorus

      • Yep, that’s one of the AD attributes that MRS updates. The question is why it wasn’t cleared… Anyway, glad that things worked out.


  8. Peter says:

    Hello Mr. Redmond,

    I wonder if you can clear something up for me. I have a couple of mailboxes that were put in suspended mode for about 3 weeks. And we finally decided to go ahead and resume and complete the move request. Coincidentally the logs drive of the target DB grew exponentially. They were about 2GB mailbox moves (95% complete) and the logs drive had 50GB free. nonetheless the logs grew and the DB went offline. Is it because the MRS has a lot to do during its incremental synchronization? but shouldn\’t it just do the changes of the mailbox during that the state the mailboxes were in suspension? I dont believe this would be the cause of the DB going offline. Also I noticed that on of the DAGs the copy queue length had grown to 48K plus, could that have done it? Thanks for the time.

    • Resuming a move after a wait of 3 weeks will mean that the incremental synchronization has a lot of work to do… Given that these are 2GB mailboxes, they are probably quite active and so three weeks worth of additions, deletions, and changes might amount to 25% of the mailboxes – or 1.5GB of updates. Nevertheless, it’s not right that 50GB of logs were consumed. I think you need to investigate the 48K logs as that’s probably the root cause of the problems. Have you looked through the event logs for clues?


  9. Peter says:

    Appreciate the quick response. What I did see so far is something happened..

    The database copy was automatically suspended due to failure item processing. At ‘7/22/2012 6:01:23 PM’ the Exchange store database ‘Exchange2010-DAG1’ copy on this server experienced a configuration error. The problem may have been the result of a storage failure. For more detail about this failure, consult the Event log on the server for other storage and “ExchangeStoreDb” events. The passive database copy has been suspended.

    the errors I see on the server in the same time frame are:

    Information Store (4200) Exchange2010-DAG1: A request to read from the file “S:\Exchange2010-DAG1DB.edb” at offset 112783261696 (0x0000001a42680000) for 32768 (0x00008000) bytes succeeded, but took an abnormally long time (31 seconds) to be serviced by the OS. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.

    Information Store (4200) The database engine attempted a clean write operation on page 3441871 of database S:\Exchange2010-DAG1DB.edb. This acton was performed in an attempt to correct a previous problem reading from the page.

    I guess a follow up with the storage team is due to see if there was a blip on their end.

    Again thanks for your time and have a good weekend.

  10. Misha Castro says:

    Not sure if this was asked. Would there be any problem with leaving move requests? I work for an MSP where they have a lot of legacy projects and I keep seeing these move requests. I usually clear them because i like to see things clean. But i am wondering if there are any issues with leaving them there (I ask because if there is i would have all the engineers comb each server to clear out request)


  11. saiyan kumar says:

    Hi Tony,

    My mailbox move completed with warning. i got move request statistics and found this.

    ” Warning: Failed to reset the target mailbox after the move.Error details: An Active Directory error 0x51 occurred when trying to check the suit ability of server ‘’. Error: ‘Active directory response: The LDAP server is unavailable.’ –> The LDAP server is unavailable.”

    Do you have any idea why this is happening?. I’ve been moving mailboxes from databases for long time but i never had issues until i upgraded to Exchange SP3 RU4. Any insights on this would surely be appreciated.

  12. Pingback: GAMME – an unfortunate name for Google’s new migration utility | Thoughtsofanidlemind's Blog

  13. hannesh says:

    Hi Tony

    Very informative article!

    i moved a mailbox from one ex2010 to a different 2010 machine, it completed with warning.
    I get the following in the get-moverequeststatistics:

    “Warning: Failed to reset the target mailbox after the move.”
    “Error Details: The source mailbox is in the wrong mailbox database”

    On the destination server it shows the mailbox as still being on the old server and on the old server it shows the mailbox as being on the new server.
    I have rebooted the mailbox replication service on both sides.

    Any pointers?


  14. Joshua says:

    I have a variation of this problem that cannot be fixed by either of these solutions.

    I have a mailbox on Exchange 2010 (fully patched) with the InTransit flag apparently set, indicated by the icon. The right-click menu does not show the ‘mailbox move’ items

    There are no existing move requests for it, although I do have the log, which shows a ‘succeeded with warning’ message stating that the source mailbox could not be deleted.

    The source mailbox is a database which no longer exists.

    There is no ExchMailboxMove showing in ADSIEdit.

    Now what ?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.