Project Coconut: Part 4 – Configuring Standby Continuous Replication

Project Coconut Entries:

• Part 1 – Getting the environment up to scratch
• Part 2 – Sizing the Exchange Server 2007 servers
• Part 3 – Deploying the first Exchange Server 2007 server
• Part 4 – Configuring Standby Continuous Replication
• Part 5 – Its mailbox migration time!
• Part 6 – Finishing the job

Project Coconut, now with even more blown deadlines!

What is Standby Continuous Replication?

Standby Continuous Replication (SCR) is a great new feature of Exchange Server 2007 SP1. SCR is basically a way to maintain an up to date replica of your storage groups and mailbox databases on a second server in case of a disaster. Typically this would be a server in a DR site somewhere in your network.

You can also use it to host replicas for multiple mailbox servers around your network, providing a single shared standby server.

SCR uses the same transaction log shipping and replay that is used in Local Continuous Replication and Cluster Continuous Replication. Each time a transaction log is written and closed off (they are each 1mb in size) it is copied to the standby server and then replayed into the standby database. If you are considering using SCR in your own environment here are a few planning points:

• SCR is available in both Standard Edition and Enterprise Edition of Exchange Server 2007 SP1.
• SCR is available in both clustered and non-clustered Mailbox Servers (this applies to both the source and the target server).
• The target server must be installed with the Mailbox Server role and have the same disk layout as the source server for a given storage group replica. For example if a storage group is configured to use L:SG1Logs for logging and H:SG1Data for the database, these paths must be available on the target server. You should also ensure that equivalent disk space is provisioned on the target server.
• Unlike CCR and LCR you cannot use a the passive database copy on an SCR target server to run your backups.
• An SCR source server can have more than one target, and an SCR target server can be the target for more than one source server.
• SCR can effect your backups.

How to configure Standby Continuous Replication

To demonstrate SCR I have two Exchange Server 2007 servers running in the lab.

• LABEX2 – member server running Exchange Server 2007 Client Access, Hub Transport, and Mailbox Server roles. This will be the SCR source server.
• LABDC1 – domain controller running Exchange Server 2007 Mailbox Server role. This will be the SCR target server. After installing the server I deleted the default Storage Group and Mailbox Database as they are not needed. Note: in a production environment I wouldn’t recommend using a domain controller for this.

Note the Storage Group and Mailbox Database folder paths on LABEX2. These folders must be available (the system will create them itself) for SCR to use on LABDC1. If the drive letter does not exist on the target server, or the folder path is in use already, then SCR will fail.

[PS] C:\>Get-StorageGroup -Server LABEX2 | fl name, systemfolderpath, logfolderp
ath

Name             : First Storage Group
SystemFolderPath : C:FSGLog
LogFolderPath    : C:FSGLog

[PS] C:\>Get-MailboxDatabase -Server LABEX2 | fl name, edbfilepath

Name        : Mailbox Database
EdbFilePath : C:FSGDataMailbox Database.edb

When enabling SCR, the first of the commands can be run from either the source or target server, but the remainder must be run on the target server. For that reason it is easier to just run all of the commands on the target server.

First we enable replication.

[PS] C:\>Enable-StorageGroupCopy "LABEX2First Storage Group" -StandbyMachine LA
BDC1

If we take a look at the status of SCR at this time we can see that First Storage Group has changed from “Not Configured” to “Disabled”.

[PS] C:\>Get-StorageGroupCopyStatus -Server LABEX2 -StandbyMachine LABDC1

Name                      SummaryCopySt CopyQueueLeng ReplayQueueL LastInspecte
                          atus          th            ength        dLogTime
----                      ------------- ------------- ------------ ------------
First Storage Group       Disabled      0             0
Second Storage Group      NotConfigured 0             0

When SCR is first enabled it does not immediately generate the target database. There is a delay of 50 transaction logs which must first be shipped to the target server. These will then not replay until the “ReplayLagTime” interval has elapsed, which by default is 24 hours.

To speed up the process of creating the SCR replica on the target server you can manually seed the replica.

[PS] C:\>Suspend-StorageGroupCopy "LABEX2First Storage Group" -StandbyMachine L
ABDC1

Confirm
Are you sure you want to perform this action?
Suspending Storage Group Copy "First Storage Group".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is "Y"):y

[PS] C:\>Update-StorageGroupCopy "LABEX2First Storage Group" -StandbyMachine LA
BDC1

[PS] C:\>Resume-StorageGroupCopy "LABEX2First Storage Group" -StandbyMachine LA
BDC1

The Update-StorageGroupCopy operation can take some time if the number of transaction logs and the size of the database are large, particularly if the seeding is occurring over a slower WAN link. Keep this in mind when seeding your SCR target servers.

Maintaining Standby Continuous Replication

When an Exchange Server 2007 server is an SCR target you cannot backup the replicated databases. These can only be backed up on the source server. Therefore if the SCR target server is not performing any other roles in your Exchange organisation then you only need to perform backups of the operating system and system state. In some cases you don’t need to backup anything at all, as Exchange Server 2007 has excellent restoration procedures for recovering a failed server with its full configuration intact (as this is stored in Active Directory, not on the server itself).

However, because of the potential impact on your normal Exchange backups, it is important to monitor the health of Standby Continuous Replication. At the very least you should use Get-StorageGroupCopyStatus to check the health of each Storage Group’s replication, and monitor the SCR target server for MSExchangeRepl warning or error events in the Application Log.

In the next part of Project Coconut I’ll demonstrate a few shell commands to help with the migration of mailboxes to the new Exchange Server 2007 server.