Applies to: Exchange Server 2007 SP1 Topic Last Modified: 2008-06-19

Standby continuous replication (SCR), a new feature in Microsoft Exchange Server 2007 Service Pack 1 (SP1), enables you to use continuous replication to replicate Mailbox server data from a stand-alone Mailbox server, from a clustered mailbox server in a single copy cluster (SCC), or in a cluster continuous replication (CCR) environment.

As its name implies, SCR is designed for use in standby recovery scenarios. The process for activating copies of Mailbox server data that are created and maintained by SCR is manual, and it is designed to be used only when a significant failure occurs. SCR is not meant to be used for simple server outages that are recoverable by a restart or some other quick means. You can activate an SCR target using database portability, using the server recovery option (Setup /m:RecoverServer), or if the Mailbox server is clustered, using the clustered mailbox server recovery option (Setup /RecoverCMS). The option you choose will be based on your configuration and the type of failure that occurs. If the SCR source is a clustered mailbox server, the optimal target configuration would be a standby cluster. If the SCR source is a standalone Mailbox server, the optimal target configuration would be a standalone mailbox server. While there is no requirement to match the target configuration with the source configuration, using the same configuration can shorten your recovery time. For example, if the SCR source is a clustered mailbox server and the SCR target is a standalone mailbox server instead of a standby cluster, the full server recovery process takes longer. The reason for this is that a standalone Mailbox server has its own Mailbox server identity which must first be removed (by uninstalling Exchange) so that Setup /RecoverCMS can be run.

 SCR Activation and Recovery Scenarios

SCR is designed to enable datacenter-level recovery options and to complement the in-datacenter resiliency provided by local continuous replication (LCR), CCR, and SCC. 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).

For details about how to use SCR and a standby failover cluster in a site resilience scenario, see Standby Continuous Replication: Site Resilience with Standby Clustering. The scenario described in that topic details how an organization, Contoso, Ltd., is using SCR in a site resilience scenario. In this scenario, the primary datacenter fails and Contoso, Ltd. makes the decision to activate the secondary datacenter. After the secondary datacenter is activated, the primary datacenter is reconfigured and eventually restored as the primary datacenter in a controlled switch over.

For details about how to use SCR with database portability, see Standby Continuous Replication: Database Portability. The scenario described in that topic details how an organization, Woodgrove Bank, is using SCR and database portability to recover from a failure of a single database. In this scenario, an SCR source database is found to contain physical corruption and the administrator makes the decision to activate the SCR target database. During activation, SCR is disabled, the SCR target database is mounted as the production database, and user mailboxes are re-homed. After data access has been restored to clients, SCR is again enabled for the storage group to restore redundancy and protection for the SCR target.