Permissions requirements
In general, requirements relating to permissions can be split into two categories:
·Accounts / Permissions needed for running the Core
·Accounts / Permissions needed for running the modules
Each of those can use independent permissions. In fact, if required, each module can use independent permissions from each other module. And that account can be different from the one running the Core.
Installing the Core typically requires a plain domain service account with Local Admin permissions on the machine and the dbcreator role on SQL. Installing Modules requires a plain domain service account with Local Admin permissions (for the install only) and then different permissions, depending on the role of the module.
·Core: Local Admin
·Module: Local Admin
·SQL: DBCreator
·Staging: Full rights for Module users
Sources/targets:
·Enterprise Vault: EV Service Account
·Exchange / Office 365: Domain service account with Local Admin rights (to run the module)
·Exchange: Multiple accounts with Application Impersonation will be added to our Credential Editor
·Office 365: An Entra ID Registered Application will be added to our Credential Editor. The Registered Application will need Application Impersonation rights and additional permissions. See Using OAuth Authentication for Office 365 migrations in the Archive Shuttle Planning Guide.
Additional requirements for imports to Exchange
|
|
NOTE: This section is for ingesting data into Exchange 2010 SP 2 or later. |
Additional Permissions (Exchange 2010 SP 2 or later)
The Archive Shuttle Exchange Import module ingests data in to Exchange mailboxes or Personal Archives using MAPI. However, certain messages may fail to ingest using this mechanism even after a number of retries. By default the module will fall back to use Exchange Web Services (EWS) when this situation arises.
In order to support this failback, the service account that is being used to ingest the data must be granted an additional role within Exchange.
An example of the PowerShell command that can be used to grant this extra permission is shown below:
[PS] C:\>New-ManagementRoleAssignment -Name:VaultAdminImpersonization -Role:ApplicationImpersonation -User: ADomain\TheUser
Additional Permissions (Exchange 2010 SP1 or earlier)
Ingestion to versions of Exchange 2010 SP 1 or earlier can be done by using EWS only. This means that the ingest provider order, on the System Configuration page, should be updated to show just EWS.
In order to support this feature, the service account that is being used to ingest the data must be granted an additional role within Exchange.An example of the PowerShell command that can be used to grant this extra permission is shown below:
[PS] C:\>New-ManagementRoleAssignment -Name:VaultAdminImpersonization -Role:ApplicationImpersonation -User: ADomain\TheUser
Recommended Bitness
It is recommended to use 64 bit modules when ingesting data into Microsoft Exchange. In many environments an ingest bridgehead server is used to perform the ingest, and whilst the machine (physical or virtual) may have 16 Gb or more RAM, out of memory errors may be observed from time to time if the regular, 32 bit modules are used.
To use the 64 bit modules it will be necessary to install 64 bit Outlook, and then the 64 bit modules. These modules will utilize RAM beyond the normal 2 Gb Windows process limit allow for faster and more reliable migrations to take place.