Enterprise deployments are complicated. When you add “cloud” services to enterprise deployments, they become much more complicated. I think we can consider those two statements axiomatic at this point. If we want to add a third axiom to the list, saying that people want simple solutions would fit the bill. Microsoft knows all three of these things, and bless their little hearts they really do try to make things as simple as they can. I have no doubt what-so-ever that their hearts are in the right place, but sometimes that is not enough.
Microsoft has just released a Beta of a new tool called Azure Active Directory Connect. You can find the blog post announcing this release HERE. The problem that Azure Active Directory Connect tries to solve is that of the complexity involved in connecting an on-premises Active Directory to Azure Active Directory. I have not had a chance to run the install for Azure Active Directory Connect yet, but I am pretty sure that Microsoft has completely missed the boat on this one.
To examine why I think this new tool fails at the job it is intended to do, we have to look at where the complexities lie.
Confusion point #1 – The name.
So you want to connect your on-premises Active Directory to “the cloud”. OK, do you connect it to Office 365? Windows Azure? Windows Azure Active Directory? Microsoft Azure Active Directory? Do you use DirSync? Azure Active Directory Sync? Forefront Identity Manager? Azure Active Directory Sync? Azure Active Directory Connect?
The point is that before we can plan a deployment, we all need to be talking about the same thing. Microsoft does not make this easy with the branding of these services. The names change way too frequently, one product can be referred to with several different names, and trying to brand everything as “Azure” ends up making all the names sound very similar. Adding Azure Active Directory Connect does nothing to address this problem, in fact it makes it worse.
Confusion point #2 – the purpose.
What does AAD Connect do? According to that blog post, it has 3 main purposes
- Streamline the experience so fewer tools are required
- Guide you through the experience so you don't have to read a bunch of documents
- Reduce the on-premises footprint so you don't have to deploy a bunch of servers
Those sound great, but as far as I can tell they just are not true. From what I can see, Azure Active Directory Connect is a set of scripts that deploys Microsoft Azure Active Directory Sync Tool. Azure Active Directory Sync will be supported by Azure Active Directory Connect at some point in the future. Azure Active Directory Connect does not eliminate the need for Microsoft Azure Active Directory Sync Tool so I don’t see how you can say “fewer tools are required”. If anything the same number of tools are required, but more tools are available.
As for “guide you through the experience so you don’t have to read a bunch of document”, this is insane. You never had to read a bunch of document to deploy Microsoft Azure Active Directory Sync Tool, you only have to read those documents if you want to understand how it works. Microsoft Azure Active Directory Sync Tool is dead simple to deploy, so reducing the number of times I have to click “Next” by 4 is no great accomplishment.
The last bullet point is “Reduce the on-premises footprint so you don't have to deploy a bunch of servers”. Again, this is just crazy. I need one server to deploy Microsoft Azure Active Directory Sync Tool if I use Azure Active Directory Connect, and I need one server if I don’t. How does that a reduction in the number of servers?
So what does Azure Active Directory Connect do? From what I can tell, it installs the Microsoft Azure Active Directory Sync Tool pre-requisites for you (a single line of PowerShell can do the same), it configures Microsoft Azure Active Directory Sync Tool for you (Already pretty simple. The Microsoft Azure Active Directory Sync Tool setup only has 2 check boxes where you need to make a choice, the rest of the install is knowing your password and clicking next), and it “Makes sure everything is working”. Maybe that last thing is of some value, but I really doubt it. From what I can tell this is just another confusing option in an already confusing list of options for identity and authentication management for Office 365/Azure.
Again, I have not used Azure Active Directory Connect yet, so may I am way off base on this. When I get a chance, I’ll give it a try and see.