I’ve been doing a bit of work with SCR lately, the point being to achieve a “poor man’s failover” for the mailbox server role. Not everyone needs the immediacy, or the expense, of a cluster, and SCR was a welcome addition to the redundacy capabilities of Exchange 2007 – but I couldn’t find a complete step-by-step resource for failover and failback so, after having worked it all out myself, here it all is.
What SCR is, and isn’t
I am not going to rehash the SCR documentation – but I will add some observations of my own.
- SCR is not a cluster.
- SCR is a way of copying the mail databases to another server where they can be activated without too much fuss – though there is nothing instantaneous about it because it is not a cluster.
- SCR failover can be achieved through database portability or through setup /m:Recover.
- The setup option actually rebuilds your standby server as the primary so it is not a good choice if you expect the primary to be back in business at some point.
- Database portability is a better choice for most failover scenarios.
- Database portabilty should really be compared to restoring mail databases from backup rather than clustering (because remember, it’s not a cluster) – where it compares very favorably because:
- it’s a lot faster as the data is already there on the standby server, and doesn’t need to be restored off tape, and
- it’s a heck of a lot more up-to-date than a tape backup is likely to be.
- And finally – the failback takes a lot longer than the failover.
Preparing the Servers
Again all the information about setting up SCR is on technet here so I’m just going to add some description about the storage group config, which had not been immediately obvious to me. Let’s say you have storage group SG1 containing mailbox database MBX1 on SRV1. You want SRV2 to be able to mount the database in case of corruption on SRV1, or all out failure of SRV1. The logs and data locations are as follows:
| SG1 Logs | E:\Logs\SG1 |
| SG1 System | E:\Logs\SG1 |
| MBX1 Data | F:\Data\SG1 |
The first thing you have to do is create the exact same folders in the exact same paths on the target server – but just leave them empty.
The next thing you do, and this is not an immediately obvious step, is to create a placeholder storage group and mail database on SRV2. If the time comes to failover you will actually mount the database copy in this placeholder DB – but you can’t give it the same name as the original. Got that?
Following the example naming from technet, create storage group SG1PORT and mail database MBX1PORT on SRV2. Mount the db, just to check it works, and then dismount again.
Failover Steps
The time has come to move MBX1 to the standby server. These steps should be easily achievable in half an hour. It is assumed SRV1 is down, or at least the MBX1 database is not mounted on SRV1.
1. Prepare storage group for restore operation
Open the Exchange Management Shell on SRV2 and run the following commands.
Restore-StorageGroupCopy SRV1SG1 -StandbyMachine SRV2
Use the "-force" switch if the source server is down.
2. Repair database copy
Test current state of database copy. Look for “Clean Shutdown” or “Dirty Shutdown”.
eseutil /mh "F:DataSG1MBX1.edb"
Repair database if in “Dirty Shutdown” state. Replace n with the number on the log files in the Log folder.
eseutil /r E0n
Confirm “Clean Shutdown” state:
eseutil /mh "F:DataSG1MBX1.edb"
3. Move the folder locations of SG1PORT so they point to the SCR copied locations
Move-StorageGroupPath SRV2SG1PORT -SystemFolderPath "E:LogsSG1" -LogFolderPath "E:LogsSG1" -ConfigurationOnly Move-DatabasePath SRV2SG1PORTMBX1PORT -EdbFilePath "F:DataSG1MBX1.edb" -ConfigurationOnly
4. Set the databases to over-writable and Mount them
Set-MailboxDatabase SRV2SG1PORTMBX1PORT -AllowFileRestore:$true Mount-Database SRV2SG1PORTMBX1PORT
5. Change user homeMDB values to the new database locations
Get-Mailbox -Database SRV1SG1MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase SRV2SG1PORTMBX1PORT
Your users should now be able to re-access their mailboxes.
Failing Back
Now you have SRV1 back up and running and you want to move the mailbox database back. Unfortunately this is going to involve copying the entire EDB file while the mailbox database is dismounted. If the file is large, this could take a while.
Your alternative is to make SRV2 the new primary – but keep in mind that you will have to reconfigure SCR to work in the opposite direction.
If a manual reseed is required you’ll end up having to copy the EDB file anyway, so you won’t have saved yourself any downtime. The method for failing back is a straight forward database move.
1. Dismount the mail databases
Open the Exchange Management Shell on SRV2 and run the following commands.
Dismount-Database -Identity SRV1SG1MBX1 Dismount-Database -Identity SRV2SG1PORTMBX1PORT
2. Delete all logs from SRV1
Remove-Item -path "\SRV1E$LogsSG1*" -Recurse
3. Set the mail database on SRV1 to over-writable
Set-MailboxDatabase SRV1SG1MBX1 -AllowFileRestore:$true
4. Copy the EDB file from SRV2 to SRV1
Copy-Item -Path \SRV2F$DataSG1MBX1.edb -Destination \SRV1F$DataSG1MBX1.edb
5. Mount the mail database on SRV1
Mount-Database -Identity SRV1SG1MBX1
6. Change user homeMDB attributes back to SRV1
Get-Mailbox -Database SRV2SG1PORTMBX1PORT |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase SRV1SG1MBX1
The mail service is now restored, but you still need to get SCR working again.
7. Change SG1PORT back to original folders
Move-StorageGroupPath srv-exch2SG1PORT -SystemFolderPath "E:LogsSG1PORT" -LogFolderPath "E:LogsSG1PORT" -ConfigurationOnly Move-DatabasePath srv-exch2SG1PORTMBX1PORT -EdbFilePath "F:DataSG1PORTMBX1PORT.edb" -ConfigurationOnly
8. Clear out SG1 folders on SRV2
Remove-Item -Path "E:LogsSG1*" -Recurse Remove-Item -Path "F:DataSG1MBX1.edb"
You should now be able to re-enable the SCR replication from SRV1 to SRV2.
