United States | A Modern Migration Challenge

Joseph Cirillo - 10.12.202120211210

A Modern Migration Challenge

United States | A Modern Migration Challenge

There are many challenges when an organization has two business units (BUs) operating in separate Microsoft 365 (M365) tenants. One common struggle is the inability to natively operate under a single brand (i.e., SMTP vanity domain) across the unique tenants. Although Microsoft does have SMTP domain sharing on their roadmap (Feature ID: 67161: Exchange: Microsoft 365 cross-tenant SMTP domain sharing in private preview), it is still in development.

Recently we worked with a client who needed to migrate a subset of their users from a source tenant to a destination tenant simply because the SMTP domain these users were required to operate from was active in the destination tenant.

On the surface this may sound like a very straightforward task, however as we began to peel back the onion, we identified quite a few interdependencies and challenges.

Note:    Password Hash Synchronization is the method of authentication to M365 used by both source and destination BUs.

  1. Both the source and destination BU each operate their own Active Directory (AD)
  2. Both the source and destination BU each operate their own M365 tenant
  3. Both the source and destination BU each have their local Active Directory synchronized to their unique M365 tenants in a hybrid identity configuration using Azure AD Connect
  4. Post-migration, the source AD user needs to authenticate to their destination M365 mailbox using their source AD credentials
  5. Neither the source nor destination BU have a local Exchange server available for mail-related attribute manipulation, although they do have critical mail attributes populated
  6. The source and destination BU have differing naming standards for the userPrincipalName (UPN) and Primary SMTP Address
  7. The source AD user’s UPN suffix cannot change due to a tightly integrated provisioning system. The UPN prefix can change
    • a. Post migration, the AD user’s UPN will not match their Primary SMTP Address
  8. There is a variety of user and mailbox configurations in play
    • a. A synced source AD user with an M365 mailbox exists in the source tenant, however it does not exist in the destination tenant
    • b. A synced source AD user with an M365 mailbox exists in the source tenant and a duplicated AD account in the destination AD is synced to the destination tenant and has an M365 mailbox
    • c. A synced source AD user with an M365 mailbox exists in the source tenant and a duplicated cloud-only user account with an M365 mailbox exists in the destination tenant (no local destination AD account)
    • d. A synced source AD user with an M365 mailbox exists in the source tenant and a duplicated AD account in the destination AD is synced to the destination tenant, however this user has no M365 license (just an M365 directory object)
  9. For each of the mailbox configurations listed in #8, the source AD user’s primary work mailbox may either be on the source or destination tenant
    • a. If the source AD user’s primary mailbox is on the source tenant and a duplicated mailbox exists on the destination tenant, mail forwarding is enabled on the destination tenant mailbox
    • b. If the source AD user’s primary mailbox is on the destination tenant, then mail forwarding is enabled on the source tenant mailbox
      • i. Authentication to the destination mailbox is via the destination AD account credentials, or in the case of a cloud-only account, the destination Azure AD credentials
  10. For any source mailbox provisioned, a representative Contact object is created in the destination tenant
  11. For any destination mailbox provisioned, a representative Contact object is created in the source tenant

Pre-Migration Configuration

United States | A Modern Migration Challenge

Once all the challenges were identified, a strategy for transition was determined.

The first thing was to ensure an exact mapping between source and destination objects. We identified ‘Custom Attribute 5’ as our primary key and populated it on all source and destination AD and M365 objects with a value which represents the final destination-branded Primary SMTP address.

We then developed a series of PowerShell scripts to execute the following process.

Important! Please note the steps below only demonstrate the directory-related changes which were made to accommodate the transition from source to destination tenant. No migration tooling or data migration specific activities are noted.

Note:    Although not specifically called out in the steps below, the PowerShell scripts addressed all the identified challenges. For example, writing to mail-related attributes without the presence of a local Exchange server, manipulating or updating Contact objects in each tenant, etc.

  1. Provision destination mailbox as cloud-only object, if does not exist
  2. Capture source AD user information
  3. Capture source M365 mailbox information
  4. Capture destination AD user information
  5. Capture destination M365 mailbox information
  6. Clear mail forwarding on destination mailbox
  7. Apply mail forwarding on source mailbox
  8. Remove source AD user from Azure AD Connect scope
  9. Remove destination AD user from Azure AD Connect scope (if this exists)
  10. Restore source M365 user as cloud-only account and clear ImmutableID attribute
  11. Restore destination M365 user as cloud-only account and clear ImmutableID attribute
  12. Set source AD user’s Primary SMTP address to the value populated in ‘Custom Attribute 5’ and set the UPN to the properly branded value by appending the UPN suffix to the destination brand
  13. Set destination M365 mailbox’s Primary SMTP address to the value populated in ‘Custom Attribute 5’ and set the UPN to the properly branded value that matches the updated source AD user
  14. Set destination M365 mailbox’s ImmutableID to match the source AD user’s objectGUID
  15. Move source AD user into scope of destination Azure AD Connect synchronization
  16. Validate sync and hard match of source AD user to destination M365 mailbox

Once the above steps are completed, the source AD user account is now synchronized to the destination M365 mailbox and the source AD user can authenticate to the destination M365 mailbox using their source AD user credentials.

Post-Migration Configuration

United States | A Modern Migration Challenge

The remnants of the migration are:

  • A source cloud-only M365 mailbox which can now be unlicensed and deleted
  • A destination AD user account that is no longer being synchronized to M365

For diverse organizations where multiple business units are operating their own IT systems and solutions within their own organizational boundaries, and now have their local services integrated with cloud services, executing a consolidation program has become more complex. However, with careful planning, exceptional attention to detail, and a meticulous focus on execution the transition can be a success.

Supporting Links:

Feature ID: 67161: Exchange: Microsoft 365 cross-tenant SMTP domain sharing in private preview

https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=Exchange%3A%2CMicrosoft%2C365%2Ccross-tenant%2CSMTP%2Cdomain%2Csharing%2Cin%2Cprivate%2Cpreview%2C

Custom Attributes

https://docs.microsoft.com/en-us/exchange/recipients/mailbox-custom-attributes?view=exchserver-2019

Read more of my blogs here, and check out this one on tenant to tenant migration planning if you are about to embark on your journey.

THANK YOU FOR YOUR SUBMISSION!

United States | A Modern Migration Challenge

The form was submitted successfully.

Join the Insentra Community with the Insentragram Newsletter

Hungry for more?

If you’re waiting for a sign, this is it.

We’re a certified amazing place to work, with an incredible team and fascinating projects – and we’re ready for you to join us! Go through our simple application process. Once you’re done, we will be in touch shortly!

Who is Insentra?

Imagine a business which exists to help IT Partners & Vendors grow and thrive.

Insentra is a 100% channel business. This means we provide a range of Advisory, Professional and Managed IT services exclusively for and through our Partners.

Our #PartnerObsessed business model achieves powerful results for our Partners and their Clients with our crew’s deep expertise and specialised knowledge.

We love what we do and are driven by a relentless determination to deliver exceptional service excellence.

United States | A Modern Migration Challenge

Insentra ISO 27001:2013 Certification

SYDNEY, WEDNESDAY 20TH APRIL 2022 – We are proud to announce that Insentra has achieved the  ISO 27001 Certification.