We had an issue recently where 45 people were removed from our view in PeopleSoft due to an error in how the view was constructed. Because they were removed from the view, FIM deleted the entries from the Portal and AD. The view was fixed and the accounts were recreated. My question is, how can I safeguard against this? For example, if the view was empty, FIM would have deleted everyone in the company...which would be a bad thing. :) Opper ...don't stop.

The best practice for this scenario is to move the objects as disabled objects into the special container and to finally delete them after a certain timeframe. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I think this scenario illustrates the value of gradual deprovisioning policies. Simply triggering a deletion when a connected object disappears is (as you have unfortunately discovered) asking for trouble. HR (or any other source) data is often inaccurate and having safeguards in place to prevent you becoming the inadvertent victim of their mistakes is a really good idea. My personal preference for dealing with deprovisioning is to take no action when an object is removed from a feed (or perhaps trigger a notification to the FIM admin) and to act only on a date or change or status. However, I understand that some feeds (especially those that use views based on a date or status) will often act this way. Here's a suggested deprovisioning policy and I imagine others have their own preferences: User object disappears from HR feed Set a date and do nothing (or send alert) If the user object does not return within a certain time (perhaps they are on long-term leave but want their user account maintained), set a status flag to "disabled" (or whatever) Use the change of flag to trigger notifications as required and link to userAccountControl (or similar in other apps) to remove access (but not the user object itself) If the user is not reinstated within HR (or maybe the portal, perhaps they have moved from FTE to Contractor), then change their status to "terminated" or whatever If you really have to, delete their account, otherwise consider retaining the MV object at least and moving connected objects to archive locations. But ask yourself why you need to delete the account - users who leave often come back again Dave Nesbitt | Architect | Oxford Computer Group

The solution we provide (Traxion) is a tool that can check "thresholds" before the import/export continues. For example if 10 deletes occur do not process any further or if a percentage of the connector space is deleted/changed/added stop processing/exporting. This provides a safeguard for your system and can be applied on every step / runprofile. http://www.traxionsolutions.com/imsequencer If you have any further questions please not hesitate to contact me. Need realtime FIM synchronization? check out the new http://www.traxionsolutions.com/imsequencer that supports FIM 2010 and Omada Identity Manager real time synchronization!

Actually we had Oxford do our implementation and deletions are not handled that way. Can't say that was suggested either. I would like more details on your proposed flows though. Check with Bob, he has my email addy. thanks.Opper ...don't stop.

Thanks Paul. As long as the product isn't bloatware, i wouldn't mind seeing a demo.Opper ...don't stop.

He opper, You can download a demo version from the website, or you can leave your email adres on the contact form so we can contact you for a demo if it is still needed.Need realtime FIM synchronization? check out the new http://www.traxionsolutions.com/imsequencer that supports FIM 2010 and Omada Identity Manager real time synchronization!

Paul/Opper The threshold concept is actually a core run profile property that has been around since MIIS days ... see here under point #7, and here for an example of using this in VBScript. I expect that the sequencer is simply providing an alternative means of setting this run profile property, which is generally set directly via the MIIS/ILM/FIM Sync Server Identity Manager console, but providing a UI alternative to the VBScript. I've only ever believed in a (near) real time model for MIIS/ILM/FIM solutions, and have been building them since 2005 (in my case using the UNIFY Event Broker, listed alongside the Traxion option on this FIM wiki page) and concur with Markus that the best approach is not to delete immediately ... although these days there is a nice AD feature in the form of the recycle bin which further mitigates this. I don't use the threshold idea myself (except maybe in lab test cases) for a couple of reasons: I have always interpreted a (near) real time requirement as running both import and export run profiles as soon as the need (external change or pending export) is detected, and in this case you will still have pending export (deletes) runs waiting to go once any threshold is reached ... in which case they will run immediately (on the next export cycle) regardless; if the solution is supposed to delete objects then it should delete them ... not second guess me :). Consequently I'd be curious to know more about how such an implementation has been achieved in a Production environment (using thresholds within a "real time" model) myself ... Bob Bradley, www.unifysolutions.net (FIMBob?)

Thanks Bob, I appreciate the feedback. Opper ...don't stop.

Paul, are you saying your tool is able to check thresholds on operation types? Eg, if more than 10 deletes, halt, but more than 10 adds/updates, proceed? I can see how that might be beneficial, and would be different to the thresholding that FIM already provides out-of-the-box for all operation types. I would assume that it would then halt any further exports and raise an alert of some kind? Otherwise, the default behaviour I expect for an automation tool would be that it would export 10, detect that there are further pending exports, so export another 10, and so on, which would eliminate the purpose of the threshold in the first place. Anyway, opper, I think you'll find that the staged deprovisioning method mentioned above is the best way to safeguard your system. In the solutions for my clients, I typically disable an account and move it to a disabled users OU, allowing it to be cleaned up later - either automatically or manually (some admins still like the peace of mind of knowing that FIM will never actually delete an account). Of course, you still run the risk that all of your accounts could be disabled, and this is where you could further mitigate the risk by adding in a 'grace period', where accounts are only disabled X days after they disappear from Peoplesoft... this would ensure that any temporary downtime does not have a significant downstream impact on your systems. - Ross Currie

Paul, are you saying your tool is able to check thresholds on operation types? Eg, if more than 10 deletes, halt, but more than 10 adds/updates, proceed? I can see how that might be beneficial, and would be different to the thresholding that FIM already provides out-of-the-box for all operation types. I would assume that it would then halt any further exports and raise an alert of some kind? Otherwise, the default behaviour I expect for an automation tool would be that it would export 10, detect that there are further pending exports, so export another 10, and so on, which would eliminate the purpose of the threshold in the first place. Anyway, opper, I think you'll find that the staged deprovisioning method mentioned above is the best way to safeguard your system. In the solutions for my clients, I typically disable an account and move it to a disabled users OU, allowing it to be cleaned up later - either automatically or manually (some admins still like the peace of mind of knowing that FIM will never actually delete an account). Of course, you still run the risk that all of your accounts could be disabled, and this is where you could further mitigate the risk by adding in a 'grace period', where accounts are only disabled X days after they disappear from Notes... this would ensure that any temporary downtime does not have a significant downstream impact on your systems. - Ross Currie

He Ross, It indeed checks the operation types, you can define for instance a export delete threshold for 1% (in relation to the entire connector space) or an absolute number (specific for the delete) For exports it checks before starting the runprofile how many "pending" deletes are available, if they exceed the threshold you have 2 options, continue to the next step in the profile or stop the entire profile. The threshold is reported in the report that is send at the end of the run (where you will see all the statistics and errors raised in the run). Read more here: http://www.traxionsolutions.com/imsequencer/help/index.html?create_or_edit_singlestep.htm It is also possible to send a SNMP message if needed. I always use this as a safeguard, because sometimes source system do not deliver their data properly and when running a Full Import will delete everything (did does not mean that all objects are deleted, but this is more how you handle deletes from the source system). I find it very useful to define thresholds on exports, for instance my customer changed something in the configuration file (and was expected it to change only for new hires) but after a full run every employee changed (but that was not what he wanted). The threshold on updates blocked this and counter measures where taken to avoid corruption. Need realtime FIM synchronization? check out the new http://www.traxionsolutions.com/imsequencer that supports FIM 2010 and Omada Identity Manager real time synchronization!