| Platform SDK: Active Directory, ADSI, and Directory Services |
The following does not describe how Active Directory replication works – instead it gives a much simpler model, which is equivalent from an application programmer's perspective.
All updates to Active Directory are performed using LDAP requests that create, modify, or delete one object for each request. A single request can set or modify any number of attributes on an object.
An update request is processed as an atomic transaction at some domain controller (DC). Either the entire update happens or none of it does. If the requester receives a successful response to an update request, that entire request has succeeded (committed). That's called an originating write. You can't group multiple LDAP requests into a single larger transaction.
As part of performing an originating write, a DC computes a "stamp" for each new or modified attribute value, and attaches this stamp to the value so when the value is replicated, the stamp is replicated too. The new stamp is guaranteed to be different from all other stamps, and in case of an update the new stamp is always larger than the stamp on the old value at that DC.
Occasionally, a DC selects the set of objects that have changed since the last time the DC performed replication. Then, for each object, it sends a single message to all other DCs containing all the current values of attributes changed since the last time the object was replicated. Replication messages are reliable and are delivered in order but may take a long time to be delivered.
When one DC receives a replication message from another DC, it processes it as follows: For each modified attribute, if the stamp on the value in the replication message is larger than the stamp on the current value, the DC applies the update; otherwise the DC discards the update. Each replication message is applied as an atomic transaction, just like an originating write.
That's the complete model of how Active Directory replication works. Key properties of this model:
The model does not guarantee the replication ordering of changes made to different objects. Don't write applications that assume changes will be replicated in originating-write order. The model does not guarantee that if an attribute of an object is changed twice, both values will be replicated: Replication sends only the current value at the time of replication.
The model differs from reality in several ways that only affect performance. For instance, Active Directory actually sends replication messages containing the changes to multiple objects, but it processes the contents of such a multi-object message as if it were a series of single-object messages. And Active Directory does not perform point-to-point replication as described in the model, but instead performs a more complex and more efficient transitive replication that is functionally equivalent to the model.