Video Series: Exchange 2007 SP1 Standby Continuous Replication (SCR)

[The_Exchange_Team]

Beta 2 of Service Pack 1 Exchange Server 2007 is available for public download and preview for MSDN and TechNet subscribers. As I wrote in my blog entry, Standby Continuous Replication in Exchange Server 2007 Service Pack 1, SCR extends the continuous replication technology in Exchange 2007, enabling new data availability scenarios for Exchange 2007 Mailbox servers. You can find product documentation for SCR in the recently refreshed TechCenter update at http://technet.microsoft.com/en-us/library/bb676502.aspx.

To demonstrate one of those scenarios, I have created a 5-part blogcast that takes you through the process of enabling SCR, monitoring SCR, and activating an SCR storage group copy using the Exchange Management Shell and other features, such as database portability. This scenario is based on the scenario detailed in the Help topic Standby Continuous Replication: Database Portability.

An example of using SCR with a standby cluster is detailed in the Help topic Standby Continuous Replication: Site Resilience with Standby Clustering.

The blogcast video parts are as follows; please click on video thumbnails below to see the videos. There is a Download link on each of the 5 video pages where you can download them in full resolution (Right-click, Save Target As...):

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

These blogcast videos are intended to be watched in full-screen resolution (at least 1024 x 768), and in numbered order.

Of course we welcome your feedback on SCR, the documentation for SCR, and this blogcast. Thanks for reading/watching!

- Scott Schnoll

