Microsoft 365 Mailbox Migration FAQ

This article covers general Microsoft 365 migration questions, as well as more specific information and troubleshooting for steps such as coexistence, impersonation, and litigation holds.

This guide is intended to be used in conjunction with the proper scenario-specific migration guide. 

Large Items

The maximum individual file size that MigrationWiz can support is 60GB.

Settings 

Settings for specific migration scenarios will be explained in the migration guides for your scenario. Some settings, however, may apply to multiple migration scenarios or require more explanation. 

Destination mailbox language

Destination mailbox language sets the language for system folder names in Outlook Web Access (OWA), but only in the case where a user or admin has never previously logged into the mailbox.

Examples of this may include:

  • If the account has been created at the Destination but no one has ever logged into the account, whatever language is set within MigrationWiz Advanced Options via this Destination mailbox language setting will be the language that OWA interface is set to. It will not perform any translation on actual mailbox content.
  • If the account has been logged in to prior to migration, this MigrationWiz Advanced Option setting will not have any effect. This setting only effects mailboxes that have never been logged in to, before migration. For example, if the user logs in to OWA and sets their OWA language to German, but the MigrationWiz Advanced Option language setting is set to French, the OWA interface language will remain set as German.
  • This setting does not handle any mapping of system or user folders from one language to another, or to/from the same language. Folder Filtering & Mapping in MigrationWiz must be added if needed. 

Set msExchMailbox GUID attribute to null

This can be set within Synchronization Rules Editor.

  • This is not supported if you have performed a directory synchronization using DirSync.
  • It is supported if performing a directory synchronization using AAD Sync, or AAD Connect.

Instructions: 

1. run the Synchronization Rules Editor as an administrator. 

2. Click In from AD - User Exchange to edit the Inbound Rule Type. 

Coexist_4.jpg

3. Select Transformations.

4. Find the msExchMailboxGuid attribute. 

5. Change it to the following: Expression - msExchMailboxGuid - NULL - Checkmark Apply Once

6. click Update.

7. Next, enable AADSync or AAD Connect and perform a full synchronization. 

Now users may be assigned an Exchange Online license, and MigrationWiz may be used to migrate their mailboxes to Microsoft 365.

Access & Credentials

There are multiple ways to manage credentials in Microsoft 365 migrations. Certain migrations call for specific credential management options, which will be specified within the migration guide. This section offers more information and context for those options. 

Modern Auth

BitTitan now supports Modern Authentication for Microsoft 365 endpoints used for Mailbox migrations. Modern Authentication provides a more secure authentication mechanism for registered applications to connect to Azure Active Directory and Microsoft 365. For more information on Modern Authentication, see this page from Microsoft: How to authenticate an EWS application by using OAuth.

The Autodiscovery of items option will not work with Modern Authentication in place.

Prerequisites

  • A Global Administrator account with access to Azure Active Directory. MFA/2FA is not supported at this time. The administrator account will need to be excluded from these policies if enabled. 
  • MigrationWiz® Mailbox project(s) created and ready for configuration.
  • The application will require administrator consent
  • For OneDrive/SharePoint migrations: The Administrator account will require access to legacy authentication in order to retrieve the Site URL. For this reason, the administrator account will need to be excluded from any baseline security policies, or have Conditional Access granted using a Conditional Access Policy
    Important note: The Administrator account will need to be added to the Exclude option.

Process

  1. Log in to the Azure AD admin console with a Global Administrator login.
  2. Select Azure Active Directory in the Azure Active Directory Admin Center.
  3. Select App Registrations, which is found under Manage.
  4. Select New Registration at the top of the screen.
  5. Give the app a distinct name. You can change this later if necessary.
  6. Select the Accounts in any organizational directory button.
  7. Under Redirect Uri, select Public Client (mobile & desktop) and set it to urn:ietf:wg:oauth:2.0:oob
  8. Click Register.
  9. Go back to App registrations.
  10. Select the App you just created.
  11. In the Overview, you will find a ClientId (aka Application) and Directory (Tenant) ID.
  12. Copy both of these to another application, such as Notepad, for use later in this process.
  13. Under the Manage menu, select Authentication.
  14. Set the option Allow public client flows to Yes
  15. Click Save.
  16. From the Manage menu, select API permissions.
  17. Select Add a Permission.
  18. Select APIs my organization uses.

  19. Scroll down and select Office 365 Exchange Online.

  20. Then select Delegated Permissions.

  21. Select EWS.

  22. Check the box under EWS for EWS.AccessAsUser.All.
  23. Click Add permissions. This permission only allows the OAuth application (MigrationWiz) to be associated with EWS. This does not grant access to all mailbox data.
  24. Click Grant admin consent.
  25. Click Yes to confirm the settings.
  26. In MigrationWiz, select the project that needs to be configured for Modern Authentication.
  27. Click the Edit Project menu.
  28. Select Advanced Options.
  29. Under Support Options enter the ClientID and TenantID information you saved earlier in the following format:
    • If enabling Modern Authentication for the Source:
      • ModernAuthClientIdExport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      • ModernAuthTenantIdExport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    • If enabling Modern Authentication for the Destination:
      • ModernAuthClientIdImport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      • ModernAuthTenantIdImport=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 
        • Enter the specific ClientID and TenantID for your tenant in place of the xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
        • These options can be entered for either the Source or the Destination, or both, depending on the settings on the tenants.
        • These options need to be configured for each MigrationWiz project that needs to have Modern Authentication enabled.

  30. Run a Verify Credentials to confirm that MigrationWiz can connect using Modern Authentication. 
  31. Click on the item that was verified. There will be a message in the MigrationWiz Migration Information page that Modern Authentication is being used. This message will show in the “Migration Errors” box; however, it is not an error. This is just a message confirming that Modern Authentication is now active and being used for connection.

