I recently delivered my first, super hands-on, one week workshop on MIIS (Microsoft Identity Integration Server) 2003 for internal staff (Microsoft Consulting Services) and a few local partners that are focussed on infrastructure work. I structured the training around each participant delivering a fictitious PoC (Proof of Concept) that involved all the different types of MA's (Management Agents). So by the end of the week, everybody had built a system that was capable of provisioning to a SQL Server 2000 database, a custom delimeted flat file, Active Directory and two separate instances of ADAM. We also took a look at provisioning to Lotus Notes.

This was the first time that a number of partners had come really close to working with MIIS 2003 and some of their feedback was as follows:-

• MIIS is not real-time (event-driven); only the password synchronisation engine functions in real time. Maybe it doesn't make sense for all MA's to be real-time, but, as an example, adding a user to Active Directory should be able to fire off a provision process to other MAs.
• Why do we need code for basic provisioning? Ok, it allows for flexibility, granted. But what about basic scenerios like provisioning to AD, especially when using the IIFP (Identity Integration Feature Pack), why do we need to write code for that?
• MIIS requires both a dev team and an experienced infrastructure team side-by-side to implement. Management of the Provision() and Deprovision() functionality in a single DLL becomes critical. Why couldn't this DLL be separate somehow.
• Role based access control (RBAC) and particularly role-based mapping are not natively implemented. RBAC can be implemented through newer applications utilizing AZMAN (Athorization Manager), but mapping business roles (Finance Managers, Accountants, Directors etc..) to various systems (MA's) in a dynamic way seems the burden of the developer.
• Built in stepped workflow is very straight forward. Imagine if this stepped workflow could include a call to an external .NET Assembly, then jamming fuctionality with in the provisioning/deprovisioning DLL would be less important and basic workflow could be implemented within this stepped framework within MIIS.

Overall the participants liked MIIS 2003, but all commented that they needed to understand how it worked first. They had all thought that it was event-driven and had to come to terms with sequencing and schedulling jobs against the various MA's to be run.

PS. It's good to be back blogging professionally again. In recent months I've turned my attention more to my personal blog on MSN Spaces (which I still think is very cool). Over here on MSDN blogs, I'm still getting the hang of our new blogging engine and there are definately some things I'd like to figure out how to customize, but it's great to be posting here once again.