Active Directory Replication Topology for 2-DC Setups

For most small business and MSP Active Directory deployments, two domain controllers are enough: one primary DC and one secondary DC in the same AD site, connected over private networking. In a single-site setup, Active Directory replication is automatic. Multi-site setups need proper Sites, Subnets, and Site Links so clients find the right DC and replication follows the right network path.

Quick verdict by setup

Simple rule:

Single location = one AD site.
Multiple network locations = multiple AD sites with subnets and site links.
Production AD = at least two domain controllers.

Why AD replication topology matters

Active Directory Domain Services is a replicated system.

Each writable domain controller stores a copy of the directory database. Changes such as password updates, group membership changes, computer joins, DNS records, Group Policy changes, and user account updates must replicate between domain controllers.

If replication is healthy, users usually do not think about it.

If replication is unhealthy, you can see problems like:

• users can log in from one location but not another;
• password changes work on one DC but not another;
• Group Policy changes apply inconsistently;
• DNS records are missing or stale;
• new computers cannot find the right domain controller;
• RDP users authenticate slowly;
• one DC shows old group membership;
• SYSVOL or GPO changes do not appear everywhere;
• a failed DC causes more disruption than expected.

Replication topology decides how domain controllers find replication partners and how changes move through the environment.

For a small deployment, the best topology is usually simple.

For a larger or multi-location deployment, the topology must be intentional.

The important AD topology terms

Before changing anything in Active Directory Sites and Services, know the core terms.

Domain controller

A domain controller is a Windows Server running the Active Directory Domain Services role.

It provides:

• authentication;
• authorization;
• directory storage;
• Group Policy access;
• AD-integrated DNS if installed;
• Kerberos services;
• LDAP services;
• domain join support.

A production domain should not rely on only one domain controller.

If the only DC fails, the domain can become difficult or impossible to operate normally until recovery.

Site

An AD site represents a network location with reliable, fast connectivity.

A site is not the same as an office name or cloud region by itself.

In Active Directory, a site is tied to IP subnets.

Examples:

Site: raff-us-east
Subnet: 10.10.0.0/24

Site: office-new-york
Subnet: 10.20.0.0/24

Sites help Active Directory decide:

• which DC a client should use;
• how replication should be routed;
• which network path should be preferred;
• which domain controllers are considered local.

Subnet

A subnet object maps an IP range to an AD site.

This is one of the most commonly missed steps.

If you create sites but do not assign subnets, clients may still use the wrong domain controller.

Example:

10.10.0.0/24 → raff-us-east
10.20.0.0/24 → office-new-york

If a client’s IP is inside 10.20.0.0/24, AD can associate it with the office-new-york site.

Site link

A site link tells AD that two or more sites can replicate with each other.

A site link has:

• member sites;
• cost;
• replication interval;
• schedule.

For two sites, the site link is straightforward.

For three or more sites, cost becomes more important because it influences the replication route.

KCC

The Knowledge Consistency Checker, or KCC, is the built-in process that automatically creates replication connections between domain controllers.

In normal conditions, you do not manually create connection objects.

You define sites, subnets, and site links.

Then KCC builds the replication topology.

Manual connection objects should be rare and carefully documented.

Bridgehead server

A bridgehead server is the domain controller selected to handle replication between sites.

In small two-site setups, you usually do not need to manually choose bridgehead servers.

Let KCC select them unless you have a clear reason.

Global Catalog

A Global Catalog server stores a partial replica of objects from all domains in the forest and a full replica of its own domain.

In a single-domain SMB setup, it is usually practical for both domain controllers to be Global Catalog servers.

This improves logon and lookup availability.

Topology pattern 1 — Single site with two domain controllers

This is the default recommendation for most small business Windows VPS deployments.

Use this when:

• both DCs are in the same cloud region;
• both DCs are on the same private network;
• the business has one logical AD location;
• latency between DCs is low;
• there is no need to control intersite replication;
• the deployment is small and simple.

