Gone, but not forgotten

For over twelve years I have worked for an IBM Business Partner in the UK focusing on IBM Collaboration Solutions and I have loved every minute of it but it’s time to move on to a new challenge which is not within the ICS community.

Coming from Domino third level support I crossed over easily to Sametime 6.5.1 which at that time was an add on to the underlying Domino server (still true to an extent now). Sametime was my first love. It should have been easy, right? An additional installer on top of Domino and for many deployments it was and still is although not so much now with WebSphere and DB2 in the mix.

What I loved were the problems Sametime caused or should I say, problems caused when you introduced Sametime to a large user base. I wrestled for many days tuning Sametime for a large deployment of over 40,000, tracing LDAP, debugging the text files and tweaking the sametime.ini. This was a baptism of fire and I loved Sametime more for the pain it caused me. I learnt so much, much of it I still remember and often come across when deploying Sametime for customers.

In 2007 I went to Collaboration University in London as Quickr had been recently released. It was my first introduction to the ICS community. Being in the same place as dozens of others all with the same approach of making Sametime, Quickr and Domino successful was intoxicating. I had already quite a bit of experience of Sametime but it helped to be in the same place as Chris Miller, Carl Tyler, Rob Novak and Warren Elsmore to bolster that knowledge and start learning about Quickr. Quickr took off incredibly quickly being easy to implement and manage which is why it’s still being used now long after it went end of life.

In recent years Connections has been the application that seems to be more in demand so I have seen my time split between the two applications. I remember being introduced to Connections, also in 2007, at a course in Hursley which described deploying and configuring Connections 2.0. At that point there were only six applications and Bookmarks was called Dogear!

Connections is a wonderfully complex set of applications which has come a long way from the days when they were a collection of disparate applications bundled together with WAS acting as the glue. The premise to get people working together better and allow you to find information quickly so you can focus on your job. For many people like me that resonates. I get paid to work with software that allows people to work together better, to formulate relationships with one another and most importantly to share. You might argue the case that is the same of all software but that’s not true. Connections is unique to that extent.

I don’t know whether it was Connections that started my journey or whether it was already something inside of me but sharing is one of the most important aspects of my job. Connections is all about sharing. Information is put into Connections for others to consume. They have a subject of interest and Connections allows them to find a person with knowledge of that subject, to follow them, to communicate with them, to add their take on the subject.

This approach to sharing makes public all your knowledge. No more do you find that people are keeping information in their mail files or P drives, it’s all there to be found. The days when you hoarded your information to make you seem indispensable to your employer are gone. People who are actively sharing their information are now seen to be those who are indispensable.

This sharing concept is underlined by two excellent Skype chat groups for Sametime and Connections. Within these two chat rooms are people such as Gabriella Davies, Robert Farstad, Michele Buccarello, Sharon James, Christoph Stoettner, Keith Brooks, Marco Ensing, Matteo Bisi, Michael Urspringer, Nico Meisenzahl, Roberto Boccadoro, Wannes Rams, Chris Whisonant and many others I haven’t mentioned. They are busy people but they help with problems whenever they have a spare 10 minutes. They share their wisdom and experience with whomever asks regardless of the complexity of question. The underlying sharing ideology runs through all these people, through the software into the wider ICS community.

As I alluded to in the opening paragraph, I am set for a new challenge and searching for the right challenge has taken me outside of the ICS product portfolio but I am staying within the larger IBM sphere. I am joining IBM Resilient working on their security incident response platform which was bought by IBM last year. It looks like an exciting time to be joining what is a growing industry.

I am sad to leave such a wonderful community at such an exciting stage with Pink gaining traction. I strongly believe Pink and it’s underlying platform will be a success especially with the aforementioned people driving the product forward.

Whilst I will soon be gone, the years working with this software will not be forgotten and neither will the friends and colleagues I have made along the way.


Sametime file transfer not working due to chat logging settings

Internally I transitioned our users over to a new Sametime 9.0.1 Community server with audio and video, meetings, TURN server, the works and it all worked, apart from file transfer.

