Migrating Azure AD connect to new Active directory domain

Migrate Azure AD connect

When you want to migrate Azure AD Connect to another domain, so things can become pretty complicated. These kind of migrations can also create a lot of issues and unknown errors. The best thing to do before you start such a migration is to prepare this scenario in a testlab.

Disable Azure AD connect

First you need to logon to the Azure AD connect server which you want to migrate. Then perform the 4 steps below.

Install the Azure Active Directory Module for Windows PowerShell. So For more info, go to the following Microsoft website:

Connect to Azure AD by using Windows PowerShell. For more info about how to do this, go to the following Microsoft website:

Disable directory synchronization.  So to do this, type the following cmdlet, and then press Enter:

Set-MsolDirSyncEnabled –EnableDirSync $false

Check that directory synchronization was fully disabled by using the Windows PowerShell. To do this, run the following cmdlet periodically:


*note This will take up to 72 hours. This change will not cause any service interruption, all users will be able to use their services as normal.

Install the new Azure AD connect

When you have prepared or executed the steps above you can install the Azure AD connect tool on the new server.

The second step is to populate your new AD domain with all user accounts. So it is now important that you copy all information from the old domain, (companyname, jobtitles etc), and for Exchange Online it is especially important that these attributes are copied:

  • userPrincipalName
  • proxyAddresses
  • legacyExchangeDN

When Hybrid you need the above and attributes below

  • msExchRecipientTypeDetails
  • msExchMasterAccountSid
  • msExchRecipientDisplayType
  • msExchRemoteRecipientType

What does the attributes do

  • The UserPrincipalName (UPN) of the users is the login name to Office 365.
  • ProxyAddresses are all your email addresses, both primary and alias.
  • The legacyExchangeDN, is used if you previously have migrated from an Exchange on-premises to Office 365. It is used for internal addressing in Exchange. If it is removed you will not be able to reply to old emails, meeting invitations, and your Suggested Contacts will also fail.
  • msExchRecipientTypeDetails sets the type of mailbox: usermailbox(1), linkedmailbox(2), Sharedmailox(4), legacymailbox(8), room mailbox(16), equipmentmailbox(13)
  • msExchMasterAccountSid This attribute of the target user object holds the objectSID of the source user account. This allows to connect to the own mailbox and shared mailbox.
  • msExchRecipientDisplayType sets the type of account that is used (List of references)
  • msExchRemoteRecipientType

Match Immutable ID

The third step is to make sure the immutable id in Office 365 which uses the ObjectGUID attribute  is translated to an ImmutableID in Azure Active Directory. If you rename your users, the ObjectGUID is untouched. And most of the time you use the ObjectGUID by default as immutableID.

*note if you have used something else please make sure this part is covert.

Currently we are moving to a new Domain so in this case the ObjectGUID will be changed. To manage this we have to clean the attribute in Office365. Office 365 generates these IDs for us,  you can use the Command below.

Set-msolUser -UserprincipalName “jerry.meyer@domain.com” -immutableID “$null”

Enable AzureAD sync and reinstall Azure AD connect

The next step is to enable Azure AD connect in the Office 365 tenant.

Set-MsolDirSyncEnabled –EnableDirSync $true

Check if it is enabled:


After these steps you reinstall the Azure AD Connect Sync tool on a server in the new domain. I strongly recommend using a new server for this step. Always use a new server for this purpose else it can create bad errors or even break the sync. When this happens you need to create a ticket at Microsoft.

When the installation and full sync is done. The Sync tool will match the users in Office 365 and AD onprem by the primary email address. When there is a match  a new ImmutableID is created and written to Azure AD.

9 thoughts on “Migrating Azure AD connect to new Active directory domain

  1. Great article…thanks for sharing! My only question is: How would you go about populating AD with the Exchange attributes you mentioned? I have used some Technet PowerShell scripts in the past, but is there a specific method you would use? ProxyAddresses for example are a multivalued attribute, so I am struggling to easily export and import. I wish someone made a nice GUI tool to accomplish this. ADMT excludes all Exchange attributes (for good reason). Thanks again!

    1. I would go with powershell or a powertool like quest migration. You can use a PS script something like this. the best way to go is to export it to a CSV and import it with CSV.

      Import-Module ActiveDirectory

      $newmail = “@tenant.mail.onmicrosoft.com”
      $users = Get-ADUser -Server dc-local -Filter ‘Name -like “*”‘ -SearchBase $Userou -Properties msExchRecipientDisplayType, msExchRecipientTypeDetails, msExchRemoteRecipientType

      #Use the part below to set the new attributes

      Foreach ($User in $users) {
      Set-ADUser -identity $User.sAmaccountname -Replace @{msExchRecipientDisplaytype = “-2147483642”}
      Set-ADUser -identity $User.sAmaccountname -Replace @{msExchRecipientTypeDetails = “2147483648”}
      Set-ADUser -identity $User.sAmaccountname -Replace @{msExchRemoteRecipientType = “4”}
      Set-ADUser -identity $User.sAmaccountname –Replace @{targetAddress = “SMTP:”+$user.SamAccountName+$newmail}

      *Do not just fire this script it will not be sufficient enough.

      Another thing you can do is sync the “old Active Directory” and the “new active directory” with Azure AD connect. when there is only one mailbox you can use the ms-Exch-Master-Account-Sid Attribute to merge the two account in Azure AD so the mailbox is linked to the right user account.

      1. Wow, thanks for the quick and detailed reply. Since we need to go from “old” to “new” in this case, I will experiment with using Azure AD Connect to facilitate the attribute migration/merge. I had not thought of that tool as an option. I’ll do some testing in a lab with all of this first.

        1. Yes good one, always test in a lab first. These kind of migration can sometimes be tricky.

          1. An Update. We were able to utilize ADMT in conjunction with this Microsoft KB (937537) to selectively sync the needed attributes. It is possible to remove attributes from the default ADMT exclusion list so everything comes over in one shot. Nice!

            Next step…complete the AAD Connect switch over to the new domain and match the Immutable ID.

  2. Hi

    How do you go about managing the mail enabled objects going forward especially if you had a hybrid setup on the old active directory?

    I am sure you can’t just install exchange on the next AD.

    1. Hi Mike,
      There are two options you can just use the old AD as a resource domain. This means that you add your new and your old domain in Azure AD. you can do this in the wizard.
      You need to make sure both domains are trusted with each other and the masteraccountsid’s are the same on both account assuming you copied them over with ADMT.
      The second option is export all necessary objects with guids etc with powershell and import them in you new AD
      To be honest i would go with the first option when you go for the long term hybrid scenario you can just migrate the server which is running the hybrid over to the new domain when everybody is migrated.

      I hope this is what you where looking for if not please let me know.

  3. Hi, I am working on a similar project where are going to migrate our existing root and child domain to a new single domain. So I would be building new AD forest and may use quest migration manager to sync the AD objects from source AD to target AD. But we also required a new hybrid Exchange 2019 in the target AD. So when we populate Exchange attributes for Hybrid Exchange 2019, would it automatically update the AD accounts in Exchange ECP to Mail enabled or Remote or Office 365 mailboxes?

    Also someone has mentioned to me that we do not have to run null the immutableID as new version of AADC automatically MAP the account when its re-enabled for synching from new AD forest.

    could you please advise?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.