I worked on a case today which had 2 Exchange 2010 servers in a DAG with about 5 mailboxes databases, all in healthy status. All but one that is. This DataBaseCopy just would not come back into sync and was stuck in the eternal Resynchronizing loop. First thing you would want to do is to get a status of the database by running get-mailboxdatabasecopystatus -id "databasename\servername" | fl. This should return you something in this format:

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus -Identity db-archive | FL

RunspaceId:           8ffefaf9-1e9e-4834-9f39-f1fddadae1cb

Identity:                  DB-Archive\DAG10MBX02

Name:                     DB-Archive\DAG10MBX02

DatabaseName:     DB-Archive

Status:                    FailedAndSuspended

MailboxServer:       DAG10MBX02

ActiveDatabaseCopy:             dag10mbx01

ActivationSuspended:           False

ActionInitiator:       Service

ErrorMessage:       The Microsoft Exchange Replication service encountered an unexpected error in log re

                                   play for database 'DB-Archive\DAG10MBX02'. Error MapiExceptionTooManyMountedDatabase

                                   s: Unable to mount database. (hr=0x8004060e, ec=-2147219954)


ErrorEventId:          4057


SuspendComment: The database copy was automatically suspended due to failure item processing. At '7/

                                9/2014 12:51:58 PM' the copy of database 'DB-Archive' on this server wasn't able to

                                operate because the number of mailbox database copies on this server exceeds the sup

                                 ported limit. Recovery was not attempted.


SinglePageRestore               : 0

ContentIndexState                : Failed

ContentIndexErrorMessage : Catalog is dismounted externally for database {58ecc424-151c-40f7-9720-8e09e7c1dbe0}

CopyQueueLength                : 1

Now generally speaking you would do a suspend-mailboxdatabasecopy -id "mailboxdatabase\servername" followed by an update-mailboxdatabasecopy -id " " -DeleteExistingFiles which would update the passive copy and resume the Storage Group Copy. Yet once in a while you'll run in to a case where this won't work as the gap is to large for Exchange to cover. In that case you'll have to perform the highly regarded "manual reseeding procedure"! This is somewhat disruptive for your users and risky unless you keep your head in the situation.

These would be the steps you follow:

Option 1:

  1. Suspend the database copy
  2. Go to the passive node and remove all the database and log files (fun yet?)
  3. Dismount the database from Exchange
  4. Go to the log files folder on the active node and move them all to a different folder
  5. Now copy the EDB file from the active node to the passive node
  6. Mount the database once this is completed
  7. Resume the storage group copy

Option 2:

  1. Get the GUID of the database: get-Mailboxdatabase –Identity Databasename | FT name,*GUID*
  2. Navigate to the following registry path on the target server: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\ContentIndex\CatalogHealth\{DatabaseGUID}
  3. Look for below string keys:
  • State: Exclude
  • ErrorCode: CatalogDismountedExternally
  • TimeStamp: 2014-07-02 14:52:14Z (depending on the last failure/updated time)
  1. Changes these value as given below:
  • State: Recommended
  • ErrorCode: “Success” or leave it blank
  • TimeStamp: 2014-07-02 14:52:14Z (depending on the last failure/updated time)
  1. Initiate seeding/update of the database update-mailboxdatabasecopy -id " " –DeleteExistingFiles
  2. This must resolve the issue.

All in all this should get your copy back in order. Not exactly the way you'd want to (without down time) but it gets the job done.

Ps: You can refer following article as well: http://blogs.technet.com/b/timmcmic/archive/2012/12/04/exchange-2010-adding-database-copies-to-databases-with-a-single-copy-results-in-copy-status-failed-after-seeding-is-completed.aspx