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 ...
Updated Jul 01, 2019
Version 2.0
Blog Post
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.
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.