Active Directory Insights (Part 6) – Domain controllers and NIC teaming

By /

If you would like to read the other parts in this article series please go to:

In the previous article in this series we examined the difficult subject of properly sizing the hardware for domain controllers. We basically stressed two things:

  • The system hardware of your physical domain controllers (or of the host machines on which your virtualized domain controllers are running) must not only be sufficient to handle the expected workload but also utterly reliable and resistant against failure.
  • While sizing domain controllers prior to their deployment is possible, in reality it takes lots of effort for likely small return; as a result the best practical approach for sizing domain controllers is still to throw more than enough processing, memory, storage and network resources at the problem and then add more if some is still needed.

The above can be frustrating of course for bottom-line thinking that tries to squeeze the most value out of system procurement expenditures. Management of companies that think like this tend to ask for Microsoft’s “official” guidance concerning what system requirements they need given the kind of Active Directory environment they want to deploy. But in many respects the idea of authoritative prescriptive guidance from Microsoft on how to use their products has never really existed. A good example of this is the legendary Windows 2000 Server Resource Kit which, when describing the many different options organizations could use for structuring their Active Directory forest (such as single domain, single domain tree, multiple domain trees, flat OU structure, hierarchical OU structure, geographical OUs, technical function OUs, business function OUs, and so on) simply presented each option along with some possible advantages and disadvantages, and then left it to the customer to try to figure out which option(s) would work best for them. Unfortunately many of the disadvantages of certain Active Directory structures (e.g. having multiple domain trees or using OUs based on business function) only became apparent years later when customers who implemented these options discovered the greater management complexity that resulted from choosing such options. In fact one can argue that Microsoft itself really didn’t understand the best (and worst) ways of deploying Active Directory until well after Windows Server 2003 was released. As a result I sometimes think customers who use Active Directory have been part of one of the biggest “beta testing” exercises in the history of information technology, but then I remember Google and Apple and many others (even Novell) in this regard. And perhaps the Ford Motor Company did the same kind of thing in the first decade of the 20th century, which reminds me of this famous technology quote by Douglas Adams: “Technology is a word that describes something that doesn’t work yet.”

But having looked at the topic of domain controller sizing, let’s backtrack to the first bullet listed above and examine a specific hardware issue concerning domain controllers, namely: Can (or should) one use a teamed network adapter (i.e. NIC teaming) on a domain controller? This is a good question to address as it focuses on a specific type of system hardware and whether it’s use is supported and recommended on domain controllers.

Supportability of NIC teaming on domain controllers

While Microsoft doesn’t seem to have published an official statement concerning the supportability of teamed network adapters on domain controllers, one can reasonably assume that NIC teaming might be supported in such a scenario. The simple reason for thinking this is that from the perspective of the network infrastructure a domain controller is basically nothing more than a collection of TCP/IP sockets of both server and client variety. Think of it this way: the directory service functions performed by a domain controller operate at a higher level of the stack than network communication functions occur. Specifically, Active Directory Directory Services (AD DS) performs its work at the Application layer of the Open Systems Interconnect (OSI) networking model while TCP/IP communications over the network take place at the Network and Transport layers and below. So the operation of AD DS should (one would hope) be transparent with respect to the actual nature of the physical network adapter on the physical domain controller (or on the host on which the virtualized domain controller is running).

For example, in this TechNet Forum thread dated 2008, Stuart Hudman who formerly worked as a support engineer at Microsoft says, “Technically speaking, multihomed domain controller is supported. However it’s not recommended as numerous issues can occur in such an environment.” Stuart then goes on to list some of the different kinds of problems that can arise when a domain controller is multihomed, and he goes on to reiterate that “it is supported, but not best practice”. So here we have a statement of supportability from someone who formerly worked at Microsoft Product Support Services (PSS) and who therefore at least clearly understands what the word “supportability” means when applied to Microsoft products.

Side note on multihomed domain controllers

As a side note, even if teamed NICs are supported on domain controllers this does not mean having multiple un-teamed NICs on a domain controller is also a supported configuration. Scenarios like this where a domain controller has more than one NIC that are not part of a team (a configuration called multihoming) have been strongly discouraged by Microsoft since Windows 2000 Server when this KB article was published describing some of the types of communication failures that can occur in such a scenario. And although the KB article is stated as only applying to Windows 2000 Server, several experts including a Microsoft MVP posting in this thread on the TechNet Forums state that this KB still applies to domain controllers running Windows Server 2012. One of these experts explains this by saying, “Multihomed DC’s are still not an option because there are issues when two NIC register two different IP in the DNS & which creates conflicts with the DNS name resolution. Certainly, there are workarounds, but I wouldn’t recommended to have dual NIC at least on the domain controller.” The expert then refers us to this blog post dated 2009 by Ace Fekay who is a Microsoft MVP whose technical expertise is in Directory Services and who explains some of the problems that can occur when you try to use multihoming on domain controllers running Windows Server 2008.

