How to Sync an Existing Office365 Tenant into a New Active Directory Domain

Normally you would have a network setup in a domain and you need to migrate into Office365. Usually away from small business server or another type of email system but what do you need to do if there is no existing domain? What if you work in a workgroup and users use Office365 but now you need to setup a domain infrastructure and synchronise that local domain with Office365, what do we need to do?

Well no worries let’s see how you do it!

You can either watch the video here or scroll down to read the blog post 🙂

[email-download download_id=”16311″ contact_form_id=”9351″]

Part 1 – Add UPN Suffixes into Active Directory

Log in to the portal as a global administrator and navigate to settings then domains. Make a list of all of the custom domains you are using not including the default onmicrosoft.com. These will be added as UPN suffixes into active directory so that users can have the same username in the local AD as they do in Office 365

Log into a domain controller and open Active Directory Domains and Trusts. Right click on the root and click on properties. This will allow you to add the UPN suffixes. Add all of the custom domains you have listed in the domains section in Office 365 with exception of the onmicrosoft.com domain.

Here we add office365lab.co.uk and press OK.

Part 2 – Check all user accounts and groups have a logon domain

Check each user account has one of your custom domains included in the user name and not the onmicrosoft.com domain.

If any user accounts have a username which is not a custom domain then go into the account and update the username and save the changes. Its ok to have a cloud admin account with is cloud only and has the onmicrosoft.com. If you want to sync everything else into your active directory then ensure all accounts have a logon domain which matches one of your custom domains.

As well as all user accounts do the same to each group in the Office 365 tenant.

Part 3 – Create object in active directory

Now its time to go down your list of user accounts in the portal and recreate them in your local active directory. Pay special attention to the user names and primary email address and aliases.

On one of your domain controllers open up active directory users and computers and start creating new user objects.

Enter the details exactly as you see them in the Office365 portal and ensure you set the user logon name suffix so that it matches the office 365 logon name in the portal.

Set a password and press Next, its not too important what the password is here because it will need resetting after the initial sync before the user can logon.

Now ensure the primary address of the user in the portal is entered on the general tab in the e-mail field.

Next go to the Attribute editor and find the proxyAddresses attribute. Here is where you enter all of the email addresses assigned to the account so add any email alises which are listed on the account in the portal.

The primary email address must be prefixed with SMTP: in capitals and all other aliases should be added in lowercase smtp: This is important so pay attention when adding all of the addresses.

The primary address (aka the send as address) has SMTP: prefixed on it and all others have a lowercase smtp:

Part 4 – Install Azure Active Directory Connect (AAD Connect)

Download the latest version of the AAD Connect tool onto one of your domain controllers or a member server which will host the sync software.


Run the installer, agree to the terms and select Continue.

We are going to go for an express setup here but if you want to explore the advanced options go for it. Select Express if you want it to work using this guide.

Enter the logon credentials of a global administrator in the Office365 tenant. Just remember that if you update the password to this account you will need to rerun the AAD Connect configuration wizard to update the password.

Enter the a domain administrator account and the same applies as above, if you update the password then simply rerun the wizard.

The wizard will verify that your custom domains have been added as UPN suffixes. If you followed part 1 of this guide your good to go.

Press install and let the configuration complete which will take a few minutes.

Once AAD Connect has been installed it will kick off a sync. Leave the system for about 20 minutes to allow this initial sync to complete in the background.

You can test the sync is working correctly by adding a new email alias into one of your active directory user accounts and see if those changes sync into the office 365 portal. We can see all of the additional aliases we added earlier in this guide have synced into the 365 portal so we have success!

Every change you make from now on will sync with Office 365 every 30 minutes by default. You wont see the changes straight away so be patient or open Powershell on the domain controller and type the following command to force a sync

Start-ADSyncSyncCycle -PolicyType delta


Setting up a new AD when a client is already using Office365 involves a lot of manual work. Never fear because Power Shell can do all of this for us within a minute! sign up for the newsletter at the top of the page to be informed when I post that script.

Author: Ian@SlashAdmin

