Active Directory Insights (Part 5) – Domain controller hardware sizing

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

Introduction

Domain controllers are the heart of a Windows Server environment. They’re the keys to the kingdom, and because of this they need not only to be secure but also reliable and always available. Having at least two domain controllers in each domain (and sometimes at each site) is essential to ensure directory services are always available for users so they can be authenticated and authorized for accessing resources. Physical domain controllers also need to have system hardware that has a high degree of reliability and resistance to the different kinds of hardware failures that server systems can be prone to. And virtualized domain controllers need to be run on host machines that have hardware with similar reliability requirements.

Basic system requirements for domain controllers

Determining the system requirements for domain controllers running Windows Server 2012 R2 begins with the basic system requirements for this operating system platform. At a minimum this means the server system you plan to deploy the Windows Server 2012 R2 domain controller role onto (and any additional roles like the DNS Server role) must be at the least:

  • 1.4 GHz 64-bit processor or faster
  • 512 MB RAM or greater
  • 32 GB disk space or greater
  • Ethernet network adapter

The above values are documented on this TechNet page. Naturally these processor, memory, storage and networking hardware requirements are the absolute minimum of what you should use. In the real world you will certainly want to have a faster processor and probably at least 2 GB of RAM, 1 GB of disk space, and a Gigabit Ethernet (GbE) network adapter. But will something like this always be enough for the environment where you need to deploy your domain controller?

The challenge of domain controller sizing

In the early days of the Windows Server platform, sysadmins spent a lot of time trying to correctly predict or “size” the workloads their servers would need to be able to handle so they could purchase hardware that would be able to handle the load the server would need to carry. This often involved creating test environments with lots of dummy accounts and resources and then automating common events like logons, group membership changes, privilege changes, policy processing, and so on and then assessing the impact (load) caused by these events. Microsoft even provided a tool for this purpose called the Active Directory Performance Testing Tool (adsizer.exe) but this tool was unsupported and was part of the famed Windows 2000 Resource Kit that included many other useful tools, some of which Windows Server admins still use to this day. But before you completely write off using this tool to profile the performance of your Windows Server 2012 R2 domain controllers, you should read this post from the Ask Premier Field Engineering (PFE) Platforms Blog where Tom Ausburne, a Premier Field Engineer at Microsoft specializing in Active Directory, explains in detail why and how this tool can still be useful even with the latest version of Windows Server. I find this simply amazing!

This often turned out to be a lot of work with very little fruit for all the effort put into it. Most sysadmins of real companies don’t have the time for doing sizing exercises like this, and they also may not be familiar with the tools or utilities that can be used to automate testing procedures and collect profile results. Many admins also don’t have sufficient scripting skills to be able to roll their own workload testing tools, and even if they do have such skills they often lack the free time to spend writing such scripts.

As a result, admins early on began hounding Microsoft asking them for some “authoritative” guidance on different server sizing scenarios. For example, a typical question might be: what processor, memory, disk and network hardware do I need for a domain controller that supports 3,000 users and about 60 security groups and two dozen Group Policy Objects and 4 file servers each with several hundred shared folders and…etc.

Microsoft, always wanting to be helpful to their customers (or at least appearing to be helpful) obliged in this regard with respect to the Windows Server 2008 R2 platform by creating a series of Solution Accelerators (SAs) called Infrastructure Planning and Design (IPD) guides for the platform. One of these guides titled “Infrastructure Planning and Design: Windows Server 2008 and Windows Server 2008 R2 Active Directory Domain Services” published in 2008 and updated in 2011 includes some additional information on how to determine disk space, memory, processor, and the network requirements for domain controllers. For example, concerning the disk space needs of domain controllers this guide says you should allocate at least:

  • 500 MB for AD DS transaction logs.
  • 500 MB for the drive containing the SYSVOL share.
  • 1.5 GB to 2 GB for the Windows Server 2008 operating system files.
  • 0.4 GB of storage for every 1,000 users in the directory for the NTDS.dit drive

For memory requirements, the guide suggest you’ll need 2 GB of RAM if you have more than 1,000 users per domain in a given Active Directory site, but it then goes on to say that additional memory can improve performance of the directory services. The guide goes on to say you should use Performance Monitor to monitor the Database Cache % Hit counter if you really want to assess the amount of RAM your domain controller needs, but in my experience most admins I know rarely if ever use Performance Monitor for collecting and analyzing performance data for Windows servers. Why not? Because it takes time to collect meaningful data and expertise to understand what the collected performance data is telling you about the server. The guide is quite unhelpful at this juncture because it should have included a real-world example of data collected for the Database Cache % Hit counter and then explained what the collected data means.

