Standby Continuous Replication in Exchange Server 2007 Service Pack 1

Standby continuous replication (SCR) is a new feature being introduced in Service Pack 1 for Microsoft Exchange Server 2007. As its name implies, SCR is designed for scenarios that use standby recovery servers. SCR extends the existing continuous replication features and enables new data availability scenarios for Exchange 2007 Mailbox servers. SCR uses the same log shipping and replay technology as local continuous replication (LCR) and cluster continuous replication (CCR) to provide added deployment options and configurations. SCR is very similar to LCR and CCR, but it has unique characteristics of its own:

  • SCR supports multiple 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 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 admin-configured delay could be used to prevent logical corruption of an SCR target database.
  • In the RTM version of Exchange 2007, rules are enforced so that in a continuous replication environment a log file is not deleted unless and until it has been backed up and replayed into the copy of the database. This rule is modified when using SCR. SCR (which introduces the concept of multiple database copies) allows log files to be truncated at the SCR source as soon as they are inspected by all SCR target machines. Log truncation at the SCR source server does not wait till all logs have been replayed into all SCR targets because SCR target copies can configured with large log replay lag times.
  • Unlike CCR and LCR, you cannot back up an SCR copy. When using SCR, the database headers for SCR copies are updated, and the log files are truncated, when supported backups are taken against the source storage group (or, in the case of LCR and CCR, when backups are taken against either the active or passive copies of the source storage group).

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 would be 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:

  • By using Restore-StorageGroupCopy, which will try to copy any missing log files from the SCR source, or
  • By using Setup /RecoverCMS to provision a replacement clustered mailbox server in the standby cluster.

SCR Sources and Targets

As with LCR and CCR, SCR uses the concept of active and passive copies of a storage group, and like CCR, SCR requires that the database and log files paths be the same on the source and the target. Because SCR extends the scenarios supported by LCR and CCR, SCR also introduces the concepts of sources and targets.

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

  • A standalone mailbox server (with or without LCR enabled).
  • A clustered mailbox server in a single copy cluster.
  • A clustered mailbox server in a CCR environment.

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.

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

  • A standalone mailbox server (without LCR enabled for any storage groups)
  • A node in a failover cluster where the Mailbox role is installed, but no clustered mailbox server has been configured in the cluster.

A source can have multiple targets. For example, a source could have one target that exists in the same datacenter as the source, and a second target that exists in a separate datacenter. There is no limit to the number of targets you can have for each source; however, we recommend using no more than four targets per source. Impact to the source server needs to be verified and planned for accordingly if more than four targets are configured.

Requirements for SCR Targets

Target machines must be in the same Active Directory domain, but they can be located in the same or in different Active Directory Sites.

Each target can have multiple source servers. Both the source and the target system must be running Service Pack 1 for Exchange 2007. The operating system can be any operating system supported by Service Pack 1 for Exchange 2007.The database and log file paths on the source and all of its targets must match for each storage group being replicated with SCR. If both paths, including drive letter(s), do not match, you will not be able to enable SCR.

When a node or a server is configured as an SCR target these capabilities are blocked:

  • A target that is a standalone Mailbox server cannot have LCR enabled for any storage groups (the Microsoft Exchange Replication service has not been designed or modified to handle managing local replication and replication from another source when the Mailbox server is also using LCR).
  • A target that is a passive node must be a member of a cluster that does not have any clustered mailbox servers.

In my next blog entry, I’ll talk about SCR target activation, as well as the cmdlets and processes used to set up, configure, and monitor SCR.

Scott Schnoll

