IBM Support

Connections Content Manager - When adding the Library widget to a Community, it appears as read-only for some Domino LDAP users

Technote (troubleshooting)


Connections Content Manager - When adding the Library widget to a Community, it appears as read-only for some Domino LDAP users, but not all.


The affected users may see the following error when trying to access the Library widget:
"The library may have been deleted or modified, or your access may have changed. Try reloading. If that fails, contact the library owner."

They may experience the following symptoms:
When user clicks into the Library, there is no "Upload Files" or "New Folder" buttons present, even though they are a Community Member or Owner.

Other users, also from the same Domino LDAP, are able to use the Library widget as expected.


The failing users have the attribute 'dominoUNID' explicitly added to the person document (this is usually not there*) in the Domino LDAP:

However the value of this field does not match the 'real' dominoUNID for the user, which can be seen here:

So, in Document Properties, the value for the dominoUNID field is: "4461F1537F9E37B3C1256896004F213B".
The "real" value however is in fact: "241412EA77BCE58CC12573B7005599C7".

CCM fails for these users because the GUID value that FileNet receives by looking up the user in LDAP does not match with the one in the Profiles database.
(Specifically, the value in the PROF_GUID column in the EMPLOYEE table in PEOPLEDB.)

*It's not clear what causes the dominoUNID to show up in the document properties. dominoUNID is considered an "LDAP operational attribute" and as such should NOT normally appear as a field on the Domino person record.


IBM Connections 4.5 with Connections Content Manager and a Domino LDAP

Diagnosing the problem

Using a Database client, open the EMPLOYEE table in PEOPLEDB and obtain the user's PROF_GUID value:

SELECT * FROM empinst.employee WHERE PROF_GUID like '4820C44D-39C4-6AD5-C125-68EA005196A9';

Enable the following trace and reproduce the issue:

In the 'waltz.sonata.trace.log', search for the user's login value, e.g. "JBoggs":

2013-12-24 15:43:42,643 [WebContainer : 2] DEBUG - WALTZ: [ID=4183AF54-FEB6-F8B1-8025-7C40004253F7; PRINCIPAL=Jla; DN=CN=Joe Bloggs; REP=Domino LDAP; GUID=54AF8341B6FEB1F880257C40004253F7;; TYPE=0(USER); LOGIN=JBloggs]
2013-12-24 15:43:42,643 [WebContainer : 2] DEBUG - WALTZ: CanonicalUUID = 4183AF54-FEB6-F8B1-8025-7C40004253F7;VMM ID = 54AF8341B6FEB1F880257C40004253F7
2013-12-24 15:43:42,924 [WebContainer : 2] DEBUG - WALTZ: DSX URL=

Notice that the 'ID' value in the log (highlighted in bold) does not match the PROF_GUID value in the Employee table.

Resolving the problem

PLEASE NOTE that carrying out these steps will involve making changes to both the Domino LDAP (i.e. names.nsf) AND the users' record in the Profiles database.

Ensure you have a working backup for both repositories before implementing this procedure.

1. Create a simple agent to clear the value for the dominoUNID field in the Domino LDAP.
This is what the affected user's Person document should look like after the agent is run:

2. In TDI file, ensure that "sync_updates_hash_field" is set to a different LDAP attribute other than 'guid' (e.g. 'uid' or 'email').

(For more information about this property, see here:

3. Run TDI script "sync_all_dns".

4. After the above steps are completed, verify that the user's PROF_GUID value in Profiles database has changed.

The scheduled task "ProcessLifeCycleEventsTask" should then automatically update the membership tables for the other IBM Connections databases. In case of issues that may arise because of the user's PROF_GUID changing, please refer to this troubleshooting document:

5. Retest the issue.

Document information

More support for: IBM Connections
Content Manager

Software version: 4.5

Operating system(s): AIX, IBM i, Linux, Windows

Software edition: All Editions

Reference #: 1664341

Modified date: 27 April 2014

Translate this page: