I noticed some odd behavior. I am testing out a data source using a MS SQL view with a SQL Server MA. I was able to provision the records correctly in the AD MA I have set up. I wanted to remove all 3 accounts I provisioned and changed the SQL records so they did not show up in the view I created to use with FIM. When I run a Full Import on my SQL MA, the three records that were provisioned to AD are not staged to delete - all I get back is completed-no-objects and the CS records are not removed and any further inbound or outbound synchronization does not occur.<o:p></o:p> I added one record back in to the view and the Full Import picked up the other two to delete and everything worked through and removed the accounts. I removed the last record from the SQL view and the Full Import on the MA still reports completed-no-objects. This leaves the last account provisioned to be deleted in CS and MV as well as in the FIM portal and AD - I cannot remove the account and it is still active in AD and FIM even though my source on SQL says otherwise. Is there any way to force the deletion of the last account or something I do not have configured correctly in FIM?<o:p></o:p>

Hi, This is normal behaviour for FIM. If no objects can be imported, no deletes will be processed. This is a security mechanism preventing deletion of all your objects when the source system generates an empty import file or, in you case, if the database is empty. Best regards, Pieter.Pieter de Loos - Consultant at Traxion (http://www.traxion.com) http://fimfacts.wordpress.com/

Pieter is correct about FIM's behavior. To remove the final record you have several choices depending future plans: 1) Delete the MA (clear connector space only) 2) Delete the MA (connector space and management agent definition) 3) Create a dummy record and then create a connector filter that always filters out that dummy record. If you are never going to use the MA again then #2. If you will use the MA again and have an empty view is something that should only occur when you have manually deleted the records or otherwise truncated the underlying table then do so in conjunction with #1, you will clear out the connector space and remove the records from the database. If you expect the table to be cleared out by other processes and want FIM to import the deletions and delete the records automatically then #3. You will need to ensure that your processes that clear out the table preserve or re-add the dummy record. Remember that when you process deletions or clear the connector space the MV object deletion rule gets evaluated for every metaverse object that was connected to the connector now being filtered or deleted. If the MV object gets deleted this could in turn trigger deprovisioning on other management agents.David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

Thanks for the answers. It does make sense it works this way - although the intention I have is to deprovision and delete the users from AD that drop out of the SQL view with the MA being used again. For example, contractors or guest wireless access with a start and end date for the thier account that will automatically expire on the end date and need to be deprovisioned and deleted from AD. After seeing how this works and the explaination given, I would need to create the dummy record and add the connector filter so I know that all the user accounts will be removed as required without leaving the last one active. Randy