- the exports are the only place for ILM updates to connected directories – the ILM sync process is supposed to be an internal ILM activity which should be able to be done safely (e.g. via preview) without affecting any connected directories
- if someone performs a preview or a sync they could be unaware that updates are actually taking affect before the export
- these sorts of tasks are often the activities most likely to fail – trying to troubleshoot failures in provisioning is a lot more difficult than running an "out of bounds" process which can be run at will as many times as necessary.
- … I could go on .
- employ third party workflow (+RBAC) tools such as Omada IM which complement the sync/provisioning performed by ILM
- write an Extensible Management Agent (xMA) to perform the work in the export step
- write an Extensible Management Agent (xMA) to interface to a workflow engine (e.g. SharePoint (WSS) list) to initiate a workflow task (e.g. Nintex, or K2) which incorporates the desired activities
- write an "out of bounds" process to "run along behind" a run profile execution and perform custom activities on freshly updated directory data.
Although all of the above are appealing options, the last option was the one I adopted because a workflow engine wasn’t at my disposal for this particular client (hopefully it will be though). What I did have, however, was Event Broker and its SDK to play with. Having written a few of these plugins before, I was able to implement some MSDN library code that could be configured in the plugin XML and executed (by the Event Broker service) as a "post processing" step in the "Outgoing" Event Broker OpList.
In this particular case I used an Event Broker "watermark" (much like those used in an ILM xMA) to store the timestamp of the last created AD user (whenCreated attribute). Whenever an export to AD succeeds, this plugin checks AD for any new users since that timestamp, checks to see if file share(s) are required for the new user based on user attribute data, and if required creates and ACLs the file shares. It then updates the watermark for next time … meaning that the cost of executing the plugin is whatever the cost of an LDAP search happens to be on the (indexable) whenCreated attribute.
Works like a charm … wonder if anyone else might want to use this? I expect to be implementing a few other activities in the same way – including some post-deprovisioning tasks (mailbox archiving, file share archiving, group membership removal, etc.)