Hi, I'm new to FIM 2010 (though I'm also new to MIIS/ILM, I have a firmer grasp of classic rules) and was having a problem deprovisioning users from the FIM Portal. Design: I have a SQL HR MA that is the authoritative source for all users. I have a FIM MA that mirrors these users to the Portal for future use. (also, it seems like none of my declarative rules happen until they're processed by the FIM MA?) I have an AD MA that is where I'll store my Active Directory users. Setup: I have an ALL AD Users set that includes all users if Employee Status = True. I have two Synchronization Rules, one to Import SQL's users (create resource in FIM) and one to provision AD's users (create resource in external system & disconnect FIM resource from external system when ...). I have two workflows that either add or remove the two Sync Rules. I have two MPRs that trigger the corresponding workflows when users transition in or out of ALL AD Users. Auto-provisioning works, so I'll gloss over that one. My problem is deprovisioning. When the Employee Status = False, the AD account is correctly deprovisioned, but the FIM Portal user remains. This is what I have and why I assume it should be working: For the FIM MA, I have the Deprovisioning Option: Stage a delete on the object for the next export run selected. For the person metaverse object, I selected Delete metaverse object when connector from any of the following are disconnected: AD MA I know the object is disconnected from the AD MA because it's gone from AD and it's not listed as a connector for the object. So why is it being stubborn? The metaverse object still exists despite the Object Deletion Rule. The object has no more ERLs attached to it and is now drifting along in space. Because of this, the user is still in the FIM Portal.

I have more info, but info I don't like. I ran into a FIM bug with my original setup. I only had one user coming out of the SQL HR MA and was trying to use the disappearance clause (I know, not recommended) to cause the metaverse object to go away, but it never did. The bug in FIM is that if a management agent processes no data, it doesn't do anything. That left my metaverse object intact and it still claimed that it was connected to the SQL HR MA. By adding a second user (forcing a minimum of one row processed by the SQL HR MA), I finally got the metaverse object for User #1 to go away (and the FIM Portal user goes away because the FIM MA deprovision rule finally gets obeyed). I'm still stuck though. I want the behavior described above. I don't want the FIM Portal to list users that aren't in AD. Since both of their sources is the SQL HR MA, this should be simple, but it's not. I can get the AD accounts to deprovision via MPR/Workflows/Sets, but can't do the same for the FIM Portal because: The FIM portal only uses classic rules. The FIM portal can't do extensions. I can only delete projected FIM Portal objects using it's FIM MA deprovisioning rules. (that I know of) The FIM MA deprovisioning rules only activate if the corresponding metaverse object is deleted. (since extensions are not allowed) I can only get the corresponding metaverse object to "delete" using the disappearance case (it doesn't come through the SQL HR MA anymore). I can only use the disappearance case because if I use a filtered disconnector (from the SQL HR MA), deprovisioning doesn't trigger. So, I'm still lost, but I found out a little bit more. If I wasn't already sitting down, I'd sit down now.

I have more info, but info I don't like. I ran into a FIM bug with my original setup. I only had one user coming out of the SQL HR MA and was trying to use the disappearance clause (I know, not recommended) to cause the metaverse object to go away, but it never did. The bug in FIM is that if a management agent processes no data, it doesn't do anything. That left my metaverse object intact and it still claimed that it was connected to the SQL HR MA. By adding a second user (forcing a minimum of one row processed by the SQL HR MA), I finally got the metaverse object for User #1 to go away (and the FIM Portal user goes away because the FIM MA deprovision rule finally gets obeyed). I'm still stuck though. I want the behavior described above. I don't want the FIM Portal to list users that aren't in AD. Since both of their sources is the SQL HR MA, this should be simple, but it's not. I can get the AD accounts to deprovision via MPR/Workflows/Sets, but can't do the same for the FIM Portal because: The FIM portal only uses classic rules. The FIM portal can't do extensions. I can only delete projected FIM Portal objects using it's FIM MA deprovisioning rules. (that I know of) The FIM MA deprovisioning rules only activate if the corresponding metaverse object is deleted. (since extensions are not allowed) I can only get the corresponding metaverse object to "delete" using the disappearance case (it doesn't come through the SQL HR MA anymore). I can only use the disappearance case because if I use a filtered disconnector (from the SQL HR MA), deprovisioning doesn't trigger. So, I'm still lost, but I found out a little bit more. If I wasn't already sitting down, I'd sit down now.

There is a simple method you can use to address this scenario. The gist of this method is that user accounts in FIM are not doing any harm, which is why there is no need to delete them immidiatley. In addition to the synchronization rules you have already configured, you need an operational outbound synchronization rule for your SQL MA. The objective of this synchronization rule is to handle deprovisioning. When the Employee Status of an object changes to false, the object is removed from the scope of the ADMA OSR and the SQL OSR. Both OSRs should have deprovisioning enabled. On your SQL MA, deprovisioning should be configured to turn the affected object into an explicit disconnector. This takes care of the SQL and the AD DS object. You can remove the FIM objects by using a scheduled cleanup script that deletes FIM objects with an empty ERE and Employee Status = False. The script takes care of the FIM object and the MV object. With this method, you can avoid orphaned EREs. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks for the response! I left out details about my AD MA because it was working as intended, but since you mention many things in your response, I'll include it here. My AD MA Sync Rule is an Inbound/Outbound and currently deprovisions as I intend to (this may change due to customer direction later). Using the Set --> MPR --> Workflow, the object is removed from the scope correctly. For the SQL MA however, I chose to stage a delete because I want to keep a tidy metaverse. You recommended making them explicit disconnectors, but I'm not sure why. Would the script that cleans out FIM objects with empty EREs be a query against the DB that serves the FIM portal? Also, I've seen mention of it in other forum posts but never found the source but: What about getting rid of orphaned EREs in the FIM Synchronization metaverse?

Thanks for the response! I left out details about my AD MA because it was working as intended, but since you mention many things in your response, I'll include it here. My AD MA Sync Rule is an Inbound/Outbound and currently deprovisions as I intend to (this may change due to customer direction later). Using the Set --> MPR --> Workflow, the object is removed from the scope correctly. For the SQL MA however, I chose to stage a delete because I want to keep a tidy metaverse. You recommended making them explicit disconnectors, but I'm not sure why. Would the script that cleans out FIM objects with empty EREs be a query against the DB that serves the FIM portal? Also, I've seen mention of it in other forum posts but never found the source but: What about getting rid of orphaned EREs in the FIM Synchronization metaverse?

Typically, the HR databases are read only. This means, "deleted" accounts remain in the source table until someone actually deletes them. In this case, you can prevent "to be" deleted objects from "coming back" by turning them into explicit disconnectors. Explicit disconnectors are not processed by the sync engine. There are also cases where folks need to keep "deleted objects" in the table for a while to reactivate them if the users come back as contractors. However, if you have write access to the database and you want to immediately delete the affected objects, you can also stage a deletion. In other words, the configuration of the deprovisioning reaction depends on your business requirements. Yes, the cleanup script runs against the FIM portal database. You can find script examples in the FIM ScriptBox. Using the method I have outlined in this thread, there is no need to worry about orphaned EREs. They are a result of deleting FIM objects with an ERE that is not empty. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation