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 🙂

Get this blog post sent to you as a PDF file to read later

Enter your email address and press Send Now

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 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 domain.

Here we add 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 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 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

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


    Post a Reply
    • Hi Ed,

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

      Hope this helps.

      Post a Reply
  4. Hi!

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

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

    What do you think?
    We thought that if we create the new 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) 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


  1. How to Sync an Existing Office365 Tenant into a New Active Directory Domain Using PowerShell | SlashAdmin Life in IT - […]… […]

Submit a Comment

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