Upon suggestion from my friend Erik Schwalb of HCL, I upgraded to FP1 a Sametime12 server where I made some branding customization.
Contrary to what I wrote in my previous post not ALL customizations are kept.
If you made some branding, you will lose it. The directory /sametime-config will be deleted and replaced by a new one, so all the custom branding files in /sametime-config/web/branding will be gone.
Also, not all the settings in custom.env will be kept. If you applied branding adding, e.g. REACT_APP_PRODUCT_NAME=RoB ST Server REACT_APP_PRODUCT_LOGO=/images/branding/logo.jpg those settings will not be kept.
To check which settings are kept, look in install.sh, you will see that the upgrade maintains the default ones, e.g SAMETIME_PROXY_HOST=st.company.com.
If you enabled Let’s Encrypt support in .env you will lose it as well, since the Let’s Encrypt TLS cert in /sametime-config/web/acme-certs/ will be gone.
Again, check install.sh to see which settings are maintained in .env
So, the suggestion I have is to copy the sametime installation directory (you read my previous post, right?) and then after the upgrade copy back the /sametime-config directory and check the files custom.env .env and docker-compose.yml
Thanks a lot to Eric Schwalb for pointing me in this direction, since I didn’t applied customizations at my customer site, I did not notice that some settings are not kept.
I have upgraded my customer server to Sametime 12 FP1.
The process is as easy as 1-2-3 🙂 Just unzip Sametime_Premium_12.0_FP1.zip into the existing sametime directory (make a copy before, just in case). Run ./install.sh, it will ask you if you want to upgrade; answer Y and that’s all. All the customization done in .env and custom.env will be maintained.
There’s a but; if you customized docker-compose.yml, the changes will not be kept, it will be overwritten by a new file.
Since integration with mail require a change in docker-compose.yml, you have either to copy that file from your previous installation (you copied it, right?), or edit it and add again SAMETIME_EXTERNAL_WARINTEGRATION=true
Now that Sametime 12 has shipped a customer has asked me to integrate it with Domino web based mail, Verse and iNotes. The problem is that all the public documentation available on this topic is relative to Sametime 11.x; which is normal since when Domino 12 shipped, Sametime 12 had not. I am sure HCL will update it soon but in the meantime this post could be useful if you want to do this.
With the invaluable help of the Sametime Wizard himself, Tony Payne of HCL, I have been able to perform the integration and will explain all the steps needed. Thanks a lot to my peer from France, Jérôme Deniau, who helped me a lot in debugging the issues I had while setting it up. Without them I would not have made it.
You need to use LTPA, which is disabled by default in Sametime, so first thing you need is the LTPA key. This is generated by IBM WebSphere, so how do you get a LTPA key ? The solution is pretty simple. Since you have Docker you can easily fire up a WAS Liberty server running this command docker run -d -p 9080:9080 -p 9443:9443 websphere-liberty:latest
Upon starting, the WAS Liberty server will create the LTPA key so you have to copy it on your machine and then on the Domino server machine. Use this command to copy the key from the container to your host machine. docker cp b2964e5fc322:/output/resources/security/ltpa.keys ./ltpa.keys where in this example b2964e5fc322 is the Liberty container ID.
You can get the ID opening a terminal and issuing the command: docker ps This will give you the container ID
Note: The default password of the key is “WebAS”, if you want to use a different one there are several articles on the web that explain you how to do that.
Let’s assume you copied the ltpa.keys file in /sametime, now you have to edit three files, which are located in the directory where you installed Sametime, to make it use LTPA.
In the file .env set the following: ENABLE_LTPA=true LTPA_KEYS_FILE_PATH=/sametime/ltpa.keys LTPA_KEYS=/ltpa-config/ltpa.keys LTPA_KEYS_PASSWORD=WebAS
The reason for these values is the following, as Tony explained to me: This line – in docker-compose.yaml
Says that “when the container asks for /ltpa-config/ltpa.keys – give it the file in the location $(LTPA_KEYS_FILE_PATH) – the code (container) is always looking for ‘ltpa-config/ltpa.keys’
LTPA_KEYS_FILE_PATH should always point to the local copy of the ltpa.keys file – which should be outside of the /sametime-config path
In the file custom.env set: STI__ST_BB_NAMES__ST_AUTH_TOKEN=Fork:Jwt,Ltpa
This is needed to tell the ST server to use Ltpa
In the file docker-compose.yml set SAMETIME_EXTERNAL_WARINTEGRATION=true
On the Domino mail server, the procedure is the usual one for setting up SSO. Create a Web SSO configuration document and import the WebSphere LTPA keys. Select as Token Format: LtpaToken and LtpaToken2. Then in the server document under “Internet Protocols” – “Domino Web Engine” select as Session authentication: Multiple Servers (SSO).
My colleague Fabio di Paola has created a new project on the OpenNTF website. This is the first contribution that my company does to OpenNTF.
The project is a template from which you create a database that check all the agents running on a Domino server and gives a report that list them by owner, by database and whether are scheduled or triggered.
A few months ago, OpenNTF started testing the waters of moving our Slack community over to Discord. The immediate impetus for this was the message-history limitation of our Slack account: on the free tier, we were losing old messages, but upgrading a community of our size to a paid tier would be cost-prohibitive.
Once we started looking into using Discord, we found that it offered much more for us than just avoiding history loss. Discord quickly proved itself a much-better match for our community, with better community controls, better voice/video chat with screen sharing, and just generally a more community-focused approach.
Since it’s gone so smoothly in a “soft launch”, we think it’s ready to invite everyone more openly. To join our Discord community, visit:
Almost all blog posts about the announcements made by HCL at the Engage conference have reported that the naming of the products will change. No more numbers but names, so the next releases of Domino will be named after rivers : Danube, then Thames then Rio Grande.
Geography is definitely the theme, so for those who did not attend the Sametime related sessions the news is that also Sametime next versions will have a geographical theme. Instead of rivers they will be named after mountain ranges, the first one will be Eifel ( a mountain range in Germany ), then Lorenzo ( Argentina ) then Petros ( Ukraine ).
Connections releases will have tree names, beginning with Cedar
I have the weird feeling that this decision of getting rid of numbers and switch to names is not completely unrelated to the fact that the next version of Domino and Sametime would have been 13 and we all know that in the USA that number is not exactly considered a lucky one 🙂 . But maybe I am overthinking….. or not ? 😉
I had an engagement recently where I had to install Connections 7 plus Component Pack and Huddo Boards.
The story of the Connections and Component Pack installation has been interesting, the customer decided to change the domain name from something like company.local to a proper domain like company.org after the installation was done; too long for this post but if you meet me at some event and want to know the details, ask me.
I have never installed Huddo Boards before, so that was an interesting challenge, and I managed to perform the installation successfully thanks to my friends and fellow HCL Ambassadors Urs Meli (Belsoft) and Wannes Rams (ISW). Their help has been really invaluable.
There are a couple of steps that gave me some problems so I will explain what I did to solve them following Urs suggestions, maybe it can be useful if you want to install Huddo Boards.
The version of Huddo Boards that ships with Connections is not the latest one, so I followed the instructions to install the most recent one from the Huddo docker repository on Dockerhub. Here are the instructions
If you want to do that, there is a setting that is not outlined in the documentation; you have to put this the boards-cp.yml : useDockerHub: true
Put it in the minio: section like this
Another issue was that the ImageTag setting was not working for me. It is used to get a specific version of Huddo Boards from their repo but when I set it I could not pull the images locally. The solution is not use that setting, because if it’s not specified, then the installation will pull the latest version of Huddo Boards. To do this comment the ImageTag setting in boards-cp.yml like this
I have the honor and the pleasure of helping the Sametime Wizard himself, Tony Payne of HCL, in the delivery of the “Sametime Deployment” workshop that will be on Monday, May 23 at 15.30 .
Walk the walk with us to setup your own ST deployment. We will show you a full installation from start to finish: Community server, Proxy server and Meeting server. We’ll cover Best practices and Troubleshooting, Network architecture, Solving network issues with STUN/TURN, Customizing Meetings and more.
If you want to join us, the link for the registration is here
Theo Heselmans has communicated today that Engage 2022 is still planned. He decided to move onward the date, originally was scheduled for the end of March now the new dates are May 23-25.
I do really hope that the COVID situation will get better, and it always has going towards the late spring / summer, so I am confident that we will have the chance to meet again in person at a great event. Engage is the new Lotusphere.
I submitted a session, if it gets accepted I will make a post about the details.