Florian’s Blog

That question came up a couple of weeks ago in the Microsoft Forums. The user simply wanted to track down the DC that originally made a change (”originating change”) to an attribute - and replicated it out to all other DCs (”replicated change”).

The great places the TechNet Forums and Newsgroups are, there are smart folks answering question (Thanks Mike, Richard, Santhosh and Syed!). So in this case, the team came up with some answers:

• Use/enable AD DS auditing and track the change down in the Security event log
• Look at a third party product that would find that info (I assume most of them will consume the event log anyway, so auditing is a requirement)
• Build a small script that loops through the list of available DCs and compare the changed object’s “whenChanged” attribute.

Answer 1 is probably the most straight-forward, as auditing these changes give you all that info. It’s a powerful Windows built-in facility. If you feel like needing additional help in cramming through the Security event logs, you might want to use EventComb (http://support.microsoft.com/kb/308471, http://www.microsoft.com/downloads/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E) to collect the event logs off multiple DCs.

Scripting the solution is a great idea, too — if you’re skilled to do that, it should be an easy job for you to build a list of available DCs and take that list to connect to each and every DC therein and ask it for the object’s whenChanged date. The whenChanged date differs from DC to DC - that is because the DC sets the “whenChanged” timestamp once it processes a change to that object _locally_. whenChanged isn’t replicated but DC-local correct for the object. That leads us to the conclusion that (a) only the DC that made the originating change on the object has the “correct” timestamp (b) the DC with the “oldest” whenChanged timestamp - assuming that replication is healthy and working! - is the one that processed the change.

Here’s a picture that shows what happens when a change gets replicated. Other DCs will notice the change, adjust the whenChanged timestamp but only the “Originating DC/DSA” has the _correct_ timestamp. So DC-1 is the “Originating DSA” here.

The script won’t work if, short after the change of our interest took place, someone performed a different change on the same object on a different DC. Our whenChanged trick would just not work then. Again, if we have auditing enabled, we’d have caught that, pretty well.

There’s another way to get to know what DC performed a change on an object’s attribute and then replicated it out. That piece of information is stored in an object’s metadata. Since AD keeps track on metadata on attribute level (USN, timestamps, version number), we get that info from there. What we’re interested in, is the “Originating DSA” here. That’s the DSA (the directory system agent, well-known as “a DC”) that performed the change.

All we need is our powerful friend repadmin with its switch /showobjmeta. It shows a well-equipped list of attributes that with their USN, version number, timestamp of last change and — the “Originating DSA”:

So, I’ve just changed my employeeNumber to some other value. I did that on DC-2008R2 as you can see from the “Originating DSA” column. I focussed “DC-2008″ in my repadmin command, so its a different DC that replicated the change in. The “Orig. Time/Date” column shows the _correct_ change time of the originating DC, _not_ the whenChanged timestamp of the DC you’re currently targeting to perform the repadmin query.

Cool, huh? :-)

By the way, in case you’re wondering: those fancy GUIDs in the “Originating DSA” column that I have for my account here in the screenshot come from a legacy-DC. The GUID belongs to a DC that no longer is in my domain. That DC used to be “DC2″, a virtual machine that I de-promoted a while ago in order to be “FFL/DFL-2008 ready”. The GUID is displayed because repadmin couldn’t put the “friendly” name in there.