First published on MSDN on Dec 09, 2014
Some of you may have run into an issue with what I like to call “ghost data”. Ghost objects are essentially fragments or artifacts left over in the metaverse when a deletion should have occurred but, for one reason or another, didn’t and are left as such in a
state of limbo. Before we can understand how to deal with them, let us first discuss what these objects really are and how they might have come to be.
Most commonly, these objects were probably created when an object (typically a user) gets deleted in the portal, but a corresponding object deletion rule has not been configured in the metaverse designer. Since this object deletion rule (and usually configured deprovisioning on the target management agents) does not exist, the object gets deleted in the portal and then, on import and sync, brought into the FIMMA connector space. Once there, however, it fails to be purged from the metaverse (and, as a result, the other MA connector spaces). For example, the object deletion rule may be configured as such:
And the management agents:
A user (or users) are removed from the portal:
The deletes are seen on import of the FIMMA:
And the FIMMA is synchronized.
If we check the “pending exports” on the Active Directory MA, however, we see this:
Panicked, we configure an object deletion rule:
And deprovisioning on the management agents:
And do another round of imports/syncs, then check the “pending exports” again:
Still nothing. Now, however, we also notice this on the FIMMA:
Five “Provisioning Adds”. The same five users we deleted from the portal. Now, in addition to these users not being deleted in AD (or elsewhere), they are actually trying to come back into the portal. Note that the five “Provisioning Disconnects” here are the same five users. This is due to two (or more) synchronizations being run without an export.
So, based on this series of events, we now have five “ghost users” hanging out in the metaverse (and ADMA connector space). We’ve configured everywhere we know to configure to force a deletion, to no avail. And now, like zombies, these five are trying to crawl their way back into the portal. What now?
Fortunately, there’s a little trick in what we call a “Dummy MA”. In essence, we populate a text file management agent with a unique attribute from these five objects, join them, configure an object deletion rule then cause a disconnection (which then spawns a delete). To begin, we need to search the metaverse in a way in which we can find these objects. Since we know these deletes originated in the portal, we can be reasonably sure they were also deleted from the FIMMA connector space. Because of this, we can use a metaverse search clause of:
csObjectID Is not present
So, there are our five zombie Lincolns. However, all we have to work with is displayName (which may or may not, and probably isn’t, unique). But hold fast, for hope is not lost. Click on the “Column Settings…” button:
Here, I have selected “ <objectGUID> ” from the left hand side and clicked “ Add>> ” to make it an available column. This is the actual MVObjectID and is perfect for uniqueness as it is impossible to have a duplicate MVObjectID (thus guaranteeing uniqueness).
Next, click to select all five objects, then copy them.
And paste them into a convenient text file. Note I have added a new first row with title to what each attribute are. This step is not necessary, and the columns will, by default, be named “Attr0” and “Attr1” when we create the management agent. I do this for my own readability. Save the file as a .csv.
Next, we need to create a delimited text file management agent. The steps are basically the same as creating any text file MA so I will not cover each individual image in detail. For more information on creating a text file
management agent, please click here .
Be sure to set your anchor attribute (in this case, objectGUID ).
This step is absolutely critical for this to function. Be sure to create a join rule mapping “ objectGUID ” to “ <object-id> ”. These are actually the same value ( MVObjectID ).
Finally, create run profiles for a Full Import and Full Synchronization . Detailed steps on creating run profiles can be found here .
Lastly, run a Full Import and a Full Synchronization on the newly created management agent. You should see joins occur (each representing one of the ghost objects).
The final piece to this puzzle is creating a new object deletion rule and tying it to the new MA.
And configuring both the ADMA:
Since we have configured the object deletion rule to “ delete metaverse object when connector from any of the following management agents is disconnected ” and selected our new MA, a delete should flow outwards to the metaverse (and, by proxy, other associated management agents) when these items are disconnected. Ergo, let’s disconnect them. The easiest way to do so is to right-click on the MA and delete its connector space.
Now, if we perform a Full Synchronization on the ghost MA, we see this:
And when we check the “ Pending Exports ” on the ADMA, we see five beautiful deletes:
Remember those troublesome five “Provisioning Adds” to the FIMMA? Gone.
So, while this may seem like a lot of work, there are, unfortunately, few alternatives. After all, would you rather delete your connector spaces and try to manually purge the metaverse that way? Me either. Special thanks to Mr. Andrew Masse and Mr. Glenn Zuckerman .
Questions? Comments? Love FIM so much you can't even stand it?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.