Architecture:

AD Site: Default-First-Site-Name or raff-primary

Private subnet:
10.10.0.0/24

Domain controllers:
DC01
DC02

Recommended role split:

DC01
* PDC Emulator
* RID Master
* Infrastructure Master
* DNS
* Global Catalog

DC02
* Secondary writable DC
* DNS
* Global Catalog
* Backup authentication path

For a small single-domain environment, you can also leave all FSMO roles on DC01 and use DC02 as the healthy standby.

That is usually simpler.

Why this works

In a same-site setup, Active Directory handles replication automatically.

KCC creates the replication connections.

You do not need to create site links.

You do not need to tune replication intervals.

You do not need to manually build a full mesh.

For most 2-DC SMB setups, this is the correct answer:

Promote the second DC.
Make sure DNS is correct.
Verify replication.
Monitor regularly.
Do not over-engineer.

Single-site setup checklist

Use this checklist after adding the second domain controller.

Confirm both DCs exist

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

Expected:

• DC01 and DC02 appear;
• both are in the same site;
• both have correct IP addresses;
• both are reachable.

Confirm DNS server settings

Each DC should usually point DNS to another DC first, then itself.

Example:

DC01 preferred DNS: DC02 private IP
DC01 alternate DNS: DC01 private IP

DC02 preferred DNS: DC01 private IP
DC02 alternate DNS: DC02 private IP

Avoid pointing domain controllers only to public DNS resolvers.

AD-integrated DNS is required for normal domain discovery.

Confirm SYSVOL and NETLOGON shares

Run on each DC:

net share

Expected shares:

SYSVOL
NETLOGON

If these shares are missing on a new DC, do not assume replication is healthy.

Investigate before using the DC in production.

Confirm replication summary

repadmin /replsummary

Expected:

0 fails
No growing replication backlog
Recent successful replication

A small delta is normal after a recent change.

Growing failures are not normal.

Confirm detailed replication status

repadmin /showrepl

Look for:

• recent last successful attempt;
• no repeated failures;
• correct source DCs;
• no RPC, DNS, or access denied errors.

Topology pattern 2 — Two cloud regions or office plus cloud

Use a multi-site topology when domain controllers live in meaningfully different network locations.

Examples:

• one DC in Raff cloud and one DC in an office;
• one DC in a primary cloud region and one DC in another region;
• one DC for headquarters and one DC for a branch;
• one DC for a production site and another for disaster recovery;
• hybrid AD where on-prem clients should prefer the on-prem DC.

Architecture:

Site: raff-us
Subnet: 10.10.0.0/24
DC01

Site: office-ny
Subnet: 10.20.0.0/24
DC02

Site Link:
raff-us__office-ny

This tells AD:

• which clients belong to which site;
• which DC is local to each subnet;
• how replication should occur between the two sites;
• how often replication should be attempted.

When multi-site is worth it

Use multiple sites when:

• IP subnets are meaningfully separated;
• clients should prefer local DCs;
• replication traffic should follow a controlled path;
• WAN or VPN links are slower than local networking;
• office and cloud authentication paths need separation;
• you need a DR location;
• you need different replication intervals by location.

Do not create multiple sites just to make the diagram look sophisticated.

If all DCs are in the same private network with low latency, one site is usually better.

Step 1 — Create the AD sites

Open Active Directory Sites and Services:

dssite.msc

Then:

1. Right-click Sites.
2. Select New Site.
3. Name the first site, for example raff-us.
4. Select the default site link for now.
5. Repeat for the second site, for example office-ny.

Use names that match actual network locations.

Good names:

raff-us
office-ny
branch-dallas
dr-site

Bad names:

site1
newsite
test
main2

The names should be understandable six months later.

Step 2 — Create and assign subnets

In Active Directory Sites and Services:

1. Expand Sites.
2. Right-click Subnets.
3. Select New Subnet.
4. Enter the subnet prefix.
5. Assign the subnet to the correct site.

