Domain Controller Overview
Start course
1h 3m

Windows Active Directory Domain Services (AD DS) is a leading identity management solution for organizations of all sizes. At the core of Windows AD DS is the domain controller. The domain controller provides login services, group policies, domain naming services (DNS), and other identity management services for users and computers in a domain along with other enterprise management services.

In this course, we start by reviewing the Windows AD DS environment including forests and domains. Then we review considerations for deploying domain controllers in a virtualized environment, on-premises, and in Azure. Next, we look at use cases for deploying read-only domain controllers at locations where physical security cannot be guaranteed. Lastly, we examine flexible single master operations roles and how to locate and move them to support troubleshooting efforts.

Learning Objectives

  • Deploy and manage domain controllers on-premises
  • Deploy and manage domain controllers in Azure
  • Deploy read-only domain controllers (RODCs)
  • View, manage, and troubleshoot flexible single master operations (FSMO) roles

Intended Audience

  • System administrators with responsibilities for managing hybrid identities
  • Subject matter experts in configuring and managing Active Directory workload on-premises and in Azure
  • Anyone preparing for the Azure AZ-800 Administering Windows Server Hybrid Core Infrastructure exam



Now that we know what Active Directory Domain Services or Windows AD is, let's review steps to implement the service. And we'll start with an overview of Windows AD domain controllers. The Windows Server OS comes with many different roles and features available. For example, a Window Server can be a web server, file server, or print server. There's another role available called Active Directory Domain Services. This role installs the components required for the Windows Server to become a Windows AD domain controller.

When the active directory domain service is installed, we have the choice to create a new domain in a new forest, a new domain in an existing forest, or join an existing domain. Adding a domain controller to an existing domain, creates a multi-master replica of the domain partition. Each domain controller stores a read/ write copy of the directory partition. That copy is kept in sync with the other domain controllers in the domain. In general, it's best to have at least two domain controllers in a domain for high availability.

Windows AD was released with Server 2000 over 20 years ago. Windows AD functions today, very similar to how it did back then, but times have changed along with the security and identity needs of organizations. Over time, features have been added, removed, and updated to meet those demands. These changes are categorized as forest and domain functional levels and corresponds to major Windows Server OS releases. A functional level determines what features are supported in the forest and domain.

New Windows Server OS versions are backwards compatible with previous functional levels. So, for example, if the functional level is Server 2016, we can use Windows Server 2016, 2019, or 2022 as domain controller, but not Server 2012 R2. Functional levels can be upgraded to the highest version supported by all domain controllers. The functional level of a domain in a forest can be higher than the forest functional level, but the forest functional level cannot be higher than any domain functional levels in the forest.

The minimum requirements for Windows AD domain controllers in any environment, physical or virtual, is the same for installing Windows Server. 1.4 GHz 64-bit processor, 2GB of RAM, 32GB of disk space, and a one gig network adapter. This is minimal and although it may work, it won't work well. Capacity planning is required to accurately size hardware used as domain controllers. Microsoft has many resources available for planning capacity of domain controllers.

At a high level, a domain controller should have 40-60 KB per user for a database storage. There should be enough RAM to store the Active Directory database, as well as what's required for the base operating system and any other third-party application. 1 GB is sufficient for the network and each CPU core can handle 1000 concurrent users. There are some additional performance tuning requirements that should be considered. For the disks, keep the OS, logs, and Active Directory database on different volumes. This will keep the IOPS separate between the three and avoid disk contention.

Also Windows will try to disable write-caching for any disk that stores the database to prevent data corruption in the event the server shuts down unexpectedly, such as a power outage. Disable write-caching if enabled on any underlying storage systems. Supply enough RAM to load the database into memory, this will improve reads from the database. For both processor and network, plan for spikes in utilization. For example, plan for an increase in utilization as users log in at the start of the day. Having multiple domain controllers will also help process logins during times of peak activity.

There are some considerations for deploying domain controllers. First as stated previously, always have at least two for high availability. Domain controllers are critical for processing logins. If none are available, users won't be able to log in. Two domain controllers at a single location may be sufficient for some organizations, but many organizations have more complex multi-site networks. In those cases, it may be beneficial to keep a domain controller replica at each remote site. This will help process logins locally, improving performance for the users at the remote site, and providing AD services if a wiring connection goes down. If domain controllers are placed at remote sites, they need to be well connected. The domain controllers in a domain cannot replicate over the internet, they need site-to-site VPN or other land connections to facilitate replication.

Let's examine the specific requirements for deploying a domain controller next.


About the Author

Travis Roberts is a Cloud Infrastructure Architect at a Minneapolis consulting firm, a Microsoft MVP, MCT, and author. Travis has 20 years of IT experience in the legal, pharmaceutical, and marketing industries and has worked with IT hardware manufacturers and managed service providers. In addition, Travis has held numerous technical certifications throughout his career from Microsoft, VMware, Citrix, and Cisco.