In a 3-site DAG, trying to activate a mailbox database copy. Since this was artificially suspended at one point - quite a few logs were backed up. As soon as the copy was resumed, I'm attempting a move operation to this database copy (which is now busy copying and replaying logs). It throws an error - which is understandable - since the target mailbox server has the default 'GoodAvailability' value for the AutoDatabaseMountDial, which is going to be used since I'm not specifying the -MountDialOverride on the Move-ActiveMailboxDatabaseCopy. This should translate in a maximum of 6 log files that are permitted in the copy queue - anything above this will fail the move. However, once the error comes back, it's referring to a queue of 10 logs (below).

There's no mention of 10 in the values used for the mount dial override behavior, however there is one regarding the DataMoveReplicationConstraint attribute that's set against a mailbox database. The functionality behind it is described here, however in this case each of the database copies is hosted by a mailbox server in a different AD site, with the mounted and a second copy being healthy, aside from the 3rd one that's copying/replicating. The setting against the database for the DataMoveReplicationConstraint attribute is 'SecondCopy'. This translates to at least one of the passive copies has to:

- Be healthy.
- Have a replay queue within 10 minutes of the replay lag time.
- Have a copy queue length less than 10 logs.
- Have an average copy queue length less than 10 logs. The average copy queue length is computed based on the number of times the application has queried the database status. 

Yet even though that's respected for the healthy, additional copy, I get the error below when trying to fail over to the one that's busy copying logs. The state of the mailbox copies after the move operation failed is in the 2nd picture.

• Edited by Albert Mihai Monday, July 13, 2015 6:02 PM

Deferred taxes can appear and when you move the mailbox databases in the fall. Later, they will be indexed and removed, in a situation at different remote sites can see it. By this, I proposed to test this service.

On your question with DAG, there is not so transparent as you can see in numbers (0-6-12). A few years ago on the subject communicated with Scott Schnoll on TechED, when he gave a talk on the Exchange 2010 High Availability