HCL Connections Docs – 2.0.1 Update Issue

Lately I had an issue upgrading from HCL Docs 2.0 CR3 iFix009 to 2.0.1. While upgrading “Docs Editor” application, using upgrade/install scripts, I was blessed with the following error code:

2021-03-05 17:23:16,464 INFO –>IM:RegisterDocsInNews
2021-03-05 17:23:16,465 INFO Register Docs application in Connections News Started
2021-03-05 17:23:40,280 INFO Register Docs application in Connections News completed
2021-03-05 17:23:47,996 INFO –>IM:ReviseLotusConnectionsConfig
2021-03-05 17:23:47,997 INFO Register Docs application in LCC.xml
2021-03-05 17:24:03,913 INFO Exception: ‘ascii’ codec can’t encode character u’\xa0′ in position 32627: ordinal not in range(128)
2021-03-05 17:24:03,913 ERROR Error while executing command, now rollback previous changes…
2021-03-05 17:24:03,913 INFO –>IM:Rollback RegisterDocsInNews
2021-03-05 17:24:03,914 INFO Rollback successfully.
2021-03-05 17:24:03,914 INFO Remove temp dir…
2021-03-05 17:24:03,915 INFO Exception: Upgrade failed. Check log file for more detail.
2021-03-05 17:24:03,915 INFO –>IM:FAILED

Although it took me a lot of time to solve this issue, it is quite simple.  I don’t know how, but I had some “Non-breaking space” characters in the LotusConnections-config.xml file for which, as it turns out, Python 2.7 does not show a lot of love.

To solve this problem I have done the following:

  1. Login to the WAS Deployment Manager and check out the LotusConnections-config.xml.
  2. Create a backup of the file.
  3. Delete all “Non-breaking space characters.
    • I managed to do this only in vim editor, by using the following setting “set list listchars=nbsp:!”.
    • Delete all newly shown “Non-breaking space” characters.
    • For more information, take a look at the Stack Exchange post.
  4. Check the file back in.
  5. Synchronize all WAS nodes in the cell.
  6. Restart the installation.

After that, the installation should complete. I hope this helps. 🙂

Note that the Error code shown above lists the exact position in the “LotusConnections-config.xml” file where the problematic character was found in the first place, but this can be misleading as you could have more than one “Non-breaking space” character in the file, so make sure to delete all of those characters.

HCL Connections 7 – PDF Export Issues

After upgrading to HCL Connections 7, the new PDF Export feature didn’t work. By clicking on the new “PDF” button inside the Wiki Page and trying to export it as a PDF, I would get an error in the GUI. In my two environments where I have encountered this, I had to do the following steps.

  1. Install “wkhtmltopdf” software and additional fonts.

This step is very well documented in the official documentation. Albeit a bit hidden.

2. Modify the IC360 configuration parameters.

In order to do this, login to the WAS Administration Console or ISC, and navigate to “Resources –>Resource Environment –> Resource environment entries –> ic360 –> Custom Properties”. Make sure that the following configuration parameters are correct:

“http.hostname” should correspond with the FQDN you are using to access HCL Connections, for example “social.domain.com”.

“http.auth.admin.user” set to WAS Administrator username.

“http.auth.admin.password” needs to have the value of WAS Administrator password. When changing the password, just delete the whole value, including “{xor}” in the field, after saving, the password will automatically be encrypted with XOR.

For additional information about IC360 configuration parameters, refer to the official documentation.

3. Sync and restart IC360 Applications.

After doing the steps mentioned above, you should be able to export the HCL Connections content to PDF files.

HCL Sametime Meetings 11.5 and LTPA version 2

As the LTPA Token version 2 is more secure than the LTPA Token version 1, it has become a new default for me. Lately I found out that the Sametime Meetings Server does not accept the LTPA Token v2 out of the box, more on that in the following. 🙂

After installing a brand-new HCL Sametime 11.5 environment, inclunding Sametime 11.5 IF1 Sametime Proxy server, importing the LTPA Key from Webphere Application Server and setting the Community Server to use the version 2 of the LTPA Token only, I found that the SSO between via LTPA was not working as expected.