When opening a chat window, the file icon would show but after about 1-2 seconds it would disappear. If you were quick enough you could send the recipient a file.

I checked all the policies, I checked policies.user.xml, I updated managed-settings.xml, I enabled trace on the client which showed it was enabled and I tried various configurations and all of which show that file transfer (both direct and via the server) was enabled.

The L3 IBM’er came back with the following

Next I looked at sametime.log and I see ST filetransfer is not staying started and suspect this is why the client can’t file transfer and they see the file transfer but show up and then go away::
I stplaces 28/Feb/17, 19:27:41 Places is operating in mode RELAX (1)
I stfiletransfer 28/Feb/17, 19:27:41 ChatLoggingMgr::setMode: mode <1>
E stfiletransfer 28/Feb/17, 19:27:41 Failed to load chatLogging BB or find one of its functions
E stfiletransfer 28/Feb/17, 19:27:41 Logging initialization failed for ChatLog library []
I stfiletransfer 28/Feb/17, 19:27:41 Terminated
I stlogger 28/Feb/17, 19:27:41 Initialization completed
I stchatlogging 28/Feb/17, 19:27:41 ChatLoggingMgr::setMode: mode <1>
E stchatlogging 28/Feb/17, 19:27:41 Failed to load chatLogging BB or find one of its functions
E stchatlogging 28/Feb/17, 19:27:41 Logging initialization failed for ChatLog library []
I stchatlogging 28/Feb/17, 19:27:41 Terminated

Chatlogging being enabled when it actually does not exist causes these type of errors and I see in the stconfig.nsf -> Communityservices document,
that yes chat logging is enabled and in relax mode:

But in sametime.ini there is no chatlogging enablement statements:

Potential solution
If no chatlogging software then they need to set the setting Flag: off and Type: 0

I updated the values in the SSC which updated the document in stconfig.nsf and after a restart of the Community server file transfer is now available!

The default is to set the following value to “when available” but setting it to “never” worked for me.

Update – 27/04/17

IBM told me that with 9.0.1, out of the box, this option is disabled by default. As this was a server upgraded to 9.0.1 it may have been the case that had this enabled. Or, I may have set it accidentally….

Update – 28/04/17

IBM posted the Technote yesterday – https://www-01.ibm.com/support/docview.wss?uid=swg22002683&myns=swglotus&mynp=OCSSKTXQ&mync=E&cm_sp=swglotus-_-OCSSKTXQ-_-E

Whiteboard now removed from Sametime meetings

I created Whiteboard in Sametime 9.0.1 after finding that a whiteboard feature was added to meetings some time ago.

This morning Andreas Bader got back to the Skype group, IBM Sametime Community Chat after finding that the whiteboard feature had been removed after applying the latest Meeting server patch. Andreas had logged a PMR asking IBM where it had gone. IBM’s response was;

“I can confirm The Meetings Whiteboard feature release is being put on hold indefinitely.
The module “Core Whiteboard Services” has been removed permanently from the ST Meetings build, the whiteboard was an unsupported proof of concept feature.”

Cheers IBM. You finally gave us something people wanted for ages and then took it away.

Sametime photos served up by IHS

Between customer work I have been working on replacing our internal Sametime servers with shiny new 9.0.1 servers using AD instead of Domino LDAP.

The final piece of the puzzle is photos. Anyone who knows Sametime knows that something as simple as a photo is not made simple by the applications. The Sametime Proxy requires an LDAP attribute (PhotoURL) to be used which points STProxy to the image retrieving it for the client. Meetings doesn’t use the same approach, grr. It can use a binary object saved in LDAP or offload the retrieval to a web server like PhotoURL for STProxy but uses a “string” where all photos must be named joe.bloggs@acme.com.jpg. Confusing? Yep.

I was about to roll over and say it’s not possible but it seems that it is possible to cover all use cases.

  1. Notes/Sametime clients using ImagePath URL
  2. STProxy web client using PhotoURL
  3. Meetings off loading to a web server
  4. Stop external access to photos

