Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2007-10-24

Seeding is the process of making available a baseline copy of a database on the current passive node. Depending on the situation, seeding can be an automatic process or a manual process in which you initiate the seeding. You can use the procedure in situations where you determine seeding is required. The size of the database being copied directly correlates to the amount of time it takes for the seeding task to complete.

Seeding is required under the following conditions:

When a new passive node is introduced into a cluster continuous replication (CCR) environment, and the first log file of the production storage group is not available.
After a failover occurs in which data is lost as a result of the now passive copy having become diverged and unrecoverable.
When the system has detected a corrupted log file that cannot be replayed into the passive copy.
After an offline defragmentation of either copy of the database occurs.
After a page scrubbing of the active copy of a database occurs, and you want to propagate the changes to the passive copy.
After the log generation sequence for the storage group has been reset back to 1.

You can perform seeding in Microsoft Exchange Server 2007 by using the following methods:

Automatic seeding An automatic seed produces a copy of a storage group's database on the target. Automatic seeding requires that log1 be available on the source. Automatic seeding only occurs during the creation of a new server, creation of a new storage group and database, or on a database that has never been backed up.
Seeding using the Update-StorageGroupCopy cmdlet You can use the Update-StorageGroupCopy cmdlet in the Exchange Management Shell to seed a storage group copy.

Manually copying the offline database This process dismounts the database and copies the database file to the same location on the passive node. If you use this method, there will be an interruption in service because the procedure requires you to dismount the database.

Note:
Some backup applications may support a mechanism to use a backup as the source of the seed database. Restores to the passive node are not supported. If this option is supported, it must be explicitly and completely supported by the backup application.

In Microsoft Exchange Server 2007 Service Pack 1 (SP1), the Update-StorageGroupCopy cmdlet has been extended to include a new parameter called DataHostNames. The DataHostNames parameter is used to specify which network should be used for seeding or reseeding. The value is a multivalued list of two names: either fully qualified domain names (FQDNs) or host names. One of these names must identify the active node.

Exchange 2007 SP1 also adds the ability to seed (without the DataHostNames parameter) using the Update Storage Group Copy Wizard in the Exchange Management Console. This wizard is available only from the Exchange Management Console on the passive node.

This topic contains three procedures. The first procedure explains how to use the Update-StorageGroupCopy cmdlet to seed the storage group copy. The second procedure explains how to use the Exchange Management Console to dismount a database for offline copying to the CCR database folder. The third procedure explains how to use the Update Storage Group Copy Wizard.

Before You Begin

To perform the following procedures on a computer that has a clustered mailbox server installed, the account you use must be delegated the Exchange Server Administrator role and local Administrators group for the target server. For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

The seed operation using the Update-StorageGroupCopy cmdlet can potentially result in an input/output (I/O) burden on the active storage group volumes. As a result, depending on the storage design of the cluster, this approach could affect client operations and possibly disrupt client access. Because of the potential impact on client access, we recommend that seeding operations using the Update-StorageGroupCopy cmdlet be scheduled for periods of lower client activity, where practicable, to minimize potential client impact. The delay needs to be considered, along with the exposure created by the unseeded passive copy.

When configuring a new CCR target from the active node, the seeding operation automatically creates the directories as well as the database file on the passive node, if they do not already exist. The location of the database and log files must be the same between servers in a cluster. Storage must be available and sufficient to store the database and logs.

Important:
If a database or the log files exist in the location where the passive copy will be stored, the database or log files must be removed prior to initiating the seeding operation.

Important:
The Update-StorageGroupCopy command must be run from the passive node.

Procedure

To use the Exchange Management Shell to seed the passive node

Suspend replication for the storage group by running the following command:
Copy Code
Suspend-StorageGroupCopy -Identity:<Server\StorageGroupName>
Remove database files, all log files, and checkpoint files from the passive node. Remove *.log, *.jrs, *.chk, and the .edb files from the configured directories (logs directory, the system files directory, and the directory hosting the database file).

	Copy Code
Suspend-StorageGroupCopy -Identity:<Server\StorageGroupName>

Run the following command to seed the storage group copy on the passive node:

	Copy Code
Update-StorageGroupCopy -Identity:<Server\StorageGroupName>

