Exchange 2007 Failover and Failback with SCR

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.

About: Carol

I've been doing IT for 30 years, and IdM for 15. I live in Australia and build IdM solutions based on Microsoft Identity Manager. I also play the violin, but that doesn't help much with the IdM solutions.