Maybe it’s because MIIS is a sort of infrastructure thing, so is given to a time-pressed system administrator to set up; or because it’s a sort of programming thing, so is given to a .NET developer with no clue about the connected directories; or because there’s a lack of good training; or no clear guidance on best practises…. whatever the reason, it’s pretty easy to get in a mess with MIIS.
My mantra in all things IT is Keep It Simple, Stupid (well, that and Go Home And Sleep On It, though GHASOI doesn’t have such a nice acronym). Whatever complicated messy solution presents itself first, there is almost always a far more simplistically elegant one lurking in the wings, and though you might have to tidy up some of your earlier patch jobs to get to it, simplicity is always a worthwhile goal in itself, contributing to the long-term maintainability and transparency of your system.
So here are my top tips for a KISSable MIIS installation.
Seperate Provisioning Extensions
Using the MVRouter approach, seperate your MVExtension code into a dll for each provisioning MA.
So if you are creating objects in MAs called AD, ADAM and Phonelist you would have three provisioning code projects: MVExtension_AD, MVExtension_ADAM and MVExtension_Phonelist.
Note that in this approach, each dll just focuses on the objects to be created in its own connector space. This is completely opposite to another common approach: organising provisioning by object type, which, frankly, can turn into quite a mess if there are many target MAs, and different rules concerning them all.
If you’re really clever you can modify MVRouter to use an XML control file where you can selectively switch off provisioning to individual MAs. This is really useful in complex environments with many MAs.
Just remember that MIIS still runs each provisioning extension against all metaverse objects so you need to include a check at the top of the Provision sub, such as:
If Not mventry.ObjectType = "user" Then Exit Sub End If
A Simple Structure for the Provisioning Code
I have a basic format that I almost always use for the Provision sub.
Dim MA As ConnectedMA = mventry.ConnectedMAs(MA_NAME)
Dim ShouldExist as Boolean
' Logic to set ShouldExist based on whether the object
' should exist in the connector space
If ShouldExist And MA.Connectors.Count = 0 Then
'Provision
ElseIf ShouldExist And MA.Connectors.Count = 1 Then
'Check if rename needed
ElseIf Not ShouldExist And MA.Connectors.Count = 0 Then
'Nothing to do
ElseIf Not ShouldExist And MA.Connectors.Count = 1 Then
'Deprovision
Else
'Error - too many connectors
Throw New UnexpectedDataException("Metaverse object has too many connectors to " & MA_NAME)
End If
Minimise Advanced Attribute Flows
Obviously I am not saying you shouldn’t use Advanced attribute flow rules – they’re extremely useful and often the neatest solution.
BUT I do have a general philiosophy about generating data outside MIIS and then syncing it through MIIS.
A lot of this is due to straight forward troubleshooting. Let’s say a user’s email address is wrong in AD. If you were flowing the email direct it would be a simple matter to point to incorrect source data, or perhaps an incorrect join.
Now lets say you were using an advanced flow rule to construct the email address based on some combination of first name, surname and department. Troubleshooting now could include attaching a debugger and tracing through the code. Apart from being a pain in the neck, this is not a task that is easily delegated. Far better to generate the email address outside MIIS (for instance, by using SQL queries or SSIS packages) and then just sync it straight through.
There is also the simple argument of efficiency. The worst advanced flow rule I have ever seen was populating group members by running SQL queries against the metaverse. Some of the groups had thousands of members and to say this was slow was a complete understatement – it barely crawled. By exporting the member DNs, and populating the groups in a SQL table outside of MIIS, I was able to reduce a four hour sync to eight minutes.
Remove Complex Join Rules
Complex join rules, with multiple possibilities and join resolution logic, should only be used as a short term measure to sort out who is who. Once the joins have been made you should flow something uniquely identifying and unchangeable out to the the connected objects. Then you can replace your complexity with a simple, direct join rule.
If you absolutely cannot export an identifier to this data source then use an XMA with a SQL table to keep track of the matches – like here. You’ll be glad you made the extra effort when you have to delete and reimport your connector space.
And the rest…
There are other things I could include – like simplifying your metaverse design, and being consistent with your attribute names… but the topics I have described here are areas where most installations I’ve seen could make improvements. Just keep it simple, and the rest should follow.
