Move a User from One Active Directory Domain to Another While Keeping the User's Office 365 Data Intact

As organizations merge and consolidate, when both entities are running Microsoft Office 365, the user's email, files, and content need to be joined together. There are plenty of 3rd party cloud tools that move mailboxes and OneDrive folders to another organization's environment (Tools from BitTitan, CloudFuze, Quest,ShareGate, etc). However there's a scenario where an organization has multiple Active Directories with a SINGLE Office 365 cloud environment, where a user needs to be moved from the old to the new Active Directory, and retain their existing Office 365 content.

We've seen this scenario pop up several times lately without any good documentation "how" to do it, so figured we'd consolidate a few of our notes and best practices.

Technical Bits - Changing the Sync of a User to a Different Active Directory Domain

Third party cloud tools aren't of any help in this scenario as you're not moving any email or file content. This scenario requires some old fashion scripting and configuration changes to move the user across Active Directories without impacting their day to day usage of Office 365 (Outlook, Teams, OneDrive, etc).

In this scenario, the Microsoft Office 365 account remains, but the "sync" process in the organization's Active Directory has to be switched from the old AD to the new AD domain.

There are options available dependent on the method you choose where you resync a user account (with similar Universal Principal Names (UPNs)) existing in one domain to another without losing original account resources (OneDrive, Outlook, Teams). The assumption here is that you already have a domain trust setup between the domains. If not then this method isn’t the route you would want to go with, the newly released Azure AD cloud sync might be a better option in a domain without a trust (https://learn.microsoft.com/en-us/azure/active-directory/hybrid/cloud-sync/what-is-cloud-sync).

One of the following starting points will be relevant in un-sync/re-sync a user account with similar UPN’s from one local AD to another or changing user from cloud only to on-premise local AD synced, and assuming the AD Connectors are setup in Azure AD Connect. This scenario is very specific in that the account that was originally synced up to Azure AD has no correlation to the local AD account. If the user is already cloud only skip “*On-premises to Cloud Only*” section.

*On-Premises to Cloud Only*

1. Set Domain A users attribute adminDescription to User_NoSync. This will stop the user from syncing to AAD
2. Run delta sync from AD Connect.
3. Restore to cloud only.
4. Then follow steps 1-8 for "*Convert from Cloud Only to different local AD*" below.

*Convert from Cloud Only to different On-premises local AD*

1. Choose one of the following to export the proxyaddress:

Export Domain A user attribute proxyaddress using PowerShell command. This would be in a case where the user was synced from On-premises then converted to cloud only then back to destination On-premises.

-OR-

If user is cloud only copy from here…. Find Azure AD user by going to AAD... searching users then selecting the user…. then clicking on properties tab, then look for proxy address. Similarly, this should be available via PowerShell.

1a. Use PowerShell command "$Null" to Domain B users proxyaddress attribute, this should clear any pre-existing proxyaddress attributes. Then, import proxy addresses from Domain A user such as…. X500, SMTP, smtp (which is lowercase because it’s an alias).?

Note: If SMTP (Upper case because it’s the primary smtp) does not exist, you will need to include an add entry. You might notice Domain A user might not have a “SMTP” entry when exporting its proxyaddress attribute (this was the case with test user account but might not be the case for you in your live user environment). After importing proxyaddresses to Domain B user, do a quality check on the SMTP (primary email address).

2. Set user attribute "Admindesciption" to "User_NoSync" Domain B user. This will stop the user from syncing to AAD. Depending on your situation this step might not be necessary, for example if there was no active AD connect sync happening.

3. User in Domain B will need to be checked to ensure it doesnt have ms-ds-consistiencyGUID attribute value. If so clear it.?

4. Then, clear immutableID for AAD user (At this point there should be an Azure AD cloud only account).

5. Allow one sync cycle… Azure AD connect. Run delta command for Azure AD connect.??

6. Thereafter clear User_NoSync attribute from adminDescription on Domain B user.

7. Either delta sync or allow for AD Connect to sync (depending on setup times can vary)

8. Check the account in Azure Active Directory as it should now show a sync status of on-premises. Attempt to login to office.com, then access Outlook, Teams, OneDrive, etc.?

Note: The password that was set from Domain A user which was synced to AAD would be the password to use upon process completion. Users should be informed to reset their password upon first login post sync.

Helpful tips:

Clear immutableID command:

set-msoluser -userprincipalname "username" -immutableID "$null"

Input your desired username in place of “username”

To get proxy address for a user:

Get-ADUser “john.doe” -Properties ProxyAddresses | select Name, ProxyAddresses

Remove “john.doe” with the Samaccountname

More details at: https://blog.technotesdesk.com/2021/09/21/add-smtp-proxyaddress-to-users-in-ad-with-powershell/

Test Before Fully Diving In!

The key is to test this process on TEST accounts one by one to make sure you clearly understand the process where the user's logon/password, mail connection, access to Teams/SharePoint/OneDrive/etc are retained, and you have predictable results on what will occur during the switchover. Once you feel you have the process figured out, then you can pilot test it on a handful of real accounts, and then shift to more or all of the accounts you want to transition over.

(note: The content of this article was distilled and documented by Convergent Computing (CCO)'s migration subject matter expert - Abdullah Rashidi)