Hi All, When a person gets deleted from FIM Portal/Service, are the associated EREs deleted automatically? I seem to have collected a bunch of EREs in my environemnt which dont have any associated ResourceParent. The only reason I could think this might have happened is the deletion of the associated users. Note: I am looking at a really high turnover rate. Are the EREs deleted automatically over a period of time? Or do they need to be periodically deleted in a scripted fashion? Thanks, Thanks & Regards, Jameel Syed Principal Consultant, fimGuru - Your window into simplified identities jameel.syed@fimguru.com - http://www.fimguru.com

The short answer is no, they are not automatically deleted - A method to remove orphaned ExpectedRuleEntry objects from your environment. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/d3eb7f06-d8f0-4678-bc55-f07243d4c849/#4b618c2e-6cc0-47fa-829a-3649d82f428a

Dealing with them in an external process Deleting them on the fly by using a workflow 3. make a MV provisioning rules extension to check for orphaned EREs and deprovision them during full/delta sync 4. try to avoid orphaned EREs and do not delete objects on the portal as proposed by the link I gave above

In that case, they need to be managed by means of transitioning into a temporal set. Do you suggest any other automatic mechanism of dealing with them? Thanks,Thanks & Regards, Jameel Syed Principal Consultant, fimGuru - Your window into simplified identities jameel.syed@fimguru.com - http://www.fimguru.com

There is a discussion about this topic on this forum - sorry, can't find it right now. FIMBob, Evgeniy - can you please help? Basically, there are two options you have: Dealing with them in an external process Deleting them on the fly by using a workflow There is no right or wrong - it is just a matter of your personal preferences. The discussion I'm looking for is actually a great resource. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Markus, I spent this morning trying to deal with EREs on the fly by using a workflow. Unfortunately I can't be done using standard methods and builtin activities. (actually it can, but the only scenario it will work looks useless for me). may be good to place it into WiKi, here's the solution that works 1. Go to activities configuration and change 'Synchronization Rule Activity' to be also an authorization activity 2. create an authorization workflow with at least 2 steps: a) sync rule activity: remove target from synchronization rule (actually the one that does the job) b) approval activity (or anything that will cause a delay for deleting an object so sync rule activity can do its job before object is deleted) c) notification activity (not required) 3. create an MPR that grants permissions to delete a target and has your newly created authorization activity in the authZ stage in the very first place that's all so you can create an object, watch for 'Create ERE' with 'add' action. but! you need to do delta import + delta sync to MV to get this ERE imported and status changed from 'pending' to 'applied', then you need to export pending changes to FIM now you can try to delete an object. you new activity would raise 'Create ERE' with 'remove' actions, so there will be the second ERE object... and you need to do delta import + delta sync before your request will be approved and object will be deleted. so you've done delta import/delta sync and ERE was deleted from MV. now you need to export changes to FIM to delete both EREs. now you're safe to approve object deletion request and once deleted you will no longer have orhaned EREs. but! once again it's too complicated scenario to work with if request will be denied you will not get your sync rule back you need a delay (like an approval WF) and delta import/delta sync + export _before_ approval will be completed. ps. if I would need to deal with EREs on the fly I would rather write my custom WF activity and will pass targetID to it in the authZ stage. It will enumerate all EREs with parentID=targetID and will use regular remove resource activity. but still... I would prefer to avoid orphaned EREs instead of trying to delete them on the fly.

Markus, I spent this morning trying to deal with EREs on the fly by using a workflow. Unfortunately I can't be done using standard methods and builtin activities. (actually it can, but the only scenario it will work looks useless for me). may be good to place it into WiKi, here's the solution that works 1. Go to activities configuration and change 'Synchronization Rule Activity' to be also an authorization activity 2. create an authorization workflow with at least 2 steps: a) sync rule activity: remove target from synchronization rule (actually the one that does the job) b) approval activity (or anything that will cause a delay for deleting an object so sync rule activity can do its job before object is deleted) c) notification activity (not required) 3. create an MPR that grants permissions to delete a target and has your newly created authorization activity in the authZ stage in the very first place that's all so you can create an object, watch for 'Create ERE' with 'add' action. but! you need to do delta import + delta sync to MV to get this ERE imported and status changed from 'pending' to 'applied', then you need to export pending changes to FIM now you can try to delete an object. you new activity would raise 'Create ERE' with 'remove' action, so there will be the second ERE object... and you need to do delta import + delta sync before your request will be approved and object will be deleted. so you've done delta import/delta sync and ERE was deleted from MV. now you need to export changes to FIM to delete both EREs. now you're safe to approve object deletion request and once deleted you will no longer have orphaned EREs. but! once again it's too complicated scenario to work with if request will be denied you will not get your sync rule back you need a delay (like an approval WF) and delta import/delta sync + export _before_ approval will be completed. ps. if I would need to deal with EREs on the fly I would rather write my custom WF activity and will pass targetID to it in the authZ stage. It will enumerate all EREs with parentID=targetID and will use regular remove resource activity. but still... I would prefer to avoid orphaned EREs instead of trying to delete them on the fly.

Thanks for your replies. Its really unfortunate that FIM doesnt automatically handle this upon deletion of an associated person object. Appreciate the direction though! Thanks,Thanks & Regards, Jameel Syed Principal Consultant, fimGuru - Your window into simplified identities jameel.syed@fimguru.com - http://www.fimguru.com