If you are planning to deploy the HCL Connections Mail Plug-in, take note of the KB0092821 knowledge base article. This is a mandatory step that must be done in HCL Connections 8 CR1 and newer environments.
If the steps described in KB0092821 article are not followed, you will get the following error message in the browser console:
Error: Unable to load https://<mailserver_hostname> status: 403
We are working on adding this step to the official documentation of HCL Connections Mail Plug-in.
I tried numerous things to resolve this issue, but in the end, the only thing that helped was rebuilding the Swiftfile index, which can be done in your HCL Notes “Preferences” menu (open your mail database and navigate to “More –> Preferences –> Mail –> Swiftfile –> Rebuild index )” as displayed in the screenshots bellow:
After rebuilding the index, the issue hasn’t occured again and HCL Notes Swiftfile was working as expected.
Recently I encountered an issue with PDF Export, right after the installation of HCL Connections applications in a multi-node, clustered, IBM WebSphere Application Server environment. This problem only occurs in a multi-node WAS environment.
In the HCL Connections GUI, in the “PDF Export Access” settings of the”Edit Community” menu (Community –> Community Actions –> Edit Community –> PDF Export Access), the following error was displayed:
At the same time, the following error is logged in the WAS application server logs, where the IC360 application is running:
ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0014E: Uncaught service() exception root cause ic360: org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.NoClassDefFoundError: com/ibm/ess/ic/ic360/security/tai/Ic360ImpersonateUserTAI
The cause for the problem were the missing java virtual machine properties, which were only set on one of the IC360 WAS applications servers. In my case, as I was installing HCL Connections using “large deployment” topology, the java virtual machine properties were only set for “IC350Cluster_server2”. Those settings can be found under “Application servers –> IC360Cluster_server2 –> Process definition –> Java Virtual Machine –> Custom properties”, as shown in the screenshot below:
On the other hand, these crucial settings were missing on the other IBM WebSphere Application Cluster member, as can be seen in the screenshot below:
To resolve the problem, make sure that the same JVM “Custom properties” are set across all WAS application servers hosting the IC360 Application. In my case I had to set the same settings for “IC360Cluster_server1” application server as they were set by the installer for “IC360Cluster_server2”, as displayed in the screenshot below:
After that, make sure that all IBM WebSphere nodes are synchronized and restart the IC360 WebSphere Application Server cluster.
The steps to resolve this issue are also documented in the KB0085725 article.
I hope this helps!
My colleague Martin Leyrer and I will be hosting a webinar “HCL Domino TOTP/2FA – Implementation, Best Practices and Pitfalls”. The session will start on September the 15th, at 4 PM CEST. So, if you are interested in TOTP/2FA Implementation using HCL Domino natively, make sure to register and join our Webinar:
We will be delighted to have your presence!
Recently, we came across some issues with contact synchronization between mobile devices using HCL Traveler, mail databases of HCL Notes users, and address books of the HCL Notes Roaming users.
To be exact, these are two separate problems which are described in the following Knowledge Base articles:
You might have the issues mentioned in the KB articles above, but haven’t noticed them yet, as the HCL Notes and HCL Traveler users will only have problems with synchronizing certain contacts “across the board”, namely those which are created on HCL Traveler devices. The issue will become more apparent with the users having more than one mobile device activated on HCL Traveler, as the contacts created on one of the devices will not sync to the other and vice versa.
There is a workaround for both issues, as stated in the KB articles mentioned above, which is to add the “AccessContacts” role to the owner of the mail database as well as to the roaming address book database, assuming the same user is also a roaming user. You can either do this manually or via LotusScript code provided by Domino Development, which you can find in the following Knowledge Base article:
Many thanks to the HCL Traveler team for confirming the issue and developing the workaround so quickly, as well as to the HCL Domino Development team for writing the code to implement the workaround.
As of yesterday, a new version of HCL Notes 12.0.1 German mail template is available, which incorporates the fixes for the following SPRs:
SPRÂ #Â PDARCBQ86UÂ >>Â DOMI: MSTeams meeting is not getting updated with new URL when user opens the accepted reschedule invite
SPRÂ #Â PDARCC68MCÂ >>Â DOMI: Reschedule meeting notice displays the old url for MSTeams meeting when chair accepts the counter
You can find the new version of the HCL Notes 12.0.1 German mail template in the KB0097354 article.
Hope this helps! 🙂
After deploying HCL SafeLinx, one of the first things you should do, is to configure the communication between the HCL SafeLinx Administrator client and the HCL SafeLinx Access Manager, so that it takes place in an encrypted and secure manner.
For this, only a few simple steps are needed.
openssl req -newkey rsa:4096 -nodes -sha256 -keyout sf.key -x509 -days 3650 -subj “/C=DE/ST=Florida/O=NOW/CN=<insert_your_sf_fqdn_here>” -out sf.crt
This will create a new private key “sf.key” and a certificate “sf.crt”. The Subject name of the certificate, in this case, is not important, use it for your reference.
With the next command, we will create a new p12 keystore using the private key and the certificate we created earlier.
openssl pkcs12 -export -out sfNew.p12 -inkey sf.key -in sf.crt
Note: If you have copied the p12 keystore into the installation folder of the HCL SafeLinx server, then you can use the relative path to the file, as in the screenshot above.
As of now, you should be able to use HCL SafeLinx Administrator to connect to the HCL SafeLinx server over an encrypted connection.
It’s hard to describe how well the Engage conference is organized and how fabulous the event is. Engage is the place where many good people gather, who gave me the opportunity to learn from them, and over the years many of them became my friends. Therefore, it is something special for me to present at Engage, and for that, I am thankful and honored.
My colleague and dear friend Martin Leyrer and I talked about Domino and TOTP, below you can take a look at the slides we have used:
We have also recorded our session, sorry for the bad audio. You can take a look at the recording below:
For the second time, I will be speaking at the EngageUG conference. I’m honored and thrilled at the same time. Come join Martin Leyrer and me for the “Domino TOTP/2FA – Best Practices and Pitfalls” session, at which we will give our best to share all our knowledge and experience with TOTP on Domino!
If this year’s conference is going to be half as good as any other before it, we are going to have a great time! Learn what’s NEXT for HCL Digital Solutions and meet your friends and colleagues.
You haven’t registered? Don’t worry, there is still time, head over to the EngageUG website and book yourself a ticket! 🙂
As Kubernetes pods do not make use of the Kubernetes nodes/hosts “host” file (/etc/hosts), which can be a challenge or a blessing, do not despair if you find yourself in an environment in which some DNS entries are missing. There is an easy workaround to “get you going”.
Although I have to stress out, that this is not a long-term solution, and you should use DNS as opposed to the following solution.
If you are using “coreDNS” on Kubernetes, edit the “configmap” of the service, by issuing the following command:
kubectl edit cm -n kube-system coredns
After that, just add the section which is marked red in the following screenshot:
And edit it to suit your needs.
Note: “fallthrough” parameter is important as it will make sure that the requests which can’t be handled by hosts configuration in the “coreDNS” pods, will be sent to the configured DNS servers.
After you are happy with the configuration, just recreate the “coreDNS” pods, by running the following command:
kubectl -n kube-system delete pods -l k8s-app=kube-dns
Note: this will cause a brief interruption of the name resolution service as the pods are being recreated.
You can test the DNS inside the Kubernetes network by creating a pod for this purpose that has all the “networking” tools you need, I decided to run with “infoblox/dnstools”.
kubectl run -it –rm –restart=Never –image=infoblox/dnstools:latest dnstools
Thoughts about HCL Connections, Domino and Sametime 