Promote a Windows VPS to a Domain Controller

In short

Promoting a Windows VPS to a domain controller is straightforward, but it should be done on a dedicated server. The clean workflow is: start with a fresh Windows Server VM, set a meaningful hostname, verify stable IP/DNS configuration, install the Active Directory Domain Services role, run Install-ADDSForest for a new forest, enter a strong DSRM password, reboot, then verify AD DS, DNS, Netlogon, and domain controller status.

Quick verdict

A domain controller is not just another Windows role. It becomes the identity foundation for the environment.

What we tested on Raff

We tested this walkthrough on a fresh Raff Windows VPS running Windows Server 2025 Datacenter Evaluation.

Test environment:

In this lab, we verified:

• 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 zone creation
• first OU and user creation

This guide demonstrates a new forest / first domain controller deployment. Adding a domain controller to an existing forest has different prerequisites and should be tested separately.

Important: use a dedicated VM

Do not promote a general-purpose server to a domain controller if it already runs production workloads such as IIS, SQL Server, RDS Session Host, file sharing for users, business applications, or public web apps.

A domain controller should be treated as a dedicated identity server.

Mixing roles creates security and maintenance risk. If one web app, SQL app, or RDS workload is compromised, the domain controller may also be exposed.

For production, use at least two DCs when possible.

What you'll need

• Fresh Raff Windows VPS
• Windows Server 2022 or Windows Server 2025
• Local Administrator access
• Stable IP configuration
• Meaningful hostname, such as DC01
• Strong local Administrator password
• Strong DSRM password
• 30-45 minutes including reboot

For a small lab, a 4 vCPU / 8 GB Windows VPS is enough.

For production, size based on users, sites, replication design, DNS usage, and redundancy requirements.

Step 1 - Confirm the test environment

Start with a fresh Windows Server VM.

Run PowerShell as Administrator:

powershellcls
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, CsNumberOfLogicalProcessors, CsTotalPhysicalMemory
Get-Service | Where-Object {$_.Name -in 'LanmanServer','Dnscache'} | Select-Object Name, Status, DisplayName
hostname

This records the baseline before AD DS promotion.

The important checks are:

Do not promote a server until the hostname is correct.

Step 2 - Set hostname and verify IP/DNS

Rename the server before promotion.

Example:

powershellRename-Computer -NewName "DC01" -Restart

After reboot, reconnect by RDP and verify hostname and IP configuration.

Useful checks:

powershell$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

Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'

For a private AD environment, the DC should use stable private IP addressing.

For a public VPS-only setup, be careful. Do not expose Active Directory services directly to the internet. Use private networking or VPN for domain traffic.

Step 3 - Install the AD DS role

Install Active Directory Domain Services and management tools:

powershellInstall-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Verify the role:

powershellGet-WindowsFeature -Name AD-Domain-Services

The AD DS role install alone does not make the server a domain controller. The promotion happens in the next step.

Step 4 - Make sure the local Administrator password is required

Before creating a new forest, the local Administrator account becomes the domain Administrator account.

If the local Administrator account does not require a password, promotion fails.

Verify it:

powershellnet user Administrator

Look for:

textPassword required               Yes

If needed, force the local Administrator account to require a password:

powershellnet user Administrator /passwordreq:yes

Then set a strong password:

powershellnet user Administrator "Replace-With-Your-Strong-Password"

For production, use a unique password stored in a password manager.

Step 5 - Promote to a new forest

For a brand-new AD environment, use Install-ADDSForest.

Example lab domain:

textcontoso.local

Run:

powershellInstall-ADDSForest `
    -DomainName "contoso.local" `
    -DomainNetbiosName "CONTOSO" `
    -ForestMode "WinThreshold" `
    -DomainMode "WinThreshold" `
    -InstallDns `
    -CreateDnsDelegation:$false `
    -DatabasePath "C:\Windows\NTDS" `
    -LogPath "C:\Windows\NTDS" `
    -SysvolPath "C:\Windows\SYSVOL" `
    -NoRebootOnCompletion:$false `
    -Force

PowerShell will ask for:

textSafeModeAdministratorPassword

This is the Directory Services Restore Mode, or DSRM, password.

Store the DSRM password securely. It is separate from normal domain login and is used for offline AD recovery.

After validation, the server installs the new forest, configures DNS, and reboots automatically.

Step 6 - After reboot, sign in to the domain

After reboot, sign in as:

textCONTOSO\Administrator

Use the Administrator password you configured before promotion.

The local Administrator account has become the domain Administrator account for the new forest.

Step 7 - Verify AD DS services

Open PowerShell as Administrator and run:

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

Expected result:

textNTDS      Running
ADWS      Running
DNS       Running
Netlogon  Running

These services confirm the server is operating as a domain controller with DNS and AD web services available.

Step 8 - Verify domain controller status

Run:

powershellGet-ADDomain | Select-Object Forest, DomainSID, NetBIOSName, PDCEmulator, RIDMaster, InfrastructureMaster

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

You should see:

• forest: contoso.local
• NetBIOS name: CONTOSO
• hostname: DC01.contoso.local
• server listed as a domain controller
• global catalog enabled

At this point, the new forest is operational.

Step 9 - Verify DNS zones and create the first OU/user

First, verify DNS zones:

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

You should see zones such as:

textcontoso.local
_msdcs.contoso.local

Then create an Organizational Unit:

powershellNew-ADOrganizationalUnit -Name "Accounting" -Path "DC=contoso,DC=local"

If the OU already exists, verify it instead:

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

Create a test user:

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

New-ADUser -Name "Jane Doe" -GivenName "Jane" -Surname "Doe" `
    -SamAccountName "jane.doe" `
    -UserPrincipalName "jane.doe@contoso.local" `
    -Path "OU=Accounting,DC=contoso,DC=local" `
    -AccountPassword $securePassword `
    -Enabled $true

