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.
Have fun!
Related Article(s):
- 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
Reference(s):
ODDYTEE 
Thanks for your post. Question: We do have on single domain. I would like sync (AADsync) OU “A” to Office 365 Tenant “A” and OU “B” to Office 365 Tenant “B”. This should be possible, right? But how? Thanks for your feedback.
When I attended the Office 365 Summit at the beginning of December, this specific question was asked. The presenter (Luca Bandinelli) stated AADSync is not designed, or supported, to sync one Active Directory forest to multiple Office 365 tenants. A discussion ensued about how to possibly configure such an unsupported implementation in a test environment.
I have not tried what you are asking but, in theory, think it could be done. In the same vain, if you are curious, I would strongly encourage that any one try it out in a lab environment first. If it does work, however, remember that the configuration is not supported by Microsoft (or any one else I know of for that matter).
In theory, you could install AADSync on two separate machines. I would sign up for 2 trial tenants to test. One AADSync server for one tenant, filtered by OU using the credentials for “tenant A”. And then the second AADSync server for the other tenant, filtered by OU using the credentials for “tenant B”. Do not sync until you have configured filtering for both implementations. Once the filtering is configured, I would think you should be able to sync from one AD forest to multiple O365 tenants.
Again, this is all in theory and no guarantees are made or given. All of the risk falls squarely on the shoulders of the implementer.
Who knows…this may all be possible with the next iteration of the Microsoft sync tools in Azure Active Directory Connect (Azure AD Connect). Until it has been made generally available, we will have to wait.
Hi Todd, thanks for your answer. We’ve already tried this approach by using different AADSync servers with OU-based filtering and it worked. However, the keypoint is that we would like to have just ONE AADSync server for all tenants. In my opinion it should be possible to configure multiple sync instances, for example: Customer “A” with UPN suffix a-example.com to Office 365 tenant “A”, Customer “B” with UPN suffix b-example.com to Office 365 tenant “B” and so on…
Well, as you already mentioned it’s not a supported configuration. I hope Microsoft will bring this feature very soon – in my opinion it’s a mandatory feature for tenant based Active Directory configuration. Anyway, thanks for your help and I wish you a happy new year.
Hi Oliver,
Do you know if MS support one AADsync server for different tenant now?
As far as I know, they still do not support it and I don’t believe it will be supported with AADSync. However, that could be possible with AAD Connect. That is where they have all of their focus right now, in my opinion. Hopefully, it will come out about the same time Exchange 2016 is released in Q4 2015.
Thanks for quick reply Todd, that’s good news for all SPLA hosting companies doing multitenant with customers that wants to use o365 for some services.
Hi Daniel,
I agree with Todd. Next step will be AAD Connect, but: I didn’t read anything about “Multi-Tenand O365 Support”. We’ll see… at the moment we have to use multiple instances/installations on member servers for each tenant…
Hi Guys,
first of all, I would like to thank for this blog which is it very useful for who use Office 365 for the first time.
I’ve the same problem of Oliver, i need to sync a multi domain Office365 with a single AD forest.
From what I understand, its possible if I install two AADSync server ; Now, as suggested, I would like to make some test with my Office 365 E3 Trial account, but i haven’t understand two thing :
– Is it possible in the trial version add an other domain and, if yes, there is a place where i can create a test domain.
– Following this article (https://oddytee.wordpress.com/2014/09/24/configure-filtering-with-aadsync/) i’ve made a sync with a single OU, but i’ve used the office365 global admin. How I should create an administrator account for the single domain.
Thank’s in advice for the help and please excuse any mistakes as English is my second language.
Regards
Alfredo
Let me reiterate to see if I understand your questions correctly.
1) You want to add more domains to a trial account?
2) You want to create another global admin in the existing O365 account?
Responses…
1) An Enterprise E3 trial account is not different than a subscription with regards to features and functionality. You will only be limited by time. But, if you contact support they will extend the trial. I’ve used several trials for 6 months at a time–probably could have gone longer.
2) If you want to test a theory by syncing multiple OUs in one domain using multiple directory sync instances to one O365 account, I suppose you could but I have never attempted that. If that’s the case, just create a new O365 “in cloud” user and assign as global admin, and another on premise account that has Enterprise Admins privileges.
I hope I understood your questions correctly. Good luck.
Hi Alfredo
Thanks for your answer. No Problem, English is my second language too 😉 However, here is my feedback about your questions.
1) Totally agree with Todd Nelson. The Office 365 trial accounts are just limited by time, not functionallity.
2). Not sure, I really understand your question, but: You could create multiple Global Admins (@yourdoman.onmicrosoft.com). This account is comparable with Domain Admins in your On-Premise environment. You could create, for example, a seperate Global Admin for AADSync, like: sa_aadsync@yourdomain.onmicrosoft.com and set “Password Never Expires” with Powershell, because it’s like a Service Account and you don’t want this password to get expired. You need a Global Admin for each Office 365 Tenant obviously, it doesn’t matter how many domains you added for this tenant.
Keep in mind: AADSync will be called AADConnect soon (new tool). As I know, there is the Public Preview out in the wild at the moment. I read about the new features – there is no multi-tenant Office 365 feature listet in one AADConnect installation 😦
However, I can confirm the scenario I described in this post earlier is working:
One Active Directory (one Domain)
– OU “Customer A” > AADSync to Office 365 Tenant A
– OU “Customer B” > AADSync to Office 365 Tenant B
– OU “Customer C” > AADSync to Office 365 Tenant C
But, what we need for this synchronization scenario is a seperate installation of AADSync on a member server for every tenant, means: Tenant A, B and C have their own member server with ADDSync installed and OU-based filtering configured. It’s NOT SUPPORTED to sync the same object (user, group,…) to different Office 365 tenants! That’s okay for us… we don’t need something like this 😉
Hope this clears up your questions. Don’t hesitate to ask you questions or tell us about your experiences.
Regards
Oliver
Thanks for the response, Oliver.