Example:

10.10.0.0/24 → raff-us
10.20.0.0/24 → office-ny

This step is critical.

Sites without subnets are incomplete.

If subnets are missing, clients can authenticate against a remote DC even when a local DC exists.

Step 3 — Move domain controllers to the correct sites

In dssite.msc:

1. Expand the old site, usually Default-First-Site-Name.
2. Expand Servers.
3. Right-click or drag each domain controller into the correct site.
4. Confirm the DC appears under the right site.

Example:

DC01 → raff-us
DC02 → office-ny

After moving DCs, allow time for replication.

Then verify:

Get-ADDomainController -Filter * |
    Select-Object HostName, Site, IPv4Address

Step 4 — Create or configure the site link

In Active Directory Sites and Services:

1. Expand Inter-Site Transports.
2. Expand IP.
3. Right-click and create a new site link, or edit the existing one.
4. Add both sites.
5. Set a clear name.
6. Set cost and replication interval.

Example:

Site link: raff-us__office-ny
Sites: raff-us, office-ny
Cost: 100
Replication interval: 15 minutes

For a simple two-site environment, cost is not very important.

For three or more sites, cost helps AD choose preferred replication routes.

Replication interval guidance

Site link replication should match business need and network quality.

Do not set everything to the fastest possible interval without understanding traffic.

For most SMB and MSP deployments, 15 minutes is a good starting point for important intersite replication.

Step 5 — Verify client site mapping

From a domain-joined client or server, run:

nltest /dsgetsite

Expected:

raff-us

or:

office-ny

depending on the client subnet.

Then check which DC the client discovers:

nltest /dsgetdc:yourdomain.local

If a client in the office is discovering the cloud DC when it should use the office DC, check subnet assignment first.

FSMO roles and placement

Active Directory has five Operation Master roles, often still called FSMO roles.

They are:

In a new forest, the first domain controller usually holds all five roles.

For a small 2-DC domain, that is usually acceptable.

Recommended FSMO placement for a 2-DC setup

For most SMB deployments:

DC01:
* All FSMO roles
* DNS
* Global Catalog

DC02:
* DNS
* Global Catalog
* Healthy replication partner
* Standby DC

Why keep all FSMO roles on DC01?

Because it is simple.

For a two-DC environment, spreading roles across DCs can create more confusion than benefit.

The important part is not role spreading.

The important part is knowing where the roles are and knowing how to transfer or seize them if DC01 permanently fails.

Check FSMO role placement

Run:

netdom query fsmo

Or use PowerShell:

Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

Document the output.

During an outage, you do not want to discover role placement for the first time.

Transfer FSMO roles for planned maintenance

If DC01 is healthy and you plan to take it offline for a long maintenance window, transfer roles gracefully.

Example:

Move-ADDirectoryServerOperationMasterRole `
    -Identity "DC02" `
    -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster

For all roles:

Move-ADDirectoryServerOperationMasterRole `
    -Identity "DC02" `
    -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Only do this when you understand the impact.

For normal patching and short reboots, transferring roles is usually unnecessary.

Seize roles only after permanent failure

Seizing roles is different from transferring roles.

Transfer = the current owner is alive and cooperates. Seize = the current owner is dead or cannot return.

Do not seize FSMO roles casually.

Seize roles only when:

• the old role holder is permanently unavailable;
• it cannot be cleanly brought back;
• you understand cleanup requirements;
• you are prepared to remove metadata for the failed DC.

If a failed DC might come back online, be careful.

Bringing back a failed role holder after role seizure can create dangerous conflicts.

Global Catalog placement

For most single-domain 2-DC setups, make both domain controllers Global Catalog servers.

That improves:

• logon resilience;
• directory search availability;
• group membership evaluation;
• lookup reliability.

Check Global Catalog status:

Get-ADDomainController -Filter * |
    Select-Object HostName, IsGlobalCatalog

For single-domain environments, both should usually show:

