With the customer where I installed Sametime 12 we had an issue with Meetings using an Android device. From a Android phone a user could not join a meeting or create a new one. With iOS devices, this problem did not happen. We tested on Sametime 12.0.FP1 and Sametime 12.0.1
We opened a Case and in the end HCL Support found the solution, you have to add to the file .env this line
STCONF_TOKENDOMAIN=yoursametimeserver.yourdomain.com
I have installed Sametime 12.0.1 integrated with Verse. The users now upload their pictures from the Verse UI but this breaks the display of images in Sametime.
The reason is simple: In the Sametime 12 documentation is clearly written that when using images from a web server the file type MUST be jpg or gif https://help.hcltechsw.com/sametime/1201/admin/admin_st_buscard.html
Business card photos must meet the following requirements:
Photos must be less than 45K in size. Photos 10K or less are recommended.
Photo file types .jpg and .gif are supported.
Photos to be used in business card for mobile or web clients they must be in the format of a URL, such as hosted from a web server or HCL Connections Profiles server.
So the users for which I manually define the Photo URL field everything works fine
But for users who upload the picture from Verse the Photo URL is something like this
This type of URL cannot be read correctly by Sametime as an image and the result is that user’s picture are not displayed in Sametime, both in the clients and in the meetings
The only workaround I can think of is to disable the possibility for the users to change the image from Verse and use a proper URL that points to a web server ( I use the same Domino server that does LDAP ). This will cause probably some dissatisfaction for the users and some work for the Admins who have to collect the pictures and put them in a single place, but is the only way to avoid this problem as far as I know.
I have installed ST 12.0.1 for a customer using Docker, and initially I wanted to use MongoDB 6.0; installation was fine but MongoDB would not start.
The error thrown was this: Job for mongod.service failed because a fatal signal was delivered to the control process. See “systemctl status mongod.service” and “journalctl -xe” for details.
A quick search on the web gave me the reason of this:
MongoDB requires the following minimum x86_64 microarchitectures:
x86_64 , MongoDB requires one of:x86_64 , MongoDB requires:My customer server had a Xeon Gold 5120 which is below the required specs for Mongodb, and that was causing the error.
The only thing I could do was uninstall MongoDB 6.0 and install MongoDB 4.4, which starts without any issue.
So if you plan to use MongoDB 6.0 pay attention to the CPU type you have .
P.S. I never had this before, I run my test servers on a AMD Ryzen 9 3900X 12-Core Processor machine, which is more than enough 🙂
AS probably you know OpenNTF has a Discord server, that everyone can join, where there are several “channels” (I know that the term is not correct) in which people can talk about specific topics.
We have just added one, “#suggestion-box” where everyone is encouraged to go if they have any idea on what OpenNTF should do; as my colleague Jesse Gallagher writes “we’d like to use it to take suggestions for improvements to our organization: our procedures, activities, infrastructure, and so forth”
I had two sessions at CollabSphere 2022
The first one “Useful Hacks for Domino Admins” together with my friend and partner-in-crime Marianna Tomasatti. The slides are here
You can find the video of our session on the CollabSphere website here
The second “Installing Sametime 12 and integrating with Verse and iNotes” was mostly a live demo. you can find the video on the CollabSphere website here
Two sessions I proposed for CollabSphere 2022 have been accepted. This is a great honor for me.
https://collabsphere.org/ug/cs2022.nsf/calendar.html
I will speak with my friend Marianna Tomasatti, October 19 at 4 pm (GMT +2). Our session is INF 107 “Useful Hacks for Domino Admins”.
Then I will speak October 20 at 9 pm (GMT +2). My session is INF 103 “Installing Sametime 12 Fp1 and integrating with Verse and iNotes”
I will also participate in the session COL107 “OpenNTF Roundtable: Have Your Say” October 20 at 6 pm (GMT +2)
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
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
– ${LTPA_KEYS_FILE_PATH}:/ltpa-config/ltpa.keys:Z
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.
You can find it here