Verifying Mailbox Access

Perform the following steps to verify mailbox access.

  1. Browse to https://login.microsoftonline.com.
  2. Log in as admin email address.
  3. Enter the exact same password as specified in MigrationWiz.
  4. Enter the Admin portal.
  5. Click Users, then Active Users.
  6. Search for users entered in Migrationwiz to make sure the admin email address and the end user´s email address specified in MigrationWiz are not misspelled by searching for them.
  7. Make sure all users have licenses assigned to them (see here if using F1 Microsoft 365 licenses). All mailboxes on the Source system are created as mail users in Microsoft 365. When you assign a license to the mail user, it will become a mailbox user. We need a mailbox at the Destination in order to be able to migrate data.
  8. If you are not using impersonation, make sure the admin account has a license assigned to it. This can even be a temporary trial license.
  9. If you deleted and recreated users, make sure the users have been hard-deleted from the Deleted users tab in the Microsoft 365 portal:

You must first use PowerShell to execute a hard delete. If not already installed, download and install the Azure Active Directory v2 PowerShell module.

Execute these PowerShell commands:

Import-Module -Name MSOnline

$LiveCred = Get-Credential

Connect-MsolService -Credential $LiveCred

Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin –Force

  • The PowerShell commands remove deleted users from the recycle bin and permanently delete them.
  • Click the Outlook tab to open the OWA and make sure you can open the end user´s email address.
  • After creating a user, you may experience small replication delays in Microsoft 365.
  • When you submit the project for migration, we try to automatically grant the administrator account permission on mailboxes (using impersonation), by executing Microsoft 365 PowerShell commands. In some cases, the Microsoft 365 PowerShell command may fail. If done manually, the issue should be resolved. The article, Impersonation and Delegation explains how to do enable impersonation.
  • When migrating more than 10 mailboxes, you may experience throttling if not using impersonation. We recommend enabling impersonation; but keep in mind that if you enable impersonation, by default the administrator account does not have permission to impersonate user accounts. We attempt to grant impersonation rights behind the scenes, but it takes a very long time and can time out. You can either:

Shared Mailboxes

Shared mailboxes migrate in a similar way to a regular mailbox migration.

  • If migrating with administrative credentials: From the MigrationWiz dashboard, click on the Quick Add button, and enter the email address of the shared mailbox at the Source, and the email address of the shared mailbox at the Destination. When the migration is performed, it will migrate with the administrative credentials added when creating the project. The administrator account must have full access permissions to the shared mailbox in order to perform the migration. If performing a Bulk Add of users, simply include the shared mailboxes in the CSV file that is used to import the mailboxes into the MigrationWiz dashboard.
  • If migrating without administrative credentials: From the MigrationWiz dashboard, click on the Quick Add button, and enter the email address of the shared mailbox at the Source, and then the login name and password of either the owner of that shared mailbox or an account that has full access permissions to the shared mailbox. Also enter the email address of the shared mailbox at the Destination, and then the login name and password of either the owner of that shared mailbox or an account that has full access permissions to the shared mailbox.

The login name and password can only be added if the MigrationWiz project is created without administrative credentials.

Refer to the Create a shared mailbox article from Microsoft for more information about how to create and use shared mailboxes in Microsoft 365.

As with a regular mailbox migration, it is necessary to purchase mailbox migration licenses or User Migration Bundle licenses in order to perform the migration.

Shared mailboxes make it easy for a specific group of people to monitor and send email from a common account, like public email addresses, such as info@mining88.com or contact@mining88.com. When a person in the group replies to a message sent to the shared mailbox, the email appears to be from the shared mailbox, not from the individual user.

Shared mailboxes are a great way to handle customer email queries because several people in an organization can share the responsibility of monitoring the mailbox and responding to queries. The customer queries get quicker answers, and related emails are all stored in one mailbox.