HCL Sametime Proxy server was working as expected, it was accepting the LTPA Tokens and authenticating users by it. Users logged in to the HCL Sametime Proxy server could login into HCL Connnections and vice versa. But the Sametime Meetings component was not accepting the LTPA Token 2, users could login to the Sametime Meetings server, but the SSO functionality via LTPA was not working.

After a brief call with a good friend of mine, Herwig Schauer from HCL, I got the information that you need to set the LTPA Cookie name to “LtpaToken2”, which is the default name for LTPA v2 Token, on the Sametime Meetings server. For Sametime Meetings Docker deployment, this can be done in “docker-compose.yml” file. You have to add the “LTPA_COOKIE_NAME” parameter, in the “auth” section of the file, and set it to “LtpaToken2”.

“docker-compose.yml” file.

After that just apply the standard procedure for changing the Sametime Meetings configuration files, and you should be good to go.

@Herwig Schauer, thank you very much for the information! 🙂

Here it comes! HCL Domino & Notes v12 Beta 3

Today Luis Guirigay, Barry Rosen and Thomas Hampel showed us the HCL Domino & Notes Beta 3 of the Version 12. Guess what!? It is available on the HCL Flexnet site for download as of now! 🙂

Where to download the v12 Beta.

I will give my best to list the most important takeaways from the today’s webinar in the following.

This is the last of the planed Beta releases before the global launch of the HCL Domino and Notes Version 12.

Timeline and Components of the HCL Domino and Notes v12.

The latest beta release is available in the following languages:

HCL Domino v12 supported languages.

As of HCL Domino version 12, additional Linux server distributions are supported.

Additional Linux Platforms.

HCL Notes 64-Bit Basic Client for Windows is available for download, a release of HCL Notes 64-Bit Standard Windows Client is planned in the future.

HCL Notes 64 Bit Client Beta.

I was especially excited as I have seen the following slide:

The Active Directory Password sync looked perfect and polished in a Demo. It takes less than 5 seconds to sync a user’s password, since it was changed in Active Directory, to Domino.

The Backup Solution also looks great, the whole backup and restore process can be controlled inside one new Domino Database. In a Demo, the restore process certainly looked fast and easy, Thomas restored some deleted Mails and Folders with ease.

New Domino Backup and Restore Database.

The backup and restore process should now be possible with most backup software vendors.

Architecture of the HCL Domino v12 backup/restore solution.

There are also some news about licensing, the CCB/CCX Licenses can now be tracked easily inside Domino, no matter how complicated your environment is.

HCL Domino & Notes Entitlement Tracker Demo.

HCL Nomad Web will also be publicly available with HCL Domino and Notes v12.

If you would like to participate in the Beta program, you can do so, HCL is open about it and they will welcome any feedback. You will need to register for an Account and afterwards you will be able to access the beta forum.

And last but not least, make space in your calendar for the HCL Domino and Sametime Launch Event on June the 7th.

Happy Testing! 🙂

HCL Connections – Do Not Forget To Install A New APNs Certificate For 2021

By default, the APNs certificates are valid for one year. The current APNs certificate for HCL Connections is going to expire on the 21st of March. You can update the APNs certificate by installing an Interim Fix provided by the HCL Connections development team, which can be obtained from the HCL Software License & Delivery Portal. There is an Interim Fix for basically all relevant versions of HCL Connections, 7, 6.5 CR1 and 6.0 CR6 and 6.0 CR3. For all details, take a look at the official article.

As soon as the APNs certificate expires, the users of the HCL Connections mobile app on iOS will not be able to get push notifications, which means that they will not get alerts or notifications from HCL Connections while the mobile application is running in the background.

Installing Interim Fixes for HCL Connections is fairly straightforward, for a step-by-step guide, refer to the official documentation. This particular Interim Fix will take about one to five minutes to install, depending on the environment.

HCL Sametime -Access User Directory over LDAPs

Configuring HCL Sametime Community Server to access the user directory over LDAPs is straightforward and usually fairly simple. In order to configure the access to Microsoft Active Directory for example, over LDAPs, you have to do the following:

  1. Configure LDAPs for the Domino Directory Assistance document used by HCL Sametime.