The nice thing STProxy does is that it will “proxy” the photos so the web browser doesn’t need direct connectivity to the jpgs. That is great because I can put the photos on an internal facing web server. The STProxy then calls the URL specified in the user’s LDAP entry (PhotoURL), caches it locally and then serves it up. Brilliant, I can lock the photos away so that no one can browse them from the internet if they know our email addresses.

You’ll need to update stproxyconfig.xml adding proxyServerURL otherwise it will not work. Don’t forget to sync and restart STProxy.


Ah, the Meeting server doesn’t follow the same logic. Clients (thick or web browser or mobile) need direct access to the photo to render it in the client. This means I’m back to square one….

Let’s jump back a step. How do we get the photos up to a web server?

Photos from Connections

At present our Sametime and Connections servers are using different LDAPs so SSO is not possible and even if it was retrieving photos from Connections via photo.do is not possible for guests because the photos require authentication so using the Connections business card for STProxy and Meetings is a show stopper.

Luckily in the Connections TDISOL there is an AL we can use called dump_photos_to_files. I won’t go into too much details about this but you can copy and paste the AL and then alter it. I altered it to return all user’s email addresses as well as UID and then dump the photos in the format of emailaddress.jpg which is the format needed by the Meeting server.

You may find the email addresses are capitalised. If so you will need to add some JavaScript to the lookup_user process to get it all in lower case


Once you have the photos in the correct format you need to get them from the server running TDI to a web server.

Web server

The logical way to serve the photos is using IHS in front of Connections. To get the files there I needed to scp them from the TDI server to IHS. I had to create ssh-keygens detailed in http://www.linuxproblem.org/art_9.html so I could scp the files wrapped in a shell script. Incidentally , the shell script called the AL and then scp’d the photos to the IHS server. Then add the shell script to cron so it is called on a schedule.

I wanted to lock down access to the photos so that people couldn’t browse to them. This is a little difficult to do but you can use IP ranges for all your internal offices and/or VPNs so that they are allowed to access the photos. The problem is guests who are truly external.

I created a new virtual host in httpd.conf with the following details.

# Sametime photos
<VirtualHost *:80>
ServerName icphotos.acme.com:80
DocumentRoot “/opt/IBM/HTTPServer/photos”
RewriteEngine On
RewriteCond %{HTTP_COOKIE} !LtpaToken2=.*$ [NC]
RewriteCond %{HTTP_COOKIE} !LtpaToken=.*$ [NC]
RewriteCond %{HTTP_COOKIE} !STPluginActivePage=stMeetingroom [NC]
# Old subnets and staff VPN
RewriteCond %{REMOTE_ADDR} !^xxx\.xx\.(x[x-x]|x[x-x])\.([x-x]|[x-x][x-x]|x([x-x][x-x])|x([x-x][x-x]|x[x-x]))$
# UK
RewriteCond %{REMOTE_ADDR} !^xxx\.xx\.(x[x-x]|x[x-x])\.([x-x]|[x-x][x-x]|x([x-x][x-x])|x([x-x][x-x]|x[x-x]))$
# India
RewriteCond %{REMOTE_ADDR} !^xxx\.xx\.(x[x-x]|x[x-x])\.([x-x]|[x-x][x-x]|x([x-x][x-x])|x([x-x][x-x]|x[x-x]))$
# Sametime Proxy
RewriteCond %{REMOTE_ADDR} !^xxx\.xx\.xx\.xxx$ [NC]
RewriteRule ^(.*)$ http://www.acme.com [R,L]

In a nutshell this allows all clients on certain IP range s to access photos. It also allows any web browser whether it is internal or on the internet to access photos IF it has either one of three cookies, LtpaToken/LtpaToken2 which is provided to the browser when someone authenticates or the cookie STPluginActivePage which the browser stores when you enter a meeting room. STPluginActivePage is in the browser whether you are a guest or an authenticated user, you just need to enter a meeting room.

