Deprovisioning In-Depth: Part 3 – Deletions

First published on MSDN on Apr 16, 2015

This is the third and final post in my series on deprovisioning. In case you missed them, check out

post one

(regular disconnectors) and

post two

(explicit disconnectors). In this post, I'll be discussing deletions. In many organizations, I find deletions to be the most fitting form of deprovision. Some organizations do have a requirement to maintain user objects forever (though this is not common), but most, I would say, delete at some point. Now, whether that deletion occurs immediately or is staged for some future time does not matter; the configuration we're about to discuss is the same. If you're interested in hearing more about the different ways we can handle deletes, be sure to stay till the end.

For this third and final round of deprovisioning, we will configure our ADMA to “stage a delete on the object for the next export run”:

And likewise on the FIMMA

As twice before, our delete once again originates with a text file MA (though this could just as easily be a SQL based HR system)

One more time, Mr. Burr:

Full import shows a pending delete:

And a full sync shows the change being to the other connector spaces:

Now, here is where we part ways with bot regular and explicit disconnects. With a delete, if we search our AD connector space for
pending exports
we see:

And the FIMMA
pending exports
shows the same:

So, based on our knowledge that
pending exports
show the changes that will be made in our
data source when we perform an export, we know that, from the above, Mr. Burr will actually be deleted in both and the FIM portal. With that in mind, an export should show a
for AD:

And the same for the FIM portal:

We can verify this by search both the FIM portal:

And :

So, I said for more detail on deletion to stay tuned until the end. This configuration, combined with a configured object deletion rule, are necessary for any kind of deletion. The default behavior out of box when configured as such is to instantly delete on the next export run. For many organizations, though, this is unacceptable. Banking, healthcare, government – just to name a few – are among the industries who need at least some degree of data retention. Whether that duration is 2 day or 2 years doesn't matter, all the pieces (out of box and custom) are the same. For a detailed, look at implementing delayed object deletion for data retention purposes, please see

this post.

Questions? Comments? Love FIM so much you can't
stand it?





This article was originally published by Microsoft's Core Infrastructure and Security Blog. You can find the original article here.