As for processing requirements, the guide is even less helpful as it basically focuses on the 32-bit version of Windows Server 2008. That’s because the guide was originally written for Windows Server 2008 and then updated for Windows Server 2008 R2, but the updating involved was probably minimal. Anyways, the guide suggests somewhat confusingly that if you have less than 10,000 users (but more than 500 users) then you should dual processors “and then scale from there” provided you assume that the “primary work of the directory is user authentication.” This doesn’t say very much and it also seems irrelevant for us today (in 2015) since even an entry-level Dell server has a processor that has two cores.

The suggestion for networking requirements is similarly vague and warns only that “placing multiple network adapters in a domain controller can cause a variety of issues, ranging from replication failures to authentication failures, and is generally not recommended.” The option of using teamed network adapters on a domain controller is not even mentioned, which again suggests that the revision this guide received in 2011 was minimal and did not give consideration to the kinds of real-world server system hardware that was readily available at that time. We’ll consider this matter of network teaming on domain controllers in the next article of this series.

The fact that Microsoft has not updated (or better, completely rewritten) this Solution Accelerator for Windows Server 2012 is indicative that the step-by-step guidance provided by this guide was probably intended more to assuage customers’ anxieties than to provide authoritative guidance for turnkey sizing of how to provision various Windows server roles. And in fact it appears that since 2013 Microsoft has discontinued creating these Solution Accelerators for if you look at this page you’ll see they’ve now been moved from the TechNet Library to the TechNet Archive.

What about Windows Server 2012 R2?

What then should admins do today if they want to properly size a physical domain controller that will be running Windows Server 2012 R2? I asked a couple of consultants and other experts who work at Microsoft if they could suggest some resource that could guide a customer for doing this, and the uniform reply I received was to look at the above IPD guide for Active Directory Domain Services. I was told that Microsoft doesn’t have anything more recent, and that the basic recommendations for Windows Server 2008 R2 found in this guide are “still sensible” when it comes to the latest version of Windows Server.

According to what I’ve been told there is no other “official” document from Microsoft on how you should properly size domain controllers running Windows Server 2012 R2. And in fact, the above Solution Accelerator should probably not be considered Microsoft official guidance since it’s now archived content on TechNet. So if your boss is demanding “something official” from Microsoft concerning this, you’re not going to get it. The best answer you’ll probably get is “try it out and adjust it until it works properly” and in fact that really is the sensible answer as far as any kind of server sizing is concerned. In fact, one Microsoft expert was reported by a colleague as saying “We recommend the customer should become acquainted to the Windows performance monitoring options and test their planned configuration in the lab” and I wholeheartedly agree with this sentiment.

What about non-official Microsoft recommendations? One colleague who has worked with Microsoft in the past pointed me to this page in the TechNet Wiki that describes some exercises you can perform to evaluate whether the RAM, network bandwidth, data storage needs and processor usage for your domain controllers are sufficient. In my opinion the “best-effort” guidance presented on this Wiki is more useful than the “step by step” prescriptive guidance provided by the out-of-date IPD guide because it doesn’t create the illusion that you can turn off your brain and just follow a checklist but instead tries to get you to think about the complex issues involved in the practice of workload sizing.

For example, concerning memory sizing the Wiki says this is “actually quite a complex exercise” that has a “high potential for error” and that the labor involved in such sizing exercises is often “prohibitive”. The Wiki then goes on to say that the “Planning” section discusses in “greater depth how [memory] can be tuned” but unfortunately when you click the link to this Planning section returns Page Not Found (!) but fortunately it turns out that’s just a broken intra-page link and the missing Planning section can be found further down the page.

This Planning section actually contains a worked example of sizing the memory for a domain controller, but unfortunately the example here uses Windows Server 2008 as the base operating system! However, a careful examination of this Wiki page indicates that it was likely written in 2013 (after Windows Server 2012 was released) and since the basic operation of the Active Directory Domain Services (AD DS) server role has not changed much since Windows Server 2008 R2 (See https://technet.microsoft.com/en-us/library/dn268294.aspx for a description of the new AD DS features in Windows Server 2012 R2) one can assume that the recommendations and scenarios included on this Wiki page still pretty much apply to domain controllers running Windows Server 2012 R2. At least we can hope so–if only Microsoft would keep their documentation updated!

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:

Leave a Comment

Your email address will not be published.

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

Scroll to Top