Shared mailboxes are also ideal for storing the mailbox contents of terminated employees.

It is not necessary to assign licenses to shared mailboxes in Microsoft 365, except when they are over their storage quota of 50GB.

In the back end, shared mailboxes are identical to user mailboxes. Look at the user list; there will be a user created for the shared mailbox.

Migrating permissions for user-created folders

By default, MigrationWiz will only migrate Mailbox Folder Permissions for System folders. To migrate permissions on folders that were created by users, the Advanced Option must be set to MustMigrateAllPermissions=1 in your project.

This setting is an option because it is not a best practice, and scanning for the permissions will slow down the migration.
We do not migrate any permissions for the Default or Anonymous user accounts.

Microsoft 365 FI (formerly Kiosk) Users

In order to migrate to kiosk users, the migration project will need to be configured to use an admin account with impersonation rights. This allows us to bypass the limitations of kiosk users, who lack the ability to connect directly via EWS.
To ensure that your migration project is correctly configured to migrate to kiosk users, perform the following steps:
Specify admin credentials:
  1. Sign in to your MigrationWiz account.
  2. Click the Go To My Projects button.
  3. Select the project that needs to be modified.
  4. Click the Edit Project button.
  5. Click Edit Project ​from the drop-down menu.
  6. Select Destination Settings.
  7. Checkmark Use Admin Credentials and enter these.
  8. Click the Save Project button.
  9. Enable Impersonation:
    1. ​Click the Edit Project button.
    2. Click Advanced Options from the drop-down menu.
    3. Under the section title Destination: Microsoft Office 365, checkmark Use impersonation to authenticate.
    4. Click the Save button.
The admin account specified does not require a license and does not need to have other admin rights configured.
Impersonation

Impersonation in Microsoft 365

MigrationWiz uses delegation by default to log in to individual user mailboxes using administrative credentials specified on the connector. However, MigrationWiz also supports impersonation in specific environments.

Using impersonation:

  • Eliminates most "Connection did not succeed" errors.
  • Allows migration of more mailboxes concurrently.
  • Reduces the impact of throttling and connection limits.
  • Uses an administrator account without assigning a license to it.

Steps

To migrate using impersonation:

  1. Use admin credentials at the Destination.
  2. Sign in to the MigrationWiz account.​
  3. Edit the Project and click Advanced Options.
  4. If migrating from Microsoft 365, under Source, check Use impersonation to authenticate.
  5. If migrating to Microsoft 365, under Destination, check Use impersonation to authenticate.
  6. Click Save Options.

MigrationWiz will automatically run a remote PowerShell command to allow the admin account to log in to (impersonate) user mailboxes.

Here is the remote PowerShell command we execute when a mailbox has been submitted for migration:

Enable-OrganizationCustomization

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>

You may also run these commands manually. This is useful if there are delays from Microsoft and the Powershell command does not run immediately.

Exchange 2010+:

MigrationWiz uses delegation by default to log in to individual user mailboxes using administrative credentials specified on the connector. However, MigrationWiz also supports impersonation in specific environments.

Benefits:

Using impersonation, sharing the throttling quota and connection limits associated with a single administrative account stops. Instead, the throttling quota of each user is used for each user mailbox.

Using impersonation:

  • Eliminates most "Connection did not succeed" errors.
  • Allows migration of more mailboxes concurrently.
  • Reduces the impact of throttling and connection limits.

Steps:

  1. Use admin credentials at the Destination.
  2. Sign in to the MigrationWiz account.
  3. Edit the Project and click Advanced Options.
  4. Under Destination, check Use impersonation to authenticate.
  5. If migrating from Exchange 2010+, under Source, check Use impersonation to authenticate.
  6. If migrating to Exchange 2010+, under Destination, check Use impersonation to authenticate.
  7. Click Save Options.

For Exchange migrations, to enable the admin account to impersonate users, run this PowerShell command:

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>

More information about this PowerShell command can be found here.

Office 365 plans named "Business Essential" and "Business Premium" do support impersonation. Follow the steps above, under the Microsoft 365 section, to enable support for use of impersonation when migrating from or to "Business Essential" or "Business Premium".

If the above Advanced Options are set to use impersonation on a project, these settings will only become effective for those migrations that are started after saving the settings. Migrations that are already running will be unaffected by any such changes.

Synchronizing Azure Active Directory 

The recommended approach is as follows:

