Sametime Proxy web client to web client audio and video

In a recent New Way To Learn session hosted by Frank Altenburg he gave us the changes necessary to enable this feature but my brief testing has been mixed.

To enable it you change stproxyconfig.xml in /opt/IBM/WebSphere/AppServer/profiles/STSCDMgrProfile/config/cells/SametimeSSCCell/nodes/*******/servers/STProxyServer/ for Linux adding “<onetoonefeature>true</onetoonefeature>”

<webaudiovideo>
<playerver>9,0,0,1523</playerver>
<softphonepluginver>9.0.0.1869</softphonepluginver>
<onetoonefeature>true</onetoonefeature>
</webaudiovideo>

Sync the nodes and then restart the Sametime Proxy server.

When you log into Sametime Proxy you’ll see that you need to install the WebPlayer plugin if you haven’t already as shown by the stars next to the two new icons.

stproxy1

stproxy2

You’ll need to accept some pop ups allowing the plugin to run.

My brief testing was mixed. I was testing on two Windows laptops and hadn’t restarted them after the plugin was installed not that it stopped me from using AV in a meeting. In most cases I saw “Call unavailable for Selected Contact” even though they were both web clients with the plugin installed.

stproxy4

I’ll test some more over the weekend. Let me know if anyone gets better results.

Remember this is a technology preview and may not be ready for production use!

Whiteboard in Sametime 9.0.1

Having just got over a problem with the Meeting server detailed in Sametime 9.0.1 Meeting server update fails due to DEPSTATUS of partial I wanted to look at the whiteboard feature that is in 9.0.1.

On a recent TechTalk whiteboard was mentioned but it was made clear that it is not supported and is not enabled by default.

The way to enable it is pretty easy.

Enterprise Applications -> Sametime Meeting Server -> Manage Modules

Map Core Whiteboard Services to STMeetingServer

Enterprise Applications -> Sametime Meeting Server -> Virtual Hosts

Map Core Whiteboard Services to the relevant VH

SSC -> Sametime System Console -> Sametime Servers -> Sametime Meeting Servers

Change whiteboard.enabled to be true and I also updated whiteboard.fileio.codebase to a different path.

3

Sync the node and restart the Meeting server.

When you log in next you’ll see the following.

1

It’s rather nice. If you draw a shape it will try to auto correct it smoothing out any of the shaky cursor lines to create a circle or square etc

2

It will be interesting to see why it’s not currently supported or what the implications are of enabling it. It may be that it was added late in the development process and hasn’t been tested thoroughly enough. Nevertheless it will be a useful tool.

I haven’t played much with it but now you can do it for yourselves!

Sametime 9.0.1 Meeting server update fails due to DEPSTATUS of partial

I updated the SSC, Community server and Sametime Proxy fine but the Meeting server (on Windows) was failing.

ibmim

In the SSCLogs directory I got the following:

2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.SCLogger init ******************************************************
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.api.Deployment setURLTimeout Cannot run program “env”: CreateProcess error=2, The system cannot find the file specified
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getBaseURL 172.xx.xx.xxx
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getOutput Is SSLEnabled = true
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL registerMyTrustManager Entered registerMyTrustManager()
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL registerMyTrustManager Exit registerMyTrustManager()
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getOutput AIDSC0877I: The complete URL is :https://ssc..acme.com:9443/console/deployment/login
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getOutput Timeout Set is :60000
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL registerMyTrustManager   Server Certificate for: CN=ssc.acme.com, OU=STAppCell, OU=sscSSCNode, O=IBM, C=US
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.ConnectionThread run AIDSC1482I: Timer is cancelled since URL hit received response.
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL constructData AIDSC0903I: The data passed to server is :ProductType=com.ibm.lotus.sametime.meetingserver&Hostname=meetings.acme.com&InstallType=PN&ComponentName=
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getBaseURL 172.xx.xx.xxx
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getBaseURL 172.xx.xx.xxx
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL sendData AIDSC0877I: The complete URL is :https://ssc.acme.com:9443/console/deployment/getInstallDepId
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.ClientUtility getDepId AIDSC0910I: Response from server :<?xml version=”1.0″ encoding=”UTF-8″?><GetDepID><Id></Id></GetDepID>
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.api.Deployment getDepId AIDSC0870I: The Deployment ID is :null

I started looking in to “Cannot run program “env”: CreateProcess error=2, The system cannot find the file specified” and “AIDSC0870I: The Deployment ID is :null” and formulated all kinds of theories such as a bug that was trying to run the “env” command which is a Linux command which has a Windows counterpart of “set.” I exhausted my investigation and enabled trace on STConsoleServer (*=info: com.ibm.sametime.*=all) as well as adding log.properties to the logs directory of IBM Installation Manager

I raised a PMR which was quickly turned around.

In the STConsoleServer trace.log the following was found.

[5/19/16 13:21:29:190 BST] 0000033d DeploymentImp > DeploymentImpl getStatus ENTRY
[5/19/16 13:21:29:193 BST] 0000033d DeploymentImp I DeploymentImpl getStatus AIDSC1486I: Size of object 1
[5/19/16 13:21:29:193 BST] 0000033d DeploymentImp I DeploymentImpl getStatus AIDSC1488I: Query Result  = 8
[5/19/16 13:21:29:193 BST] 0000033d DeploymentImp < DeploymentImpl getStatus RETURN

In the SSC I saw that the deployment plan had a status of “partial.” I haven’t a clue when this changed.

mtg

$ db2 connect to STSC

$ db2 “select * from SSC.DEPLOYMENT where PRODUCTTYPE = ‘com.ibm.lotus.sametime.meetingserver'”

$ db2 “select DEPSTATUS from SSC.DEPLOYMENT where PRODUCTTYPE = ‘com.ibm.lotus.sametime.meetingserver'”

DEPSTATUS
—————————————————————————————————-
8

$ db2 “select DepID from ssc.deployment where DEPSTATUS = ‘8’”

DEPID
————————————————————————————————————————————————————————————————————————————–
14f4cd91acd-00000000000a-MTGSDep

The fix was to change the DEPSTATUS to 1542. This is done by backing up the database first of all and then using the earlier commands to obtain the DepID change the DEPSTATUS

$ db2 “UPDATE ssc.deployment SET DEPSTATUS = ‘1542’ WHERE DepID = ’14f4cd91acd-00000000000a-MTGSDep'”

In the SSC the deployment status is correct.

mtg2

Now IBM IM passes the validation stage and I can update the Meeting server.

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
APPID   : *LOCAL.DB2.
HOSTNAME:
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

UPDATE DBM CFG USING NUMDB 15
DB20000I  The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.

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

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

UPDATE DBM CFG USING NUMDB 15@

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 cogconfig.sh (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.

1

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

/opt/IBM/Cognos/Transformer/configuration/cogstartup.xml

/opt/IBM/Cognos/CognosBI/configuration/cogstartup.xml

Changing the following value

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

Save and close the file and then run cogconfig.sh -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)”