I’ve been writing a few new plugins for Event Broker lately on the back of some client requirements for what in the FIM world would be regarded as "custom activities". The latest of these allows an ILM 2007 implementor to provision and ACL file shares based on nominated user attributes in AD (e.g. profilePath and homeFolder). This is a pretty common activity that occurs for a new AD account – along with mailbox provisioning, and notification emails for initial passwords. However, ILM implementers will know only too well that you can’t accomplish this sort of thing with the Active Directory Management Agent alone.

Some might think that it would be reasonable to do this sort of thing in your provisioning logic, but think again! Sure you can put in an external call to a .Net ADSI wrapper to go and do extra work when you provision a new user, but there are several reasons why this is a bad idea. It is one thing to go and read an external directory (e.g. to check if a sAMAccountName has been used), but it’s another thing altogether to perform updates. The most sigificant reasons NOT to do this are probably the following:

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 .

In the ILM 2007 (and MIIS 2003) world there are several accepted approaches to doing these custom activities:

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.)