Exchange migrations vary by source and destination version. The migration guide specific to your scenario will guide you through the steps needed to perform your migration, but the following article contains more general information and explanations about some of the commonly asked questions concerning this migration type.

Access

Migrating via administrative credentials 

Some Exchange IMAP systems support administrative login. To use this feature:

1. On each mailbox, specify the user name as follows:
   • domain\adminUserName\mailboxUserName
2. On each mailbox, specify the administrator's password.

Here are some examples of user names you might specify on each mailbox, depending on your configuration:

• domain.com\admin\user1
• domain\admin\user1
• domain\admin@company.com\user@company.com

Full Access Permissions for Exchange Account for Intermedia Hosted Exchange

Migrated Items

Rules & Permissions

Rules and permissions can only be migrated from Exchange Server 2010+ (or Microsoft 365). This is due to API limitations in earlier versions of Exchange. Additionally, your migration Destination must be Exchange Server 2013+ (or Microsoft 365).

For Exchange server 2010+ running SP1+, this is how rules and permissions are handled:

Rules

Rules will appear as an option when the Source is set to Exchange 2003+, but can only actually be migrated from Source servers that are Exchange Server 2010 and later, running SP1+. The reason for this slightly confusing User Interface (UI) setting is that we have bundled all Exchange Server versions into one Source option: Exchange 2003+. This is to simplify choosing your Source environment within our UI.

• We migrate server-side rules. We do not migrate client-side rules.
• Exchange migrations only migrate the permissions of system folders by default. System folders include folders like "Inbox", "Sent" and "Trash". However, if the customer wants to migrate permissions for all folders, they can use the advanced option “MustMigrateAllPermissions=1".
• Migration of rules under a multi-geo tenant is currently not validated within MigrationWiz

Folder permissions

• We migrate folder permissions but not delegate/sharing permissions, which means that "Send As" and "Send On Behalf Of" permissions are not migrated.
• Folder permissions are those permissions that are granted at each folder level within a mailbox. These can be set from within a mailbox, by right-clicking on the folder, selecting Properties, clicking on the Permissions tab, and defining the Permissions there.
• Delegate permissions are set from Tools/Options/Delegates. These are not migrated, so they will need to be reset post-migration.

Resource Migration

Distribution Lists

Server-based Distribution Lists are not migrated with MigrationWiz since it does not include Distribution List discovery. Personal Distribution Lists are not migrated by MigrationWiz.

When referring to Distribution Lists, there is an important distinction between server-based Distribution Lists and personal Distribution Lists. Server-based Distribution Lists appear in the Global Address List, while Personal Distribution Lists are stored locally.

Personal Distribution Lists are now called Contact Groups in Microsoft 365.

If you have server-based Distribution Lists, your options include the following:

• Use Microsoft (e.g., Microsoft Entra Connect formally known as Microsoft Entra Sync) to synchronize the Distribution Lists between your Source environment and your Destination environment. 
• Create your own PowerShell scripts to export and import these. Examples from Microsoft can be found here.
• Manually recreate the Distribution Lists at the Destination.

Other Source systems will not have (Exchange) Distribution Lists. Partners should create Distribution Lists post-migration, and then add the necessary users into the Distribution Lists, based on the membership of equivalent groups/Distribution Lists from the Source.

Folder Conversion

Folder size migration impact

Please refer to the appropriate version of your software below:

Exchange 2003

Exchange 2003 data export speeds may be degraded when enumerating folders that exceed the Microsoft recommended guidelines. As described by the TechNet article, Understanding the Performance Impact of High Item Counts and Restricted Views, Microsoft states "with Exchange Server 2003, the recommended maximum item count per folder was 5,000 items."

The only workarounds for the large folder issue are:

Exchange 2007

Exchange 2007 data export speeds may be degraded when enumerating folders that exceed the Microsoft recommended guidelines.

As described by the TechNet article Understanding the Performance Impact of High Item Counts and Restricted Views, Microsoft states "in Exchange 2007, improvements in I/O, larger page size, and increased cache can help enable an increase in the recommended maximum item count. With properly architected hardware, an acceptable user experience can still be maintained with item counts as high as 20,000 items."

Note that enumeration is only slow for the folders that exceed the maximum item count guidelines, and does not affect folders that are smaller than these recommended sizes.

The only workarounds for the large folder issue are:

• Filter unnecessary large folders.
• Split the large folders into smaller ones (less than 20,000 items).

Exchange 2010, 2013, 2016, and Microsoft 365

Exchange 2010+ data export speeds may be degraded when enumerating folders that exceed the Microsoft recommended guidelines.

As described by the TechNet article Understanding the Performance Impact of High Item Counts and Restricted Views, in Exchange 2010, 2013, and 2016 the maximum folder size is 100,000 items.

Note that enumeration is only slow for the folders that exceed the maximum item count guidelines, and does not affect folders that are smaller than these recommended sizes.

The only workarounds for the large folder issue are:

