Exchange 2007 CCR failback – When everything goes wrong … A survival guide
Sometimes, after having done a failover on our Exchange 2007 CCR, we might notice that failback to the original node is not working. In a separate post, I will detail what could go wrong and why.
But for now, I am publishing this little recipe of cmdlets that allows us to failback gracefully, without having to search all over Internet.
1- Start doing a Test-replicationHealth –MonitoringContext:$true
2- Look at the SGCopyFailed parameter. Many times it will indicate a FAILED status
3- Do a Get-ClusteredMailboxServerStatus |fl to get an overview of the status of the Cluster. This is detailed equivalent of what we have as a status from the EMC.
4- Check the SG status for replication : Get-StorageGroupCopyStatus –identity CMS-SERVER\SG1-MB |fl
5- Re-Check the SG configuration : Get-StorageGroup |fl
6- In order to initiate a manual seeding, suspend the replication with : Suspend-StorageGroupCopy –identity CMS-SERVER\SG1-MB |fl
7- Once replication is suspended, we can initiate the seeding :Update-StorageGroupCopy –identity CMS-SERVER\SG1-MB |fl
8- We might get the error saying that we need to delete existing files for the complete re-seeding : we the redo the command Update-StorageGroupCopy –identity CMS-SERVER\SG1-MB |fl –DeleteExistingFiles
9- Seeding starts
10- Once the seeding is complete, we have to restart the replication : Resume-StorageGroupCopy –identity CMS-SERVER\SG1-MB |fl
11- Re-check the replication status done at #4 (Get-StorageGroupCopyStatus). It should say HEALTHY.
12- We can now re-try the failback again: Move-ClusteredMailboxServer –identity CMS-SERVER –TargetMachine Node1 –MoveComment “Finally, we can move back to active”.
NOTE : If we are working with ALL SG instead of just one, we will use PIPING. Here a few examples :
Get-StorageGroup –server CMS-SERVER | Suspend-StorageGroupCopy will suspend ALL SG replication.
Leave a Reply