I just finished the upgrade of our production Domino server to V14, and since I remembered the issues that can happen when you use the Local System Account to run the Domino service (which is the way to do up to V12) I read again the excellent post from Daniel Nashed and avoided any problems.
I encourage ( encourage just because I can’t force š ) every admin who wants to upgrade to Domino 14 to read Daniel’s post, before you call Support for a server crash.
Today I noticed that Sametime awareness was not working in Verse. Since it did until a few days ago I started to look what could be wrong. I tried to log in to Sametime and could not.
Alas, time to look at the logs on the server; doing so I noticed a strange error in the community container log. A timeout when connecting to my LDAP server. I checked my Domino server, which is my LDAP and everything was fine. So I started a remote session with my Linux box where I have installed Sametime and all of a sudden weird errors appeared when I tried to change directory from / to /sametime. A look at the filesystem left me horrified. I had the disk full!!!
How could it have happened ? I did nothing recently on that machine.
In quick chat with my friend and Lifetime HCL Ambassador Daniel Nashed he suggested me to install ncdu to see what was eating up my disk. I did so and found out that the /var/lib/docker directory was more than 70 GB! I checked what I had in Docker and found out that all the images from the ST12.0.1 installation were there. That makes sense, since I upgraded my server from 12.0.1 to 12.0.2 and the upgrade does not automatically delete the old images. I did not bother at the time to delete the images of 12.0.1 but now I did so and the disk is now 40 GB lighter
So my advice is, if you plan to upgrade an existing Sametime server from 12.x to 12.0.2 remember to delete the old images once everything is running fine.
I was asked by a friend, who is mostly a developer and not a Domino Admin about upgrading his dev server from V12 to V14. He told me that he uninstalled V12 and installed V14 but then the Domino server would start in setup mode.
The reason in simple, but if you were not part of the V14 beta program you may have missed it.
In Domino 14 the notes.ini file is not anymore in the program directory, but in the data directory.
In the beta program forum there were different opinions on this move, not everyone believes is a good idea, but anyway it is what it is.
So what happened to my friend ? The uninstaller left a copy of notes.ini in the Domino program directory and when he ran the V14 installer he noticed that that file was renamed notes.ini.old. There is now a new notes.ini in the Domino data directory, but is an “empty” notes.ini, i.e. it contains only the first 6 or 7 lines, so when the server starts, it goes in setup mode. [Notes] NotesProgram=C:\Program Files\HCL\Domino Directory=C:\Program Files\HCL\Domino\Data KitType=2 InstallType=2 PartitionNumber=1 showControllerStatusWindow=0 ServiceName=HCLDominoServer(CProgramFilesHCLDominoData)
How to solve this?
The solution is easy, edit the notes.ini.old file in the program directory and copy everything below the line FaultRecovery_Build=Release 12.0.2FP2 (or whatever is the version you are upgrading from). Then copy it in the notes.ini in the data dir just below the line FaultRecovery_Build=Release 14.0 If there are those lines: CFP_LP_PREV=Release 12.0.2|November 03, 2022 CFP_LP_BASE_VERSION=Release 12.0.2|November 03, 2022 CFP_LP_CURRENT=Release 12.0.2FP2|July 12, 2023 delete them.
Now restart your V14 server and it will not go in setup mode anymore.
Note that if you do NOT uninstall the V12 server, but just run the V14 installer on top of your existing installation, the installer will take care of everything and it will create the correct notes.ini in the data directory with all the values from the V12 one.
You should use the option of uninstalling only if you are upgrading a server that is pre-V9.0.1
I upgraded my server, yes the production one, (what else do you expect from me?) from ST 12.0.1FP1 to 12.0.2 and I ran into an issue.
In 12.0.1 the LTPA token could be placed anywhere you like then you had to change the file .env and set the path in LTPA_KEYS_FILE_PATH= Now in 12.0.2 the default path is /sametime/ltpa-config, which means that you have to copy the ltpa.keys file in that path.
The problem I found is that when you upgrade or install a new ST12.0.2 in that path there is a directory named ltpa.keys that gets created and this breaks everything, since ST expects to find a file named ltpa.keys and not a directory.
The obvious solution is to delete the subdirectory ltpa.keys from /sametime/ltpa-config and then copy the file ltpa.keys in there.
I reported this to HCL and they confirmed is a bug that will be fixed soon.
I worked with my friend and lady geek, Marianna Tomasatti, at a customer to perform an upgrade of the Notes client to V12.0.2 FP1 on Terminal Server Windows 2019 Datacenter (multi-user installation) because the Notes clients had some issues.
Since the previous version was V9, in the userās home directory W: there was a folder named IBM, and the path to the client data directory was W:\IBM\Notes\Data.
V12 creates a directory named W:\HCL\Notes\Data when installing for the first time so what we expected was that launching the Notes client, the setup wizard started.
To our surprise, the client started normally and not in setup mode! We double checked and found that the notes.ini in the old W:\IBM\Notes\Data was used and the directory W:\HCL\Notes\Data was not created.
We could simply not understand why this behaviorā¦ so I put forward the wild idea āmaybe the client tries to find a notes.ini in any directory and if it finds it, it uses that oneā. Being like-minded, Marianna did not laugh at me, because she is a very experienced Notes administrator and has seen many strange things in her career so even the wildest of the ideas could have some possibility to work.
With the help of the customer Terminal Server administrator, we checked what files the client was trying to open and we found out that it tries, in order
And if it finds the notes.ini file in there, uses it.
This makes sense, since the naming of the default directories of Notes/Domino have changed over time from Lotus to IBM and now to HCL, but we did not know that the client tried to find the notes.ini in those directories!
The solution was then to rename W:\IBM to W:\IBM_username because the client would not check a directory with that name.
In fact, after the rename, we launched the Notes client again and the setup wizard started.
Personally I do not know a single person in the Domino community that is happy with the actual Flexnet download site to get the kits of the various HCL products. There are many issues, and I won’t go into details here, but is enough to say that many people have complained. The good news is that HCL is listening and acting.
HCL made a quiet introduction of the new Software Download Portal allowing initially access only to the participants of the Domino V14 beta program. The feedback was good, so they now added all the Domino and related product versions, and the access is open to anyone that has the credentials for the Flexnet old site. The splash screen still shows the warning that the site is open only for the V14 beta, but is not true anymore
Once logged in you will see this screen
And if you select “HCL Domino” you will see that all the various products are there for you to download, obviously according to the entitlement you have.
For example if you select Domino, you have the options to download V11.0.1 or V12 and the relative Fixpacks and Interim Fixes
Download is very fast and on the various product pages there are links to the documentation and system requirements.
This is definitely a big improvement that will make our life much easier when we need to find and get a install kit.
Kudos to HCL for listening to the community and resolving a problem that made us unhappy.
From 24 to 27 April Engage was held in Amsterdam, the most important event for us who work in the field of collaboration with HCL products. As usual Theo Heselmans organized an outstanding event; the location, the Felix Meritis was an ancient building from 1776, originally the seat of a scientific-cultural Academy and kept the charm of the time intact. The only ones to complain were my legs, the rooms were arranged on 4 floors to be done strictly with stairs š Let’s get to the contents. HCL confirmed what was announced last year, namely that the focus for Domino is application development, but this does not mean abandoning the mail and calendar part. The future for development is Volt MX Go, if you don’t know it yet, it’s time to start looking at it, the Early Adopter program is active, the software is available and you can start using it to develop new applications. XPages remain alive, and this is part of the tradition started since the days of Lotus, to maintain backwards compatibility of products. If you have applications developed with XPages, they will continue to work for years to come. However, XPages will not be enriched with new features, so HCL recommends starting to use the new tools which will instead have many developments in the coming years. Another thing that has been seen is the considerable development that the Domino REST APIs have had, and continue to have. As mentioned, the mail and C&S part is not left out, in fact HCL has made an agreement with OnTime to give their product, which is absolutely the best for managing group calendars, included in the Domino license. The same that was done years ago with Panagenda’s MarvelClient. Even if you only use Domino for email and have no applications, you can rest assured that HCL is continuing to invest in that area as well. Sametime continues to be actively developed, and the new Program Manager, Trevor Tallackson, was introduced. I’ve known Trevor for years, up until now he was in Sametime L3 support, and he’s really good. Personally I find it great that the new PM is someone who comes from the team that develops and supports the product, I take it as a guarantee that HCL believes in Sametime and I can’t wait to see how it will evolve in the future. I can’t talk about DX or Connections, there were too many interesting sessions and I couldn’t follow any related to that. As for me personally, it was one of the best events ever, I had a lot of fun doing the āTips and tricks for Domino administratorsā session with my friend Marianna Tomasatti from GT Tech, we had a lot of participants in the session, honestly more than I imagined, and there were questions at the end. I hope this means that you enjoyed the session and found it useful. You can find the presentations made during the event on the Engage website, https://engage.ug
Me with the wonderful ladies I had the honor and the pleasure of presenting with.
My friend Marianna Tomasatti and me had the privilege and honor of giving a session at Engage 2023.
Our session was āTips and tricks for Domino Administratorsā, if youāre interested in the slides, Theo has published them on the official Engage website.
But on Docker it was not working, in various panels, for example those related to meetings it showed “no data”. Some of us reported this to HCL and they told that a fix would be provided for FP1.
In fact if you look at the fix list for FP1 here, you will see this: SAME-46471 – Update to support the Meetings Dashboard on Docker.
I found a small issue, though. For me the dashboard does not show correctly the meeting numbers. Even if you have one or more meetings active , it always shows 0
I had a chat with the Sametime Wizard, Tony Payne from HCL, and he suggested me to edit the file docker-compose-monitoring.yml and change from cadvisor: image: google/cadvisor:latest
to
cadvisor: image: gcr.io/cadvisor/cadvisor:latest
After I did that and restarted the server, the dashboard works perfectly š
If you are interested in Sametime, and I assume you are if you are reading this, I strongly suggest you to attend at Engage the session “Ad08 – Real life challenges and configurations when implementing HCL Sametime” on Tuesday, April 25 at 13:30 – 14:30 done by Erik Schwalb and Herwig Schauer of HCL. I had a meeting with Erik and he showed me a preview of what they will talk about, I can guarantee you that this session is very interesting and useful.
Just like I wrote some time ago about upgrading from 12.0 to 12.0.1, this upgrade is extremely simple and fast, but you have to take some small steps before doing it.
Make a backup copy of the directory where you installed Sametime, e.g. cp -r /sametime /sametime.bck
This is needed because not all the customization you did will be preserved, in my case I found out that the /sametime/sametime-config/web/branding and /sametime/sametime-config/web/acme-certs directories were not kept. I found out this, because not having the certificates my server did not start correctly.
So after the upgrade, just copy the missing directories from the backup directory to the install directory before starting the server. NOTE: In FP1 the ST containers no longer run as root, so the sametime-config directory and all its subdirectories are not owned by root:root but by 1000:1000; if you copy the directories from the backup to the working directory check and (if required) change the ownership of the files and directories you brought back from the backup directory.
As I wrote in a previous post about upgrading Sametime, if you have integrated mail you will have to edit docker-compose.yml and change again SAMETIME_EXTERNAL_WAR_INTEGRATION=true.
To upgrade, unzip Sametime_Premium_12.0.1_FP1.zip in the directory where you have installed sametime. Make sure to overwrite all the files, on a test server I made a mistake and did not upgrade install.sh, so in the end I ran the 12.0.1 install file, which is not a good idea š
Once unzipped, just run ./install.sh, it will ask you if you want to upgrade the existing Sametime, answer Y and that’s all. If you are not running the install as root, it will prompt you for the sudo password towards the end, when it updates the permissions in the ‘sametime-config’ directory.
