Why installing Azure AD Connect on an Active Directory Domain Controller might not be the most brilliant of ideas

Reading Time: 3 minutes

Azure AD ConnectWhen you read through Azure AD Connect’s prerequisites page, you’ll notice that Microsoft supports installing Azure AD Connect on Active Directory Domain Controllers.

While this would certainly be a helpful scenario for organizations with up to 50 user accounts, I would not recommend doing so.

Installing Azure AD Connect on a Read-only Domain Controller is a no-go area.

Here’s why:



Is the problem with Active Directory or with Azure AD Connect?

Requiring a reboot for Azure AD Connect might result in temporal denial of service to users, applications, systems and/or services that rely on the Active Directory Domain Controller. This is especially true for environments with a single Domain Controller. I know this scenario is unsupported, but common in small environments.


Disaster Recovery

In terms of disaster recovery (DR), it’s a best practice to keep all Active Directory Domain Controllers as similar as possible and to configure them identically, following a pre-approved procedure. This way, when a Domain Controller fails, it can easily be rebuilt from scratch. When you install Azure AD Connect on an Active Directory Domain Controller, it becomes a one-off.

Azure AD Connect comes with a SQL Server 2012 Express Edition database. When you install SQL Server on an Active Directory Domain Controller, you lose the ability to demote the Domain Controller. This might hurt any disaster recovery procedure you might want to follow, when, for instance, the Active Directory database (ntds.dit) becomes corrupted.

In the worst case scenario, the Active Directory Domain Controller functionality and the Azure AD Connect functionality, would both have to be rebuilt from scratch. I wonder how many people have documented and/or exported their Azure AD Connect configuration, and especially their custom synchronization rules…



Any application and/or agent installed on an Active Directory Domain Controller adds attack surface. Azure AD Connect and especially its SQL Server 2012 Express Edition may contain vulnerabilities, that would lower the security stance of the Active Directory Domain Controller they are installed on.


Service Accounts

Any Azure AD Connect service accounts that need admin to the local server are added to the Builtin\Administrators group in Active Directory and, thus, gain administrative privileges to the Active Directory domain.


Memory consumption

Azure AD Connect comes with SQL Server Express, when you don’t choose to use a separate SQL Server (cluster) to host its database. SQL Server uses resources and is particularly fond of RAM. Active Directory Domain Controllers also likes to use your RAM, to cache its database (ntds.dit).

Granted, in small organizations, the Active Directory database (ntds.dit) would not exceed 40MB, but in some larger organizations, both RAM usages would collide and starve the Windows Server installation from available RAM. Performance issues might follow, when the disk subsystem is hammered for the pagefile.


Global Catalogs and the PDC Emulator

When you install any application on an Active Directory Domain Controller, it tends to communicate exclusively to that Domain Controllers. Surely, the Domain Controller wouldn’t need other Domain Controllers to provide the right information. All Domain Controllers are created equally anyway, right?

Some Active Directory Domain Controllers are created more equally than others. Some Domain Controllers act as Global Catalogs. In an environment with multiple Active Directory domains and/or multiple Active Directory forests, Azure AD Connect should be installed on a Global Catalog.

When you promote a Domain Controller to a Global Catalog, don’t forget to reboot it afterwards.

Other Active Directory Domain Controllers hold one or more of the Flexible Single Master Operations (FSMO) roles. Ranging from forest-wide to domain-wide roles, one role is of particular importance: the PDC Emulator role. The Domain Controller with the PDC Emulator Role in each Active Directory domain is the source of replication for password(hashe)s and Group Policy changes. If you really need to install Azure AD Connect on a Domain Controller, especially when using Password Hash Sync (PHS), installing Azure AD Connect on the Domain Controller with the PDC Emulator FSMO Role would make the most sense for the scenario.



Microsoft KnowledgeBase Article 2032911 states that is not recommended to install SQL Server on an Active Directory Domain Controller and explains that you ‘may encounter problems’.

From a support point of view, this means that when you encounter problems, you might need to relocate Azure AD Connect somewhere else on the network, before Microsoft would start troubleshooting your issues.



Don’t do it.

11 Responses to Why installing Azure AD Connect on an Active Directory Domain Controller might not be the most brilliant of ideas



    I'm doing an analysis before installing. This helped.



    Thanks for the document, I was about to install a DC in my AD Connect server.

    I have installed a small network with a DC, a AD FS server, a WAP server and have federated some services. Now I want to access Azure services for my network, and planning to install a new VM with a clean server 2016 and Azure AD connect.
    Does Azure AD Connect has to be installed in the AD FS server ? or can it be another server in my domain?


    • Hi Manuel,

      Azure AD Connect does not need to be installed on an AD FS Server.
      You can install it on a separate server.



    I installed AD connect on our Domain Controller (Windows Server 2008 R2).
    How do I uninstall it from this live Domain Controller?

    Does uninstall result in any issues for SQL?
    Will it corrupt my Domain Controller?
    Please advice me.

    • You can install Azure AD Connect on another server, that is not a Domain Controller. Install it as a Staging Mode server.
      Follow the steps from my Azure AD Connect Release Management HOWTO to switch the two Azure AD Connect installations with all the required checks, but without risk or downtime.

      Then, uninstall Azure AD Connect, together with all its components (this includes SQL Server Express).

      I have not experienced any issues uninstalling Azure AD Connect from Domain Controllers. If you have merely one Domain Controller in your environment, than the best time to deploy the second Domain Controller is before you uninstall Azure AD Connect from the first Domain Controller.


    Perhaps you should mention that whichever server you install AADConnect on needs to be treated the same as any other Tier 0 server (like a DC).



    I understand that its not recommended to install on production domain controller but can we install in test environment> i do not want to create another server in test environment.

    • Hi Usman,

      If your test environment is a true test environment, you could use the approach. However, from a privacy and security point of view, this means that the environment cannot contain any actual personal data, cannot contain any production data and cannot use information or naming that is traceable to the production environment or the organization. After all, this environment has a lower level of information security and thus a higher chance of being compromised.


    Hi, What if I plan to install the DB separately anyway?

    • All of the above points remain valid, except for installing SQL Server on the Domain Controller.

      You can install Azure AD Connect using a separate SQL Server.
      To this purpose you'll need a service account or gMSA in Active Directory. With Azure AD Connect installed on a Domain Controller, Azure AD Connect would only communicate with the directory service on that Domain Controller. If the directory service fails, Azure AD Connect will stop working, both for not being able to communicate to Active Directory and for using its service account.

      Additionally, you will need to open additional networking ports between the SQL Server and the Domain Controller. This networking traffic may be used by an attacker to gain access to the Domain Controller in unforeseen and possibly unmonitored ways.

      Be sure to encrypt the traffic between the Domain Controller with the Azure AD Connect and SQL Server and secure the SQL Server properly (you are now hosting identity data on it).


leave your comment

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