True

For multi-domain forests, Global Catalog placement needs more planning.

DNS design for two domain controllers

AD depends heavily on DNS.

Bad DNS design causes many “replication” problems that are really name-resolution problems.

For two DCs:

DC01 DNS:
Preferred: DC02 private IP
Alternate: DC01 private IP

DC02 DNS:
Preferred: DC01 private IP
Alternate: DC02 private IP

For clients:

Client DNS:
Preferred: nearest/local DC
Alternate: secondary DC

Do not point AD clients directly to public DNS resolvers such as 8.8.8.8 or 1.1.1.1.

Use AD DNS first.

Forwarders can handle internet DNS resolution from the DCs.

Network ports and private connectivity

Domain controllers need more than RDP open to each other.

AD replication and domain services use several protocols, including:

• DNS;
• Kerberos;
• LDAP;
• LDAPS if configured;
• SMB;
• RPC Endpoint Mapper;
• dynamic RPC ports;
• Global Catalog ports.

For modern Windows Server environments, dynamic RPC commonly uses the high port range:

49152–65535

This matters if you place DCs behind strict firewalls, private networks, security groups, VPNs, or segmented networks.

A practical rule:

Keep domain controllers on a trusted private network when possible.
Do not expose AD replication paths to the public internet.

If you must segment domain controllers, plan firewall rules carefully.

Do not randomly open ports until replication works.

Replication health checks

Run replication checks regularly.

For production, weekly is a reasonable baseline.

For critical environments, run them daily or automate monitoring.

Quick summary

repadmin /replsummary

Look for:

• largest delta;
• failures;
• failure percentage;
• source DSA;
• destination DSA.

Healthy result:

0 fails
low or expected delta
recent replication

Detailed replication view

repadmin /showrepl

Use this when /replsummary shows failures.

Look for:

• last success time;
• last error;
• source DC;
• naming context;
• repeated failure patterns.

Common errors often point to:

• DNS failure;
• RPC blocked;
• access denied;
• time skew;
• offline DC;
• broken secure channel;
• routing/firewall issue.

Force replication when needed

Use this after planned changes or when testing.

repadmin /syncall /AeD

Common options:

For many admin checks, this is useful:

repadmin /syncall /AeD

Do not use forced replication as a substitute for fixing a broken topology.

Check domain controller discovery

nltest /dclist:yourdomain.local

Check secure channel:

Test-ComputerSecureChannel

From a domain-joined client:

nltest /dsgetdc:yourdomain.local

These commands help confirm whether clients can discover and use domain controllers correctly.

Check SYSVOL replication

SYSVOL contains Group Policy and logon scripts.

Check shares:

net view \\DC01
net view \\DC02

Expected:

SYSVOL
NETLOGON

Check Group Policy consistency:

gpupdate /force

On a client:

gpresult /r

If Group Policy behaves differently depending on which DC is used, investigate SYSVOL and AD replication.

Monitoring schedule

Use this simple schedule.

AD replication should not be checked only when users complain.

Backup and recovery for domain controllers

Do not rely on replication as a backup.

Replication copies changes.

That includes bad changes.

If an admin deletes an OU, breaks DNS, damages Group Policy, or removes users, that change can replicate to other DCs.

You still need backups.

For AD, plan:

• system state backups;
• VM-level backups or snapshots;
• restore testing;
• documented recovery steps;
• Active Directory Recycle Bin if appropriate;
• clear rules for FSMO seizure;
• metadata cleanup process for failed DCs.

Snapshots are useful before risky changes.

Backups are required for recovery.

Common mistakes

Mistake 1 — Running only one domain controller

A single DC is a single point of failure.

If it fails, users may lose authentication, DNS, Group Policy, and domain services.

Use at least two domain controllers for production.

Mistake 2 — Putting both DCs on the same failure boundary

Two DCs on the same host, same storage dependency, or same fragile network path may not provide real redundancy.

For stronger resilience, separate them where practical.

