The log drive for one of my storage groups ran out of space causing the database to dismount. In order to restore service as quickly as possible I moved all the logfiles before the checkpoint to a different location and was able to mount the database. Now, however, I am unable to get CCR replication working again for that storage group. I'm attempting to do a reseed but the logfiles are not copying so it's in a failed state. If I suspend replication and do get-storagegroupcopystatus it show 1315020 for CopyQueueLength for that storage group. In Event Viewer there is an error with Event ID 2059, MSExchangeRepl that says: Description: The log file 1278189 for Server2\SG2 is missing on the production copy. Continuous replication for this storage group is blocked. If you removed the log file, please replace it. If the log is lost, the passive copy will need to be reseeded using the Update-StorageGroupCopy cmdlet in the Exchange Management Shell. So I can't move back the log files because the drive will fill up again but the reseed isn't working. Does anyone know what I need to do to get the CCR replication working again? Thanks, Kenny

How large is this database? Seems you have no option but to perform a full reseed of the entire database. Use the Update-StorageGroupCopy command with the DeleteExistingFiles option.Thank you, Ibrahim Benna MCSA+Messaging, MCSE+Messaging, MCT, MVP "Did you backup your Information Store Today?!"

I've already tried that. It finishes reseeding but none of the log files get copied. Just the database itself. And the status says Failed. If i suspend replication at that point the status says Suspended instead of Failed and that's where I see the huge number in CopyQueueLength. So it seems like it's still trying to replicate all the log files I moved even though I'm doing a full reseed. Thanks

What does the eseutil say about the current state of the database?

On the active node - Suspend the storage group - Dismount the database -Remove/Delete/move all the log files -Now mount the database -Restart the replication service on both the nodes Now from the passive node -Do a reseed of the database using 'delete existing files' option Thanks

Have you tried taking a full Exchange-aware backup on the active node? Did you move the log files in a supported manner? -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "Kas333" wrote in message news:46965705-8639-43c8-8589-c52193d6070e... The log drive for one of my storage groups ran out of space causing the database to dismount. In order to restore service as quickly as possible I moved all the logfiles before the checkpoint to a different location and was able to mount the database. Now, however, I am unable to get CCR replication working again for that storage group. I'm attempting to do a reseed but the logfiles are not copying so it's in a failed state. If I suspend replication and do get-storagegroupcopystatus it show 1315020 for CopyQueueLength for that storage group. In Event Viewer there is an error with Event ID 2059, MSExchangeRepl that says: Description: The log file 1278189 for Server2\SG2 is missing on the production copy. Continuous replication for this storage group is blocked. If you removed the log file, please replace it. If the log is lost, the passive copy will need to be reseeded using the Update-StorageGroupCopy cmdlet in the Exchange Management Shell. So I can't move back the log files because the drive will fill up again but the reseed isn't working. Does anyone know what I need to do to get the CCR replication working again? Thanks, Kenny Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

This is going to be the next thing I try. I have a case open with MS support. They had me disable SCR replication for the storage group in question and run a full backup but the log files are not truncating. So the next thing they want me to try is exactly what you said. I will have to wait till after business hours to try it, though,

Yes. We run full Exchange-aware backups nightly. However, for that SG the log files are not truncating even after a successful backup. We suspected that was because of SCR so I disabled SCR and ran another backup but still log files not truncating.

This solution worked. Thanks very much for the assistance. Kenny