Office 365: Migrating DirSync to new AD domain

Disclaimer
This blog post was written for older versions of Office 365 and Azure AD, and has not been tested in the latest version. Always make sure that you have a valid backup before making any changes to your system.

In a migration scenario you might need to replace the Active Directory domain used to sync your users to Office 365. I will go through the steps you need to change AD domain.

In this scenario I assume that ADFS is not used. If it is, you first have to disable federation. I suggest looking at my previous post where I described how to switch from ADFS to Password Sync.

The steps we have to go through are:

  1. Disable DirSync in old domain
  2. Populate new AD domain with users and attributes
  3. Prepare Office 365 users for new domain
  4. Install DirSync in the new domain.
  5. Verify Sync

First, disabling DirSync is very easy. Just go to the Office 365 admin center and click the Deativate link under users and groups.

dirsync-change-domain-1This will take up to 72 hours. When this process is over all user accounts are managed in the Office 365 portal, and there is no connection to your old domain. This change will not cause any service interruption, all users will be able to use their services as normal.

In the meantime you can uninstall the Azure Active Directory Sync tool on the old DirSync server.

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

  • userPrincipalName
  • proxyAddresses
  • legacyExchangeDN

UserPrincipalName is your login name to Office 365. I don’t think I have to explain why this attribute is important 🙂 . ProxyAddresses are all your email addresses, both primary and alias. The last attribute, 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.

I will not go through here how to migrate these attributes here, check out our post on how to sync attributes from cloud identities to active directory.

The third step is where the magic happens. Office 365 uses the ObjectGUID attribute to keep track of the user accounts in in your on-premises Active Directory. It is translated to an ImmutableID in Azure Active Directory. If you rename your users, the ObjectGUID is untouched. Hence the name ImmutableID.

dirsync-change-domain-2The problem is that when you move to a new domain, all ObjectGUIDs are changed, and we need to generate a new ImmutableID.

Office 365 generates these IDs for us, we just have to clear the attribute on all users in Office 365. This is easily done with PowerShell:

Set-MsolUser -UserPrincipalName "aaron.beverly@365lab.net" -ImmutableId "$null"

The next step is to activate DirSync in the Office 365 portal again, and then reinstall the Azure Active Directory Sync tool on a server in the new domain. I strongly recommend using a new server for this step. Re-using the old server (after joining it to the new domain) might break your sync.

After the installation a full sync is done. The Sync tool will identify and match the users in Office 365 and Active Directory by the primary email address. If a match is found a new ImmutableID is created and written to Azure Active Directory.

Finally, after the initial sync is done we can look in Synchronization Service Manager to check that all users were matched and that we don’t have any sync errors.

/ Andreas

