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

Replication crash proofing: The battle for change

Sometimes two admins might make a change to Active Directory at the same time. Here is one way to make sure that replications won't disagree with each other in those instances.

If two administrators, each connected to a different domnain controller (DC), both tried to change the same user record at about the same time, Active Directory (AD) will decide who's change rules. This tip offers a (kind of sneaky) way to increase the odds that your change wins.

Every object in Active Directory contains version number and modified attributes. These attributes determine how Active Directory reacts during a "replication crash".

Imagine a network with 5 DCs, named DC1 through DC5. Now consider what happens when you change a user record to update the user's manager.

If this is the first change since the record was created, the version number changes from 1 to 2, and the modified attribute is set to the current time according to the DC to which you are connected.

Now replication begins, and by default AD will treat replication within a 5-DC network as a virtual ring, with DC1 connected to DC2, DC2 to DC3, and so on, with DC5 connected to DC1.

Let's say you changed the record on DC3. Come replication time, DC3 tells DC4 about the change, and also tells DC2. Next replication time DC2 tells DC1 and DC4 tells DC5. Next replication time DC5 will talk try to update DC1 (or vice versa) but they will realize they already heard about the change through the back door.

Now consider what happens if you (connected to DC3) change the record at about the same time someone else (connected to, say, DC1) changes the same record. Somewhere down the road there's going to be a "replication crash" when two DCs try to update the same record with different changes.

Here's how AD handles the conflict:

If the version numbers are different, the higher version number wins.
If the version numbers are the same, the later modified timestamp wins.

So, if the user record being altered in this example hasn't been modified in a while (thus all AD replicates agree) then the "winner" normally depends on random variation in time clocks.

If you want to decrease the possibility of a replication crash voiding your modification, you can deliberately increment the version number of the user record you are modifying. If the new manager's name is Mike, for example, you could first change the name to Michael (version 2) then change it to Mike (version 3). Any other pending update will get overruled by your higher-version copy. Of course I suppose there's always the possibility that some other admin incremented a version higher than yours, but if you've got to worry about that sort of problem, then the answer is probably professional counseling for your admins.

Kevin Sharp is a registered professional engineer, writer and yoga teacher living in Tucson, Arizona, and gains his expertise from a variety of professional activities. His writing interests have produced books and articles on the economic impact of technology on manufacturing and distribution organizations.

Dig Deeper on Windows systems and network management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.