Not every mailbox move is a one off. Most of the time in my line of work I am trying to move a significant number of mailboxes in any given evening. This can be complicated if you target Mailbox happens to be sitting on a Database Availability Group (DAG) database. An issue that can rear it ugly head is the log replay depth of the secondary or ternary copy of the database can get significantly long. This is usually attributed to one of the following: speed of links, disk performance, a database(s) offline, or slew of other possibilities. Once this log depth gets to high the database is flagged as being to far out of sync the mailbox move will be stalled. Now if you are lucky and have a fast link the queues will empty and life goes on. However, if you are like most of the world in and suffer from inadequate resource the mailbox move will stall out and fail
Microsoft has 3 fixes for this problem
1. Remove move the request
2. Resolve the issue with the database copies. (Bring them up to date and healthy)
3. Modify the database with the set-mailboxdatabase command to update the DataMoveReplicationConstraint to allow the moves to continue regardless of copy status.
However I have another idea that work very well and save a lot of bandwidth and time. with that being said this is not always an option depending on your service level agreements and database copy requirements.
Here are the steps from a high level
1. Remove all remote copies of the database.
2. Perform mailbox moves
3. Backup database to removable storage.
4. Walk,Bus,Drive,Fly, UPS or FedEx removable drive to remote location
5. Copy database to proper location
6. Add a mailbox copy using powershell with the SeedingPostponed parameter set
7. Database plays logs and catches up with active copy*
8. Done.
*All logs must be present since the database backup was made in order to re-sync with active copy
Tweet