Deprovisioning In-Depth: Part 2 – Explicit Disconnectors

First published on MSDN on Apr 15, 2015

This is Part 2 of the series on deprovisioning. Having covered
regular disconnectors


, I'd like to use this post to talk about
explicit disconnectors
. If you have not already done so, I would encourage you to read

part one

as it lays down the ground work that this post builds on. As explained in part one, an explicit disconenctor is, for all intents and purposes, no different than a regular disconnector (with the previously noted two distinctions). That being said, I'd still like to step through the process of intentionally causing an explicit disconnect (as part of a regular deprovision) anyway. On our AD management agent, we have now configured deprovisioning to “make them explicit disconnectors”

With the same configuration on the FIMMA:

As with regular disconnection, we will initiate our deprovisioning from the Vice Presidents text file based management agent.

Goodbye again, Mr. Burr.

An import of the source data directory (as before) will show a deletion of this user object:

And a full synchronization will show provisioning disconnects to both and the FIM portal.

Just like before, searching the AD management agent connector space for
pending exports
shows nothing:

And neither does the same for the FIM management agent:

At this stage our user continues to exist in both as well as the FIM portal (just like a regular disconnector).

Like a regular disconnector, they will no longer be updated in one data directory based on changes in another. Unlike a regular disconnector, however, simply recreating this user in an authoritative data source will not bring them back. Once an object has entered the state of explicit disconnector, it will stay in that state until manually changed. In fact, if we search the metaverse from within the joiner tool, we can actually see this explicitly disconnected object:

How, then, is an explicit disconnector removed (if, for example, the user is rehired)? The process is the same as if they were a regular disconnector, but prefixed with an additional step of manually changing their disconnection state (from explicit to regular). For detailed instructions on doing so, 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.