How to Install and Configure Active Directory Domain Services on Windows Server 2022

Standing up the first domain controller is one of those tasks that looks like a long wizard but is really just a few decisions made in the right order. Get the prerequisites right — name, IP, functional level — and the promotion itself is almost boring. Get them wrong and you’ll be renaming a DC or fixing DNS a week later, which is far more painful than doing it properly the first time.

This guide walks through installing the Active Directory Domain Services (AD DS) role on Windows Server 2022 and promoting the server to the first domain controller in a brand-new forest. You’ll see both the Server Manager path and the PowerShell equivalent, because the GUI is easier to learn from and PowerShell is what you’ll actually script later. We finish with the verification steps that tell you the DC is genuinely healthy, not just “installed”.

Before you start: prerequisites that matter#

A domain controller is fussier about its host configuration than a member server. Two settings cause most first-day problems: the computer name and the IP address. Both are hard to change cleanly after promotion, so fix them first.

Pick the domain name carefully — you live with it for the life of the forest. Use a domain you control, typically a subdomain of your public domain such as ad.example.com or corp.example.com. Avoid a single-label name like contoso with no suffix, and don’t reuse your live public DNS zone (example.com) as the internal AD name unless you understand the split-brain DNS work that creates.

For the very first DC in a new forest there’s a chicken-and-egg situation with DNS: the DNS server you want to use doesn’t exist yet. That’s fine. Point the adapter’s preferred DNS at the loopback address (127.0.0.1) or at the server’s own static IP before promotion, and let the wizard install DNS for you. Once a second DC exists, you’ll adjust each DC to point at a partner first and itself second — covered in our guide to the best DNS settings for domain controllers.

Step 1: Install the AD DS role#

You can add the role through Server Manager or with one PowerShell command. The role install only stages the binaries — it does not make the server a domain controller. Promotion is a separate step.

Option A: Server Manager#

1. Open Server Manager → Manage → Add Roles and Features.
2. Choose Role-based or feature-based installation.
3. Select your local server from the server pool.
4. On the Server Roles page, tick Active Directory Domain Services. When prompted, accept the additional management tools (the AD DS and AD LDS Tools).
5. Click through Features, read the AD DS info page, then Install.

Leave the box that says Restart the destination server automatically unticked — the role install itself doesn’t need a reboot.

Option B: PowerShell (faster, and required on Server Core)#

One line installs the role and its management tools:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

This is the only practical option on Server Core, and it’s the one to use if you’re building DCs at any scale. When it completes you’ll see Success and an exit code; no reboot is required yet.

Step 2: Promote the server to a domain controller#

Promotion (dcpromo in spirit, though that command is long gone) is where the server actually becomes a DC and your forest is born.

Promote with Server Manager#

After the role installs, Server Manager shows a yellow notification flag with Promote this server to a domain controller. Click it to launch the Active Directory Domain Services Configuration Wizard.

1. Deployment configuration — choose Add a new forest and type your root domain name, e.g. ad.example.com.
2. Domain controller options — set the forest and domain functional levels (see the next section), keep DNS server and Global Catalog ticked, and enter a DSRM password.
3. DNS options — you’ll likely see a warning about DNS delegation. For the first DC in a new forest this is expected and safe to ignore.
4. Additional options — confirm or set the NetBIOS name (the wizard suggests one from your FQDN).
5. Paths — accept the defaults for the database, logs, and SYSVOL unless you have a dedicated volume.
6. Review and run the prerequisites check. Fix anything flagged as an error (warnings about DNS delegation and cryptography defaults are normal).
7. Click Install. The server reboots automatically when promotion finishes.

Promote with PowerShell#

The Install-ADDSForest cmdlet does the same job and is easy to read. This example creates a new forest at the Windows Server 2016 functional level with DNS installed:

Install-ADDSForest `
  -DomainName "ad.example.com" `
  -DomainNetbiosName "AD" `
  -ForestMode "WinThreshold" `
  -DomainMode "WinThreshold" `
  -InstallDns:$true `
  -DatabasePath "C:\Windows\NTDS" `
  -LogPath "C:\Windows\NTDS" `
  -SysvolPath "C:\Windows\SYSVOL" `
  -Force:$true

WinThreshold is the identifier for the Windows Server 2016 functional level — there’s no newer one (more on that below). The cmdlet prompts for the DSRM (SafeMode) password unless you pass -SafeModeAdministratorPassword with a secure string. The server reboots on completion.

Step 3: Choosing forest and domain functional levels#

Functional levels gate which AD features are available and set the minimum OS allowed for domain controllers. Here’s the part that trips people up on a fresh 2022 build: Windows Server 2019 and 2022 did not introduce new functional levels. The highest level you can pick is Windows Server 2016.

For a brand-new forest with only Server 2022 DCs, set both forest and domain levels to Windows Server 2016. Only choose a lower level if you must add a domain controller running an older OS, and in that case set the level no higher than that oldest DC. You can always raise the level later after the old DCs are gone; lowering it is not generally supported.

Step 4: Verify the domain controller is healthy#

Promotion finishing without errors is a good sign, not a guarantee. Run a few checks before you trust the DC with real workloads.

First, confirm the directory services and DNS are up:

Get-Service NTDS, DNS, Netlogon, KDC | Format-Table Name, Status, StartType

Then run the built-in health diagnostic. dcdiag runs a battery of tests against the DC; on the first DC most should pass cleanly:

dcdiag /v
dcdiag /test:dns /v

Confirm the two shares that every working DC must publish exist. If SYSVOL and NETLOGON are missing, Group Policy and logon scripts won’t work — we cover that specific failure in SYSVOL and NETLOGON missing on a domain controller.

net share

Finally, query the directory itself to confirm the DC and forest exist as expected:

Get-ADDomainController -Identity $env:COMPUTERNAME |
  Format-List Name, Domain, Forest, IsGlobalCatalog, OperationMasterRoles
Get-ADDomain  | Format-List DNSRoot, NetBIOSName, DomainMode
Get-ADForest  | Format-List Name, ForestMode, GlobalCatalogs

On the first DC in a new forest, this server holds all five FSMO roles by default. That’s normal — you only think about moving them when you add more DCs or retire this one. When that day comes, see how to transfer or seize FSMO roles.

Common mistakes when building the first DC#

A few patterns show up again and again on fresh deployments:

• Leaving the adapter on DHCP. Covered above, but it’s the single most common cause of a DC that “worked yesterday” and now has broken DNS.
• Using the public domain name internally without a plan. Naming the AD domain example.com when that’s also your live website domain creates split-brain DNS. It’s workable but you must host every public record internally too. A subdomain like ad.example.com avoids the whole problem.
• Pointing the DC’s DNS at a public resolver. A DC must use internal AD DNS to find itself and its partners. A public resolver as the primary DNS server breaks domain location. Forwarders are the right place for external resolution.
• Forgetting the DSRM password. It’s only needed during a restore, which is exactly why it gets lost. Store it the moment you set it.
• Skipping verification. “The wizard said success” is not the same as a healthy DC. Run dcdiag and check the shares.

Adding a second domain controller#

One DC is a single point of failure. As soon as the first one is stable, add at least a second so authentication and DNS survive a reboot or hardware failure. The process is similar, with two differences: you choose Add a domain controller to an existing domain instead of creating a forest, and you point the new server’s DNS at the first DC before promotion. The PowerShell cmdlet changes to Install-ADDSDomainController:

Install-ADDSDomainController `
  -DomainName "ad.example.com" `
  -InstallDns:$true `
  -Credential (Get-Credential) `
  -Force:$true

With two DCs running, redo your DNS client settings so each DC points at the other DC first and itself second. That avoids the islanding problem where a DC can only resolve through itself.

Wrapping up#

Installing AD DS on Windows Server 2022 comes down to preparation more than clicking. Lock in the name and static IP, let the wizard install DNS for the first forest DC, set both functional levels to Windows Server 2016 (the highest 2022 offers), and keep the DSRM password somewhere safe. Then verify with dcdiag, confirm SYSVOL and NETLOGON, and don’t stop at a single DC — a second one is what turns a lab into something you can rely on.

Once the forest is up, the natural next steps are protecting it and keeping replication healthy: read up on forcing Active Directory replication and backing up and restoring AD system state before you put real users on it.