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.

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.


Sync the node and restart the Meeting server.

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


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


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!

New Sametime white paper: Understanding IBM Lotus Sametime 8.5.1 enterprise architecture and design

I noticed that a white paper from Andy Yiu was released two weeks ago focusing on the architecture of Sametime 8.5x. There is some good information in there and I’d recommend that anyone working with the technology should read it. It’s good to see that information is continuing to be released.

developerWorks article

Meeting federation/clustering fails with multiple IPs

I was asked to visit a customer who was having problems federating a primary node (Meeting server) with the SSC. They had some other problems as well which meant that I thought it was best to uninstall, clean up and reinstall.

After the two Meeting servers were reinstalled I hit the same problem when trying to federate the primary node. I looked in the addnode.log and noticed an error with an exception, unfortunately I didn’t take a note of the error but the crux of it was that during the addnode process the IP address the DM was resolving for the PN was incorrect.

Looking at the Windows 2008 server I noticed that it had two NICs, a primary and a management LAN. I added host file entries for the SSC and the two Meeting servers to all three servers after which federation worked fine.

I do not know why WAS picked the management IP, there is probably an algorithm it uses to decide but it is wise to be mindful of this if installing on a server with multiple IPs.

DB2 HADR – clustered Meeting servers

I needed to create a cluster of Sametime Meeting servers to ensure high availability. With WebSphere (like Domino) this is relatively easy but what about the database? DB2 HADR (High Availability and Disaster Recovery) ensures that two databases are kept in sync with each other in case one of the databases fails.

HADR does this by creating a primary and standby database. The primary is always in use whilst the standby is kept in sync using internal processes to ship database log buffers to it. A process at the standby server then replays the log records directly to the standby database. If the primary fails the standby database can be promoted to primary to take over responsibilities.

  • This is not a seamless fail over, it requires manual interaction to promote the standby database.
  • To achieve seamless fail over other tools such as TSA or HACMP must be used.
  • The standby cannot be accessed, only the primary can be read or written to.
  • In DB2 v9.7 the standby can be used for reads but if you cannot write to it I am unsure of the effect this might have on Sametime.

Instead of installing the limited use (CZLF7ML) version of DB2 for Linux I opted to use the full version (C1X0UEN) which gave me greater control over user accounts and install directory. I decided to use the GUI to set up HADR, good thing about it is that at almost every step you can see the command that the GUI is compiling should you wish to script it next time round.

Screen shots detailing HADR set up.

The deployment plans for the Meeting servers both have to point to the same DB2 fqhn as defined in the “Connect to DB2 databases” in the SSC. If the primary DB2 server should fail WebSphere will not be able to read/write to it even if the standby has been promoted to the primary. To fix this Automatic Client Reroute can be used within WebSphere.

You need to make each DB2 server aware of the other so that when a client connects it knows how to reroute it should it fail. You need to run the following command on each server referencing the other in the command line.

./db2 update alternate server for database STMS using hostname db2.acme.com port 50000

Log in to the SSC and go to Resources – JDBC – Data sources. You will see a number of JDBC data sources, normally two for each Meeting node and two for the cluster.

Click on each (checking at the bottom of the page that it references STMS and not STSC) and then select “WebSphere Application Server data source properties” on the right hand side.

Under “DB2 automatic client reroute options” you have options of adding alternate servers and the ports they listen on. You configure your second database here. Make sure the changes synchronise with your nodes and that the applications servers are restarted afterwards.

If your primary database fails WebSphere will then connect to the alternate DB2 server as long as the alternate server has been made the primary.