Deleting a Connector Space: When, Why and How

***PLEASE NOTE:   This post is explicitly intended for use with on-prem (FIM/MIM) only and is NOT for use with AAD Connect. Following this process with regard to AAD Connect may be considered an unsupported action. ***

 

Today I’d like to discuss something I get asked about a lot: deleting connector spaces. Virtually everyone who uses FIM has seen the option to delete them, but few people feel comfortable knowing when or how to do so in a safe manner. The other side of this coin are those who think nothing of deleting their connector spaces on a whim. Often times, however, these individuals, however gung-ho, may be unaware of the proper process and, usually, end up making things worse.

Right-clicking on any management agent and selecting “Delete” will display this window. Here, we are
given the choice to delete the connector space only, or the connector space and the management agent.

First, let’s discuss the “why”. Under what scenarios does deleting a connector space make sense? I think the most common scenario I see involves bad logic (usually of the join variety). Someone has configured what they thought was good join logic on a management agent (typically an ADMA) that resulted in many, many bad joins. For example, maybe a singular join criteria of “sAMAccountName->accountName” was put in place. Generally speaking, this is OK, as sAMAccountName has to be unique forest wide (as required by Active Directory). But what happens in a 2+ forest environment? Suddenly, John Doe (jdoe) from Forest A and Jane Doe (jdoe) from Forest B have been joined. The result is bad juju. While it is true there are several approaches to handling this, I find the quickest/easiest (in cases where this has occurred in a connector space with tens or even hundreds of thousands of user objects) way of handling this to be connector space deletion. Here, we would remove/modify the join logic, delete the connector space, then perform a full import and full synchronization to rebuild it. At that point, everything is healthy again. Basically, deleting a connector space makes sense any time one has become corrupted to the point where there’s no other quick and/or easy way to fix it.

Now that we know under which circumstances it makes sense to delete, let’s talk a little bit about how to delete. On the surface, it’s as simple as:

Right-click the management agent, select “Delete” and choose “connector space only”

This does, however, carry the potential of making things far, far worse than the problem you’re trying to correct. First and foremost, if you are about to delete a connector space and have synchronization rules in your environment, you have to disable synchronization rule provisioning. Failure to do so can (and usually does) result in duplicate or orphaned metaverse objects. Now, you may be thinking, “ok, I’ll just delete the metaverse, no big deal”. Unfortunately, however, there really is no way to delete the metaverse, we do have some round-about ways of clearing it out, but it is not a simple of straightforward process. In similar form, if you are instead using a rules extension, you would need to make certain the box for “Enable Provisioning Rules Extension” is unchecked.

Here we see the option to “Enable Synchronization Rule Provisioning”. Make sure this box is unchecked
prior to deleting a connector space.

Likewise, prior to deleting a connector space, you must be sure to check (and disable) object deletion rules in the metaverse designer. For example, an object deletion rule typically used says, “delete an object when it is disconnected from any of the following” and has a list of management agents. What happens when the connector space I am about to delete belongs to one of the listed management agents? Deletion of the connector space would technically disconnect every object in that management agent. And, since we have configured it to “delete when disconnected”, this could potentially stage
a delete for every object in that management agent in every other management agent. This could result in what we call a “resume generating event” .

Here we can see the configured Object Deletion Rule. This is the normal configuration to delete
users. As configured here, if any user disappears from either “Blue AD” or “Red
AD” (disconnection) they will be deleted in all other connected data sources.
If this were left as configured and the connector space for either of these
were deleted, all users contained therein could potentially be deleted
everywhere else they exist.

 

From here, the actual deletion is pretty straightforward. Now, I would like to talk about what happens after we delete the connector space. More especially, I’d like to discuss the scenario of deleting multiple connector spaces. Let’s just say things have gotten really bad. As in, bad to the point where I’ve deleted both an AD management agent connector space as well as the FIM management agent connector space. Now what? Sure, the next steps are full imports and full syncs. But there are additional considerations to take at this point. For example, we all know we can easily configure join logic on our ADMA, but what about the FIMMA? The FIMMA, having no direct join logic, is rather finicky. By this I mean, if we were to perform an import and sync on it first, we will most likely experience additional errors. The reason for this goes back to the six individual steps that make up synchronization. Remember, if an object is new (not pre-existing), during a synchronization it will be projected into the metaverse. Likewise, an old (pre-existing) object will attempt to join. Seeing as there is no join logic on the FIMMA, we must make sure he is the one to do the projection. After all, if we have just flattened the connector space, from
the standpoint of the metaverse, all objects are now considered to be “new”. So, in this scenario, we would want to perform full imports (to build the connector spaces), but the FIMMA should absolutely be the first one to synchronize. This will allow it to project all objects back into the metaverse, so that when we sync the ADMA its users can then join.

The above image shows the configured join logic for a user object on an Active Directory management
agent. Note the “sAMAccountName -> accountName” join mapping. In a single forest environment, this is generally acceptable.

Here we see a FIM management agent. Note the absence of the of “Configure Join and Projection Rules” tab.

So, let’s actually walk through a typical deletion scenario covering all steps. In this scenario, we will assume we have two connector spaces (ADMA and FIMMA) that are being deleted.

 

  1. Disable “Synchronization Rule Provisioning”
  2. Disable metaverse object deletion rule
  3. Delete ADMA connector space
  4. Delete FIMMA connector space
  5. Delta synchronize each management agent (Delta synchronization will process disconnectors and, if we’re lucky, should clean these objects out of the metaverse
  6. Full Import ADMA and FIMMA
  7. Full synchronization on FIMMA first (we should see all objects projecting into the metaverse)
  8. Full synchronization of the ADMA (we should see joins occurring)
  9. At this step, we may enable “Synchronization Rule Provisioning”
  10. Re-sync both management agents and perform exports (if any)
  11. Recreate object deletion rule

 

It is important to note the delta synchronization step following connector space deletion. This will force FIM to process disconnectors (which should be every object in the deleted connector space) and should purge those objects from the metaverse. This is a crucial step in the process. If the metaverse is not cleaned out, the bad objects we are trying to get rid of will remain and, on the next synchronization, essentially undo the deletion.

 

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

EMAIL US>WE WANT TO HEAR FROM YOU!<

## https://blogs.msdn.com/connector_space # #