Note:
The TargetPath parameter is used to seed a database to a path that is different from the configured location for the passive copy of the database. For example, when you have each CCR node in a different physical location, you can use the TargetPath parameter to perform the update locally on the active node, and then use a copy utility that provides data compression to move the copy over the network to the passive node. If the Target Path parameter is not used, the Update-StorageGroupCopy cmdlet must be issued on the computer containing the passive copy.

Note:

The TargetPath parameter is used to seed a database to a path that is different from the configured location for the passive copy of the database. For example, when you have each CCR node in a different physical location, you can use the TargetPath parameter to perform the update locally on the active node, and then use a copy utility that provides data compression to move the copy over the network to the passive node. If the Target Path parameter is not used, the Update-StorageGroupCopy cmdlet must be issued on the computer containing the passive copy.

Note:
The Update-StorageGroupCopy command automatically resumes replication to the storage group copy. If you do not want the Update-StorageGroupCopy command to automatically resume replication, run the command with the ManualResume parameter. For more information, see Update-StorageGroupCopy. To resume replication manually after running the Update-StorageGroupCopy command, run the following command:

Note:

The Update-StorageGroupCopy command automatically resumes replication to the storage group copy. If you do not want the Update-StorageGroupCopy command to automatically resume replication, run the command with the ManualResume parameter. For more information, see Update-StorageGroupCopy. To resume replication manually after running the Update-StorageGroupCopy command, run the following command:

	Copy Code
Resume-StorageGroupCopy -Identity:<Server>\<StorageGroupName>

Note:
If you receive errors when you run the Update-StorageGroupCopy task, for more information see the errors table in Update-StorageGroupCopy.

Note:
Run the following command to specify that a redundant network be used for the seeding operation:

	Copy Code
Update-StorageGroupCopy -Identity:<Server\StorageGroupName> -DataHostNames:{Host1,Host2}

After the Update-StorageGroupCopy command is complete and the storage group copy is resumed, verify that replication is working correctly by using the Get-StorageGroupCopyStatus cmdlet.

Important:

Make sure that the data is actually flowing because a lack of data flow can make it look like operations are normal when they are not.

Important:
Make sure that the data is actually flowing because a lack of data flow can make it look like operations are normal when they are not.

To use the Exchange Management Console to manually seed the passive node by copying an offline database file

Open the Exchange Management Console.
Expand Server Configuration, and then select Mailbox.
In the result pane, select the Mailbox server that contains the database that you want to dismount.
In the work pane, right-click the database to be dismounted, and then select Dismount Database.
Suspend replication on the dismounted database. Follow the steps for suspending replication that are shown in How to Halt Replication for a Passive Copy in a CCR Environment.
After the replication is suspended on the database, copy the database file (.edb file) from the production database folder to the CCR database folder.

Note:

The location of the production database folder can be found on either the Summary page or the Properties page.
After the database file has been copied from the production database folder to the CCR database folder, right-click the dismounted database, and then select Mount Database.

Note:

Seeding is complete when the file is copied. Client access is restored after the production database has been mounted.
Resume replication for the dismounted CCR database. Follow the steps for resuming replication in the topic How to Restart Replication for a Passive Copy in a CCR Environment.

Note:

Seeding is now complete, and transaction log replication and replay will now occur automatically.

Note:
The location of the production database folder can be found on either the Summary page or the Properties page.

Note:
Seeding is complete when the file is copied. Client access is restored after the production database has been mounted.

Note:
Seeding is now complete, and transaction log replication and replay will now occur automatically.

To use the Update Storage Group Copy wizard to seed the passive node

Open the Exchange Management Console on the passive node.
Expand Server Configuration, and then select Mailbox.
In the result pane, select the Mailbox server that contains the storage group that you want to update.
In the work pane, right-click the storage group to be updated, and then select Update Storage Group Copy. The Update Storage Group Copy Wizard appears.
Verify that the correct storage group is listed in the Storage group name field. If the wrong storage group was selected, click Cancel, exit the wizard, and select the correct storage group. If there are any existing log files in the passive copy of the storage group that are not viable or needed for log replay after seeding has completed, select the Delete any existing log files in the target path check box. Click Next to continue.

Click Update to seed the passive node with the database copy.

Note:
During the update process, you will be prompted to delete any obsolete checkpoint files that are found in the passive copy of the storage group, and any existing database file that is found in the passive copy of the storage group.

After seeding has completed, click Finish to exit the wizard.

For More Information

For more information about the Exchange Management Shell cmdlets described in this topic, see:

For more information about managing your CCR environment, see Managing Cluster Continuous Replication.