Hi, I have encountered a situation in which an ERE for connected system A is removed from the user, and in the configuration for the management agent, the deprovisioning action is set to 'Stage a delete on the next export run'. The checkbox for 'do not recall' is NOT checked. This works fine and the object is deleted when the ERE is removed, but the attributes contributed by that MA are not being recalled, even when that MA is the only contributor for the attributes in question. Attribute recall works on objects from this MA when I do a disconnect on them manually, but the same behaviour does not happen when the object is deleted from the connected system. On the delta import / delta sync after the exported delete, it does show up as a delete. In the metaverse, the user has no connector to system A, yet it has values contributed by system A. So my question is, does attribute recall work differently depending on how the object is disconnected? Is a delete not considered a disconnect? Thanks, Mark

No and no... The attributes should be recalled. If they are not recalled, you should contact PSS. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I had this issue too. What FIM Build version are you on? In my opinion this is related to the following issue: The attribute precedence does not work as expected with Declarative Provisioning and the FIM Service Management Agent. Build 4.0.3558.2: http://support.microsoft.com/kb/2272389http://setspn.blogspot.com

Thanks for the responses. For now, I have adjusted the configuration of this particular FIM solution to not rely on the attributes being recalled; I will follow up with PSS if I continue to see this behaviour. This is on FIM build 4.0.3576.2. Thanks, Mark

I have had this behavior too, but in my experience this happened "rarely", i.e. it works as expected most of the times, and on some occasions (I really cannot tell under which conditions) the recall is not triggered. Are you opening a bug? If so, will you post a link here so we can vote it? Thanks, PaoloPaolo Tedesco - http://cern.ch/idm