Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
Topic Last Modified: 2008-10-21

Standby continuous replication (SCR) is a new feature introduced in Microsoft Exchange Server 2007 Service Pack 1 (SP1). As its name implies, SCR is designed for scenarios that use or enable the use of standby recovery servers. SCR extends the existing continuous replication features found in the release to manufacturing (RTM) version of Exchange Server 2007 and enables new data availability scenarios for Mailbox servers running SP1. SCR uses the same log shipping and replay technology used by local continuous replication (LCR) and cluster continuous replication (CCR) to provide added deployment options and configurations.

SCR enables a separation of high availability (comprised of service and data availability) and site resilience. For example, SCR can be combined with CCR to replicate storage groups locally in a primary datacenter (using CCR for high availability) and remotely in a secondary or backup datacenter (using SCR for site resilience). The secondary datacenter could contain a passive node in a failover cluster that hosts the SCR targets. This type of cluster is called a standby cluster because it does not contain any clustered mailbox servers, but it can be quickly provisioned with a replacement clustered mailbox server in a recovery scenario. If the primary datacenter fails or is otherwise lost, the SCR targets hosted in this standby cluster can be quickly activated on the standby cluster.

Sources and Targets

As with LCR and CCR, SCR uses the concept of active and passive copies of a storage group, but instead refers to them as sources and targets. Also, as with CCR, SCR requires that the database and log file paths be the same on the source and the target.

The starting point for SCR is called the source, which is any storage group on any of the following:

  • Stand-alone Mailbox server

  • Clustered mailbox server in a single copy cluster (SCC)

  • Clustered mailbox server in a CCR environment

    Note:
    Recovery storage groups cannot be enabled for SCR.

As with LCR and CCR, SCR-enabled storage groups cannot contain more than one database. You cannot enable SCR for a storage group that contains more than one database, and you cannot add a second or subsequent database to an SCR-enabled storage group.

If the SCR source computer is not clustered, it can also host other server roles, such as the Hub Transport, Client Access, and Unified Messaging server roles.

The endpoint for SCR is called the target, and the target can be either of the following:

  • Stand-alone Mailbox server that does not have LCR enabled for any storage groups

  • A standby cluster, which is a failover cluster where the Passive Clustered Mailbox role is installed, but no clustered mailbox server (e.g., no Active Clustered Mailbox role) has been installed in the cluster

An SCR target computer must have the Mailbox server role installed, even if it does not host production mailboxes. The Mailbox server role is required because it includes the Microsoft Exchange Replication service and other components necessary for SCR functionality. If the SCR target computer is not clustered, it can also host other server roles, such as the Hub Transport, Client Access, and Unified Messaging server roles.

SCR is available in the Standard Edition of Exchange 2007 SP1. If a Mailbox server in an SCC or CCR environment is used as the SCR source, the Enterprise Edition of Exchange 2007 SP1 is required because Enterprise Edition is required when clustering Exchange 2007. If a standby cluster is being used as the SCR target, the Enterprise Edition of Exchange 2007 SP1 is also required.

Comparing SCR with LCR and CCR

SCR is similar to LCR and CCR, but it has unique characteristics of its own:

  • SCR supports multiple replication targets per storage group. LCR and CCR support only one replication target per storage group (the passive copy).

  • SCR includes a built-in delay for replay activity, and it enables an administrator to specify an additional delay. This is useful in a variety of scenarios. For example, in the event of logical corruption of an active database, the built-in and additional administrator-configured delay could be used to prevent logical corruption of an SCR target database. LCR and CCR have no such delays.

  • SCR is completely managed using the Exchange Management Shell. The Exchange Management Console can be used to manage many aspects of LCR and CCR, but it cannot be used to enable or manage any aspects of SCR.

SCR Copy Activation

The process for using an SCR target database is called activation, and the way in which the database is activated depends on the nature of the failure. If one or some of the databases on the SCR source are affected, you can use the database portability feature in Exchange 2007 as part of the activation process for the SCR target databases. If all of the databases on an SCR source server are affected, or if an entire server or clustered mailbox server is being recovered, you can use Setup’s server recovery features (Setup /m:RecoverServer for a stand-alone server, and Setup /RecoverCMS for a clustered mailbox server) as part of the activation process.