Use this article from Microsoft for the most up-to-date information: Set up Directory Synchronization

  1. Download and install AAD Sync or AAD Connect (if you need support for federation).
  2. Set msExchMailbxoGuid to Null.
  3. Configure filtering to define which objects are synced. Read the Azure AD Connect sync: Configure filtering article from Microsoft for more information.
  4. Use Microsoft AAD Sync or AAD Connect to create and synchronize the accounts from the On-premises environment to Microsoft 365.
  5. Assign Microsoft 365 licenses to accounts on Microsoft 365.
  6. Remove the null attribute from the msExchMailboxGuid, using the Synchronization Rules Editor.
  7. Perform another synchronization, using AAD Connect (or AAD Sync).
  8. Migrate, using MigrationWiz. This step can also be initiated after Step 4, once the licenses have been assigned.

If the local Active Directory (AD) schema has not been extended to support Exchange, then the steps above to set msExchGuid attribute to null are not needed. Synchronization can be run in the normal manner.

If you have previously used DirSync from an environment where the local AD supports Exchange, you cannot set the msExchangeMailboxGUID to null, because this is not supported by DirSync. Therefore, we recommend that you instead use AAD Sync or AAD Connect to rectify this problem, by following the steps outlined above.

If you do not set the msExchMailboxGuid to null, before running a synchronization from an environment where the local AD supports Exchange, all of the On-Premises Exchange attributes for each user will be synchronized, including the MailboxGuid attribute. If users are created in this state on Microsoft 365, an Exchange Online license cannot be activated unless Mailbox Replication Services (MRS) is used to perform the mailbox move, or the steps above are followed to rectify this problem.

Once the users have been created on Microsoft 365, and the licenses have been activated, then you can start using DirSync, AAD Sync, or AAD Connect in the normal manner. The problem is limited to the user creation and license enablement (when the local AD supports Exchange).

If the mailboxes are on an Exchange Server in the local AD, Microsoft 365 accounts can be created using one of the following methodologies. 

    • AAD Sync or AAD Connect. Follow the instructions detailed in the recommended approach above.

    • Manually, one at a time.

    • By bulk import, via CSV file.

    • BitTitan DirSync tool.

Licenses will also need to be assigned to the users, once they have been created.

Mail Routing

When Migrating Users in Batches

When migrating to Microsoft 365 using MigrationWiz, mailboxes need to be provisioned on Microsoft 365 in order to be able to write the content, mail, contacts, calendar, etc. (the user must exist on Microsoft 365 with an O365 license assigned to it, including a mailbox).

When a migration is performed in stages or batches, care must be taken to ensure that full mail flow continues for those migrated users.

This can be further explained by way of an example:

  • John and Tom need to be migrated to Microsoft 365. They are in different user batches. Batch 1 will be migrated first. Batch 2 will be migrated second.
  • John is in the first batch, gets migrated, and is using his Microsoft 365 mailbox.
  • Tom is in the second batch. This batch of users will be migrated at a later date.
  • When it comes to migrating users in Batch 2, these users will need to be activated on Microsoft 365 prior to migration since, as explained above, the mailbox needs to be active in order for MigrationWiz to migrate data into it.

What will happen if mail is sent to this newly activated Microsoft 365 mailbox while the migration is occurring?

If John sends an email to Tom, Microsoft 365 will internally route it to the new mailbox instead of the on-premises mailbox that Tom still uses. The email will not get lost since the email is stored in a mailbox that eventually Tom will get, but Tom will not have access to the email until the migration is completed.

How do we fix this?
The default mail routing can be manipulated by a mechanism called Criteria-Based Routing (CBR). Instead of dropping the mail in the mailbox on Microsoft 365, we can intercept the message and transfer it to the on-premises mail system, to be handled there. The interception is based on criteria similar to the membership of a specific Distribution List.

This is best explained by using the same example scenario:

  • John was migrated to Microsoft 365 in the first batch.
  • Tom is part of a Distribution List (DL) called NotMigrated.
  • We have set up a CBR mechanism that defines the following:
    • If you are a part of the DL NotMigrated, your mail will be intercepted and will be sent to the on-premises environment.
  • This way, when John sends an email to Tom, it will not go into the Microsoft 365 mailbox, but instead, be transferred to the On-Premises Exchange 2010+ environment.

Step-by-step setup:
For the setup, use PowerShell, because it is faster and easier to set up than working through the Microsoft 365 admin portal. If you need information about how to do this through the Microsoft 365 admin portal, contact Microsoft Support.

  1. Connect to Exchange Online PowerShell.
  2. Create the Distribution List (DL):
    New-DistributionGroup -Name "BtNotMigratedUsers"
  3. Add All Users to this DL.
  4. Create the Connector:
    $result = New-OutboundConnector -Name "CBRConnector" -ConnectorType OnPremises -SmartHosts "<fill smart host to source environment>" -UseMXRecord $false -IsTransportRuleScoped $true
    • -SmartHosts entry needs to be set to the URL or IP Address of the Source environment server.
    • On Exchange 2003, 2007, and 2010, this will be the address of the Transport server.
    • On Exchange 2013 and 2016, this will be the address of the Mailbox server, not the Transport server.
    • If the Source environment is Hosted, you would need to obtain this address from the Hosted Provider.
    • If the Source environment is G Suite, you would need to change the -SmartHosts entry to be the following: 
      •  -SmartHosts “aspmx.l.google.com”
  5. Create Rule:
    $result = New-TransportRule -Name "PilotInABoxRule" -SentToMemberOf "BtNotMigratedUsers" -RouteMessageOutboundConnector "CBRConnector"

