I have had the idea to create an application for viewing the differences between copies of the same ldap directory for a while now. What got me thinking along these lines was the snapshot feature in Active Directory that shipped with Windows Server 2008. The idea was to get the current state of the snapshot and compare that to a domain controller and presenting that to the user in a rather fancy way. But more about the application later, for now we’ll focus on a tiny but important detail that is part of reaching synchronization nirvana.

The .NET framework contains some very nifty functionality that is ideally suited for the above mentioned scenario. With the help of the DirectorySynchronization functionality in the System.DirectoryServices namespace one can retrieve the current state of the snapshot and use that to query the DC for any updates.

One problem with the snapshot feature is that the highestCommittedUSN value in a newly created snapshot is higher than the corresponding value on the DC. The screenshot below illustrating the differing values was taken immediately after creating the snapshot. 

 

The reason this matters is that highestCommittedUSN plays a very central role when it comes to directory synchronization and replication. Basically we’re letting the DC know that we’re currently at 45056 sequence wise and asking it to send us any updates that are more recent than that. Since the DC is at 40986 we won’t get anything besides a rather rude exception and a hefty event log entry.

 

In short: from a replication standpoint the recently created snapshot appears to be more up to date than the DC. To me this seems rather fishy; I’d expect the DC highestCommittedUSN value to be either equal to or higher than the value in the snapshot at any given point in time.

As far as I know this has been filed as a bug so hopefully this will be fixed in the future. :)

The not so elegant workaround

To enable the above mentioned functionality we just have to raise the highestCommittedUSN in the DC. Since the value for this attribute is automatically incremented when objects are created/modified/deleted we’ll do exactly that. The not so elegant part is that we’ll have to do it 4070 times (from the above example: snapshot highestCommittedUSN – DC highestCommittedUSN = 4070).

The first option is to wait for the DC highestCommittedUSN to increase by itself through normal usage. Obviously this might take a very long time if there is little to no activity as is often the case in a test environment. The drawback is that any changes to objects that occur for the next 4070 sequence updates will not be detectable with the DirectorySynchronization approach.

This brings us to the other option which is to artificially raise the DC highestCommittedUSN by performing updates to objects over and over until the sequence number has been raised enough. Personally I chose to modify the title attribute of the administrator account 4070 times at which point the highestCommittedUSN values in both data sources had the same value. There was no special reasoning behind the choice of object to modify, it really doesn’t matter what kind of updates we perform as long as we do it enough times. The point of this approach is to fill the existing gap, if you can call it that, by performing updates that we’re not interested in anyway.

Clearly not the the most elegant solution, it does however resolve the issue at hand.