We are running an Exchange 2007, SP1, CCR.We had a hardware issue (SAN Hard drives) on what was the Active Node of the CCR over the weekend. What was the passive node is now the Active Node.The hard drives of the now passive CCR server are nowback online, but the CCR is saying Copy Status Failed. When I run Get-StorageGroupCopyStatus the SummaryCopyStatus for the First Storage Group is "Failed."Based on what I have read, I am leaning towards performing a manual reseed tonight. My plan is as follows:1. Dismount the Database.2. Suspend Replication on the dismounted database.3. Copy the Database File (.edb) from the Active node to a USB drive.4. Transport the USB drive to our other site and copy the Database file (.edb) that was copied from the Active node (step 3 above) to the passive node.5. Mount the database6. Verify that the Copy Status is now no longer in a failed state.I am leaning towards the USB drive due to the size of the DB and the link speed between the two sites involved in the CCR.I continue to research this approach, and others, and would appreciate any thoughts you might have on this.TIA

Anything in the event logs? If you do a seed of the passive node, no need to wait for off hours, you can do it during production hours, but I'm wondering why link speed is a concern? CCR assumes WAN level bandwidth between nodes.More on seeding:http://technet.microsoft.com/en-us/library/bb124706.aspx

We have decent speed between the two sites, but I just figured it would be faster to copy the DB file (100+ GB) to a USB drive than to reseed over a WAN link as I understand it, a reseed copies the entire DB over the wire, which could take a while.

As for the Event Logs, the now Passive node (where the hard drive problem occured) is getting a lot of 2070 errors. Seems unhappy about a missing log file. File check failed : Logfile 'D:\Program Files\Microsoft\Exchange\Logfiles\E0000000001.log' was not found.

Yep, the copy of the edb and logs will take a bit. But then again, so will copying to the USB and back to disk - and manually copying will require downtime of course. Something a standard reseed doesnt require.The last time I had to do this, it was about 90 minutes for a 70GB store.

Andy, Thanks for your time and comments. I am a little hesitent to perform a standard reseed as I tried that yesterday during non production hours and it caused mail services to go down. Perhaps the passive node somehow became the active node during that process, and when that occured, email became unavailable. Also - the reseed failed with the following:Error:Seeding Failed: Database seeding error: An unexpected error has occured. Error Code (0x6ba). It failed 36 minutes into the reseed process.Going to Google the above error now. Not sure why it failed right now.We are in production hours now, so I am not sure I want to risk a Standard Reseed after what occured yesterday.

Have you gotten a full backup of the now active node since the failure?

No, I haven't. I getting a backup last night of the Exchange Information stores. One of the storage groups was backed up, but the one we are having trouble with was not backed up successfully.

I would get a backup before proceeding, even if you have to use something like ntbackup.

Planning on getting a backup before I do anything else. Thanks.

So I got a backup using NTBackup and performed a standard reseed.Everything seemed to be going fine. Now I amhunting for a powershell cmd to show me thestatus of the process. I lost my RDP session into the passive node.

Problem is resolved. Reseed worked fine after replacing some fixing a router related issue that was causing problems with the reseeding process.