In our Exchange 2010 environment each of our DAGS contains 3 servers, each holding active, passive and lagged databases. The lagged databases are set to an activation preference of 3 and are only used for recovery in the event that the two updated copies become corrupt or in the event of a catastrophic failure of the other 2 nodes.  In our 2010 environment in the event of a catastrophic failure of 2 of the servers the logs for the lagged database copies would be automatically replayed and the databases brought online.  In testing this functionality on our new Exchange 2013 environment I am encountering the following error:  

        Database copy 'DATABASENAME' on server 'SERVER' has a total (copy plus replay) queue length of
843 logs, which is higher than the maximum allowed queue length of 400. If you need to activate this database copy,
you can use the Move-ActiveMailboxDatabase cmdlet with the -SkipLagChecks and -MountDialOverride parameters to
forcibly activate the database copy. If the database does not automatically mount after running
Move-ActiveMailboxDatabase successfully, use the Mount-Database cmdlet to mount the database.

We need a way for databases to automatically fail over and replay logs in the event of a catastrophe.  Is there any way to change the maximum allowed queue length?

Hi,

According to this error, I suggest to use Move-ActiveMailboxDatabase cmdlet with the -SkipLagChecks and -MountDialOverride parameters to activate the database copy as descript in the error. So try the command like this:

Move-ActiveMailboxDatabase  "DBname"  -ActivateOnServer  "ServerName" -skiplagcheck - SkipClientExperience -SkipHealthChecks -MountDialOverride:None

By the way, we can use Get-MailboxDatabaseCopyStatus to check the copy queue length and replay queue length.

Best Regards.

As was stated in my original post "We need a way for databases to automatically fail over and replay logs in the event of a catastrophe."

Obviously having to use special switches does not allow for automatic failover which is what I was asking about in the first place.

• Edited by JSHK 14 hours 53 minutes ago

As was stated in my original post "We need a way for databases to automatically fail over and replay logs in the event of a catastrophe."

Obviously having to use special switches does not allow for automatic failover which is what I was asking about in the first place.

• Edited by JSHK Monday, March 30, 2015 4:30 PM

Hi.

To automatically switch databases (exit 2 servers), it is necessary that the architecture of Exchange remained most of the votes in the cluster. To do this in your mail system should be placed at least 4 Exchange server and one Witness.

If you are planning to failure of two servers in one DC, then in the second server with at least 2 alternative Wintess, switching is performed manually, too.

PS. Maximum queue, you can specify its own, but in this case the variant with increasing load on the server and stop all mail databases.

Oleg, thanks for the response.  But you don't specify where to specify the Maximum queue.  I have the DAG set up and functioning, that is not the concern.  And it's a three server DAG so the votes in the cluster scenario does not really matter.  All I am seeking is information on setting the maximum queue so I can allow databases to automatically fail over to the server that holds the lagged copies, should we experience a catastrophic failure on two of the three nodes in the DAG.

I will try to convey my point.
If you have happened to a situation where 2 of 3 copies of the databases are not available and the latest database contains a complete list of log files and thus may be damaged. This is very bad. The probability of restoration of data and databases in general is very low. It says error risk calculation and servers. In this case, you will need to backup your mail and then transferring messages from damaged database.
Theoretically possible to restore the database and connect it, but there is no guarantee the contents of the database.
Activate a lagged mailbox database copy.

Exchange Server 2013 Lagged Database Copies In Action

In my practice, I have encountered a few times with this situation and have always warned that this is a last resort and there is no warranty of on the safety of data.

You can reduce the quality of test copies accessible database. If this status corresponds to the quality of the database, it will be installed automatically. But this mechanism does not cost transparent at first glance.

Exchange 2013 High Availability demystified