Re-seeding Exchange CCR when it breaks

There may be times where you will need to re-seed Exchange CCR when it breaks.  This is frequent after the logs drive fills up and you have manually deleted the logs on the active node to get it up and running again.  The passive node will need to be reseeded.  Other reasons you may need to re-seed include:

•Corrupt log file
•Data loss after a failure
•Offline defrag of the DB
In summary, re-seeding involves copying a new copy of the edb database and log files onto the passive node and replaying the logs to the log file specified by the chk file on the active node.

There is a direct correlation between the size of the database and the amount of time it takes to re-seed.  However, there is a handy string of o’s to let you know how you are getting on.  e.g.


So, to do this, first suspend replication of the Storage Group in the Exchange PowerShell:

Suspend-StorageGroupCopy -Identity:<Server\StorageGroupName>

If you don’t have the name of the Storage Group Copy, run:


Next, manually remove (delete) the database, log files and checkpoint files from the Passive Node.

Next, while still on the passive node, run:

Update-StorageGroupCopy -Identity:<Server\StorageGroupName>

Once it has completed, you can resume the Storage Group Copy as follows:

Resume-StorageGroupCopy -Identity:<Server>\<StorageGroupName>

Finally, verify that CCR is working properly again using the Get-StorageGroupCopyStatus utility

Hope this helps,


Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.