I'm having problems with attributes not being recalled on object deletion. The problem has been reported previously, see e.g. http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/afa58a56-0220-4b6a-a4db-e647cebd50cf/. I opened a case with PSS. Basically, what happens is that an object is deleted from a connected system (HR), and in the MV the object does not have a connector in HR, but still has the values that were contributed by HR. To have a workaround for this problem, I would like to know if there is a way to force recalling attributes contributed by a MA. Thanks, PaoloPaolo Tedesco - http://cern.ch/idm

I way I worked around the problem is by triggering a Function Evaluator Workflow that was triggered to set, let's boolean value from True to False, where a set that would deprovision a user based on the boolean value, i.e. being True or False.

I way I worked around the problem is by triggering a Function Evaluator Workflow that was triggered to set, let's boolean value from True to False, where a set that would deprovision a user based on the boolean value, i.e. being True or False.

Paolo, what build are you on? And more specific, do you want to fix this for objects which have attributes that weren't recalled before you patched to the latest version? Or or you still seeing this bug? I myself will do the following before I patch to the latest version: do an export of the MV using sqlcmd, and then do a field by field comparison of the HR file I have. A lot of those fields are mapped one-to-one so any differences are fields which shouldn't be there.. I'll replace them with "dummy" in the HR file, import, sync and then remove those "dummy" values, import, sync and attributes are being recalled... At first this FIM MA precedence/attribute recall didn't seemed bigdeal, but basicaly now it's corrupting the way our users are represented in AD :( http://setspn.blogspot.com

Hi Thomas, Thanks for your answer! I'm still on 4.0.3531.2, is this problem fixed with the latest patches? I was thinking about something similar (insert dummy entry, import, remove dummy entry, import) as a workaround to my problem, but I was hoping there was a simpler way. So, what you are planning is: insert dummy entries, import update to latest patch remove dummy entries, import Right? This problem is very annoying for us as well :( Cheers, Paolo.Paolo Tedesco - http://cern.ch/idm

Yep, this issue is fixed (build 4.0.3558.2) check FIM Build Overview We're also at update1. Waiting for a timeslot to test the update to the final version... You can patch first and then do your workaround. But somehow you'll have to trigger the "recall". I think that can only be done by recalling a dummy attribute. <a href=">http://setspn.blogspot.com

Yep, this issue is fixed (build 4.0.3558.2) check FIM Build Overview We're also at update1. Waiting for a timeslot to test the update to the final version... You can patch first and then do your workaround. But somehow you'll have to trigger the "recall". I think that can only be done by recalling a dummy attribute. <a href=">http://setspn.blogspot.com

On the official release page I could not find a reference to that bug... would that be the one that says "The attribute precedence does not work as expected with Declarative Provisioning and the FIM Service Management Agent"? Is it the same issue? The worst thing about this problem is that it hits only in production - the lab environment is totally immune, so I will not be able to say if installing the patch will fix the problem :) Paolo Tedesco - http://cern.ch/idm

I think it's more or less a side affect :) due to the precedence bug, the FIM MA is seen as a contributor. hence the attribute isn't recalled... :)http://setspn.blogspot.com