I described the steps needed in the previous post how to do this.

2. Restart the Sametime Community Server and make sure you can still login into Sametime.

If this is not the case, then you have a problem with the configuration done in step 1. Only if you can log in successfully at this point, proceed to the next step.

3. Install GSKit provided with the Sametime Community Server setup.

Within the HCL Sametime Community Server setup, two executables for GSKit are provided, “gsk8crypt64.exe” and “gsk8ssl64.exe” (on Windows platforms), install both.

4. Add the directory of the installed GSKit to the “PATH” environment variable.

If your HCL Sametime Community Server is running on Windows, then the “Path” definition should look similar to the screenshot above.

If you are running Sametime Community on Linux and you are using the Domino Start-Script by Daniel Nashed to start the HCL Domino Server, you will need to modify the script to include the GSKit in the “Path” environment variable.

5. Create a trust store for verifying the target server authenticity.

You can either create the trust store in either “.p12” or “.jks” format. I usually go with “.p12”, for this you can use OpenSSL or even the “Certificates” Snap-In of the MMC console on a Windows client. Just make sure it contains the personal and the CA certificate of the LDAP target server. One of the both certificates, personal or CA certificate, should suffice, but I usually add both, just to be on the safe side. After you have created the Trust store, copy it to the Domino server.

6. Choose and define the TLS Scope.

As described in the official documentation, choose for which TLS Scope you want to configure. I just wanted to configure LDAPs and I have created a trust store for this solely purpose, so I only configured the individual TLS scope for LDAP. Therefore, I just added the following “Sametime.ini” settings:


7. Enable LDAPs in the Sametime Community Server configuration

Access the “stconfig.nsf” database on the Sametime Community Server using HCL Notes Administrator Client and open the LDAP Connection document. In the LDAP Settings set “SSLEnabled” parameter to “true”. If you are using other SSL Port than the default 636, you will also have to change “SSL Port” setting to reflect that.

Excerpt from the LDAP configuration in the “stconfig.nsf” Domino database.

If you want to use LDAPs for accessing the Sametime Business Card Information, then you will need to modify the “UserInfoConfig.xml” file and enable LDAPs. In order to do that, open “UserInfoConfig.xml” and locate “SslEnabled” parameter and set it to “true”. Also, make sure that the port number defined in the “SslPort” parameter is correct, per default that is 636.

That’s it, just restart the server and verify the configuration by logging into Sametime and accessing the Sametime Business Card Information.


If you have any issues logging in and you start getting the following error:

HCL Sametime Client – Login failed

Login failed – Reason: The log in information you entered cannot be verified at this time. Contact your help des or system administrator. Error details: Directory is unreachable.

Try setting the following debug parameters in the “sametime.ini”:


After that, restart the Sametime Community server, reproduce the issue and check the “STPolicy” as well as the general Sametime log as those files should provide more information about the authentication process failing.

I hope this helps! 🙂

HCL Domino – Directory Assistance – Access to Active Directory via LDAPs

In order to re-configure the existing HCL Domino Directory Assistance document for accessing the user data over encrypted LDAP connection or LDAPs you have to do the following:

  1. Create a Domino keyring file for the source Domino server.

Generally there are many good guides on the internet for doing this, personally, I like the following articles:

Generating a keyring file with a third party CA SHA-2 cert using OpenSSL and KYRTool on a Windows workstation
Generating a keyring file with a self-signed SHA-2 cert using OpenSSL and kyrtool

Personally, I advise you to always use an official certificate, any well known third party CA or Let’s Encrypt certificates, which by the way are free, will do. This will save you some pain in the long run.

2. Add the personal certificate and/or CA certificate to the Domino keyring file of the Active Directory server you want to access.

You can do this in the same manner as adding the Domino root or personal certificate in the guides mentioned above. If possible, I would always add the personal and the root certificate of the AD target server, just to be sure that the trust will be established successfully. Just make sure to set a reminder to change the certificates mentioned before they expire. 🙂

3. Add the newly created Domino keyring file to the Domino Server document

