Performance Problems in Lithnet

Other

An associate asked, ” How could there be performance problems for something like Lithnet?”

Here’s my response:

MIM has a unsupported .NET library which exposes low level calls to retrieve separate bits of data from the MIM internal data structures.  Lithnet uses these calls, and compiles together complete results for a call like “Get-PendingImports”.  Lithnet has to make many calls to get the information it needs: probably one for the list of connector space object IDs, then for each connector space object one to get metadata (DN, object type etc), one to get the attribute hologram, one to get the pending import metadata, one to get the pending import attribute delta, one to get the pending import hologram, one to get the unapplied (pending) export metadata, one to get the unapplied (pending) export deltas, one to get the unapplied (pending) export hologram, one to get the escrowed (unconfirmed) export metadata, one to get the escrowed (unconfirmed) export delta, one to get the escrowed (unconfirmed) export hologram, etc etc.  Unfortunately calls like “Get-PendingImports” return objects with all of that data (yes, even the pending export data) and that takes time to retrieve, so if there are a lot of pending operations then it can be quite time-consuming.

CSExport.exe isn’t much better, but it is a little bit more controllable than the Lithnet library, so it can be used to improve the performance slightly.  The best approach would be to use the underlying .NET library directly and only make the absolute minimum number of calls to get just the data I actually need.  That’s a road I haven’t gone down… yet.

Audit drop files don’t require any .NET calls to get the update information, but there are three big problems with them.  Firstly, they’re expensive to generate and write out to disk.  Secondly, for a Full Import they include all records and you therefore can’t tell which ones are adds, updates or deletes unless you compare the entire data set to the existing connector space, which is incredibly slow.  Thirdly, even for deltas some MAs just send a drop file with the whole object and “replace” operations (i.e. update if exists or add if does not exist) and so again you therefore don’t know if it’s an update or an add operation.

Here endeth today’s lesson; Thanks be to Microsoft.  AMIM.

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.

Failure creating new ECMA2 MA: Exception from HRESULT: 0x8023072A

Other, Sync Service

While creating a new ECMA2 MA, I was faced by this error: “Exception from HRESULT: 0x8023072A”

The only helpful info I found was this, buried deep in https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/WinArchive/[MS-UPSDBDAP].pdf

0x8023072A extension-dll-noimplementation
The management agent extension does not contain a class that implements the extension interface(s).

Turns out the DLL I was using (UNIFY Identity Broker) was an old ECMA one, not ECMA2.

Welcome to the MIMicry blog

Other

“Mimicry is a similarity of one organism, usually an animal, to another that has evolved because the resemblance is selectively favoured […] Mimicry occurs when a group of organisms evolve to share perceived characteristics with another group, the models.”
— Wikipedia

Hello!  This is MIMicry, a blog site where I share Microsoft Identity Manager knowledge and thoughts that come my way.

Why “mimicry?”  Well, most of what I do is to walk in the footsteps of Bob, Carol, Ryan and all the other generous FIM and MIM role models.