Dan from this week’s Exchange 2010 (10135) class asked a great question. “Chad, you mentioned that if you have to create a DB copy of a file that would be potentially 200-300gb, you could “Seed” the other server with a copy of the database to reduce network traffic.

I was able to locate this documentation for ya bud! from our friends @ TechNet – Managing Mailbox Database copies

 

Seeding a Database Copy

Seeding, also known as updating, is the process in which a database, either a blank database or a copy of the production database, is added to the target copy location on another Mailbox server in the same database availability group (DAG) as the production database. This becomes the baseline database for the copy maintained by that server.

Depending on the situation, seeding can be an automatic process or a manual process that you initiate. When a database copy is added, the copy will be automatically seeded, provided that the target server and its storage are properly configured. If you want to manually seed a database copy and don’t want automatic seeding to occur when creating the copy, you can use the SeedingPostponed parameter when running the Add-MailboxDatabaseCopy cmdlet.

Database copies rarely need to be reseeded after the initial seeding has occurred. But if reseeding is necessary, or if you want to manually seed a database copy instead of having the system automatically seed the copy, these tasks can be performed by using the Update Database Copy wizard in the EMC or by using the Update-MailboxDatabaseCopy cmdlet in the Shell. Before seeding a database copy, you must first suspend the mailbox database copy. For detailed steps to seed a database copy, see Update a Mailbox Database Copy.

After a manual seed operation has completed, replication for the seeded mailbox database copy is automatically resumed. If you don’t want replication to automatically resume, you can use the ManualResume parameter when running the Update-MailboxDatabaseCopy cmdlet.

  Choosing What to Seed

When performing a seed operation, you can choose to seed the mailbox database copy, the content index catalog for the mailbox database copy, or both the database copy and the content index catalog copy. The default behavior of the Update Database Copy wizard and the Update-MailboxDatabaseCopy cmdlet is to seed both the mailbox database copy and the content index catalog copy. To seed just the mailbox database copy without seeding the content index catalog, use the DatabaseOnly parameter when running the Update-MailboxDatabaseCopy cmdlet. To seed just the content index catalog copy, use the CatalogOnly parameter when running the Update-MailboxDatabaseCopy cmdlet.

  Selecting the Seeding Source

In Exchange 2007, continuous replication could only seed a database copy by copying the active copy of the database. In Exchange 2010, any healthy database copy can be used as the seeding source for an additional copy of that database. This is particularly useful when you have a DAG that has been extended across multiple physical locations. For example, consider a four-member DAG deployment, where two members (MBX1 and MBX2) are located in Portland, Oregon and two members (MBX3 and MBX4) are located in New York, New York. A mailbox database named DB1 is active on MBX1 and there are passive copies of DB1 on MBX2 and MBX3. When adding a copy of DB1 to MBX4, you have the option of using the copy on MBX3 as the source for seeding, and in doing so, you avoid seeding over the wide area network (WAN) link between Portland and New York.

To use a specific copy as a source for seeding when adding a new database copy, you would do the following:

  • Use the SeedingPostponed parameter when running the Add-MailboxDatabaseCopy cmdlet to add the database copy. If the SeedingPostponed parameter isn’t used, the database copy will be explicitly seeded using the active copy of the database as the source.
  • Use the SourceServer parameter when running the Update-MailboxDatabaseCopy cmdlet and specify the desired source server for seeding. In the preceding example, you would specify MBX3 as the source server. If the SourceServer parameter isn’t used, the database copy will be explicitly seeded using the active copy of the database as the source.

  Seeding and Networks

In addition to selecting a specific source server for seeding a mailbox database copy, you can also specify which DAG networks to use, and optionally override the DAG network’s compression and encryption settings during the seed operation.

To specify the networks you want to use for seeding, use the Network parameter when running the Update-MailboxDatabaseCopy cmdlet and specify the DAG networks that you want to use. If you don’t use the Network parameter, the system uses the following default behavior for selecting a network to use for the seeding operation:

  • If the source server and target server are on the same subnet and a replication network has been configured that includes the subnet, the replication network will be used.
  • If the source server and target server are on different subnets, even if a replication network that contains those subnets has been configured, the client (MAPI) network will be used for seeding.
  • If the source server and target server are in different datacenters, the client (MAPI) network will be used for seeding.

