Important: We are no longer supporting Enterprise Vault migrations using in-flight stub rehydration. This documentation is available only for reference purposes; it will be archived soon.
Enterprise Vault Migrations Using In-Flight Stub Rehydration: Overview
This overview provides general guidance for using BitTitan MigrationWiz to execute an archive migration from Enterprise Vault using in-flight stub rehydration. In-flight stub rehydration is a process provided by BitTitan MigrationWiz.
Rehydrating stubs reconstructs the archived email message by recombining the stub with the original message body along with attachments, if any. Rehydrating stubs is necessary when migrating archived email, contacts, and calendar items out of a legacy archiving system, if those archives rely on stubs in Exchange.
Stub rehydration has traditionally taken place on the Source system or on the Destination system, but both of these approaches have drawbacks.
- Rehydrating stubs on the Source results in "exploding" the volume of data in your Source Exchange server. If you have sufficient space on the Source server to handle the volume of archived data, then your migration may succeed. However, running out of space during the migration will cause the migration to fail.
- Rehydrating stubs on the Destination creates different issues. Because migrating your archive to the Destination may take some time (weeks, and perhaps months for extremely large systems), the link between the stubs in user mailboxes and the archived message is broken for the duration of the migration, making archived messages inaccessible during that period. This can be a big headache during enterprise-grade migrations.
MigrationWiz overcomes these issues by introducing in-flight stub rehydration (IFSR), which executes stub rehydration while the migration is in progress. This provides efficiencies, as well as avoiding the issues created with Source- and Destination-based rehydration.
Enterprise archive migrations
Migrating an email archive is challenging because, if improperly done, you can break the link between the stubs and their associated email, which makes the stubs useless and the archived messages orphans, which is a potentially catastrophic outcome.
Failing to plan for stub management can bring pain to your end users, especially to the IT team supporting them. The central concern is If I have stubs, what do I do with them? You can choose to ignore stubs and simply delete them, but most commonly you'll want to preserve them. The best option, then, is rehydrating the stubs and moving the reconstituted messages to your new Destination.
In-Flight stub rehydration workflow
In-flight stub rehydration follows a complex workflow that touches four environments: the Source and Destination environments, Enterprise Vault file and database servers, and MigrationWiz (see Figure 1). Fortunately, MigrationWiz hides almost all of the complexity and requires only that you correctly set up, configure, and execute your MigrationWiz project.
Here is an overview of the IFSR workflow, which is diagramed in Figure 1. Numbers in the diagram are referenced in the text following.
Figure 1. In-flight stub rehydration workflow.
The customer Source site has an Exchange Server, which contains the message stubs. It also contains a virtual machine, on which the extractor agent is installed. You download an install the extractor from the MigrationWiz UI while setting up your migration project.
- The extractor agent communicates with the MigrationWiz, whose connector service polls Exchange on the Source to identify message stubs. This is the sense in which MigrationWiz is said to be "stub-aware." The message stubs in Exchange contain pointers to their archived message bodies, plus each one's attachments.
- The archived message bodies and their attachments are stored on file servers in Enterprise Vault. Mailbox user information is stored as an Active Directory (AD) user object in a SQL Server instance. AD is used to associate the archive to users.
- When MigrationWiz detects a message stub, it contacts the extractor agent, which in turn tracks the pointer into Enterprise Vault and retrieves the archived message and hands it back to MigrationWiz.
- The worker process in MigrationWiz reassembles the message and its attachments, if any, and queues the messages for migration.
- MigrationWiz then migrates the rehydrated message to the desired Destination.
The Destination system can be Office 365 mailboxes or Exchange Online archive mailboxes, or other message system of choice.
Limitations of in-flight stub rehydration
While stub rehydration is feasible in nearly all migration scenarios, to implement in-flight stub rehydration using MigrationWiz, there are some limitations:
- The extractor agent at the Source (see Figure 1) has a limit of 20 simultaneous connections. However, you can overcome this by spinning up multiple instances of the extractor agent.
- Presently, MigrationWiz can implement in-flight stub rehydration only in cases where the archive Source is Enterprise Vault, only versions 9 and 10. Additional Source archives will be supported in the future.
- You cannot implement in-flight rehydration if your Source is configured as a "hybrid" environment, where its components are segmented between on-premises and cloud-based installations.
- In-flight rehydration does not act on journal items.
- In-flight rehydration acts only on message items that are associated with message stubs that live in Exchange at the Source.
- BitTitan cannot migrate items in vault stores that are not associated with a vault store group; that is, when a vault store’s group version field is empty.
For more information, see the white paper attached below.