Enterprise Vault 10.0.0.4 or later source
Prerequisites
It is essential that the following steps have been completed prior to beginning the migration:
·All Modules are enabled
·Appropriate Active Directory Domains is enabled for scanning
·An Enterprise Vault Environment has been added for migration
·A Link Database has been created for the source archive
·Module Mappings are configured for the source Vault Store and also the target Vault Store
Map containers - For the Journal Archive
The first thing to do when migrating a journal archive to a new vault store is to do a container mapping. This is slightly different than the process followed earlier in the document since Archive Shuttle must do a single container mapping.
To setup the mapping, follow these steps:
1.Navigate to the Bulk Mapping or Manual Mapping page.
2.Type the beginning of the archive name in the Name filter. Click the Apply button at the right of the filter row.
3.Select the checkbox next to the archive, and click Add Mappings from the navigation bar.
|
|
NOTE: A short wizard will start, which gathers information relating to the mapping for the archive. |
4.The destination of the migration can then be chosen from the available list and then subsequent pages of the wizard will prompt for further information.
|
|
NOTE: It is recommended that a workflow policy is created that suits the requirements, or the Journal Archive workflow is chosen. |
Set Policies and Enable Migration
Once the container mapping has been selected, it is necessary to add two more components to the link, before the migration can be enabled.
To setup the migration, follow these steps:
1.Click Existing Mappings.
|
|
NOTE: All the normal filtering and searching is available on the Existing Mapping screen, which can help identify the mapping. |
2.Locate the mapping that was created in the previous step.
3.Select the checkbox next to the mapping.
4.From the toolbar, select Set Workflow Policy and choose the Journal Workflow.
5.From the toolbar, select Set Filter Policy and choose a filter if one is required.
6.Finally, from the toolbar select Enable for Migration and Enable Item Gathering.
|
|
NOTE: The container mapping will now look much like other mappings that may have been created. Ensure that the Item Gathering and Migration Enabled flags are displayed before moving on to monitoring the migration. |
Monitoring the Migration
Monitoring the Stage 1 synch process for a journal archive is the same as with other types of archive migration. A few minutes after setting the policies and enabling migration (see previous section), the container will appear on the Stage 1 (Sync Data) screen in the administration console.
Performing Stage 2 and Extra Steps
Migrating a journal archive is slightly different to migrating an ordinary Enterprise Vault archive. There are a few additional steps, as outlined below:
1.Stop the Enterprise Vault Journal Task, and set the startup of the task to Disabled.
|
|
NOTE: The journal mailbox that the task was targeting will now start to grow in size because Enterprise Vault is no longer processing items from it. |
2.Go to the Stage 1 (Sync Data) screen.
3.Locate the container mapping for the journal archive, and select the check box next to it.
4.From the toolbar, select Enable Stage 2.
5.After a few minutes, observe the Stage 2 (Switch User) screen and ensure that after a few more minutes the migration is marked as complete.
The Journal Archive has now been moved to a new Vault Store, and a new archive. The final step is to change the journaling process in Enterprise Vault. Usually this is a matter of changing the journal target to be the new archive, and restarting the journal task after setting the task startup back to Automatic.
|
|
NOTE: Depending on the migration being performed, it may also be necessary to reconfigure the Exchange journaling configuration to journal to the new mailbox. |
Performing the journal mapping
Once the configuration changes have been made, then the journal archive can be mapped in the normal way except that you should choose the option in the wizard to process the mapping as journal splitting.
Migrating a shared mailbox archive
This section outines the steps that are necessary to complete the migration of an archive shared amongst a group of users. The migration will be from one Enterprise Vault environment to another.
In Enterprise Vault, this may simply be a regular mailbox archive so that is maintains the structure from the mailbox where the data comes from. The mailbox itself will ultimately have one true owner in Active Directory, but a number of other users and/or groups may also have access to both the mailbox and the archive.
Capture Permissions on the Source
There a number of ways in which the permissions can be shown for an archive, including the following:
·Open the properties of the archive in the Vault Administration Console, and check the entries on the permissions tab
·Use a script similar to the one provided on the Symantec Connect web site:
Build an EVPM File
From the list of permissions on the source archive an EVPM file should be built. There are details about the way to use EVPM in the Enterprise Vault Utilities Guide. At a high level the steps are:
·Directory section should contain information about the Enterprise Vault Directory computer and Enterprise Vault site name.
·A section should be added called ArchivePermissions
·The Archive Name property should be added to this section with the name of the archive.
·The Grant Access property should be added to this section with a list of people to grant access to the archive. This should be listed one per line.
Perform the Migration
The migration of the archive/container can then be performed. Particular care should be taken in relation to migrating these types of archives/containers because the migration has an impact on a number of people.
Apply the EVPM File
Following the successful migration of the Shared Mailbox / Archive, the EVPM file that was created previously should be run to grant permissions on to the target/new archive.
Migrating leavers to Office 365
Archive Shuttle can manage a pool of licenses to provision and migrate data to Office 365 mailboxes or archives whose source archives have been retained but owners have left the organization. It can even treat an archive as though it is ownerless, and migrate it using this process, even if an owner is shown in the user interface.
The general process for doing this is:
1.Define the naming scheme for the target. It is suggested to prefix or postfix names, ex. AL-<archivename> or <archivename>-Departed. This makes the data easier to find in the target after the migration has completed.
2.Define the allowed number of rolling licenses.
3.Perform the mappings.
In the background what will happen is:
Provisioning
1.A user account is created according to the naming scheme.
2.A Personal Archive is created if it was required in the mapping.
3.A license is assigned from the pool.
4.The mailbox/personal archive is placed on litigation hold.
5.A license is assigned from the pool.
6.The data from Office 365 about the user is synchronized into Archive Shuttle.
Migration
1.Data is exported after the provisioning process is done.
2.Data is imported soon after it is exported.
Stage 2
1.The familiar parts of the workflow still occur, such as renaming the source archive and doing a final delta.
2.The user associated with the mailbox targeted is removed; resulting Office 365 processes are to reclaim the license and treat the mailbox in an inactive status. The mailbox is removed in Stage2 with the RemoveMailbox command.
Items which belonged in a mailbox can be searched via eDiscovery. Click here for more information.
How to set this up is described here.
Requirements
The normal Office 365 migration requirements are necessary (see the earlier section). In addition, note that Azure management tools are required. These can be downloaded from: https://msdn.microsoft.com/en-us/library/azure/jj151815.aspx
If these components are not installed, the normal Office 365 migrations will still be successful, but processing of leavers will not be successful. They can be added at any time during the migration; it is not necessary to reinstall or modify the Office 365 module following their installation.