This post was originally written by Robert Crane, Microsoft MVP
The most popular post on my blog is currently:
The currently recommended tool for syncing your on premises AD to Office 365 is now is not DIRSYNC but:
There is a further updated version that is currently in preview called:
and you can read more about that preview here:
I’ll do a blog post on that very soon, but for now let’s concentrate on what is generally available.
You can read more about Azure Active Directory Sync here:
Firstly, download the tool from the link above. In this case I am installing on clean AD and I’m also going to install the tool onto a domain controller, which is supported but not best practice. I am also using a new demo empty Office 365 E3 tenant.
After you have made sure your on premises AD is in good health, and before installing the sync tool on your network, you should login to your Office 365 tenant as a global administrator and navigate to the Admin portal.
You then need to select the Active Users option from beneath the Users menu item from the option on the left of the Office 365 Admin portal.
Note: that I have no users apart from the Global Administrator in my new Office 365 tenant initially.
At the top of the Active Users dashboard you will see an option called Active Directory synchronization as shown above. Select the Set up hyperlink to the right.
This will then present you with a number of steps. You should complete Steps 1 and 2, which I have already completed.
Then select the Activate button under option 3.
You’ll then be prompted to confirm you do want to proceed with synchronization. Note the warnings and select the Activate button to proceed.
You should now see that option 3 displays Active Directory synchronization is activated as shown above.
Return to your on premises sync server and double click on the package you downloaded. It will be extracted.
Double click the icon it places on the desktop to commence the configuration process.
You are prompted for the location to install the software. The default location is:
c:\program files\microsoft azure ad sync
You can however change this if desired.
When you have entered in the appropriate installation directory and checked the I agree to the license terms box, you can select the Install button in the lower right hand corner.
You will now see the program install the files to the installation directory as shown above.
You will then see Microsoft SQL Express being installed. Having SQL on a domain controller is generally not best practice but is supported now. However, beware that they sync tool will install and use SQL Express by default.
You will then see it installing the actual Sync Service on your machine.
Amongst a few other Azure services installed on your machine you’ll now find the Microsoft Azure AD Sync service as shown above.
You’ll then be prompted to enter you details for Azure AD as shown above.
Remember, Office 365 is built on Azure AD and uses it to manage identity. Thus, here you now enter your Office 365 global administrator credentials.
Best practice is to use a dedicated global administration account that has not been assigned any licenses. That is, create a new user and make then a global administrator but don’t assign them a license in your Office 365. Then only use this user to synchronise your local AD to Office 365.
Here, I am am just going to use the default tenant administrator to keep it simple but importantly, the user you enter here MUST have the Office 365 Global Administration role.
When you have completed the required details here press the Next button to proceed.
The provided login will then be authenticated.
If you have not as yet enabled directory synchronization in your Office 365 tenant, as detailed previously, you will see the above error message.
You will be prompted to enable this before you can proceed further.
You’ll then be prompted for a local forest (domain) and domain administrator as shown above.
If you look at your local Active Directory Users and Computers you will normally find the forest name at the top of the tree. In this case it is kumoalliance.org.
Note, that you need to have users assigned to routable domain locally as their primary UPN, not something like .local or .lan. if they are, then you will need to change this prior to synchronisation or otherwise users won’t end up correctly in Office 365.
Take a look at this article:
on how to perform update your users if you only have a .local domain.
Also note here that I have four users in my local domain also shown above.
When the correct local domain administration credentials have been entered select the Add Forest button.
If that is successful you should see you domain listed below teh entry fields now as shown above.
Select the Next button to proceed.
You should now see the connector from your local AD to Azure being created and configured as shown above.
You are now given the options to match local users to Azure AD users if they exist. This will basically match on premise AD objects to those already in Azure AD.
Because there are currently no users in my Office 365 tenant there are none that require matching so best practice is to leave the default options configured and select the Next button to continue but as you can see, you can match users between your local AD and the cloud via a variety of options.
You are now presented with the Optional features page. You can learn more about the options here at:
Where many get confused is the difference between Password write-back and Password synchronization. Password write-back is an Azure Active Directory Premium feature. For more information on how to configure this, see:
Office 365 currently doesn’t include Azure AD Premium so the only option available is Password synchronization which you should select. More information on password synchronization can be found here:
Remember, Azure AD sync allows the connection of more than just Office 365 to your local AD, that’s why there are more options here.
The new sync tool, Azure AD Connect, that is in preview, will support password writeback as the above blog post highlights towards the end of the post. As I said, I will also do a post on this soon.
So, in summary here, select Password synchronization and then the Next button to continue.
You can now review the information and when ready select the Configure button to continue.
The tool will now complete the configuration and enable the options you select. You see it connecting as shown above.
You will then see it enable the options you selected with any issues or errors highlighted.
When the process is complete you’ll have the option to Synchronize now, which you can uncheck if desired. Remember, this first sync may be quite large and take some time depending on how many objects are being copied to Office 365.
However, in most cases, you’ll leave this option checked and select the Finish button.
In a very short period of time you should see your users appear in the Office 365 console as shown above.
However, importantly, they will not have a license assigned to them so they won’t have things like a mailbox yet.
Why is that? Remember you can have many different types of licenses in Office 365 and you can allocate them to different users as you please. The sync client doesn’t know which licenses you want applied to which user so they need to be applied manually.
If all the users are going to get the same license simply select all the users in bulk as shown above, then select the Activate synced users hyperlink in the lower right hand side.
Then assign the location and license you want to apply to these users and select the Activate button at the bottom of the screen.
The process is now complete. Your local AD users are now synced to Office 365 using Azure Azure Sync Services. If they change their password on premises it is also synced using password hashing to Office 365.
Points to remember with Azure AD Sync (and DIRSYNC for that matter):
– By default, passwords changed in the cloud are overwritten when the next sync from on premises AD occurs.
– Information is copied from local AD to Office 365 not back. That is, the way it was installed above, it is a one way sync from on premises to Office 365.
– Changes are synchronized based on a three hours interval (this is the same interval that is also used by DirSync). There is a scheduled task running as the service account which will run the cycle. If you unselected “synchronize changes now” during installation then the task is installed as “disabled”. You can force synchronization using a PowerShell command if required as well as running the following file:
C:\Program Files\Microsoft Azure AD Sync\Bin\directorysyncclientcmd.exe
– The new Azure AD Connect tool is due soon with more features (blog post on that coming soon)
You’ll also find some tools installed on your sync machine to help manage and troubleshoot the sync process.
Like the Synchronization Service Manager show above that give you a low level insight into what the sync is actually doing. More on that again in an upcoming post.