This blog post discusses several top issues seen to date by the Microsoft Exchange Product Support Team regarding the Standby Continuous Replication (SCR) feature introduced in Exchange 2007 Service Pack 1. We wanted to share this information as it can be used as a preventative measure as well as for resolving issues you may have experienced. It is understood that this will not cover all that can possibly go wrong, but it should give you some good pointers in some situations that you might have seen.
For basic configuration information on SCR, please review the following article available on Microsoft TechNet: Standby Continuous Replication
Issues covered here include:
- Enable-StorageGroupCopyStatus -StandbyMachine reports error "Another standby continuous replication source is already configured..."
- SCR Target Log Files Fail to Truncate After the TruncationLagTime is Surpassed
- SCR does not replicate logs in a disjoint namespace scenario
- Database seeding error: Error returned from an ESE function call (0xc7ff1004), error code (0x0)
- SCR Hidden Network share not created in a Cluster with Event id 2074
Enable-StorageGroupCopyStatus -StandbyMachine reports error "Another standby continuous replication source is already configured at <path to Storage Group logs> for 'CopyLogFolderPath'."
Possible Causes
The SCR target server may be using the same log file path as the SCR source server. This can happen when attempting to enable SCR on the First Storage Group.
Resolution
Change the log file, system file paths on the Storage Group and database path on the Mailbox database to another location on the SCR target server. Note: In order for the file path change to take effect the databases in the Storage Group will be temporarily dismounted and then remounted.
Step-by-step instruction
This can be done from the Exchange Management Console or through the Exchange Management Shell. For specific instructions, please click the following links:
How to Set or Change the Location of Storage Group Log Files
How to Set a Database File Location
SCR Target Log Files Fail to Truncate After the TruncationLagTime is Surpassed.
Possible Causes
The SCR log file truncation time is set to a value over 24 hours.
Resolution
Set TruncationLagTime to 0.0:00:00 minutes and then restart the Microsoft Exchange Information Store and Microsoft Exchange Replication services. Next, take a backup of the Storage Group on the SCR Source server and then confirm that SCR Target log files get truncated after successful backup. After SCR target files truncate properly, you may change the TruncationLagTime to your desired values.
Note: This issue will be addressed in a future rollup for Exchange 2007 Service Pack 1.
Step-by-step instruction
In order to change the TruncationLagTime, you must disable SCR and then enable SCR using the desired values. For specific instructions, please click the following links:
How to Disable Standby Continuous Replication for a Storage Group
How to Enable Standby Continuous Replication for an Existing Storage Group
How to Enable Standby Continuous Replication for a New Storage Group
SCR does not Replicate Logs in a Disjoint Namespace Scenario
Possible Causes
The SCR source and the SCR target servers have FQDNs with disjointed domain names
Resolution
Issue will be fixed in a future rollup for Exchange 2007 Service Pack 1. To resolve this issue, contact Microsoft Customer Support Services to obtain fix 951955.
More Information
Understanding Disjoint Namespace Scenarios with Exchange 2007
Database Seeding Error: Error returned from an ESE function call (0xc7ff1004), error code (0x0).
Possible Causes
Windows firewall settings are blocking the command
Resolution
Add the "Windows PowerShell" to the Exceptions list under Windows Firewall settings.
Step-by-step instruction
Add a Program to the Exceptions List
SCR Hidden Network Share is not created in a Cluster with Event id 2074
Possible Causes
Resources in the default Cluster group, such as Cluster IP Address, Cluster name and Quorum disk were moved to a different cluster group.
Resolution
Move the Cluster IP Address, Cluster name and Quorum disk to the default Cluster group.
Step-by-step instruction
Best practices for configuring and operating server clusters
If you experience failures other than those listed here, look at the event log on both nodes to determine the cause and use the information in the logs to determine what recovery steps need to be taken. You can also review other events that occurred around the same time that the failure occurred to help assess if they could be attributed to the issue.
Here are some How-to Webcasts on SCR configuration created by Scott Schnoll:
SCR in Exchange Server 2007 SP1 - Part 1
SCR in Exchange Server 2007 SP1 - Part 2
SCR in Exchange Server 2007 SP1 - Part 3
SCR in Exchange Server 2007 SP1 - Part 4
SCR in Exchange Server 2007 SP1 - Part 5
- Gurpreet Erickson