Reseeding Exchange Database Availability Groups

This was originally published July 5th, 2011 on my old blog: http://geekswithblogs.net/marcde/archive/2011/11/03/dags-and-reseeding.aspx

I worked on a case today which had 2 Exchange 2010 servers in a DAG with about 6 mailbox 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 from hell.

The first thing we did was to get the status of the database by running get-mailboxdatabasecopystatus -id “databasename\servername” | fl. This returned us the following information:

RunspaceId                   : 9d5ba0d8-78ff-4b51-bbd9-254953d36ecb
Identity                     : Databasename\servername
Name                         : Databasename\servername
DatabaseName                 : DatabaseName
Status                       : Mounted
MailboxServer                : Servername
ActiveDatabaseCopy           : servername
ActivationSuspended          : False
ActionInitiator              : Unknown
ErrorMessage                 :
ErrorEventId                 :
ExtendedErrorInfo            :
SuspendComment               :
SinglePageRestore            : 0
ContentIndexState            : Healthy
ContentIndexErrorMessage     :
CopyQueueLength              : 0
ReplayQueueLength            : 0
LatestAvailableLogTime       :
LastCopyNotificationedLogTime:
LastCopiedLogTime            :
LastInspectedLogTime             : 
LastReplayedLogTime              : 
LastLogGenerated                 : 0
LastLogCopyNotified              : 0
LastLogCopied                    : 0
LastLogInspected                 : 0
LastLogReplayed                  : 0
LogsReplayedSinceInstanceStart   : 0
LogsCopiedSinceInstanceStart     : 0
LatestFullBackupTime             : 
LatestIncrementalBackupTime      : 
LatestDifferentialBackupTime     : 
LatestCopyBackupTime             : 
SnapshotBackup                   : 
SnapshotLatestFullBackup         : 
SnapshotLatestIncrementalBackup  : 
SnapshotLatestDifferentialBackup : 
SnapshotLatestCopyBackup         : 
LogReplayQueueIncreasing         : False
LogCopyQueueIncreasing           : False
OutstandingDumpsterRequests      : {}
OutgoingConnections              : 
IncomingLogCopyingNetwork        : 
SeedingNetwork                   : 
ActiveCopy                       : True

RunspaceId                       : 9d5ba0d8-78ff-4b51-bbd9-254953d36ecb
Identity                         : MailboxName\servername
Name                             : MailboxName\servername
DatabaseName                     : Mailboxdatabasename
Status                           : FailedAndSuspended
MailboxServer                    : Servernamethatfailed
ActiveDatabaseCopy               : servername
ActivationSuspended              : True
ActionInitiator                  : Service
ErrorMessage                     : The required log file 2103 for MailboxName\servername is missing on the active copy. If
                                    you removed the log file, please replace it. If the log file is lost, the database 
                                   copy will need to be reseeded using Update-MailboxDatabaseCopy.
                                   
ErrorEventId                     : 2059
ExtendedErrorInfo                : 
SuspendComment                   : The database copy was automatically suspended due to failure item processing. At '03
                                   /11/2011 16:23:14' the copy of 'mailboxdatabase' on this server experienced an error t
                                   hat requires it be reseeded. For more detail about this failure, consult the Event l
                                   og on the server for other storage and "ExchangeStoreDb" events. The passive databas
                                   e copy has been suspended.
                                   
SinglePageRestore                : 0
ContentIndexState                : Failed
ContentIndexErrorMessage         : Catalog is dismounted externally for database {0b5d6c24-09dc-4648-958c-eb61b2bd778a}
                                   .
CopyQueueLength                  : 3753
ReplayQueueLength                : 0
LatestAvailableLogTime           : 03/11/2011 16:22:17
LastCopyNotificationedLogTime    : 03/11/2011 16:22:17
LastCopiedLogTime                : 
LastInspectedLogTime             : 
LastReplayedLogTime              : 
LastLogGenerated                 : 3753
LastLogCopyNotified              : 3746
LastLogCopied                    : 0
LastLogInspected                 : 0
LastLogReplayed                  : 3695
LogsReplayedSinceInstanceStart   : 0
LogsCopiedSinceInstanceStart     : 0
LatestFullBackupTime             : 
LatestIncrementalBackupTime      : 
LatestDifferentialBackupTime     : 
LatestCopyBackupTime             : 
SnapshotBackup                   : 
SnapshotLatestFullBackup         : 
SnapshotLatestIncrementalBackup  : 
SnapshotLatestDifferentialBackup : 
SnapshotLatestCopyBackup         : 
LogReplayQueueIncreasing         : False
LogCopyQueueIncreasing           : False
OutstandingDumpsterRequests      : {}
OutgoingConnections              : 
IncomingLogCopyingNetwork        : 
SeedingNetwork                   : 
ActiveCopy                       : False

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” (also known as the sledgehammer)! This is somewhat disruptive for your users and risky unless you keep your head in the game.

These would be the steps you follow:

  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
  8. Drink cocktails on the beach as your sync is healthy (not required but highly recommended)

All in all this should get your copy back in order. Not exactly the way you’d want to (aka without down time) but it get’s the job done. And sometimes thing just need a little convincing

Leave a Reply

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

Close Menu
%d bloggers like this: