How to Promote Windows Server 2025 to an Active Directory Domain Controller

In short

To promote Windows Server 2025 to an Active Directory domain controller, start with a fresh dedicated server, set the final hostname, use stable private addressing, and make sure DNS is planned for Active Directory rather than public resolvers. Install the AD DS role, create the new forest with Install-ADDSForest, set and protect the DSRM password, reboot, then verify AD DS, DNS, SYSVOL, NETLOGON, and dcdiag before joining production systems.

For a new production forest, use a DNS namespace based on a domain you control, such as ad.example.com, rather than creating a new .local namespace. For production, plan at least two domain controllers, private connectivity, system-state backups, and tested recovery.

Raff Technologies originally tested the first-DC workflow on Windows Server 2025 on June 9, 2026. This September refresh preserves that lab evidence while updating the production domain-naming, functional-level, DNS, backup, and recovery guidance.

Windows Server 2025 domain controller setup at a glance

The clean first-domain-controller path is:

Fresh Windows Server 2025
→ rename server
→ confirm stable IP + AD DNS design
→ install AD DS
→ Install-ADDSForest
→ set DSRM password
→ reboot
→ verify AD DS + DNS + SYSVOL + NETLOGON
→ create test OU/user
→ run health checks

This guide covers the first domain controller in a new forest

You will build this:

Dedicated Windows Server 2025 VM
  → Hostname: DC01
  → AD DS role installed
  → New forest created
  → DNS installed during promotion
  → Server rebooted as domain controller
  → AD DS, DNS, Netlogon, SYSVOL, OU, and user verified

This guide does not fully cover production multi-DC replication topology, Active Directory Sites and Services design, RODC design, hybrid identity, or migration from an existing forest. If you already have a domain and need a second DC, use the additional-domain-controller path later in this article and then review Active Directory replication topology for 2-DC setups.

What we tested on Raff

The original lab used a fresh Raff Windows VM running Windows Server 2025 Datacenter Evaluation.

The lab verified the server baseline, hostname and IP/DNS pre-flight, AD DS role installation, local Administrator password requirement, Install-ADDSForest promotion, AD DS services after reboot, domain-controller verification, DNS zones, and the creation of a first OU and user.

The test used contoso.local because it was an isolated lab. Do not copy that namespace into a new production forest. Current Microsoft design guidance recommends using registered DNS names and does not recommend unregistered suffixes such as .local.

Use a dedicated VM for a domain controller

Do not promote a general-purpose Windows server to a domain controller if it already runs production workloads such as:

• IIS or public web applications;
• SQL Server;
• RDS Session Host;
• ERP or accounting software;
• user file sharing;
• business applications;
• third-party tools with broad privileges.

A domain controller is part of the identity and authentication foundation. Separating application workloads from AD DS reduces the security blast radius and makes patching, troubleshooting, backup, and recovery easier.

For sizing, avoid treating one lab specification as a universal production requirement. Directory size, DNS activity, authentication volume, Group Policy, replication, monitoring, backup activity, and failover capacity all matter. See Windows Server sizing by workload for a broader sizing process.

Choose the Active Directory DNS name before promotion

The DNS namespace is difficult to change later, so choose it deliberately before creating the forest.

For a new production forest, prefer a namespace based on a domain your organization controls, for example:

ad.example.com
corp.example.com
ds.example.com

Avoid new single-label domains such as:

company
contoso

Also avoid copying the lab-only .local pattern into a new production design. Microsoft recommends registered DNS names for Active Directory namespaces because registered names are globally unique.

The remainder of the production-oriented examples in this guide use:

ad.example.com

The screenshots continue to show the original contoso.local test environment so the historical lab evidence remains unchanged.

Plan the Windows Server 2025 functional level before promotion

Windows Server 2025 introduces a Windows Server 2025 domain and forest functional level. Functional levels determine which domain-controller operating-system versions can participate and which AD DS features are available.

The compatibility decision is important:

Do not raise a production forest to Windows Server 2025 merely because the first new DC runs Server 2025. Once the environment needs older supported DC versions, the 2025 functional level is not compatible with them.

For a clean new Server 2025-only forest, the simplest promotion command can let the current AD DS deployment workflow select supported defaults. If your design requires explicit functional levels, choose them deliberately after confirming the planned DC operating-system mix.

What you'll need

Before starting, prepare:

• a fresh dedicated Windows Server 2025 or Windows Server 2022 VM;
• local Administrator access;
• a final hostname such as DC01;
• stable private IP addressing where possible;
• an Active Directory DNS namespace chosen before promotion;
• a strong local Administrator password;
• a strong DSRM password stored outside the server;
• private networking or VPN for AD traffic;
• a second-DC plan for production;
• an AD-aware backup and recovery plan.

