Windows Server for beginners. Part 10: The second controller and replication
All parts of the series “Windows Server for beginners”Everything from the previous six parts lives on a single server. Today a second one appears, and the directory becomes what it was designed to be: a database with no single owner. Any controller accepts changes, and they spread to the others; any controller can be switched off, and the domain won't notice. For that to work, the controllers have to be able to agree on who has the newer data — that's replication, and it's built in a more interesting way than the word "copying" suggests.
The dc2 server is prepared as in part 1: the name dc2, the addresses 192.168.1.11 and 2001:db8:1::11 (it needs a static IPv6 address, just like dc1 in part 9), time, updates. The only difference from what we did with dc1: the DNS client points to 192.168.1.10 — the future controller has to find the domain.
Adding a controller
The same role, a different cmdlet:
PS C:\> Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
PS C:\> $dsrm = Read-Host -AsSecureString 'DSRM password'
PS C:\> $cred = Get-Credential CORP\alice.admin
PS C:\> Test-ADDSDomainControllerInstallation -DomainName corp.example.com -Credential $cred -InstallDns -SiteName Default-First-Site-Name -SafeModeAdministratorPassword $dsrm
PS C:\> Install-ADDSDomainController -DomainName corp.example.com -Credential $cred -InstallDns -SiteName Default-First-Site-Name -ReplicationSourceDC dc1.corp.example.com -SafeModeAdministratorPassword $dsrm -Force
There's no need to join the domain beforehand: on a standalone server Install-ADDSDomainController creates the computer account itself if you give it domain administrator credentials. The parameters that Install-ADDSForest didn't have:
| Parameter | What |
|---|---|
-Credential |
who promotes: Domain Admins rights are needed |
-SiteName |
which site to put the controller in; without the parameter it's chosen by subnet, and if there are no subnets, the site of the controller replication comes from |
-ReplicationSourceDC |
where to take the initial copy from; without the parameter it picks one itself |
-NoGlobalCatalog |
don't make it a global catalog; by default it does |
-InstallationMediaPath |
the path to IFM media instead of replicating over the network |
-CriticalReplicationOnly |
replicate only critical objects during installation, the rest in the background after the reboot |
-ReadOnlyReplica |
a read-only controller, the topic of the next part |
IFM (Install From Media) is a way to avoid pushing the database over a slow link: a snapshot of the database and SYSVOL is taken on a working controller, carried to the new server on a disk or copied in advance, and promotion takes the objects from there, pulling over the network only the changes accumulated since the snapshot:
PS C:\> ntdsutil "activate instance ntds" ifm "create sysvol full C:\IFM" quit quit
For a controller in the next rack this isn't needed; for a branch office behind a 2 Mbit/s link with a 2 GB database it's the only sensible way.
During the minutes promotion takes, the following happens. The server object and NTDS Settings for dc2 are created on dc1 in the configuration partition, and from that moment the other controllers know about the new one. dc2 replicates from dc1 the schema, the configuration, the domain and, since it's a global catalog, partial copies of the other domains (which we don't have). Then SYSVOL: dc2 becomes a member of the DFS-R replication group and pulls the contents from dc1. After the reboot Netlogon registers the SRV records, DFS-R reports that initial synchronization is complete (event 4604 in the DFS Replication log), and dc2 publishes SYSVOL and NETLOGON and starts advertising itself to clients.
PS C:\> Get-ADDomainController -Filter * | Format-Table HostName, IPv4Address, Site, IsGlobalCatalog, OperationMasterRoles -AutoSize
HostName IPv4Address Site IsGlobalCatalog OperationMasterRoles
-------- ----------- ---- --------------- --------------------
dc1.corp.example.com 192.168.1.10 Default-First-Site-Name True {SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster}
dc2.corp.example.com 192.168.1.11 Default-First-Site-Name True {}
The FSMO roles stayed on dc1: they don't move by themselves, and that's what part 17 is about. Everything else is the same on the two controllers.
How replication works
Replication in Active Directory is multi-master and attribute-level: what travels over the network is not the whole object but the changed attribute (for multi-valued attributes such as member, an individual value — this is called linked value replication). Three mechanisms make it possible.
USN and invocationID. Every controller has a USN (update sequence number) counter that grows with every write to the database — the very highestCommittedUSN from RootDSE in part 5. Every change is stamped with a "who made it, with which USN" pair: a controller is identified by its invocationID — a GUID it gets at promotion and changes when restored from a backup (so that old USNs don't get mixed up with new ones). A change made by a client on this controller is an originating write; one received through replication is a replicated write, and it keeps the originating pair from the controller where it was born.
The watermark and the up-to-dateness vector. For each partner a controller remembers the high-watermark — up to which of the partner's USNs it has already received everything. A replication request sounds like "give me everything that has changed on you after USN 41237". Besides that, every controller has an up-to-dateness vector: for each controller in the forest, the highest originating USN it has already seen. The vector is sent to the partner along with the request, and the partner doesn't send changes the requester has already received by another path. That way two controllers with three partners each don't get the same change three times — this is called propagation dampening.
PS C:\> Get-ADReplicationUpToDatenessVectorTable -Target dc2 -Partition 'DC=corp,DC=example,DC=com' | Format-Table Partner, UsnFilter, LastReplicationSuccess -AutoSize
Partner UsnFilter LastReplicationSuccess
------- --------- ----------------------
CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp… 41290 15.10.2026 11:02:14
CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp… 12811 15.10.2026 11:02:14
Conflicts. The same attribute was changed on two controllers before they replicated. The change with the higher attribute version wins (it grows with every originating write; we saw it in Get-ADReplicationAttributeMetadata); with equal versions, the one with the later timestamp; with both equal, the invocationID of the controller where the change was born decides. The losing change disappears without a trace, and that's fine for a directory where conflicts are rare. Two special cases: an object created with the same name in the same container on two controllers — the loser gets the suffix \0ACNF:<GUID> added to its name, and such objects can be found with the filter (name=*\0ACNF:*); an object moved into a container that was deleted on another controller ends up in CN=LostAndFound.
Urgent replication. Normal replication within a site goes with a 15-second notification delay. Some changes don't wait: an account lockout (but not an unlock), changes to the domain lockout and password policies, a change of a trust password or of a controller's computer account password, a change of the RID master role owner notify partners immediately. User passwords are a separate story: when a password changes, the controller, besides normal replication, immediately sends it to the PDC emulator over RPC, and when the user logs on at another controller that still has the old password, that controller asks the PDC again before refusing. That's why a new password works everywhere at once, even though it reaches some controllers only a quarter of an hour later.
KCC and topology
Who replicates with whom is decided by the KCC (Knowledge Consistency Checker) — a process on every controller that runs every 15 minutes and builds connection objects (nTDSConnection) under each controller's NTDS Settings: inbound links through which this controller pulls changes. A connection is always one-way; for two controllers the KCC creates two.
Within a site the KCC builds a ring: each controller replicates with its two neighbors in the ring, and if there are more than seven controllers, it adds links so that there are no more than three hops between any two. Within a site replication goes by notification: a controller that has accepted a change notifies its partners after 15 seconds, and they pull it; without compression, over RPC.
Between sites everything is different. In each site one controller is designated the ISTG (Inter-Site Topology Generator) and builds links to other sites along the graph of site links (siteLink), choosing bridgehead servers in each site. Inter-site replication goes on the link's schedule, with compression, and without notifications by default.
PS C:\> Get-ADReplicationConnection -Filter * | Format-Table Name, ReplicateFromDirectoryServer, ReplicateToDirectoryServer, AutoGenerated -AutoSize
Name ReplicateFromDirectoryServer ReplicateToDirectoryServer AutoGenerated
---- ---------------------------- -------------------------- -------------
3b1a2c4d-5e6f-4a70-8b91-c2d3e4f5a6b7 CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,… CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,… True
7c8d9e0f-1a2b-4c3d-9e4f-5a6b7c8d9e0f CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,… CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,… True
AutoGenerated: True means built by the KCC. Connections can be created by hand, and the KCC won't touch them, but manual connections are almost always a mistake: they stay when the topology changes, and the KCC stops being responsible for that part. The right way to manage topology is sites and site links, and let the KCC build the connections itself. To make it recalculate right now: repadmin /kcc.
Sites
A site is a set of subnets with fast connectivity between them; by design, one location. Sites serve three things: replication (inside, fast and by notification; between, on a schedule and with compression), DC Locator (a client looks for a controller in its own site, part 3) and site-aware applications (Exchange, DFS, SCCM). Which site a client belongs to is determined by its address using subnet objects.
A forest is created with a single site, Default-First-Site-Name, without subnets. Let's put it in order and add a second site for the branch office 192.168.2.0/24, where a controller will appear in the next part:
PS C:\> Get-ADReplicationSite 'Default-First-Site-Name' | Rename-ADObject -NewName Office
PS C:\> New-ADReplicationSubnet -Name 192.168.1.0/24 -Site Office -Location 'Head office'
PS C:\> New-ADReplicationSubnet -Name 2001:db8:1::/64 -Site Office
PS C:\> New-ADReplicationSite -Name Branch
PS C:\> New-ADReplicationSubnet -Name 192.168.2.0/24 -Site Branch -Location 'Branch office'
PS C:\> Get-ADReplicationSubnet -Filter * | Format-Table Name, Site, Location -AutoSize
Name Site Location
---- ---- --------
192.168.1.0/24 CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com Head office
192.168.2.0/24 CN=Branch,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com Branch office
2001:db8:1::/64 CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
You need all the subnets: a client from a subnet that isn't in any site lands in a random site and goes to a controller across the ocean, and the controller logs event 5807 about it in the System log ("clients from unregistered subnets", the list is in %SystemRoot%\debug\netlogon.log).
A site link describes the link between sites: cost, replication interval and schedule. When a forest is created, one appears, DEFAULTIPSITELINK, with a cost of 100 and an interval of 180 minutes. A site created with New-ADReplicationSite isn't in any link (the snap-in wizard asks you to pick a link right away), and until it's added to one, the controllers in it replicate with nobody, and the ISTG logs event 1865. Let's add Branch and shorten the interval at the same time — three hours is too long for modern links:
PS C:\> Set-ADReplicationSiteLink -Identity DEFAULTIPSITELINK -ReplicationFrequencyInMinutes 15 -Cost 100 -SitesIncluded @{Add='Branch'}
PS C:\> Get-ADReplicationSiteLink -Filter * | Format-Table Name, Cost, ReplicationFrequencyInMinutes, SitesIncluded -AutoSize
Name Cost ReplicationFrequencyInMinutes SitesIncluded
---- ---- ----------------------------- -------------
DEFAULTIPSITELINK 100 15 {CN=Office,…, CN=Branch,…}
Fifteen minutes is the minimum for the schedule. If the links allow it, inter-site replication is switched to notifications, as within a site: bit 1 in the link's options attribute (Set-ADReplicationSiteLink DEFAULTIPSITELINK -Replace @{options=1}); then changes reach the branch office in seconds rather than on a schedule. -Replace overwrites the whole attribute: if options already has other bits set (for example, 4 — no compression), the new value is built with -bor. With several sites and links, the cost of the links determines which path replication takes when there's no direct one: the KCC computes the shortest path by the sum of costs, and site link bridges make all links transitive by default.
There are two transports, IP and SMTP; SMTP is for sites without a permanent connection, it replicates only the schema, the configuration and the global catalog, it isn't used in modern networks, and Microsoft warns that future versions won't support it.
To move a controller to another site: Move-ADDirectoryServer -Identity dc3 -Site Branch. A site without a global catalog can enable universal group membership caching (Set-ADReplicationSite Branch -UniversalGroupCachingEnabled $true) so that logons don't depend on the availability of a GC in another site, but it's simpler to make every controller a GC.
repadmin
The main tool. Four subcommands cover almost everything.
/replsummary — a summary for all controllers in the forest, the place to start:
PS C:\> repadmin /replsummary
Replication Summary Start Time: 2026-10-15 11:10:02
Beginning data collection for replication summary, this may take awhile:
.....
Source DSA largest delta fails/total %% error
DC1 08m:12s 0 / 5 0
DC2 08m:12s 0 / 5 0
Destination DSA largest delta fails/total %% error
DC1 08m:12s 0 / 5 0
DC2 08m:12s 0 / 5 0
largest delta is how long it's been since the last successful replication of the most lagging partition; fails/total is how many links out of how many are failing. Five links for two controllers means five partitions: schema, configuration, domain, DomainDnsZones, ForestDnsZones. A healthy forest has zeros in the fails column and deltas below the schedule interval.
/showrepl — all inbound links of one controller, with the result of the last attempt:
PS C:\> repadmin /showrepl dc2
Office\DC2
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 8e1f2a3b-4c5d-4e6f-9a7b-8c9d0e1f2a3b
DSA invocationID: 8e1f2a3b-4c5d-4e6f-9a7b-8c9d0e1f2a3b
==== INBOUND NEIGHBORS ======================================
DC=corp,DC=example,DC=com
Office\DC1 via RPC
DSA object GUID: 2f3e4d5c-6b7a-4899-8a7b-6c5d4e3f2a1b
Last attempt @ 2026-10-15 11:02:14 was successful.
CN=Configuration,DC=corp,DC=example,DC=com
Office\DC1 via RPC
DSA object GUID: 2f3e4d5c-6b7a-4899-8a7b-6c5d4e3f2a1b
Last attempt @ 2026-10-15 11:02:14 was successful.
CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com
Office\DC1 via RPC
DSA object GUID: 2f3e4d5c-6b7a-4899-8a7b-6c5d4e3f2a1b
Last attempt @ 2026-10-15 11:02:14 was successful.
...
When a link is failing, instead of was successful there will be a code and the number of consecutive failures: Last attempt @ … failed, result 8524 (0x214c): The DSA operation is unable to proceed because of a DNS lookup failure. 3 consecutive failure(s). The codes you see most often:
| Code | What |
|---|---|
| 8524 | the partner can't be found in DNS: its <GUID>._msdcs CNAME or A record doesn't resolve; almost always the DNS client of one of the controllers |
| 1722 | RPC unavailable: the partner is off, or a firewall between sites has closed 135 or the dynamic ports |
| 1256 | the remote system is unavailable: a secondary status, the real cause shows in the errors of the same partner's other partitions |
| 8453 | replication access denied: the controller account, time or rights on the partition |
| 8606 | insufficient attributes to create an object: lingering objects, part 18 |
| 8614 | the controller hasn't replicated for longer than the tombstone lifetime; replication with it is blocked, part 18 |
| -2146893022 | the target principal name is incorrect: most often the KDC has an outdated password of the source controller's account, less often a wrong DNS record or SPN |
/syncall — start replication of everything with everyone: repadmin /syncall /AdeP (A — all partitions, d — show names instead of GUIDs, e — across site boundaries, P — push: send to partners, not just pull). Run it when you need a change to spread now rather than on the schedule. For a single target: /replicate dc2 dc1 DC=corp,DC=example,DC=com pulls one partition from one controller to another.
/showobjmeta — an object's metadata, the same as Get-ADReplicationAttributeMetadata, but from a tool that's available everywhere:
PS C:\> repadmin /showobjmeta dc2 "CN=Alice Smith,OU=Sales,OU=Departments,DC=corp,DC=example,DC=com" | Select-String 'pwdLastSet| mail$'
12790 Office\DC1 41190 2026-10-15 09:30:11 3 pwdLastSet
12702 Office\DC1 40955 2026-10-14 16:21:07 2 mail
The columns: the local USN on this controller, where the change was born, its USN there, the time of the originating write, the version, the attribute. mail has originating USN 40955 on dc1 and local USN 12702 on dc2 — different counters, as described above.
The same in PowerShell: Get-ADReplicationPartnerMetadata -Target dc2 -Scope Server, Get-ADReplicationFailure -Target dc1, dc2, and Sync-ADObject -Object $dn -Source dc1 -Destination dc2 for a single object.
SYSVOL and DFS-R
SYSVOL isn't replicated by the directory but by the DFS Replication service: the Domain System Volume replication group, the SYSVOL Share folder, with all controllers as members. This is block-level file replication with compression (RDC, remote differential compression), on its own schedule (continuous for SYSVOL) and with its own state database in C:\System Volume Information\DFSR.
Checks and diagnostics are done with the dfsrdiag utility and the DFSR module:
PS C:\> dfsrdiag replicationstate /member:dc2
Summary
Active inbound connections: 0
Updates received: 0
Active outbound connections: 0
Updates sent out: 0
Operation Succeeded
PS C:\> @(Get-DfsrBacklog -GroupName 'Domain System Volume' -FolderName 'SYSVOL Share' -SourceComputerName dc1 -DestinationComputerName dc2).Count
0
Get-DfsrBacklog lists the files that haven't yet made it from one member to another — in one direction only and no more than 100 (with -Verbose, their total count too); an empty list means everything has arrived. dfsrdiag pollad makes the service re-read its configuration from the directory, which is needed after a membership change. The events that tell you about health: 4614 — SYSVOL is initialized and waiting for initial synchronization with a partner (normal for a new controller in its first minutes), 4604 — initial synchronization is complete; if 4614 isn't followed by 4604 for hours, the partner is unavailable or not synchronized itself. The first controller in a domain logs a single 4602 instead of this pair: it has nobody to synchronize with, and its copy is considered the source. And one you run into after a power failure: 2213 — the DFS-R database was shut down uncleanly, and the service has stopped replication on the volume until it's resumed. The event text gives the command wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="…" call ResumeReplication (in PowerShell the where condition goes in single quotes), but WMIC is a deprecated feature on demand in Windows Server 2025, and PowerShell does the same: Get-CimInstance -Namespace root\MicrosoftDFS -ClassName DfsrVolumeConfig -Filter "VolumeGuid='…'" | Invoke-CimMethod -MethodName ResumeReplication. After that, events 2212 and 2214 appear in the log. This is protection against replicating damaged data, and in the backup part we'll see its big brother — the authoritative restore of SYSVOL.
A mismatch of policy versions between the directory and SYSVOL is checked by gpotool from the old resource kits or by dcdiag /test:sysvolcheck /test:advertising; the main tool here is Get-GPO with its DSVersion and SysvolVersion, which we'll get to in the group policy part.
The controller's DNS client
Now the most important practical rule of this part. During promotion the wizard edits the DNS server list itself: for the first controller in the forest it leaves only 127.0.0.1, and for an additional one it appends it to the end of the list. It should be different:
PS C:\> Set-DnsClientServerAddress -CimSession dc1 -InterfaceAlias Ethernet -ServerAddresses 192.168.1.11, 192.168.1.10
PS C:\> Set-DnsClientServerAddress -CimSession dc2 -InterfaceAlias Ethernet -ServerAddresses 192.168.1.10, 192.168.1.11
The partner first, itself second. The reason is the startup order. At startup the directory service has to find its partners and complete initial synchronization before it declares itself ready (isSynchronized); for that it needs DNS. The DNS service at startup loads zones from the directory, and until the directory is ready it has no zones — it waits (event 4013 from part 7). A controller whose DNS client points only to itself ends up in a loop after a reboot: the directory waits for DNS, DNS waits for the directory. After a timeout the directory gives up, starts without synchronization, DNS loads the zones, and everything works — but the first replication attempts are recorded with error 8524, and in repadmin /showrepl this error will hang around until the next successful cycle, scaring whoever looks. With the partner first, the controller resolves names through it at startup and synchronizes right away.
The second address — its own — is needed for when the partner is unavailable. Microsoft allows both this layout and the reverse one (itself first, the partner second), and advises switching a new controller to its own DNS only after replication has gone through in both directions. The own address can also be given as 127.0.0.1 — the BPA analyzer only requires that the loopback isn't first — but not twice: its own IP and 127.0.0.1 in one list are the same server. In a site with a single controller, where there's no partner, only its own address remains, in first place, and that's the rare case where error 8524 after a reboot is unavoidable and harmless.
Along the way, let's finish what we postponed in earlier parts: forwarders on dc2, the second DNS server in the DHCP option, and the DHCP role on dc2 with failover from part 8. Failover doesn't replicate server-level settings, so the DNS and domain options and the DNS registration settings are set on dc2 separately:
PS C:\> Set-DnsServerForwarder -ComputerName dc2 -IPAddress 192.168.1.1
PS C:\> Install-WindowsFeature -ComputerName dc2 -Name DHCP -IncludeManagementTools
PS C:\> Add-DhcpServerSecurityGroup -ComputerName dc2
PS C:\> Invoke-Command dc2 { Restart-Service DHCPServer; Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\ServerManager\Roles\12' -Name ConfigurationState -Value 2 }
PS C:\> Add-DhcpServerInDC -DnsName dc2.corp.example.com -IPAddress 192.168.1.11
PS C:\> Set-DhcpServerDnsCredential -ComputerName dc2 -Credential (Get-Credential CORP\svc-dhcp-dns)
PS C:\> Set-DhcpServerv4DnsSetting -ComputerName dc2 -DynamicUpdates OnClientRequest -DeleteDnsRROnLeaseExpiry $true -UpdateDnsRRForOlderClients $true
PS C:\> foreach ($s in 'dc1', 'dc2') { Set-DhcpServerv4OptionValue -ComputerName $s -DnsServer 192.168.1.10, 192.168.1.11 -DnsDomain corp.example.com }
PS C:\> Add-DhcpServerv4Failover -ComputerName dc1 -PartnerServer dc2 -Name Office-failover -ScopeId 192.168.1.0 -LoadBalancePercent 50 -SharedSecret (Read-Host 'Shared secret') -Force
-Force in the last command is there because with -SharedSecret the cmdlet otherwise asks for confirmation.
For IPv6 it's the three commands from the "Two servers without failover" section of part 9: the same scope on dc2 and both controllers in the DNS option on both servers.
All these commands are run on dc1 against the other server via -ComputerName: the DnsServer and DhcpServer modules can do this by themselves, over WinRM, and in part 15 we'll look at how.
A hands-on look
Replication of a single change, step by step. We change an attribute on dc2 and watch it appear on dc1:
PS C:\> Set-ADUser alice -Server dc2 -OfficePhone '+1 555 0101'
PS C:\> Get-ADUser alice -Server dc1 -Properties OfficePhone | Select-Object OfficePhone
OfficePhone
-----------
PS C:\> Start-Sleep 20; Get-ADUser alice -Server dc1 -Properties OfficePhone | Select-Object OfficePhone
OfficePhone
-----------
+1 555 0101
PS C:\> repadmin /showobjmeta dc1 "CN=Alice Smith,OU=Sales,OU=Departments,DC=corp,DC=example,DC=com" | Select-String telephoneNumber
41305 Office\DC2 12840 2026-10-15 11:20:33 1 telephoneNumber
Fifteen seconds of notification delay plus the replication itself. In the metadata on dc1 the change is marked as born on dc2 with USN 12840 and written locally under USN 41305. If the same attribute had been changed on dc1 during those 15 seconds, both changes would have version 1, and the later one by time would win.
The exchange itself in packets. Replication goes over RPC: the client (the controller pulling the changes, here dc1) asks the partner's Endpoint Mapper on port 135 where the DRSUAPI interface (e3514235-4b06-11d1-ab04-00c04fc2dcd2) is listening, and connects to a dynamic port. In Wireshark, from a capture on dc1:
No. Source Destination Protocol Info
1 192.168.1.10 192.168.1.11 EPM Map request: drsuapi
2 192.168.1.11 192.168.1.10 EPM Map response, Tower: ncacn_ip_tcp:192.168.1.11[49668]
3 192.168.1.10 192.168.1.11 DCERPC Bind: call_id: 2, DRSUAPI V4.0, auth: Kerberos, level: Packet privacy
4 192.168.1.11 192.168.1.10 DCERPC Bind_ack
5 192.168.1.10 192.168.1.11 DRSUAPI DsBind request [encrypted]
6 192.168.1.10 192.168.1.11 DRSUAPI DsGetNCChanges request [encrypted]
7 192.168.1.11 192.168.1.10 DRSUAPI DsGetNCChanges response [encrypted]
DsGetNCChanges — "give me the partition's changes after such-and-such USN" — is replication itself; all the content is encrypted at the RPC level (packet privacy) with Kerberos authentication. Port 49668 is from the dynamic range, and for a firewall between sites it can be pinned:
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'TCP/IP Port' -Value 50000 -Type DWord
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -Name 'DCTcpipPort' -Value 50001 -Type DWord
After a reboot replication will use 50000 and Netlogon 50001. DFS-R, which replicates SYSVOL, has its own dynamic port, pinned with Set-DfsrServiceConfiguration -RPCPort 50002. Then between sites it's enough to open 135, 50000–50002 and the rest from the port table in part 3.
Who is in which site from the client's point of view:
PS C:\> nltest /dsgetdc:corp.example.com /site:Branch
DC: \\dc1.corp.example.com
Address: \\192.168.1.10
...
Dc Site Name: Office
Our Site Name: Branch
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST FULL_SECRET WS DS_8 DS_9 DS_10 DS_13 KEYLIST
The Branch site exists, there are no controllers in it yet, and the Locator returned the nearest one by link cost — from Office, without the CLOSE_SITE flag. In the next part the branch gets its own.
Directory Service log events that tell you about replication problems before repadmin shows them:
| Id | What |
|---|---|
| 1311 | the KCC couldn't build the topology: a site not linked to the others, no available bridgehead |
| 1865 | a site isn't connected to any other: no site link includes it |
| 2087 | the partner can't be found in DNS, and replication failed (the same 8524 seen from the log side): with a detailed list of what exactly didn't resolve |
| 2088 | the partner can't be found in DNS, but replication succeeded through the NetBIOS name or FQDN: DNS still needs fixing |
| 1925 | couldn't establish a replication link with the partner |
| 2042 | there has been no replication with the partner for longer than the tombstone lifetime; further replication with it is prohibited |
| 1988 | a lingering object was detected on the partner |
Sources
- Install Active Directory Domain Services and Install-ADDSDomainController — promoting an additional controller and the cmdlet's parameters;
- ifm (Ntdsutil) — creating IFM installation media;
- Active Directory Replication Concepts and How the Active Directory Replication Model Works — USN, invocationID, the vectors, conflicts, urgent replication;
- How Active Directory Replication Topology Works — the KCC, the ring and the three-hop rule, the ISTG, bridgeheads, site links and site link bridges, the SMTP transport;
- Introduction to Active Directory Replication and Topology Management Using Windows PowerShell and Advanced Active Directory Replication and Topology Management Using Windows PowerShell — the
*-ADReplication*cmdlets; - Set-ADReplicationSiteLink and Determining the Interval — interval, cost and notification on site links;
- Repadmin — the
repadminsubcommands; - Troubleshooting Active Directory Replication Problems and Troubleshoot common Active Directory replication errors — log events and error codes, with a link for each error;
- Active Directory replication error 8524 — the DNS failure during replication;
- Recommendations for DNS client settings — the controller's DNS client and DNS "islands";
- Force synchronization for DFSR replicated sysvol and Troubleshoot missing SYSVOL and Netlogon shares — events 4614, 4604 and 4602,
dfsrdiag pollad; - DFSR event ID 2213 and Get-DfsrBacklog — stopped replication after a crash, and the backlog;
- Restrict Active Directory RPC traffic to a specific port, Set-DfsrServiceConfiguration and Configure firewall for AD domain and trusts — fixed ports and the firewall;
- MS-DRSR: IDL_DRSGetNCChanges — the call that is replication itself;
- Deploy DHCP Using Windows PowerShell and DHCP failover — the DHCP role on the second controller.
Two controllers, two sites, and nobody in the second site yet. In a branch office with ten employees, one cabinet without a lock and a link that goes down once a month, you don't want to put a full controller: it holds the passwords of every user in the domain. There's a special kind of controller for that.
Next — part 11: the read-only domain controller. How an RODC differs from a regular one, how the password replication policy works and what happens when a branch user logs on for the first time, which attributes never reach an RODC, who the delegated administrator is, and how DNS lives on an RODC.
Only registered users can leave a comment.
Sign in or register to leave a comment.