Standby Continuous Replication (SCR) is a high availability feature that was introduced in Exchange 2007 SP1. This feature provides site resilience beside data availability; this means that if the data center at the main site fails, the service can be moved to the disaster recovery (DR) site.

When SCR is enabled for a storage group, a replication process is started between the source mailbox server and the target mailbox server. The source mailbox server can be a stand-alone mailbox server or a clustered mailbox server in a Single Copy Cluster (SCC) or a Cluster Continuous Replication (CCR) environment. The target mailbox server must be in the same Active Directory domain as the source mailbox server.

The storage groups for which you will enable replication should contain only one database, same as in Local Continuous Replication (LCR) and CCR enabled storage groups. Once the replication has been enabled you can't add a second database to the storage group. And those storage groups can't have Local Continuous Replication enabled.

The replication occurs every time a new log is generated on the source mailbox server. When the log file size reaches 1MB it is closed and a new file is created. The closed log file will be shipped to the target database to keep it updated.

In case of the source mailbox server failure, you have to manually failover to the SCR target mailbox server in the DR site.

Configuring SCR

To enable SCR for a storage group, the target server must have the same disk partitions as the source mailbox server i.e. if the logs for the source server storage group are stored at E:\Storage-Group-01\Logs and the database path is F:\Storage-Group-01\Database-01.edb then the target server should have the E: and F: drives to store the log files and the database at the same paths.

To enable standby continuous replication for a storage group, we will use the Exchange Management Shell (EMC). There are some commands that should be run on the target server like Restore-StorageGroupCopy command which we will see later and other commands can be run on both source and target servers. In this article I'll run the commands on the target mailbox server.

To enable replication use the command
Enable-StorageGroupCopy Tj-Ex1\Tj-Users -StandbyMachine Tj-SCR -ReplayLagTime 0.0:15:0 -TruncationLagTime 1.0:0:0

The ReplayLagTime parameter is used to define the time the Microsoft Exchange Replication service should wait before the copied log files are replayed to the target database. It is defined as Days.Hours:Minutes:Seconds. The default value is 24 hours. The database will not be created until the first 50 logs are created.

The TruncationLagTime parameter specifies the time the Microsoft Exchange Replication service waits before truncating the replayed log files.

After enabling the replication for a storage group, the ReplayLagTime and TruncationLagTime can't be changed. If a change is necessary, then disable and enable back the replication.
Disable-StorageGroupCopy Tj-Ex1\Tj-Users -StandbyMachine Tj-SCR

If we wait for some logs to be generated, we can check the health of the replication using the command shell. Replication health cannot be checked through the EMC
Get-StorageGroupCopyStatus Tj-Ex1\Tj-Users -StandbyMachine Tj-SCR

SummaryCopyStatus - Could be one of the following: Disabled, Failed, Seeding, Copying, Stopped, and Healthy.

CopyQueueLength - The number of logs that need to be copied to the target.

ReplayQueueLength - The number of copied logs that are waiting to be replayed.

LastInspectedLogTime - This is the timestamp for the log that the Replication Service last inspected successfully on the target server.

To check the health of all storage groups you can use the command:
Get-StorageGroup | Get-StorageGroupCopyStatus -StandbyMachine Tj-SCR

Also the command Test-ReplicationHealth can be used for this purpose:

Use it also with " -MonitoringContext $true " or " -MonitoringContext 1 " parameter to include replication monitoring events and performance counters:

Testing SCR

Now that we enabled and checked the replication health, we will test and move one of the databases to be mounted on the target server.

Create a test storage group with one database on the source mailbox server, in my example I'll create the storage group Tj-Users at E:\Storage-Group-01\Logs for logs and F:\Storage-Group-01 for the database.

Create a test mailbox, and send emails to it. Send emails with large attachments to quickly generate logs. As we already said, the database will only be created after the first 50 logs have been replicated to the target mailbox server.

Enable and test the replication for this storage group then follow these steps to mount the database at the target server:

1. Create a temporary Storage Groups on the SCR target server.

   New-StorageGroup -Name SCRTj-Users -Server Tj-SCR -LogFolderPath:"D:\SCR\SCRTj-Users" -SystemFolderPath:"D:\SCR\SCRTj-Users"

   

2. Create and dismount a temporary Database on the SCR target server.

   New-MailboxDatabase -StorageGroup "Tj-SCR\SCRTj-Users" -Name "SCRTj-scrDB" -EdbFilePath D:\SCRDBs\SCRTj-Users\SCRTj-scrDB.edb

   Dismount-Database SCRTj-Users\SCRTj-scrDB

   

3. Dismount the Source database (if the source server is available).

4. Activate the Storage Groups on the target server:

   Restore-StorageGroupCopy Tj-Ex1\Tj-Users -StandbyMachine Tj-SCR
   

   You may need to use the "-Force" parameter if the source server can't be contacted.

   Restore-StorageGroupCopy Tj-Ex1\Tj-Users -StandbyMachine Tj-SCR -Force

5. Check if the database is in a Clean Shutdown state:

   eseutil /mh F:\Storage-Group-01\Database-01.edb

   Note that the path is the same as the source database on the source server.

   

6. If the database is in a Dirty Shutdown state, then we need to fix it using the command:

   eseutil /r E08 /dF:\Storage-Group-01\Database-01.edb /lE:\Storage-Group-01\Logs

   

7. Check again if the database is in a Clean Shutdown state:

   eseutil /mh F:\Storage-Group-01\Database-01.edb

   

8. Set the paths of the storage group and the database on the target SCR server to the path of the replicated storage group and database:

   Move-StorageGroupPath Tj-SCR\SCRTj-Users -SystemFolderPath E:\Storage-Group-01\Logs -LogFolderPath E:\Storage-Group-01\Logs -ConfigurationOnly

   Move-DatabasePath Tj-SCR\SCRTj-Users\SCRTj-scrDB -EdbFilePath F:\Storage-Group-01\Database-01.edb -ConfigurationOnly

   

9. Allow the Databse to be restored

   Set-Mailboxdatabase Tj-SCR\SCRTj-Users\SCRTj-scrDB -AllowFileRestore:$true

10. Mount the Database on the Target SCR Server

    Mount-Database Tj-SCR\SCRTj-Users\SCRTj-scrDB

11. Move the Mailboxes configuration to the Database on the Target SCR server

    Get-Mailbox -Database Tj-Ex1\Tj-Users\Database-01 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase Tj-SCR\SCRTj-Users\SCRTj-scrDB

    

12. Replicate the Domain Controllers in both the mail and the DR sites.

Conclusion

In this article we went through a brief overview of SCR. We covered the basic requirements for the source and target servers, enabled and tested the replication between the source and target SCR servers. Finally we also tested moving the database and mounting it at the target SCR server.

References

TechNet: Standby Continuous Replication

TechNet: Managing Standby Continuous Replication