So it seems to me that there are a lot of options open to you to extend your on premise AD to Azure AD, but just which one should I use? A typical consultant answer, well that depends! Here is a bit of story that tells the DirSync journey that I have been on which may help clarify why we have so many options and where it is all leading to:
DIRSYNC FOR ALL YOUR SYNCING NEEDS (AS LONG AS YOU ONLY HAVE ONE AD FOREST):
In the beginning Microsoft created DirSync and all was good in the world (May sound a bit preachy but this is a good place to start). DirSync was a tool that was installed on a server on premise that would synchronise you on premise AD to Azure AD. Simple. Job done.
BUT! DirSync had one limitation (big one for a lot of customers). It can only handle one Active Directory forest! For organisations that had multiple forests such as organisations that had adopted a resource forest model, DirSync simply could not handle it and in the early days was a technical blocker for people wanting to adopt Microsoft cloud solutions such as Office 365.
FIM, WHEN SYNCING MULTIPLE FORESTS IS YOUR BAG:
Along came the workaround, the long standing and much underused in my opinion, product they call FIM (Forefront Identity Manager). FIM had a special connector created by Microsoft which was just the ticket for those tricky multi forest deployments. If you lift the hood of DirSync you will actually see a cut down version of FIM as the engine so no surprise that it’s bigger brother could be configured to sync our AD to Azure AD!
Problem was, you had to buy FIM licenses, get experts into deploy it and then configure the connector to how you wanted it, the cost saving of adopting the cloud could be wiped away with the need for licenses and expertise to deploy this solution and just was not appealing to customers looking to adopt Office 365.
WE DON’T NEED NO STINKING FIM OR DIRSYNC:
Finally, a solution. Azure AD Sync Tool was released and there was much rejoicing! Azure AD Sync could handle multi forest deployments, tick. It does not require any additional licensing, tick. It can run on a single server just like DirSync could with a simple wizard driven deployment, tick. So that’s surely where we leave it. Tea and medals all round.
COME BACK DIRSYNC!:
Or so I thought. Imagine my surprise when a college was trying to configure conditional access using Azure Active Directory Device Registration and all the articles refer to DirSync and not Azure AD Sync, an overlook surely I thought but checking this article I saw that it was true! Device write back is only available in DirSync and not in AAD Sync Tool:
https://msdn.microsoft.com/en-us/library/azure/dn757582.aspx
It seemed that the only option we had was to redeploy DirSync to have this feature enabled but I know from my time last year at TechEd and the blogs that have been flying around that papa will soon have a brand new sync bag!
THIS TIME WE NAILED IT!:
Throw any challenge that has been mentioned above at Azure Active Directory Connect and it will knock it out the park! Yes to multi-forest deployments, tick. It does not require any additional licensing, tick. It can run on a single server just like DirSync could with a wizard driven deployment, tick. Can support all of those features like write-back of devices? Nearly a tick. It is currently in public preview 2 according to this blog but Microsoft will support it in production environments but as you can see in the feature list, CS=Coming Soon, it is not quite there yet.
In addition to all these great new features it can also allow customers to deploy ADFS and WAP for single sign on using the wizard making the deployment of single sign on for the environment even more simple.
I am eagerly anticipating the final release of Azure Active Directory Connect, you can get a preview right now but all the features may not be there as of yet but finally I will be able to answer the question as to what we should be using as our sync client:
AZURE ACTIVE DIRECTORY CONNECT
This will replace all of the others once it is finally released with all features in the first part of 2015 which I read as being at the end of May.
Did notice a potential gotcha! The Azure Active Directory Connect client will only be installed on Windows Server 2012 or Windows Server 2012 R2. I know of a few clients that have still not deployed Windows Server 2012 or Windows Server 2012 R2 in their environment. If this is you then don’t worry the other sync clients will be fully supported but you may miss out on some great new features that Azure AD Connect will bring.
In the meantime all of the other sync clients are still fully supported by Microsoft and you should use this URL to decide on which best fits your needs if Azure Active Directory Connect still has not been released use this as your guide as to which one you should use according to your needs:
https://msdn.microsoft.com/en-us/library/azure/dn757582.aspx
Cheers
Paul