I included both LtpaToken and LtpaToken2. I found the Sametime client was sending only LtpaToken with the HTTP GET for the photos. This may be due to the fact that I allow both LtpaToken and LtpaToken2 in the Domino web SSO configuration document. If you only allow LtpaToken2 then you may find that the client sends LtpaToken2 with the GET.

If you are a web browser outside of the IP ranges and you do not have any of the three cookies then you will be redirected to http://www.acme.com. You could change this to a static html page of your choice.

I’m no whiz when it comes to Apache but I have tested this quite a bit and it seems pretty secure and should cover most bases. Of course it doesn’t stop a meeting guest from guessing email addresses and browsing other people’s photos but since you have invited them to a meeting, provided them with the meeting room password there is an element of familiarity that should stop them from being malicious in this way. If you back this up with changing the meeting room passwords often you should be in a strong position to keep these photos relatively secure.

If anyone has any thoughts on the httpd.conf I am all ears as I would like to tie it down further if it needs it.


I found that my original RewriteCond  for the IP addresses were not working. I was originally using the following method because it seemed nice and easy to just enter the CIDR but reading further the following approach only works with Apache 2.4 and IHS is using 2.2.8. You can find out by running apachectl -V.

RewriteCond expr “-R ‘xxx.xx.xx.0/xx'”

So regex was the only way to go and trying to work it out was going to be a headache. To my rescue came http://jodies.de/ipcalc? to convert the CIDR to all the IP addresses (well the first and last) and then I put these values into http://www.analyticsmarket.com/freetools/ipregex to give me the regex.

SSL certificates and TLSv1.2 for Sametime (but also valid for WebSphere)

I thought I’d write this entry after assisting a peer and struggling myself to work out why TLSv1.2 was not working for a given node.

I will detail how to add a wildcard certificate to a Sametime 9.0.1 cell and then how to enforce TLSv1.2 for Sametime Proxy and Meeting server nodes.

Import the SSL certificate

There are various ways to go about this but I will detail using a .p12 file (pcks#12 format). The nice thing about getting a .p12 file is that all the certificates should be in there, all intermediary and the root protected by a password.

There are ways to create .p12 files using openSSL and Google is awash with posts so I won’t go into any more detail.

You will want to export the intermediary and root certificates. You can view the contents of the .p12 using openSSL. I am running Cygwin on a Windows laptop hence the .exe.

openssl.exe pkcs12 -in ./wild_acme_com.p12 -info

This will allow you to copy and paste the intermediary and root certificates which are needed. Again there are commands to export the certificates are available from Google or you could down load them from the Certificate Authority (CA).

Once you have your .p12 and intermediary and root certificates log into the ISC and go to SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal certificates.

Click Add and add the intermediary and root certificates.

Now go to SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal certificates > Import and click on key store file.

Point it to your .p12 and enter the password. It will then read the contents and give you a ridiculous name for an alias. I suggest you enter something meaningful. Then press apply.


At which point you will see the chain in SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal certificates which should look something like this


You can see the chain is complete. This is important otherwise web browsers will show various types of untrusted errors.

If you haven’t done this already you will need to apply the certificate to the nodes that need it.

Go to SSL certificate and key management > Manage endpoint security configurations.

From here you will need to expand the Inbound and Outbound sections for the STProxy and Meeting nodes. If you have a WebSphere proxy in front you will need to apply the certificate to that server. You can also add the certificate to the STProxy or Meeting application server too in case you have users connecting directly.

You need to tick Override inherited values and then press Update certificate alias list at which point in the Certificate alias in key store you should see the alias for the imported .p12. Remember to repeat for both Inbound and Outbound.


Now normally you would stop all application servers, WAS proxies, node agents and then the deployment manager and start them back up but because we are enabling TLSv1.2 we need to do a little more…..


If you try to enforce TLSv1.2 on a SIP Proxy Registrar then it will not work properly and you’ll get messages like the following when clients try to connect.

[10/12/16 10:37:24:483 BST] 0000008e TelephonyServ I   UserName in Message 
is null
[10/12/16 10:37:31:278 BST] 000000ba SSLHandshakeE E   SSLC0008E: Unable 
to initialize SSL connection.  Unauthorized access was denied or security 
settings have expired.  Exception is javax.net.ssl.SSLHandshakeException: 
Client requested protocol TLSv1 not enabled or not supported

This means that using SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore to control the protocol will not work because it will apply to all application servers in the cell including the SIP Proxy Registrar.

If you have awareness and meetings only then you can get away with it, although you need to take special care with recording of meetings because that will not work if you enforce TLSv1.2. In this case you may need to run the following to add the TLS configuration for recording.

"INSERT INTO mtg.configuration (server_id, CONFIGURATION_KEY,
CONFIGURATION_VALUE) values ('<substitue your server id here>',


Before I go on I will explain what limitation I found. If I enforce TLSv1.2 on the Meeting server I cannot connect to it using a Sametime  (thick) client. Web browser and mobile apps work fine. In the thick client it will not connect and I get errors in the client logs.

The default in QoP is SSL_TLS which enables all SSL V3.0 and TLS 1.0 protocols. This is not terribly useful considering I want to use TLSv1.2 but cannot enforce it across all the cell. You can use SSL_TLSv2 which enables all SSL V3.0 and TLS 1.0, 1.1 and 1.2 protocols so at least I have the option of using TLSv1.2 if the client uses that protocol.

So my steps involve some application servers using SSL_TLS, most using SSL_TLSv2 and the Sametime Proxy using TLSv1.2.

Remember I have WebSphere proxies fronting STProxy and Meeting servers to host HTTP -> HTTPS redirection and I will use them as the TLSv1.2 point.

Import p.12 to NodeDefaultKeyStore

So the steps are threefold, 1) add the .p12 certificate to the STProxy server node, 2) set the node to use the NodeDefaultKeyStore and 3) enforce TLSv1.2.

