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:
Looking into the Logs showed me the following error:
[5/9/16 10:31:42:122 UTC] 0000155b LotusConnecti E com.ibm.openactivities.exception.OpenActivitiesException: 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:
As you can see, there are differences in the applications. Simply syncing the apps should solve the problem:
ActivitiesMemberService.syncMemberByExtId("4FC66FAD-FB89-A453-C125-6EB4002D0754") BlogsMemberService.syncMemberByExtId("4FC66FAD-FB89-A453-C125-6EB4002D0754") DogearMemberService.syncMemberByExtId("4FC66FAD-FB89-A453-C125-6EB4002D0754") CommunitiesMemberService.syncMemberByExtId("4FC66FAD-FB89-A453-C125-6EB4002D0754") FilesMemberService.syncMemberByExtId("4FC66FAD-FB89-A453-C125-6EB4002D0754") ForumsMemberService.syncMemberByExtId("4FC66FAD-FB89-A453-C125-6EB4002D0754") NewsMemberService.syncMemberByExtId("4FC66FAD-FB89-A453-C125-6EB4002D0754") WikisMemberService.syncMemberByExtId("4FC66FAD-FB89-A453-C125-6EB4002D0754") MetricsMemberService.syncMemberByExtId("4FC66FAD-FB89-A453-C125-6EB4002D0754")
Now executing: FeatureMemberService.getMemberExtIdByLogin(“firstname.lastname@example.org”) 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:
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:
- TDI sync pulls the Second UNID that is stored in LDAP as the additional attribute … ID that ends with “…4D5005971C9”
- 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.
- 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”
- 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.
- 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!