Introduction to Active Directory Domain Services on Windows Server 2022
Active Directory Domain Services (AD DS) is the cornerstone of identity and access management in Windows environments. It provides a centralized, hierarchical directory that stores information about users, computers, groups, printers, and other network resources. On Windows Server 2022, AD DS benefits from improved security defaults, enhanced support for virtualization safeguards, and tighter integration with Azure Active Directory for hybrid scenarios. This tutorial walks through every major step of installing, configuring, and verifying an AD DS deployment from scratch.
Prerequisites Before Installing AD DS
Before promoting a server to a domain controller, several prerequisites must be met. The server must have a static IP address assigned — using DHCP for a domain controller is unsupported and will cause DNS and replication issues. You should also set a descriptive hostname before promotion, because renaming a domain controller after the fact is a multi-step procedure that risks AD database inconsistencies.
Open PowerShell as Administrator and set a static IP address:
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.1.10 -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1
After promotion the loopback address 127.0.0.1 will resolve to the locally running DNS service. Set the hostname if needed:
Rename-Computer -NewName "DC01" -Restart
Installing the AD DS Role
The Active Directory Domain Services role is not installed by default. Use the Install-WindowsFeature cmdlet to add it along with the management tools:
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools -IncludeAllSubFeature
This installs the AD DS binaries, the ADDSDeployment PowerShell module, Group Policy Management Console (GPMC), Active Directory Users and Computers (ADUC), AD Administrative Center, and related RSAT tools. The server does not yet become a domain controller — that happens during the promotion step. You can verify the role is installed:
Get-WindowsFeature -Name AD-Domain-Services
The output should show Install State as Installed.
Creating a New Forest with Install-ADDSForest
If this is the first domain controller in a brand-new environment, you create a new forest using the Install-ADDSForest cmdlet from the ADDSDeployment module. This cmdlet replaces the legacy dcpromo.exe wizard (removed in Windows Server 2012) and provides full scripting capability for automated deployments.
Install-ADDSForest `
-DomainName "corp.example.com" `
-DomainNetbiosName "CORP" `
-ForestMode "WinThreshold" `
-DomainMode "WinThreshold" `
-DatabasePath "C:WindowsNTDS" `
-SysvolPath "C:WindowsSYSVOL" `
-LogPath "C:WindowsNTDS" `
-InstallDns:$true `
-SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd!Secure" -AsPlainText -Force) `
-Force:$true
The -ForestMode and -DomainMode parameters set the functional levels. WinThreshold corresponds to Windows Server 2016 functional level, which is the highest explicitly named level available in Server 2022 (Server 2022 uses the same functional level value). The forest functional level determines which features are available across all domains in the forest, while the domain functional level controls features within a specific domain.
The -SafeModeAdministratorPassword is the Directory Services Restore Mode (DSRM) password — a critically important credential used when booting the DC into recovery mode. Store it securely. The server will reboot automatically after the promotion completes.
Understanding the AD DS Database: NTDS.dit, SYSVOL, and NETLOGON
After promotion, the AD DS database file NTDS.dit is stored at C:WindowsNTDS by default. This file is an ESE (Extensible Storage Engine) database that contains all directory objects — users, computers, groups, OUs, policies, and schema definitions. Alongside NTDS.dit you will find transaction log files (edb*.log) and a checkpoint file (edb.chk) that track which transactions have been committed.
The SYSVOL folder (default: C:WindowsSYSVOL) is a shared directory that is replicated to all domain controllers using DFS Replication (DFSR). It contains Group Policy templates, logon scripts, and other files that must be consistent across all DCs. The SYSVOL share is accessible via the UNC path \domainSYSVOL.
The NETLOGON share (\domainNETLOGON) is a subfolder within SYSVOL that stores logon scripts. Both SYSVOL and NETLOGON are exposed as SMB shares automatically upon DC promotion. You can verify these shares:
Get-SmbShare -Name SYSVOL
Get-SmbShare -Name NETLOGON
DNS Integration with AD DS
Active Directory relies heavily on DNS for service location. Domain controllers register SRV records that allow clients and other DCs to find services such as Kerberos (_kerberos._tcp), LDAP (_ldap._tcp), and the Global Catalog (_gc._tcp). When you install AD DS with -InstallDns:$true, a DNS server is configured automatically with a primary zone matching your domain name.
Verify that the critical AD DNS records are registered:
nslookup -type=SRV _ldap._tcp.corp.example.com
nslookup -type=SRV _kerberos._tcp.corp.example.com
You can also list all DNS zones to confirm the AD-integrated zone exists:
Get-DnsServerZone
AD-integrated DNS zones store their data in the AD DS database itself rather than text files, which provides replication, security (ACL-based updates), and fault tolerance automatically.
Verifying the AD Installation with PowerShell
Once the server reboots and you log back in, verify the forest and domain configuration using the ActiveDirectory module:
Import-Module ActiveDirectory
Get-ADForest
This returns the forest name, forest mode, root domain, all domains in the forest, global catalog servers, and the sites list. To inspect the domain:
Get-ADDomain
Output includes the domain name, NetBIOS name, domain mode, the PDC emulator, RID master, infrastructure master, and the default naming contexts. To check which server holds each FSMO role:
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Confirm the domain controller is advertising properly using netlogon:
nltest /dsgetdc:corp.example.com
Default Organizational Units and Containers
After creating a new domain, AD DS automatically creates several default Organizational Units (OUs) and containers. These include:
Builtin — A container (not an OU) that holds default local groups such as Administrators, Backup Operators, and Remote Desktop Users. Group Policy cannot be linked to Builtin.
Computers — The default container where new computer accounts are placed when a machine joins the domain without being pre-staged in a specific OU. Use the redircmp command to redirect this to a custom OU.
Domain Controllers — A genuine OU that holds all DC computer accounts. The Default Domain Controllers Policy GPO is linked here by default.
Users — A container that holds several default user accounts (Administrator, Guest, krbtgt) and default groups. Like Computers, it is a container rather than an OU, so GPOs cannot be linked directly to it. Use redirusr to redirect new user account creation.
To redirect new computer accounts to a dedicated OU:
New-ADOrganizationalUnit -Name "Workstations" -Path "DC=corp,DC=example,DC=com"
redircmp "OU=Workstations,DC=corp,DC=example,DC=com"
Using Active Directory Users and Computers (dsa.msc)
The graphical management console for AD DS is Active Directory Users and Computers, launched via dsa.msc. Open it from the Run dialog or Server Manager. The left pane shows the domain tree with OUs and containers. You can create users, groups, computers, and OUs by right-clicking any container.
To view all attributes for an object (the equivalent of the Attribute Editor), you must enable Advanced Features from the View menu. This exposes additional tabs on object properties, including the Attribute Editor which shows all LDAP attributes and their current values — useful for troubleshooting and advanced configuration.
To open dsa.msc from PowerShell:
Start-Process dsa.msc
Checking AD DS Service Health
The AD DS service runs as NTDS (NT Directory Service). Verify it is running:
Get-Service -Name NTDS | Select-Object Status, StartType
Use dcdiag for a comprehensive health check of the domain controller:
dcdiag /test:all /v
Key tests include Advertising (DC is advertising itself correctly), Replications (replication is healthy), Services (all required services are running), SysVolCheck (SYSVOL is shared and populated), and NetLogons (NETLOGON and SYSVOL are accessible). A healthy domain controller should pass all tests. Any failures should be investigated before adding more domain controllers or joining computers to the domain.
Additionally, check the event logs for AD-related events:
Get-EventLog -LogName "Directory Service" -Newest 20 | Format-Table TimeGenerated, EntryType, Message -AutoSize
Event IDs 1000, 1308, and 1864 in the Directory Service log are important indicators of replication health and should be investigated if present. With the domain controller installed, verified, and healthy, you now have a solid foundation for building your Active Directory environment on Windows Server 2022.