First here is some background on the issue at hand. I am not a big fan of Lotus Notes, and having to synchronize data with the built in management agent for MIIS/ILM/FIM has brought me my share of joyful moments.

Over the years, while monitoring an MA connection to a Lotus Notes database, I would occasionally see discovery errors saying “missing-dn”, and some details about the error.   Discovery errors are very bad on connected systems since they affect other aspects of the synchronization process for that MA, so they need to be resolved as quickly as possible.

When you click on the error you are presented with the information below:


The error information would provide you the UNID of the record that is missing the DN.   The Lotus Notes MA switched to using the UNID for the anchor in one of the earlier MIIS 2003 updates,  but it translates the UNID (UniversalID) to the FullName field of the record for displaying as the DN in the connector space.

I assumed this record was just missing the FullName value, so I provided the UNID in the error to my Notes Admin, expecting it to be an easy correction.  However, my admin tells me that the UNID does not exist in their system, so they could not find it to correct it.

Perplexed with this,  I thought it must be some sort of stale data error from replicas, because FIM clearly gave me the UNID so I would wait for replication.   Time would pass,  and the error would disappear leading me to believe it was just a replica issue that waiting for additional replication resolved.

However,  recently working on a Forefront Identity Manager 2010 (FIM2010) project to synchronize a different Lotus Notes database, I  was immediately with a large amount of the discovery errors providing me UNIDs.   Once again I provided them to the Notes admin only to be told those UNIDS could not be found.  This time while collecting information, and looking at individual document records in the Notes system a pattern started to stick out.

I soon realized that the UNID provided by the Lotus Notes MA,  was provided in the wrong order of what the UNID actually was in the Lotus Notes system.

Here is how to decode the UNID provided by the MA, and to reassemble it to look up the Notes record in the proper format.

Decoding the UNID from the Lotus Notes MA:

  1. In this example,  let’s assume I have a discovery error which provided me “UNID=dd3942e17cffab30006945738625719” in the details.
  2. We break this UNID value into 4 segments of these character lengths and label each segment with the letter:
    • A = 8 chars long = dd3942e1
    • B = 8 chars long = 7cffab30
    • C = 8 chars long = 00694573
    • D = 8 chars long = 88625719
  3. Now rearrange the ordering of the segments to from ABCD to BADC
  4. You now have a value of “7cffab30dd3942e1862571900694573”
  5. This is the UNID order that will return the Notes document object in the Notes database when you search the Notes database.

Here is an example of the Document information in the Notes database.


The first 2 lines in the above image contain the UNID with some extra characters (Remove the OF on the first line, and the ON on the 2nd line).  Unfortunately searching for the document on the UNID is not a straightforward task, so your Notes admin should be able to assist with this.

I was able to give the proper UNID format to my admin, and they were able to correct the FullName issue on those records,  resolving my discovery issues.

So the question is,  why does the MA return the value in a different order than what the connected system expects?

I did just find that this was also discussed in some of the threads (and here) on the Technet forums, but I only just discovered it as I went to make this post.  Hopefully it will help someone else though.