For a long long time I needed to deep dive in current project I’m involved to one of my favorite topics, on-premises AD DS replication.
Below is simplified version of the sequence between source and destination domain controllers when the source initiates replication by sending a change notification (picture from TechNet)
Domain Controllers use Update Sequence Numbers aka USNs to determine what changes they needs to replicate. Source determines changes that have been received and destination uses USNs to determine what changes it needs to request.
USN is found from each Domain Controller highestCommittedUsn attribute on the rootDSE object. At the start of each update transaction (originating or replicated), the DC increments its current USN and associates this new value with the update request.
You can find highestCommitedUsn number with PS “Get-ADRootDSE” or with ADSIEdit.msc
The following series of diagrams (from Microsoft Technet pages) illustrates the replication for a single object and one of its attributes from creation to replication.
- User object is created on domain controller DC1 – USN 4710.
- When the object is created, the local USN of 4711 is assigned to each attribute of the user object, and the current USN for the domain controller increments from 4710 to 4711.
- Because the object has not yet changed, the value of its uSNChanged attribute is the same as its uSNCreated attribute 4711.
Replication-related data on DC1 when user object is created
Replication-related Data on DC2 when a New User Object is replicated from DC1
The following information is transferred in the metadata of an updated attribute value from the source domain controller to the destination domain controller:
- The originating USN value for the updated attribute, which is the USN assigned by the domain controller on which the update was made
- The stamp for resolving conflicts
The next diagram illustrates the change in the replicated object on DC2 when someone changes the password of the object on that domain controller.
- The current USN on DC2 has increased from 1746 to 2453.
- The update request changes the password and increments the current USN to 2453 on DC2.
- The request also sets the password attribute’s originating USN and local USN to 2453 and creates a new stamp for the password value.
- The version number of this password’s stamp is 2, which is one version number higher than the version of the previous password.
Replication-related Data on DC2 after the User Password Value Has Been Changed on DC2
In the next diagram, the changed password is now replicated back to the original domain controller
- Current USN has increased to 5039.
- The replicated update increments the current USN of DC1 to 5040.
- The per-attribute originating USN and stamp (version, originating time, originating DC) are replicated from DC2 to DC1, and the per-attribute local USN and per-object uSNChanged values are set to 5040.
Replication-related Data on DC1 after the Password Change Has Replicated to DC1
- Up-to-dateness vector. The current status of the latest originating updates to occur on all domain controllers that store a replica of a specific directory partition
- Tracking attributes to send for replication
- High-watermark (direct up-to-dateness vector). The latest update (originating or replicated) to a specific directory partition that has been received by a destination from a specific source replication partner during the current replication cycle
- Tracking objects to send for replication
Values can be seen with following commands:
- up-to-dateness vector in the output of the repadmin /showvector
- You can see the high-watermark in the output of the repadmin /showreps /verbose command. Look for lines that begin with “USNs:”. The high-watermark USN is the number that is followed by “/OU”.
Guideline for these vectors and tables are
- For a specific directory partition, a domain controller maintains a high-watermark value for only those domain controllers from which it requests changes (direct replication partners)
- But it maintains an up-to-dateness vector entry for every domain controller that has ever performed an originating update, which is typically every domain controller that holds a full replica of the directory partition.
Domain controllers uses different values to determine conflicts, including version number, originating time and originating DSA.
When these stamps are compared:
- Version is the most significant
- Followed by originating time and originating DSA
- If two stamps have same version number, originating time almost always breaks the tie.
- If originating time is identical then originating DSA breaks the tie in arbitrary fashion.
Lot’s of things happening underneath the hood. When troubleshooting replication in large environment knowledge about replication model helps a lot.
Deep dive documentation and material above found from link below: