Recommended Settings for Exchange Online Microsoft 365 Tenant to Tenant Coexistence with Azure AD Connect

This article is an overview of the recommended settings for our coexistence option to migrate mailboxes from one Microsoft 365 tenant to another when you are also using Azure AD Connect to sync objects into the target tenant. For step-by-step instructions on how to complete this type of migration, please visit this guide.

Important

Due to the deprecation of RPS (Remote PowerShell) for Exchange Online, it has been disabled for all tenants created before July 1st, 2023. Tenants created prior to this date will need to re-enable it by following the steps outlined by Microsoft here.

Any new tenants created after July 1st, 2023 will not be able to re-enable RPS.

There are a number of factors and issues to take into consideration for this type of migration. The recommendations detailed below offer mitigation strategies that may work in different scenarios to enable the use of the coexistence tool for discovery and provisioning while having Azure AD Connect in place.

IMPORTANT! Do not put anything in the "Source Tenant ID" and "Destination Tenant ID" fields (see below screenshot).  For Modern Authentication, the IDs will be added to the project's Advanced Options.  These fields were added for use at a later date.

Issues

Below is an overview of four primary issues that can occur with this type of migration. 

Object Creation Mail Forwarders Conflict of Objects Organization Enablement

Issue One – Object Creation

In a scenario where objects are being synced into a target tenant from an existing on premises Active Directory, we don't want to allow MigrationWiz to provision these items as well. MigrationWiz will see the items that are already there and assume they are duplicates, creating additional Mail User objects with '2' or '3' etc. after the name.

If electing to create the destination users manually in the destination tenant and not have MigrationWiz create them, the UPN prefix for the destination users must match the UPN prefix of the users in the source tenant. If they do not, the destination addresses that appear in MigrationWiz will have a prefix of DOES_NOT_EXIST. There is no current process to edit the addresses in bulk when this occurs.

Recommendations

The following configurations may help mitigate the problems outlined above. You should only need to complete one of these settings configurations in order to avoid problems. We suggest reviewing each recommendation separately, testing these options in small numbers, and choosing the one that best fits the scope and complexity of your migration project.

Prepare Project - Configure Mailboxes Before Discovery

If you are creating objects in your Azure AD by syncing with your local AD, license the mailboxes before you run the discovery and matching process in MigrationWiz. This way they will have a valid mail entity on which to place the forwarder for the coexistence to work.

For this process:

  1. Place mailboxes in a Mail Enabled Security Group on the Source Tenant
  2. Enable licenses and 'light up' the mailboxes in the target tenant.
  3. Run the project setup and discovery processes for the Coexistence project, using the settings outlined at the bottom of the section.

By doing this, the system will find the appropriate matches, apply forwarders, and be able to migrate data into the target mailboxes without errors.

IMPORTANT! Do not put anything in the "Source Tenant ID" and "Destination Tenant ID" fields (see below screenshot).  For Modern Authentication, the IDs will be added to the project's Advanced Options.  These fields were added for use at a later date.

mceclip1.png

 

Prepare Project - 'Just In Time'

This option functions in a similar fashion to the one above, but may be performed immediately before the migration to avoid consuming licenses unnecessarily in advance of the migration.

To use this option:

  1. Place mailboxes in a Mail Enabled Security Group on the Source Tenant
  2. Enable licenses and 'light up' the mailboxes in the target tenant.
  3. Run the project setup and discovery processes for the Coexistence project using the settings outlined at the bottom of the section.

By doing this, the system will find the appropriate matches, apply forwarders, and be able to migrate data into the target mailboxes without an errors.

IMPORTANT! Do not put anything in the "Source Tenant ID" and "Destination Tenant ID" fields (see below screenshot).  For Modern Authentication, the IDs will be added to the project's Advanced Options.  These fields were added for use at a later date.

The setup options are identical to the option above:

mceclip1.png

Light Setup

Using light setup means directing the project to skip the following:

  • Create mail users in the target tenant;
  • Perform any conversion of mail users into mailboxes during the prestage.

You will also skip applying licenses during the project setup. Essentially you are using the coexistence setup to run the discovery process via Group Membership.

This can happen when organizations have everything preplanned onsite along with contingencies around how they want to handle the mail forwarding and general coexistence. For this scenario, all of the tasks around mailbox provisioning would be handled by systems outside of MigrationWiz.

IMPORTANT! Do not put anything in the "Source Tenant ID" and "Destination Tenant ID" fields (see below screenshot).  For Modern Authentication, the IDs will be added to the project's Advanced Options.  These fields were added for use at a later date.

The setup screen would look like this;

mceclip3.png

 

MigrationWiz Provisioning

With a system that is creating the objects in the target tenant ahead of time, there is no actual backend identity management for the purpose of licensing. In this case, MigrationWiz should be set to perform the license management of the system but not to provision any of the Mail User objects/conversions itself.

IMPORTANT! Do not put anything in the "Source Tenant ID" and "Destination Tenant ID" fields (see below screenshot).  For Modern Authentication, the IDs will be added to the project's Advanced Options.  These fields were added for use at a later date.

To simply enable the license management piece, the selected options would look like this:

 

Configure Azure AD Connect (OU's) after MigrationWiz discovery

Test First!

Before going ahead with this type of setup for a full migration, we strongly suggest testing on your particular environment with a very limited number of mailboxes (less than five) to ensure that it has the desired effect you are looking for.

This solution may or may not be a viable option, and is more complex than the previous recommendations. We strongly suggest testing the other options and only trying this one if they don't solve the issue.

In general, there are two options available for when you first set up the Azure AD Connect. The configuration can either wait until the migration progress can start, or the Organization Units (OUs) that are scoped for the Azure AD Connect synchronization can be limited to particular OUs in the source, which enables far more granular control of the contents of the OUs. With this in mind, you can provision a project that would have a set number of users in it, configured to create mail user objects, run conversions during pre-stage and perform the licensing.

IMPORTANT! Do not put anything in the "Source Tenant ID" and "Destination Tenant ID" fields (see below screenshot).  For Modern Authentication, the IDs will be added to the project's Advanced Options.  These fields were added for use at a later date.

The settings should be set up like this:

 

In the below example, Kirk Duerr would show up as a valid Mail User in the EAC with a forwarder back to his source mailbox.

mceclip3.png

Next, trigger the OU in Azure AD Connect to perform the synchronization of the object into Microsoft 365. Once completed, Kirk would show up as a valid user in Microsoft 365, but with the 'Synced with On Prem' tag next to him as shown below;

mceclip4.png

Now run the pre-stage task on his mailbox. Since the UPN on the Mail User object and the object in Azure AD both exist, the system would join those two together and enable his Mail User object for active email.

Once this is complete, the Mail User entity is gone and the Active User in the Microsoft 365 console now has a license attached, along with a valid mailbox. The forwarder for his now active mailbox in the target tenant also remains intact. 

This may not work for all scenarios.

mceclip6.png

mceclip7.png

mceclip8.png

 

mceclip5.png

 

 

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