Unify Solutions have a bunch of great add-on products for FIM 2010 and, now I’m working here, I have a chance to find out more about them. The first one I’ve been playing with is the FIM Event Broker, which is essentially a task scheduler for FIM Sync, with all sorts of great features like an intuitive GUI, event-triggered tasks and proper logging. All things I think we can safely agree have been missing from the Sync Service as it comes out of the box!
Why we need it
Most people still trigger run profiles and associated processes (such as SSIS packages and other scripts) using a combination of vbscript or powershell scripts, and the Windows Task Scheduler. This approach is OK to a point – but when a lot of processes need to run at different times it can quickly become unweildy and hard to manage.
Something that is even more pertinent now we have the FIM Portal is on-demand provisioning. When an account is requested in the FIM Portal we may want to provision that account straight away, instead of having to wait for the next Sync cycle. I worked on a project a few years back where on-demand provisioning was a big requirement – this was before the FIM Portal so we were using a custom built website and ILM 2007, but the principal is the same. At the time I actually wrote my own ILM Scheduler service, just to tackle this problem – but I sure wish I’d known about Event Broker then – it would have made life a lot easier!
In Event Broker you can define lists of tasks called “Operations”. Here’s one I’ve been using a lot in my FIM Portal demos, where I’m creating objects in the Portal and provisioning them through the AD. Note the sub-task for the FIM MA – here if I get that annoying stopped-ma error that is only fixed by a Full Import, Event Broker will automatically run the Full instead of the Delta.
Operations are not just confined to run profiles – there are various other tasks I can include, such as running a powershell script:
You can schedule operations the traditional way, with times and repetition frequencies, though with a lot more flexibility than you get with the Task Scheduler:
The really cool way to trigger EB operations is in response to events in the connected data source. There is an agent involved, but once that’s in place you can actually trigger sync runs in response to, for example, a new user object being created in AD, or a new record being added to a database table. Here’s a view of the agents available with Event Broker.
The method I’ve been using the most is the FIM Agent where I can make use of the Event Broker Workflow Activity. This activity can be added into standard FIM workflows, so that you can then actually trigger a Sync run, or anything else you’ve defined as an operation in EB, as part of the workflow. Here’s the workflow I’ve been using in my demos so I can provision an AD account immediately and without having to run any other scripts:
So just to spell out what that workflow is doing:
- I generate DisplayName, AccountName, Domain and an initial password for the user,
- I attach the “Provision AD User” Sync Rule,
- I send notifications to the Target and Requestor, and
- I call the Event Broker Operation that syncs the changes through to AD (identified by it’s GUID to prevent any renaming mishaps).
And it’s been workingÂ a treat!
Finally, logging has always been somewhat undernourished in FIM Sync, but you can get the detailed logs you’d expect in EB.
Just a couple more points…
I’ve been using it with R2 and it works fine. EB is now on version 3.0 and has a long history in production with many Unify customers in Australia so it’s a stable product. And it’s straight-forward to install yourself.
3 Replies to “Event Broker for FIM 2010”
I was thinking about writing something like this for System Center Orchestrator. A quick little Integration Pack that would trigger FIM run profiles when certain conditions are met, or when changes/additions are made to a contributing DB / Identity Store. Would that still be something useful, in your opinion?
I’m more and more convinced that the future of FIM is with Systems Center (SCIM?) so that certainly makes sense with me. I gather you could wrap a powershell script that runs a run profile into Orchestrator without too must trouble.
Oh yes, very little trouble at all. Without FIM having a dedicated scheduler, it seemed like a no-brainer to me. The availability of Orchestrator/Opalis seems slim in the space right now, since it only comes with the full suite. Hopefully that’ll change. Thanks for your input. P.S. I also think it’s common sense to have FIM in the System Center suite. When they wrapped it into Forefront, it took me aback a little.