Read Only Domain Controller (RODC) in Wundowa Server 2022
How to deploy a Read-Only Domain Controller for a branch office: prerequisites, site and subnet design, promotion with Server Manager or PowerShell, Password Replication Policy, verification and troubleshooting.
A domain controller you can afford to lose
A branch office with weak physical security should not hold every password in your forest. An RODC keeps a read-only copy of the directory and caches only the passwords you allow. The writable source in this lab is server.vmorecloud.com at 192.168.91.129.
Install-ADDSDomainController -ReadOnlyReplica, configuring the Password Replication Policy (PRP), verifying with repadmin, dcdiag and DNS SRV records, and fixing the common problems.One-way replication
The RODC only pulls changes from a writable DC. Nothing it holds can be replicated back, so a compromised branch cannot corrupt the forest.
Cache only what is needed
The PRP decides whose passwords reach the branch. Keep admins in the denied list.
Design the site first
A correct site, subnet and site link make clients find the RODC and the RODC find a writable partner.
Introduction, lab values and security rationale
A normal domain controller is writable and stores password hashes for every account in the domain. At a branch office that is a risk: a stolen or tampered server hands an attacker the whole directory. An RODC reduces that risk in four ways:
- Unidirectional replication: the RODC pulls from a writable DC and never replicates changes outward.
- Credential caching only on demand: passwords are stored on the RODC only for accounts that the PRP allows and that have authenticated there.
- Privileged accounts excluded by default: Domain Admins, Enterprise Admins, Schema Admins and the built-in operator groups are in the deny list, so their passwords are never cached.
- Separate administration and its own krbtgt: a local delegated admin can manage the RODC without domain rights, and the RODC signs tickets with its own
krbtgt_#####account.
| Setting | Writable DC (existing) | RODC (new) |
|---|---|---|
| Hostname | server.vmorecloud.com | <RODC-HOSTNAME> (this series uses RODC1) |
| IP address | 192.168.91.129 | <RODC-IP> (a free address; not .129) |
| Subnet mask | 255.255.255.0 (/24) | |
| Default gateway | 192.168.91.2 in this lab; use the branch gateway in production | |
| DNS server during promotion | itself | 192.168.91.129 (the writable DC) |
vmorecloud.com, and the writable DC is server.vmorecloud.com. If your forest root is named differently, substitute it everywhere.Prerequisites and placeholders
- Functional levels: forest functional level of at least Windows Server 2003. Windows Server 2025 domain controllers may need a higher level, so check Microsoft’s requirements for your version.
- Writable partner: at least one writable DC in the same domain running Windows Server 2008 or later, and the PDC emulator must also be Windows Server 2008 or later.
- Forest preparation: if the forest has never had a Windows Server 2008 or later DC, run
adprep /rodcpreponce as an Enterprise Admin. Modern forests normally have this already. - DNS integration: the RODC runs the DNS Server role with read-only copies of the AD-integrated zones. Clients cannot register records on it directly; updates are referred to a writable DNS server.
- Target server: a supported Windows Server version (Windows Server 2025 in this lab) with a static IP address and reachable from the writable DC over the network.
- Credentials: a Domain Admins account. Use a full installation or Server Core, but keep the server physically as secure as you can.
Replace every highlighted placeholder with your own value:
| Placeholder | What to substitute |
|---|---|
| <RODC-HOSTNAME> | Hostname of the new server, up to 15 characters, for example RODC1. |
| <RODC-IP> | The static IPv4 address of the RODC. It must be unused and different from 192.168.91.129. |
| <BRANCH-SITE> | Name for the AD site representing the branch, for example Branch-Office-1. |
| <BRANCH-SUBNET> | The branch IP subnet in CIDR format, for example 192.168.50.0/24. |
| <DOMAIN-ADMIN> | A Domain Admins account, for example vmorecloud\Administrator. |
| <DSRM-PASSWORD> | A new strong Directory Services Restore Mode password, entered at a prompt. Store it in a password vault. |
| <RODC-ADMIN> | The branch admin user or group to delegate local administration of the RODC to. It must not be a Domain Admin. |
| <BRANCH-ALLOWED-GROUP> | A security group containing the branch users and computers allowed to cache passwords on this RODC. |
Check the existing forest (run on server.vmorecloud.com)
# Functional levels
Get-ADForest | Select-Object Name, ForestMode
Get-ADDomain | Select-Object DNSRoot, DomainMode
# PDC emulator and the other FSMO roles
netdom query fsmo
# Existing DCs and their OS versions
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem, IsReadOnly
# Quiet health test: no output means no failures
dcdiag /e /q
repadmin /replsummary
Fix any DNS or replication failure before going further. Only if the forest was never prepared for RODCs, run this on the schema master as an Enterprise Admin:
adprep /rodcprep
Prepare the environment: site, subnet and site link
The RODC lives in its own AD site so branch clients authenticate against it. Create the site, assign the subnet and connect the site to the hub with a site link. Replication only works from a writable DC in a site linked to the RODC’s site.
Create the branch site, subnet and site link
GUI path:
- Right-click Sites → New Site. Name it <BRANCH-SITE> and pick the default site link.
- Right-click Subnets → New Subnet, enter <BRANCH-SUBNET> and associate it with <BRANCH-SITE>.
- Under Inter-Site Transports → IP, open the site link and confirm both sites are included. Set cost and replication interval to suit your WAN.
PowerShell (run on the writable DC):
# 1. Branch site
New-ADReplicationSite -Name "<BRANCH-SITE>"
# 2. Branch subnet mapped to the branch site
New-ADReplicationSubnet -Name "<BRANCH-SUBNET>" -Site "<BRANCH-SITE>"
# 3. Site link between the hub site and the branch site
New-ADReplicationSiteLink -Name "HQ-to-<BRANCH-SITE>" `
-SitesIncluded "Default-First-Site-Name", "<BRANCH-SITE>" `
-Cost 100 -ReplicationFrequencyInMinutes 15
# Check
Get-ADReplicationSite -Filter * | Select-Object Name
Get-ADReplicationSubnet -Filter * | Select-Object Name, Site
Get-ADReplicationSiteLink -Filter * | Select-Object Name, Cost, ReplicationFrequencyInMinutes
-SiteName during promotion. Clients will not be steered to it by subnet, but the replication design is identical.Prepare the RODC server
Set the static IP with DNS pointing at the writable DC
$if = (Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object -First 1).Name
Set-NetIPInterface -InterfaceAlias $if -Dhcp Disabled
New-NetIPAddress -InterfaceAlias $if -IPAddress <RODC-IP> -PrefixLength 24 -DefaultGateway 192.168.91.2
# DNS = the existing writable DC, so the RODC can find the domain
Set-DnsClientServerAddress -InterfaceAlias $if -ServerAddresses 192.168.91.129
# Verify DNS, time and connectivity to the writable DC
Resolve-DnsName vmorecloud.com -Server 192.168.91.129
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.vmorecloud.com -Server 192.168.91.129
w32tm /stripchart /computer:192.168.91.129 /samples:3 /dataonly
Test-NetConnection 192.168.91.129 -Port 389
Join the domain and install the AD DS and DNS roles
# Rename and join in one step; the server restarts
Add-Computer -DomainName vmorecloud.com -NewName <RODC-HOSTNAME> -Credential (Get-Credential <DOMAIN-ADMIN>) -Restart
After the restart, sign in as a domain admin and install the roles:
Install-WindowsFeature -Name AD-Domain-Services, DNS -IncludeManagementTools
Get-WindowsFeature AD-Domain-Services, DNS | Select-Object Name, InstallState
GUI path: Server Manager → Manage → Add Roles and Features, select Active Directory Domain Services and DNS Server.
Promote the server as an RODC
Option A: Server Manager
- Click the yellow flag and select Promote this server to a domain controller.
- Deployment Configuration: Add a domain controller to an existing domain, domain
vmorecloud.com, with <DOMAIN-ADMIN> credentials. - Domain Controller Options: keep DNS server and Global Catalog, tick Read only domain controller (RODC), select <BRANCH-SITE> and enter the DSRM password.
- RODC Options: set the Delegated administrator account to <RODC-ADMIN>. Under Accounts allowed to replicate passwords add <BRANCH-ALLOWED-GROUP>. Leave Denied accounts at the default.
- DNS Options: ignore the delegation warning (parent zone not found); it is expected for a root domain.
- Additional Options: replicate from
server.vmorecloud.com. Keep the default paths. - Review, use View script if you want the PowerShell, pass the prerequisites check and click Install. The server restarts.
Option B: PowerShell with -ReadOnlyReplica
$cred = Get-Credential <DOMAIN-ADMIN>
$dsrm = Read-Host "Enter <DSRM-PASSWORD>" -AsSecureString
$nb = (Get-ADDomain -Server server.vmorecloud.com).NetBIOSName
# Dry run
Test-ADDSDomainControllerInstallation -DomainName vmorecloud.com -ReadOnlyReplica:$true `
-SiteName "<BRANCH-SITE>" -Credential $cred -SafeModeAdministratorPassword $dsrm
# Promote as RODC
Install-ADDSDomainController `
-DomainName "vmorecloud.com" `
-Credential $cred `
-ReadOnlyReplica:$true `
-SiteName "<BRANCH-SITE>" `
-InstallDns:$true `
-NoGlobalCatalog:$false `
-ReplicationSourceDC "server.vmorecloud.com" `
-DelegatedAdministratorAccountName "$nb\<RODC-ADMIN>" `
-AllowPasswordReplicationAccountName @("$nb\<BRANCH-ALLOWED-GROUP>") `
-DenyPasswordReplicationAccountName @("BUILTIN\Administrators","BUILTIN\Server Operators","BUILTIN\Backup Operators","BUILTIN\Account Operators","$nb\Denied RODC Password Replication Group") `
-DatabasePath "C:\Windows\NTDS" -LogPath "C:\Windows\NTDS" -SysvolPath "C:\Windows\SYSVOL" `
-SafeModeAdministratorPassword $dsrm `
-Force:$true
The deny list above matches the defaults, written out so you can see what is protected. The server restarts automatically. The delegation warning may be printed; it does not stop the install.
Add-ADDSReadOnlyDomainControllerAccount and let a branch admin attach the server later with only the delegated account. That avoids handing domain admin credentials to the branch.Configure the Password Replication Policy
The PRP is the core security control. It is a pair of lists on the RODC computer object: allowed accounts may have passwords cached, denied accounts never do. Deny always wins over allow. Two domain groups feed the defaults:
| Group | Purpose | Default content |
|---|---|---|
| Allowed RODC Password Replication Group | Accounts allowed to cache on every RODC in the domain | Empty |
| Denied RODC Password Replication Group | Accounts never cached on any RODC | Domain Admins, Enterprise Admins, Schema Admins, Cert Publishers, Group Policy Creator Owners, Domain Controllers, Read-only Domain Controllers and the krbtgt account |
The RODC’s own deny list also includes Administrators, Server Operators, Backup Operators and Account Operators. Privileged accounts must be denied because a stolen RODC would otherwise expose their password hashes and give an attacker a path to the writable DCs. Keep them in the deny list and sign in to branch machines with non-privileged accounts.
Scope the policy to this RODC
Avoid putting branch users in the domain-wide Allowed group, which would let every RODC cache them. Use a branch-specific group and apply it only to this RODC:
# Branch group with the users and computers that work at this site
New-ADGroup -Name "<BRANCH-ALLOWED-GROUP>" -GroupScope Global -GroupCategory Security
Add-ADGroupMember "<BRANCH-ALLOWED-GROUP>" -Members user1, user2, BRANCH-PC01$
# Apply to this RODC only
Add-ADDomainControllerPasswordReplicationPolicy -Identity "<RODC-HOSTNAME>" -AllowedList "<BRANCH-ALLOWED-GROUP>"
# Optional extra denied accounts for this RODC
Add-ADDomainControllerPasswordReplicationPolicy -Identity "<RODC-HOSTNAME>" -DeniedList "svc-backup"
# Review
Get-ADDomainControllerPasswordReplicationPolicy -Identity "<RODC-HOSTNAME>" -Allowed
Get-ADDomainControllerPasswordReplicationPolicy -Identity "<RODC-HOSTNAME>" -Denied
In the GUI: Active Directory Users and Computers → Domain Controllers → RODC → Properties → Password Replication Policy tab, then Advanced to see accounts that were revealed or authenticated.
Prepopulate and audit cached passwords
# Pre-cache a user so the first branch logon works even if the WAN is down
repadmin /rodcpwdrepl <RODC-HOSTNAME> server.vmorecloud.com "CN=user1,CN=Users,DC=vmorecloud,DC=com"
# Which accounts have passwords cached on the RODC?
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "<RODC-HOSTNAME>" -RevealedAccounts
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "<RODC-HOSTNAME>" -AuthenticatedAccounts
If the RODC is lost or compromised, reset the passwords of every revealed account.
Verification
Confirm the RODC is listed and read-only
Get-ADDomainController -Identity "<RODC-HOSTNAME>" | Select-Object Name, IsReadOnly, Site, IPv4Address, IsGlobalCatalog
Get-ADDomainController -Filter {IsReadOnly -eq $true} | Select-Object Name, Site
# The RODC has its own krbtgt account
Get-ADUser -Filter 'Name -like "krbtgt_*"' | Select-Object Name
In Active Directory Users and Computers, the RODC sits in the Domain Controllers OU with DC Type: Read-only.
Check replication and health
repadmin /replsummary
repadmin /showrepl <RODC-HOSTNAME>
repadmin /syncall /AdeP
dcdiag /s:<RODC-HOSTNAME> /v
dcdiag /s:<RODC-HOSTNAME> /test:dns /v
repadmin /showrepl on an RODC lists inbound neighbours only, which is the one-way model in action. Failures must be 0 and every dcdiag test should pass.
Validate DNS SRV records and site awareness
# DC locator records for the RODC's site
Resolve-DnsName -Type SRV _ldap._tcp.<BRANCH-SITE>._sites.dc._msdcs.vmorecloud.com -Server 192.168.91.129
Resolve-DnsName -Type SRV _kerberos._tcp.<BRANCH-SITE>._sites.dc._msdcs.vmorecloud.com -Server 192.168.91.129
# Host record and the site the RODC thinks it is in
Resolve-DnsName <RODC-HOSTNAME>.vmorecloud.com -Server 192.168.91.129
nltest /dsgetsite
# From a branch client: which DC does it use?
nltest /dsgetdc:vmorecloud.com
The SRV records for the branch site should list the RODC. If branch clients still pick a hub DC, the subnet mapping is wrong.
Common pitfalls and troubleshooting
DNS resolution failure
“The specified domain either does not exist or could not be contacted.” The RODC is not using the writable DC for DNS.
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName vmorecloud.com
ipconfig /flushdnsSet DNS to 192.168.91.129 before promotion and remove public DNS servers. After promotion, list the writable DC first and the RODC itself second.
Replication errors
Errors 1722 (RPC unavailable), 8524 (DNS lookup failure) or “no partner” mean connectivity, DNS or site-link problems.
repadmin /showrepl <RODC-HOSTNAME>
Test-NetConnection 192.168.91.129 -Port 135
dcdiag /test:replicationsOpen RPC (TCP 135, 389, 445, 88, 464 and 49152-65535) and confirm a writable DC exists in a site linked to the branch.
Time sync problems
Kerberos fails when the clock is off by more than 5 minutes, which is common on branch VMs.
w32tm /query /status
w32tm /resync /forceThe domain time source is the PDC emulator. Make sure the hypervisor time sync does not fight Windows Time.
Clients use the wrong DC
Branch clients authenticate over the WAN even though the RODC is up.
nltest /dsgetsite
Get-ADReplicationSubnet -Filter * | Select-Object Name, SiteAdd or correct the subnet object so the branch network maps to <BRANCH-SITE>, and check that clients get the right DNS servers from DHCP.
Users cannot log on when the WAN is down
Their password was never cached because they are not in the PRP allowed list, or were not yet authenticated.
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "<RODC-HOSTNAME>" -RevealedAccountsAdd the users to <BRANCH-ALLOWED-GROUP>, then prepopulate with repadmin /rodcpwdrepl.
Promotion prerequisite failure
The wizard reports the forest is not prepared, a functional level is too low, or no writable DC is available.
Get-ADForest | Select-Object ForestMode
netdom query fsmo
adprep /rodcprepRaise the level, make sure the PDC emulator is on Windows Server 2008 or later and run adprep /rodcprep once if the forest was never prepared.
Frequently asked questions
Can an RODC be the only domain controller?
No. It must replicate from a writable DC in the same domain, so at least one writable DC is required.
Do users change passwords on an RODC?
Password changes and other writes are forwarded to a writable DC. The RODC only refreshes its cached copy afterwards if the account is allowed by the PRP.
Should the RODC be a Global Catalog?
Usually yes. It speeds up branch logons and universal group lookups, and it is read-only like the rest of the directory.
Can the branch admin be a Domain Admin?
No. Delegate local administration only. A branch admin with domain rights defeats the purpose of the RODC.
Conclusion
You now have a branch domain controller that can serve authentication and DNS locally while limiting what an attacker gains if the server is lost. Use the checklist below to confirm the deployment.
- Forest and domain levels meet the requirements, a writable DC runs Windows Server 2008 or later, and the PDC emulator is supported
- Branch site, subnet and site link exist and the subnet maps to <BRANCH-SITE>
- RODC has a static IP, DNS pointed at
192.168.91.129during promotion, and correct time Get-ADDomainControllershowsIsReadOnly = Truein the branch site- PRP allowed list limited to branch accounts; privileged accounts and the Denied RODC Password Replication Group remain denied
repadmin /replsummaryshows 0 failures anddcdiagpasses- SRV records for the branch site list the RODC
- Delegated admin is not a Domain Admin; DSRM password stored safely
Next: protect the local administrator password
With an RODC deployed, the next step in the AZ-802 lab series is managing local administrator passwords with Windows LAPS on VMoreCloud.
Sources & Further Reading
Technical note: commands were written for Windows Server 2025 in the vmorecloud.com lab. Test in a lab before production and replace all highlighted placeholders with your own values.

