Azure AD Connect is GA

On February 18th  2016 Microsoft released a significant update to Azure AD Connect, version It adds some capabilities and improves on others. For me this is a core piece of the puzzle today and in the future for many of my plans to optimize the future IT Infrastructure & DevOps. Even when politics seem hell bound on slowing you down and cause a serious delay and missed opportunities this piece of technology is key in breaking through those barriers and keep moving ahead.

So what’s in the box with version

  • Automatic upgrade feature for Express settings customers.
    Support for the global admin using MFA and PIM in the installation wizard.
  • We can change the user’s sign-in method after initial install.
  • We can now set Domain and OU filtering in the installation wizard. As a secondary benefit this means we can now connect to forests where not all domains are available.
  • We get a Scheduler is built-in to the sync engine.

Some preview features are now GA:

We get one new preview features which is going to be a hit in world where patience disappeared from the equation:

  • The default sync interval is now 30 minutes instead of 3 hours before. this is configurable now in the scheduler.

It also fixes the following issues:

  • The verify DNS domains page didn’t always recognize the domains.
  • Prompts for domain admin credentials when configuring ADFS.
  • On-premises AD accounts are not recognized by the installation wizard when they are in a domain with a different DNS tree than the root domain.

Grab the latest version of Azure AD Connect here.

9 thoughts on “Azure AD Connect is GA

  1. I still see the issue of “Prompts for domain admin credentials when configuring ADFS.” on my installation. This happens when I’m trying to switch from password sync to ADFS and I always get an error of “User %DOMAIN%\Administrator doesn’t belong to the domain admin group of %DOMAIN%.

    Can anyone verify this?

      • Nope, sorry. Haven’t had any luck so far with any of the updates either. I’ve communicated the bug to Microsoft but they haven’t really gotten back to me yet. I’m thinking it might be something about my AD forest with multiple child domains. And I’m still considering a reinstall of AAD Connect but haven’t gotten to it yet.

      • I think I’ve found it: Use a domain admin account that is not also a member of the enterprise admin group.


  2. Wanted to share how I resolved this, since this post is the only result I get when searching for the exact error.

    The account I was installing Azure AD Connect with was a domain account, with admin privileges on the server I was installing on, but was NOT a domain admin. When entering a domain admin username and password, it would give the above mentioned error. Adding the account used to install AADConnect to Domain admins fixed the problem for me.

    Presumably running the program under a domain admin account on the server would accomplish the same thing.

  3. I have tried multiple different ways. I still get the same error. I have confirmed my user is in the domain admins group. I have tried it with enterprise admin group and not. Any ideas?

  4. I have just resolved this issue on my end. For my solution, the Domain Admin group was set to be the primary group assigned to my user. I added the domain user group to my user, set it as the primary group while leaving the the user a member of the domain admin group. My issue is resolved, I hope it helps.

    • This worked for me too. I had this come up during the Azure AD Connect wizard when it was setting up ADFS as part of the install/config.

      Here’s a recap for other people:
      1.) Set the Domain Admins group as the primary group.
      2.) Remove the user from Domain Users group.
      3.) Add the Domain Users group membership back.
      4.) Set the Domain Users group as the primary group.

Leave a Reply, get the discussion going, share and learn with your peers.

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