SCR does not require specially configured disk storage. SCR requires storage that provides adequate capacity. Equivalent storage solutions should be configured for all SCR targets configured for the same storage group. We recommend that you follow the configuration procedures provided by your storage vendor to complete the configuration.

Managing Disk Volumes in an SCR environment

SCR is enabled only by using the Exchange Management Shell and running either the New-StorageGroup cmdlet or the Enable-StorageGroupCopy cmdlet. Both cmdlets include some new parameters that are introduced with Microsoft Exchange Server 2007 Service Pack 1 (SP1):

• -StandbyMachine   This parameter is used to specify the name of the computer that will contain the SCR target. The value of this parameter is set as part of the value for the msExchStandbyCopyMachines attribute of the storage group being enabled for SCR. The msExchStandbyCopyMachines attribute is a multivalued Unicode string that is added to the Active Directory directory service schema when Exchange 2007 SP1 is introduced into the Exchange organization.
  
  
• -ReplayLagTime   This parameter is used to specify the amount of time that the Microsoft Exchange Replication service should wait before replaying log files that have been copied to the SCR target computer. The format for this parameter is (Days.Hours:Minutes:Seconds). The default setting for this value is 24 hours. The maximum allowable setting for this value is 7 days. The minimum allowable setting is 0 seconds, although setting this value to 0 seconds does not affect the default delay in log replay activity of 50 log files. After being set, the value for this parameter cannot be changed without disabling and then enabling SCR.
  
  
• -TruncationLagTime   This parameter is used to specify the amount of time that the Microsoft Exchange Replication service should wait before truncating log files that have been copied to the SCR target computer and replayed into the copy of the database. The time period begins after the log has been successfully replayed into the copy of the database. The format for this parameter is (Days.Hours:Minutes:Seconds). The maximum allowable setting for this value is 7 days. The minimum allowable setting is 0 seconds, although setting this value to 0 seconds effectively eliminates any delay in log truncation activity. After being set, the value for this parameter cannot be changed without disabling and then enabling SCR.
  
  
• -SeedingPostponed   This parameter can be used to skip the initial seeding of the SCR target. If this parameter is used, the administrator must manually seed the SCR target using the Update-StorageGroupCopy cmdlet. This parameter is available only with the Enable-StorageGroupCopy cmdlet. It is not available with the New-StorageGroup cmdlet because no source database exists at this point.
  
  

  Important:
  To change the replay or truncation delay settings, you must first disable SCR and then enable SCR using the new values for these settings.

In addition to the administrator-configured delay of replay that is specified using the ReplayLagTime parameter, Exchange also prevents a fixed number of log files from being replayed on an SCR target, regardless of the value for ReplayLagTime, using the following formula:

Maximum of ("value of ReplayLagTime" or "X log files")

where X=50. This is an additional safeguard against the need to reseed a storage group in situations when an SCR source that is in a continuous replication environment, for example, local continuous replication (LCR) or cluster continuous replication (CCR), experiences a lossy failover and is brought online using the Restore-StorageGroupCopy cmdlet. By delaying replay activity on the SCR targets, when a lossy failover for an SCR source occurs, the chances of needing to reseed the SCR copies are minimized because the nature of the data loss on the SCR source puts the two copies closer together in time.

Important:
The built-in lag time of 50 log files, and the value of the ReplayLagTime parameter has implications for the creation of the initial SCR target database. An SCR target database will not be created until 50 transaction log files have been replicated to the SCR target computer, and until the time period specified by ReplayLagTime (or the default ReplayLagTime of 24 hours) has elapsed.

When you enable SCR for a storage group, a copy of the storage group (system files, log files, and database file) is automatically created and maintained on the SCR target computer, using the same paths as the storage group on the SCR source.

After SCR has been enabled, we recommend monitoring the health and status for each storage group using the Test-ReplicationHealth cmdlet. For detailed steps about how to enable SCR, see How to Enable Standby Continuous Replication for an Existing Storage Group and How to Enable Standby Continuous Replication for a New Storage Group.

SCR and Log Truncation

SCR is disabled only by using the Disable-StorageGroupCopy cmdlet and the StandbyMachine parameter. When disabling SCR, it is important that you include the appropriate value for the StandbyMachine parameter. If the SCR source storage group also has LCR enabled and you do not include the StandbyMachine parameter as part of this command, LCR will be disabled for the storage group.

Disabling SCR is necessary to change the value for either the ReplayLagTime or the TruncationLogDelay parameters. These values cannot be modified while SCR is enabled. Therefore, to change the replay or truncation delay settings, you must first disable SCR and then enable SCR again using the new values for these settings.

For detailed steps about how to disable SCR for a storage group, see How to Disable Standby Continuous Replication for a Storage Group.

Although SCR does not require any special monitoring, we recommend regularly monitoring each storage group to verify that it is replicating log files correctly. The Microsoft Exchange Server 2007 Management Pack for Microsoft Operations Manager 2005 includes alerts for several critical problems related to SCR environments:

