An alternate method for dealing with Orphaned MetaVerse Objects

Update 21 April ’17. The LithnetMIISAutomation PS Module now has a -Force switch for Delete-CSObject

As often happens in development environments, data changes, configurations change and at some point you end up with a whole bunch of objects that are in no-mans land. This happened to me today. I had thousands of objects that we basically empty but had previously triggered to be exported to the MIM Service prior to them actually being deleted from the source management agent.

FailedCreations
Failed Creation via web services

An example of one of the objects. A group with a Pending Export to the MIM Service.

Failed Creation via web services
Failed Creation via web services

A closer look at the object and there is no attribute data present as the source object had been removed.

no attributes to sync
no attributes to sync

And only a single connector, to the MIM Service which it will never reach as it doesn’t contain the mandatory attributes.

single connector
single connector

Normally to clean up such a mess you’d probably be looking at deleting the Connector Space for the MIM Service and then refreshing it from the MIM Service and these objects would be gone. However, this development environment is rather large, and that wasn’t something I had time or was prepared for at this time. So here’s how I worked around the issue.

Deleting spurious objects from the Connector Space

There’s two approaches;

  1. Select each of the errors, select the MIM Service Connector and select delete. That would work but I had thousands.
  2. Automate the process described in point 1. That’s the approach I took

Using the ever versatile Lithnet MIM Sync Powershell Module I retrieved the last run details for my MIM Service MA. I grabbed all the errors, inspected the errors for the ones that were failing creation to the MIM Service and then deleted the CSObject for that orphan.

Here’s where it got more than a little *clink clink* cowboy-ish. The Delete-CSObject cmdlet requires confirmation to delete the CSObject. There is not a switch to force the delete, or accept confirmation globally*. I wasn’t going to click Yes or press Enter 5000 times either.

drinkingbird

So I wrote a small script that loops and checks for the Confirm disconnection dialog and sends the enter key to window.

Here’s the two little scripts.

This first script retrieves the last run details and loops through the errors.

This second script which I ran in a second separate PowerShell Runspace loops around and presses enter at the right time.

*I’ve submitted an enhancement request to Ryan to add a confirm parameter to Delete-CSObject. UPDATE: You can now use the -Force switch. Get-CSObject -DN $objDN -MA “MIM Service” | Disconnect-CSObject -Force