Everybody likes when software performs well and feels “snappy”, guided by that mantra I’ve found that with the help of one “sametime.ini” parameter for LDAP tuning, you can improve the “login” performance of the clients and the time it takes to load Sametime Business Cards considerably.
By setting the “ST_DB_LDAP_CONNECTIONS_NUMBER” parameter, to a value greater than one, you can increase the maximum number of the LDAP connections HCL Sametime components can use to access the LDAP repository. Per default, every HCL Sametime module, which needs LDAP access, will use one connection to access the repository (“StAuthentication.dll” is the exception, as it uses two connections). Details about that can be read from the official documentation.
In most Sametime environments I’ve deployed, I have set the parameter “ST_DB_LDAP_CONNECTIONS_NUMBER” to two or three, depending on the Sametime Community server and LDAP server hardware. This led, at least subjectively, to 40-60% faster login times and about the same faster response when loading the Sametime Business Cards.
Make sure to monitor the hardware utilization and the performance of both the HCL Sametime Community server(s) and of the LDAP server(s), as changing this parameter will have a direct impact on it. Also, consider that setting the value too high can have negative effects.
If you are planning to deploy HCL Sametime Community service in a cluster or HA architecture, setting a Community ID is a must.
Ideally, this should be an FQDN used for accessing the Community servers, something which is easy to remember, and your users can relate to. So, think ahead and use a name that can be used to access the service externally and internally, I would never use the hostname of the Sametime Community server, in most cases, this is hard to remember and can’t be used to access the service over the internet. A “nice” and simple DNS alias like “chat.company.com” is generally the best way to go.
This is especially important when setting up an HA environment, in this case, you also must make sure that the FQDN used, points to the Load Balancer. The consequences for not doing this, in a HA environment, can be catastrophic. In an event of the failover, the Sametime Embedded or Connect client may recognize the server failing over to, as a member of a different community. This would result, among other issues, in not displaying the user’s Sametime contact list.
The Community ID can be set via “sametime.ini” and the process is quite simple, as described in the official product documentation.
Recently I ran into the issue with HCL Sametime, the Chat was not working inside the Sametime Meetings. In this environment, the Sametime Meetings components are deployed on a single Docker host server.
After a little bit of Troubleshooting and Log Analysis, I found the following error in the Sametime Proxy catalina logs:
WARNING [https-jsse-nio-443-exec-8] com.ibm.rtc.stproxy.servlet.STProxyServlet.forward CLFRX0050E: User null – /stwebapi/chat/nway – <meeting_server_ip_address> is not authenticated.
Not coming any further, I opened a case at HCL, and the answer from the HCL Support came as fast as lightning. I deployed an internal STUN server, as it turns out, if you deploy your own STUN server and reference it for use in the “.env” file together with Google STUN servers, you should not set the “DOCKER_HOST_ADDRESS” variable inside of the “custom.env” file.
So the solution was easy, I just deleted the value of the “DOCKER_HOST_ADDRESS”, and enabled the configuration changes, as described in the official documentation.
Don’t forget to register for the today’s webinar “HCL Sametime: Make Your Meetings Deployment and Administration Easy”. It starts today at 4:00 PM CEST, and as the title says, the focus will be the Deployment and Administration of HCL Sametime:
Video meetings solutions can be cumbersome and time-consuming to deploy, configure and maintain. But it doesn’t have to be that way. Get up and running easily — and deploy however you want, whether on-premises, private cloud, or a hybrid solution — with deep savings in both time and admin resources.
I needed to set a new HCL Sametime policy just for a handful of users, so I have decided to do this via an explicit Sametime policy, assigned to the users via a new user group in LDAP user repository.
This process is simple and very well documented, check out the official documentation if you have to do this:
After creating, setting the policy and restarting the HCL Sametime Community server, I ran into a problem, the settings in the newly created policy didn’t have any impact on the Sametime clients.
In order to find the cause for the problem, I have set the following debug settings in the “sametime.ini” (in the [Debug] section) file:
POLICY_DEBUG_LEVEL=5
ST_POLICY_NOTES_GROUPS=1
“POLICY_DEBUG_LEVEL” can be set to ‘1’, ‘3’ or ‘5’, depending on the log information you want, ‘5’ being the most verbose.
After setting the debug level I found the following Entries in the Log:
[ 08:36:02.756 | 15.04.2021 | INFO | 15 ] : FilterSyntaxAdapter : replaceSubStrings : replaceSubStringsInFilter replacing %s with <dominounid> result is :(&(objectclass=inetOrgPerson)(|(mail= <dominounid> )(cn= <dominounid> )(uid= <dominounid> )))
[ 08:36:02.758 | 15.04.2021 | INFO | 15 ] : DirLdapBlackBox : getContextFromPool : A context has been retrieved from the conection pool for LDAP server
[ 08:36:02.758 | 15.04.2021 | SEVERE | 15 ] : DirLdapBlackBox : groupSearchByName : searchFilterGenerator is null, returning empty group list
Seeing this, the solution for the issue was pretty straightforward. The Sametime Internal User ID was set to “dominounid”, and it this parameter was missing from the LDAP Search filter used when resolving the user distinguished name to Sametime internal username. In order to solve this I had to modify the value of the LDAP search filter, used for resolving usernames to distinguished names, to include the “dominounid” parameter.
This can be done in the “stconfig.nsf” database, you just need to restart the HCL Community Server afterwards. Take a look at the screenshot after the configuration change:
The screenshot displayed above shows the LDAP Filter configuration change.
After that the HCL Sametime policy mechanism could be used as intended. Please do note that the issue was not a software defect, but rather the environment specific circumstances which ultimately resulted in a configuration error.
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! 🙂
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:
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.
Troubleshooting
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.
As a part of HCL Digital Week, Luis and Gini presented the HCL Sametime Premium. It is intuitive, easy to use and frankly everything what we want from a modern video conferencing solution and more. The emphasis is put on cost savings, according to HCL you can save, for ten thousand users, over a million us dollars annually! In the following I will write a brief summary of the session, along with a few thoughts of my own.
According to HCL, when deploying video conferencing software, the customers are met with the following problems:
These problems are tackled with the HCL Sametime Premium.
HCL Sametime Premium – Focus points
As mentioned, a lot of emphasis is set on cost savings. The amount of money that HCL Sametime Premium can help you save, just blew me away, amazing! Take a look at the following slide.
Cost savings with HCL Sametime Premium
I like it that we still decide where we can deploy the solution, not like at some other software vendors…
HCL Sametime Premium and Sametime v11.5 offers a lot of new functionality, the following slide does not represent the full set of features, just the most important functionality at a glance.
HCL Sametime Premium – Features at glance
Luis also showed us a very cool demo with Sametime Premium, mostly Meetings, in action. You can create new Sametime Meetings in HCL Notes, or in HCL Nomad Web client, no problem.
HCL Nomad Web client
All functions are intuitive and easy to access, like screen sharing.
Screen Sharing
YouTube video sharing, as well as streaming on YouTube is available out of the box! I personally really like this feature.
HCL Sametime Premium integration with YouTube
The transition to mobile devices is easy and seamless.
Meeting transition to a mobile device
By the way, you can install the mobile app via QR-Code, you just need to enter your username and password and you are ready to go. This is a welcome addition, I always wanted to spare the user of typing the server name and other needed settings.
HCL Sametime App installation via QR-Code
This is how a meeting can be created via web client.
HCL Sametime Meetings web client
Another cool thing is that the meeting recording is available just seconds after ending the recording of a meeting.
Downloading or sharing a meeting recording
Luis also showed us that you can deploy HCL Sametime Premium, with all features, in a day! Including setting up AWS, or doing some other preparation work on your platform of choice. To help us gain knowledge on how to do this, HCL will publish some new Whitepapers.
HCL Sametime whitepapers
HCL Sametime 11.5 including Meetings is available for download today, including a calculator tool to help you leverage just how much money you can save with HCL Sametime Premium.
Get Started!
All in all Sametime Premium and/or Meetings is a very welcome addition, there are so many customers waiting for Sametime Meetings. I hope that we are going to use HCL Sametime in many of our future projects. In the end always remember:
If you plan to manage your HCL Sametime clients via Expeditor managed settings framework and automatically updating their preferences via “managed-settings.xml” file, make sure that the file(s) are placed on a web server, in that way, so these files can be accessed without any form of authentication.
A SAML enabled server may look like a good idea, but at least in my tests, I could not get it to work with HCL Sametime Embedded client.
I came across an HCL Domino environment with HCL Sametime where the Sametime embedded clients were logging in via LTPA but with a different authentication server than the Sametime Community server.
As you can imagine, this was important to keep in mind during a Sametime migration. The Domino server used for authenticating Sametime clients is also hosting multiple websites and using multiple LTPA tokens, so the question was, which LTPA token is actually used for authenticating the Sametime clients.
After some searching I asked a good friend, Herwig W. Schauer, and he knew the answer. The LTPA token used for authenticatication of Sametime embedded clients is the default LTPA token, which is found inside the “($WebSSOConfigs)” hidden view of the Domino directory.
To access this view, hold “CTRL” and “Shift” keys while opening the “names.nsf” database. I hope this saves someone some time. 🙂
Thoughts about HCL Connections, Domino and Sametime 