As I have run through the steps to import the certificate to the cell I do not need to run through that again. You need to go to SSL certificate and key management > Key stores and certificates > NodeDefaultKeyStore > Personal certificates/Signer certificates (choosing the node for STProxy) and repeat the steps above.

Now go back to SSL certificate and key management > Manage endpoint security configurations and go to the Inbound and Outbound sections. I made the change on the WebSphere proxy that fronts STProxy.

Change SSL configuration NodeDefaultSSLSettings click update certificate alias list at which point in the Certificate alias in key store you can select the alias you set. Repeat as required.


It will then look something like this. Only was_stpProxy is using the NodeDefaultSSLSettings, all others are using the default, CellDefaultSSLSettings.


The reason why you have done this is important in the next section.

Enforce TLSv1.2

I suggest you stop all the application servers, WebSphere proxies, node agents at this point.

Now you need to enforce TLSv1.2 at the node level. Go to SSL certificate and key management > SSL configurations > NodeDefaultSSLSettings (for STProxy) > Quality of protection (QoP) settings and change Protocol from SSL_TLS to TLSv1.2.


Go to SSL certificate and key management > SSL configurations and for all the other nodes including CellDefaultSSLSettings and XDADefaultSSLSettings set the Protocol to be SSL_TLSv2 including the SIP Proxy Registrar.

On all the nodes find the ssl.client.props file which is somewhere like /opt/IBM/WebSphere/AppServer/profiles/hostSTPPNProfile1/properties/ssl.client.props on Linux.

Ensure this is set as the following default value


This file instructs the client (the node agent) what protocol to communicate with the deployment manager using. As you have set this protocol in QoP for the cell, all nodes (apart from STProxy) and XDADefaultSSLSettings then all node agents can talk freely to the deployment manager.

If you miss a step here you’ll see from the deployment manager’s SystemOut.log that the node agent seems to stop and then start repeatedly. This is because the node agent cannot communicate properly, mainly because you have not changed XDADefaultSSLSettings appropriately.

