Updated on 28 August 2015
IMPORTANT: AAD Connect has replaced AADSync and DirSync. Reference: Azure Active Directory Sync
NOTE: On 16 April 2015, the latest version of AADSync was released, and is available here to download here.
NOTE: As of 27 October 2014, password synchronization is available with AADSync version 1.0.0470.1023 (refer to AAD Sync Version Release History).
If you are thinking about deploying Office 365 for another company under the same Office 365 account due to a merger or investment or whatever the case may be, and don’t want to rush into merging forests and domains and Exchange orgs–Oh my!, Azure Active Directory Synchronization Services (AADSync) can provide a relatively rudimentary solution to what used to be a fairly complicated and involved process in which Microsoft Services needed to be summoned.
In the past, Microsoft’s involvement was needed due to the complexity of implementing Forefront Identity Manager (FIM) 2010 to “merge” two Exchange organizations through forest trusts into a single Office 365 account.
AADSync is built to remove the complexity of implementing FIM and the need for Microsoft Services. With AADSync, the tool describes three common deployment scenarios.
In my post on installing AADSync, I went through the basic process of installing and configuring the tool in a single forest domain. Check it out before proceeding, if you haven’t already. The neatest thing about AADSync compared to DirSync is the fact that we can now merge multiple forests and Exchange organizations into one Office 365 tenant. Before AADSync, implementing DirSync nearly took an act of God to configure with multiple Exchange orgs to one Office 365 account. But with AADSync, it took me less than 30 minutes to deploy.
NOTE: This and my previous AADSync posts are based on very basic (almost default) implementations of the tool.
The focus of this post will be on the Separate Technologies deployment scenario. Though the technologies in my labs are the same (Windows-based), we will use this scenario as it is the simplest to set up.
My lab deployment will not contain any forest trusts. The steps in this post are not recommended for a single sign-on (SSO) deployment with Active Directory Federation Services (ADFS). To implement SSO for multiple organizations via ADFS, two-way forest trusts must be in place and (in my opinion) only one forest should host the AADSync server.
In my lab, I have second simple environment (similar the environment described in my post on installing AADSync).
- Office 365 E3 Trial Subscription (same account same with previous post)
- AADAdmin (O365 global admin)
- Domains Added: domain1.com* and domain2.com* (*not my real domain names)
- Windows 2008 R2 Domain
- One Windows 2008 R2 domain controller
- No forest trusts
- Single forest, single domain
- Internal domain name of domain2.local
- Routable UPN suffix (e.g. domain2.com)
- AADSyncAdmin (domain user)
- AADSync Server
- Windows 2008 R2 Standard with SP1 server (virtual machine)
- Domain-joined server
- 2048 MB of memory
- 30 GB of disk space
For my Office 365 account, I already have one forest (e.g. domain1.local) connected with on premise AD users and groups being synced. Office 365 also hosts a public domain name (e.g. domain1.com).
To prepare Office 365 to host the on premise AD users and groups for the additional forest (e.g. domain2.local), I added my other public domain name (e.g. domain2.com) to the O365 tenant. In addition, I made sure that the names of the users and groups from both forest would not cause name conflicts by configuring and assigning UPNs for each user, and designed both AD environments with the thought of AADSync OU-based filtering in mind (as configured in this post).
Once I had this baseline established, I was ready to proceed with installing AADSync in my second forest using the same steps as before. However, instead of allowing AADSync to synchronize immediately, I chose to uncheck the Synchronize Now option so I could first configure filtering with AADSync. By deselecting the sync now option, the Azure AD Sync Scheduler scheduled task is disabled until we enable it.
Before I could configure filtering, I restarted the AADSync server.
NOTE: If you do not at least log off and then log back in to the AADSync server, the Synchronization Service Manager will not start due to local group membership that was assigned during the installation. Also, the Microsoft Azure AD Sync service will not start unless we restart the AADSync server (recommended) or manually start the service.
Again, I designed the OU structure of the second forest in such a way to allow synchronizing of only the users and groups I need in O365. That top-level OU will end up being the source for synching my on premise AD objects to O365.
After restarting the server, I opened the Synchronization Service Manager to configure filtering. I went through the steps to configure filtering for the one top-level OU I created with the exception of the third set of tasks. Because, we did not previously run the synchronization tasks we jump from the second set of tasks to the fourth set of tasks by enabling the Azure AD Sync Scheduler scheduled task and finally running it.
At the conclusion of the scheduled task run, I was able to confirm the accounts from both forests (e.g. domain1.com and domain2.com) were present in my Office 365 tenant–and easily identifiable based on the UPN suffixes that were set in AD and the domains that were added to O365.
- Azure Active Directory Synchronization Services (AADSync)
- Requirements for AADSync
- Installing AADSync
- Configure Filtering with AADSync
- Uninstalling AADSync
- Force Sync to Office 365 with AADSync
- AADSync Updates
- AADSync Version History