Exchange Mailbox Migrations FAQ

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 would specify on each mailbox (depending on your configuration):

  1. domain.com\admin\user1
  2. domain\admin\user1
  3. domain\admin@company.com\user@company.com

Full Access Permissions for Exchange Account for Intermedia Hosted Exchange

For Intermedia-hosted accounts only

Navigate to Control Panel at https://controlpanel.msoutlookonline.net and log in using your administrator account.
  1. Navigate to Services, and click on Exchange Mailbox.
  2. Click on the display name for the mailbox that you want to grant full access permissions.
  3. Click on 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 on the Check Name button to check the name. You can also select the name from address book. 
  5. Click on Add to add the administrator account.
  6. Select Full Access and then, in the Access Allowed for window, click on 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 assistances.

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

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

Specifically, for Exchange server 2010+, running SP1+, here is how rules and permissions are handled:

Rules:

  • 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, and so 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 (like OWA), then we also 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 could 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 MigrationWiz 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:

  1. Filter unnecessary large folders.
  2. Split the large folders into smaller ones (less than 5,000 items).

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:

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

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:

  1. Filter unnecessary large folders.
  2. 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.

In the example screenshot below, 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 Can I migrate a Source mailbox into a single subfolder of a Destination mailbox? article for more information about how to circumvent 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 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.

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 Office 365 to
Office 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 Office 365 tenant.
  4. Add licenses to the newly created mailboxes in Office 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 Office 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.

Autodiscover

Finding the main AutoDiscover URL and Certificate Principal Name for a Hosted Exchange provider

This article provides the steps to follow to determine the main AutoDiscover URL and Certificate Principal Name for your Hosted Exchange Provider.

These steps are only neccessary 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.

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, within your DeploymentPro project, rather than the end user OWA URL. The reason for this is that some smaller Hosted Exchange providers have not set up their DNS Autodiscover redirects properly. This 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.

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

Option 1

  • Obtain the OWA URL from your Destination Hosted Exchange provider. Enter this into a browser window. Upon connection to the Hosted Exchange provider, there will be an auto redirect to the main AutoDiscover URL of the Hosted Exchange provider. 
  • Make a note of this URL, and enter this into your DeploymentPro project (more details on where to enter this are provided at the bottom of this article).

Option 2

Ask your Hosted Exchange Provider for the main AutoDiscover URL.

  • Make sure that you ask for the main AutoDiscover URL, and not the AutoDiscover or OWA URL that is specific to your customer.
  • This is required is because if you enter the customer AutoDiscover URL, there will be a 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 will fail to 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 Certifcate Prinipal 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 on the Test button.
  5. In the results window, look for the entry for Certificate Principal Name, as shown in this screen shot:

cert plan.PNG 

Important: The screen shot above is for Office 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.

autodiscover.PNG

The screen shot above is for Office 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.​

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

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.

How do I filter objects using Azure Active Directory (AAD) Connect?

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

  • Important:
    • If you are using AAD Sync, instead of AAD Connect, as your synchronization tool, 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 Office 365 as a production platform. You would want to filter out all objects except those user objects that are already using Office 365. This way only those objects would be included in the synchronization.
  • You are planning a batch migration to Office 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 Office 365. This will allow users to send email to the on-premises users, after mail routing has been enabled on Office 365.

Summary explanation

The filter, based on a specific attribute, will clear the msExchMailboxGuid for the synchronized objects, and thus avoid any service disruption for those users already using Office 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 very important that you are familiar with AAD Connect and PowerShell syntax.
  • The screen shots are from Microsoft Azure Active Directory Connect, version 1.1.189.0. If you are using other versions, the screen shots 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):
KB005809_Change_ExtensionAttribute.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. Note: 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. Also, take note of the lowest precedence number (in this example it is 80). You will need it below.
    KB005809_Export_Usr_Exch_Rule.jpg

A Notepad (or other text editor defined as a default) will open, with a randon name and a .tmp extension.
Important: Save the file and keep it in a safe location. The file will allow you to recreate the default rule without any customization if something goes wrong.

KB005809_Temp_Notepad_File.jpg

4. After you save the file, create a duplicate, change the extension to .ps1, and edit the file.
KB005809_Notepad_Dir.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 4 (in our example, it was 80).
    • Delete the lines identifier and ImmutableTag.

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

KB005809_Changes_to_Rules.jpeg
 

5. Open a PowerShell with elevated privileges, navigate to the folder where you store the .ps1 file, and execute the script. After it finishes, scroll up and validate that no error appears. 
KB005809_Execute_ps1.jpg

6. Confirm that a new line was created in the Synchronization Rules Editor. Note: There is no refresh, so you will need to close and reopen it to confirm that a new line was created:
KB005809_New_AAD_Connect_Rule.jpeg

7. Now, edit the rules.

    • Start with the customized synchronization rule.
    • Highlight the rule and click Edit.
      KB005809_Edit_Customized_Rule.jpg
    • Select Scoping filter and click the Add clause button. This will create a new line. Choose the extensionAttribute used before. Under Operator, select EQUAL and populate the Value with "BT - User Migrated".  Then select Transformations.
      KB005809_Change_Scoping_Filter.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
      KB005809_Change_Transformation.jpg

    • Click Save. The window will close automatically.
    • Now, 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:
        KB005809_Change_Scoping_Filter_1.jpg

8. Perform a FULL Sync.  Note: 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:
    KB005809_Delete_Synchronization_Rule.jpg
    KB005809_Confirm_Delete_Synchronization_Rule.jpg
  2. Remove the clause from the Scoping filter of the original rule:
    KB005809_Deleting_Clause.jpg

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