Verify the OU and user:

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

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

This proves the domain is usable for basic directory operations.

Additional DC path for existing domains

If you already have an Active Directory domain, do not use Install-ADDSForest.

Use Install-ADDSDomainController instead.

Example:

powershell$cred = Get-Credential

Install-ADDSDomainController `
    -DomainName "contoso.local" `
    -InstallDns `
    -Credential $cred `
    -DatabasePath "C:\Windows\NTDS" `
    -LogPath "C:\Windows\NTDS" `
    -SysvolPath "C:\Windows\SYSVOL" `
    -NoRebootOnCompletion:$false `
    -Force

Before adding an additional DC, confirm:

• network reachability to the existing DC
• DNS points to the existing DC
• domain admin credentials work
• time is synchronized
• replication health is clean
• private connectivity exists between servers

This guide tested the first-DC / new-forest path only.

Production recommendations

A single DC is acceptable for a lab or simple test environment.

For production, plan for:

Do not expose domain controller services directly to the public internet.

Common mistakes

Promoting before renaming the server

The server name becomes part of AD metadata. Rename before promotion.

Skipping stable IP/DNS planning

Domain controllers need reliable IP and DNS configuration. AD depends heavily on DNS.

Using a server that already runs IIS, SQL, or RDS

Domain controllers should be dedicated. Mixing roles increases risk.

Forgetting the local Administrator password requirement

If the local Administrator account does not require a password, promotion can fail.

Losing the DSRM password

The DSRM password is needed for offline AD recovery. Store it securely.

Pointing DNS only to public resolvers

Domain members must use AD DNS to locate domain services. Public DNS alone breaks AD discovery.

Building a single DC for serious production

A single DC is a single point of failure. Use at least two DCs for production.

Opening AD ports to the internet

Do not expose LDAP, Kerberos, SMB, RPC, or DNS to the public internet unless you have a very specific and secured architecture.

What Raff recommends

For Active Directory on Windows VPS, Raff recommends:

1. Use a fresh dedicated Windows VPS for the domain controller.
2. Rename the server before promotion.
3. Use stable private IP addressing where possible.
4. Install only the AD DS/DNS roles needed for the DC.
5. Store the DSRM password securely.
6. Verify AD DS services after reboot.
7. Verify DNS zones and domain controller status.
8. Create test OU/user objects to confirm AD works.
9. Use at least two DCs for production.
10. Do not expose AD services directly to the public internet.

For most SMB production environments, Active Directory should be part of a broader network design, not a standalone public server.

Tested on

Tested on Raff Windows VPS, Windows Server 2025 Datacenter Evaluation, promoted as the first domain controller of the contoso.local forest, 2026-06-09. We installed the AD DS role, verified local Administrator password requirements, ran Install-ADDSForest, rebooted, verified AD DS/DNS/Netlogon/ADWS services, confirmed domain controller status, checked DNS zones, and created an Accounting OU with a Jane Doe test user. Tester: Serdar Tekin.

What's next

• Connect to a Windows VPS via RDP - connect to your server first
• Windows Server Hardening Checklist - secure the new domain controller
• Windows Update Strategy on Production Servers - patch domain controllers safely
• RDS CAL Licensing on Windows Server - understand licensing before adding RDS
• Raff Windows VPS - deploy a Windows Server VPS for Active Directory, DNS, IIS, SQL Server, and business apps

Sources

• Microsoft Learn - Install Active Directory Domain Services
• Microsoft Learn - Install-ADDSForest
• Microsoft Learn - Install-ADDSDomainController
• Microsoft Learn - Active Directory Domain Services overview
• Date last verified: 2026-06-09