[#2]

Scott,

Why was the database in a dirty shutdown state, when you intentionally dismounted it?

[#3]

Excellent Stuff dude... Why was db showing dirty shutdown?

[#4]

Excellent Stuff dude... Why was db showing dirty shutdown?

[#5]

When a database is shut down before you have performed required maintenance, it is put into an inconsistent state. This is referred to as a Dirty Shutdown. This means that some transaction log files must be replayed before the database can be considered consistent. You cannot mount a database is in a Dirty Shutdown state until the transaction logs have been replayed and the database has correctly detached from the current log stream.

[#6]

Hi Scott,

While we enable SCR, what do you mean by 50 logfiles & 24 hours lag delay? What if i have 500 logfiles? Also, being asynchronous replication, what does this delay refer to? Shouldn't it replicate once the logfile is closed as with lcr/ccr?

Where do we mention the files/locations on the scr target to get the data replicated from the source scr? thats not clear. Target server doesn't show the target sg/mb anywhere before we switch to recovery objects, but where do we have being them replicated? The enabling of scr is done but recovery sg/mb is being created afterwards, & could be created after disaster as well. Where are the target paths?

Wwat names & paths necessarily be provided to create recovery objects (sg & db) ahead of disaster to facilitate database portability? What association do they have with Active Directory, for which we are deleting them after we create them?

Ofcourse, after the active is corrupted, it is unavailable. In that event, utlook 2007 clients would be able to access the new paths after DS replication. But do you mean outlook 2003 or earlier clients, all manual intervention is required?

[#7]

BestofHarish, with SCR targets, there is a built-in hard-coded delay in replay of 50 log files, plus a default, soft-coded delay of 24 hours, which can be modified by an admin as they see fit (increase time, decrease time, make time value 0, etc).  But even if they make the time value (what we call ReplayLagTime) 0, there's still the hard-coded replay delay of 50 log files.

Keep in mind that this is a delay in REPLAY activity, not REPLICATION activitity.  We chose the name 'continuous replication' specifically to emphasize that replication is by default continuously happening (unless of course the admin suspends it, or there is some failure causing an interruption).  It's the replay aspect that is delayed, which enables additional recovery scenarios (e.g., going back in time scenarios).

As I demonstrate in the blogcast, there's nothing that you need to create on the target.  When you enable a storage group for SCR, a path matching the source paths for the storage group is created on the SCR target computer by the Replication service on the SCR target computer.  Once that path is created, the Replication service on the SCR target computer begins continuous replication.

None of the SCR target storage groups will be visible on the SCR target computer as storage groups and database objects.  The Exchange Management Console does not display SCR target storage group copies, just like it doesn't display the passive copy of a storage group as a separate storage groups.  But you can still get details on the storage group copies by using Get-StorageGroupCopyStatus (with the -StandbyMachine parameter) and Test-ReplicationHealth.  You can also suspend replication, and use vssadmin to take an offline VSS snapshot of the SCR target database copy and then use Eseutil to periodically verify the integrity of the target copy.

The storage group and database recovery objects can be created after a disaster, but it's better to create them beforehand as it saves you time in a disaster recovery operation.  You just want to make sure that their paths are unique and that they don't conflict with any other storage group or storage group copy. Their only purpose is to act as destination objects in the database portability steps.

Messaging clients running Microsoft Office Outlook 2007 and non-Outlook clients will have access to the user's mailbox after the directory servers used by the user's Client Access server have been updated with the new paths. Messaging clients running Outlook 2003 and earlier versions will require the user's desktop messaging profile to be updated with the new server name if the original server is down or otherwise unavailable. If the original SCR source server is online and available to respond to client requests, then messaging clients running Outlook 2003 and earlier versions will have their desktop messaging profile automatically updated by the original server with the new server name, and the desktop messaging profile will not need to be manually modified.

For more information on SCR, see http://technet.microsoft.com/en-us/library/bb676502.aspx.

[#8]

Hi Scott,

1. SCR introduces the concept of multiple database copies. What is meant by that?

2. Only database headers of SCR copies are updated, & SCR target would inspect source logfiles for permitting them to be truncated after being backed up by supported utilities. What is meant by only db headers being updated, & why not complete files? What is actually been ispected & where does it keep the files which is not committed into target, but has got inspected upon for deletion on source.

3. When performing data portability by restore-storagegroupcopy on target sg, if source is available, this command would copy the remaining log files from source to target, if any. But, in case the scr source is not available or lost forever, then what? Is there any dumpster concept here?

4. Why do we intend to make sure that the logfiles are copied, when we also would like to leverage the replay lag feature in case the logfiles are corrupted in the source & we dont like to get that corruption been replicated?

5. Let's say i mentioned a replay delay of say 5 hours & say i lost my scr source. Now, as per 5 hours delay in replay, it would get replayed after 5 hours gap. But where would they reside until they are replayed into scr target.

6. How can i stop the logfiles to be replayed into scr target after i found that scr source site is lost. Moreover, how would i get to know that whether the logfiles which are yet to be replayed into the scr target, are corrupted or not?
*****************************************************

[#9]

BestofHarish,

1. SCR introduces the concept of multiple 'storage group copies'.  Whereas with LCR and CCR, you only have two copies of each storage group (the active and the passive) with SCR, you can have additional storage group copies (which we call SCR targets).

2. I'm not sure what you are saying here.  An SCR target copy cannot be backed up.  SCR targets copies only get their updates which come from the logs shipped by the Replication service.

3. Restore-storagegroupcopy is not part of database portability.  It is a continuous replication function.  Basically, we clean up the replay states for replication so that the target can be configured as a replication source.  Restore-SGC attempts to copy all remaining log files and close the storage group.  We also mark the database as mountable by updating the MountAllowed flag.

4. All logs that are shipped are checked for corruption and undergo database signature validation before they are replayed.  Continuous replication will not replay a corrupt log file into a database copy.  The idea is that logs are shipped immediately; they are just not replayed immediately.

5. As with all three forms of continuous replication, the logs will be on the SCR target computer in the path for the log files for the storage group copy.  See http://blogs.technet.com/scottschnoll/archive/2006/10/30/More-on-Continuous-Replication.aspx for some more information on this.

6. Why would you want to?  That is the whole point of SCR; to give you a viable, online copy in the event you lose your original.  The log files will be checked for corruption, and if corruption is found they will not be replayed into the copy of the database.

Have a look at http://technet.microsoft.com/en-us/library/bb676502.aspx for more information on SCR.

[#10]

Thank Scott!

1. Oh! I thot Restore-SGC is a part of db portability. Can you please explain the entire process/componet & intervention involved with database portability process.

2. If while playing the logfiles, scr target finds that a particular logfile is corrupted, then it wont play it. What would happen to the remaining log stream. Would all the logs be discarded then?

***There can be a number of permutations for scr sources & targets being a standalone server or a cluster server. If the source & target are standalone, then we could go either for db portability or /RecoverServer setup option.***

3. If we have a source as SCC or CCR, & the target as a standalone server, then would we go for /RecoverServer or /RecoverCMS? & Secondly, if source is standalone but the target is a passive node in standby cluster, then what?
My Question in actuality is: Does /RecoverCMS depend upon the source being CMS or the target being CMS?

4. Can /RecoverCMS be used when recovering storage groups from a single CCR SCR-source only? What about when we have multiple CCR SCR-sources, single SCR-targets or multiple SCR-targets?

[#11]

Hi BestofHarish,

1. You can find documentation on database portability at http://technet.microsoft.com/en-us/library/bb123954.aspx.  This topic includes conceptual material that explains the process.  It also includes a link to the procedural topic that walks you through database portability.

2. If a log cannot be replayed for any reason, it is kept in the InspectionFailed folder.  See http://blogs.technet.com/scottschnoll/archive/2006/10/06/Exchange-2007-_2D00_-Continuous-Replication... for more information on this.

3. You use /m:RecoverServer to recover a standalone system and /RecoverCMS to recover a clustered mailbox server.  You cannot mix and match them (e.g., you cannot use /RecoverCMS to recover a standalone server).  These switches are for recovery only, and cannot be used for conversion.  See http://technet.microsoft.com/en-us/library/aa998656.aspx for more information.

4. /RecoverCMS is used to recover an entire clustered mailbox server.  In fact, both Setup recovery options are used to recover a whole server; if you need to recover just some of the databases, you would use database portability.  If you need to recover the whole server, then you would use the appropriate server recovery option.

[#12]

Scott,

I have tried several time to upgrade my CCR cluster to SP1 beta 2.  I start by upgrading the passive node per the instructions.  Each time it fails and it appears there is no way to recover the node.  The error message in the setup log says that the mailbox role is not current.  After the upgrade fails I cannot recover and have to start over.  Any ideas on what to look for?

[#13]

Additionally, when I try to restart the setup again it reports that the server is in an incosistent state and says to run recover server.  However, if you try to do so it says that it cannot find the clustered mailbox server - I imagine because it is not on this node.

[#14]

I am able to enable SCR for a single SCR Target and am intersted in configuring multiple SCR Tragets now. Please can you share the cmdlets for enabling multiple SCR Targets for a storage group?

[#15]

Hi ExchUser, the steps are the same, except that you specify a different StandbyMachine.

[#16]

We are very excited about SCR and would love to be able to implement this instead of NSI's DoubleTake, but I need some clarification. I've been trying to find documentation on how I would configure multiple sources for a single target. Currently we have 2 SCC virtual servers in our main datacenter. We would like to use a single server in our DR site as the SCR target. So in a nutshell:
We have 2 clusters that we want to use SCR to replicate to a SINGLE server. I have seen comments that this is possible, but nothing technical on exactly how to run setup /recovercms for BOTH clusters which will be replicated to the target.
Please point me in the right direction.

[#17]

I've read something regarding that if in your Exchange organization have more than one server with public folders, you will not be able to use SCR anywere. Since I have no other options than enabling public folders (75.000 outlook 2003 clients), is there any possibility of using SCR and public folders on diferent servers in this scenario? Maybe disabling public folder replication manually?

[#18]

Len, to configure multiple SCR targets for the same storage group, you simply repeat the Enable-StorageGroupCopy task (with the -StandbyMachine parameter pointing to the new target) for each additional target you want to create.  To configure storage groups on multiple clustered mailbox servers for SCR using the same target, you simply use the same StandbyMachine for those storage groups. Note that the OS on the SCR source and targets must match, and you must not have any storage group or database path collisions between the SCR sources and all targets.

Once you have both CMS' replicating their storage groups to the same standby server, the way in which you activate that server depends on the nature of the failure.  If you lose just a single SG/DB, you will find database portability to be the best way.  If you lose an entire CMS, then you can use the recovery option.  However, in that case, be aware that the SCR target computer must be a passive node in a failover cluster that does not contain any CMS in the cluster. This is required in order to leverage Setup /recovercms.  Also be aware that you will need to suspend SCR for the other, healthy CMS, and then reconfigure SCR after you have recovered your standby cluster.

[#19]

Bernat, you cannot disable all public folder replication.  The issue is that as long as there is more than one PF database, public folder replication is enabled, even if none of the folders are configured with replicas. One reason is that the hierarchy is always replicating. For complete details on SCR and public folders, please see http://technet.microsoft.com/en-us/library/bb676502.aspx.

[#20]

Thanks for the info Scott, but I have one further wrinkle..
What if we lost BOTH CMS' (at the same time)which are replicating to the single target?
Thanks in advance.

[#21]

Len, in that case, it depends.  If both CMS' are from the same cluster, then you use Setup /recovercms to recover them both back into the same cluster.  This is because splitting CMS' from a single failover cluster into many failover clusters, or vice versa, is not supported and cannot be accomplished using Setup /recovercms. If the CMS' are from different clusters, then you use Setup /recovercms to recover one of them, and then you use database portability to recover the databases from the other CMS.

[#22]

THANKS, SCOTT!!!
That was the last piece of the puzzle I was missing. Our CMS' are in fact on 2 seperate clusters so the combination of /recovercms and database portability will be the way to go.