Today I learned a new lesson during troubleshooting a IBM Connections System. I updated to 6.0 CR2, updated WebSphere to FP13, last fixpack for Docs and so on. You will ask if I added IFP88438 to the list, be sure that I installed this fix which reanables the root element in Federated Repositories. Have a look at WAS 8.5.5 FP12 breaks Domino “root” base entry setting for more details.
Then one of the two deployments showed strange behavior with Activities. On the Activitystream I only got an orange error symbol instead of the Todo list and when I opened Activities directly I got an empty page.
The error log just said CLFRA0123E: Profile Provider Error and
EJPVJ9367E: Unable to associate the login ID cnxadmin to the user ID 0C000000-EC0B-0E00-ADMI-N,OU=SVC,O=EXAMPLE,C=DE
com.ibm.lconn.wikis.web.servlet.Application doGet The current user is not valid.
All other applications worked, they showed similar errors in the log, but everything worked. TDI Synchronisation worked perfectly. I checked the databases and found that new admin profiles got created with this DN/UUID syntax. Normally I would expect a UUID here.
A third system worked in that environment, but with different LDAP servers. All other applications (Sametime, Printer, Quickr) which used that server worked perfectly.
Several restarts later, I checked everything.
Rollback Fixpack Install on WebSphere
Enabled and disabled the administrator user.
Redeployed Activities and so on.
Nothing helped!
I could logon and only Activities had issues, so I decided to go back to a snapshot with CR1.
What shall I say? Same error appeared…
So I started a LDAP Browser and tried a search on the directory server (Domino LDAP System).
Ok, so the LDAP server has a problem, when I tried the directory search. Sorry about the german error message, it says:
Directory Search - [servername:port]
An error occurred when the schema was received. The schema entry from … does not seem to be valid, since the required attributes attributeType and objectClass with non-empty value sets do not exist. Try changing your credentials or the list of server-side access controls (ACL).
A short view on the Domino LDAP server showed that the database index for names.nsf was missing, but that couldn’t be the root cause, because the LDAP server was used several months for authenticating WebSphere, Connections and Sametime.
A short restart later and a new try …
After the restart the ldap browser was able to search and gets results. Restarting Connections server and Activities showed up.
What have I learned?
A lot …
First of all it was a little surprise that the different applications of Connections do direct LDAP calls. I knew that Blogs do this, because the blogs ldap table never used the peopledb content, it collects the user informations directly. The Activities lookups seems very long, because in my experience only longer queries have problems with missing indexes on directory databases. Failover LDAP servers are useful for outages, but when a LDAP server provides wrong or short returns, these are valid and do not force a switch to other LDAP server.
As best practise I learned that I could save a lot of time, when WebSphere fixpacks and interim fixes are deployed seperatly, not in one big step. For example you can install WebSphere 8.5.5.13 with some IFP in one step, just with adding the repositories in Installation Manager. When you want to do a rollback, this is not possible. So installing first 8.5.5, then Fixpack 13 and in a third step the IFP creates 2 possible rollback positions.
