Hi, I have reviewed the material in this forum dealing with the deprovisioning of objects from a connected directory, specifically the AD. Also reviewed understanding deprovisioning in FIM document. None could help in my situation - the reason for this question. Deprovisioning in our company involves the moving of a user in the AD to a specicific OU for a grace period of 3 months ( ~90 days), after which it should be deleted. I am using FIM 2010 R2 RTM. I can move the user to the designated OU and also delete it when the grace period has passed. I have configured the object deletion rule in the metaverse to only remove the MV object when connectors from the following MA is disconnected, and select the FIM MA. The HR MA is configured to not recall attributes when an object is disconnected from it. everything works perfectly, except the MV, and FIM objects remain connected. Any idea as to why this is happening? According to the documentation I was expecting that all objects wil be deleted after the FIM MA is disconnected from the MV, but it seems that it is joing again, when looking at the MV object it shows as provisioned from the FIM MA. Any help is appreciated Tanks Johan MaraisJkM6228

I believe the reason this is happening to you is that you've configured the system to delete only the AD object when the grace period ends, therefore wouldn't you need the object deletion rule to delete when the ADMA object is disconnected? If FIM is authoritative for User provision and deprovision, then I suggest you change your grace period deletion to delete the FIM object, regardless of where it is in the connected data (AD)....then everything else you have currently configured will work. This is all if I read your question correctly.

I believe the reason this is happening to you is that you've configured the system to delete only the AD object when the grace period ends, therefore wouldn't you need the object deletion rule to delete when the ADMA object is disconnected? If FIM is authoritative for User provision and deprovision, then I suggest you change your grace period deletion to delete the FIM object, regardless of where it is in the connected data (AD)....then everything else you have currently configured will work. This is all if I read your question correctly.

gdtilghman, Thanks for the reply. What you say makes sense. My reasoning was that because the FIM portal is controlling everything the deletion should be processed when the FIM object is disconnected which is specified in the SR. I have a set, WF and MPR which removes the user from the SR which causes the AD obejct to be deleted and the MV object, which is then returned by the FIMMA. But I will go and config the object deletion rule on the MV to remove the MV object when the ADMA is disconnected instead of the FIM MA. Will post back on the result. Thanks Johan MaraisJkM6228

gdtilghman, Thanks for the help. thinking about your advice it is actually obvious that the whole deprovisioning process start when the ADMA object is disconnected. Sometimes one gets so involved in the detail of a problem that you can't think straight! You put it in perspective for me, I configured it like that and everything is working 100% now. Regards Johan MraisJkM6228

Now maybe you can help me. We haven't begun our deprovision process using FIM yet, but will. Our deprovision will look almost exactly like yours does. I was wondering if you could share with me the process and how you accomplished the move and delete after 90 days....was it codeless or did you have to use rules extensions?

gdtilghman, I had been helped by many people in this forum, and I am glad to be able to return the favour. This is going to be a post on the lenghty side, my apologies for that, but I have to start from the beginning. In our environment almost all provisions and deprovisions come from our HR system except for a small category of contractors which only exist in the AD. We receive a csv file from HR on daily basis containing only active employees, we do a calculation between the previous file and the current file to calculate amongst other things new employees and employees who have left the company. We update the status as Active and Inactive respectively. In the FIM portal I have a Set for users with an Inactive status which then initiates the deprovisioning process by first moving the users in the AD to an OU where we keep the exits based on the month in which they leave, fo example: When the users are moved to the Exits folder in the AD the description field is updated with something like"User moved and disabled by FIM on 2012-06-12 10:30:12". In the FIM portal I also have a custom attribute which I populate with the date the user is moved, this date is tracked by the FIM portal. The password of the user is also changed to a random password and the acount is locked based on whether it had an email address or not. The user object will remain in the Exits OU for a period of 90 days, if it is not re-enabled and moved out to a normal user OU. (sometimes this happens with contractors when the contracts are renewed). I also update the info field in the AD for the user with the OU the user originated from, in case he / she had to be moved back. With the reception of the HR file the next day the users just exited are no longer in the file and is removed from the CS of HR, but the MV objects remain. (Which is what you want). At this point the ownership of the MV object belongs to the FIM portal which controls what happens with the object. When the 90 day grace period has lapsed, (tracked through the custom attribute), the deletion process is started, we do this in a two step fashion, I first update the description in the AD to "To be deleted". The desciption "To be deleted" puts the user/s in a Set which will ensure that a workflow removes the SR which disconnects the FIM object from the AD object and the object is deleted from the AD. The Metaverse object deletion rule is configured to remove the MV object when the AD object becomes disconnected (your advice). This together with the Deprovisiong rule in all the MAs which state to Stage a delete once the connector becomes disconnected or MV object is deleted. For the AD MA I had to do a Legacy rule extension because some objects I don't want to delete but just disconnect. The AD MA's deprovsioning rule is configured to Detemine with rule extension. With "To be deleted" in the description field will result in the object been deleted. With another specific string it will just be disconnected, which is required for another scenario we have in our environment where the anchor attribute in the HR file is changed - but this is another discussion. Everything I have done is done through the FIM portal except for the deprovisioning rule in the AD MA and a custom Workflow activity to get todays date in the FIM portal, but I guess that depending on your environment, you might not need either. Also realize that it will take a couple of sync cycles in and out of the FIM portal until everything is converged, in my case with all the different changes, it takes about 16 run profile steps to get everything converged, but because all steps are like E, DI, DS - it doesn't take to long to finish everything. :-) I suggest that if you want to test this, to first do it in a dev or lab environment. Another sugestions is to break the whole process into steps, and impliment them one by one, my expereince with this is that although it sounds simple, it is actaully a complex process. Hope this gives you some help in doing this for your environment. If you need more info, maybe send me your email and I can send excerpts from my design documentation. Regards Johan MaraisJkM6228