Mistake 3 — Creating sites but not assigning subnets

Sites without subnets do not properly guide client location.

If clients authenticate against the wrong DC, check subnet mapping first.

Mistake 4 — Manually creating replication connections without a reason

KCC normally handles connection objects.

Manual connections can make troubleshooting harder.

Only create manual connections when there is a documented reason.

Mistake 5 — Leaving old failed DC metadata behind

If a DC is permanently gone, clean it up properly.

Stale DC objects can cause replication, DNS, and authentication confusion.

Mistake 6 — Opening AD ports over the public internet

Domain controllers should communicate over private networks, VPNs, or trusted paths.

Do not expose domain controller replication broadly to the public internet.

Mistake 7 — Treating replication as backup

Replication is not backup.

Replication copies both good and bad changes.

Use system state backups and recovery planning.

Mistake 8 — Ignoring DNS

Many AD replication problems are DNS problems.

Always check DNS before assuming AD itself is broken.

Mistake 9 — Not documenting FSMO placement

During an outage, FSMO role placement matters.

Document current role holders and recovery steps.

Mistake 10 — Mixing too many roles on domain controllers

Domain controllers should be dedicated when possible.

Avoid running SQL Server, ERP apps, IIS workloads, or random business software on DCs.

A mixed-role DC is harder to secure, patch, and recover.

Raff recommendation for 2-DC Windows VPS deployments

For most Raff Windows VPS Active Directory deployments, use this model:

DC01:
Primary domain controller
DNS
Global Catalog
FSMO roles
Private IP only where possible

DC02:
Secondary domain controller
DNS
Global Catalog
Replication partner
Private IP only where possible

If both DCs live in the same Raff private network and region, keep them in one AD site.

If one DC is in Raff and another is in an office or another region, create proper AD sites and subnet mappings.

Recommended baseline:

Small deployment:
2 DCs, one AD site, both DNS + GC

Hybrid office/cloud:
2 sites, 2 subnets, 1 site link, 15–30 minute replication

MSP client environment:
separate client domains or forests, not one shared AD for unrelated clients

Do not overcomplicate the topology before the business needs it.

But do not run production AD with one DC.

What to test before production

Before relying on the topology, test:

• both DCs can authenticate users;
• both DCs resolve AD DNS records;
• repadmin /replsummary shows no failures;
• SYSVOL and NETLOGON exist on both DCs;
• clients discover the correct site;
• clients find the expected domain controller;
• Group Policy applies correctly;
• a password change replicates;
• DNS records replicate;
• backup and restore procedure is documented;
• FSMO owners are known.

A clean test saves painful troubleshooting later.

Compatible with Raff Windows VM

This guide is compatible with Raff Windows VM deployments running Windows Server domain controllers.

Use a “Tested on Raff” claim only after retesting the exact environment and recording:

• Windows Server version and build;
• number of DCs;
• topology type;
• private network design;
• test date;
• tester name;
• screenshots;
• repadmin /replsummary output.

Suggested test note after validation:

Tested on two Raff Windows VMs running Windows Server 2022 or 2025, two writable domain controllers, AD-integrated DNS, same-site replication, Global Catalog enabled on both DCs, and private networking between DCs. Replication verified with repadmin /replsummary and repadmin /showrepl.

Do not publish that claim until the test is actually complete.

What's next

• Promote a Windows VPS to a domain controller.
• Set up Active Directory Group Policy from scratch.
• Review Windows Server hardening before exposing production workloads.
• Configure Windows Firewall for production.
• Plan Windows Server backups before relying on AD in production.
• Review RDP access and RDS licensing before giving users server access.

Sources

• Microsoft Learn — Active Directory Replication Concepts
• Microsoft Learn — Transfer or seize Operation Master roles in Active Directory Domain Services
• Microsoft Learn — Service overview and network port requirements for Windows
• Microsoft Learn — Active Directory Domain Services overview
• Raff — Windows VM product page