At the DAG level, DAG networks are configured for encryption and compression. The default settings are to use encryption and compression only for communications on different subnets. If the source and target are on different subnets and the DAG is configured with the default values for NetworkCompression and NetworkEncryption, you can override these values by using the NetworkCompressionOverride and NetworkEncryptionOverride parameters, respectively, when running the Update-MailboxDatabaseCopy cmdlet.

  Seeding Process

When you initiate a seeding process by using the Add-MailboxDatabaseCopy or Update-MailboxDatabaseCopy cmdlets, the following tasks are performed:

  1. Database properties from Active Directory are read to validate the specified database and servers, and to verify that the source and target servers are running Exchange 2010, they are both members of the same DAG, and that the specified database isn’t a recovery database. The database file paths are also read.
  2. Preparations occur for reseed checks from the Microsoft Exchange Replication service on the target server.
  3. The Microsoft Exchange Replication service on the target server checks for the presence of database and transaction log files in the file directories read by the Active Directory checks in step 1.
  4. The Microsoft Exchange Replication service returns the status information from the target server to the administrative interface from where the cmdlet was run.
  5. If all preliminary checks have passed, you are prompted to confirm the operation before continuing. If you confirm the operation, the process continues. If an error is encountered during the preliminary checks, the error is reported and the operation fails.
  6. The seed operation is started from the Microsoft Exchange Replication service on the target server.
  7. The Microsoft Exchange Replication service suspends database replication for the active database copy.
  8. The state information for the database is updated by the Microsoft Exchange Replication service to reflect a status of Seeding.
  9. If the target server doesn’t already have the directories for the target database and log files, they are created.
  10. A request to seed the database is passed from the Microsoft Exchange Replication service on the target server to the Microsoft Exchange Replication service on the source server using TCP. This request and the subsequent communications for seeding the database occur on a DAG network that has been configured as a replication network.
  11. The Microsoft Exchange Replication service on the source server initiates an Extensible Storage Engine (ESE) streaming backup via the Microsoft Exchange Information Store service interface.
  12. The Microsoft Exchange Information Store service streams the database data to the Microsoft Exchange Replication service.
  13. The database data is moved from the source server’s Microsoft Exchange Replication service to the target server’s Microsoft Exchange Replication service.
  14. The Microsoft Exchange Replication service on the target server writes the database copy to a temporary directory located in the main database directory called temp-seeding.
  15. The streaming backup operation on the source server ends when the end of the database is reached.
  16. The write operation on the target server completes and the database is moved from the temp-seeding directory to the final location. The temp-seeding directory is deleted.
  17. On the target server, the Microsoft Exchange Replication service proxies a request to the Microsoft Exchange Search service to mount the content index catalog for the database copy, if it exists. If there are existing out-of-date catalog files from a previous instance of the database copy, the mount operation fails, which triggers the need to replicate the catalog from the source server. Likewise, if the catalog doesn’t exist, and it doesn’t on a new instance of the database copy on the target server, a copy of the catalog is required. The Microsoft Exchange Replication service directs the Microsoft Exchange Search service to suspend indexing for the database copy while a new catalog is copied from the source.
  18. The Microsoft Exchange Replication service on the target server sends a seed catalog request to the Microsoft Exchange Replication service on the source server.
  19. On the source server, the Microsoft Exchange Replication service requests the directory information from the Microsoft Exchange Search service and requests that indexing be suspended.
  20. The Microsoft Exchange Search service on the source server returns the search catalog directory information to the Microsoft Exchange Replication service.
  21. The Microsoft Exchange Replication service on the source server reads the catalog files from the directory.
  22. The Microsoft Exchange Replication service on the source server moves the catalog data to the Microsoft Exchange Replication service on the target server using a connection across the replication network. After the read is complete, the Microsoft Exchange Replication service sends a request to the Microsoft Exchange Search service to resume indexing of the source database.
  23. If there are any existing catalog files on the target server in the directory, the Microsoft Exchange Replication service on the target server deletes them.
  24. The Microsoft Exchange Replication service on the target server writes the catalog data to a temporary directory called CiSeed.Temp until the data is completely transferred.
  25. The Microsoft Exchange Replication service moves the complete catalog data to the final location.
  26. The Microsoft Exchange Replication service on the target server resumes search indexing on the target database.
  27. The Microsoft Exchange Replication service on the target server returns a completion status.
  28. The final result of the operation is passed to the administrative interface from which the cmdlet was called.

Advertisements