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.
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.
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.
Issue Two – Mail Forwarders
If Azure AD Connect is used to provision 'just' the identities in the target tenant, then they will exist as non-mail enabled entities. MigrationWiz isn't going to be able to apply any type of forwarder to these objects, and will cause repeated failure messages when trying to do so. You will need to deselect this option in the project setup and look after this portion on the target tenant.
Issue Three – Conflict of Objects
If items are being created by Azure AD Connect into the Microsoft 365 target tenant, it will perform a certain amount of logic around what it considers a match of UPN or SMTP address on items that may already exist, like Mail Users etc. It is wise to limit the scoping of changes made by Azure AD Connect after a project has run, especially if the project has been configured to create Mail Users in the target. To avoid this, perform tests with small subsets of objects prior to making any big changes to the system. This is helped in MigrationWiz by the ability to Scope the Discovery by way of Mail Enabled Security Groups on the source tenant. Please refer to the main guides on exactly what the options do before undertaking any large projects.
Issue Four – Organization enablement
MigrationWiz cannot create an organizational relationship for domains entered in the project if they already pre-exist in an Organization Sharing or Individual Sharing policy in the source or destination tenant. MigrationWiz also cannot modify a policy that it has already created in a tenant with subsequent attempts, or if migrating with more than one Tenant to Tenant Coexistence MigrationWiz project.
During project setup, if the Organization-Enablement step is failing, please try to edit the project and save it. The issue could be caused by timeouts errors thrown by the Microsoft tenant while running this step and it needs to be manually tried again if the step is unsuccessful. If this step is failing persistently, it is likely that you have an existing organization relationship configured in your source or destination tenant that is using one of the source or destination domain names that you are trying to setup the project for.
In this scenario please use the Exchange Admin Center (this must be done for both source and destination):
- Login to the Exchange Admin Center
- Go to Organization > Sharing. Under Organization Sharing, select the Organization Relationship and click ‘Edit’
- Select the domain(s) (used for project setup) and remove the domain(s) from organization relationship:
- Verify that the step is complete, Login to Powershell and issue the following commands:
i) Connect-ExchangeOnline
ii) Get-OrganizationRelationship | Select Name, DomainNames
Ensure that the source or destination domains are not listed under any Organization relationship
- Try to resume project setup for the T2T Coexistence project again by clicking on Edit and Save
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
For this process:
- Place mailboxes in a Mail Enabled Security Group on the Source Tenant
- Enable licenses and 'light up' the mailboxes in the target tenant.
- 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.
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:
- Place mailboxes in a Mail Enabled Security Group on the Source Tenant
- Enable licenses and 'light up' the mailboxes in the target tenant.
- 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:
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;
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.
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;
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.