26 thoughts on “Office 365: Migrating DirSync to new AD domain”

  1. Simon Kwok

    This is a good article to describe the situation of migrating DirSync to a new AD domain. What about the steps for handling the groups and contacts in new AD domain where these objects are being synchronized by old DirSync to WAAD? Thanks.

    1. Andreas Lindahl Post author

      This question is actually a bit trickier than it might look. To my knowledge, there is no such thing as an ImmutableId on these object types. That leaves us with two options:

      1. Keep the contacts and groups in Office 365 (no sync)
      2. Delete them from Office 365 and then sync them from Active Directory.

      The second option will work from an Exchange Online perspective, as long as we export the legacyExchangeDN attribute before deleting them. We can then add it as an X500 value in our Active Directory and sync it back to Office 365. I just want to give you a warning regarding this method: If you are using the groups for access rights in Sharepoint Online your permissions will break!

  2. Pingback: Office 365: Migrate from Cloud identities to Dirsync | Tailspintoys – 365lab.net

  3. Mike

    Andreas,
    Thanks for the interesting article.
    One question – will this process actually re-link all of the users resources (SharePoint doc’s, OneDrive folders, MySite, Lync contacts, etc.) in O365 with the new ObjectGUID?

    Thanks.

    1. Andreas Lindahl Post author

      Since the Azure Active Directory account still is the same (it is just connected to a new on-prem identity) all services will still work. It is allthough very important that the attributes in both the old and new on-prem AD are the same, otherwise your services might break.

      The AAD account has it’s own ObjectId that is untouched when changing the ImmutableId.

  4. Jon

    I’m getting ready to convert our ADDS from domain.local to ad.domain.org by establishing mutual trusts between the forests and migrating users. My initial thought is that the GUID and all attributes will remain the same for all users and groups that are synced, so I should not need to manipulate the ImmutableID or run into any problems with the groups. What are your thoughts on this?

    1. Andreas Lindahl Post author

      When migrating accounts between Forests the SID and ObjectGuid is changed, which means that you also have to update the ImmutableID.
      Also make sure that all required attributes are included when you migrate the user accounts. The proxyAddressses attribute for example is not migrated by default in ADMT.

  5. Philip

    If say I wanted to use this process and before disabling DIrsync I use a 3rd party tool to migrate email from Office 365 to a new email domain in a new AD, could I then use your process to re-attach a new dirsync in the new domain to link with the Office 365 accounts. Basically re-connect accounts but email now on local premises in a new AD domain with its on premises Exchange? Then delete email mailboxes for the accounts in Office 365.

    1. Andreas Lindahl Post author

      That’s hard to say without the full scenario, but from your question I would choose another approach: If the goal is to move all mailboxes back on-prem (and keep using other Office 365 services like SharePoint Online and Skype for Business Online), but synced to another forest than the one originally synced to Office 365, I would:

      1. Use ADMT to migrate the user accounts from the forest to the new domain. Include the attributes as described in this blog post.
      2. Establish a sync with Azure AD in the new domain, and adjust the ImmutableID to match the new objectGUID
      3. Install the new Exchange server in the new domain, and establish a hybrid with Office 365.
      4. In your on-prem Exchange server, run Enable-RemoteMailbox for all mailboxes.
      5. Migrate the mailboxes back to your on-prem server (standard Office 365 offboarding process)
  6. Morgan

    Thanks for the article, its helpful. Today I have a forest domain of ad.xyz.com and use a UPN of xyz.com for O365. I want to change my forest name to ad.ABC.com however leave my UPN to xyz.com (and later I’ll change the UPN). Am I able to change the FQDN without impacting the O365 sync since it the proxyaddress and UPN should stay the same?

    1. Andreas Lindahl Post author

      No, this scenario is not supported. If you plan to do major restructuring in Active Directory I recommend that you first disable the sync, and then do a new installation on a new server in the new domain. Do not rename the existing server.

  7. Morgan

    Thanks for the quick reply. So new Azure AD Sync and the accounts between that box and the O365 tenant should match via UPN/proxyAdress (run the ID Fix tool again I’d assume)? We were not on exchange before so we have no LegacyExchangeDN set.

    1. Andreas Lindahl Post author

      Correct. Change both UPN and primary email address/sip address at the same time for each user.

  8. Erik N

    Is it possible to migrate just a batch of about 10 users? Or do you have to migrate all the users at once?

    1. Andreas Lindahl Post author

      Step 1-4 is done for all users at once, but the last step can be done in batches.

  9. Back Alley Labs

    I have a scenario where we have migrated users from an on-premises Exchange server to Office 365 using a cut-over migration,. Dir-Sync was not installed or used for the this original migration to O365. We now need to build a completely new AD with a different domain name and want to install DirSync on this new domain to manage the already migrated mailboxes in the cloud. Will we need to do anything special for this?

    1. Andreas Lindahl Post author

      The process is still the same. Be careful when populating mail, UPN and proxyAddresses in the new Active Directory so everything match the values in Office 365 before enabling the sync in the new domain.

      Since you have not synced before there is no need to set the ImmutableID, it will match automatically. The only difference is that you will use AADConnect instead of DirSync (this blog post is almost two years old, DirSync should no loger be used)

  10. Luke Brewerton

    Will this affect mailboxes?

    We are looking to move to a new AD (Domain, users etc will be named the same but will be fresh and clean after a tech decided it was a “playground” and things are very messy) but this is our live O365 tenant so the mailboxes are in use and old emails will be required so is it just a case of assigning new AD objects named the same and with the same attributes as mentioned above?

    1. Andreas Lindahl Post author

      The process is the same as described above. The mailbox data will be untouched. However you might run into issues regarding groups, please check the other comments and replies about that.

  11. TX_IT_Guy24

    My company is about to convert to the Azure AD Connect tool and I had a question on what to expect from the distribution groups. I read the previous comment talking about importing the legacayExchangeDN but I checked a few groups in our current domain but they did not have anything set as that attribute. Any information you could provide would be much appreciated.

    1. Andreas Lindahl Post author

      There are cases when there is no legacyExchangeDN in your local directory, for example if you have set up Active Directory synchronization without an on-prem Exchange server. In that case you can safely skip that attribute.

  12. Safeer Khan (@safnha)

    Hi Andreas, Its a great post. any suggestions for below situation.
    * We have a AD connect running on a forest A with 8 domains syncing to tenant
    * A new forest B needs to be setup and synced to same tenant.
    * Slowly the users from forest A will be moved to Forest B. And they need to have same domain suffix to select for UPN. Though actual forest name is different than forest A.

    Should we just add forest with existing AD connect and sync will it work when we move users along with all attributes? I am confused on both UPN suffix and ad connect sync part. Please help…

    1. Andreas Lindahl Post author

      You have to sync forest B using the same AD Connect server as for syncing forest A. Myltiple sync servers is not supported.

  13. ali

    hi Andreas, we want to transfer tenant from Canada to US and looks like this is not an option , hence we have AAD connect, ADFS , Hybrid Exchange setup, how can we move the domain to a new tenant ?

Comments are closed.