Windows NT uses a single-master replication model, wherein the PDC is the only domain controller in a domain with a writeable, master copy of the accounts database. The OS writes changes to the PDC, and the PDC replicates these changes to all BDCs in the domain. Windows 2000 (Win2K) uses a multimaster replication model, wherein all domain controllers in a domain retain a replica of the domain’s database. The multimaster model has no master copy of the accounts database per se, because all domain controllers are peers. You can update any domain controller in a domain, and that domain controller will replicate those changes to all other domain controllers within the domain.
Multimaster replication provides better fault tolerance because it doesn’t rely on one master copy. A failed domain controller in a Win2K domain is less likely to have the serious consequences that a failed PDC can have in an NT domain.
Types of Updates
Active Directory (AD) updates consist of originating updates and replicated updates. Originating updates, which include adding, deleting, or modifying objects, or changing the attributes of existing objects, replicate to other domain controllers as replicated updates. If, for example, you change a user’s password at a domain controller called Mars, the update takes hold at Mars and then replicates to other domain controllers known as Jupiter and Saturn. The update you made at Mars is the originating update, and the subsequent updates at Jupiter and Saturn are known as the replicated updates.
Update Sequence Numbers
When you create a new object, such as a new user, or modify an attribute of an object, such as a user’s phone number, the domain controller generates a unique stamp that replicates along with the values you updated. In addition, the updated domain controller assigns an Update Sequence Number (USN) to the object. Each domain controller in a domain maintains a USN table to track replication updates. When a domain controller writes a change to the AD, it also writes the associated USN. The USN grows incrementally after each originating or replicated update.
Suppose you have three domain controllers in a domain. Each domain controller has a USN table containing the USN values for all the other domain controllers in the domain. The USN table for domain controller Mars might look like this:
| From Domain Controller Jupiter | From Domain Controller Saturn | |
| Highest USN Received by Domain Controller Mars | 15 | 20 |
Let’s say you make 10 originating updates on Saturn, causing the USN on Saturn to update to 30. The next time Mars receives notification that Saturn has changes, it will request that Saturn send changes above 20. The resulting replicated updates on Mars will cause the USN table to look like this:
| From Domain Controller Jupiter | From Domain Controller Saturn | |
| Highest USN Received by Domain Controller Mars | 15 | 30 |
Timestamps and Version Numbers
AD also writes timestamps and version numbers with attributes. AD doesn’t really use timestamps for replication, but as tiebreakers to resolve update conflicts. The version number initializes when an attribute writes to an object the very first time. AD increments the version number after each subsequent originating update. Unlike the USN, the version number stays with the attribute throughout its lifetime, and it’s not tied to a specific domain controller.
Resolving Conflicts
Certain situations cause conflicts that the AD must resolve. If, for example, a replicated version number matches the locally stored version, you’ll encounter a collision. Regardless of which number is the replicated version and which is the stored version, AD will always use the higher version number.
If you modify the same object at more than one domain controller at about the same time, you’ll see a collision that the domain controller will resolve with the timestamp. If the domain controller receives an update with the latest timestamp, it will apply it; otherwise, it will discard it.
Although it’s highly unlikely that a domain controller will receive an update with the same version number and the same timestamp as a local copy, it’s technically feasible. In such situations, AD resorts to the Globally Unique IDentifier (GUID) to resolve the conflict. Every object in the AD has a GUID, and this final tiebreaker ensures the ultimate resolution of update conflicts.
Efficient Mechanism
AD has an efficient mechanism in place that minimizes conflicts and ensures that the same update always takes place on all domain controllers. AD minimizes collisions by replicating changes at the attribute level, rather than at the object level. As a result, you can modify attributes such as an email address and a phone number for the same user object at the same time, and you won’t cause any conflicts.
Attribute-level replication also reduces replication traffic. When you update an object in NT, the entire object replicates from the PDC to all BDCs in a domain. Because changes replicate at the attribute level in Win2K, the entire object doesn’t need to replicate—which is good because some objects can have dozens of attributes. Replicating only the attributes of an object uses significantly less network bandwidth.
