Domain Controllers as Cluster Nodes – Bad Idea

This is an issue that pops up all the time when it comes to best practices and building server clusters.  

It is considered a very bad practice, in the community, to run Domain Controllers (DCs) as nodes in a cluster. While Microsoft says it is possible, and it is even discussed in KB171390

So, why do so many people recommend against doing it? Let’s hit the main reasons:

  • Microsoft clearly recommends against it in KB281662

  • It is not supported for Exchange per KB898634

  • There are known issues with file share clusters per KB834231

  • The SQL team strongly recommends against it for performance reasons

  • Some hotfixes for DC/GCs may not be recommended for clusters

  • There is overhead involved with running the DC/GC on each node of approximately 130 MB of RAM, plus issues with replication traffic and overhead involved with responding to authentication and logon requests

  • There are issues with multihomed DCs where the private connections also get registered in DNS and can cause many systems to fail to properly logon/authenticate – the check box to not register the private heartbeat connection is not honored by a domain controller without proper hotfixes or registry hacks

  • If they are the only DCs in the org, then they must also be Global Catalog servers (GCs) and must also host DNS

  • If they host DNS, they should point to each other for their own DNS resolution, which will cause failures in resolution if one node is down

  • There are issues with FSMO roles and how will they will be handled if the node that hosts them is down

  • There are problems with the first node coming online if it is the only DCs in the org because the cluster service needs to validate its own account, but it can’t find the DC if the node is pointing to the other for DNS per proper DNS practices and the same is true for services such as SQL and Exchange that use service accounts

  • There are issues with possible failures if the DC is too busy being a DC and the cluster service can’t access the quorum drive as required

  • The hisecdc security template will break clustering if it is used to secure domain controllers

It is vital to remember why we are implementing server clustering when it comes to making decisions like making the nodes domain controllers. We implement server clustering because the service that the cluster is hosting is vital to the company, and we want to mitigate against risks that could cause its failure. Putting nodes on domain controllers introduces too many new risks to the cluster and that is a huge violation of high availability practices.

I hope I have made it clear that it is a really bad idea to use DCs as cluster nodes.

Leave a Reply

Your email address will not be published. Required fields are marked *