Enterprise Vault to Office 365
The following is a general recommendation for large journal migration projects using the journal transformation process based on the current understanding of the project. Additional hardware may be needed depending on expected performance of the migration.
High level requirements
·Bridgehead servers: 2 per EV server to run EV Export and Office 365 Import modules.
·Staging areas: 1 per EV server sized to the largest individual journal on the server (1.2-1.5x).
·Office 365 service accounts (five per Bridgehead server).
·Available Exchange Online licenses (around 100).
·Remote access for managed migration.
Machine specifications and additional information
Core server
·Windows Server 2012R2, 2016, 2019 and 2022.
·Minimum 4 CPU (recommended 8 CPU).
·Minimum 8GB RAM (recommended 16GB RAM).
·IIS 7.5 or later is required.
SQL server
·Windows Server 2016, 2019
·SQL server 2016, 2017.
oEnterprise Edition highly recommended
oUse the latest versions (Windows 2016/2019, SQL 2016/2017).
oMinimum 16 CPU, recommended 32 CPU (cores or vCPUs).
oIf using less than 32 cores, please ensure that CPU clock speed is equal to or more than 2.8Ghz.
oMinimum 512GB RAM (recommended 1TB RAM)
·SQL storage
oDisks should be configured as per Microsoft SQL server best practices with TempDB, databases and logs separate disks.
oAssume approximately 5K per item (as shown in the EV usage report) when sizing the storage for database. This is dependent of the number of recipients per message and is only an initial estimate.
oUse fast tier 1 disk arrays, SSD is recommended.
·The SQL server must be treated as you would a production server.
oMaintenance plans including full backups are the responsibility of the customer. Click here for more information.
Remote access for managed migrations
Customer must provide access to assigned staff with sufficient privileges to administer any system involved in the project. Specifically, the following:
·Required
oAccess to Archive Shuttle core server
·Optional, but highly recommended
oAccess to module servers (bridgehead servers)
oAccess to SQL server or MSSQL Management Studio
oAccess to staging areas
·Remote access to the on-premises server(s) for the Delivery and Operations teams is required, either through Citrix VDI, VPN, or other remote access technology.
|
|
NOTE: WebEx is not suitable nor is anything that requires the customer to initiate the session. |
Bridgehead servers (two per EV server)
·Windows Server 2012 R2, 2016 or 2019.
·Minimum 4 CPU (recommended 8 CPU).
·Minimum 16GB RAM (recommended 32GB RAM).
·.net 3.5.1.
·.net 4.6.2 or later.
·Microsoft Graph PowerShell module
Staging areas (one per bridgehead server)
·Volume sized to the largest individual journal on the EV server (1.2-1.5x).
oShared via SMB; can be attached to the bridgehead server, recommended on a datastore with a fast disk, or on fast NAS storage.
Available Office 365 (EXO) licenses
·The process of finalizing and managing leaver mailboxes in Office 365 requires Archive Shuttle to have licenses to work with during the migration.
·It is recommended to have around 100 licenses to ensure that Archive Shuttle can migrate to as many targets at once (parallelism), and finalize leaver mailboxes.
·These licenses would only be needed during the migration (finalization and management of leavers will be removed and and returned as soon as the migration is complete.
·The number of licenses Archive Shuttle has access to heavily affects the overall performance.
Office 365 throttling limits
In order to achieve the best migration performance possible, it is recommended to contact Microsoft and request that throttling be lifted. Click here for more information.
Globally increase message size limit from 25 MB (optional)
Click here for more information on size limits when ingesting into Office 365.
Anti-virus exclusions
Generally, Archive Shuttle requires anti-virus exclusions on any machine running the Archive Shuttle modules. This would include EV servers in addition to the bridgehead server (ingest server):
·Exclude staging area volumes
·Disable Real-time scanning
·Disable In memory scanning (if available)
Click here for more information.
Journal archive folder split settings
When migrating a large source journal archive into a target, you might want to implement and use Folder Splitting functionality in Archive Shuttle, as well as archive splitting. This article explains why.
When migrating from a source archiving system, such as Enterprise Vault, to a new target archiving system, such as Enterprise Vault, there is usually no need to split the source archive in terms of the archive itself, or into new folders (and subfolders).
However, if the migration is to Exchange or Office 365, then it is often desirable for several reasons:
·Office 365 and Exchange have limits on the number of items that can be stored in individual folders.
·Performance in relation to viewing folders that contain millions of items is poor when using Outlook-type clients (MAPI based).
·Mailbox or Personal Archive size limits on the target may prevent a large journal archive being ingestable into a single target container.
For these reasons, splitting at the folder level (which is a configuration of the Enterprise Vault Collector module) is desirable and easy to do. Splitting at the archive level by querying Enterprise Vault and counting the number and size of items in the journal archive per day, per week, per two weeks, or per month. Once a suitable splitting range has been defined, filters based on a date can be implemented in Archive Shuttle, and the source archive can be mapped multiple times to different target archives with different filters.
User Interface
When migrating a journal archive, using the Archive Shuttle folder splitting feature is recommended since many target environments have limits on the number of items that can be in a single folder.
These settings can be found on the Configuration > General System Settings page.
The settings are:
·Journal Split Base Folder Name: This is the name of the top-level folder that will be split when items are ingested into the target environment.
·Journal Split Threshold: This is the number of items that should be placed in each folder before a new folder is created.
The settings above can be applied only for Enterprise Vault and SourceOne sources.
Other sources (like EAS, DAM/QAM, and PST) are not supported. This is because they are unable to recognize the journal archive as a specialized container and are treated like a normal archive. For EAS, DAM/QAM, and PST sources, the large folder setting named Split threshold large folders (except journal / folderless) can be applied on their journal archive.
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.