When a user is fully migrated, remove the user from the DL, and they will receive their email in their own Microsoft 365 mailbox.

There must be a mail-enabled contact on-premises for each user that has been migrated.

Coexistence 

Setting up Coexistence in Tenant to Tenant Projects

Microsoft 365 Tenant to Tenant Coexistence provides coexistence functionality for Microsoft 365 to Microsoft 365 migrations. When performing an Microsoft 365 migration and cutover is planned for a later date, migrations are done in batches. These types of migrations generally require coexistence so that the users on the source and destination can seamlessly communicate. This feature enables migrated users to be able to see the non-migrated users free/busy status and their contact details.  

Migration can be completed in batches, but all the users need to be in the same project. Once a project is set up, users can only be added or removed from the source environment, then use the Rediscover Items button in MigrationWiz to sync those changes. Users cannot be manually added or removed from the migration project.

Important: Microsoft 365 Tenant to Tenant migrations with Coexistence only support migration scenarios where the domain name is changing between the source and destination.  Migrating and keeping the same domain name is not supported at this time.

Important: Azure Active Directory Connect (ADFS, AADConnect, AADSync, ADSync, etc.) cannot be used to do anything with the destination user accounts until after the migration project is fully completed.

Setting up the Microsoft 365 Tenant to Tenant Coexistence

  1. Launch MigrationWiz and create a Mailbox project. For help creating a new Mailbox Migration project, see MigrationWiz Projects.
  2. Set up the Source and Destination endpoints as Microsoft 365. 
  3. Enable Tenant to Tenant Coexistence by selecting the checkbox during the initial project creation.
  4. Configure the Tenant to Tenant options.
    • Configure Domain Addresses: Enter the primary Source and Destination vanity domain names. The Source domain is optional and can be left blank. This will enable coexistence for all domains on the Source.
    • Setting Global Administrator Credentials: A Global Administrator account is required on both the Source and Destination endpoints. 
      Important: The destination tenant Administrator account needs to be able to access MSOnline, so the account must use the .onmicrosoft.com domain to ensure the correct access levels.
    • Choose Microsoft 365 License: Select the Microsoft 365 License type to be used on the Destination.  When the mail enabled contact is converted to a user account with a mailbox, this is the license that will be applied.
    • Migrate Distribution List and Groups: Select the groups that are to be included as part of this migration.  Changes to the Distribution Lists and Groups can be synced during the project. 
  5. Click Save and Go to Summary.

Distribution List Changes

It is possible to sync changes to the Distribution Lists before a migration by using these steps:

  1. Make your changes to the Distribution lists or groups in the Source Environment.
  2. Click Tenant to Tenant Management.
  3. Select Sync Distribution List.

Tenant to Tenant Migrations with Coexistence 

User Migration Bundle licenses are required for this migration. Only specific Microsoft 365 licenses are supported for this migration. The supported types are listed in the Migration Setup drop-down menu. Only one Microsoft 365 license type can be used per project and the Microsoft 365 license types cannot be changed once the project has been set up.

The migration can be completed in batches; however, all the users need to be in the same project.

Once a project is set up, you can use the Rediscover Items option in the Manage Tenant to Tenant menu to add/remove users from the project. The users must be removed or added to the Source environment before the Rediscover is used. Cloud accounts are created on the destination. User passwords will be created as part of the DeploymentPro Profile Configuration.

Azure Active Directory Connect cannot be used to do anything with the destination user accounts until after the migration project is fully completed.

One the Tenant to Tenant Coexistence option is selected and the migration is saved, the coexistence option cannot be removed. It is recommended to make sure that the scope and time frame of the migration is known ahead of time.

A Global Administrator account is absolutely required for both the source and destination endpoints. If one is not available to be used, then this migration type cannot be used.

All users on the source will be discovered to create mail-enabled contacts for those items on the destination. This migration type, therefore, is unsuitable for part divestitures from the source tenant. The mail-enabled contacts will be converted into cloud-only user mailboces. Synchronization with on-premises objects with AADC cannot be performed until after the migration.

Only a single-target domain is supported.

A Tenant to Tenant Migration with Coexistence project is unique in MigrationWiz.  While the overall process is no different from any other migrations, this specific type of migration does the extra setup to establish the coexistence link between the Source and Destination tenants.