Share This Post On
468 ad


  1. Hi, i follow all the step for 28 users, but 3 of them, the sync create like a duplicate user with conflit smtp information, the user in my on-premise AD where copy paste from the office 365, but those 3 that had some other user smtp alias doesn’t work.
    Can i delete the extra alias from the on-premise ad user smtp?
    or what can i do to fix everything?


    Post a Reply
  2. Hi Ian,
    thank you very much for this very detailed and useful post.
    Small question: if I edit or add some data on the Office 365 portal and run Start-ADSyncSyncCycle Powershell command on the Local AD server, does it mean that Local AD will sync the changes from the O365? Or O365 will be overwritten by current data from the Local AD?

    Post a Reply
    • Any changes in 365 won’t replicate to the local AD. Likely the script will fail on existing objects. Any new objects in 365 should get created. Best thing to do is run once then setup AD Connect to get a perminant sync from local to 365. Hope that helps 🙂

      Post a Reply
  3. Hi,

    I was wondering if I create a local AD domain with the UPN as in the on prem domain will not be office365lab.local but office365lab.co.uk.

    Will this make any difference or do you recommend having it as .local and add .co.uk?


    Post a Reply
    • Hi Ed,

      It’s recommended to have .local and add the .co.uk UPN. This avoids confusion with the internal domain space and the public one.

      Hope this helps.

      Post a Reply
      • We keep the full domain but we proceed our internal domains with ad for active directory, such as ad.contoso.com.

        Post a Reply
  4. Hi!

    We have an internal domain (company.net for that example) that we are using for desktop authentication. And we own a company.com that we use for emails. Now we bought Office365 licenses and registered company.com. A lot of users have Office365 accounts in company.com domain. In their desktops use Office365 account to login in Outlook, Onedrive…

    Now we need to separate the company.net domain and move all Office365 users to a new Active Directory. So we are thinking to name our new on-premises domain like company.com. Then create a forest trust between company.net and company.com on premises forests. Move users from a domain to another (to maintain user profiles) and finally sync company.com AD with Office365.

    What do you think?
    We thought that if we create the new company.com AD, sync with Office365 to create all these users in our on premise AD, then to migrate users from a forest to another it’s not possible because users are already created.


    Post a Reply
  5. Will this sync from o365 to local AD?

    Post a Reply
    • Hi Pete,

      Yes that is what it was written for.

      Post a Reply
  6. Hi,

    Thanks for this useful post !!
    A question about the password.
    When i’ll launch the sync, do users need to reset their password or do we have a solution to keep the password actually used into Office365?

    Post a Reply
  7. Hello!

    The existing mailboxes will not overwrite to an empty one, right?

    Post a Reply
    • No they wont there will effectively be no change in 365 until you configure AAD Connect to sync the local AD back to 365. Even then the mailboxes and users will all be synced and the data stays in tact.

      If you are running a local exchange and you are trying to sync 365 users back to an existing AD running exchange then the script could cause some conflicting user accounts. But without knowing your exact setup I cant say 100%.

      Post a Reply
  8. Thank you very much for your guide. One question please:

    In part 3: Enter the details exactly as you see them in the Office365 portal and ensure you set the user logon name suffix so that it matches the office 365 logon name in the portal.

    In our case the Office365 logon name is (in example) workforce.gr. Our internal domain logon name is workdom.local. The users are setup already in both Office365 and internal domain and we cannot change them. Is it going to be a problem and how do you think we could get over it?

    Thank you in advance.

    Kind Regards,

    Harry Arsenidis

    Post a Reply
    • The UPN’s will need to match but there should be no issue changing your internal logon names. I would test with one user and see if any logon issues occur.

      Post a Reply
  9. What if Office 365 already is AAD syncing with an AD and they want to build a new AD which the same Office 365 should sync with instead – same users, same mailboxes ?

    Post a Reply
  10. Hi,

    I have AWS EC2 instance configured as domain controller.
    I create users on it and users get sync to Office 365 portal (using Azure AD connect).
    Now I am planning to setup on premises DC with active directory configuration.
    I need all users which are already there in office365 portal in on premises AD.
    How the sync need to be configured?

    Post a Reply
    • A couple of options for you. Create a site to site vpn and bring up a second DC. Uninstall AD Connect on the AWS instance and configure on the on prem DC. Then finally decommission your AWS DC.

      Second option is to uninstall ADConnect and turn off sync using Powershell command: Set-MsolDirSyncEnabled $false

      Wait then use this script to sync 365 back to AD and setup AD Connect again. https://www.slashadmin.co.uk/how-to-sync-an-existing-office365-tenant-into-a-new-active-directory-domain-using-powershell/

      A third option to look at is to break AD sync then install AD Connect on your new on prem DC and try using AD Connect write back features. Not sure if it writes back user accounts yet but worth testing out.

      A few options for you 🙂

      Post a Reply
  11. Hi, what if you have a large organization (like a university in my case) that uses thousands of Office 365 accounts that are administered from Office 365 account. Office 365 is the leading user directory. What will be the best option to get a local AD that automatically imports and syncs user information from Office 365 without any manual user creation, etc. We need a local system to authenticate the users with their Office 365 user and pass and we can integrate that system to a local AD, but that AD should receive all user information from Office 365. We don’t intend to make any changes locally and sync back to Office 365.

    Post a Reply
  12. Hey Ian, Thank you so much for this article however I am facing a strange issue. I tested with manually creating the ID’s and it worked as expected. As I have more number of users so I tried your powershell script and it created mostly all users in on-prem AD.

    Now when I am trying to sync then it rather creates a new user in AAD than syncing the existing one.

    I have deleted all users those were imported through power shell and trying to manually create them but still same issue and every time it creates new user in AAD

    Any help would be greatly appreciated.

    Post a Reply
    • It could have been that the upn was not set to the domain used in 365 as the default in the local ad but difficult to know for sure. Check all the attributes match up correctly.

      Post a Reply
      • Question: Is this the same procedure if my existing tenant was already been syncing with my Old local Domain? I have built a new Active Directory infrastructure with a new local domain name. Can I follow the same procedure for Ofice 365
        to switch ADsync from the old AD to the new One?

        Post a Reply
        • Yes run the script and it will create all the accounts. If you are not using the new domain yet you even get a good chance to test it all properly. When you are ready to switch just stop the sync to the old domain and setup adconnect in the new one.

          Post a Reply
  13. If I have 100 Office 365 account and I bought a new local AD server, for which I payed 5 CAL licenses, what will happen after I synchronize 60 online users with local AD server?
    1) Do these 60 synced users all must have CAL licenses on a local server?
    2) For those 40 users which are not synced on local AD, are they losing ability to log into their accounts on Office 365?

    Post a Reply
  14. Hi, we have around 50 users in Azure AD and want to migrate them all to Local AD we do not want to have a downtime for these users. So when I do these steps the password for Local AD users would be same as their Azure AD account right? I mean the AD connect tool will sync the Azure AD passwords to Local AD right? that’s is why you told it is not important for the password in your section above as it will get rewritten by AD connect in Local AD?

    Post a Reply
  15. Hi, the article is misleading. You are not synching O365 accounts _into_ a local AD. You are manually creating local accounts which then you sync back to O365.

    The only accurate thing in the article is that certain properties (that you manually populate) must match their cloud equivalent.

    Post a Reply
    • You must have missed the script part.

      Post a Reply
  16. Hi, I know it’s an old thread but we have an existing tenatn and new AD. I’ve got some script to properly hard match newly created AD users to their aad counterpart. Problem is that resetting the passwords of the AAD users is not really an option. Is there any way to make AD Sync keep AAD password and overwrite the AD password (powershell command, or set some property in O365 so dir sync *thinks* the password in AAD is changed and syncs it back to AD? I have writeback enabled.

    Post a Reply
    • That’s a tricky one. If you know all the users passwords you can set them in AD and even script it but likely you have lots of user accounts and dont know the passwords.

      I think your only option is to force a password reset and let it write back or issue new passwords and set the new one’s in AD and let AD Connect sync to the cloud.

      No much help I know but I think your options are limited and a password reset will be needed.

      Post a Reply
  17. thank you very much for your explanation this is exactly what I need for my company, however I tried in LAB the solution (with my domain onmicrosoft.com) and I have a problem with password replication: if I change the passwords in AD password does not change in Azure Ad on my existing users O365 but for a new user created on AD and newly synchronize on Azure AD O365 the passwords are replicated and change if it is changed on AD. also do you know if the logo should change on Azure Ad for the user and switch from the Cloud logo to On-Premise?

    Post a Reply
  18. Hi, do I need to buy a azure ad licence or can I just take the free verison to sync?

    Post a Reply
    • Free version is fine yes.

      You might want to look at the sync tool’s write back options as I believe it can write back users accounts now which saves you having to manually create them. Perhaps someone can verify that.

      It’s on my list to try the latest version.

      Post a Reply
  19. Hi,

    I tested this with one account and I get this Duplicate Attribute Error coming from Azure portal after the sync completed.

    Unable to update this object because the ProxyAddresses value SMTP:*******.com associated with this object may already be associated with another object in your local directory services. To resolve this conflict, first determine which object should be using the conflicting value. Then, update or remove the conflicting value from the other object(s).

    Post a Reply


  1. How to Sync an Existing Office365 Tenant into a New Active Directory Domain Using PowerShell | SlashAdmin Life in IT - […] http://www.slashadmin.co.uk/how-to-sync-an-existing-office365-tenant-into-a-new-active-directory-dom… […]

Submit a Comment

Your email address will not be published.