If you are building this on Raff, deploy the Windows VM first and keep domain services on a private network rather than exposing AD ports publicly.

Step 1 — Confirm the Windows Server baseline

Run PowerShell as Administrator:

Get-ComputerInfo | Select-Object `
    WindowsProductName, WindowsVersion, OsBuildNumber, `
    CsNumberOfLogicalProcessors, CsTotalPhysicalMemory

hostname

Record the Windows version, current hostname, CPU, memory, network configuration, and any pending reboot before making the server a DC.

Do not promote a server until its final hostname is set.

Step 2 — Rename the server and verify IP/DNS

Rename the server before promotion:

Rename-Computer -NewName "DC01" -Restart

After reboot, reconnect and verify the hostname and network configuration.

$adapter = (Get-NetAdapter | Where-Object Status -eq 'Up').Name

hostname

Get-NetIPAddress -InterfaceAlias $adapter -AddressFamily IPv4 |
    Select-Object InterfaceAlias, IPAddress, PrefixLength, AddressState

Get-DnsClientServerAddress -InterfaceAlias $adapter -AddressFamily IPv4

For a first DC in a new forest, the pre-promotion DNS state depends on the surrounding network. After AD-integrated DNS is installed, domain controllers and domain members must use DNS servers that can resolve the AD DNS zone. Do not configure DCs or domain members to use public resolvers such as 8.8.8.8 or 1.1.1.1 as their AD DNS servers. Configure external name resolution through DNS forwarders instead.

Step 3 — Install Active Directory Domain Services

Install the AD DS role and management tools:

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

Verify it:

Get-WindowsFeature -Name AD-Domain-Services

Installing the role does not make the server a domain controller. Promotion happens with the AD DS deployment cmdlets in the next step.

Step 4 — Verify the local Administrator account is protected

Before a new-forest promotion, verify the local Administrator account requires a password:

net user Administrator

Look for:

Password required               Yes

If needed:

net user Administrator /passwordreq:yes

Then set a unique strong password through your normal privileged-access process. Avoid putting production credentials directly into shell history, scripts, tickets, or documentation.

Step 5 — Promote Windows Server 2025 to the first domain controller

For a brand-new forest, use Install-ADDSForest.

A production-style example is:

Install-ADDSForest `
    -DomainName "ad.example.com" `
    -DomainNetbiosName "EXAMPLE" `
    -InstallDns `
    -Force

PowerShell securely prompts for the SafeModeAdministratorPassword, also called the DSRM password.

Microsoft's current AD DS deployment guidance installs DNS by default for Install-ADDSForest; keeping -InstallDns here makes the intended result explicit.

The screenshot shows the original lab command and contoso.local test namespace. For a new production forest, use the registered namespace planned earlier.

Explicit functional levels are optional but must match your DC plan

If you deliberately specify -DomainMode or -ForestMode, do not blindly copy an old WinThreshold example. Windows Server 2025 has its own functional level, while Windows Server 2016 remains the newest functional level that supports Server 2016, 2019, and 2022 DCs alongside Server 2025.

After promotion, verify the actual levels:

Get-ADDomain | Select-Object DNSRoot, DomainMode
Get-ADForest | Select-Object RootDomain, ForestMode

Store the DSRM password securely. It is a recovery credential and should not depend on access to the failed DC itself.

Step 6 — Sign in after the reboot

After promotion and reboot, sign in using the new domain, for example:

EXAMPLE\Administrator

or:

[email protected]

The first DC in a new forest holds the initial domain Administrator context and the FSMO roles for that new forest/domain.

Step 7 — Verify AD DS, DNS, and Netlogon services

Run:

Get-Service -Name "NTDS","ADWS","DNS","Netlogon" |
    Format-Table Name, Status

Expected state is Running for the services required by this deployment.

Service state is only one check. Continue with directory, DNS, SYSVOL, and diagnostic verification.

Step 8 — Verify the domain controller and functional levels

Get-ADDomain | Select-Object `
    DNSRoot, NetBIOSName, DomainMode, `
    PDCEmulator, RIDMaster, InfrastructureMaster

Get-ADForest | Select-Object RootDomain, ForestMode, SchemaMaster, DomainNamingMaster

Get-ADDomainController -Filter * |
    Select-Object HostName, Domain, Forest, Site, IsGlobalCatalog

For the first DC, confirm:

• the expected DNS domain and NetBIOS name;
• the intended domain and forest functional levels;
• DC01 appears as a domain controller;
• the Global Catalog is available;
• FSMO role holders are known and documented.

Step 9 — Verify Active Directory DNS

Check the zones:

Get-DnsServerZone |
    Format-Table ZoneName, ZoneType, IsDsIntegrated, IsReverseLookupZone

For ad.example.com, expect an AD-integrated domain zone plus the forest-wide _msdcs zone.