After following the steps in the Microsoft 365 Tenant to Tenant Coexistence Project Setup Guide above, MigrationWiz will perform several actions in the background on both the source and destination to prepare the users for coexistence. This process is done automatically, there is no need for any actions to be done manually.

  1. Once the project is saved, MigrationWiz automatically opens both endpoints, connects to Azure Active Directory, and starts to configure the Microsoft 365 tenants for the project. This process can take up to one hour per 1000 users.
  2. Organizational Sharing and Individual Sharing are set up and enabled on the source and destination tenants; Free/Busy between the tenants.
    Coexist_1.png
  3. Users are discovered in the source tenant and mail contacts are created with an external email address of the primary domain on the destination tenant for the users. This will allow for reverse free/busy look up from the destination to the source as well as enable mail routing from the destination to the source.
    Coexist_2.png
  4. Once the automatic process is finished, the users are imported into the MigrationWiz project. The users are now ready to have User Migration Bundle licenses applied.  See MigrationWiz Licenses for steps on applying licenses. 
    Coexist_3.png 

Litigation Holds

We do support Litigation Hold migrations, but with some important known limitations.

​Be aware of these limitations since, for obvious reasons, Litigation Hold tends to have a 100% fidelity requirement. ​

All emails in the primary mailbox will indeed be migratedMigrationWiz is unable to migrate Litigation Hold data from the Archive Mailbox. If Litigation Hold data is in the Archive Mailbox, it must be moved to either the primary mailbox or the Recoverable Items.

Folders created in Litigation Hold are considered to be "email folders" but this is not necessarily the case. Therefore, all the special Litigation Hold items (whose type is not email) fail to migrate due to a known limitation in EWS (which is what MigrationWiz uses for migrations, when migrating from Exchange 2007+ as the source).

Several of these are considered to be email folders by EWS, even though they are not. Due to a bug in EWS, if you try to create a non-email item within those folders, it reports an error stating: "the item type does not match the folder type".

For example, if a contact is deleted, it will be stored in the /Purges folder. When we try to migrate this contact to the destination mailbox's /Purges folder, it reports an error.

Here are some known folders in the recoverable items mailbox:

  • Versions: If Litigation Hold (or for that matter, In-Place or single item recovery) is enabled, this subfolder contains the original and modified copies of the deleted items. Note: This folder is not visible to end users.
  • Purges: If either Litigation Hold (or single item recovery) is enabled, this subfolder contains all items that are hard-deleted. Note: This folder is not visible to end users.
  • Discovery Holds: If In-Place Hold is enabled, this subfolder contains all items that meet the hold query parameters and are hard-deleted.
  • Audits: If mailbox audit logging is enabled for a mailbox, this subfolder contains the audit log entries. This folder is not migrated with MigrationWiz.
  • Calendar Logging: This subfolder contains calendar changes that occur within a mailbox. This folder is not available to users.
  • Deletions: This subfolder contains all items deleted from the Deleted Items folder. (In Outlook, a user can soft-delete an item by pressing Shift+Delete.) This subfolder is exposed to users through the Recover Deleted Items feature in Outlook and Outlook on the web.

The folders indicated above will, by default, be migrated into a folder at the Destination, named "Deletions". Any mail items within these folders will be migrated. The non-email items will return an error in the MigrationWiz portal, but will not prevent the migration from completing. Typically there are only a few extra errors caused when performing Litigation Hold migrations (since most items in these folders are, in fact, email items) so the error count threshold will not need to be adjusted.

The migration process includes a folder discovery, plus it attempts to retrieve items from within each folder. If the attempts fail, this folder will be excluded during the migration, so that the migration can continue.

If you prefer to have the folders in the recoverable items mailbox migrated into their own corresponding folders at the Destination, and not migrated into a folder named "Deletions", you must add the Advanced Option (under the support section): OverrideRecoverableItemsFolderMapping="^SourceFolder->DestinationFolder" to your project before performing your migration.

Here are the recommended step-by-step directions for performing a migration that includes mailboxes set for Litigation Hold:

  1. Create a regular mailbox migration project, set the advanced options and submit mailboxes for migration. Follow directions under the migration guide for the appropriate scenario. All migration guides can be found in the MigrationWiz category of the BitTitan Help Center.
  2. Once the mailbox migrations have completed, create a new mailbox migration project specifically for Litigation Hold.
  3. Set the project advanced options for this Litigation Hold project, so that the Source: Migrate from: parameter is set to Recoverable Items. This will automatically set the Destination: Migrate to: parameter to be set to Recoverable Items.
  4. Return to the regular mailbox migration project dashboard, select completed migrated items, and move these items to the Litigation Hold project.
  5. Now, from the Litigation Hold project, submit items for migration. These will then migrate all items under the recoverable items folder at the source into the recoverable items folder at the destination.
  6. Once complete, move items back to the regular mailbox migration project.
  7. All emails will be migrated.
  8. Users will not be able to see anything that they should not be able to see.
  9. Mailbox migrations allow up to 10 passes per mailbox. Therefore, migrating mailboxes under the Litigation Hold project will not consume any additional licenses, provided that the items were moved between projects.
  10. Do not add new mailboxes under the Litigation Hold project. Instead, move items into this project. This way all project statistics and license history will be retained.​
  11. When migrating to recoverable options, it is recommended to increase the retention period for deleted items folder. The default retention period is 14 days. This should be increased to the maximum, which is 30 days. Steps for this are included in this TechNet article: https://technet.microsoft.com/en-us/library/dn163584(v=exchg.150).asp

