This is not strictly news, though at Engage HCL announced that the product documentation is now Open Source (and many other things, see this presentation)
anyone who used the official documentation for e.g. Sametime has noticed that is on GitHub.
This is great news from various points of view: it confirms the commitment HCL has for Open Source, see the above presentation (and as a Director of OpenNTF this is great for us), and for the first time gives us users the possibility of improving the documentation.
Now, I know that if you are an Admin you may think “not for me, GitHub and the like are developer stuff”, but this is not true. I am an Admin and I made some changes to the Sametime 12.0.2 official documentation! 🙂
Now, the two copies are different, mine contains the corrections and the HCL one doesn’t. What do you do to have the changes posted in the official repository? Just click on the link in the homepage of your fork, here
This will bring you back to the HCL GitHub repo and you can click here
You will see this
Now fill in the form and submit it.
HCL documentation team (the owner of the repository) will review the changes you propose and if they accept them, they will become part of the official documentation
If you open the HCL repository and click on “Pull requests” you can see that I submitted two and they have been accepted, which means that HCL is really listening to suggestions.
Verse 3.2.1 has shipped and one of the new things in this release is DOMI. If you lived under a rock in the last years and do not know what DOMI is, it’s a feature that allows you to dynamically create a link to meetings on the following services – GoToMeeting, Microsoft Teams, WebEx, Zoom, and Sametime when creating an invitation. Until now it was available only in Notes, but now is available on Verse too.
There is an issue, though, when using Sametime 12.0.2: when you create a meeting, the online meeting is not created and you see an error message. I opened a case with HCL Support and they acknowledged that this is a bug and found a solution in a very short time.
1)You have to open a case and they will send you a link where you can download a file “custom-meet.conf”. 2)Place the ‘custom-meet.conf’ into the sametime-config/web/nginx folder 3)Edit the custom.env and update the entries like below. CONTENT_SECURITY_POLICY=frame-ancestors https://*.company.com CORS_ALLOWED_ORIGINS=https://verse.company.com CORS_ALLOW_HEADERS=Content-Type,Authorization,x-csrf-token 4)Restart Sametime
This additional step is not required from the next release(12.0.2 FP1) onwards.
With Domino 12.0.2 and above, and Verse 3.1 and above there’s a new feature that allows the users to preview file attachments in emails using the Domino POI service.
A customer of mine found an edge case, when this feature doesn’t work. If the attachment is an Excel file with more than one tab, it will not be shown and Verse will throw an error.
If you are using Domino Leap you should know that in V14 something has changed. I found that stopping and restarting dleap in V14 is different from the previous Domino versions
I have tested this with Domino Leap 1.1.3.11 and 1.1.2.18
To launch Leap you go in the server console and issue the command tell http osgi ss dleap if everything is OK the result is this
Note the first new thing, in V14 all the commands related to osgi show at the end this line osgi> gosh: stopping shell
to stop Leap you issue the command tellhttp osgi stop dleap
The command does not return anything but leap is stopped To check issue again the command tell http osgi ss dleap, the result is this
Now, here is the difference between V14 and the previous versions. Until V12 to restart leap you issue the command tell http osgi start dleap. This does not work in V14 if you try, you will get this
To start leap again you should note the number of the process, in my case 129, and issue the command tell http osgi start 129 It does not return anything
but is you now issue again tell http osgi ss dleap you will see that it is active
I am not sure if this is working as designed or is a bug or if is due to the different Java version that is in V14. But now I know how to make it work
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.
