Promote a Windows VPS to an Active Directory Domain Controller

Promote a Windows VPS to a domain controller only when it is a fresh, dedicated server. The clean workflow is: rename the server, verify stable IP and DNS settings, install the Active Directory Domain Services role, run Install-ADDSForest for a new forest, set a strong DSRM password, reboot, then verify AD DS, DNS, Netlogon, SYSVOL, domain controller status, and basic directory operations.

Quick verdict

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

What this guide covers

This guide demonstrates the first domain controller in a new forest path.

You will build this:

Fresh Windows Server VPS
  -> Hostname: DC01
  -> AD DS role installed
  -> New forest created with Install-ADDSForest
  -> 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, site design, RODC design, hybrid AD, or migration from an existing on-prem domain. Those require additional planning.

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 Windows server to a domain controller if it already runs production workloads such as:

• IIS
• SQL Server
• RDS Session Host
• ERP software
• accounting software
• public web apps
• file sharing for users
• business applications
• backup agents with broad access
• third-party tools you do not fully control

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

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

For production, use at least two domain controllers when possible.

Production topology before you start

For a lab, one domain controller is enough.

For production, one DC is a risk.

A practical production design is:

Private network
  |-- DC01
  |   |-- AD DS
  |   |-- DNS
  |   |-- Global Catalog
  |   `-- FSMO roles
  |
  `-- DC02
      |-- AD DS
      |-- DNS
      |-- Global Catalog
      `-- replication partner

If both DCs are in the same private network and location, keep the design simple with one AD site.

If one DC is in the cloud and another is in an office or another region, plan AD Sites, Subnets, and Site Links so clients find the right domain controller and replication follows the right path.

Domain naming note

The lab domain in this article uses:

contoso.local

That is fine for a controlled tutorial.

For production, choose your domain name carefully. Many teams use a subdomain of a domain they own, such as:

ad.example.com
corp.example.com
internal.example.com

Avoid single-label domain names such as:

contoso
company
localdomain

They create unnecessary DNS and compatibility problems.

What you'll need

Before starting, prepare:

• Fresh Raff Windows VPS or similar Windows Server VPS
• Windows Server 2022 or Windows Server 2025
• Local Administrator access
• Stable private IP configuration where possible
• Meaningful hostname, such as DC01
• Strong local Administrator password
• Strong DSRM password
• Private networking or VPN for domain traffic
• 30-45 minutes including reboot
• A second DC plan if this will become production

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

For production, size based on users, sites, replication design, DNS usage, monitoring, backups, redundancy, and the number of domain-joined systems.

Step 1 - Confirm the test environment

Start with a fresh Windows Server VM.

Run PowerShell as Administrator:

cls
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:

Rename-Computer -NewName "DC01" -Restart

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

Useful checks:

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

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

Verify the role:

Get-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 can fail.

Verify it:

net user Administrator

Look for:

Password required               Yes

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

net user Administrator /passwordreq:yes

Then set a strong password:

net 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:

contoso.local

Run:

Install-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:

SafeModeAdministratorPassword

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:

CONTOSO\Administrator

Use the Administrator password you configured before promotion.

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

If RDP does not accept the short form, try:

contoso.local\Administrator

or use the domain selector from the Windows sign-in screen.

Step 7 - Verify AD DS services

Open PowerShell as Administrator and run:

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

Expected result:

NTDS      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:

Get-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
• FSMO roles held by the first DC

At this point, the new forest is operational.

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

First, verify DNS zones:

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

You should see zones such as:

contoso.local
_msdcs.contoso.local

Then create an Organizational Unit:

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

If the OU already exists, verify it instead:

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

Create a test user:

$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=contoso,DC=local" `
    -AccountPassword $securePassword `
    -Enabled $true

Verify the OU and user:

Get-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.

Step 10 - Run final health checks

Before calling the setup complete, run a few simple health checks.

Confirm SYSVOL and NETLOGON

net share

Look for:

SYSVOL
NETLOGON

These shares are important for Group Policy and logon scripts.

Run DCDIAG

dcdiag

For a clean new lab DC, the main tests should pass.

If you see DNS warnings, investigate them before joining clients.

Confirm the DC list

nltest /dclist:contoso.local

Expected result:

DC01.contoso.local

Confirm the site

nltest /dsgetsite

In a one-DC lab, the site will usually be:

Default-First-Site-Name

You can rename this later in Active Directory Sites and Services if the environment becomes production.

Additional DC path for existing domains

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

Use Install-ADDSDomainController instead.

Example:

$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
• firewall rules allow required AD traffic
• the new DC name is unique
• the server is not already running other production roles

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.

Basic firewall and port warning

Active Directory is not a single-port service.

Domain controllers may need DNS, Kerberos, LDAP, SMB, RPC Endpoint Mapper, and dynamic RPC port access between domain members and DCs.

For modern Windows Server environments, dynamic RPC commonly uses:

49152-65535

That is one reason AD traffic should live on a private network, VPN, or trusted internal path.

Do not try to make AD work by opening broad public firewall access.

Backups for domain controllers

Replication is not a backup.

If you accidentally delete an OU, break DNS, damage Group Policy, or remove users, that change can replicate.

For production, plan:

• system state backups
• VM-level backups or snapshots
• restore testing
• Active Directory Recycle Bin if appropriate
• documented FSMO transfer or seizure plan
• metadata cleanup process for failed DCs
• backup access control

Snapshots are useful before risky changes.

Backups are required for recovery.

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, RDS, or ERP

Domain controllers should be dedicated. Mixing roles increases security and recovery 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, DNS, or dynamic RPC ports to the public internet unless you have a very specific and secured architecture.

Treating replication as backup

Replication copies both good and bad changes. Use backups and test restores.

Not checking SYSVOL and NETLOGON

A promoted DC is not fully usable for domain operations if SYSVOL and NETLOGON are missing.

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. Verify SYSVOL and NETLOGON.
9. Create test OU/user objects to confirm AD works.
10. Use at least two DCs for production.
11. Place DC-to-DC traffic on private networking or VPN.
12. Do not expose AD services directly to the public internet.
13. Plan backups and recovery before joining production clients.

For most SMB production environments, Active Directory should be part of a broader private 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
• Active Directory replication topology for 2-DC setups - plan the second DC before production
• 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 - Active Directory Domain Services overview
• Microsoft Learn - Install-ADDSForest
• Microsoft Learn - Install-ADDSDomainController
• Microsoft Learn - Service overview and network port requirements for Windows
• Microsoft Learn - Active Directory replication concepts
• Raff - Windows VM
• Date last verified: 2026-07-07