Sizing the PST output location
If Archive Shuttle is being used to extract data to PST files, the sizing of the PST Output location is important and should be carefully considered.
Consider the following options when sizing the storage area:
·It does not have to be locally attached storage to the Native Format Import Module. Network attached storage is supported.
·No data is written to the location until Stage 2 is activated for the chosen containers.
·Typically the space required for a PST file export of an archive will be almost double the size of the source archive.
|
|
NOTEs: ·PST files will be created by default of about 2 GB in size. A lower size can be set in the UI if required. ·The export item size estimate when importing using the Native Format Import module may be larger in the UI than the estimated size in the database. |
How to change folder translations
By going to System Configuration > General > Folder, you are able to add, remove and change the translation for new and existing folders.
Clicking on the Edit button brings up a pop-up menu, showing the list of labels of folders. Clicking one gives you a list of translations on the right pane.
You can edit the translations on the right hand pane by selecting one, or add a new translation by selecting the end of a translation and pressing Enter. You can edit as many folders as you wish, and once you are done, click Save, then Save in the top right. This is logged in the database dbo.MailboxFolderTranslation.
|
|
NOTES: ·Folder Translation is working only for Exchange 2013 and higher versions of Exchange mailboxes, as well as for Exchange Online mailboxes. ·Folder Translation is working only for root folders, not for split folders, therefore all split folders will use language of the source archive. |
Preserving the Chain of Custody
Archive Shuttle performs a number of operations in order to preserve and verify the Chain of Custody of data items during a migration. This section explains some of those which need to be taken into account in a migration.
Item level hashing
When an item is exported from a source environment. a hash is generated for that item and stored in the Archive Shuttle Item database. Sometime later, when the item is ingested, the hash is recomputed and compared with that stored value.
If the hashes do not match, a Chain of Custody violation is logged and the item will by default be re-exported and re-migrated.
|
|
NOTE: If a significant number of Chain of Custody alerts are reported, it is likely that anti virus is touching the files after they have been stored on the staging area. |
Migration-level hashing
As Archive Shuttle is performing the hashing on the items as mentioned in the previous section, a hash is generated on the whole message file, in order to avoid tampering during the migration.
Watermarks
When migrating from EV to EV Archive Shuttle adds a custom index entry to migrated item. This entry contains:
·Migration Time UTC
·Source Archive ID
·Source Transaction ID
·Archive Shuttle Version
When migrating from EV to Exchange, Archive Shuttle adds the same information to each migrated item as MAPI properties.
Retained databases
Following the migration, in case of Chain of Custody queries, you may consider retaining the Archive Shuttle SQL databases.
Migrating leavers data and journal archives
When performing a migration with Archive Shuttle a question which arises and needs to be addressed is whether to migrate leavers data if journal migration is being performed.
Journal archives contain messages from everyone inside the organization, and all inbound and outbound communications. It has messages from everyone in the company now, and everyone that left the company over the preceding years. The tricky part is determining when journal archiving was turned on. That can affect whether or not you need to migrate just the journal archive, or the journal archive and leavers data.
Lets look at a couple of examples.
Example 1
Lets say Bob works for the organization now, and has been working for the organization for 3 years. Jane doesnt work for the company any more, she joined about 18 months ago and left 3 months ago.
Journal archiving has been in place for 5 years.
In this example, the data which would be in Bobs archive will be in the journal archive. The data which would be in Janes leaver archive will also be in the journal archive. Therefore, the organization could make the decision that they do not need to migrate that leaver archive.
Example 2
Lets say Sarah has been working for the company for 6 months. Lets say David is a leaver, he left 3 months ago, and has been working for the company for 7 years.
Journal archiving has been in place for 5 years.
In this example the data in Sarahs archive will be in the journal archive, but not all of the data in Davids leaver archive will be in the journal archive. Therefore, the organization could make the decision that they do need to migrate Davids data as well as the journal archive.
This comparison would need to be done across all leaver archives before an overall decision could be reached, and ultimately its the organizations decision to migrate the data or not.