Monday, August 25, 2008

Surprising Change When Standing up a New Domain controller

We had a bit of a surprise when we started our project to replace aging domain controller hardware with new hardware.  Perhaps we should have anticipated it, but we didnt.

Essentially, when we stood up a new Domain Controller, we found that all the objects in the AD database on that system got a new modifyTimeStamp based upon when that object was created/added to the new database on that specific system.

The following is a more detailed explanation.

Effect of a DC Addition on the modifyTimeStamp Attribute

Issue:  the modifyTimeStamp attribute on all Active Directory (AD) objects is reset to a time specific to the generation of the AD database on a new Domain Controller (DC) added to the domain.

Impact:  Some folks use the modifyTimeStamp attribute on objects in AD to determine when an object, especially a computer object, is stale or no longer used.  Scripts using this attribute will not be accurate when referencing a new domain controller because of the reset of this attribute when the AD database is created on the new DC.

Explanation:  When a new DC is brought online using DCPromo, the DC generates a new local copy AD database and builds it by replicating all the necessary data from other DC’s in the domain.  During this process, all objects are given a modifyTimeStamp of the date and time when the DC initially replicated and added that object to its local database.  Since Windows 2003 uses linked value replication, the modifyTimeStamp and other attributes are then given a version number of 1 to avoid excessive replication of this and other attributes back again to other DC’s (i.e. a version number of “1” indicates the value has not changed and therefore does not need to be replicated to any other DC’s).

The net result is that after a new domain controller is brought online, the modifyTimeStamp will vary from DC to DC, depending upon when the DC was promoted and the AD database created. 

Example: was promoted on August 1, 2008 at 3PM.  It sets the modifyTimeStamp on all objects in its copy of the AD database to 8/1/2008 @ 3:00PM. 

MyDC4. was promoted on August 5, 2008 at 11:00AM.  It sets the modifyTimeStamp on all objects in its copy of the AD database to 8/5/2008 @ 11:00AM.

On August 6, 2008, if you look at the two DC’s you see:

Objects on will show the modifyTimeStamp of 8/1/2008 @ 3PM

Objects on MyDC4. will show the modifyTimeStamp of 8/5/2008 @ 11AM

Any objects which subsequently changed through normal usage will show the updated modifyTimeStamp when they were used, e.g. 8/6/2008 @ 2PM on both DC’s.


Replication Impact:  Because the modifyTimeStamp’s version number is set to 1, the reset modifyTimeStamp date will not be replicated to other DC’s in the domain as additional DC’s are promoted.  Only subsequent modifications of the object itself through normal usage will cause the modifyTimeStamp to be updated, the version number incremented, and the attribute then replicated.

Hence, over time, as the objects are modified during normal operations, the modifyTimeStamp and other attributes will be updated and replicated normally.

Amy G. Padgett