• Microsoft Exchange Replication service is not running. Note that the event that generates this alert does not repeatedly appear after the service is stopped, so any alert associated with it would be lost if it were cleared.
  
  
• SCR target copy is in a Failed state.
  
  
• SCR target copy is in a Healthy state, but it is behind in log copying.
  
  

You should investigate and resolve any of the preceding alerts generated by the Exchange 2007 Management Pack as quickly as possible.

Test-ReplicationHealth Cmdlet

It may occasionally be necessary to mount or dismount databases in an SCR environment. If the SCR source storage group or database needs reconfiguration or maintenance, you must block the services interacting with both while the activity is occurring. This could be required to perform a reconfiguration or to correct issues with the server or database. When the database is dismounted, it is inaccessible.

You can change the location of a database in an SCR-enabled storage group. In an SCR environment, there are two database files, one for each copy. When moving the storage group files or the database file, the locations for both copies must be changed in tandem.

Note:
The complete path for the storage group files and database file must match on the SCR source and all SCR targets.

Similar procedures are used to reconfigure the location of a storage group log and system files and the location of the database files in an SCR environment. For detailed steps about how to change the location of log files and system files for an SCR-enabled storage group, see How to Move a Storage Group in a Standby Continuous Replication Environment. For detailed steps about how to change the location of database files in an SCR environment, see How to Move a Database in a Standby Continuous Replication Environment.

Important:
Databases cannot be placed at the root of a volume.

All monitoring and status is performed using the Exchange Management Shell. The Exchange Management Console does not display copy status or any other information about SCR. After SCR has been enabled for a storage group, you can use the Exchange Management Shell to view the SCR-specific configuration settings for the storage group and its database.

Status Information for Standby Continuous Replication

Exchange 2007 publishes a variety of status information for SCR copies. The following table describes the status information that is available for SCR-enabled storage groups. For detailed steps that explain how to obtain status information, see How to View the Status of Standby Continuous Replication.

Note:
The following table lists the properties in the order that they appear when viewing the full output of the Get-StorageGroupCopyStatus cmdlet.

Status information available for SCR-enabled storage groups

Property	Description
Identity	Server and name of the queried storage group.
StorageGroupName	Name of the queried storage group.
SummaryCopyStatus	Current overall status of the SCR copy. Possible values are: Not Supported   The current configuration does not support continuous replication. Disabled   The computer has not been designated as a target. If the target computer has not yet read the updated information in Active Directory that specifies it as a target computer, it reports a status of Disabled. If you have enabled this target computer for SCR but it reports a status of Disabled, check Active Directory replication for any problems or latency. Failed   Verification has failed (database or logs were incompatible with each other), or the storage group is improperly configured for SCR. Seeding   Database seeding is in progress. Initializing   System is coming online, but replication has not yet begun. The system will remain in this status until a transaction log file has been generated. Service Down    Microsoft Exchange Replication service is not running. Suspended   Transaction log copying and replay are stopped. Synchronizing   System has detected a failover, and it is correcting any divergence that occurred. Healthy   Status is healthy and normal, and nothing is blocking or blocked.
Failed	Verification of the database or logs identified an inconsistency that prevents replication. Alternatively, there is a configuration or access problem with the active or passive copy. Possible values are True and False.
FailedMessage	Textual message identifies the condition that caused replication to fail. It may not be the only replication problem area.
Seeding	Seeding in progress. Possible values are True and False.
Suspend	Replication (and replay) halted for the passive copy. This prevents the database from advancing and logs from being copied. Possible values are True and False.
SuspendComment	Optional administrator comment providing a reason or note as to why replication activity has halted.
CopyQueueLength	Number of transaction log files waiting to be copied to the passive copy log file folder. A copy is not considered completed until it has been checked for corruption.
ReplayQueueLength	Number of transaction log files that have been copied and are waiting to be replayed into the passive copy.
LatestAvailableLogTime	Time stamp on the source storage group of the most recently detected new transaction log file.
LastCopyNotificationedLogTime	Time associated with the last new log generated by the active storage group and known to the copy.
LastCopiedLogTime	Time stamp on the source storage group of the last successful copy of a transaction log file.
LastInspectedLogTime	Time stamp on the target storage group of the last successful inspection of a transaction log file.
LastReplayedLogTime	Time stamp on the target storage group of the last successful replay of a transaction log file.
LastLogGenerated	Last log generation number known to be generated on the active copy of the storage group.
LastLogCopied	Last log generation number successfully copied to the passive copy log folder.
LastLogNotified	Last log generation number generated by the active storage group and known to the copy.
LastLogInspected	Last log generation number inspected for consistency and corruption.
LastLogReplayed	Last log generation number successfully replayed into the passive copy of the storage group.
LatestFullBackupTime	Time of the last full backup.
LatestIncrementalBackupTime	Time of the last incremental backup.
SnapshotBackup	Backup taken using legacy streaming APIs or Volume Shadow Copy Service (VSS). Possible values are True and False.