Note:
If your recovery plans include using Setup /RecoverCMS to recover a clustered mailbox server (CCR or SCC) that has one or more storage groups enabled for SCR, you must first disable SCR for the storage groups before running Setup /RecoverCMS.

For more information about activation and recovery in an SCR environment, see Activating Standby Continuous Replication Targets.

SCR Deployment Scenarios

SCR enables you to use continuous replication to replicate Mailbox server data from a stand-alone Mailbox server, or from a clustered mailbox server in an SCC or in a CCR environment. The following figures illustrate a few of the possible SCR configuration options.


SCR from one stand-alone server to another

The preceding figure illustrates the use of SCR to replicate multiple storage groups from one Mailbox server to another Mailbox server. In this example, the Mailbox servers are not clustered and both are acting as SCR sources and targets. In this example, each server is located in a different data center and a different Active Directory site. Depending on the nature of the failure, recovery of a storage group on either server could be performed using database portability or the /RecoverServer Setup option.


Local CCR with remote SCR

The preceding figure illustrates a one-to-one CCR-to-SCR model. In this example, EXCLUS1 is a clustered mailbox server in a CCR environment that is located in Active Directory site REDMOND. EXCLUS1DR is a standby cluster located in Active Directory site QUINCY. In this case, recovery of all storage groups on the SCR target can be achieved by using the /RecoverCMS Setup switch. If not all of the storage groups need to be recovered, one or more storage groups can be recovered using database portability.


CCR replicating to local and multiple SCR targets

The preceding figure illustrates a one-to-many CCR-to-SCR model. The computers on the left side represent the two physical CCR nodes in the same datacenter. The computers on the right side represent two SCR targets in a second datacenter. In this example, a single storage group is being replicated to multiple SCR targets on two different computers. Recovery of the storage group on either SCR target can be achieved by using either of two methods:

  • /RecoverCMS can be used when recovering storage groups from a single CCR source only.

  • Database portability can be used when recovering storage groups from multiple CCR sources.


SCC with remote SCR target

The preceding figure illustrates a one-to-many SCC-to-SCR model. The computers on the left side represent the two physical SCC nodes in a single datacenter. The computers on the right side represent SCR targets in a separate datacenter. In this example, a single storage group is being replicated to two stand-alone targets in a second datacenter. Recovery of this storage group on the SCR target can be achieved by using the /RecoverCMS Setup switch.

Cmdlet Updates for SCR

SCR is managed using the Exchange Management Shell. SP1 includes a new parameter called StandbyMachine for several of the Exchange Management Shell cmdlets that are used to manage and configure continuous replication. Specifically, the following cmdlets now include support for SCR and the StandbyMachine parameter:

  • Suspend-StorageGroupCopy

  • Resume-StorageGroupCopy

  • Update-StorageGroupCopy

  • Restore-StorageGroupCopy

  • Get-StorageGroup

  • Get-StorageGroupCopyStatus

In addition to the preceding cmdlet updates, the New-StorageGroup and Enable-StorageGroupCopy cmdlets have been updated to support SCR. In Exchange 2007 SP1, you can use New-StorageGroup to create a new storage group that is enabled for SCR and Enable-StorageGroupCopy to enable SCR for an existing storage group. These cmdlets include the following updated parameters:

  • -StandbyMachine   This parameter specifies the name of the SCR target computer.

  • -ReplayLagTime   This parameter is used to specify the amount of time that the Microsoft Exchange Replication service should wait before replaying log files that have been copied to the SCR target computer. The format for this parameter is (Days.Hours:Minutes:Seconds). The default setting for this value is 24 hours (1.0:0:0). The maximum allowable setting for this value is 7 days. The minimum allowable setting is 0 seconds, although setting this value to 0 seconds effectively eliminates any delay in log replay activity above the default delay of 50 log files. After the value for this parameter is set, it cannot be changed without disabling and then enabling SCR.

  • -TruncationLagTime   This parameter is used to specify the amount of time that the Microsoft Exchange Replication service should wait before truncating log files that have been copied to the SCR target computer and replayed into the copy of the database. The time period begins after the log has been successfully replayed into the copy of the database. The format for this parameter is (Days.Hours:Minutes:Seconds). The maximum allowable setting for this value is 7 days. The minimum allowable setting is 0 seconds, although setting this value to 0 seconds effectively eliminates any delay in log truncation activity. After the value for this parameter is set, it cannot be changed without disabling and then enabling SCR.

