1.1 Deploying & Managing Domain Controllers On-Premises

Deploying & Managing Domain Controllers On-Premises

Active Directory Domain Services (AD DS) forms the identity and authentication backbone of hybrid enterprise infrastructures. This section covers the on-premises half of that job: promoting and demoting domain controllers on physical hardware and on-premises hypervisors, choosing forest and domain functional levels, automating deployment with the ADDSDeployment module, and deciding between Server Core and Desktop Experience. Domain controllers hosted on Azure IaaS virtual machines — including the disk-caching rules, static addressing requirements, and virtualized domain controller cloning — are covered separately in section 1.2.

---

1. AD DS Architecture & Deployment Prerequisites

Before promoting a Windows Server instance to a domain controller, specific infrastructure prerequisites must be satisfied to ensure directory stability and replication integrity.

+-----------------------------------------------------------------------------+
|                   AD DS PROMOTION PREREQUISITE CHECKLIST                    |
|                                                                             |
|   [1. IDENTITY & CREDENTIALS] ---> Enterprise Admins / Schema Admins for    |
|                                    Forest Root; Domain Admins for child/new |
|                                    replica domain controllers               |
|                                     |                                       |
|                                     v                                       |
|   [2. NETWORK & DNS]          ---> Static IP allocation, correct DNS client |
|                                    pointing to existing DC/DNS servers      |
|                                     |                                       |
|                                     v                                       |
|   [3. TIME SYNCHRONIZATION]   ---> Windows Time (W32Time) accuracy within  |
|                                    5 minutes (Kerberos max clock skew)      |
|                                     |                                       |
|                                     v                                       |
|   [4. BINARIES & ROLES]       ---> AD-Domain-Services role and RSAT tools    |
|                                    installed via Install-WindowsFeature     |
+-----------------------------------------------------------------------------+

Core Prerequisite Dimensions

• Administrative Privilege Delegation: Promoting the first domain controller in a new forest requires membership in the local server's Administrators group. Adding a new domain to an existing forest requires membership in Enterprise Admins. Modifying schema during preparation requires Schema Admins. Adding a replica DC to an existing domain requires Domain Admins in that target domain.
• Domain Name System (DNS) Architecture: AD DS depends fundamentally on DNS Service Location (SRV) resource records (e.g., _ldap._tcp.dc._msdcs.<DomainName>) to locate directory services. Before promoting a replica DC, its network adapter DNS client settings must point to an existing active AD DS DNS server—never to loopback (127.0.0.1) as the primary DNS during promotion.
• Time Synchronization (Kerberos v5): The Kerberos authentication protocol tolerates a default maximum clock skew of 5 minutes (300 seconds). If system clocks between domain controllers or authenticating clients drift beyond this threshold, ticket granting and directory replication fail catastrophically.

---

2. Forest and Domain Functional Levels (FFL & DFL)

Functional levels determine the available capabilities of an Active Directory forest or domain, as well as the minimum Windows Server operating system version that can host a domain controller.

+-----------------------------------------------------------------------------+
|                     FUNCTIONAL LEVEL PROGRESSION & FEATURES                 |
|                                                                             |
|   Windows Server 2012 R2 FFL/DFL                                            |
|   - Kerberos Armoring (FAST) & Protected Users Security Group               |
|   - Authentication Policies & Silos                                         |
|                             |                                               |
|                             v                                               |
|   Windows Server 2016 FFL/DFL                                               |
|   - Privileged Access Management (PAM) with Expiring Group Memberships      |
|   - NTLM fallback disabling across trust boundaries                         |
|                             |                                               |
|                             v                                               |
|   Windows Server 2025 FFL/DFL                                               |
|   - 32k Page Database Engine (Extensible Storage Engine optimization)       |
|   - NUMA-Aware Active Directory scalability                                 |
|   - Channel Binding & LDAP signature enforcement by default                 |
+-----------------------------------------------------------------------------+

Key Functional Level Mechanics:

1. Elevation Invariance: Forest and Domain Functional Levels can be raised using PowerShell cmdlets (Set-ADForestMode and Set-ADDomainMode), but they cannot be lowered below Windows Server 2008 R2. If raised to Windows Server 2016, all older domain controllers (e.g., Windows Server 2012 R2) must have been demoted prior to level elevation.
2. Dependency Hierarchy: The Forest Functional Level can never be higher than the lowest Domain Functional Level in any domain across the forest. Conversely, a domain's DFL can be equal to or higher than the FFL.
3. Privileged Access Management (PAM) Expiring Links: Introduced in Windows Server 2016 FFL, this feature enables time-to-live (TTL) memberships in administrative groups, allowing Just-In-Time (JIT) access without manual group pruning.

---

3. PowerShell Deployment Automation (ADDSDeployment Module)

Deploying domain controllers via GUI (Server Manager) has been superseded in enterprise environments by declarative, repeatable PowerShell automation using the ADDSDeployment module.

Primary Deployment Cmdlets

Automated Forest Root Promotion Script

# Install the AD DS role and management tools
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

# Configure SafeMode Administrator Password (DSRM)
$SecureDSRMPassword = ConvertTo-SecureString 'P@ssw0rd2026!Secure' -AsPlainText -Force

# Promote server to the Forest Root Domain Controller
Install-ADDSForest `
    -DomainName 'corp.contoso.com' `
    -DomainNetbiosName 'CORP' `
    -ForestMode 'WinThreshold' `
    -DomainMode 'WinThreshold' `
    -InstallDns:$true `
    -DatabasePath 'F:\NTDS' `
    -LogPath 'F:\NTDS' `
    -SysvolPath 'F:\SYSVOL' `
    -SafeModeAdministratorPassword $SecureDSRMPassword `
    -NoRebootOnCompletion:$false `
    -Force:$true

[!TIP] Parameter Deep Dive: WinThreshold: In PowerShell cmdlets such as Install-ADDSForest and Set-ADForestMode, the string value 'WinThreshold' or 'Windows2016Forest' specifies the Windows Server 2016 functional level. Windows Server 2019 and Windows Server 2022 operate at the Windows Server 2016 functional level baseline.

---

4. Server Core vs Desktop Experience for Domain Controllers

Microsoft strongly recommends deploying domain controllers using the Server Core installation option rather than Server with Desktop Experience.

+-----------------------------------------------------------------------------+
|                   SERVER CORE VS DESKTOP EXPERIENCE FOR DCs                 |
|                                                                             |
|   DIMENSION             SERVER CORE                  DESKTOP EXPERIENCE     |
|   --------------------+----------------------------+------------------------|
|   Attack Surface      | Minimal (No Shell, No IE,  | Large (GUI components, |
|                       | GDI32 restricted)          | explorer.exe, themes)  |
|   Patch Reboots       | ~60% fewer reboots required| Frequent patch cycles  |
|   Memory Footprint    | ~512 MB - 1 GB RAM idle    | ~2 GB - 3 GB RAM idle  |
|   Disk Consumption    | ~10 GB OS footprint        | ~28 GB OS footprint    |
|   Management Model    | Remote: WAC, RSAT, SSH,    | Local console or RDP   |
|                       | PowerShell Remoting        | Desktop sessions       |
+-----------------------------------------------------------------------------+

[!IMPORTANT] Headless DC Management Principle: Running Server Core eliminates local interactive desktop logons by administrators, enforcing the principle of tier-0 administrative isolation. All day-to-day administration must be conducted through remote management tools, including Windows Admin Center (WAC), Remote Server Administration Tools (RSAT), and PowerShell Remoting over WinRM/HTTPS.

---