You can quickly assess the health of an SCR copy by looking at the values for SummaryCopyStatus, CopyQueueLength, ReplayQueueLength, and LastInspectedLogTime. These properties show whether the SCR copy is functioning correctly, and whether the SCR copy is relatively current in both copying and replaying logs. If the following conditions occur, you should determine the cause and correct the problem:

• The copy is spending significant time in a state that is not healthy.
  
  
• The copy queue length is more than 5.
  
  
• The replay queue length is more than 20.
  
  
• The last inspected log time does not show a current time. There are two likely reasons that could cause this: Either the storage group is not experiencing much change, or the replication service is stopped.
  
  

The replay queue length and copy queue length values are available as performance counters. They are the CopyQueueLength and ReplayQueueLength performance counters under the MSExchange Replication performance object.

There are some rare scenarios where the replication status can be misleading. The following is a list of those scenarios:

• A storage group that is not active (that is, not changing) can report as healthy when it might not be healthy. This situation could occur because the unhealthy condition could not be detected until a log is replayed.
  
  
• During replication initialization, the replication status is being evaluated and may not be accurate. When the initialization completes, the status is updated.
  
  
• The value of the LastLogGenerated field can be wrong when a database is dismounted. However, all logs with end-user content are replicated if the storage group copy is replicating.
  
  
• When there are one or more missing logs in the middle of a log stream, the passive copy continues to try to recover. In doing so, the replication status switches between failed and healthy states. The replay and copy queues continue to grow.
  
  
• In some very rare conditions, a log can be successfully verified but it can still fail to replay. In this situation, the system alternates between failed and healthy states as it attempts to recover. The replay and copy queues continue to grow.
  
  

When you use SCR, we recommend that you verify the integrity of each SCR target copy periodically by running a physical consistency check against the database and transaction log files. A physical consistency check examines the transaction logs and database files for corruption. You can perform the check by using the command-line version of the Microsoft Volume Shadow Copy Service tool (VSSAdmin.exe), and the Exchange Server Database Utilities (Eseutil.exe). For detailed steps about how to use VSSAdmin and Eseutil to check the transaction logs and database files for physical corruption, see How to Verify a Standby Continuous Replication Copy.

Note:

Before you run a physical consistency check against a database, you must temporarily suspend all replication activity against the storage group. You can suspend replication activity by using the Suspend-StorageGroupCopy cmdlet in the Exchange Management Shell. When the consistency check has completed, you can resume transaction log replay activity by using the Resume-StorageGroupCopy cmdlet. We recommend that you perform verification during non-production hours and minimize the amount of time that replay activity is suspended. This is because suspending the storage group copy halts all updates to the SCR copy, thus causing some content to be vulnerable to a failure.

Managing log file replication and replay in an SCR environment involves the following main activities:

• Halting replication to the storage group copy
  
  
• Restarting replication to the storage group copy
  
  
• Reseeding a storage group
  
  

Halting and Restarting Changes to a Storage Group Copy and its Database

Seeding and Reseeding a Storage Group Copy

After a failure or corruption of a database copy, you need to assess if you want to immediately continue operation using an SCR target. SCR provides key pieces of information to aid in this decision:

• Health of the copy at the time of failure
  
  
• Replay and copy queues at the time of the failure
  
  
• Last inspected log time at the time of the failure
  
  

The information can be obtained using the Get-StorageGroupCopyStatus cmdlet. For detailed steps about how to obtain this information, see How to View the Status of Standby Continuous Replication.

Note:
The last inspected log time provides information about the most recent changes from the SCR source. This aids in detecting failures that occur when the Microsoft Exchange Replication service is not started because the queue lengths are inaccurate when the Microsoft Exchange Replication service is stopped.

The copy queue length includes the best available information of the SCR source at the time of failure. Based on this information and your assessment of the recovery time of the failed database, you must decide if the available SCR target is to be activated:

• If the replay queue length is significant, recovery might take time but it is not an indicator that significant data loss will be experienced.
  
  
• If the copy queue length is significant, many logs have been lost. If the database is activated, it will be restored to a time frame of approximately the last copied log (also provided by the Get-StorageGroupCopyStatus cmdlet).
  
  
• If the last inspected log time is significantly prior to the time of the failure, it is likely that the Microsoft Exchange Replication service is stopped and other queue information is inaccurate.
  
  

  Note:
  Due to the nature of SCR, as well as external latencies and communication failures, it is possible for the copy queue length to be inaccurate because the current state of the active copy is asynchronously updated. In general, the inaccuracy is limited to activities approximately a minute before and after the failure.

  Note:
  A failed database cannot be used to seed an SCR target.