Problem solve Get help with specific problems with your technologies, process and projects.

Changing attributes to an object: Last writes don't always win

If two people change the same object on different DCs prior to replication occurring, one of these three things can happen.

This tip was submitted to the Tip Exchange by member Mark Bagley. Let other users know how useful...

it is by rating the tip below.

What happens if two people change the same attribute of the same object on different domain controllers prior to replication occurring? A popular belief is that the person who makes the last change to the attribute will win. However, this isn't necessarily so.

When a change is made to an attribute of an object, the attribute is "stamped" with the following information:

  • The change version number
  • The date and time at which the change was made (to the nearest second)
  • The GUID of the DC at which the change was made

    The change version number is a counter that keeps track of the number of times the attribute has been changed. If I change a user's first name 10 times, then this counter will be 11 (assuming that the user was given a first name when it was created).

    When replication occurs between two domain controllers where the same attribute of the same object has been changed on both, the stamps are compared to determine which change will win. The change version number is the most significant field within the stamp. It is checked before the time field in deciding which change will win. If the version numbers are identical, the times are compared. If the times are identical, then the DC GUIDs are compared. The GUIDs can never be equal, so this field is guaranteed to break the deadlock (usually the last DC promoted to the network will have the highest GUID).

    So, we have three scenarios to consider. Say we have two domain controllers with an administrator at each DC making a change to the same user object's first name (Fred).

    If both admins make a single change to Fred's first name at exactly the same time, and then replication occurs, the administrator at the DC with the highest GUID will win.

    If both admins make a single change to Fred's first name one second apart (or more), and then replication occurs, the admin who made his/her change last will win.

    If the first admin changes Fred's name, then realizes that he/she made an error and changes it again; then the second admin changes Fred's name, and then replication occurs, the first admin will win, regardless of whether the second admin made his/her change after the first admin's.

    Does all of this matter?

    In a well connected, highly available network, this will probably rarely be an issue. But it may help to explain the odd unexpected result when multiple admins are making changes to the same object.

    However, in a network where there is significant delay in replication, or a limited replication window, this effect may well need to be considered in determining day to day change processes.

  • This was last published in February 2003

    Dig Deeper on Windows administration tools

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.