I have a lab environment, running on two SLES 10 SP1 servers, with eDirectory 8.8 SP1, Identity Manager 3.5.1. Each server is running 6 eDirectory instances. There are Production, Quality Control, and Development environments, with two tree per environment, thus the 6 eDirectory instances per server. Two of the trees are linked via eDirectory to eDirectory drivers.

I have about 6000 users in the system. The authentication tree is automatically built out of information in a Location code, so I need to delete and recreate it, each time the logic for location placement changes.

I needed to clean the tree up, and previously I had been disabling the eDirectory driver in the Authentication tree, and bulk-deleting every object in the Users container. I disabled the driver, thinking that letting Identity Manager process the 6000 delete events, along with actually deleting them, would take too much time to clear up. When a driver is disabled (which is different than being stopped), the Event engine does not queue up events in the TAO file. This way, the 6000 delete events would not have to be processed.

At the end of a day, I decided to see how long it would take Identity Manager to process the deletes, since there is a Veto of delete operations in the Subscriber Event Transformation rule. This is pretty darn early in the rule set, so it should not take a lot of overhead to process and then veto each rule.

To recursivly delete thousands of users in over 100 containers, without going through the pain of emptying each container first, I used the free Ldap Browser tool http://www-unix.mcs.anl.gov/~gawor/ldap/ and selected the parent containers, and then deleted them. The tool presents a confirmation box that allows you to specify "delete children" as well. This is a huge timesaver compared to ConsoleOne or doing it via an LDIF file.

The delete process via Ldap browser took about three minutes.

I expected to see hundreds to thousands of events piling up in the TAO file. I was shocked to see that Identity Mangager not only kept up (Trace level of 3, on most of the drivers, so not running in an efficient mode), but I also never saw any events remain in the .TAO file.

Very neat to see! The obvious question that the previous statement brings is: How did I see what was in the .TAO file while the driver was running? Funny you should ask that!

The Identity Manager 3.6 Milestone 1 plugins have been made available. They are not released for production yet, but they are available. Check these Blog entries for more info on some of the features:

http://www.novell.com/coolblogs/?p=1137
http://www.novell.com/coolblogs/?p=1015

The second entry shows how in the new plugins you can look at the cache file (TAO file) of a running driver to see the pending events, and what number and type of event is pending.

For this feature alone I completly recomend switching to this new plugin. There are MANY more really nice User Interface improvements made to the plugin as well.

Well done, overall!