• Filter unnecessary large folders.
• Split the large folders into smaller ones (less than 100,000 items).

Different folder types at destination

After performing a mail-only mailbox migration, you may notice that some folders are of a different folder type (i.e., mail folder instead of calendar folder) in the Destination, and that some items may be missing. This happens when mail folders contain non-mail subfolders such as calendar or contact subfolders.

Example: Folder 1 is a mail folder, and Folder 2 (a subfolder of Folder 1) is a calendar folder in the Source environment. If you perform a mail-only mailbox migration, then Folder 1 and its subfolders are migrated. However, Folder 2 is converted to a mail folder in the Destination and calendar items saved within that folder are missing post-migration.

To circumvent this issue, we recommend that you direct users to separate folders of different types and move non-mail folders to the root. If separating folder types is not possible, we recommend that you perform a full migration of all mailbox item types (mail, calendar, contacts, etc.).

This issue can also occur when using the folder mapping support option to map the contents of a Source mailbox into a single folder on the Destination. Read the MigrationWiz - Email Migrations - FAQ article for more information about how to avoid this issue.

Forward slash file names

During migration, MigrationWiz will convert any instances of a forward slash  "/"  in an Outlook folder name to an underscore  "_".  This requirement was designed to overcome the limitations of the underlying migration protocols being used, e.g., Exchange Web Services (EWS) for migrations from Exchange 2007+ servers.  

Litigation Hold Migrations

We do support Litigation Hold migrations but with some limitations. It's important to be aware of these limitations since Litigation Holds tend to have a 100% fidelity requirement. ​

All emails in the primary mailbox will be migrated, but MigrationWiz 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 non-email Litigation Hold items will fail to migrate due to limitations 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 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 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.

For example, add all Advanced Options below to migrate the Source folders to their corresponding folders at Destination,

OverrideRecoverableItemsFolderMapping="^Calendar Logging->Calendar Logging"
OverrideRecoverableItemsFolderMapping="^Deletions->Deletions"
OverrideRecoverableItemsFolderMapping="^DiscoveryHolds->DiscoveryHolds"
OverrideRecoverableItemsFolderMapping="^Purges->Purges"
OverrideRecoverableItemsFolderMapping="^Versions->Versions"

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 the 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 been 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 the 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 holds 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 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 of 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 to retain it for legal review.

In-place hold migration involves putting a subset of a user's entire mailbox on hold to retain 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.

How Litigation Hold works

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 a 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.

Autodiscover

Find the main Autodiscover URL and Certificate Principal Name for a Hosted Exchange provider

The main Autodiscover URL is different from the Autodiscover URL that your end users enter as their Outlook Web Access (OWA) URL. It is important to include the main Autodiscover URL for the Hosted Exchange provider in your DeploymentPro project, rather than the end-user OWA URL. If your Hosted Exchange provider has not set up their DNS Autodiscover redirects properly, it can cause problems when reconfiguring profiles based on the end user Autodiscover URL. For this reason, it is important to enter the main Autodiscover URL instead of the end user OWA URL.

When setting up your DeploymentPro project with a Destination endpoint that is Exchange 2003+, there will be a section in the DeploymentPro portal for Autodiscover Preferences. Further details on what to enter in the fields can be found toward the end of this Knowledge Base article.

The steps below provide the necessary information on how to ascertain both the main Autodiscover URL and Certificate Principal Name for your Destination Hosted Exchange provider and show where this information needs to be entered within your DeploymentPro project. These steps are only necessary when migrating to a Hosted Exchange provider using DeploymentPro. See What Destination systems are supported by DeploymentPro? for what systems are officially supported for use with DeploymentPro.

How to find the main Autodiscover URL for your Destination Hosted Exchange provider:

Option 1

1. Obtain the OWA URL from your Destination Hosted Exchange provider. Enter this into a browser window. Your browser will automatically redirect to the main Autodiscover URL of the Hosted Exchange provider. 
2. Enter this URL into your DeploymentPro project. See below for more details.

Option 2

Ask your Hosted Exchange Provider for the main Autodiscover URL.

How to find the Certificate Principal Name:

Option 1

Ask your Hosted Exchange Provider for the Certificate Principal Name.

Option 2

Configure one Outlook profile manually for a test or active mailbox user.

1. From this manually configured profile, while Outlook is running, hold down the CTRL key, right-click on the Outlook icon in your system tray or notification area (lower-right corner of the computer screen), and then select Test E-mail AutoConfiguration. 
2. Enter your email address and password.
3. Clear the check boxes next to Use Guessmart and Secure Guessmart Authentication. Make sure that Use Autodiscover is selected.
4. Click the Test button.
5. In the results window, look for the entry for Certificate Principal Name, as shown in this screenshot:

Where to enter the main Autodiscover URL and Certificate Principal Name in DeploymentPro:

Upon the first launch of DeploymentPro for your customer, there will be some fields for Autodiscover URL and Certificate Principal Name.

Enter the information gathered from the above steps into these fields:

The screenshot above is for Microsoft 365. The Certificate Principal Name for your Hosted Provider will contain URL information for your Hosted Exchange provider.

Export from Exchange 2007 using WebDAV

Filter objects using Microsoft Entra Connect

This section explains the steps required to set a filter using Microsoft Entra Connect that will clear the msExchMailboxGuid so objects can be synchronized between environments.

The following are example use cases where filtering objects from the synchronization could be advantageous:

• Some users are already using Microsoft 365 as a production platform. You would want to filter out all objects except those user objects that are already using Microsoft 365. This way only those objects would be included in the synchronization.
• You are planning a batch migration to Microsoft 365. You would then want to filter out all objects except those user objects that are part of the batch, or any previous batch. This way only those objects would be included in the synchronization.
• You do not have the required Exchange Online licenses to assign to all the users. This would be useful so that you can then assign licenses to all synchronized accounts.
• Enabling the Exchange Online license will cause an error.

Summary explanation

The filter you choose will clear the msExchMailboxGuid for the synchronized objects, and thus avoid any service disruption for those users already using Microsoft 365.

Follow the steps below to guide you through the process of creating a new rule on Microsoft Entra Connect and filtering objects based on one extensionAttribute (called customAttribute on Exchange, and extensionAttribute on Active Directory Schema).

• Before you start, you must be familiar with Microsoft Entra Connect and PowerShell syntax.
• The screenshots in this guide are from Microsoft Microsoft Entra Connect, version 1.1.189.0. If you are using other versions, the screenshots may be different.

Pre-Migration Tasks

1. Choose one extensionAttribute that can be populated with a customized tag. In our example, we will use extensionAttribute 5 and the tag "BT - User Migrated".
2. Populate the extensionAttribute of the users that you are planning to assign an Exchange Online license, with the chosen Tag. This step can be executed in any of the following ways:

a. Using Exchange Management Console (EMC):

b. Using Exchange Management Shell (EMS) by executing the following script:

Set-Mailbox <user_UPN> -customAttribute5 "BT - User Migrated"

c. Bulk edit using EMS:

• Create a users.CSV file with the UPN of the users that you what to enable the Exchange Online. It should look like this:

d. Execute the following PowerShell script:

$UserList = Import-CSV '<Path Name>\Users.csv'
foreach( $user in $UserList )
{
     Set-Mailbox $user.UPN -customAttribute5 "BT - User Migrated"
}

3. Search and select the rule.

• In Windows, search for the Synchronization Rules Editor, and open it. The default location is C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe.
  
• Search and select the rule with the name In from AD - User Exchange and click Export. Take note of the lowest precedence number, you will need it later. In this example, the lowest precedence number is 80.
  

The system's default text editor, such as Notepad, will open with a random name and a .tmp extension. Save this file in a safe location. The file will allow you to recreate the default rule without any customization if something goes wrong.

4. After you save the file, create a duplicate, change the extension to .ps1, and edit the file.

On the .ps1 file:

• • Change the Name to identify that it is a customized rule.
  • Change Precedence to a number lower than the number found in Step 3.
  • Delete the lines Identifier and ImmutableTag.

After the above modifications have been made, the file will look like this:

5. Open a PowerShell with elevated privileges, navigate to the folder where you saved the .ps1 file, and execute the script. After it finishes, scroll up and check for errors. 

6. Close and reopen the file to confirm that a new line was created in the Synchronization Rules Editor:

7. Now, edit the rules.

• Start with the customized synchronization rule.

• Highlight the rule and click Edit.
  
• Select Scoping filter and click the Add clause button. This will create a new line. Choose the same extensionAttribute as before. Under Operator, select EQUAL and populate the Value with "BT - User Migrated", then select Transformations.
  

• Scroll down until you find the msExchMailboxGuid attribute, and change it to the following:

  Flow Type: Expression
  Target Attribute: msExchMailboxGuid
  Source: NULL

  Merge Type: Update
  
  

• Click Save. The window will close automatically.

• Next, edit the original Synchronization rule. On the Scoping filter, click Add clause, and add the extensionAttribute, NOTEQUAL, and BT - User Migrated.
• It will look like this:
  

8. Perform a FULL Sync. A DeltaSync will not make the required changes. 

An easy way to perform this step is to open a PowerShell on the computer where Microsoft Entra Connect is running, and execute the following script:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Initial

9. Enable the Exchange Online license for the required users.

10. Using EMC, AD, or using PowerShell, remove the tag BT - User Migrated from the users. If you use PowerShell, replace BT -User Migrated with $null. 

11. Perform a DeltaSync.

An easy way to perform this step is to open a PowerShell on the computer where Microsoft Entra Connect is running, and execute the following script:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

Post-migration tasks

After you enable all the required Exchange licenses in Office 365, you can revert all the changes made on Microsoft Entra Connect:

1. Highlight and delete the customized synchronization rule:
   
   
2. Remove the clause from the Scoping filter of the original rule:
   
   
   It should look like this: