Archive for October, 2009

Upgrading from one build of FIM to another

I know FIM is not out yet and I am talking about upgrades from one build to another. The situation I was facing is an upgrade form RC0 to RC1 build.

I’ve have coded several custom activities for FIM that referenced several DLLs from FIM portal. One of them was Microsoft.IdentityManagement.WFExtensionInterfaces.dll

When a custom activity referenced to the Microsoft.IdentityManagement.WFExtensionInterfaces.dll form RC0 build, and then was copied to RC1 build without re-compiling it with a reference to a new version of DLL (from RC1) the activity will not display in Portal and will fail to initialize.

The problem is in version redirection settings.  To resolve this problem I had to modify web.config file by adding following statement:

<dependentAssembly>
        <assemblyIdentity name="Microsoft.IdentityManagement.WFExtensionInterfaces" publicKeyToken="XXYY11XXYY11XXYY" culture="neutral" />
       
<bindingRedirect oldVersion="4.0.0.X-X.XXXXX.XXXXX.XXXXX" newVersion="4.0.XXXX.X" />
</dependentAssembly>

I’ve modified actual values of publicKeyToken, oldVersion and newVersion attributes to protect the innocent, so to speak. You’ll have to do your-own look up in GAC and properties of your DLLs.

 

Happy coding!

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

Attaching to Microsoft.ResourceManagement.Service.exe failing

There is a lot of thing person can overlook when he/she in the hurry. And every time I am re-installing FIM service on my dev box I am in the hurry to make things done.
I am posting this entry mostly for my future self. It is for second or third time after upgrading FIM 2010 portal service release to latest and greatest version I am encountering this issue and every time I remember that was able to solve the last time around and can’t remember what exactly I did.
So, when you want to debug your custom code for FIM 2010 in Visual Studio and trying to attach to  the Microsoft.ResourceManagement.Service.exe with default Visual studio settings you will likely to see a failure message like "access denied", "failed to attach" or something like that.
The trick is very simple: right before attaching to the service, in the field "attach to" select "Managed Code" and not default value "Automatically determine…" . Problem should be solved!