Using Standby Continuous Replication in both single node cluster implementation and database portability implementation when only a single machine is available.

Last week I received an interesting question from one of our Exchange MVPs.

“Can I use a single node cluster as an SCR target for both recovering the entire cluster or recovering just a single database?”

My original thoughts on this was no…when implementing SCR you have to make a choice. Are you implementing a single node cluster target where you would recover the entire cluster or are you implementing a standalone mailbox server target where you would use database portability.

The more I thought about this, the more I determined that YES, there is a way to have your cake and eat it to when you only have a single machine to act as the SCR target. Let me explain…

Since we are talking about using a single node cluster as the SCR target that means that we have some form of cluster source, either SCC or CCR.

In the event that you were to loose the entire source cluster, you would activate the SCR target by:

Running restore-storagegroupcopy –standbymachine <NODE>
Running setup.com /recoverCMS /cmsName:<NAME> /cmsIPAddress:<IP>
Mounting the databases.

Now the question becomes, how can I use this single node cluster in order to recover just a single database – ie using the database portability recovery method.

In this case the first thing we need to do is identify the database or databases that we wish to recover to the SCR target. These databases would have to be dismounted on the source server if they were not already. We would then run restore-storagegroup –standbymachine on these database instances.

The databases that have been ported to this machine are not in a “clean shutdown” state. At this time I recommend that we bring the databases to a clean shutdown state. To perform this operation:

Open a command prompt.
Run the following command –> eseutil /r <LOGPREFIX> /l <LOG PATH> /s <CHECKPOINT PATH> /d <DATABASE PATH>

Assume the following:

The log files and checkpoint file are located at x:\SG3
The database files are located at y:\SG3
The log prefix is E02 (the first 3 letters of a log file).
The command would be eseutil /r E02 /l “x:\SG3” /s “x:\SG3” /d “y:\SG3”

If you had to use the –force switch with restore-storagegroupcopy, this means that all logs could not be copied over. In this case you would run eseutil /r E02 /l “x:\SG3” /s “x:\SG3” /d “y:\SG3” /a (note the addition of /a) given the above example. Some situations where you would have to use –force might include network failures preventing the copy from proceeding successfully, corrupted log files on the source, or missing log files / database on the source.

When this is completed all SCR replication to the target must be disabled. The reason for this is that an active CMS (we’ll get to this later) cannot also be a target for SCR replication. To disable SCR in bulk consider running get-storagegroup –server <SOURCE> | disable-storagegroupcopy –standbymachine <TARGET>. Because this command modifies an AD attribute, we will need to take sometime here to allow for AD replication to converge and for the replication services to detect this change and discontinue the replication instances. (Note: The disable command will fail on the storage groups where you ran restore-storagegroupcopy -standbymachine. When running restore-storagegroupcopy –standbymachine on a database enabled for SCR it is automatically disabled for SCR when the command restore command completes successfully.)

So at this point what we have accomplished is to have all databases and logs necessary for recovery of the desired database instances present on the SCR target and all other replica instances disabled to that same target. We can now continue with the recovery.

Since the SCR target in this case is running the passive node installation of Exchange, it cannot be made into a standalone mailbox server without uninstalling Exchange. In this case that’s fine, we are going to create a single node active CMS. In order to create the active CMS, we will run setup.com /newCMS /cmsName:<NAME> /cmsIPAddress:<IP>. This setup command gives us a single node CCR cluster. Please note that cluster type does not matter here since we are assuming that we will always be using a SINGLE NODE cluster. In essence what we have done here is created a new Exchange server in the environment.

To take stock of where we are at now…we now have a single node cluster with X number of databases that are fully recovered and in a clean shutdown state. We now need to mount these databases.

To mount these databases:

Create a storage group for each database that was restored. DO NOT use the same paths as the restored databases.
Create a new mailbox database in each of these storage groups to correspond to the restored databases. DO NOT use the same database paths as the restored databases. DO NOT mount the databases (thus creating a blank database).
- If the mount database option is accidentally selected, the database must be dismounted before continuing.
Run move-storagegrouppath –identity <NewSG> –logfilePath:<RestoredLogPath> –systemfilePath:<RestoredCheckpointPath> –configurationOnly:$TRUE
Run move-databasepath –identity <NewDB> –edbFilePath:”<RestoredDBPath\DBName.edb>” -configurationOnly:$TRUE. [You will need to use the same *.edb name as the database on disk]
Run get-mailboxdatabase –server <NewCMS> | set-mailboxdatabase –AllowFileRestore:$TRUE
Run get-mailboxdatabase –server <NewCMS> | mount-database

This should mount the databases that were restored.

The finishing steps are to rehome the users to the restored databases. To perform this step:

Get-Mailbox –Database:“<OriginalServer>\<SGName>\<DatabaseName>” | where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'} | Move-Mailbox -ConfigurationOnly –TargetDatabase: “<NewCMS>\<NewSG>\<RestoredDatabaseName>”

Please note the following:

When using /recoverCMS the source cluster can be cleared and it’s nodes re-subscribed as an SCR target.
If following these instructions to implement database portability, the original clustered nodes that are running the other databases are ineligible to be SCR targets since there is an active CMS. Moving back to the original cluster could possibly mean moving all mailboxes back using the move mailbox process.
Using this approach to recover a single database means disabling replication for all other databases. This may have an impact on your overall disaster recovery design and planning.
Depending on replayLagTimes of the SCR target there could be a large delta of logs to be recovered before the database can be mounted. Planning for activation must include the time to copy delta logs as well as relay all outstanding log files.
If using a cluster source consider using CCR for maintaining database availability and using SCR for disaster recoveries.
Using move-mailbox –configurationOnly causes multiple changes to be committed to the active directory as well as client profiles changes. Please consider this also in the overall time to recovery.