My Early Experiences with Azure AD Connect

I deployed the generally available release of AADConnect to synchronise our Active Directory with Azure AD (Office 365) 24 hours after it was made available. Here’s my early experience.

The download link for Azure AD Connect is quite hard to find! You can download AADConnect from here. The getting started guide/instructions are here.

What is Azure AD Connect?

AADConnect is the new unified way for setting up a connection between your on-premises (“legacy”) Active Directory with Azure AD. The tool is extremely easy to use. For most SMEs, you will:

  1. Create your domain in Azure AD and validate it (operation with your DNS registrar)
  2. Set up an in-cloud service account for Azure AD with global admin rights on the directory
  3. Create a service account in your on-premises AD with Enterprise Admin rights
  4. Install AAD Connect
  5. Run the Express Settings configuration, enter your domain details, and supply the required credentials when prompted

It’s not far from Next > Next > Next. That’s what I did at work to get a directory synchronization using AD Sync.

You can do a customized installation allowing you to:

  • Tweak the configuration
  • Deploy and configure ADFS


How I Set It Up At Work

The configuration is actually pretty simple. We have 2 AD sites in our single domain:

  • On-premises
  • In Azure

All the usual AD engineering was done with AD sites, including site links, etc.

The DCs in Azure are Basic machines in an availability set (keeping them in different fault/maintenance domains or zones in Azure). The first one is a Basic A1, which is more than enough for a normal DC. The second machine is where I have installed AAConnect; I have found this needs a bit more RAM so this machine is a Basic A2 (enough for our small company). This in-Azure DC is the one that synchronises with Azure AD.


My Experience

I actually set up AADConnect while it was still in preview (2nd release). I didn’t do the express installation – which was a mistake because I wasn’t really sure what I was doing! We had previously been using O365 in a limited way with accounts that were created in the cloud; these accounts were failing to synchronize.

I upgraded AADConnect from preview to GA and the issue persisted – the upgrade ran perfectly, though and I blame me for the sync issue. I then decided to uninstall AADConnect so I could completely reconfigure the synchronization. The uninstall worked perfectly (which did not happen with the first preview release) and I reinstalled and reconfigured it with the express installation. A few minutes later, every account, except one, was showing as “Synced with Active Directory”.


The one remaining one was one of the original in-cloud users. That has a sync-generic-failure warning in Synchronization Service Manager (the AAD Sync GUI (C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe) which betrays some of it’s heritage. The stack trace shows an error of “The object located by DN is a phantom”. A metaverse search doesn’t find the user account … so AADSync doesn’t find the user in on-prem AD, but the user is in AAD. However, I can see the user in on-prem AD. Quite odd!

Anyway, other than that 1 user account, I think AADConnect is superb. It’s a huge step forward from DirSync, which is complex to set up, and I found it to be a house of cards. This product looks much better so far, offering an easy setup for most customers, and easy to access and detailed logs.


That one account eventually did sort itself out over the weekend. I have no idea how – it just synchronised and I cannot complain about that! Password write-back is working fine too.

Technorati Tags: ,

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.