UK’s trusted IT infrastructure partner since 2003
Servnet
ConfiguratorGet in Touch
Specifying an Active Directory domain controller without over-building it (UK 2026) — analysisSpecifying an Active Directory domain controller without over-building it (UK 2026) — analysis — reach
Server Infrastructure · How-To

Specifying an Active Directory domain controller without over-building it (UK 2026)

Servnet Editorial · Server Infrastructure Practice10 min read

The domain controller is the server people reflexively over-build. It sits at the centre of everything, so the instinct is to throw a big two-socket box at it - which is almost always the wrong call. Active Directory is one of the lightest production roles you will ever run. The job here is resilience and placement, not horsepower. This is how we spec domain controllers for UK customers without wasting money.

How many DCs, and how big?
How many users and sites?
One small site
2 modest DCs, redundant
Multiple sites
A DC per site, local auth
Large estate
More DCs, still modest

Active Directory is a light role - genuinely

A domain controller authenticates logons, serves Group Policy, and replicates a database that is small by modern standards even in large organisations. The AD database and SYSVOL share are measured in low gigabytes for most businesses, the working set fits comfortably in modest RAM, and CPU sits near-idle outside logon storms. This is not SQL Server or a virtualisation host; it does not need fast cores or a wall of memory.

The corollary is liberating: you should deliberately under-spec a DC relative to your instinct. The money and effort belong in redundancy and correct placement, not in a spec sheet that will never be exercised.

Resilience comes from count, not from one big box

The single most important rule: never run a single domain controller. AD is designed to be multi-master, so two (or more) modest DCs give you real resilience - one can fail or reboot for patching while the other keeps authenticating. Two small servers beat one large one every time for this role, because the failure domain is what matters, not the per-server capacity.

Size the number of DCs from your user and site count, not from load. A single small site needs two DCs for redundancy; multiple physical sites usually want a DC each so authentication stays local and survives a WAN outage. That placement decision drives the build far more than any performance number.

Virtual, small physical, or a MicroServer?

Most DCs today are virtual machines - and that is fine, with caveats. A virtual DC must follow Microsoft's guidance (modern VM-GenerationID-aware hypervisor, no naive snapshot rollback of a live DC, time sync handled correctly) to avoid the USN-rollback problems that plague careless virtualisation. If your hypervisor cluster is healthy, a pair of small VMs is the cheapest, most flexible answer.

But there is a strong argument for at least one physical DC. If your entire estate is virtualised and the virtualisation platform depends on AD to authenticate, a total cluster outage can become a chicken-and-egg recovery nightmare. A small, cheap physical DC - the kind of role an entry-level tower or an HPE MicroServer fills perfectly - breaks that dependency loop. Read the detail on the HPE MicroServer for exactly this lightweight, always-on role.

  • Two small VMs: cheapest and most flexible if the hypervisor cluster is healthy
  • One small physical DC: breaks the AD-depends-on-virtualisation-depends-on-AD loop
  • MicroServer / entry tower: ideal physical DC - low power, low cost, always on
  • Never: a single DC, or a virtual-only design with no out-of-band recovery path
VM DC vs small physical vs MicroServer
Virtual DCSmall physicalMicroServerCostLowestLowLowestFlexibilityHighestMediumLowBreaks loopNoYesYesBest asPair of DCsAnchor DCAlways-on DC

What the spec actually needs

Concretely: a modest current-generation CPU (entry single-socket is plenty), enough RAM to hold the AD database and OS comfortably with headroom - tens of gigabytes, not hundreds - and a small mirrored SSD/NVMe pair for the OS, database and SYSVOL. ECC memory is worth having for a server that must stay up, but exotic RAS features and maximum core counts are wasted here.

Resist the temptation to co-locate heavy roles on a DC. Keep domain controllers single-purpose where you can; piling file shares, print, or applications onto a DC turns a trivially-recoverable server into a complicated one and expands its attack surface. Build a right-sized physical DC in our configurator.

Getting the build right

The summary: spec down, duplicate, and place deliberately. Two modest DCs with sensible placement deliver far better availability than one expensive server, and keeping at least one physical breaks the worst-case recovery dependency. If you want a second pair of eyes on the design, our server configuration service sizes the role to your user and site count and stops you over-building. For an entry-level always-on physical DC, the HPE MicroServer is purpose-made.

Key takeaways
  • Active Directory is a light role - deliberately under-spec a DC relative to your instinct.
  • Resilience comes from running two or more modest DCs, never one large box.
  • Size DC count from user and site count for local authentication, not from load.
  • Keep at least one physical DC to break the AD-depends-on-virtualisation loop.
  • Modest CPU, tens of GB of ECC RAM, mirrored SSD - keep DCs single-purpose.
Frequently asked

FAQs — Specifying an Active Directory domain controller without over-building it (UK 2026)

Sizing

What spec does a domain controller need?

Far less than people think: a modest single-socket CPU, tens of GB of ECC RAM, and a small mirrored SSD for the OS, AD database and SYSVOL. AD is a light role - put the effort into redundancy and placement instead. Size it in our configuration service.

How many domain controllers do I need?

At least two for redundancy, and ideally one per physical site so authentication stays local and survives a WAN outage. The count is driven by sites and resilience, not load. Build a right-sized DC in our configurator.

Virtual vs physical

Should a domain controller be virtual or physical?

Virtual is fine if your hypervisor follows Microsoft's guidance on VM-GenerationID and snapshots. But keep at least one physical DC so a total cluster outage does not become a chicken-and-egg recovery - an HPE MicroServer is ideal for this.

Can I run other roles on a domain controller?

Best avoided. Co-locating file, print or application roles turns a trivially-recoverable server into a complicated one and widens its attack surface. Keep DCs single-purpose - our team can help design the wider estate around them.

Related

Got a question this article didn't answer?

One conversation with an engineer who's done this before. No sales script.

Talk to Servnet →