Migrating Litigation Hold Data for Inactive Users

By default, mailboxes for inactive users with litigation hold are not migrated by MigrationWiz. Because the users are not licensed in the destination system, the mailboxes are not created, and the held items do not have a location to be migrated to.

It is possible to set up a migration specifically to migrate these held mailboxes. Use the steps below to create a project and migrate litigation hold data for inactive users in an Microsoft 365 to
Microsoft 365 tenant migration scenario:

  1. Find all inactive mailboxes. This can be done using the Powershell command below.
    Get-Mailbox -InactiveMailboxOnly -ResultSize Unlimited
  2. Add inactive users to MSPComplete either individually (Quick Add) or using a CSV (Bulk Add). 
  3. Create the target mailboxes in the destination Microsoft 365 tenant.
  4. Add licenses to the newly created mailboxes in Microsoft 365. (This requires at least an E3 license.)
  5. Set litigation hold on the new mailboxes.
  6. Set all the new mailboxes as Inactive. This will also remove the Microsoft 365 license from those mailboxes.
  7. Create a new MigrationWiz Mailbox project.
  8. Do not check the box for Tenant to Tenant Coexistence.
  9. Click Save Project.
  10. Add the email addresses for the inactive users to the project. The source email addresses must match the inactive mailbox UPNs. The destination email addresses should be the newly created email addresses that were created earlier in these steps. 
  11. Once the project is created, click Edit Project and select Advanced Options.
  12. Under both the Source and Destination sections, click Recoverable Items.
  13. Click Save.

The migration is now ready to be run. Other changes can be made if your scenario requires them, but no other settings are required to migrate mailboxes for inactive users.

If this migration fails, recover the inactive mailboxes before retrying the migration of the Recoverable Items.  Use the steps in this Microsoft document to recover the mailboxes: Recover an inactive mailbox in Office 365, then run the migration again when the mailboxes are recovered.

Litigation Hold vs. In-Place Hold

Litigation Hold migration involves putting a user's entire mailbox on hold for the purpose of retaining it for legal review.

In-Place Hold migration involves putting a subset of a user's entire mailbox on hold for the purpose of retaining only certain types of email.

The only difference between these two types of migration is a query. Litigation Hold can be enabled to hold all items that are deleted or modified. In-Place Hold is set up like Litigation Hold, but adds a filter query to only retain specific kinds of email.

Litigation Hold works like this:

In the normal deleted item workflow, a mailbox item is moved to the Deletions subfolder in the Recoverable Items folder when a user permanently deletes it, or deletes it from the Deleted Items folder. A deletion policy (which is a retention tag configured with a Delete retention action) also moves items to the Deletions subfolder when the retention period expires. When a user purges an item in the Recoverable Items folder, or when the deleted item retention period expires for an item, it is moved to the Purges subfolder in the Recoverable Items folder and marked for permanent deletion. It will be purged from Exchange the next time the mailbox is processed by the Managed Folder Assistant (MFA).

When a mailbox is placed on Litigation Hold, items in the Purges subfolder are preserved for the hold duration specified by the Litigation Hold. The hold duration is calculated from the original date an item was received or created, and defines how long items in the Purges subfolder are held. When the hold duration expires for an item in the Purges subfolder, the item is marked for permanent deletion and will be purged from Exchange the next time the mailbox is processed by the MFA.  If an indefinite hold is placed on a mailbox, items will never be purged from the Purges subfolder.

Troubleshooting

Migrating Large Items

The steps in this article require that you connect to Microsoft 365 with Windows PowerShell. Refer to the Connect to Office 365 PowerShell article from Microsoft for detailed steps on how to connect to Microsoft 365 using Windows PowerShell.

To migrate items to Microsoft 365 that are larger than th​e EWS defaults, you will need to run the following PowerShell scripts.

First, you should run this script against your Microsoft 365 environment to determine what your current settings are:

Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize

The user can be any standard user on Microsoft 365 that has an Microsoft 365 license assigned that contains a mailbox license. It should be a user whose settings have not been previously modified.

Example results:

