Journal Splitting
Archive Shuttle Journal Splitting setup
The Office 365 Virtual Journal feature brings with it the possibility to migrate large journal archives to Office 365, using multiple target mailbox/personal-archives and specifying criteria such as number of items and size of target. This article explains more detail about this splitting process.
There are two ways that data can be split:
Number of Items
This is the simplest form. The splitting to a new mailbox/personal-archive occurs when the specified number of items are routed to the target mailbox or personal archive.
Size of Items
The splitting here is determined by the size of the items from the source environment. In the case where migration is from Enterprise Vault, the size used is the larger of the original size versus compressed size. When the amount of data routed to a target container reaches the specified value, a new target container will be created.
Journal archives in source environments are typically large. Their multiple terabyte nature makes it currently quite hard to migrate the data to Office 365 as there are limits imposed by Microsoft on both the mailbox and personal archive sizes. To be able to migrate a large journal archive to Office 365, the product introduced a concept of a Journal Splitting.
There are two processes in migrating a journal archive to Office 365. This can be via Journal Splitting or a Journal Transformation. Below are the steps for Journal Splitting.
The general process for doing this is:
1.Define the naming scheme for the target. It is suggested to prefix or postfix names, eg AL- or -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.Decide on the type of hold to place on the migrated data.
4.Configure the maximum number of items allowed per child container, and maximum size allowed.
5.Perform the mapping.
In the background what will happen is:
1. Provisioning
a.A user account will be created according to the naming scheme.
b.A Personal Archive will be created if it was required in the mapping.
c.The mailbox/personal archive will be placed on the selected type of hold.
d.A license will be assigned from the pool.
e.The data from Office 365 about the user will be synchronized.
2. Migration
a.Data will be exported after the provisioning process is done.
b.Data will be imported soon after it is exported, when a particular child container is full, as determined by the system settings, a new one will be created.
3. Stage 2
a.The license which was assigned in order to be able to ingest data in to the mailbox (or Personal Archive) will be removed (usually as the last step) and returned to the pool so that another mapping can take that license and complete the provisioning step.
Transformation
Journal Transformation information can be found here.
Suggested values for splitting journal data
This article gives an indication of some suggestions relating to splitting of data when migrating with Archive Shuttle.
Virtual Journal Total Mailbox Item Count Limit
900,000 items
Virtual Journal Total Mailbox Item Size Limit (MB)
80 Gb, this way it is lower than the normal size allowed for a personal archive
Journal Split Base Folder Name
This is a customer/migration dependent, or can be left at the default
Journal Split Threshold
100,000 items, this way if it is ever necessary to open a mailbox it wont cause too many problems if using Outlook.
Convert journal messages to Office 365 journaling format
Occasionally, before migrating Journal messages from Enterprise Vault to Office 365, it is important to consider if want to have migrated the entire envelope, or just the P2.
Archive Shuttle has a Convert Journal messages to Office 365 Journaling Format setting on Office 365 module tab in System Configuration, and this setting works as follows:
a) If unchecked (default), it will migrate the whole envelope (P1 and P2) to Office 365. In the Compliance Center, then you can do a search, because envelopes were implemented in the search functionality.
Journal message migrated with P1 and P2 item to Office 365:
b) If checked, it will migrate only the P2 message and will remove the P1 header. The metadata of the P1 message (DL Expansion, BCC etc.) is then put into special properties of the P2. Because of this, Office 365 Compliance Search can find them.
Journal message migrated with P2 item to Office 365:
In the background, once Archive Shuttle collected information from the P1 message, it will create new properties and store the P1 info into them.
|
|
NOTE: Archive Shuttle does not currently support only ingesting P1 and stripping P2. |
Considerations when enabling the option
·If you wish for the items to be migrated much more as-is, i.e. matching the source system, then do not enable the option.
·If you wish for the items to be more inline with the way that Office 365 does this natively, then the option should be enabled.
·If you are doing a Journal Transformation migration, then the option is enabled silently, and can not be disabled.
·When looking at emails from a compliance point of view, messages stored with the GERP attribute contain information about who got the original email, but not the why they got the email (that information is stored in the P1 message, for example, the message was sent to a distribution that contained a particular recipient)
·Office 365 works with either formatted message.
·Migrating data with the P1 & P2 data means that the P1 data becomes a free-text search, whereas enabling the option to convert the journal message (and adding the information to the GERP attribute) means it is a fully indexed property of the message. Confusion can arise if you search for mails to X, if P1 & P2 data is migrated, this type of query may return fewer results. Instead, you should perform a free-text search instead, but then it is not possible to search for mails o X in the same way.
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.