How many domain controllers should we have?

Determining the ideal number of domain controllers for an organization is an important decision that requires careful planning and consideration of several factors. The number of domain controllers needed depends on the size and complexity of the network environment. While there is no one-size-fits-all answer, some best practices and guidelines can help inform the right number of domain controllers for a given business.

What is a domain controller?

A domain controller is a server that manages user accounts, passwords, group memberships and other objects in Active Directory for a domain. It authenticates users, allows or denies access to resources, and replicates directory data across other domain controllers.

Key responsibilities of a domain controller include:

  • Managing the Active Directory database
  • Handling authentication requests
  • Enforcing security policies
  • Replicating directory changes to other DCs

Domain controllers form the foundation of Active Directory and are critical for securing access to files, applications, and other network resources in an AD environment.

Factors to consider

When determining the ideal number of DCs, organizations should take into account factors like:

  • Number of users – More users mean more authentication requests and directory lookups. Additional DCs help load balance these activities.
  • Number of sites – If an organization has multiple office locations or sites, DCs are needed at each site for optimal performance.
  • Service level agreements – The number of DCs can be planned around uptime and performance SLAs for directory services.
  • Geography – Global enterprises may require more DCs to provide local authentication in regional offices.
  • Application needs – Apps that heavily use AD for authentication or identity services may require scaling up DCs.
  • Fault tolerance – More DCs adds redundancy to handle server outages or failures.

Best practices

When determining how many DCs an organization needs, some general best practices include:

  • Have at least two DCs for redundancy – One DC alone creates a single point of failure.
  • Follow odd number convention – Having an odd number of DCs (e.g. 3 or 5) allows for majority consensus.
  • Plan for scaling – Consider future user/computer growth to determine how many DCs may be needed down the road.
  • Deploy based on sites – Have DCs at each physical site for optimal performance and authentication.
  • Align with SLAs – Factor in uptime and responsiveness requirements when planning DC capacity.
  • Monitor performance – Keep an eye on DC workload, requests, and replication health to right-size as needed.

DC capacity planning

Capacity planning is key for properly sizing the number of domain controllers. Factors to consider include:

  • User and computer accounts – The number of objects in AD affects memory usage and replication traffic.
  • Authentication rates – Bulk logons from large apps can increase load at peak times.
  • Replication traffic – More DCs translates to more replication overhead across sites.
  • FSMO roles – Special FSMO roles for schema/domain naming masters may require dedicated DCs.
  • Virtual vs. physical – Virtual DCs require additional host resources that can constrain capacity.

Microsoft provides guidance on domain controller capacity based on the number of objects in Active Directory:

User/Computer Accounts Recommended DCs
Fewer than 10,000 2 DCs
10,000 – 30,000 3 DCs
30,000 – 70,000 4 DCs
70,000 – 125,000 5+ DCs

However, these are general guidelines. The right number still depends on the specific environment, workloads, and performance requirements.

Location and placement

The physical placement of domain controllers is also an important consideration:

  • Central vs distributed: Centralized DCs work for single-site environments, but distributed DCs are better for multi-site networks.
  • Site coverage: Ensure each Active Directory site has at least one local DC for optimal authentication and traffic flow.
  • Physical security: DCs should be in physically secure areas to prevent direct tampering with the AD database.
  • Network location: Placing DCs near the center of network topology can improve replication efficiency.

As a general rule, domain controllers should be distributed geographically close to concentrations of users and resources for the best performance and redundancy.

Virtual vs. physical domain controllers

Domain controllers can be deployed on both physical servers and virtual machines. Considerations for each option:

Virtual DCs

  • Lower hardware costs by consolidating DCs on shared hosts.
  • Easier to provision, clone, and scale up additional DCs.
  • Provides flexibility for DC mobility, failover, and dynamic resource allocation.
  • Requires sufficient host resources and prevents oversubscription.
  • Avoid risks from VM snapshots and migrations causing USN rollbacks.

Physical DCs

  • Avoids hardware contention for resources like CPU, memory, and disk.
  • Prevents VM sprawl and host resource constraints.
  • May provide better performance for high load environments.
  • Hardware costs are higher due to dedicated servers.
  • More difficult to rapidly provision new DCs as needed.

For most environments, a mix of virtual and physical DCs can provide a good balance of flexibility, performance, and costs.

FSMO role placement

FSMO (flexible single master operations) roles are key functions performed by specific domain controllers:

  • Schema Master – Controls schema changes and modifications.
  • Domain Naming Master – Manages additions/removals of domains in forest.
  • RID Master – Issues unique IDs for user/computer objects.
  • PDC Emulator – Acts as primary domain controller for legacy systems.
  • Infrastructure Master – Updates references from objects moved between DCs.

FSMO roles are often placed on dedicated domain controllers for stability. This may influence the number of DCs if additional servers are needed to host these roles separately.

Trust relationships

If the Active Directory domain has external trusts to other domains, forest, or third-party directories, additional domain controllers may be needed to manage trust validation and authentication requests.

Bidirectional trusts to partner organizations can increase login traffic and put more demand on DCs to resolve identities.

Read-only domain controllers

Read-only domain controllers (RODCs) hold read-only copies of AD and can help offload authentication requests from writable DCs. RODCs may be useful for:

  • Handling logins at branch offices and remote locations.
  • Improving security in lower trust environments like conference rooms or partner sites.
  • Scaling up logins for large user populations without adding writable DCs.

RODCs don’t perform full AD replication, so high numbers can be deployed without increasing network overhead. The optimal number depends on branch office sizes, network connectivity, and security considerations.

Migrating NT4 domains

Migrating from Windows NT4 domains to Active Directory also influences DC planning. NT4 used primary and backup domain controllers (PDC/BDC):

  • An AD PDC emulator FSMO role holder replaces the NT4 PDC.
  • NT4 BDCs should be migrated to AD member servers or removed from domains.
  • Additional AD DCs are needed for redundancy and performance.

For large networks, aim for parity in the number of NT BDCs converted to AD DCs.

Sizing recommendations

Taking the key factors above into account, here are some general recommendations for sizing the number of domain controllers:

  • In most cases, start with at least 2 or 3 DCs for redundancy.
  • Depending on scale, plan for 2-5 DCs per site/location.
  • Target 150-200 users/devices per DC, with lower ratios for higher SLAs.
  • Convert NT4 BDCs to AD DCs at a 1:1 ratio.
  • Add more DCs if needed to handle FSMO roles separately.
  • Deploy additional dedicated RODCs for remote offices and high-login apps.
  • Aim for 60-70% resource utilization on DCs during peak times.

Also be prepared to adjust the number of DCs by monitoring operational usage, performance, replication traffic, and infrastructure growth over time.

Conclusion

Determining how many domain controllers to deploy depends on several environmental factors. While there are general guidelines and capacity planning considerations, the ideal number can vary significantly between organizations. The key is to start with a reasonable number for redundancy, monitor performance and activity, and scale up or down accordingly based on actual production workloads and growth.

By following best practices for placement, roles, virtualization, and capacity planning – while also allowing room for adjustments based on real-world experience – companies can architect an Active Directory infrastructure with the right number of domain controllers to meet their needs.

Leave a Comment