Well that’s satisfying … today at the ILM2 course I found that Event Broker works beautifully with ILM2 without any changes being required to the code base .  Awesome!  Even better I was able to get delta imports firing from the MSILM database only when changes to data/rules in the ILM portal were ready to flow in to the MIIS engine.  As a result the Operations History showed just a chronological history of real changes to the ILM portal as they were detected (near) real time and synchronised with AD and ADLDS in the lab.

I ran this by the presenter who I’m sure was politely obliging me at first, and he totally understood the revolutionary impact this will have on the ILM2 world – given that the alternative (use of a VB script to fire a fixed import/sync/export cycle on a 1 minute timer) was a great way to clog up the Operations History and make it very hard indeed to separate real changes from ghost ones  (e.g. in one hour of the lab this equated to reducing the run history from 6 x 60 = 360 runs down to a couple of dozen.  Once I’d calibrated the listener to work efficiently with the HyperV environment, I was getting ILM portal updates being applied to AD and ADLDS (with confirming imports) within 10 seconds.

• MSILM
• AD, and
• ADLDS changes plugins required for the ILM2 lab.

Over the remaining 2 days of the ILM2 course I expect I’ll come up with ways to further refine these – for example, working out how to deal with the data from the ILM portal (MSILM MA) differently based on whether it’s rules (which seem to require full syncs on each MA subsequent to any import) or data (which only need a delta import/delta sync).  I’m thinking that there may be a case for splitting these into 2 – i.e. partitioning into an ILM rules MA and an ILM data MA, simply to allow the correct sync flows to occur.  Will ponder this some more … but one thing is for sure, and that is the case for using Event Broker with ILM has never been stronger.