Comments (36)
  1. lee says:

    Neat stuff.  This will allow a lot of new redundancy scenarios.  Very cool.  Sign me up for a webcast!

  2. Dave Stork says:

    Very exciting feature!

    It is not specified whether this will be available in the Standard and/or Enterprise Edition. Could you clarify this?

  3. Scott says:

    Dave, we’ll be communicating licensing details later this year as we approach RTM of SP1.

  4. bday says:

    This is great news!! It is exactly what we were hoping for. Now you have me salvating at the mouth even more waiting to hear about Running Exch 2007 on Server 2008 and clustering nodes without having to be on the same subnet anymore!

  5. Brian says:

    Can you clarify the target options for a cluster?  I’m not making the distinction between a failover cluster with the mailbox role installed, and no mailbox cluster configured… i.e. this line:

    A node in a failover cluster where the Mailbox role is installed, but no clustered mailbox server has been configured in the cluster.

    I know I’m misunderstanding something but these sound like the same thing to me…


  6. Lily Cui says:

    Very exciting stuff, and an excellent blog!  I cannot wait to see your next blog entry on how to activate the SCR.  By the way, is there a doc or help file that I can follow and try it in my environment?  I am eager to try SCR in my data center.

  7. Scott says:

    Brian: When you install Exchange 2007 into a Windows failover cluster, there are two roles that can be installed: one is the Mailbox server role, and the other is the Active Clustered Mailbox Server (CMS) role.  Only the Active node gets both roles installed. The passive node only gets the Mailbox role installed.  Thus, a CMS is always and only created and only exists on the Active node.  Note, though, that this does not prevent a Passive node from becoming an Active node, and you don’t need to install the CMS role on a Passive node.  This role distinction is only so Setup can install the role you want to install (e.g., Active vs. Passive).

    So what we’re saying with an SCR target is that you can only have the Passive role (e.g., only the Mailbox role) installed.  You cannot have a CMS in the cluster. If you imagine a two-node cluster then, basically what you’re doing is installing the Passive role on both nodes.  You don’t install the Active role because a failover cluster that is configured as an SCR target cannot contain a CMS.

  8. Scott says:

    Lily: SCR is not yet in the Beta of SP1, but it is expected to be in Beta 2 (along with rich documentation on how to use the feature in a variety of scenarios).

  9. Lily Cui says:

    Hi Scott,

    I think SCR fan-in and fan-out feature is fabulous.  One source can have multiple targets and one target can also have multiple sources!

    But with the target requirement: "If both paths, including drive letter(s), do not match, you will not be able to enable SCR".  In a larger organization with multiple Exchange servers in different data center, usually the data/log path, drive letters are standardized, such as: drive L for log files, drive M for EDB files, etc…  If I have 5 Exchange servers are sources and one Exchange server is a target in my DR data center, how should I map the drive letter?  Should I use mounting-point to solve this problem?

    Thank you very much for your help!


  10. Chris says:

    Fantastic news…

    Is there a target date yet for Beta 2?

  11. Scott says:

    Lily: You may very well find that mount points will work best here.  In addition, you may need to move the locations of some existing files in case you want SCR sources that are configured with identical or standardized paths using the same SCR target. Obviously, some additional planning will need to take place to make sure that you don’t run into any path collisions or an inability to use a server as an SCR target because the needed path is already in use.

    Chris: Yes, we’re targeting Q3 of this year for Beta 2.

  12. Sean says:

    With regard to a target having multiple sources:

    a.) i imagine we would want to fullyqualify Storagegroup folder structure to avoid collisions, for example:


       Each source server could have:


       And the target could host:




        does this look correct in any way ?

    b.)  does recovery of a DB to an SCR target entail modifying user’s

    AD attributes:  homemdb,homemta,msExchHomeServerName , similar to

    other asynch failover methodolgies ?


  13. Mohd El-Z says:

    Can you describe the fallback ?

    In that case you need a full reseed ? or can you leverage backups ?

    Can you do it without outage ?

  14. yasin says:

    Excellent post.

    So in a SCC cluster at the production site as the source, using SCR to a DR site onto standalone Exchange Servers with M/B, CAS, HUB co-located should be possible.

    Has there been any large scale testing between CCR Mailbox Server v’s M/B-CAS-HUB colocated ?

    When are you planning on for your next blog on this :) ?


  15. Scott says:

    Sean: For the paths, that is one way to prevent name/path collisions.  You might also want to combine that method with volume mount points so that you don’t have multiple databases or log streams from multiple storage groups on the same physical disk.  As for activation of an SCR target, that is a manual process that involves using either Exchange 2007’s database portability feature, or using Setup with one of the recovery switches: /m:RecoverServer if recovering a standalone server, or /RecoverCMS if recovering a clustered mailbox server.

    Moha: There is no fallback in SCR, as fallback is a cluster term and SCR is not a clustered solution.  Although you can use SCR to replicate data from a SCC and CCR, SCR does not require clustering.

    Yasin: Yes, you can use SCR to replicate data from a clustered mailbox server in a single copy cluster to a Mailbox server in another Site. As for testing, like the work on SP1 itself, testing in labs and in MSIT’s environment is still underway, and it does include testing of CCR+SCR and well as standalone Mailbox servers+SCR.

  16. nseslija says:

    Great feature!

    I just want to ask, is it possible to have SCR environment with only two Exchange 2007 servers on two locations.

    Thank you!

  17. Ian Murphy says:

    Don’t forget to add something on how the failover will actually occur. Does SCR update active directory to ‘repoint’ the users outlook to the replica when the main server is inactivated or is this left up to the admin?

    Seems incredible but mailbox replication and automatic failover to another server was standard in Notes over 15 years ago.

    C’mon guys. If I can maintain two copies of outlook open with replicas uploading and downloading changes why can’t Exchange do the same but between two servers. Let me connect to either of the servers. If one fails I can use the other. And don’t say clustering.

    Building resilient exchange is more of a cross your fingers and hope it never goes wrong.

  18. Scott says:

    nseslijia: Both servers would have to be running the Client Access, Hub Transport, and Mailbox server roles.  You need two Mailbox servers to do SCR between them, and if these are your only two servers, they also need to run CAS and Hub because those roles are required for the Mailbox role.

    Ian: I plan on talking about SCR target activation in an upcoming blog.  There is not failover, though, as failover is a cluster term, and SCR does not require or depend on clustering. Activation is done using database portability or one of the recovery options with Setup.

  19. one last clarification... says:

    if you use recoverserver or recovercms, how can you have an SCR target failover for multiple sources ?

  20. mornlee says:


    The 32-bit event sink (server COM+) works fine in Exchange 2003(32-bit). It’s developed with .net 2.0(32-bit).

    Could the 32-bit event sink (server COM+) migrate to Exchange 2007(64-bit) without any modification?  

    Thanks & Regards,

  21. George says:

    so a target can also be a source and a source can also be a target at the same time? I am thinking about a scenario with two mailbox servers that replicate their productive data x-over to each other. You would have sort of a "manual CCR" without a "idle" passive node … (of course you would have to calculate with doubled performance needs – in the moment you mount the SCR DB on the target).

  22. johanz says:


    Seeking clarification of the question of nseslija.

    SO if I install all roles on the two servers I can do SCR between two locations on only two servers ?

  23. JeremyD says:

    With Beta 2 targeted for Q3 and Server 2008 coming out next February, is Exchange 2007 SP1 also slated for next February?  A previous EHLO blog mentioned tying in the SP1 release with Longhorn.

  24. SimonH says:

    So I will be able to have a Single Copy Cluster (aka ex2003 clustering) which I will be able to fail back and forth whilst maintaining a SCR target on another server incase the whole Single copy cluster fails? This would be cool… so long as its not a difficult/complex/extended process to enable the SCR copy and to move back to the SCC. The problem we always have in this situation is, if its not easy to switch to DR(SCR) and then back to Live(SCC) it never gets done and the downtime is inevitable unless the building blows up.

  25. Lily Cui says:

    Hi Scott,

    How does SCR get the logs from the active node of CCR?  Does SCR use the replication service to pull the logs from the shared log directory of Active node (same as the passive node does the logs)?

    When we can see your next Blog?  I am eager to try activation the SCR node  on my remote data center.

    Thank you very much for your help!


  26. klstclair says:


    Based on the statement "SCR includes a built-in delay for replay activity, and allows 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 admin-configured delay could be used to prevent logical corruption of an SCR target database."

    Is the prevention of corruption a distinct advantage of SCR only due to the delayed writes on the target database?

    Does the replication mechanism in CCR/LCR also prevent the replication of logical corruption to the copies of the database as well?

    Thank you,


  27. Jacob says:

    Hi Scott,

    Will an SCR target activation require Outlook 2007 to work or will an Outlook 2003 client be able to handle this as well? How easy is it to go from single servers with one or more roles to a SCR configuration? Can we start without SCR and later add a server and enable SCR between those them? For CCR implementations it seems a choice during installation, is that the same for SCR?



  28. DaSS_UK1 says:

    Hi Scott,

    There is mention of a delay extension to prevent corruption from being written to the target (through manual intervention). Does it not follow a similar or the same process used by LCR, in such, it is dropped into an ‘inspection’ folder and verified? What does this verication involve? eseutil? If that is the case, I will assume the only corruption would be the actual write to the target?

    thanks in advance


  29. klstclair says:


    When using a CCR cluster as the source for SCR, is it possible to select a particulat node as the target and what is the impact to this node?

    When using SCR to replicate a CCR cluster, it the target required to also be a CCR cluster or can it be a stand-alone server?

    Thank you,


  30. klstclair says:


    My apologies, I meant to ask… "When using a CCR cluster as the source for SCR, is it possible to select a particular node as the SOURCE and what is the impact to this node?"


  31. VicW says:

    Is it possible to have 2 servers replicating to a single standby server in another location, and fail BOTH primary servers? As in a disaster scenario?

  32. Greggblue says:


    Let’s say I have a 3+1 single-copy cluster at a remote site, and I have a 4 passive node cluster at a remote site. Could I have SCR enabled for each of the active servers and replicate via SCR to the remote site on the 3 passive nodes with the mailbox server role? Then, if there’s a disaster, run the recover CMS to make the remote servers active? And have a 3+1 enabled remotely?



  33. HH says:

    SCR smells like NSI’s double-take. Even double-take calls the server’s source and target. Double-take does failover AD attributes automatically on source failure though. Also once the source is back up failback to it can be performed.

  34. Eggy says:

    Scott — Thanks for this info.  I’m very interested in SCR.

    In your original post you mentioned "In my next blog entry, I’ll talk about SCR…".  Did I miss that post?  Or is it still ‘in the works’?  If it’s out there somewhere please point me to it.



  35. Donald says:

    Why does the target have to be in the same AD Domain?

  36. swiss says:

    I like the CCR and SCR. The SCR because you don’t need a high tech cluster which brings more work with it. And in allmost all companys i have seen cluster usage they had fallouts because of a) people not knowing what they do with clusters b) Got so complex that only the guy who built it knew how to change => So at the end they had more downtime since they had put everything to high avaibility.

    Something i still don’t understand: If someone uses SCR in the same Site. How does this company restore a single mailbox or E-Mail without having the usage of the Restore Storage Group?

Comments are closed.