IBM DB2 NUMDB value changes when migrating IBM Connections databases causing application problems

A very recent go live of IBM Connections 5.5 from 4.5 resulted in an error affecting Metrics. Metrics was not working what so ever.

A look at the cogserver.logs showed DB2 exceptions. I checked the DB2 client on the Cognos node, it could connect. I noticed that all the daily refreshes failed so it must have been database related.

I checked the value of the numdb having set the value to 25 after the databases were created prior to transfer of the 4.5 data. Running db2 get dbm cfg | find “NUMDB” gave me the value of 15 which is not what I set. I checked my notes and I did set it to 25.

I looked at db2diag.log and could see that the value changed at the time of go live, in fact it had changed after the databases were created and after I had changed the value to 25.

PID     : 7376                 TID : 3468           PROC : db2bp.exe
INSTANCE: DB2                  NODE : 000           DB   : HOMEPAGE
EDUID   : 3468
FUNCTION: DB2 UDB, config/install, sqlfLogUpdateCfgParam, probe:30
CHANGE  : CFG DBM: “Numdb” From: “25”  To: “15”

The above entry was at the same time that activity was happening with HOMEPAGE database.

I checked the scripts I had written and all seemed well. I then checked the lcwizard logs directory and found in C:\Users\db2admin\lcWizard\log\dbWizard\homepage_upgrade-50CR3-55.log the following


In ..\Wizards\connections.sql\homepage\db2\upgrade-50CR3-55.sql I found the culprit.

— —————————————————————–
— Defect 164873:
— —————————————————————–


I really have no idea why IBM would put that in there. There are 16 databases if you include FEBDB. Why have it for HOMEPAGE and not the other database scripts?

I updated the number of databases and then stopped all the application servers and restarted DB2 for good measure and all is well now.


IBM Connections Metrics graphs stop working after 365 days with CAM-CRP-1098 error about CSK

A Connections 5.0 CR03 customer logged a ticket because graphs stopped working in Metrics, no data was shown in any community or global Metrics.

In pogo_*.log I found the following errors.

2016-05-06 11:55:59.536 ERROR [.handlers.dispatchercache.CacheFileHandler] WebContainer : 8: Failed during cache file read CAM-CRP-1098 Unable to find the common symmetric key with alias ‘************’ in the keystore ‘/opt/IBM/Cognos/CognosBI/configuration/csk/jCSKKeystore’.

2016-05-06 11:56:15.839 ERROR [.handlers.dispatchercache.CacheFileHandler] WebContainer : 5: Failed to get URL parameters for dispatcher cache file serve CAM-CRP-1098 Unable to find the common symmetric key with alias ‘****************=’ in the keystore ‘/opt/IBM/Cognos/CognosBI/configuration/csk/jCSKKeystore’.

To restore service I restarted Cognos and all was well.

After a little bit of digging it looks like there is a common symmetric key (CSK) and the default for these are 365 days. I looked at the date some of the files and directories were created and they were around a year ago, give or take a couple of days.

Looks like what has happened is that the configuration client has not been opened for a year. On opening and saving the client saves the configuration and also refreshes the CSK key.

After a year the CSK rolls and is recreated causing the errors and the problems I observed. It’s not until a restart that it starts working again having read in the new keys.

To make sure this doesn’t happen again you can open the client using (BI and Transformer) and X11 or cogconfig.bat and increase the lifetime value. On save and close the keys will be updated. You should restart Cognos afterwards.


If you’d prefer to avoid the client or can’t X11 then update the following files.



Changing the following value

<crn:parameter name=”CSKLifetime”>
<crn:value xsi:type=”xsd:long”>365</crn:value>

Save and close the file and then run -config which will then create cogconfig_response.csv.*date*_*time*.log and in there you can see the keys have been refreshed.

INFO, “[main]”, “Silent Execution Mode (start)”
EXEC, “[main]”, “Loading configuration file”
SUCCESS, “[main]”, “Completed successfully.”
EXEC, “[Cryptography]”, “Generating cryptographic information”
SUCCESS, “[Cryptography]”, “Completed successfully.”
EXEC, “[Save Configuration]”, “Saving configuration parameters”
SUCCESS, “[Save Configuration]”, “Completed successfully.”
INFO, “[main]”, “Silent Execution Mode (end)”

The importance of Java and Cognos with IBM Connections

During an install of Connections 4.5 I came across a problem when Configuring the IBMConnectionsMetricsAdmin role on Cognos which required me to disable anonymous access in the Cognos Configuration tool (Local Configuration -> Security -> Authentication -> Cognos to set Allow anonymous access? -> False) and save.

On saving I was getting the following error in the client.


I had previously applied 10.1.1 FP001 and believed something had happened during the upgrade.

Googling came up with some suggestions all around cryptography with How to Regenerate Cryptographic Keys seemingly the best way to try and get this working. The problem was that I couldn’t export a copy of the configuration.

I tried various approaches including configuring cogstartup.xml manually removing the encryption variables so no password was set, nothing worked.

The more I Googled and researched IBM/Cognos forums the more Java was mentioned. After burning the best part of a day I started to look at what version of Java was being used.

I have installed on CentOS (not supported I know) and the version of java is as follows.

[root@cognos ~]# java -version
java version “1.7.0_09-icedtea”
OpenJDK Runtime Environment (rhel-
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

This is reading it from /usr/bin/java.

I didn’t set JAVA_HOME when installing Connections which installs Cognos so what version of Java is it using? I looked at the WebSphere SystemOut.log for the application server and noted that it is using the IBM JRE (/opt/IBM/WebSphere/AppServer/java).

After setting export JAVA_HOME=/opt/IBM/WebSphere/AppServer/java I could save my settings in the Cognos Configuration client.

IBM Connections SSO not working with Metrics

The one problem I had out the back of the Metrics install which was post-Connections 4.0 was the when users clicked on the Metrics tab they were not signed into Metrics automatically. Users were faced with the following screen.


The User ID field was pre-populated with the users userPrincipalName ( which was not accepted. To log in to metrics the needed to be removed leaving the users sAMAccountName which did work.

I changed the following fields in Cognos BI which worked and the user was signed in BUT it broke the daily and weekly cube refresh/build and no data appeared in Metrics.

User lookup – (userPrincipalName=${userID})
External identity mapping – (userPrincipalName=${environment(“REMOTE_USER”)})

I reverted back to using sAMAccountName so data was presented but the user had to remove the domain and log in manually.

I spoke with a colleague who performed the migration from 3.0.1 to 4.0 and it turns out that there was a change to the wimconfig.xml to allow the customer to log in with different attributes.

<config:attributes name=”samAccountName” propertyName=”uid”>

With this:
<config:attributes name=”userPrincipalName” propertyName=”uid”>
<config:attributes name=”samAccountName” propertyName=”cn”>

So I looked more closely at it and read an interesting piece which talks about using the replace function to remove the domain name from the string. The example given is (&(uid=${replace(${environment(“REMOTE_USER”)},”ABC\\”,””)}

I added (&(sAMAccountName=${replace(${environment(“REMOTE_USER”)},”\\”,””)} to External identity mapping and changed the syntax a few times before realising that it was supposed to be stripping the domain in from a format such as ACME\Joe Bloggs. I then changed it and after a couple of goes I got the correct syntax of (sAMAccountName=${replace(${environment(“REMOTE_USER”)},””,””)}) and after I restarted the Cognos application server the user was able to sign in automatically and all the data was there.