Recently I was asked to install Sametime Community server in a new site. I’ll be honest, I haven’t done a greenfield site install of Sametime in nearly a year, my work has primarily been upgrading (adding new elements) and maintenance.
As you probably know you can’t just install the Community Server onto Domino, much of the admin and management features are now controlled solely inside the Sametime System Console running on WebSphere. When installing WebSphere I installed version 8.5.5 as a base then applied the latest fixpack 12. (now version 13). The Sametime elements only work with Java SE6 which used to be fine, during the WebSphere install I’d explicitly override its wish to install Java SE8 with a radio button to choose Java SE6, however that option disappeared on fixpack 11 and as of April 2018 Java SE6 is no longer supported even though Sametime still requires it and will continue to do so I suspect well into next year since the next release of a Community server is scheduled for H1 2019 and other elements for H2 2019.
Everything installed fine but then the servers with the applications couldn’t be stopped properly. I had to uninstall WebSphere and the SSC entirely, then install base 8.5.5 with fixpack 8 (which I had to hand although other early fixpacks may also have worked) that allowed me to choose Java SE6 then install the SSC. Once it was installed and I tested starting and stopping server elements I went ahead and upgraded the fixpack to 12. WebSphere will warn you but continue to honour the Java version you originally chose , in this case Java SE 6, and not force an upgrade.
So. Websphere 8.5.5 with FP8 , then FP11.. 12.. 13 whatever you want. The system requirements still say these are all supported so the loss of the option to choose Java SE 6 during fixpack install is what we are trying to fix.
I recently built a new Sametime Complete environment for a customer that included an Advanced and Meeting server. When I had completed the build I tested a new standalone Sametime client in a VM to confirm that I could login to the new Community server and it would log me into the Advanced and Meeting servers. Having added the necessary lines to plugin_customization.ini to enable Sametime Advanced* I was able to login to the Community server successfully and be automatically logged into the Meeting and Advanced servers. However, when I handed over to the customer for testing I was surprised that they couldn’t actually login to the Meeting server at all through the Sametime client. They got a server unreachable error.
So I did further testing
- On my client I was configured to use SSL for both the Meeting server and Sametime Advanced. I could login to the Community server and that logged me in securely to Meetings and Advanced. That same configuration on a test workstation of theirs failed to login to the Meeting server saying server not responding (although it did successfully log in to Advanced)
- If I removed the Sametime Advanced servers from the Sametime workstation client it could suddenly log in to the Meeting server
- If I changed the Meeting server configuration in the workstation client to use HTTP (80) instead of HTTP (443) I would be logged in to the Meeting and Advanced server
- On the test workstation I could always login to the Meeting server securely through a browser and open a tab to the Advanced server and be automatically logged in there even when the Sametime client claimed it couldn’t reach the server.
So why did it fail on every one of their workstations and not for me? It turns out they were using the latest Sametime client I had downloaded from Fix Central (20170402-0344) for them whereas I was using the 2016 build (20160624-0209). I took a snapshot of my VM and upgraded my Sametime client to the April 2017 one and I immediately was unable to log in to the Meeting server. I rolled the snapshot back to the 2016 client and everything worked again.
One of the major updates in the 2017 client was SAML functionality and it does seem that the single sign on logic has been broken in some way by that 2017 update. Everything is working with the 2016 client so for the time being (and whilst IBM investigate the PMR) we are rolling that out. One to watch out for though – newer is not always better and you might want to avoid the latest 20170402-0344 update.
*for Sametime Advanced login to work at all in the client you must ensure “remember password” is checked and the following two lines are in the plugin_customization.ini
Today I was contacted urgently by a site I did an install for back in early September. The install went well and I left them several months ago with working components, but apparently about a week ago people stopped being able to login to the Community server. In fact not even the SSC could access it.
.. and yet no-one had changed anything at all. I do love a good mystery so I thought it would be useful to someone (or even just future Gab) to document what I did:
- verified if port 1533 was listening using netstat -an |find /i “1533”.
- verified there were no running AV services that could interfere with the ports.
- checked if the ST services were running, in fact only about 6 were.
- tried to start some of the services that weren’t running and they failed immediately.
- since no-one touched Sametime my next guess was a Windows update that caused a problem.
- checked the Windows networking settings hadn’t been overwritten (they had) . Although those settings shouldn’t cause the services to fail completely it was worth resetting them.
- I then added vp_trace_all=1 to the [Debug] settings in the sametime.ini which creates detailed log files in the \ibm\domino\trace directory.
- having added that I could see log files being created for every service, even the ones that wouldn’t stay started. In fact those ones recreated every couple of minutes. So the services were trying to start and failing.
- reviewing the log files I could see on things like STPlaces there was a JVM error, but I put that aside for the time being in case it was a dependency issue.
- in other logs such as STDirectory I could see broken networking errors and just before that I could see a comment about switching to TLS.
A-ha! Well, that’s new.
- checking the sametime.ini I found:
which I changed to:
My guess being an incomplete TLS configuration from the SSC. Having done that the server restarted perfectly and all services started. The SSC could then access the server with no problem.
Of course once I had spent 4hrs doing that I then found a technote on it which I never would have found before I saw the TLS entry. Here’s the technote .
Sometimes it’s a rollercoaster but so long as I get things working I’m calling that a good day. Now back to building more Connections servers.
The first thing I do when building any product is go check the latest system requirements in case they have changed. That’s a bit of a challenge with Sametime since the system requirements are (and have been for some time) nonsense. No reference to WebSphere 8.5.5 and definitely no reference to the fixpacks or even the individual servers.
Try it yourself. Go here http://www-01.ibm.com/support/docview.wss?uid=swg27007792 and click on any of the requirements for 9.0.1 Complete, Communicate or Conference to see what I mean.
Buried in the actual help documentation is the phrase “Restriction: Most of the Sametime 9.0.1 servers that run IBM WebSphere® Application Server require version 220.127.116.11” but that doesn’t help anyone wanting detailed system requirements or who doesn’t find that page.
If anyone from the ST or documentation team sees this – please fix it.
After serveral weeks travelling around the US doing work and visiting friends we ended up in Austin for MWLUG. Another great event organised by Richard Moy and the team with lots of great sessions including Scott Souder’s session on IBM Verse, more on Project Toscana and Ben Langhinrichs’ on Data Visualisation which is an area I’m working a lot in right now.
I had three presentations during the conference and ended up doing four to fill in for a session that was cancelled at the last minute. The Adminblast session I gave was one I hadn’t looked at in over a year until 20 minutes before I started so we all went on a magical journey discovering what I meant to say on each slide as it appeared.
Austin was a great town which I didn’t get to see enough of but luckily we arrived early on the Saturday before the rains started and walked around enjoying the bars and the music. Of all the amazing food on offer I will miss the Vegan Nom taco truck the most. Now to try and reproduce those flavours at home…
IBM Traveler, Management and Security
The SSL Problem and How To Deploy SHA2 (with Mark Myers from LDC Via)
Adminblast Emergency MWLUG Session (original co-authored with Paul Mooney)
Deploying Instant Messaging For Mobile Devices
My final New Way To Learn session today was looking at the Sametime mobile clients, Connections Chat and Sametime Meetings. I hope you find it useful and as always the full recorded session is available in the #NWTL Community.
The slides by themselves are below
In this session we looked at the architecture behind the Sametime mobile applications for chat and meetings. What do you need to deploy to support mobile users and what features are available to them on the different mobile platforms. We also looked at potential bottlenecks, security and troubleshooting for the mobile clients.
This week I will be presenting on upgrading Sametime to 9.0.1 as part of IBM’s New Way To Learn program (see here for details – requires login ). In preparation for that I wanted to take an existing environment I had and step through the upgrade of all components using the documentation. I discovered a few things I’ll share in my presentation and on this blog but one spectacular reoccuring critical full stop can’t move any further what was THAT – problem I thought best to share now.
After successfully upgrading the Community server (I know it was successful because the installer and the logs told me so 🙂 I discovered that the server couldn’t start the policy servlet. It was hard to see since all the other servlets started fine but if I watched the console as it tried to start I saw a servlet error when loading Policy and a message saying com.lotus.sametime.admin.policy.PolicyServlet could not be located. Luckily I’ve seen similar errors before in some 9.0 upgrades and on those it was the STCore.jar file which sits in the Domino program directory that was at fault. I took a backup of that STCore.jar and replaced the one in the program directory with one from a 9.0 server (bear with me, it was just to prove something) and sure enough, the server came up and launched Sametime this time finding the Policy servlet but missing the UserInfo servlet.
OK so I knew where I was. The STCore.jar that installed as part of the 9.0.1 upgrade was missing some policy files. I rename both the new 9.0.1 STCore.jar and the copy of my 9.0 STCore.jar to STCore.zip and then extracted them both so I could compare. I drilled down to the folder it claimed was mising com\lotus\sametime\admin\policy and in the screenshots below you can see my 9.0.1 version only has 4 files whereas my 9.0 version had 6 files including the missing one (PolicyServlet).
The STCore.jar as installed by the 9.0.1 upgrade
The STCore.jar from my 9.0 server
As you can see, the two missing files include the one the server was looking for. I extracted the two files and added them to my 9.0.1 folder then compressed everything again as STCore.zip and renamed to STCore.jar. I copied this new “fixed” (I hope) STCore.jar to the Domino directory and the server started with no problems. At least none I could immediately see.
I had come across this once before (an incorrect STCore.jar) on an earlier customer upgrade so it’s a recurring problem. I’m not sure what happens during the upgrade process – the file itself is dated 25th April 2016 so it’s not built during the install and isn’t broken for new installs. So two suggestions
1. Always backup STCore.jar before starting any upgrade along with sametime.ini vpuserinfo.nsf stconfig.nsf etc
2. If your server console is reporting a missing servlet during launch then verify that servlet exists in the STCore.jar