In addition to the administrator-configured delay of replay that is specified using the ReplayLagTime parameter, Exchange will also prevent a fixed number of log files from being replayed on an SCR target, regardless of the value for ReplayLagTime using the formula Maximum of ("value of ReplayLagTime" or "X log files") where X=50. This is an additional safeguard against the need to reseed a storage group in situations when an SCR source that is in a continuous replication environment (for example, LCR or CCR) experiences a lossy failover and is brought online using the Restore-StorageGroupCopy cmdlet. By delaying replay activity on the SCR targets, when a lossy failover for an SCR source occurs, the chance of needing to reseed the SCR copies will be minimized because the nature of the data loss on the SCR source puts the two copies closer together in time.

Important:
The built in-replay lag of 50 log files and default time of 24 hours have implications for the creation of the initial SCR target database. An SCR target database will not be created until 50 transaction log files have been replicated to the SCR target computer and the time specified by ReplayLagTime (by default, 24 hours) has elapsed.

Setup Updates for SCR

SCR is designed largely for significant failures, such as a complete site failure. These types of failure scenarios involve manual activities, such as activation of a backup datacenter, as well as a move back to a primary datacenter.

Using the figure Using multiple remote SCR targets for an SCC earlier in this topic as an example, consider what happens when the primary datacenter (the site containing the SCC) fails, and the decision is made to activate the second datacenter as a replacement primary site. When the second datacenter is activated, the original datacenter configuration remains in Active Directory, and this configuration is used by the second datacenter after it has been activated. The clustered mailbox server configuration for the SCC also remains on the original cluster. For the original cluster to be brought back online, the clustered mailbox server configuration must be removed from the cluster nodes without affecting the clustered mailbox server configuration in Active Directory (which is being used by the second datacenter).

To facilitate this and other site resilience scenarios, Setup has been modified in Exchange 2007 SP1. Specifically, Setup includes a new command-line option called /ClearLocalCMS, which is used to clear the clustered mailbox server configuration information from the original cluster nodes without affecting the configuration information stored in Active Directory. For example, to clear the local configuration data for a clustered mailbox server named EXCLUS1, you would run the following command locally on each node in the original cluster from which you want to remove a clustered mailbox server:

Copy Code 
Setup /ClearLocalCMS

Be aware of the following requirements and restrictions when using the /ClearLocalCMS option:

  • This option can only be used locally; it cannot be used remotely.

  • This option can be used only on nodes that host a clustered mailbox server (for example, active nodes); it cannot be used on passive nodes.

  • This option does not remove the Microsoft Exchange program files, and it does not update any configuration information in Active Directory.

  • This option can be used only when the local clustered mailbox server is offline, and when the local node is not on the RedundantMachines list for the local clustered mailbox server.

  • The account used to clear the local clustered mailbox server configuration must be delegated Exchange Server Administrator permissions for the clustered mailbox server.

  • If the cluster nodes are running on Windows Server 2008, after you run Setup /ClearLocalCMS, the virtual computer object (VCO) will be disabled. You must re-enable the VCO.

For More Information

For more information about planning for SCR, see Planning for Standby Continuous Replication. For information about managing SCR, including detailed steps about how to enable or disable SCR for a storage group, see Managing Standby Continuous Replication.


Using multiple remote SCR targets for an SCC
Using CCR to replicate storage groups locally and SCR to replicate storage groups to multiple remote locations
Using CCR to replicate storage groups locally and SCR to replicate one storage group to a remote location
Using SCR to replicate a storage group from one stand-alone Mailbox server to another Mailbox server