MailboxPlan: ExchangeOnlineEnterprise-4b910ff9-8b91-4f2e-960c-302a90c95668
 
MaxSendSize: 35 MB (36,700,160 bytes)
 
MaxReceiveSize: 36 MB (37,748,736 bytes)

Next, run this script against your Microsoft 365 environment to set the Mailbox Plan, the Max Send Size and the Max Receive Size:

Get-MailboxPlan | Set-MailboxPlan -MaxSendSize 150MB -MaxReceiveSize 150MB

New users created after you change the mailbox plan will have 150MB as the max send and receive size. However, the current user will still have 35MB. To increase the limit for all users you can run:

Get-Mailbox | Set-Mailbox -MaxReceiveSize 150MB -MaxSendSize 150MB

The example below shows how you can validate that the new limits are applied:

PS C:\Windows\system32> Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize
 
MailboxPlan: ExchangeOnlineEnterprise-4e910ff9-8b91-4f2e-960c-302a90c65668
 
MaxSendSize: 150 MB (157,286,400 bytes)
 
MaxReceiveSize: 150 MB (157,286,400 bytes)

​Migrating Mailboxes Larger than 100GB

Follow these steps to migrate a mailbox larger than 100GB to Microsoft 365:

  1. Open MigrationWiz and create a mailbox migration project.
  2. Configure the Source and Destination Endpoints.
  3. Add the users to the project.
  4. Within the Advanced Options section, configure the destination settings to migrate to the Archive mailbox for the users. For additional information, read the  MigrationWiz - Advanced Options & General Options article.
  5. Set a date range filter within the project to migrate items older than a specific date. For example, migrate all items a year old or older to the Archive mailbox. For additional information, read Set a date range filter in MigrationWiz.
  6. Submit a Full migration pass that migrates only mail items. Monitor the migration until it is successful.
  7. Once the migrations to the archive mailboxes are complete, change the setting in the Advanced Options to now migrate to the primary mailbox instead of the archive mailbox.
  8. Remove the date range filter.
  9. Perform either a Pre-Stage migration or a Full migration pass to the primary mailbox.

Turn off Calendar Assistant

Calendar Assistant in Microsoft 365 can break meetings and recurring meetings in Outlook and OWA. We recommend that Calendar Assistant is turned off at the start of any migration. This feature can be turned again on after the migration has completed. There is no negative impact when Calendar Assistant is turned off.

Use PowerShell to create a remote session to Microsoft 365 to execute the following commands:

$cred= Get-Credential

$o365= New-PsSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -AllowRedirection -Authentication Basic

Import-PsSession $o365 –Prefix o365

Get-o365Mailbox -ResultSize unlimited | Set-o365Mailbox -CalendarRepairDisabled $true

The Calendar Assistant is now disabled for all mailboxes in the Microsoft 365 tenant. It can be enabled again by using this PowerShell command:

Get-o365Mailbox -ResultSize unlimited | Set-o365Mailbox -CalendarRepairDisabled $false

Create an Admin Account

The easiest approach to follow is to use the global admin account. This was set up at the time of tenant creation.

However, if you do not wish to use this global admin account during migration, then a new user account can be created instead. This will then need to be granted full access rights to each mailbox user.

Steps:

  1. Create a user in Microsoft 365: Create user mailbox in Exchange Online.
  2. Connect to Exchange Online by using remote PowerShell. For more information about how to do this, go to the following Microsoft website: Connect to Exchange Online Using Remote PowerShell
  3. Type the following command, and then press Enter:
    Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Admin')} | Add-MailboxPermission -User AdministratorAccount@mydomain.com -AccessRights fullaccess -InheritanceType all

After you perform these steps, the specified user will be able to access all user mailboxes in Microsoft 365. The user will be able to view the contents of the mailboxes from either Outlook or Outlook Web App.

Migrating to Microsoft 365 in China

The first thing that needs to be done is to determine exactly which version of Microsoft 365 in China that you want to migrate to.

The key factor here is where Microsoft 365 resides, for example whether or not Microsoft 365 is outside or inside the Chinese firewall.

The Chinese government runs and maintain the Great Firewall in China. There is an "international side" (outside the firewall) and a "mainland" side (inside the firewall). 

In MSPComplete, the "Microsoft 365 China" endpoint refers to "Micrsoft 365 China International." You can use this endpoint if you are migrating users to this international version of Microsoft 365 in China, the version that is outside the firewall.

However, if you are migrating to Microsoft 365 in China (inside the firewall), you should work with 21 Vianet. BitTitan has partnered with 21 Vianet to enable Partners to migrate to Microsoft 365 in China, inside the firewall. For more information on this partnership, read the blog here.

To initiate the process, contact 21 Vianet's sales department by sending an email to bluecloudsolutions@oe.21vianet.com.

Was this article helpful?
0 out of 2 found this helpful