Wednesday, August 22, 2007

DirSync Control - SearchResult Without ObjectClass

The DirSync control is super-easy to use in .NET 2.0 with System.DirectoryServices. It is really as easy as adding one line to your regular DirectorySearcher.
DirectorySearcher searcher = new DirectorySearcher();
searcher.DirectorySynchronization = new DirectorySynchronization();

Once your query is done you can get the cookie quite easily:
Byte[] cookie = searcher.DirectorySynchronization.GetDirectorySynchronizationCookie();

I was happily using this in an XMA when I ran into what I suspect is a bug. ILM requires the objectClass when you import deleted objects. The dirSync control dutifully shows me the objectGuid (my MA's anchor attribute) then I ask it for the objectClass attribute. The attribute is there on the tombstone, I can see it using LDP. The attribute is in the DirectorySearcher's PropertiesToLoad collection, but sometimes when I ask for the objectClass it just isn't there.

Turns out this repros consistently. If the first SearchResult returned by the DirSync search is a delete then the objectClass attribute will not be present in the SearchResult.Properties collection. It will be there for the remaining SearchResult objects, but not the first.

The workaround for my MA was to put the DN back together using the 'name' and 'lastKnownParent' attributes on the tombstone, then find the objectClass using a WMI search of the ILM CS. Bugger, but the workaround works.

Attribute Replace or Object Replace?

Recently I ran into a fun issue with a DSML import in ILM. For years I've assumed delta imports for file MAs did attribute level deltas, meaning that the delta import did not require the full attribute set, only the changed attributes. For example, if an object has ten attributes in the CS and your delta file only has one attribute then the import should just update that one attribute and leave the rest alone, right?

Wrong. My assumption was wrong (for years) and the delta import needs to contain the full attribute set. Importing a delta with missing attributes will result in those missing attributes being deleted from the CS object, which will in turn trigger the sync rules and cause re-population if any other MA is contributing.

I ran into this when doing a dirSync delta for the LDAP XMA. The dirSync control neatly tells you the exact attributes that have changed, so you can package them up into the DSML file and hand it over to ILM. On import I was seeing attributes getting whacked which proved that indeed there is a lot to learn ;-) This problem didn't repro with the changeLog deltas we do on the LDAP XMA because for changeLog we just go to the DS to get the real object, instead of parsing the LDIF from the changeLog entry into DSML for our import file. Turns out that is exactly the way to do it for dirSync deltas too.