Domino (LDAP) and CCM problems – a collection

Hi all,

today I had problems with an IBM Connections CCM installation in combination with a domino directory (nothing new for me 😉 )
I decided to collect all technotes and blog entries I know about this topic to save some time for you guys troubleshooting CCM problems.

All problems show up with an error message similar like this:

"The library may have been deleted or modified, or your access may have changed. Try reloading. If that fails, contact the library owner."

Lets start:

1. Libraries not accessible caused by duplicate dominoUNID entries in DD

As far as I understand, there was an early requirement of WebSphere Portal 5.1 to add the attribute “dominoUNID” explicitly (so that you have the dominoUNID of the person document and the dominoUNID that was added explicitly as an attribute) … Well not really clear to me why this had to be done. But in some customer DD this “duplicate” attribute still exists which causes the described problems.
Here is the solution for this problem –> here

————————

2. Library not accessible caused by “blanks” in the LDAP repository identifier

This is a technote that was created from one of our CCM PMRs. This was really a tricky one…
Take a look at the wimconfig.xml file

CCM_LDAP1

Can you see the ” ” in front of the repository identifier? This happened by copy + pasting the name into ISC console – seems that there is an additional control sign that WebSphere parser does misinterpret. This causes a miscalculation of the GUID so that Filenet is not able to lookup the user correctly.

Here is the solution for this issue –> here

——————————

3. Library not accessible caused by “complex” LDAP filter that Domino cannot handle

This is really a very bad error and I had problems finding a solution… In certain domino versions, the server does not return search results when using a “complex” search filter.

 e.g. (&(uid=*)(connectUser=true)(objectClass=dominoPerson))

The solution is described –> here

—————————–

4. Library not accessible caused by Waltz-API that performs “substring-search” instead of “exact-search”

I just had this problem in one environment. The environment has two LDAP servers configured:
– SDS –> everything worked fine
– Domino –> Library access not possible

When accessing a Library with a domino user I saw the following error in the log:

handleError 404 ItemNotFound CQL5993: The user or group testuser was not found in the domain ICDomain. Verify that you are entering a valid user ID.

&

caused by: com.ibm.connections.directory.services.exception.DSException: com.ibm.connections.directory.services.exception.DSException: 
com.ibm.connections.directory.services.exception.DSException: java.lang.NumberFormatException: For input string: ""                             
        at com.ibm.connections.directory.services.engine.VMMSearchEngine.searchVMMObjects(VMMSearchEngine.java:122)                       
        at com.ibm.connections.directory.services.component.VMMUserServices.searchUsersByLoginNameSubstringQuery(VMMUserServices.java:197)

Well it turned out that by default the Waltz-API performs a substring-search on VMM. So if you enter “testuser”, the Waltz-API searches for “testuser*” which might return more than one user entry.
This can be avoided by forcing Waltz to perform “exact-match” searches. In this case, Waltz would lookup “testuser” and the result is exactly one unique user.

There is a new technote for this problem –> here

You need to add

-Dibm.filenet.security.searchByWaltzLoginName=true

as JVM argument for the Filenet Application Server.
This property should be set in general on all your CCM environments and will be a standard JVM argument in the future IBM Connections releases

Et voilà… It started working again.

————————–

5. Existing Libraries work. But you cannot add new Libraries

This was caused due to a mismatch of waltz and sonata jars. I described the error in details –> here

—————————

6. Library access not possible caused by additional e-mail addresses in the short name field of the domino person document.

This problem was caused by a wrong order of username / e-mail addresses in the short name field of domino. This is described in details –> here

—————————

… and more to come 😉

A lot of problems, especially in combination with Domino you need to be aware of when using CCM.
I hope this helps someone out there!

Leave a Reply

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