So while multihoming isn’t recommended on domain controllers, it is possible to implement it if you do it just right. If you’re interested in the steps involved for doing this, see this blog post for some unofficial guidance on how you can do it (and see this KB article as well). Also be sure to see this article on Windows IT Pro.com which talks about disabling unused NICs on domain controllers to make sure they don’t accidentally register IP addresses assigned by Automatic Private IP Addressing (APIPA) to the unused NICs as this can result in name resolution problems.

Recommendations concerning using NIC teaming on domain controllers

Returning to the blog post by MVP Ace Fekay referenced above, it’s worth noting that he also includes several links in his blog post to articles and discussions that suggest that NIC teaming is not recommended on domain controllers in at least certain situations. Specifically, based on the discussion in this TechNet Forum thread, you probably shouldn’t try using NIC teaming combined with network load balancing. This is also stated in an old KB article found here. However, from discussing this with a couple of people inside Microsoft it seems like these constrains may no longer apply as they date back to the Windows Server 2003 era when Microsoft still had some problems using NIC teaming on domain controllers. The basic reason for these problems was that at the time Windows Server didn’t include its own NIC teaming solution so customers had to rely on third-party solutions from networking vendors. Since Microsoft couldn’t control these third-party solutions and how they might impact domain controller operations, Microsoft didn’t like recommending NIC teaming for domain controllers at that time. Of course, the world has moved on by then and Microsoft now offers its own NIC teaming solution as a new feature called Windows NIC Teaming first introduced in Windows Server 2012.

A more recent post by Ned Pyle dated 2011 on the Ask The Directory Services Team Blog answers the question “Is NIC teaming recommended on domain controllers?” by responding, “Do you trust your NIC vendor support?” But it should be remembered that Ned wrote his post before Microsoft released their own NIC teaming solution in Windows Server 2012. Ned also points out significantly that a domain controller “probably doesn’t need” NIC teaming because if the entire network bandwidth of the domain controller’s NIC is being consumed then adding more bandwidth by teaming the adapter with a second adapter is probably not the best solution. A better solution would simply be to add another domain controller to the domain and/or site. Basically what this advice reflects is the fact that network connectivity is usually not a bottleneck for domain controllers, it’s usually memory (for caching) or processor (for handling concurrent logons) or storage (for storing the transaction logs) that is the usual bottleneck.

Ned also points out that if you do use NIC teaming then it would be best to implement in a failover configuration where the second adapter is inactive unless the first one fails in the team. A good introduction to Windows NIC Teaming in Windows Server 2012 R2 can be found in my series of articles titled Windows NIC Teaming using PowerShell here on WindowsNetworking.com. But while Windows NIC Teaming is supported for domain controllers running Windows Server 2012 and later, it doesn’t mean it’s not without problems as it still has to rely on the underlying third-party device drivers for the network adapters on the server.

Summary of recommendations

To sum up then:

  • Windows NIC Teaming is supported on domain controllers running Windows Server 2012 and later.
  • Support for third-party NIC teaming solutions on domain controllers should be discussed with your networking hardware vendor.
  • If you decide to use NIC teaming on a domain controller, configure it in failover mode so the secondary NIC comes online if the primary NIC fails.
  • If the network link to your domain controller is saturated, add another domain controller to your domain/site instead of configuring NIC teaming in load balancing mode.

Last word

Did you know that it’s possible to have too much memory in a domain controller? I actually heard about an organization that had more than 100,000 users and wanted to run the AD DS server role on powerful server systems having 512 GB of RAM in them. But this would be a very bad idea indeed, considering what it would mean in terms of page file size, time for the server to reboot, and the time it would take for a full memory dump to complete should the operating system crash on the server.

Still got questions about Active Directory?

If you have any questions about domain controller hardware planning, the best place to ask them is the Active Directory Domain Services forum on TechNet. If you don’t get help that you need there, you can try sending your question to [email protected] so we can publish it in the Ask Our Readers section of our newsletter and see whether any of the almost 100,000 IT pro subscribers of our newsletter have any suggestions concerning your problem.

If you would like to read the other parts in this article series please go to:

About The Author

Mitch Tulloch is Senior Editor of both WServerNews and FitITproNews and is a widely recognized expert on Windows Server and cloud technologies. He has written more than a thousand articles and has authored or been series editor for over 50 books for Microsoft Press and other publishers. Mitch has also been a twelve-time recipient of the Microsoft Most Valuable Professional (MVP) award in the technical category of Cloud and Datacenter Management. He currently runs an IT content development business in Winnipeg, Canada.

Read Next

Static vs Dynamic IP Address

Static vs Dynamic IP Address

Most people are familiar with Internet Protocol (IP) Addresses, but many people don’t know you have 2 types. In this article, you’ll learn about static…

Read More »

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top