Then check domain-controller locator records:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.example.com
Resolve-DnsName -Type SRV _kerberos._tcp.ad.example.com

If these records cannot be resolved from the DNS server used by domain members, fix DNS before joining clients.

Step 10 — Create a test OU and user

Create an Organizational Unit:

New-ADOrganizationalUnit `
    -Name "Accounting" `
    -Path "DC=ad,DC=example,DC=com"

Create a test user without embedding the password in the command history:

$securePassword = Read-Host "Initial password" -AsSecureString

New-ADUser -Name "Jane Doe" `
    -GivenName "Jane" `
    -Surname "Doe" `
    -SamAccountName "jane.doe" `
    -UserPrincipalName "[email protected]" `
    -Path "OU=Accounting,DC=ad,DC=example,DC=com" `
    -AccountPassword $securePassword `
    -Enabled $true

Verify:

Get-ADOrganizationalUnit -Filter "Name -eq 'Accounting'" |
    Select-Object Name, DistinguishedName

Get-ADUser -Identity "jane.doe" |
    Select-Object Name, SamAccountName, UserPrincipalName, Enabled

The screenshot preserves the original contoso.local lab. The production examples above use ad.example.com.

Step 11 — Verify SYSVOL and NETLOGON

Run:

net share

Confirm these shares exist:

SYSVOL
NETLOGON

SYSVOL carries Group Policy and logon-script data. A new DC that does not expose the expected shares is not ready for normal domain use.

Step 12 — Run DCDIAG and DNS diagnostics

Run:

dcdiag

For a DNS-focused check:

dcdiag /test:dns /v

Also confirm DC discovery:

nltest /dclist:ad.example.com
nltest /dsgetsite

Investigate repeated DNS, advertising, service, SYSVOL, or connectivity failures before adding production members.

Add a Windows Server 2025 DC to an existing domain

If a domain already exists, do not use Install-ADDSForest. Use Install-ADDSDomainController.

Before promotion, confirm:

• the existing domain functional level is at least Windows Server 2016 for a Server 2025 DC;
• the server uses existing AD DNS;
• network and private connectivity to existing DCs work;
• time synchronization is healthy;
• replication is healthy;
• credentials have the required privileges;
• the new hostname is unique;
• the server is not hosting unrelated production roles.

Example:

$cred = Get-Credential

Install-ADDSDomainController `
    -DomainName "ad.example.com" `
    -InstallDns `
    -Credential $cred `
    -Force

After reboot, verify replication with:

repadmin /replsummary
repadmin /showrepl

Then review Active Directory replication topology for 2-DC setups.

Domain controllers must use Active Directory-aware DNS

Active Directory depends on DNS for locating LDAP, Kerberos, Global Catalog, and other domain services.

For a multi-DC environment, every DC and domain member should use DNS servers authoritative for the AD zone. Exact preferred/alternate ordering can vary by topology and promotion stage; the invariant is that AD clients must not bypass AD DNS by pointing directly at public recursive resolvers.

For internet lookups, configure forwarders on the DNS servers rather than setting public resolvers on the domain member's NIC.

When troubleshooting authentication, replication, Group Policy, or domain joins, check DNS before assuming AD DS itself is broken.

Do not expose Active Directory ports to the public internet

AD DS uses multiple protocols, including DNS, Kerberos, LDAP, SMB, RPC Endpoint Mapper, Global Catalog, and dynamic RPC ports. Modern Windows commonly uses the dynamic RPC range:

49152-65535

That wide service surface is one reason domain traffic belongs on trusted private networking, VPN, or another controlled internal path.

Do not make a cloud DC reachable by opening LDAP, Kerberos, SMB, DNS, and RPC broadly to the internet.

Production Active Directory should have at least two domain controllers

A one-DC setup is appropriate for a lab and can be acceptable for temporary testing. It is a single failure point for production identity and AD-integrated DNS.

A small production topology is usually:

Private network
├── DC01
│   ├── AD DS
│   ├── DNS
│   ├── Global Catalog
│   └── FSMO roles
└── DC02
    ├── AD DS
    ├── DNS
    ├── Global Catalog
    └── replication partner

If both DCs are in one low-latency private network, a single AD site is usually sufficient. If they are in different locations or network subnets, plan Sites, Subnets, and Site Links instead of creating topology by guesswork.

System-state backup is the recovery foundation for a domain controller

Replication is not a backup. Deleting an OU, breaking Group Policy, damaging DNS data, or making an administrative mistake can replicate to other DCs.

Microsoft's domain-controller recovery guidance requires regular system-state backups for supported disaster-recovery scenarios. System state contains Active Directory data and logs, the registry, SYSVOL, and other operating-system state required for AD recovery.

Plan:

• regular system-state backups using an AD-compatible backup workflow;
• backup copies protected from the live DC;
• documented DSRM access;
• restore testing;
• Active Directory Recycle Bin when appropriate;
• recovery procedures for a failed DC and FSMO roles;
• VM-level recovery points as an additional infrastructure control, not the only AD backup.

Modern virtualization includes VM-Generation ID safeguards that help AD DS detect supported snapshot restores and avoid older USN-reuse problems. That does not turn arbitrary VM snapshots into an Active Directory backup strategy. Use system-state backup and documented AD recovery procedures.

Active Directory Recycle Bin is useful but not a backup

Active Directory Recycle Bin can simplify recovery of accidentally deleted AD objects, but it is not enabled by default and enabling it is a forest-wide design decision. It does not replace system-state backup, multi-DC redundancy, or tested disaster recovery.

Common domain-controller setup mistakes

Creating a new production .local forest

The original Raff lab used contoso.local, but Microsoft does not recommend unregistered suffixes such as .local for new Active Directory namespaces. Use a registered DNS namespace or subdomain you control.

Hardcoding an old functional level

Windows Server 2025 introduces its own domain and forest functional level. Choose the highest level your planned DC operating-system mix supports; do not blindly reuse an old WinThreshold command from a tutorial.

Promoting before renaming the server

Set the final hostname before promotion. The DC name becomes part of the directory and DNS design.

Pointing domain members at public DNS

Domain members need AD-aware DNS to find domain services. Use DNS forwarders for external resolution instead of bypassing AD DNS.

Mixing IIS, SQL Server, RDS, or ERP with AD DS

Keep domain controllers focused on identity infrastructure. Role separation improves security and recovery.

Losing the DSRM password

Store DSRM credentials in a secure system accessible during an AD outage.

Opening AD ports publicly

Use private networking or VPN. Active Directory is not a single-port service.

Treating a second DC as a backup

Replication improves availability, but it also replicates unwanted changes. You still need recoverable backups.

Treating a VM snapshot as the only DC backup

Virtualization safeguards help with safe restore behavior, but Microsoft still requires an AD-aware recovery plan and regular system-state backup.

What Raff recommends for Active Directory on Windows VMs

For a small production environment:

1. Use dedicated Windows VMs for the domain controllers.
2. Choose a registered production DNS namespace before promotion.
3. Set the final hostname and stable private addressing first.
4. Keep DC and domain-member DNS pointed at AD DNS servers.
5. Select functional levels around the DC versions the environment must support.
6. Keep AD traffic on private networking or VPN.
7. Run at least two DCs for production.
8. Verify AD DS, DNS, SYSVOL, NETLOGON, dcdiag, and replication before relying on the domain.
9. Use Windows LAPS for managed local-administrator passwords on member systems where appropriate.
10. Use focused Group Policy rather than unmanaged per-server configuration.
11. Maintain system-state backups and test recovery.
12. Keep application, SQL Server, and RDS workloads off domain controllers.

For the next steps, use the 2-DC replication topology guide, Group Policy setup guide, and Windows LAPS deployment guide.

Tested on Raff

Original lab: Raff Windows VM, Windows Server 2025 Datacenter Evaluation, first domain controller of the contoso.local test forest, June 9, 2026, by Serdar Tekin. The lab verified AD DS installation, local Administrator password requirements, Install-ADDSForest, reboot, AD DS/DNS/Netlogon/ADWS services, domain-controller status, DNS zones, and creation of an Accounting OU and Jane Doe test user.

Validation scope — September 10, 2026: Production domain naming, Windows Server 2025 functional-level interoperability, Install-ADDSForest behavior, DNS design, virtualized-DC recovery, and system-state backup guidance were revalidated against current Microsoft documentation. No new Raff lab test is claimed for this refresh.

What's next

• Connect to a Windows VPS via RDP
• Active Directory Replication Topology for 2-DC Setups
• Active Directory Group Policy Setup
• Windows LAPS on Windows Server 2025
• Windows Server Hardening Checklist
• Windows Server Sizing by Workload
• Raff Windows VM

Sources

• Microsoft Learn — Active Directory Domain Services overview: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview
• Microsoft Learn — Install Active Directory Domain Services: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/install-active-directory-domain-services--level-100-
• Microsoft Learn — Active Directory Domain Services functional levels: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels
• Microsoft Learn — Raise domain and forest functional levels: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/raise-domain-forest-functional-levels
• Microsoft Learn — Select the forest root domain: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/selecting-the-forest-root-domain
• Microsoft Learn — Restore a virtualized domain controller: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/virtual-dc/restore-virtualized-domain-controller
• Microsoft Learn — Virtualized domain controller architecture: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/virtualized-domain-controller-architecture
• Microsoft Learn — Windows service and network port requirements: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements
• Microsoft Learn — Active Directory replication concepts: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts
• Sources revalidated: 2026-09-10