Because of the nature of Active Directory replication, it is possible that conflicts could occur if one domain controller accepted an originating update, while another received an originating update on the same object (for example a user). First of all, Active Directory helps to reduce the possibility of this by replicating at the attribute level. As such, one domain controller could update a user’s password and another his postal code and there would be no conflict, even thought changes were made to the same object. In the event that there is a conflict, these are solved using three possible methods (also referred to as globally unique stamps), in the order listed below:
1. Version numbers – all attributes start with their version number set to 1. Every time an update occurs, this number increases by one, and a higher version number always wins. However, this also means it is possible that 2 domain controllers could update the numbers to the same value, which means a conflict still exists.
2. Timestamps – In the event that version numbers are the same, timestamps are used, with the time of the update on the domain controllers being compared. The most recent update (say 2:10pm over 2:07pm) always wins.
3. Server GUID – In the highly unlikely event that a conflict still exists, the globally unique identifiers of the servers making the originating update are compared, the one with the higher value wins.
There are a couple of cases that may still cause problems. One example is with orphaned objects. Lets say that you were to create a user in an OU called Sales, and then a minute later the Sales OU was deleted on another domain controller before replication had occurred. In this case, the parent object of the user would no longer exist, and the user would be moved to the LostandFound container.
In situations where two objects are created on different domain controllers that have the same distinguished name, you’ll always be able to tell, because one of the objects (the one with the higher stamp from the above list) retains the name while the lower of the two will exist with a name that appears as the object’s relative name + the characters “CNF:” + the GUID of the object.
