Exchange Mailbox Migrations FAQ

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

For Intermedia-hosted accounts only
Navigate to the Control Panel and log in using your administrator account.
  1. Navigate to Services, and click Exchange Mailbox.
  2. Click on the display name for the mailbox that you want to grant full access permissions.
  3. Click Exchange. In the Mailbox access area, click on the Full access & Send as link.
  4. In the new window, enter the administrator name you want to use for migration, and click the Check Name button to check the name. You can also select the name from address book. 
  5. Click Add to add the administrator account.
  6. Select Full Access and then, in the Access Allowed for window, click Save Changes.​

The step-by-step process above is a general guideline, and is subject to change. If you encounter issues with granting full access permissions, contact Intermedia for assistance.

Migrated Items

Rules & Permissions

Rules and permissions can only be migrated from Exchange Server 2010+ (or Office 365). This is due to API limitations in earlier versions of Exchange. Additionally, your migration Destination must be Exchange Server 2013+ (or Office 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 the 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 advanced option “MustMigrateAllPermissions=1".

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 individual 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

The information in this article is specific to the Source as Exchange or Office 365, and the Destination as Exchange or Office 365.

We handle resource mailboxes the same way that we handle regular user mailboxes.

If you can log in to the resource mailbox using a web client (i.e., Outlook Web Access), we should be able to log in as well, and migrate the data. If there is no way to log in to the resource mailbox using a web client, then we cannot log in and migrate the data.

In some cases, the resource mailbox is just a shared calendar that is owned by a user. For those cases, when the user's mailbox is migrated, we should be able to migrate the resource mailbox calendar as one of the user's calendars. Once the migration is complete, you can set sharing/permissions on the calendar so that it can be accessed by other users.​​​

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 Office 365.

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

  • Use Microsoft (e.g., AAD Connect formally known as AAD 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.
If migrating from Hosted Exchange, ask the Hosted Exchange provider to export the Distribution Lists to a CSV file, and then import them into Office 365, based on the information in the CSV file.

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:

Exchange 2010, 2013, 2016, and Office 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:

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.  

Note: The most common occurrence of this conversion is folder names containing dates with "/".

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

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

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

Note

Make sure that you ask for the main Autodiscover URL, and not the customer-specific AutoDiscover or OWA URL. The customer Autodiscover URL will automatically redirect to the main Autodiscover URL. If the Hosted provider has not set up their DNS properly, this redirect will fail and the Outlook profiles won't be reconfigured properly.

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.

Note: When setting up this profile, bypass the Autodiscover warning messages to complete the profile configuration. Once this profile has been created, you can use the settings to determine the Certificate Principal Name for your Hosted Exchange provider. This can then be entered into your DeploymentPro portal, so that all future profiles can be configured with this Certificate Principal Name stored in the profiles.

  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 checkboxes 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 screen shot:

1.PNG 

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

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

Upon 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:

2.PNG

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

By default, when Exchange 2007 is the Source server, we will export the data using EWS.​

Important: Once a mailbox has begun a migration, you will not be able to switch from one to the other. The system will prevent you from doing this by failing on submission. The reason is that we cannot detect duplicates between the two methods. Switching will require the removal of previously-migrated data first. The following options need to be set prior to migration.

To force all mailboxes within a connector to use WebDAV:
  1. Sign in to your MigrationWiz account.
  2. Click Dashboard.
  3. In the Mailbox Migration section, click Perform mailbox migration.
  4. Select your Mailbox Connector.
  5. From the Task menu, click Edit connector.
  6. Click the link Show Advanced Options.
  7. For the field Support Only Options enter MustUseWebDav=1.​

Ensure that the Destination mailbox is cleaned up (or recreated) prior to switching, or the migration will result in duplicates.

If you switched the export method after a migration has begun, your migration will fail with an error stating so. If this is intentional, contact our Support team.

Filter objects using Azure Active Directory (AAD) Connect

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

Note

  • If you are using AAD Sync, the steps will be very similar to the ones detailed below.
  • If you are using DirSync, the steps will not be similar enough. In this case, we recommend that you upgrade to either AAD Sync or AAD Connect.

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.

Important: In all of the scenarios above, you would still want to synchronize all the objects using AAD Connect in order to have a complete Global Address List (GAL) on Microsoft 365. This will allow users to send email to the on-premises users after mail routing has been enabled on Microsoft 365.

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 AAD Connect and filtering objects based on one extensionAttribute (called customAttribute on Exchange, and extensionAttribute on Active Directory Schema).

  • Before you start, it is important that you are familiar with AAD Connect and PowerShell syntax.
  • The screenshots in this guide are from Microsoft Azure Active Directory 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 to, with the chosen Tag. This step can be executed in any of the following ways:

a. Using Exchange Management Console (EMC):
3.jpg

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:
​UPN
​UserA@mydomain.com
​​​​UserB@mydomain.com
​​​UserC@mydomain.com
​...
​​​UserZ@mydomain.com

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.
    4.jpeg
  • 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.
    5.jpg

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.

6.jpg

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

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:

8.jpeg
 

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. 
9.jpg

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

7. Now, edit the rules.

    • Start with the customized synchronization rule.
    • Highlight the rule and click Edit.
      11.jpg
    • 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.
      12.jpg
    • 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
      13.jpg

    • 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:
        14.jpg

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 AAD 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 AAD 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 AAD Connect:

  1. Highlight and delete the customized synchronization rule:
    15.jpg
    16.jpg
  2. Remove the clause from the Scoping filter of the original rule:
    17.jpg

    It should look like this:
    18.jpg
Was this article helpful?
0 out of 0 found this helpful