I’ve found myself repeating this on MMSUG a couple of times recently, so a post is probably in order. Don’t go deleting everything just because a CS object disappears!
There’s a dangerous little form in the Metaverse Design section of Identity Manager which allows you to set your Object Deletion Rule. By the simple expedient of clicking a radio button you can delete Metaverse objects just because the object (ie “connector”) disappeared from a nominated Connector Space.
If you’ve also set your Management Agents to delete based on disappearance of the MV object, this deletion will then be replicated in all your connected directories.
So why am I so worried about this? Let’s say, for example, that you are supplied with a daily text file from HR listing all current users. If a user is no longer on the list then what’s the problem with removing all their accounts?
Take it from me (who accidentally disabled hundreds of user accounts using such a system) you need something more concrete when you’re going to start taking things away from people!
The fact of the matter is, glitches occur. That text file generation could have been interrupted part-way through. Even if you’re going closer to the source, eg straight from a SQL table, you can run into problems with SQL replication and DTS packages. And lets not forget the sheer scope posed by human error! I’m also wondering if an incomplete Import step into MIIS could lead to CS objects temporarily going missing … I think not, but in Good Design we don’t take the chance.
My proposal is that you figure out a way to get an extra Status field into your input data. This field should be used for tags such as “Active” and “Inactive”, as well as any other special-purpose flags you may see fit to introduce.
Here’s what you need to do:
1. Change that Metaverse Deletion Rule. You may need to write extension code (the third option), but I’ve only ever used the first option:
2. It should be fine to leave the MA Deprovisioning rules set as shown above as you won’t be deleting the Meteverse object until all CS objects are gone.
3. Create a Metaverse attribute and import flow rule for the Status field, so that it is flowed in along with other object data.
4. You can now do a simple test, in your MVExtension code, before you proceed to anything destructive:
If mventry(“Status”).Value = “Inactive” Then
account disable/delete instructions
End If
5. If you wanted to, you could now use the disappearance theory as a way to clear out objects later on – just check first that a previous import has set the expected Status:
If csobject Is Nothing AndAlso mventry(“Status”).Value = “Inactive” Then
connector deletions
End If
So, using this method, what happens if a few objects do go missing (accidentally or otherwise) from your input data?
- MIIS will remove the CSobject from your source MA, correctly reflecting the input data it has been fed;
- The metaverse (and hence other connector space) objects will be unaffected – all that’s happened is a connector has been lost;
- When the object reappears in the inital connector space it should just rejoin to the existing metaverse object. And if it doesn’t, CHECK your join rules!
If you’re worried about orphaned objects you can do the odd MIIS DB query to list the metaverse objects without a connector in the source CS, and then follow those up. After doing that a few times you will probably be well on your way to training your data handlers to NEVER just delete a record without putting it through an “Inactive” phase first!