Copy the Domino keyring file, including the stash file (.sth) to the Domino Data folder and reference it in the Domino server document.

4. Import the root and personal certificate of the Active Directory server to the Domino Directory

Export the Active Directory root and personal certificates as “.cert”, Base-64 encoded, and import them to the Domino Directory.

5. Activate encryption in the Domino Directory Assistance document.

Set the “Channel encryption” to “SSL”, I advise you to set the other settings to be “less restrictive”, you can fine tune those after you made sure that basics are working.

Do not worry if clicking the “Verify” button returns an error. I think that there is a bug in the Domino 11 DA Template. I was always getting the following error “Connection to host ‘<hostname>:636’ failed”.

6. Restart the Domino Server and verify.

After the Domino Server restart you can verify that the Microsoft Active Directory user data can be accessed via HCL Domino Directory Assistance by issuing the command “show xdir“, the result should be something like the following:

This is everything you have to do to access the user data over encrypted LDAP connection using HCL Domino Directory Assistance. I hope this helps.

HCL Connections Invite – Issues when using TDS/SDS as User Repository

Take care when deploying the HCL Connections Invite application using the TDS (Tivoli Directory Server)/SDS (IBM Security Directory Server) as user repository. The following information from the official documentation is wrong:

The following value includes the LDAP property used to map the user in LDAP to their Profiles GUID. In an Active Directory environment, for example, the default property is objectGUID. Other known defaults are entryuuid (IBM Security Director Integrator, formerly TDI),…


First, the value of the Attribute in the “selfregistration-config.xml” is missing, this would be: “<key>com.ibm.snx_profiles.base.guid</key>”.

By reading the documentation, you would set the <value> parameter to ${ldap:entryuuid}, if you do that, you would get the following error:

00000660 SelfRegistrat W   Failed to get all the required attributes! required: ‘{​${​ldap:entryuuid}​=entryuuid, ${​ldap:sn}​=sn, ${​ldap:cn}​=cn}​’, received attributes: ‘{​sn=sn: Mail, cn=cn: <e-mail>}​’

The correct value for the parameter, when using TDS/SDS, would be “${ldap:ibm-entryuuid}”, so you should endup with the following:


Although there are some comments in the “selfregistration-config.xml” showing the right information, a few colleagues/friends including me found them to be a bit “misleading”. This will surely be corrected in the future.

OpenNTF February Webinar – Introduction to Ansible for Newbies

If you haven’t already, don’t forget to register for the OpenNTF Webinar about Ansible, scheduled for tomorrow. Christoph Stöttner is, among other things, a Connections/Kubernetes/WebSphere and DevOps Guru, so I am pretty sure he knows his stuff about Ansible. 🙂

More details about the event:

This talk is for Domino admins and developers who would like to learn Ansible basics. Ansible is an automation engine to automate deployments. HCL provides a set of Ansible playbooks and roles to deploy a complete HCL Connections 7 environment. Come learn what Ansible is and why you should use it in this webinar.

The speaker will be:
Christoph Stoettener, HCL Ambassador

This webinar will take place on Thursday, February 18, 2021 at 11:00 AM (New York time) to 12:30 PM. There will be time for questions at the end.

To register for this webinar go to: https://attendee.gotowebinar.com/register/864492529194071053

You can also access information about and recordings of all of our webinars at https://openntf.org/webinars

HCL SafeLinx – SSL Issues

If you are using HCL SafeLinx and you cannot access your websites using “HTTPS” and you see the following error in the HCL SafeLinx “wg.log” log file:

PKCS12_parse failed, return 587686001 (error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure

Then, most likely, either you are using the wrong password for the “P12” file, database where your SSL certificates reside, or your HCL SafeLinx Server is installed on Linux and the password for the “P12” file contains some special characters that need to be escaped. In my case, it was the later.

As a workaround I created a new “P12” file, with corresponding certificates, without using any special characters in a password. After that, I just restarted all HCL SafeLinx processes and everything was fine once again. I could access all configured sites via SafeLinx using HTTPS.

This issue occurred in HCL SafeLinx version 1.1.1 on Red Hat Linux.