Exchange: DAGs and reseeding


*repost from 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 mailboxes, 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. So our client cried for help.

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:

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"! 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.

Comments (4)

  1. Mahmoud says:

    Wow Man works like MAGIC

  2. Parveen says:

    Mark, by Moving all the log files you mean to move only the Transactions Logs only or does it also includes to move everything including folders, .jrs .chk and tmp db file as well?

  3. robk says:

    and then you invalidate incremental backups and nothing works after that. by removing logs from active node you are resetting sequence number of your logs. nice try

  4. Marc says:

    Hi Robk. You are right, it will reset the sequence number of the log files. Then again, dismounting the database will cause a playback of the log files in to the database file so I don’t see why you would care? Your DR solution is the DAG and your next
    full backup is going to get the full data set…