Stop and start the deployment manager, run syncNode on all nodes and start the node agents, application servers and proxies and test. Check the SystemOut.log for any exceptions and if you see them check your configuration.


If you run a test against your STProxy or Meeting servers you’ll get marked down for the weak ciphers.


You can remove these from SSL certificate and key management > SSL configurations > NodeDefaultSSLSettings > Quality of protection (QoP) settings > Cipher suite settings. You will need to change from Strong to custom and then remove the ciphers listed above, if you so wish.

If you plan to do this for the Meeting server as well as STProxy then you will need to change the Inbound and Outbound options for the WebSphere proxy in front of Meetings so that it uses the NodedefaultSSLSettings which allows you to then use a default set of ciphers.


I have created a PMR to ask IBM about their support for TLSv1.2 in Sametime. I’ll update things once I get a response.


I am planning to move our internal servers to the latest Sametime servers which are using  a different LDAP. I have constructed managed-community-configs.xml to redirect the clients to the new Community server sitting behind a DNS alias of sametime.acme.com whilst resetting the client and automatically signing them in to the new servers using Notes client single sign on but I kept having a problem when the client tried to log in to the new Community server.

I found that the client wouldn’t log in to the new server using the Notes single sign on method. This process sends the Notes ID to the Community server (or another Domino server). Domino then checks the Notes ID and then sends back an LtpaToken to the Notes client. The Notes client sends the same LtpaToken to the Community server which Sametime uses to authenticate the user.

This really frustrated me. I couldn’t work out why this was happening. I enabled Wireshark trace and compared a successful connection to another server with the failing one. I found that the packets were similar up until a point and then there was a FIN, ACK. This normally means one of the host terminates the connection which seemed odd.

I spoke with a colleague who is a goldmine of Domino knowledge and after a bit of experimentation we found that when I try opening sametime.acme.com in the Notes client (Ctrl + O) it failed whilst it worked when opening a database for the actual Domino server ie sametime004.acme.com worked.

When putting  a trace on the client I got the following:

Using address 'x.x.x.x' for sametime.acme.com on TCPIP
Connected to the wrong server Sametime/Servers/ACME using address x.x.x.x
Using address 'sametime.acme.com' for sametime.acme.com on TCPIP
Unable to connect to sametime.acme.com on TCPIP (The server is not 
responding. The server may be down or you may be experiencing network 
problems. Contact your system administrator if this problem persists.)

The server document does not have sametime.acme.com listed but sametime004.acme.com since that is the name of the Domino server. I changed the name of the fqhn on the basics tab to sametime.acme.com and restarted the server. Now, I could access a database using sametime.acme.com.

Going back to the Wireshark trace it looks like the FIN, ACK was because the Notes client was stopped from connecting to the Domino server due to the different names.

My colleague then came up with NETWORK_SPRAYER_ADDRESS. This notes.ini value is described here.

When a notes client connects to a Domino server part of the protocol 
exchange includes the notes client telling the server what it thinks 
the server's name is.If the names do not match, the connection is 
terminated. This mechanism is part of the code which supports partitioned 
servers running on the same IP address. However, because of this 
algorithm, we cannot use network sprayers in front of Domino servers. 
When a Notes client uses a Network Sprayer address as a Domino server 
address, the network sprayer may make the final connection to any of 
the Domino servers behind it. If the name supplied by the client is not 
the Domino server name of the selected server, the connection will be 
broken. This fix provides a mechanism to skip the server name checking 
to allow this configuration to work.

I stopped Domino, added NETWORK_SPRAYER_ADDRESS=* and then started Domino. On testing I could open a database using sametime.acme.com and sametime004.acme.com.

When testing managed-community-configs.xml my Notes client was signed in fine to the new Community server!

The crux is that the problem was because I was using a DNS alias to connect to Domino which didn’t match the actual Domino server name. Sametime doesn’t care normally but the Notes client obviously does. Using NETWORK_SPRAYER_ADDRESS tells Domino not to care and to allow the client to connect.

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>”


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.



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.


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!