FIMMA vs non-standard MV Schema

(note-to-self)

As you probably know, in ILM the MV schema can be changed easily.
It’s pretty easy to add or remove attributes.

In the past, in some cases, customers had the MV completely removed and rebuilt to only contain (just) the object and attribute definitions needed. Fit to the customer’s standards, without overhead.

In FIM it still is quite easy to manipulate the FIM Sync MV schema at will.
Easy! … at first sight.

NOT! Because the FIMMA doesn’t like it.

If you add the FIMMA after you change the default MV schema, you could run into trouble.
That is, the FIMMA the wizard checks the MV schema (note the Update Schema step).

And if one or more default object definitions are missing, the wizard prompts you to update the schema.
AFAIK, strangely enough the option is not triggered when all default objects are present, even if some default attribute definitions are missing.

You’ll need to click Next> to continue installing the FIMMA.
(“< Back” for previous step, “Cancel” to stop installation…)
So, there’s no option to continue installation without changing the MV, even not partially.
No other way around.

In the demo setup I use for the screenshots, the following objects were removed, because they were not managed by FIM: computer, domain, function, locality, organization, printer, role.

Additionally, the group object had been created manually as “Group” (uppercase “G”).
Same thing for OrganizationalUnit, … and some attributes.

Under “Schema Update Status” the wizard shows the detailed info, like

Reading though the update status, you could encounter different types of messages, like:

/../
Create <missing object name> object…
The attribute <missing attribute name> will be added.

Create <object name> object completed with the following warnings:
The attribute <changd attribute> already exists. It should be  “<default name>” indexable non-indexed, but is  “<changed name>” non-indexable non-indexed.
The attribute Manager already exists. It should be  “manager”, but is  “Manager”.
/../

Apart from automattically adding missing attributes, the wizard also duplicates attributes that already exist to match the object. So it restores the link between the attribute and object.
But it does NOT change the attribute type. 

Just an example, if you completely removed the ‘street’ attribute from all objects, the wizard will add it again as String(indexable) and map it to the appropriate objects.

BUT, if you created the attribute ‘STREET’ (as Binary (non indexable)), you’ll get a notice the attribute ‘STREET’ already exists, although is should be ‘street’… And again the wizard maps ‘STREET’ to the default objects where it is supposed to be linked.

Conclusion, better avoid this annoyance and loss of time (spent deleting MV objects), so:
– Don’t delete default object definitions
– Stick as much as possible to the standard FIM Sync MV Schema.
– Don’t re-add default objects or attributes that have even the slightest difference in naming (change in uppercase/lowercase) or type definition

If you need additional attributes
– add non-default object types (like ‘Identity’ for people or persons)
– by preference, add custom attributes to to the existing object types

If you really would like to clean up the MV or really need to set it your way:
– first add the FIMMA, then change the MV
– keep it in mind when you need to restore the FIM config for whatever reason (eg moving from DEV > Accept > production)

And leave the synchronizationRule, expectedRuleEntry, detectedRuleEntry in place, they are needed for the core FIM system functionality

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s