IBM Connections – problem with duplicate dominoUNIDs

IBM Connections – problem with duplicate dominoUNIDs


we saw a very strange behavior in one of our customers environment this week. Several hundred users were not able to use parts of IBM Connections, getting errors like this:

Bildschirmfoto 2016-06-02 um 08.28.21

Looking into the Logs showed me the following error:

[5/9/16 10:31:42:122 UTC] 0000155b LotusConnecti E 
CLFRA0473E: Error locating profile: EXID mismatch, but email matches.  
name=XXX, directory EXID=DF8478A0-4CC8-0CBB-C125-7A930077FA56, 
db EXID=4FC66FAD-FB89-A453-C125-6EB4002D0754

No problem… Looking at the Ids I saw differences in features:

Feature EXT-ID
Profiles FC66FAD-FB89-A453-C125-6EB4002D0754
Activities DF8478A0-4CC8-0CBB-C125-7A930077FA56
Blogs 4FC66FAD-FB89-A453-C125-6EB4002D0754
Dogear 4FC66FAD-FB89-A453-C125-6EB4002D0754
Communities DF8478A0-4CC8-0CBB-C125-7A930077FA56
Files 4FC66FAD-FB89-A453-C125-6EB4002D0754
Forums DF8478A0-4CC8-0CBB-C125-7A930077FA56
News 4FC66FAD-FB89-A453-C125-6EB4002D0754
Wikis 4FC66FAD-FB89-A453-C125-6EB4002D0754
Metrics DF8478A0-4CC8-0CBB-C125-7A930077FA56

As you can see, there are differences in the applications. Simply syncing the apps should solve the problem:


Now executing: FeatureMemberService.getMemberExtIdByLogin(“”) showed me, that all ExtIds were the same.

The customer tested again but told me that still it is not possible to use activities and communities. What the hell is wrong here?

Looking at the IDs I saw again the same result as shown in the table above…

Checking the User using a LDAP browser revealed the problem:

Bildschirmfoto 2016-06-02 um 08.11.53

There are two dominoUNIDs with different values…

  • First UNID is the DocID that each document in Domino has
  • Second UNID is an extra attribute “dominoUNID” that has been added to the directory years ago – must be more than 10 years ago or so

What happens is the following:

  1. TDI sync pulls the Second UNID that is stored in LDAP as the additional attribute … ID that ends with “…4D5005971C9”
  2. TDI is happy, the user is synchronized and the canonical String is stored in the field PROF_GUID. This is the ExtID that is syncrhonized to all applications.
  3. Now the user logs into IBM Connections… When logging in, the dominoUNID or the canonical String is available within the session. This time the First UNID is pulled. The value that is stored as DocID. ID that ends with “…4D0002A8671”
  4. Communities that was first called tries to insert this into its member table, as this ID seems to be new for Communities – this does not work, as the email of this user is already available.
  5. Now we have the problem!!!

The issue is also known in combination with CCM and described here

How to resolve this issue?

  • Remove the additional Attribute from Domino (Be careful, as TDI will inactivate the user if the field “guid” is used.
  • We changed the synchronization from guid to uid after all users have been changed
  • TDI pulls the new, correct ExtID and we are fine 😉

One question remains… How was it possible that those IDs did not match anymore? The customer used an agent to synchronize both fields. This has been inactivated some weeks ago. Some days ago they had big problems with replication conflicts. It seems that the “wrong” replica has been deleted and the DocID got a new value causing the differences between both attributes.

Overall a bad thing… Watch out for this additional dominoUNID attribute! It only causes problems!

One thought on “IBM Connections – problem with duplicate dominoUNIDs

  1. Thanks. Just one additional thing:
    You could just use collect_dns and populate_from_dn_file, this iterates on the $dn within collect.dns and do not use uid or guid for matching. So after “repairing” ldap it just synchronizes your new GUIDs.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.