Microsoft added standby continuous replication (SCR) to its solutions in Exchange Server 2007 Service Pack 1 (SP1). SCR works similarly to local continuous replication (LCR) and cluster continuous replication (CCR) but has some limitations, such as a lack of support for automatic failover. Get an understanding of how standby continuous replication works within your Exchange environment and how to properly plan an SCR deployment.
Microsoft Exchange Server 2007 brought with it several new features, including local continuous replication and cluster continuous replication. These features use log shipping to store a secondary copy of the Exchange server database in an alternate location. That way, the server can be recovered quickly by retrieving data from the database replica in the event of a catastrophic failure.
Although LCR and CCR are great features, Microsoft went a step further in Exchange Server 2007 SP1 with standby continuous replication, which works similarly to LCR and CCR, but has some additional capabilities. SCR overcomes some of the limits of LCR and CCR. It may be tempting to begin using SCR immediately, but you should be aware of its significant limitations and restrictions. That's why it's crucial to properly plan an SCR deployment.
LCR requires that database replicas are stored locally; CCR lets you store database replicas on a different server that must exist in the same subnet as the primary database server. With this, you can have only one replica.
SCR allows your primary mailbox server (source) to replicate its database to multiple standby servers (targets). These target servers can exist on your LAN, but that isn't necessary. The subnet limitation doesn't apply to SCR.
The first SCR limitation to be aware of is that, like LCR and CCR, SCR works by replicating an individual storage group. However, you can't replicate any storage group. Recovery storage groups are not supported, and the storage group that...
To continue reading for free, register below or login
To read more you must become a member of SearchExchange.com
you're replicating can't contain more than one database.
While there is no limitation to the number of targets that a source storage group can be replicated to, Microsoft recommends that you limit the process to no more than four targets.
SCR and server roles
Although Microsoft recommends using a dedicated Exchange Server to host each server role, many companies choose to host multiple roles on a server because they lack the budget for a fully distributed deployment or they don't have enough users to justify having dedicated servers for each role. Because hosting multiple roles on a single Exchange Server is a common practice, it's important to understand how server roles work when SCR is implemented.
The roles that an SCR source server can host vary, depending on whether or not the server is clustered. If the source server is clustered, then it can only host the Mailbox Server role. If the source server isn't clustered, then the Mailbox Server role is required for SCR. However, the server can also optionally host the Client Access Server, Hub Transport Server or Unified Messaging (UM) Server roles.
The same basic rules apply to SCR target servers. The Mailbox Server role is always required, because it contains the necessary replication components. If the target isn't part of a cluster, it can optionally host the Client Access Server, Hub Transport Server, or Unified Messaging Server roles. In either case, LCR cannot be used on a target server.
If the target is a part of a cluster, it should be designated as a passive node on a failover cluster. The Mailbox Server role must be installed where no other clustered mailbox servers have been installed in the cluster.
SCR and Exchange backups
One last limitation is related to backups. Many organizations use CCR to make the backup process more efficient. Backups can be run against a CCR replica without affecting the primary mailbox server. But unlike cluster continuous replication, you can't run a backup against a standby continuous replication target. You can, however, use CCR on an SCR host. This allows you to create a CCR replica of the primary database, run your backups against this replica and still reap SCR's benefits.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services (IIS) and File Systems and Storage. He has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
