Rename of objects in code and in codeless provisioning with FIM 2010

Over this weekend I have found (apparently well-known) deference between coded/scripted provisioning (aka traditional .net code) and new codeless provisioning of FIM 2010.

The deference between those two methods is that Scripted Provisioning treads change of the value of DN attribute as a rename and therefore requires provisioning code to be written for it. For example when you want to move an object in AD from OU=Old to OU=New, you need to write code for it. With CP this is not a case any longer. You want re-concatenate your DN you can simply express it in the FIM Portal UX.

Moreover, since you were expected to write a code for renaming of objects you also have had an option to disable your own code execution at will. In Identity Manager you could go to Tools –> Options and un-check "Enable Provisioning Rule Extension";

The Codeless Provisioning behaves exactly the same way. You still can go to Identity Manager and click Tools –> Options –> and un-check "Enable Synchronization Rule Provisioning" in the "Synchronization Rule Settings" section. That will disable your Codeless Provisioning.

However!  FIM 2010 treads DN attribute as any other attribute; it can simply flow new DN value into the connectors space and therefore it is capable of effectively renaming object WITHOUT provisioning being enabled. Meaning that rename of the object is not treaded as provisioning, but rather as an attribute flow.

Let me elaborate on importance of this deference. Each Identity Management project generally contains "initial import" and/or "migration" phase of some sort. It is an accepted practice to import and synchronize all objects from all participating management agents before enabling provisioning. That is done to ensure that all joining and projection that is happening at that time are not prematurely triggering provisioning and causing "object with DN X already exists in MA Y" exception. Aside from implementing "Auxiliary MA" technique you pretty much have to disable provisioning and re-enable it later for a secondary sync. So with the scripted provisioning you would NOT expect to see any "moves"/"renames" of the objects during that cycle. However in FIM 2010 you WILL see your renames happening during your initial synchronization cycle, which could be something, you might want to verify prior to enabling provisioning and/or exporting objects into the "real world".

Happy codding

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: