Is it possible to recall an attribute for an object when the object is deleted from the contributing MA? In particular, I have a custom boolean attribute, contributed by my HR MA, called activeUser, which I set to a constant boolean value true. I would like to have this attribute removed when the user is deleted from the HR MA. The reason I'm trying to do this is that I would like to trigger a rule that sets the object expiration date when activeUser is not true anymore, and then have the object deleted from FIM and all the other connected systems only once the expiration date has elapsed. Thanks, Paolo Paolo Tedesco - http://cern.ch/idm

Paolo, Isn't that the default behaviour? If you configure a new MA, by default it should behave like that. Some explanation from technet: If you want the connector space attribute to remain after the metaverse attribute is deleted, in the Configure Deprovisioning property of the management agent, select Do not recall attributes contributed by objects from this management agent when disconnected. When you select this check box, the connector object attribute is retained in the connector space when the attribute of the metaverse object is deleted. So in your situation, if it's not checked, it should dissapear. Regards, Thomashttp://setspn.blogspot.com

But in this case the object is not disconnected, but deleted. Should the behavior be the same? In my environment, attributes contributed by that MA are not recalled after the object has been deleted. Thanks, PaoloPaolo Tedesco - http://cern.ch/idm

I think a deletion has the same effect: the object disspears from the Connector Space, hence the appropriate Metaverse object is disconnected from that Connector Space object and attribute recall should kick in. However, in my environment I have seen attribute recall fail to do it's thing some times, both with a CSV and a SQL MA. If you double click the MV object, and verify on the connectors tab that your MA is not listed, then on the attribute tab it should never be listed as a contributing MA. Supposing you have not check the "do not recall..."http://setspn.blogspot.com

Hi Thomas, I just made a quick check: if, instead of deleting the object, I make it a filtered disconnector (configuring a connector filter) the attributes are recalled. So probably deletion and disconnection are not the same for what attribute recalling is concerned... PaoloPaolo Tedesco - http://cern.ch/idm

Hey Paolo, This might be interessting: http://social.technet.microsoft.com/Forums/en-GB/ilm2/thread/de15bf3f-b38d-4bc6-8ab0-a41b3a16ebb1 It's a question of myself concerning this actual topic, I still believe the deletion should also trigger the attribute recall, it's also what I'm seeing in our environment. Regards, Thomashttp://setspn.blogspot.com

From the link you sent it looks like deletion should recall values too, which also makes more sense, but in my case this is not happening :( Is there something I should check? The "do not recall..." checkbox is unchecked in my MA. Thanks, PaoloPaolo Tedesco - http://cern.ch/idm

Attribute recall is triggered upon a disconnect. Technically, FIM doesn't even know what a deletion on the CS side is. A picture would help because it is not clear to me what does / does not happen in your environment. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Paolo, It might be advised to test your attribute recall with multiple test objects. I have seen cases where my first delete action did not trigger the desired effect, but subsequent deletions for other objects did act as expected. I'm not seeing it often enough to log a case with pss and i'm still in a lab environment....http://setspn.blogspot.com

Hi Markus, let's start from the beginning (sorry for the long post)... My problem is this: 1) When a user contract ends, I want to disable his account and, after a grace period of six months, delete it. 2) If, during these six months, the gets a new contract, I want to re-enable the account and unset the expiration date (so that it will not be deleted at the end of the grace period). We could say that I want to implement what you describe as a "wait and see" policy in your article about deletions in ILM. Now, when a user's contract ends, his record is not deleted from the HR DB, but rather a boolean attribute, called "ACTIVE_USER" changes from true to false. Moreover, I cannot write in the HR DB (among other things I'm using a view), so I cannot delete a user from it. I decided to implement things like this: 1) Flow: HR ACTIVE_USER -> MV activeUser -> FIM ActiveUser (allow nulls). 2) Transition-out MPR: when a user goes out of the set "Active Users" (users where ActiveUser is true), run a custom activity that disables the account and sets the expiration time to now + 6 months. 3) Transition-in MPR: when a user enters the "Expired users" set (users where expiration time is prior to today), delete it 4) MV deletion rule for person: delete when connector from any of the following MAs is disconnected: FIM (so that FIM is "authoritative" for accounts deletions) 5) AD MA deprovisioning: stage a delete on the object for the next export run 6) HR deprovisioning: make disconnector Now, to trigger the change in ACTIVE_USER, I have two options: 1) Filter out users where ACTIVE_USER != 'Y' directly in the view on the HR DB that I'm using. 2) Configure a connector filter, so that if ACTIVE_USER != 'Y' the user becomes a filtered disconnector, and the attribute is recalled. Option #2 is working, but I think that using connector filters is not considered a good practice, even if I haven't understood why. Option #1 does not seem to work: the user disappears from the HR MA CS and the attributes are not recalled, which, from your previous answer, seems to be the correct behavior. So, finally, what I would like to know is if my approach to "wait and see" deletion makes sense, or if I could solve it in an easier way, and if there are possible problems I'm not aware of with the connector filter I configured. Thanks, Paolo Paolo Tedesco - http://cern.ch/idm

Paolo, I don't think you interpreted Markus answer the right way: Attribute recall is triggered upon a disconnect. Technically, FIM doesn't even know what a deletion on the CS side is. I think what Markus is saying is that FIM doesn't know the difference between a disconnect between a MV object and a CS object, or when an object is simply deleted from the CS. For FIM the connector dissapears in both cases and attribute recall kicks in. That's how I think it's happening :) I currently wrote some rules extensions to handle the first option as you describe it. I don't have a active/inactive boolean in my HR source, they just hand me a CSV with all "Active" people... I choose one of the attributes in the csv, a unique ID, which I flow to a dummy attribute in the Metaverse, called HRMA_Active. Whenever the CS object is deleted, the Emp_Active is recalled (the HR MA is the only contributor). So in my AD MA I got an EAF which sets the expirationDate of the account in AD to now + x weeks whenever the Emp_Active attribute is not present. Using an other IAF I put the expirationDate in the employeeEndDate in the MV. On top of that I got an other IAF on the AD MA which will, whenver the expiration date is in the past, set my EmployeeStatus attribute in the MV to disabled. This is flowed out to the FIM Portal and then the regular deprovisioning MPR's kick in which in turn will disable/move the account in AD. I think this dummy attribute concept is called "a disconnector detector". But that's one side of the story, there are probably other/better alternatives. If youd like more clarity on my explanation I could give it a go. http://setspn.blogspot.com

Paolo- Doing the connector filter is relatively slow so I would just do the filtering of active users in your query. As far as the activeUser attribute, if you flow the <dn> from HR > activeUser and use a constant of "true", when the user drops out of HR your activeUser attribute will become null which you could then create a set for {activeUser Is Not True}.Active Directory, 4th Edition - www.briandesmond.com/ad4/

I think what Markus is saying is that FIM doesn't know the difference between a disconnect between a MV object and a CS object, or when an object is simply deleted from the CS. For FIM the connector dissapears in both cases and attribute recall kicks in. That's how I think it's happening :) There you go. When a deletion is imported from a connected data source, the related CS object is not deleted if it is a connector. The synchronization engine just stages a "to be deleted" flag on it. During a next synchronization run, the CS object is deleted. The deletion of the CS object also deletes the link relationship between the CS object and the metaverse object. The link removal is what triggers further actions - not the deletion of the CS object. The same thing happens, when a connector is filtered by the connector filter - the link relationship is removed. So, what the metaverse eventually "sees", is a link removal. The link removal is all that's relevant for the metaverse object not the "why". A potential contributor (if the unlinked CS object had IAFs configured) is gone, now what? If the unlinked CS object was a contributor, the synchronization engine needs to determine whether the attribute values the object has contributed have to be pulled (recalled). If so, the synchronization engine pulls the values and determines whether there are remaining connectors to repopulate the MV object. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Actually, I prefer the long post :o) because it helps to give you a better answer to your question. "Now, when a user's contract ends, his record is not deleted from the HR DB, but rather a boolean attribute, called "ACTIVE_USER" changes from true to false. If, during these six months, the user gets a new contract, I want to re-enable the account and unset the expiration date (so that it will not be deleted at the end of the grace period)." How does "user gets new contract" translate to HR database activities? Since the old record was not deleted, is it reused - for example, is just Active_User set to true again? What I don't quiet get right now is why you need to disconnect your HR object and recall the attribute. To make synchronization decisions, it is always good to have "active" data. What I mean is a contributed value such as "Active User = false". This is better as interpreting what an unpopulated attribute means. In case of an unpopulated (null) value, you have to ask yourself whether the attribute was never populated or pulled - "false" is less ambigious. You should only disconnect the HR object if the old record is kept in the database for compliance or other reasons. There is a third option you have to handle the disconnection of the HR connector - to deprovision it. This option is in my opinion a bit more elegant from the implementation perspective because it integrates processing decisions into the FIM policy model. It makes it also easier to "read" your implementation... You already have your Active User set. Transitioning into this set should bring the affected objects into a HR outbound (!) synchronization rule. All, you need to configure in the synchronization rule next to the relationship criteria is to Enable Provisioning: When an object transitions out of your Active User set, you also remove the object from the scope of the synchronization rule. This triggers deprovisioning on your HR object - which disconnects it. If you don't need the HR record anymore, configure deprovisioning to make the CS object an explicit disconnector: As mentioned before, if the old HR record is reused, I wouldn't disconnect the object at all. HTH Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Markus, thanks for the long answer :) What happens when the user gets a new contract, is that the "Active_User" flag is set to true again. I too would prefer a solution without deletion/filtering/attribute recalling, but what I don't understand in that case is this: supposing that a user gets a new contract before the end of the six-months grace period, if the user's entry in HR is a disconnector, what would make it a connector to the existing MV entry again? Thanks, PaoloPaolo Tedesco - http://cern.ch/idm