Friday, August 29, 2008

ILM 2 Beta - The Codeless Provisioning Detour

So, while working with one of our TAP customers this past week I got the chance to do a really deep dive on Codeless Provisioning. The past weeks worth of posts here are the partial result of that endeavor and out of that came a deck with a few interesting slides that I thought would make good blog fodder. So here it is, in all of its glory, the "Codeless Provisioning Detour".

With MIIS/ILM we've enjoyed (some would say suffered) a somewhat inflexible system for provisioning new objects into other connector spaces - the Provisioning Rules extension. "Why do I need to write code to provision new accounts?" has been the frequent cry heard by the product group certainly since the product shipped back in 2003. We've all gotten used to handling our own "manual workflow" through this method despite its limitations and yet it has a peculiar bit of efficiency about it that you'll no doubt come to realize once you understand how Codeless Provisioning works. Let's look at how things work today:

imageThe Sync Engine today is able to leverage the Provisioning Rules extension to directly to make decisions that can result in the immediate creation or deletion of objects in other connector spaces.


This creates a pretty efficient pipeline when you can take information from an authoritative source, make a decision about it and then immediately take action. With Codeless Provisioning we have to take a "detour" through the ILM MA and the portal application so the workflows, processes, and policies can work their magic. image

With ILM 2, in order for WF to take effect you have to first get the object into the portal to begin with. Getting the object into the portal allows your Management Policy Rule to fire and create the ExpectedRuleEntry object for every object that falls under the scope of your Synchronization Rule.image

When you check the little box on an Inbound Sync Rule to "Create object in ILM" it's provisioning the object into the ILM MA datastore so it can be evaluated for Outbound Sync Rules.


It doesn't really matter yet that you have Outbound Sync Rules already in place - until you take the detour through the ILM MA your new objects can't be added to the scope of those rules yet; more on this later.


anant said...

Hi Brad,

I am trying to workout codeless provisioning scenario. I have everything configured in my environment. I am getting

Microsoft.MetadirectoryServices.ProvisioningBySyncRuleException: The DN must be set before calling CSEntry.CommitNewConnector.


any idea ?

Brad Turner said...

Sorry for the delay - you will need to ensure that in your CP Outbound Sync rule that you have one rule set as "initial only" and that it is building the DN.

Post a Comment