WinDeveloper O365 Mailer FREE for 1 Year

WinDeveloper IMF Tune
WinDeveloper IMF Tune

Exchange 2007 Standby Continuous Replication - Configuration & Testing

Tariq M. Jaber [MCSE 2003, MCTS (ISA 2006, Exchange 2007)]

Tariq M. Jaber [MCSE 2003, MCTS (ISA 2006, Exchange 2007)] Photo

Tariq is a senior Microsoft Systems Engineer. He implemented several Microsoft infrastructure projects for various major companies. He is now focusing on Active Directory and Exchange server administration and implementation.

Cast your Vote
Poor Excellent

In this article we will explain Standby Continuous Replication (SCR); an overview, how it works and how to enable it. We finally test SCR by moving the Exchange service to the disaster recovery (DR) site.

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:


User Comments - Page 1 of 1

RAPel 12 Jul 2016 19:14
simply: you cannot . powershell only.
Sudhir 23 Sep 2013 00:56
how to do these procedure via UI instaed of powershell?
Copyright © 2005 - 2024 All rights reserved. is not affiliated with Microsoft Corporation