Various MIM, Broker & UNIFYNow conventions explained

Good, Learnings, Other, Ugly, UNIFYNow

This post is a consolidated collection point for notes about MIM, UNIFYBroker and UNIFYNow conventions that should be followed, with explanations why.

UNIFYNow

MIM Run Profile Operation Names

Convention

In UNIFYNow, operations that run MIM profiles should always have the name of the MA and the Run Profile being invoked clearly evident.

Rationale

When MIM run profiles are recreated, or ‘Refresh MA’ is clicked in UNIFYNow (either intentionally or accidentally) the run profile GUIDs on operations can end up being incorrect.  When this happens it may be necessary or expeditious to simply re-select the appropriate MAs and run profiles from the GUI, in which case having the name of the MA and run profile in the operation name will be extremely beneficial.

In Event Broker 4 (an older version of UNIFYNow) there is a known issue where this can happen unexpectedly when a server is rebooted in certain, rare conditions.  The exact trigger for this behaviour is unknown.  It may be related to starting Event Broker on a system where the WMI Service is not running, but this is by no means certain.

Changing case/capitalisation on Identity Broker attribute names

Learnings, Ugly, UNIFYBroker

UNIFY’s Identity Broker keeps old attribute names (both connector and adapter), in the ‘CollectionKey’ SQL table.  The attribute’s name (‘Caption’ column) is a unique key in that table.

Even if you delete an attribute from every connector and adapter in Broker, it still keeps that attribute name record.  Even if you delete all data for the attribute!  It’s there for good, with whatever capitalisation you first used.

If you try to use that same attribute name with a different capitalisation (e.g. in an Rename adapter transformation) Broker does a case-sensitive search for that attribute name’s CollectionKey record and doesn’t find it (because the case doesn’t match).  So it tries to create one… but this fails because the SQL unique key for the Caption field is case insensitive!  The error is:

Violation of UNIQUE KEY constraint 'DF_CollectionKey_Caption'.
Cannot insert duplicate key in object 'dbo.CollectionKey'.
The duplicate key value is (xxxx).

Solutions to this predicament are:

  1. Don’t ever change the capitalisation of the attribute name (avoidance)
  2. If you have to change it (e.g. because you got it wrong in the first place) then go into the SQL table and change the Caption to whatever capitalisation you want 🙂

Criteria-based sets and “prior to today” evaluation in the Portal vs the MIM Service

Learnings, Lithnet, MIM Service, Portal, Ugly

So… maybe you have a set like this:

You might wonder exactly what “prior to today” actually means.  Especially when it comes to timezone handling.  And if you’re not wondering that, well you probably should be 🙂

First of all, remember that all your time DateTimes are (or at least should be) stored in UTC inside the MIM Service database.  That’s the sensible approach, and the Portal will format your DateTimes correctly based on the configured timezone if you do.

Anyway, back in the Portal and you’re clicking the “View Member” button.  It’s not hard to work out that “prior to today” seems to actually mean “prior to now” there.  Specifically, the UTC time in your attribute needs to be before the current UTC time.  I’m not specifically sure if that’s the web browser’s UTC time or the server’s UTC time, but in any sensible environment they’ll be the same anyway.

Here’s a quick look at the underlying Filter attribute to get a better understanding of that:

So it’s all about fn:current-dateTime().  Cool.

So far so sensible.  Now we know that temporal sets like this only get re-evaluated when the FIM_MaintainSetsJob runs on the SQL server.  And here’s where the pain sets in – a user with accessExtensionExpiryDate prior to the current time appeared as a member just fine in the Portal, but when I ran the SQL agent job to recalculate my set membership the user object didn’t get added to the set.

After quite a bit of trial and error it appears that the SQL Agent job’s definition of “prior to now” is “before 1AM today in the local server time”.  I can sort-of understand a decision to do the evaluation in local time – at some time someone decided that the job should just do the sensible thing, since “prior to today” inherently needs to know what “today” means, and using local server time is probably what MIM developers want, rather than “today” in the UTC sense.  But the 1am threshold?  That makes basically no sense to me.  I can only guess it’s because FIM_MaintainSetsJob is configured to run at 1am by default.  If that’s the case then hard-coding the definition of “today” to the time when a SQL job runs by default isn’t my idea of sensible programming 🙁

No wonder temporal sets cause headaches!

Addendum: if you really want to see what’s in your Set, LithnetRMA is your friend:

(Search-Resources -XPath "/Set[DisplayName='My Lovely Set']" -AttributesToGet @("ComputedMember")).ComputedMember