Additional details on Enterprise Vault to Enterprise Vault migrations
Introduction
This section explains what the requirements are for an Enterprise Vault (EV) to Enterprise Vault migration, and then covers the basic steps that should be followed to start such a migration.
Requirements
The following is a list of requirements.
|
Requirement |
Description |
|---|---|
|
Modules installed on source |
The EV-type modules should be installed on each appropriate source Enterprise Vault server involved in the migration. The EV import module is not required on these machines. |
|
Modules installed on target |
The EV-type modules should be installed on each appropriate target Enterprise Vault server involved in the migration. The EV export module is not required on these machines. |
|
AD Collector module installed |
An AD Collector module should be installed so that it can collect user-level information for the migration project. |
|
Staging Area created |
One or more staging areas should be setup, of an appropriate size and should be excluded from virus scanners. |
|
Workflows reviewed |
The Stage 2 workflows should be reviewed, and if necessary, customized to meet the needs of the project. |
|
Apply appropriate failed item threshold |
It is best practice to find an appropriate failed item threshold for the project/customer and apply that at the links level. This way all mappings which are created will inherit this value. |
Basic steps
The following are the basic steps to start this type of migration.
|
Step |
Screen |
Description |
|---|---|---|
|
Enable Modules |
Modules |
All Archive Shuttle modules must be enabled, and optionally a schedule for them defined. It is important to verify that none of the modules have a red background (this indicates that Archive Shuttle Core has not had contact with the module) and that the module versions are as expected. |
|
Enable Domains |
Active Directory |
Select and enable one or more domains for synchronization. |
|
Add Source EV Environment |
EV Environment |
Add the Enterprise Vault source environment. |
|
Add Target EV Environment |
EV Environment |
Add the Enterprise Vault target environment. This is not necessary if both the source and target are the same. |
|
Add Retention Category Mappings |
Retention Category Mappings |
Map the source and target environment retention categories. If the migration is intrasite, they can be automatically created in the admin interface. |
|
Add Source Links |
Links |
Configure all appropriate source links. Select the links, and then click on Map Modules, create the item database(s) and enable archive gathering. Ensure there is no import module specified on the links as this may impact the process later on. |
|
Add Target Links |
Links |
Add all appropriate target links. An EV Collector module should be associated with one of the links so that shortcut building information can be gathered from the site settings in Enterprise Vault. |
|
Add Staging Area |
Links |
Ensure that the Default Staging Area is configured correctly. Depending on the migration, the free space, and the number of vault stores being used as the source for the migration, the high water mark can be adjusted upwards. |
|
Configure Folder-Less Item Handling |
System Configuration |
Many versions of Enterprise Vault allow archiving of items in a folder-less area called the Top Of Information Store. On the System Configuration, enter a folder name to be used for placing the items in the target archive. |
|
Stop the EV Provisioning task from auto-enabling users |
Enterprise Vault Administration Console |
Ensure that the source and target environments do not have any provisioning groups set to auto enable users throughout the duration of the migration. This prevents users being targeted by alternating environments depending on when and which provisioning task runs. |
|
Stop Storage Expiry running |
Enterprise Vault Administration Console |
Ensure that the source and target environments do not have storage expiry running. If it is enabled then it is possible that items which are collected can not be found when it is time to export them. |
|
Map one or more containers |
Manual Mapping/Bulk Mapping |
One or more containers can now be mapped and migration can begin. |
Determining Enterprise Vault archive owner(s)
Archive Shuttle must determine the owner of a mailbox archive. This section explains how this takes place..
Archive Shuttle takes the owner information of a mailbox archive from the Auto Security Descriptor field within the Enterprise Vault Directory database. The first entry for an archive will be the owner. Take the following three examples:
Simple 1
·Bill usage to: somedomain\simple1
·Permissions tab: somedomain\simple with inherited read, write and delete permissions
Archive Shuttle will see the owner of this archive as simple1.
Simple 2
·Bill usage to: somedomain\simple2
·Manually grant an additional user read, and delete permissions on the archive
·Permissions tab: somedomain\simple2 with inherited read, write and delete permissions. somedomain\someotheruser with manually set read, and delete permissions
Archive Shuttle will see the owner of this archive as simple2.
Simple 3
·Bill usage to: somedomain\simple3
·Grant full mailbox access via Exchange Management Console or Exchange Management Shell
·Permissions tab: somedomain\simple3 with inherited read, write and delete permissions. somedomain\someotheruser also with inherited read, write and delete permissions
Archive Shuttle will see the owner of this archive as simple3.
|
|
NOTE: The order which the archives are listed in the permissions tab in Enterprise Vault does not reflect the order that the accounts are described in the Auto Security Descriptor field. The permissions tab shows the archive permissions in alphabetical order. |
More detail
1.Archive Shuttle resolves the 'Owner' of an Archive as follows:
In the EnterpriseVaultDirectory database, the following SQL is used:
select ADMbxDN, LegacyMbxDN from ExchangeMailboxEntry where DefaultVaultId=@VAULTID
2.Archive Shuttle then does a lookup for the ADMbxDN in Active Directory to get the SID:
LDAP Query: (ADMbxDN=)
If Archive Shuttle does not find the AD object, the archive will be marked as Ownerless and move to the next option.
3.Archive Shuttle then does a lookup for the LegacyMbxDN in Active Directory to get the SID:
LDAP Query: (LegacyMbxDN=)
If Archive Shuttle does not find the AD object, the archive will be marked as Ownerless and move to the next option.
4.We then compare the SIDs we got from ADMbxDN and from LegacyMbxDN, and if both of them match, we have an Owner. If they do not match, they will be marked as 'Ownerless' and move to the next option.
5.If we do not find an entry in ExchangeMailboxEntry, we resolve using the BillingOwner or the AutoSecurityDesc:
select SID from Root inner join trustee on OwningTrusteeIdentity = TrusteeIdentity where VaultEntryId=@ARCHIVEID
|
|
NOTE: Regarding OwnerUserSid versus SID fields in the EVArchive Table on in the Archive Shuttle Directory Database: ·SID is always filled out with the SID which is retrieved from the above steps ·OwnerUserSid has a foreign key constraint on the [User] Table. So Archive Shuttle only fill this out if the SID obtained from EV is actually contained in the Archive Shuttle Directory Database (i.e. has been synced from AD) |
5.The UserSidHistory table is stored Sid history for each user when they were migrated from AD1 to AD2. This SidHistory attribute is part of Active Directory, and Archive Shuttle collects this data from Active Directory directly.
Example
User1 was migrated from AD1 to AD2, SidHistory attribute was populated to Active Directory and when the Active Directory sync is performed, table UserSidHistory is populated in parallel. User1 was migrated to another Active Directory, so it is supposed to be the same user and therefore in owner resolution logic is UserSidHistory as the last step. Sometimes, even the migrated user from AD1 to AD2 is not supposed to be the same user as samAccountNames are different in both Active Directories. In this case, owner resolution will take AD2 user as the owner which could be wrong in some special situations.
Workaround
As a workaround, you can:
§remove SidHistory parameter from Active Directory, and allow Archive Shuttle to synchronize Active Directory entries (recommended option), run Enterprise Vault collection, to assign correct users in ContainerToUser table
§use the SQL to assign HistoryUserSid instead of actual Sid, example of such script is below:
--update ContainerToUser, take UserHistorySid and assign to Container type 1 (EV containers only)
SET NOCOUNT OFF;
declare @sid varchar(128)
DECLARE ITEM_CURSOR CURSOR FOR
Select UserSid From ContainerToUser a
inner join [dbo].[Container] b on a.ContainerId = b.ContainerId and ContainerTypeId = 1
OPEN ITEM_CURSOR;
FETCH NEXT FROM ITEM_CURSOR INTO @sid
WHILE @@FETCH_STATUS = 0
BEGIN
update x set UserSid = (SELECT UserHistorySid FROM [dbo].[UserSidHistory] where UserSid = @sid)
from [dbo].[ContainerToUser] x
where UserSid = @sid
print 'Updated containerid ' + @sid;
FETCH NEXT FROM ITEM_CURSOR INTO @sid;
END;
CLOSE ITEM_CURSOR;
DEALLOCATE ITEM_CURSOR;
·remove entries from UserSidHistory table, disable Active Directory sync to avoid entries are coming back with next Active Directory sync, run Enterprise Vault collection to assign correct users in ContainerToUser table
|
|
NOTE: Re-using of sAMAccountsName/MbxNTUser or MbxDisplayName in one domain can cause an issue with Enterprise Vailt Archive assigning process. |
General considerations
The following general considerations should be taken into account for this type of migration:
·Ingest speed is likely to be reduced versus the speed of export since ingesting is also going to place a load on the indexing engine on the target environment. In general do not expect the export and ingest speeds to be comparable.
·When migrating from a pre EV 10.0.3 system extraction of data may be slower than expected if Enterprise Vault Collections have been used. Access to the data inside the CAB file is single threaded. This issue does not exist in Enterprise Vault 10.0.3 and later.
·An issue is currently being investigated by Symantec. Items extracted from EV 9, may not be ingested into EV 11.0.1. This affects only a small number of items. This may be addressed in the future by Symantec.
·EVPM may have difficulty in connecting to, and processing, mailboxes which are homed on Exchange 2013. This knowledge base article may help.
·EVPM may need to have the DS Server registry key set. This knowledge base article may help.
Enterprise Vault to Exchange
This section explains what the requirements are for an Enterprise Vault (EV) to Exchange migration, and then covers the basic steps that should be followed to start such a migration.
Stage 1 - Synch
As soon as a user is enabled for migration, the synch process-flow shown above starts.
Archive Shuttle Core sends a command to collect all needed metadata information such as the number of items, size, and Enterprise Vault transaction IDs for the archive of the user. The results are reported back to Archive Shuttle Core to allow item level tracking and auditing.
The Enterprise Vault Export and Exchange Ingest process is then started. It runs continuously in the background until the administrator initiates a switch (Stage 2) for the user or a specified external trigger is fired (e.g., the mailbox has been moved from Exchange 2003 to Exchange 2010).
Stage 2 - Switch
After the Stage 2 ('Switch') phase to the target environment is initiated, the configured workflow starts, and by default determines the gap between the source archive and the last imported item. Archive Shuttle then synchronizes the difference one last time to the target mailbox.
The last step is to cleanup shortcuts in the source mailbox by deleting them.
Requirements
The following is a list of requirements.
|
Requirement |
Description |
|---|---|
|
Modules installed on source |
The EV-type modules should be installed on each appropriate source Enterprise Vault server involved in the migration. The EV import module is not required on these machines. |
|
Modules installed on appropriate bridgehead to reach target |
Exchange and Post Processing modules are the two which are primarily needed to work with this type of migration. |
|
AD Collector module installed |
An AD Collector module should be installed so that it can collect user-level information for the migration project. |
|
Staging Area created |
One or more staging areas should be setup, of an appropriate size and should be excluded from virus scanners. |
|
Ingest accounts configured for Application Impersonation |
5 accounts should be configured with Application Impersonation rights, and those accounts should be added to the credential editor on the machine running the Exchange ingest module. |
|
Workflows reviewed |
The Stage 2 workflows should be reviewed, and if necessary, customized to meet the needs of the project. |
|
Apply appropriate failed item threshold |
It is best practice to find an appropriate failed item threshold for the project/customer and apply that at the links level. This way all mappings which are created will inherit this value. |
Basic steps
The following are the basic steps to start this type of migration.
|
Step |
Screen |
Description |
|---|---|---|
|
Enable Modules |
Modules |
All Archive Shuttle modules must be enabled, and optionally a schedule for them defined. It is important to verify that none of the modules have a red background (this indicates that Archive Shuttle Core has not had contact with the module) and that the module versions are as expected. |
|
Enable Domains |
Active Directory |
Select and enable one or more domains for synchronization. |
|
Add EV Environment |
EV Environment |
Add the Enterprise Vault source environment. |
|
Add Source Links |
Links |
Configure all appropriate source links. Select the links, and then click on Map Modules, create the item database(s) and enable archive gathering. Ensure there is no import module specified on the links as this may impact the process later on. |
|
Add Target Links |
Links |
Add all appropriate target links. An ingest and post-processing module should be associated with each possible target Exchange Database. |
|
Add Staging Area |
Links |
Ensure that the Default Staging Area is configured correctly. Depending on the migration, the free space, and the number of vault stores being used as the source for the migration, the high water mark can be adjusted upwards. |
|
Configure Folder-Less Item Handling |
System Configuration |
Many versions of Enterprise Vault allow archiving of items in a folder-less area called the Top Of Information Store. On the System Configuration, enter a folder name to be used for placing the items in the target archive. |
|
Ensure AIP/EWS is configured correctly |
System Configuration |
Ensure that the migration providers are listed in the required order and that the AutoDiscoverURL is specified if required. The account which is to be used for ingest needs to have Application Impersonation rights. This article will help with configuring that. |
|
Consider disabling reminders for appointments in the past |
System Configuration > Exchange Import Module |
Consider enabling the option to Disable reminders for appointments in the past this will prevent pop-ups appearing from Outlook on end-user machines when old appointments are processed. |
|
Map one or more containers |
Manual Mapping/Bulk Mapping |
One or more containers can now be mapped and migration can begin. |
Determining Enterprise Vault archive owner(s)
Archive Shuttle must determine the owner of a mailbox archive. This section explains how this takes place..
Archive Shuttle takes the owner information of a mailbox archive from the Auto Security Descriptor field within the Enterprise Vault Directory database. The first entry for an archive will be the owner. Take the following three examples:
Simple 1
·Bill usage to: somedomain\simple1
·Permissions tab: somedomain\simple with inherited read, write and delete permissions
Archive Shuttle will see the owner of this archive as simple1.
Simple 2
·Bill usage to: somedomain\simple2
·Manually grant an additional user read, and delete permissions on the archive
·Permissions tab: somedomain\simple2 with inherited read, write and delete permissions. somedomain\someotheruser with manually set read, and delete permissions
Archive Shuttle will see the owner of this archive as simple2.
Simple 3
·Bill usage to: somedomain\simple3
·Grant full mailbox access via Exchange Management Console or Exchange Management Shell
·Permissions tab: somedomain\simple3 with inherited read, write and delete permissions. somedomain\someotheruser also with inherited read, write and delete permissions
Archive Shuttle will see the owner of this archive as simple3.
|
|
NOTE: The order which the archives are listed in the permissions tab in Enterprise Vault does not reflect the order that the accounts are described in the Auto Security Descriptor field. The permissions tab shows the archive permissions in alphabetical order. |
More detail
1.Archive Shuttle resolves the 'Owner' of an Archive as follows:
In the EnterpriseVaultDirectory database, the following SQL is used:
select ADMbxDN, LegacyMbxDN from ExchangeMailboxEntry where DefaultVaultId=@VAULTID
2.Archive Shuttle then does a lookup for the ADMbxDN in Active Directory to get the SID:
LDAP Query: (ADMbxDN=)
If Archive Shuttle does not find the AD object, the archive will be marked as Ownerless and move to the next option.
3.Archive Shuttle then does a lookup for the LegacyMbxDN in Active Directory to get the SID:
LDAP Query: (LegacyMbxDN=)
If Archive Shuttle does not find the AD object, the archive will be marked as Ownerless and move to the next option.
4.We then compare the SIDs we got from ADMbxDN and from LegacyMbxDN, and if both of them match, we have an Owner. If they do not match, they will be marked as 'Ownerless' and move to the next option.
5.If we do not find an entry in ExchangeMailboxEntry, we resolve using the BillingOwner or the AutoSecurityDesc:
select SID from Root inner join trustee on OwningTrusteeIdentity = TrusteeIdentity where VaultEntryId=@ARCHIVEID
|
|
NOTE: Regarding OwnerUserSid versus SID fields in the EVArchive Table on in the Archive Shuttle Directory Database: ·SID is always filled out with the SID which is retrieved from the above steps ·OwnerUserSid has a foreign key constraint on the [User] Table. So Archive Shuttle only fill this out if the SID obtained from EV is actually contained in the Archive Shuttle Directory Database (i.e. has been synced from AD) |
5.The UserSidHistory table is stored Sid history for each user when they were migrated from AD1 to AD2. This SidHistory attribute is part of Active Directory, and Archive Shuttle collects this data from Active Directory directly.
General considerations
The following general considerations should be taken into account for this type of migration:
·When migrating from a pre EV 10.0.3 system extraction of data may be slower than expected if Enterprise Vault Collections have been used. Access to the data inside the CAB file is single threaded. This issue does not exist in Enterprise Vault 10.0.3 and later.
·EVPM may have difficulty in connecting to, and processing, mailboxes which are homed on Exchange 2013. This knowledge base article may help.
·EVPM may need to have the DS Server registry key set. This knowledge base article may help.
Migrating an archive from Enterprise Vault to Exchange
Complete the steps below to migrate a single test archive within Enterprise Vault to an Exchange 2010/2013 personal archive.
Prerequisites
The steps below must be complete before the migration begins:
·Enable all Modules.
·Enable appropriate Active Directory domains for scanning.
·Add an Enterprise Vault environment for the migration.
·Create a link database for the source archives.
·Configure module mappings for the source archives and the target Exchange environment.
·Run a PowerShell command to allow application impersonation.
In addition, if youll use an Exchange personal archive, rather than an ordinary mailbox for the test migration, the personal archive needs to be pre-created. The personal archive doesnt need to be created on the same mailbox database as the primary mailbox.
Map containers for the test archive
To migrate a test archive from Enterprise Vault to Exchange 2010/2013, the source and target containers must be mapped. Follow these steps to do it:
1.Go to Manage > Bulk Mapping.
2.Type the beginning of the archive name in the Container Name filter. Click the button in the Apply Filter row, located at the far right of the filter row. Note: If the test archive doesnt display, go back to the Configuration > EV Environment page and click Sync all AD Users. Then, select the vault store where the source archive is located and click [Run Now].
3.Select the checkbox next to the test archive(s) and click Add Mappings. A wizard runs, gathering information related to the mapping(s) for the selected archive(s).
4.When youre prompted to choose a target container type, select Exchange and click [Next].
5.When youre prompted to choose the type of migration, select Normal and click [Next].
6.When youre prompted to choose the target mailbox type, select Secondary (Archive) mailbox. Then, in the second part of the dialog select Skip, and then click [Next].
7.When youre prompted to choose the target user, select Same User, and click [Next].
8.On the Choose Workflow Policy screen, select the Exchange migration (without archive deletion) option, leave the second drop-down list blank, and then click[Next].
9.When youre prompted to choose a filter policy, leave the Default (No Filter) option selected, and then click [Next].
10.On the Container Mapping Settings screen, select Enabled for both Migration Status and Item Gathering Status, and then click [Next].
11.Leave the priority blank and click [Next].
12.Review the summary screen, and then click Confirm.
A few minutes after the mapping is created, appropriate modules start the actions defined in the mapping. The progress of this stage of the migration can be reviewed by following these steps:
1.Go to the Stage 1 (Sync Data) page.
2.Type the beginning of the archive name in the Name filter. Click the Apply Filter button at the far right of the filter row.
3.Once the source archive displays, click Refresh to see the progress of the export of the archive and the ingestion of data into the Exchange personal archive. Continue to click Refresh until both the export and import are complete.
Validate exported data
In addition to checking export/import status (using the steps in the Review Stage 1 status procedure above) you can use Windows Explorer to browse the export/import storage area and data on the disk.
Its also possible to log in to Outlook or Outlook Web Access as the test user. The migrated data will be present in the Personal Archive, and can be freely opened and manipulated.
|
|
NOTE: If the test user previously used the Exchange personal archive feature, it might be difficult to locate the migrated data. Because of this, Archive Shuttle recommends that the test user has an empty personal archive before migration. |
Enable Stage 2
Before enabling Stage 2 (Switch User) for the test archive, check the Stage 1 Status page for issues like failed item-export or item-import.
Complete these steps to enable Stage 2 (Switch User) for the test archive
1.Go to the Stage 1 (Sync Data) page.
2.Select the checkbox next to the test archive, and click Enable Stage 2 in the navigation bar.
3.When you refresh the Stage 1 (Sync Data) page, there should be a green and white check mark in the Stage 2 Enabled column.
Stage 2 is the switchover to the target environment. A final synchronization of archived items is performed from the source environment to the target environment before several additional migration tasks are performed.
Review Stage 2 Status
After a few minutes, view the progress of the test archive migration on the Stage 2 Status page by following these steps:
1.Go to the Stage 2 (Switch User) page.
2.Type the beginning of the archive name in the Container Name filter. Click the Apply button located at the far right of the row in the Apply Filter column.
|
|
NOTE: If the archive is not displayed, wait one to two minutes and click Refresh in the navigation bar. |
3.Once the source archive displays, click the Refresh button to show the progress of the final stages of the archive migration. By default, since the Exchange migration (without archive deletion) workflow policy was selected, the following steps are performed:
a)Disable source mailbox from Enterprise Vault archiving.
b)Rename the source archive.
c)Collect any remaining items for migration.
d)Import the remaining items into the target.
e)Delete any Enterprise Vault shortcuts in the mailbox
Verify data has been migrated
Once all Stage 2 operations are complete, the Stage 2 (Sync Data) for the test archive will have a check mark in the Finished column.
In addition, if Outlook or Outlook Web Access is used to access the test mailbox, then all archived items will be in the personal archive and no Enterprise Vault shortcuts will remain in the source mailbox.
Enterprise Vault to Office 365
This section explains what the requirements are for an Enterprise Vault (EV) to Office 365 migration, and then covers the basic steps that should be followed to start such a migration.
Stage 1 Synch
As soon as a user is enabled for migration, the synch process-flow shown above starts.
Archive Shuttle Core sends a command to collect all needed metadata information such as the number of items, size, and Enterprise Vault transaction IDs for the archive of the user. The results are reported back to Archive Shuttle Core to allow item level tracking and auditing.
The Enterprise Vault Export and Office 365 module then begin to work. This runs continuously inf the background until the administrator initiates a Switch (Stage 2).
Stage 2 - Switch
After the Stage 2 ('Switch') phase to the target environment is initiated, the configured workflow starts, and by default determines the gap between the source archive and the last imported item. Archive Shuttle then synchronizes the difference one last time to the target mailbox.
The last step is to Zap the mailbox to remove Enterprise Vault settings, cleanup shortcuts in the source mailbox by deleting them, and change any pending-archive items back to normal items.
Requirements
The following is a list of requirements.
|
Requirement |
Description |
|---|---|
|
Modules installed on source |
The EV-type modules should be installed on each appropriate source Enterprise Vault server involved in the migration. The EV import module is not required on these machines. |
|
Modules installed on appropriate bridgehead to reach target |
Office 365 and Post Processing modules are the two which are primarily needed to work with this type of migration. |
|
AD Collector module installed |
An AD Collector module should be installed so that it can collect user-level information for the migration project. |
|
Staging Area created |
One or more staging areas should be setup, of an appropriate size and should be excluded from virus scanners. |
|
Ingest accounts configured for Application Impersonation |
5 accounts should be configured with Application Impersonation rights, and those accounts should be added to the credential editor on the machine running the Office 365 module. One account should also be configured as a Global Administrator in Office 365, and be marked as that in the credential editor. |
|
Workflows reviewed |
The Stage 2 workflows should be reviewed, and if necessary, customized to meet the needs of the project. |
|
Apply appropriate failed item threshold |
It is best practice to find an appropriate failed item threshold for the project/customer and apply that at the links level. This way all mappings which are created will inherit this value. |
Basic steps
The following are the basic steps to start this type of migration.
|
Step |
Screen |
Description |
|---|---|---|
|
Enable Modules |
Modules |
All Archive Shuttle modules must be enabled, and optionally a schedule for them defined. It is important to verify that none of the modules have a red background (this indicates that Archive Shuttle Core has not had contact with the module) and that the module versions are as expected. |
|
Enable Domains |
Active Directory |
Select and enable one or more domains for synchronization. |
|
Add EV Environment |
EV Environment |
Add the Enterprise Vault source environment. |
|
Add Source Links |
Links |
Ensure that the Default Staging Area is configured correctly. Depending on the migration, the free space, and the number of vault stores being used as the source for the migration, the high water mark can be adjusted upwards. |
|
Add Staging Area |
Links |
Select the newly created link, and map a Shortcut Process Module to it. |
|
Configure Folder-Less Item Handling |
System Configuration |
Many versions of Enterprise Vault allow archiving of items in a folder-less area called the Top Of Information Store. On the System Configuration, enter a folder name to be used for placing the items in the target archive. |
|
Set Office 365 Credentials |
OAuth authentication Screen: Office 365 module Run the Archive Shuttle Office 365Module Credential Editor and add OAuth credentials. Then test the connection. Then, from the Office 365 Module, select the Use modern authentication (OAuth) option. | |
|
Update Shortcut Processing Module Configuration |
System Configuration > Shortcut Processing |
Update the settings so that Use EWS for Processing is enabled. |
|
Consider disabling reminders for appointments in the past |
System Configuration > Office 365 Module |
Consider enabling the option to Disable reminders for appointments in the past. |
|
Map one or more containers |
Manual Mapping/Bulk Mapping |
One or more containers can now be mapped and migration started. |
Determining Enterprise Vault archive owner(s)
Archive Shuttle must determine the owner of a mailbox archive. This section explains how this takes place..
Archive Shuttle takes the owner information of a mailbox archive from the Auto Security Descriptor field within the Enterprise Vault Directory database. The first entry for an archive will be the owner. Take the following three examples:
Simple 1
·Bill usage to: somedomain\simple1
·Permissions tab: somedomain\simple with inherited read, write and delete permissions
Archive Shuttle will see the owner of this archive as simple1.
Simple 2
·Bill usage to: somedomain\simple2
·Manually grant an additional user read, and delete permissions on the archive
·Permissions tab: somedomain\simple2 with inherited read, write and delete permissions. somedomain\someotheruser with manually set read, and delete permissions
Archive Shuttle will see the owner of this archive as simple2.
Simple 3
·Bill usage to: somedomain\simple3
·Grant full mailbox access via Exchange Management Console or Exchange Management Shell
·Permissions tab: somedomain\simple3 with inherited read, write and delete permissions. somedomain\someotheruser also with inherited read, write and delete permissions
Archive Shuttle will see the owner of this archive as simple3.
|
|
NOTE: The order which the archives are listed in the permissions tab in Enterprise Vault does not reflect the order that the accounts are described in the Auto Security Descriptor field. The permissions tab shows the archive permissions in alphabetical order. |
More detail
1.Archive Shuttle resolves the 'Owner' of an Archive as follows:
In the EnterpriseVaultDirectory database, the following SQL is used:
select ADMbxDN, LegacyMbxDN from ExchangeMailboxEntry where DefaultVaultId=@VAULTID
2.Archive Shuttle then does a lookup for the ADMbxDN in Active Directory to get the SID:
LDAP Query: (ADMbxDN=)
If Archive Shuttle does not find the AD object, the archive will be marked as Ownerless and move to the next option.
3.Archive Shuttle then does a lookup for the LegacyMbxDN in Active Directory to get the SID:
LDAP Query: (LegacyMbxDN=)
If Archive Shuttle does not find the AD object, the archive will be marked as Ownerless and move to the next option.
4.We then compare the SIDs we got from ADMbxDN and from LegacyMbxDN, and if both of them match, we have an Owner. If they do not match, they will be marked as 'Ownerless' and move to the next option.
5.If we do not find an entry in ExchangeMailboxEntry, we resolve using the BillingOwner or the AutoSecurityDesc:
select SID from Root inner join trustee on OwningTrusteeIdentity = TrusteeIdentity where VaultEntryId=@ARCHIVEID
|
|
NOTE: Regarding OwnerUserSid versus SID fields in the EVArchive Table on in the Archive Shuttle Directory Database: ·SID is always filled out with the SID which is retrieved from the above steps ·OwnerUserSid has a foreign key constraint on the [User] Table. So Archive Shuttle only fill this out if the SID obtained from EV is actually contained in the Archive Shuttle Directory Database (i.e. has been synced from AD) |
5.The UserSidHistory table is stored Sid history for each user when they were migrated from AD1 to AD2. This SidHistory attribute is part of Active Directory, and Archive Shuttle collects this data from Active Directory directly.
General considerations
The following general considerations should be taken into account for this type of migration:
·A call should be logged with Microsoft to get the throttling limits raised for the duration of the migration, otherwise ingest performance will be reduced.
·When migrating from a pre EV10.0.3 system extraction of data may be slower than expected if Enterprise Vault Collections have been used. Access to the data inside the CAB file is single threaded. This issue does not exist in Enterprise Vault 10.0.3 and later.
·Different flavors of Office 365 license have different size limits, as described here. It is advised to run SQL Queries on the source environment in order to determine if any archives are likely to have.
·Many large items- Many archives have more data in them than is allowed by the Office license.
·It is advised to ensure a high level of Mailbox Parallelism and a low level of item/batch parallelism. This gives least chance to get to throttling limits.