The constructed attribute modifyTimeStamp always == whenChanged?

So if you read up on modifyTimeStamp – for example here: http://blog.joeware.net/2006/10/03/655/ or at MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/ms677125(v=vs.85).aspx “modifyTimeStamp” is a constructed attribute and as Joe points out it’s based on the “whenChanged” attribute and that assumption is right in 99,9% of all cases, BUT not always – So where is the exception?

The exceptional case

The exception is the DMD or the SubSchemaSubEntry “CN=Aggregate,CN=Schema,CN=Configuration,DC=X“

Let’s have a look with LDP.exe:

So this clearly shows that ‘modifyTimeStamp’ is NOT based on the ‘whenChanged’ attribute for the subSchemaEntry.

How it really works

Let’s agree we have confirmed that, so to the next question, what is it based on? Well it’s based on the last time the in-memory schema cache of the particular DC was updated either during boot or by manually triggering the operational attribute “SchemaUpdateNow:1”

So let’s try that?

So let’s have a look again:

Yes – “modifyTimeStamp” now shows todays date: 2013-06-28 instead of previously 2013-06-21 J

Why it was implemented

So I guess now there is really one good question left, why?

The answer can be found if you read up on RFC 2251 that says:

“modifyTimestamp: the time this entry was last modified” – you can read further on MSDN where you can see what functionality defined in RFC 2551 Active Directory has implemented: http://msdn.microsoft.com/en-us/library/cc223231.aspx