This section provides information on troubleshooting and supporting Sametime environments. Use this section to assist you with problems that you might experience and contacting support if needed.
-Getting help
diff --git a/docs/v1202/search/search_index.json b/docs/v1202/search/search_index.json
index 72d85df6..133eb0e1 100644
--- a/docs/v1202/search/search_index.json
+++ b/docs/v1202/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"admin/admin_st_buscard.html","title":"Setting up business cards","text":"
You can configure the Sametime server so that business card information about an individual displays when a user hovers over a name in a chat window or a contact list. Business card information also displays at the top of an active chat window.
Business cards are configured to access user information from the LDAP directory. To access the user information from the LDAP directory, Sametime provides a search engine called a black box.
By default, you can choose the following fields to display in the business card.
To troubleshoot problems with business cards, see Resolving problems with business cards.
Business card photos must meet the following requirements:
A single LDAP server must be used as the primary repository to retrieve user information. A secondary repository is optional and must be configured as a secondary LDAP server for business cards.
"},{"location":"admin/admin_st_buscard.html#tasktroubleshooting_ay3_nrv_4tb","title":"Planning for photos","text":"If photos are used in a business card , they can be stored in the LDAP directory or in the format of a URL hosted from a web server. For mobile and web clients using the Sametime Proxy server, they must be stored in the format of a URL. Importing photos into a directory using an image/jpeg type is only supported on the Connect and Embedded clients.
Importing photos into a directory increases the size of the directory. The increase in size can affect the performance of other applications that use the directory.
Depending on the Sametime client type, the attribute to defined the photo location is different.
PhotoURL supports the Web and Mobile clients.ImagePath supports the Connect and Notes Embedded clients.PhotoURL and ImagePath can be mapped to the same LDAP field. To support all Sametime client types using a URL:
PhotoURL and ImagePath.For example:
<Detail Type=\"text/plain\" FieldName=\"PhotoURL\" Id=\"ImagePath\"/>\n <Detail Type=\"text/plain\" FieldName=\"PhotoURL\" Id=\"PhotoURL\"/>\n\n<Set params=\"MailAddress,Name,Title,Location,Telephone,PhotoURL,ImagePath,Company\" SetId=\"0\"/>\n<Set params=\"MailAddress,Name,Title,Location,Telephone,PhotoURL,ImagePath,Company\" SetId=\"1\"/>\nAfter you have identified where the user information is stored, proceed to the applicable topic to configure business cards.
UserInfoConfig.xml file in the community pod.Parent Topic: Configuring
"},{"location":"admin/admin_st_mng_remotecomm.html","title":"Updating connectivity settings with the managed-community-configs.xml file","text":"You can distribute updates to HCL\u00ae Sametime\u00ae client communities automatically using a managed-community-configs.xml file. The managed-community-configs.xml file is policy-based, so you can control communities for different user groups.
You can also use the managed-community-configs.xml file to manage secondary communities, while preventing users from adding or deleting communities. Set the Allow Multiple Communities policy to false and use the managed-community-configs.xml to define the desired secondary communities. The client allows the user to log into secondary communities defined in the .xml file, but the user cannot delete secondary communities defined in the file.
At login time, the client receives policies and checks for the existence of a managed-community-configs.xml file according to the Sametime update site URL policy. For example, if the administration update site URL is http://example.com/updates, the client looks for the file in http://example.com/updates/managed-community-configs.xml.
Follow these steps to create and post a managed-community-configs.xml file.
Create a settings XML file and save it as managed-community-configs.xml.
Add settings for communities and actions in the file.
Place the file on a web server, and post the URL (starting with http://) for the file to the Sametime update site URL in the Chat section of the Instant Messaging policy.
If you changed the settings file to update the host name of a community to a new server that is part of the same community, users' contact lists are still valid with the new host. Set the ST_COMMUNITY_ID in the sametime.ini file of both servers to the same value and ensure that all the communities in your cluster are using the same community ID. This prevents duplicate communities from being created on the client when logging into the new host for the first time.
You can now test the\u00a0managed-community-configs.xml\u00a0file:
(Optional) Enable logging of the managed community settings to help debug problems. To enable logging for the handling of the remote\u00a0managed-community-configs.xml\u00a0file, set the following log level in your client's\u00a0user.home/HCL/Sametime/.config/rcpinstall.properties\u00a0file:\u00a0
com.ibm.collaboration.realtime.community.internal.config.level=FINEST\ncom.ibm.collaboration.realtime.policy.sametime.level=FINEST\nwhere user.home/HCL/Sametime represents the client's workspace location.
Managed community settings Define managed community settings in the managed-community-configs.xml file.
Parent Topic: Sametime client configuration options
"},{"location":"admin/administering.html","title":"Administering","text":"This section provides information on administering on Sametime environments.
Starting and stopping MongoDB
Configuration files Configuration files maintain information used by the Sametime server for various reasons.
This section provides information relating to administering MongoDB.
Changing MongoDB credentials in Sametime for Docker and Podman
Changing MongoDB credentials in Sametime for Kubernetes and Openshift A connection URL is used to configure the Sametime and MongoDB connection. The connection URL tells Sametime how to connect to your MongoDB.
Parent Topic: Administering
"},{"location":"admin/adminui_grafana_config_docker.html","title":"Configuring Grafana on Docker and Podman","text":"When using the managed charts to install Sametime, the Grafana dashboard is created. If using a manual install or update process, Grafana can be configured as a post-installation task.
After Grafana is configured, port 3001 is the default port used for Grafana.
Edit the .env file and add the following statement.
COMPOSE_PROFILES=monitoring\nNote: If you are have enabled the Outlook addin, the COMPOSE_PROFILES statement looks like the following:
COMPOSE_PROFILES=monitoring, outlookAddin\nEdit the custom.env file and add ensure that the following settings are set to true.
ENABLE_GRAFANA_PROXY=true\nMONITORING_ENABLED=true\nEdit the monitoring.env file and add the Grafana administrator ID and password.
GF_SECURITY_ADMIN_USER\nGF_SECURITY_ADMIN_PASSWORD\nStart the Sametime server to apply the changes.
docker compose up -d
Grafana can be configured as a post-installation task or during an upgrade.
To use Granfana, the Prometheus application must be installed.
To verify that the service was created correctly, run the following command to display a list of all services:
kubectl get svc -n monitoring\nEnsure that Grafana is listed as a service. Below is an example.
By default, Grafana is not available through an ingress controller.
Before you can create your first dashboard, you need to add your data source. Note that you must have Grafana administrator access to add data sources. Complete the following steps to run Grafana and import your dashboard.
Enable port forwarding for the Grafana service.
kubectl port-forward service/grafana 3000:3000 -n monitoring\nWhen using a remote setup, navigate to the Grafana sign-in page in your browser.
<Cluster-IP>:3000\nThe default port for Grafana is 3000. If you are on a local machine use localhost:3000.
Enter admin for both the user name and prom-operator, and then select Sign In.
You are prompted to change the password.
Select OK and enter the new password.
From the left panel, hover over + Create and select Import.
Upload the K8_Sametime_Dashboard.json file.
The K8_Sametime_Dashboard.json file is included in the Sametime Premium install product image. After decompressing the product image, the file is in the root directory.
Select Prometheus (default) as the data source and then select Import.
Save the dashboard.
Parent topic: Monitoring your meeting and chat metrics with Grafana
"},{"location":"admin/adminui_grafana_overview.html","title":"Monitoring your meeting and chat metrics with Grafana","text":"Sametime uses the third-party software, Grafana, to generate insightful graphs and visualizations derived from time-series database (TSDB) data. Integrating Grafana into your Sametime environment allows you to see analytic metrics about Sametime meetings and chats on a Grafana dashboard. The metrics can be used to monitor Sametime usage and resources.
Using Grafana involves that you have a running Grafana installation and then setting up the dashboard to view Sametime metrics. The Sametime Premium product image contains two JSON files that define Sametime metrics to display on the Grafana dashboard. One file is for a Docker environment and the other for Kubernetes. After you decompress the product image, the JSON files are located in the root folder. The files are:
The Sametime Grafana dashboard consists of four rows, you can expand and contract each row.
Overview : Provides total number currently active chat sessions and logins, group chat sessions, active meetings, and meeting participants.
Chat Server : Provides details related to chats usage such as the number of chat server logins, CPU usage, sent and received network traffic and more.
Chat Proxy : Provides details about web and mobile client sessions, such as number of sessions, app usage, threads, and CPU usage, and more.
Meetings : Provides malformation about meetings, such as number of active and inactive meetings, largest meetings, memory usage and more.
If you have Grafana administrator access, you can customize the dashboard to generate additional or different metrics. Refer to the Grafana documentation on Dashboards for the details.
Configuring Grafana on Docker and Podman
Configuring Kubernetes to run Grafana
Parent Topic: Administering
"},{"location":"admin/adminui_overview.html","title":"Sametime Admin overview","text":"The Sametime Admin is a web access interface used to work with policies and analytic data related to Sametime Meetings and chat features.
Only those users with access privileges can access the Sametime Admin after logging into Sametime. The access URL is: sametime\\_server\\_url/admin/.
The Admin UI contains a left pane, with icons that allow for accessing features. Click the icons to go from one feature to another.
Granfana dashboard displays provided that your environment includes a Grafana integration. A Grafana integration allows you to view various analytic metrics about your Sametime deployment. The Grafana dashboard provides charts, graphs, and alerts about Sametime Meetings and Chat features. You can use a predefined Sametime dashboard or create one. For more information, see Dashboards in the Grafana documentation.
If your environment does not include a Grafana integration this page is empty. For additional information on using Grafana, see adminui_grafana_overview.md.
Manage Sametime polices used to control user access to Sametime features. You can create, assign, and view policy assignments, and more.
See [adminui\\_policy\\_manage.md](adminui_policy_manage.md) for additional information.\nThe administrator is defined during the installation process. You can change or modify the administrator by updating the following files.
custom.env file for Docker or Podmanvalues.yaml file for Kubernete or OpenshiftYou can add a policy by creating a new policy, or by copying and modifying an existing policy.
The new policy is added to the table and assigned a weight higher than the current highest weight value. It is also in unassigned state.
Parent Topic: Managing policies
"},{"location":"admin/adminui_policy_add_copy.html","title":"Copying a policy","text":"You can create new policies by copying and editing a current policy.
The new policy is not in effect until the server is refreshed. After creating the new policy you can restart the sever or wait for the next refresh which happens every hour based on when the server was started.
Click the Copy icon() next to the policy to copy.
Type a name for the new policy and click Save Copy.
The new policy is added to the table and assigned a weight higher than the current highest weight value.
Edit the new policy by clicking the Edit icon.
When finished with changes, click Save Policy.
Parent Topic: Adding a policy
"},{"location":"admin/adminui_policy_assign.html","title":"Assigning users and groups to policies","text":"Policies are not used until assigned to users or groups.
Click the Assign icon () for the policy being assigned, type or search for the user or group name to assign the policy.
Select the name from the search results. The name is added to the Assign to list below the search field.
You can continue to search for names to assign the policy to. To remove a name, click the Delete icon next to the name.
When finished, clicked Save.
Note: For the policy to take immediate effect, restart the server. Otherwise, policy refresh happens every hour based on when the sever was started.
Parent Topic: Managing policies
"},{"location":"admin/adminui_policy_create_new.html","title":"Creating a policy","text":"You can create a custom policy that takes precedents over the Default and Anonymous policies. There can be many custom policies based on the requirements for your environment.
Newly created policies are assigned a weight higher than the current hightest weight value. The new policy is not in effect until the server is refreshed. After creating the new policy you can restart the sever or wait for the next refresh which happens every hour based on when the server was started.
Click the Add a policy for the policy to copy.
Enter a name for the policy in the Policy Name field.
Policy names must be unique.
Select the features to associate with the policy. When finished, click Add.
The new policy is added to the table.
Parent Topic: Adding a policy
"},{"location":"admin/adminui_policy_delete.html","title":"Deleting a policy","text":"You can delete policies no longer needed.
Click the Delete icon () next to the policy to delete.
Confirm the deletion by clicking Delete.
Sametime policies allow administrators to control user access to features.
Two predefined policies are automatically assigned to users. You can also create custom polices that fit your company's requirements and user access to Sametime feature. Which policy that is automatically assigned depends on whether the user is authenticated or not. You can also create custom polices that fit your company's requirements.
Policies are only applied from the primary Sametime community defined in the client. Additional server communities' policies are not pushed down to the users' desktops. A user's primary Sametime community is the first community listed in their Sametime client Server Communities Properties settings.
To manage Sametime policies, you need access to the Sametime Admin. After accessing Sametime Admin, click the Manage Policy icon on the left side of the window.
From the Manage Policies window, you can create, assign, and view policy assignments, and more using the icons under Actions. To the right of each policy is the policy weight followed by actions. To know more about a policy, click the policy name.
To know more about a policy, click the policy name. The View/Edit Policy window opens where you can view and change features related to the policy.
Parent topic: Administering
"},{"location":"admin/adminui_policy_modify.html","title":"Modifying a policy","text":"Policy attribute can be modified for all policy types.
Changes to a policy are not in effect until the server is refreshed. After creating the new policy you can restart the sever or wait for the next refresh which happens every hour based on when the server was started.
Click the Edit icon for the policy to modify.
The View/Edit Policy opens where you can modify features associated with the policy. When finished, click Save Policy.
You can change all attributes including the policy name.
Parent Topic: Managing policies
"},{"location":"admin/adminui_policy_sections.html","title":"Policy sections","text":"Each policy contains several sections.
Policy attributes are group into the following sections:
Chat
Meeting
File transfer
Mobile
Administration
Parent topic: Managing policies
"},{"location":"admin/adminui_policy_types.html","title":"Policy types","text":"There are three types of policies. The Anonymous and Default policies are predefined and cannot be deleted. There is only one of these policy types. All other policies are considered custom policies. There can be many of this type of policy.
The anonymous user policy and the default user policy are automatically assigned.
Policy type Description Anonymous Users who have not authenticated are assigned the anonymous policy by default. The anonymous policy cannot be deleted but can be edited if you want to allow or restrict access to certain Sametime features for unauthenticated users. The anonymous policy always has the lowest policy weight (0) and this weight cannot be changed. Default Users who have authenticated are assigned the default policy if no other policy can be found for that user. The default policy can be inherited or assigned. The default policy cannot be deleted but can be edited if you want to allow or restrict access to certain Sametime features. The default policy has the next lowest policy weight (1) after the anonymous policy and this weight cannot be changed. custom policies Custom policies can be designed for specific users or groups to allow or restrict access to certain Sametime features. When you create a new policy, the default policy settings are applied as the base settings of the new policy. You can update these settings.Parent topic: Managing policies
"},{"location":"admin/adminui_policy_view_active.html","title":"Finding active policies associated with user or group","text":"You can view policies assigned to a user or group.
Type the name of a user or group in the Find Active Policy search field and click \u200bthe Search icon. You must enter the complete name to search. The search results in a list of assigned policies.
"},{"location":"admin/adminui_policy_weight.html","title":"Policy weight","text":"Policy weights and group nesting levels are used to determine which policies take precedence over the attributes of other policies.
Policies with a higher weight take precedence over those with a lower weight. You can change the weight of policies to control their order of precedence by moving them up and down within the policy list. The policy weights of the anonymous and default policies, which are the lowest (0) and next-lowest (1) weights, cannot be changed.
For a user or group that is assigned two or more policies, the policy with the highest weight is used. For authenticated users, Sametime searches for an exact ID match, and then applies the highest weighted policy.
Policies are only applied from the primary Sametime community. Additional server communities' policies are not pushed down to the users' desktops. A user's primary Sametime community is the first community listed in their Sametime Server Communities Properties settings.
"},{"location":"admin/adminui_policy_weight.html#policies-applied-to-nested-groups","title":"Policies applied to nested groups","text":"You can configure how Sametime considers nested groups when it applies policies and how many levels deep that are searched for the highest weighted group. By default, four levels of nested groups are searched when it determines the highest weighted policy. The maximum search depth limit is 10 levels and the minimum is -1 level (no nesting).
Note: Entering a large number as the maximum nested group depth can have an impact on performance.
"},{"location":"admin/adminui_policy_weight.html#examples","title":"Examples","text":"In the following examples, the Renovations company has assigned employees to the following user groups. Notice that many of the groups have other groups nested within them.
Group name Members Renovations Group George Corporate Communications Group Corporate Communications Group Fernando Marketing & Merchandising Group Marketing & Merchandising Group Betty Marketing Group Marketing Group Samantha Sales Group Sales Group Anne Brand Specialist Group Brand Specialist Group TedThe Renovations company has created policies to control which user groups have access to different features in Sametime. The actual set of features available to each user depends on how these policies are weighted and nested.
"},{"location":"admin/adminui_policy_weight.html#nested-groups-inherit-policies","title":"Nested groups inherit policies","text":"Policy A is assigned to Renovations Group. The nesting level is set to the default 4.
George is assigned to Policy A because he belongs directly to the Renovations Group.
Fernando is assigned to Policy A because his group falls within the group search nesting limit of 4 levels from the Renovations Group.
Betty is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Renovations Group.
Samantha is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Renovations Group.
Anne is assigned to the default policy because her user group is nested more than the defined limit of 4 levels from the Renovations Group.
Ted is assigned to the default policy because his user group is also nested more than the defined limit of 4 levels from the Renovations Group.
"},{"location":"admin/adminui_policy_weight.html#highest-policy-weight-breaks-ties","title":"Highest policy weight breaks ties","text":"Policy A has a weight of 3 and is assigned to Renovations Group. Policy B has a weight of 2 and is also assigned to Renovations group. The nesting level is set to the default of 4.
George is assigned to Policy A because he belongs directly to the Renovations Group and Policy A has a higher weight.
Fernando is assigned to Policy A because his group falls within the group search nesting limit of 4 levels from the Renovations Group.
Betty is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Renovations Group.
Samantha is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Renovations Group.
Anne is assigned to the default policy because her user group is nested more than the defined limit of 4 levels from the Renovations Group.
Ted is assigned to the default policy because his user group is also nested more than the defined limit of 4 levels from the Renovations Group.
"},{"location":"admin/adminui_policy_weight.html#directly-assigned-policies-have-priority-over-inherited-policies-regardless-of-weight","title":"Directly assigned policies have priority over inherited policies, regardless of weight","text":"Policy A has a weight of 2 and is assigned to the Corporate Communications Group. Policy B has a weight of 3 and is assigned to the Renovations Group. The nesting level is set to the default of 4.
George is assigned to Policy A because he belongs directly to the Renovations Group.
Fernando is assigned to Policy A because he belongs directly to the Corporate Communications Group and Policy A has been directly assigned to the Corporate Communications Group.
Betty is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Corporate Communications Group.
Samantha is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Corporate Communications Group.
Anne is assigned to Policy A because her groups falls within the group search nesting limit of 4 levels from the Corporate Communications Group.
Ted is assigned to the default policy because his user group is nested more than the defined limit of 4 levels from both the Renovations Group and the Corporate Communications Group.
"},{"location":"admin/adminui_policysection_administration.html","title":"Administration","text":"Policy Description Policy ID Attribute name Sametime update site URL Applied only to Installed clients. im.2012 imserver.policygroup.chat User can install plug-ins im.2013 imserver.policygroup.plugin Sametime optional plug-in site URLs A list of URLs separated by a comma, semicolon or pipe symbol. im.2022 imserver.policygroup.plugin"},{"location":"admin/adminui_policysection_chat.html","title":"Chat","text":"Policy Description Policy ID User can set the community server as the default server User must set this community as the default server community Applied only to Installed clients. im.2019 User can add multiple server communities Allow user to add multiple server communitiesApplied only to Installed clients. User can save chat transcripts Set this field to zero to allow users to save chat transcripts for an unlimited time. im.2002 Save chat transcripts automatically im.2004 Maximum number of days chat transcripts are saved Default 365 days. im.2006 Allow custom emoticons (Installed Client) im.2008 Limit contact list size set to 800 contacts per user im.2014 Allow all Sametime Connect features to be used with embedded clients Enable Sametime PWA Allow the Sametime PWA installation icon added to the desktop. Allow chat reactions Turn on and off the ability to react to a chat message im.chatReactionEnabled Allow delete chats Allow meeting links feature from chat clients User can capture screens and images im.2009 Maximum image size in KB for custom emoticons, screen captures, and in-line images The default value is 500 KB. im.2020Parent topic: Policy sections
"},{"location":"admin/adminui_policysection_filetransfer.html","title":"File transfer","text":"Policy Description Policy ID Users can transfer files im.1 Maximum file transfer size in KB: The default value is 1000 KB. im.2 Use exclude file types transfer list for files sent through the server im.3 File extensions for files to be excluded from transfer. List of filetypes to exclude from transfer. Type the three-letter extension of each file type, separated by a comma. im.4 Allow client-to-client file transfer This policy applies only to Installed clients. im.2005 Enable file transfer in group and meeting chatParent topic: Policy sections
"},{"location":"admin/adminui_policysection_meeting.html","title":"Meeting","text":"Policy Description Policy ID Allow Sametime Meetings Use this policy to allow and disallow meeting attendance. Note: Turing off this attribute doesn't prevent the login prompt. To remove guests from a meeting, see Preventing guest access for additional information."},{"location":"admin/adminui_policysection_mobile.html","title":"Mobile","text":"Policy Description Policy ID Allow mobile client im.2010 Disable untrusted SSL User cannot log into a server that doesn't have a certificate trusted by the device. Turn this setting off to enable the use of self-signed certificates. This rule also applies to pre-production environments that use self-signed certificates. The default value is on. im.mobile.disableUntrustedSsl Disable password save User cannot save password on their mobile device. Default value is on. To save your password for the next login, retain the default setting of this policy and enable Remember Password from the community settings. Turn this setting on to require users to enter their password at every login. When turned on, the client removes the password regardless if Remember Password is enabled. im.mobile.disablePasswordSave This policy also applies to meeting passwords. For safety reasons, Apple restricts users from texting while driving. The ability to save meeting passwords allows CarPlay users to safely enter meeting rooms while driving. When turned off, the Save Password switch is displayed on the password entry dialog when joining password-protected meetings. When turned on, the Save Password switch is disabled. In the event that a password has been saved prior to changing the default settings, then the password is stored in a secure storage. Allow mobile user to send files By default, you can upload files in a one-to-one chat. This policy only applies to the Choose from Files menu item in the chat window. Leave this setting on with Policy id = 1 to allow users to upload files in a one-to-one chat. Uploading files in a group chat will also require Policy id =im.allowTransferringFilesToNwayParticipants to be turned on. Sending photos from either the camera or the photos app is controlled with Policy id = im.mobile.allowSendImages which is discussed below. im.mobile.allowSendFiles User can share files with other apps Allow mobile user to send images This policy must be turned on to allow images from the device camera or photos app to be sent as inline images in a chat. It does not prevent image files such as PNG or JPG images from being sent through the Choose from Files menu. Default is on. m.mobile.allowSendImages Allow mobile user to share chat images with other apps By default, you can share images from the chat. Turn this setting off to restrict users from sharing images from the chat. m.mobile.allowShareChatImages Restrict copy/paste from chat Prevent users from copying clipboard data in to other apps. Enable URL preview User can export their Sametime contact information to a device contact application on their device Applied only to Android devices. Parent topic: Policy sections
"},{"location":"admin/alternate_client_configuration.html","title":"Configuring Sametime preferences using HCL Notes policies","text":"To configure preferences for the HCL Sametime Embedded Client for Notes, you can also use the Domino\u00ae Desktop policy settings document. These policies are applied when a Notes user logs into their home mail server and retrieves their desktop policy. These settings will not apply to any other client.
The Domino desktop policy settings document Custom Settings tab contains a Managed Settings option, through which you can define preferences.
If you do not use Domino Administrative policies in your organization, you can configure the same settings by leveraging the managed-settings.xml file and defining it in the Sametime policy.
If the preference is set in both the Domino Desktop policy settings document and the managed settings, the preference in the Desktop policy settings document takes precedence. Best practices indicate that it's preferable to set the preference in the Desktop policy settings document or the managed settings, but not in both places.
For step-by-step instructions see the article:
How to use a Notes desktop policy to push Sametime embedded client settings.
Parent Topic: Sametime client configuration options
"},{"location":"admin/apply_configchanges_docker.html","title":"Applying configuration changes in Docker or Podman","text":"Configuration files contain environment variables that can be changed and applied to the Sametime server.
You can make configuration changes by modifying the following files.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Note: Values in the Docker commands are case-sensitive and must be entered in lowercase.
Shut down the Sametime server.
docker compose down\nModify the configuration file.
Save changes to the configuration files.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Configuring
"},{"location":"admin/apply_configchanges_kubernetes.html","title":"Applying configuration changes in Kubernetes or Openshift","text":"Configuration files contain environment variables that can be changed and applied to the Sametime server.
You can make configuration changes to the Sametime deployment server by modifying the helm/values.yaml file.
Note: These settings are case sensitive and must be entered as shown.
Edit the helm charts and make modifications.
Go to the helm directory.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Configuring
"},{"location":"admin/c_dbutility.html","title":"Using the Sametime Database utility","text":"The Sametime Database utility is used to synchronize the information with that of the Sametime server database.
When you change user or group names in the directory, the change is not reflected in Sametime databases. In order to synchronize the directory names with the names in the Sametime databases, you must run the name conversion utility. You can run the name conversion utility manually on a stand-alone Community Server, or on a server in a cluster which replicates the change throughout the cluster.
Note: You do not need to run the Sametime Database utility when adding new users or groups to the Domino or LDAP directory.
The tool performs the following functions:
\u200b
Note: Refer to the Converting chat history owner data from Domino directory to LDAP format topic for the convert function.
The utility is loaded to your Docker repository during the Sametime install process, it is located in the image repository. The name of the utility image is sametime-db-utility. The Sametime Database utility uses a comma-separated value (CVS) file that you compile to update, convert, or delete names which includes the descriptor that corresponds to the task to be completed. To use the utility, create a CVS that corresponds to the task to be completed. The CVS file must contain only one type of task, that is you cannot run an update and convert using the same CVS file. Note that CSV files are case-sensitive and sensitive to spaces.
Descriptor Purpose DELETE Removes specified individual contact names from contact lists and privacy lists. ID Changes specified first names, last names, display names, or group names. TASK_LDAP Changes all contact list information from Domino Directory format to LDAP format. ORGANIZATION Change the organization name for all users.At the end of the Sametime Database utility run, a report file is generated containing a summary of changes applied to the database. You can view the report to verify your changes. The report contains a summary of changes applied to the database, including records touched, modified or deleted. It also has the count of records modified or deleted and which attribute is modified. The report file is created in the data folder. The report file name is in following format:
name_change_summary_report_[date_time].log\nParent Topic: Administering
"},{"location":"admin/c_migration_planning.html","title":"Planning for migration to Sametime 12","text":"Sametime 12 requires a new product install and migration of data from your previous version. Do not uninstall the previous version until the V12 installation is finalized and working as expected.
Because Sametime 12 is a fully containerized application, an in-place upgrades from a previous version cannot be done. Previous Sametime versions included a community and proxy server. The services provided by these servers are inclusive within the Sametime 12 container.
Before you begin the migration having a back-out plan is necessary in case the migration does not succeed. Understand the steps to reverse the changes to place the users back on the older environment if the upgrade is not successful.
"},{"location":"admin/c_migration_planning.html#section_ahy_55v_15b","title":"Contact lists","text":"In Sametime 9.x, 10.x and 11.x, vpuserinfo.nsf is used to store contact lists. Starting in Sametime 12, contact lists are maintained in MongoDB. There is a migration tool to move the contact list to MongoDB. If the deployment being migrated is not configured for LDAP, you must first convert the vpuserinfo.nsf data to LDAP using the Stnamechange utility on your current deployment environment. The utility is not available on Sametime 12 which is why you must run the utility on Sametime 9, 10, or 11 before migrating. The notes-migration tool is used to move the LDAP contact list data to MongoDB.
Before you begin the migration, purge stale users from vpuserinfo.nsf. This can be done manually with a Lotuscript agent or by using the NameChange utility. Domino database maintenance should be performed after purging stale users.
For details, see Migrating contact lists.
"},{"location":"admin/c_migration_planning.html#section_x3c_c4y_ryb","title":"Persistent chat","text":"If you were using persistent chat, you must convert it to LDAP format. For details, see Converting chat history owner data from Domino directory to LDAP format.
"},{"location":"admin/c_migration_planning.html#section_xvg_1xv_15b","title":"Customized settings","text":"Customized settings used to tune Sametime for your environment are maintained in the sametime.ini file. You'll need to make the same changes in the new environment, otherwise the settings are lost. The ST_COMMUNITY_ID parameter must match the old server to ensures that clients show awareness properly after migrating.
Policies are configured in policies.user.xml. You must start your new server configuration with the policies.user.xml file that comes with the Sametime 12 install and manually configure, when needed. There are settings in the new server version that were not in the older versions of Sametime and in the deployment. If you are using managed-settings.xml or managed-community-conf.xml, be sure to include these files in the new Sametime 12 policies.
"},{"location":"admin/c_migration_planning.html#section_yl4_f1b_b5b","title":"Moving the users","text":"After you complete testing of the new environment and ready to migrate the users, you can use one of the following strategies to migrate users.
For details, see Moving the users.
Converting from native Domino directory to LDAP
Migrating contact lists
Moving the users
Parent Topic: Migrating and Upgrading
"},{"location":"admin/c_planning_docker.html","title":"Running and managing containers with Docker and Podman","text":"Docker and Podman are third-party products. HCL support is available to assist in configuration and support-related issues as they pertain to the Sametime product. If you require assistance with a full platform deployment, contact HCL Services or one of our HCL Business Partners to inquire about professional services.
Note: Download the platform package directly from your vendor.
Docker and Podman are open-source tools used for developing, managing, and running containers on your Linux\u00ae systems. What differentiates Podman from Docker is Podman's daemon-less architecture. To learn more about these technologies, refer to Podman vs. Docker topic in the RedHat documentation.
"},{"location":"admin/c_planning_docker.html#section_vmd_vh3_ywb","title":"Deployment and support","text":"The number of concurrent users that Sametime can support depends on the size of the deployment.
System requirements : The minimum requirements must be available to install the product successfully. For details on system requirements, see the System requirements article.
Meeting size : By default, there is a limit of 100 participants for every meeting. To reach a wider audience, you can start a live stream and share the link with all intended participants. The limit is configurable. For more information, refer to Configuring the maximum number of meeting participants.
"},{"location":"admin/c_planning_docker.html#section_qgr_233_ywb","title":"Migration","text":"When moving to a new server, redeploy Sametime as a new configuration. If the server host name in the URL changes, you can push the new URL to the Connect and Embedded clients using Managed Settings or Domino Desktop policy (Embedded only). For more information, refer to Updating connectivity settings with the managed-community-configs.xml file.
Existing URLs work if the host name remains the same.
"},{"location":"admin/c_planning_docker.html#section_rvv_hw1_ftb","title":"Disaster recovery","text":"The backup and restore process is handled outside of Sametime. Consult with your Docker or Podman vendor for details.
Parent Topic: Platforms
"},{"location":"admin/c_planning_kubernetes.html","title":"Planning for Sametime in a Kubernetes environment","text":"Kubernetes provides container orchestration for managing containers. When using this platform, you must consider how to manage operations, scalability, and security.
Kubernetes is a third-party product. HCL support is available to assist in configuration and support-related issues as they pertain to the Sametime product. If you require assistance with a full Kubernetes deployment, reach out to HCL Services or one of our HCL Business Partners to inquire about professional services.
Note: Packages for Kubernetes can be downloaded directly from your vendor.
"},{"location":"admin/c_planning_kubernetes.html#section_sdv_x43_ywb","title":"Manage operations","text":"Kubernetes automates the deployment and management of containerized applications. The number of concurrent users that Sametime can support depends on the size of the deployment. For sizing and deployment-related questions, contact HCL. If you are unfamiliar with this technology, see An Overview of Kubernetes.
High-availability clusters : High availability is supported for the front-end web traffic to the Kubernetes cluster. You can deploy multiple web front ends on different physical or virtual nodes pointing to the same back end in order to both distribute load and survive a node outage.
High availability is not supported for active meetings. If a server hosting a meeting goes down, then ongoing meetings on that server are interrupted. There is a reconnection timer built into the client that causes all the clients to reconnect and be distributed to an available node. In some circumstances, a server going down results in the client thinking the meeting has ended. Users can quickly re-join the meeting from their Recent meetings list and meet again on an available server momentarily.\nCloud deployment : You can run a Kubernetes cluster on your own hardware or a different cloud provider. You can also use a third-party Kubernetes cloud provider, such as Amazon EKS, Google GKE, or other third-party Kubernetes provider to deploy Sametime. Each cloud provider makes security recommendations for running workloads securely in their environment. Refer to the cloud provider's security documentation for further details.
- [Deploying Sametime 12 on Google Kubernetes Engine](https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0099614) for Google GKE deployment.\n- [Deploying Sametime Meetings in Amazon's AWS Elastic Kubernetes Services](https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0085515) for Kubernetes Cloud deployment. The examples in this knowledge article are based on the version 11.5 guide and are not the exact steps for version 12. For version 12, the cluster.yaml file is found in the location of the Sametime 12 installation directory under /kubernetes/stack/eks/cluster.yaml. For additional information, see [Deploying Sametime 12 on Google Kubernetes Engine \\(GKE\\)](https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0099614).\nKubernetes automatically scales a cluster up and down in line with demand without increasing your operations team. To achieve optimal performance, you can provision the infrastructure for Kubernetes before you can install, configure, and connect a component to create a cluster.
Meeting size : By default, there is a limit of 100 participants for every meeting. To reach a wider audience, you can start a live stream and share the link with all intended participants. The limit is configurable. For more information, refer to Configuring the maximum number of meeting participants.
"},{"location":"admin/c_planning_kubernetes.html#section_hrd_ww2_jwb","title":"Security","text":"With Kubernetes, you must integrate security throughout the layers of the solution stack before deploying and running the container. Because cloud-native security is multilayer, it is an effective way to address threats across every level of workflow.
For additional information, see Overview of Cloud Native Security in the Kubernetes documentation.
"},{"location":"admin/c_planning_kubernetes.html#section_rvv_hw1_ftb","title":"Disaster recovery","text":"The backup and restore process is handled outside of Sametime. Consult with your Kubernetes vendor for details.
"},{"location":"admin/c_planning_kubernetes.html#section_n2b_1p3_ywb","title":"Beyond container orchestration","text":"Aside from container orchestration, you can also use Kubernetes to abstract the infrastructure away from higher-level services and applications, making these applications more portable and flexible. Furthermore, Kubernetes allows you to build a much-needed and future-ready architecture.
Planning for a Kubernetes cluster configuration
Planning for Openshift OpenShift is a cloud-based Kubernetes platform. Planning considerations and procedures used to deploy Sametime in an Openshift environment are the same as the Kubernetes platform with the additional considerations addressed in this topic.
Parent Topic: Platforms
"},{"location":"admin/c_planning_kubernetes_cluster.html","title":"Planning for a Kubernetes cluster configuration","text":"When installing Sametime in a Kubernetes cluster, there are several considerations, some are a prerequisite to installing Sametime. Sametime can also be installed into the same Kubernetes cluster as other products, for example, MongoDB as long as the system requirements are met.
Note: The Sametime documentation does not provide full step-by-step instructions on creating a Kubernetes cluster because each Kubernetes provider has different steps. Consult your Kubernetes provider documentation for details on creating a cluster.
Two types of server nodes with different requirements are required:
The nodes are labeled with Kubernetes labels which allows the Kubernetes pod scheduler to assign the Kubernetes pods to the proper node type.
The video node runs the video pods only. This allows the video pod full access to the machine. A video node is reached from clients by NodePort, directly to its Public IP address. There is no load balancer or service requirement for inbound media traffic, as the media traffic is addressed to the specific video bridge where the meeting is active. The machine type must be suitable for media, with a minimum of 4 CPU and 16GB of RAM. When creating the node, pool autoscaling must be enabled. The Sametime autoscaler uses CPU utilization to determine when to bring up more nodes. For guidance on how many nodes to include in the video node pool, contact HCL
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_mrc_fc5_swb","title":"Availability zones for resiliency","text":"If you are installing Sametime into a cloud hosted Kubernetes environment, such as Google Kubernetes Engine, or Amazon Elastic Kubernetes Service, consider creating nodes in more than one availability zone. This provides some additional resiliency if the cloud provider has an outage in a particular data center, having nodes in a different zone allow a fail over event to take place.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_dw3_1b5_swb","title":"Namespaces","text":"Many existing production environments use namespaces. A namespace can be used for Sametime, but it is not required. When you enable autoscaling, you are creating a namespace for monitoring and custom-metrics. If a namespace is created for Sametime, be sure to add the namespace argument to the helm and kubectl commands. For example, if you deploy Sametime in a namespace called sametime and you want to view a list of pod, issue the following command:
kubectl -n sametime get pods\nTo see a list of namespaces that are configured, issue the following command:
kubectl get namespaces\nFor additional information, see Namespace topic in the Kubernetes documentation.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_adc_db5_swb","title":"Network","text":"If you are new to Kubernetes, there are some concepts that are helpful to understand how to configure your firewall. There are small differences between cloud providers and on-prem providers where the names of the features may vary. The following information is generic to introduce the concept. It is important to understand the IP addresses used in a deployment have different ranges, and when configuring a firewall rule, the source IP and destination IP need to be considered.
Node : A node is the virtual machine or hardware running the Kubernetes cluster, it hosts the pods that run the Sametime workloads. A node has an IP address in the node IP range, it will have both an internal IP address and an external IP address. Video nodes are reached by end users from their public IP address directly to the node\u2019s external IP address.
Pod : A pod is a Kubernetes based workload, which has one or more containers inside. These are stateless in Sametime which means they have a defined life cycle and they do not persist. Each pod has its own unique cluster-wide IP address which changes as the pods are scaled. Typical container-to-container communications between pods on the same host are normally permitted without any additional configuration. For example, the community pod communicating to the proxy pod.
: Pods have no awareness of the node host ports or IP addresses. Additionally, you cannot directly reach a pod IP address from outside of the cluster. To expose an application that is running in your pods to be reachable from outside your cluster, Kubernetes services and ingress are used. Ingress is used to expose web services, like Web Chat and Meetings. For on-premise Kubernetes clusters, ingress is also used to expose the Sametime mux to Connect clients and embedded clients which use port 1533.
Service : A Kubernetes service is used by Sametime to expose various components running in pods outside the cluster. It provides a single endpoint to multiple back-ends. Kubernetes services have their own IP address range that is separate from the node IP and pod IP ranges. This provides a consistent IP address as a front-end since the IP addresses for pod change frequently. There are different types of services in Kubernetes, Sametime uses the LoadBalancer type service which directs traffic to back-end pods, each cloud provider has its own implementation of this and some cloud providers have more features than others.
: For cloud hosted Kubernetes clusters, Sametime deploys the mux as a service with the LoadBalancer type for both an internal IP and an external IP. The external IP is used for Sametime Connect and Embedded clients to connect to Sametime. Use the external IP to configure your firewall rules to allow external traffic if you are supporting these clients.
When you install an ingress controller in the cluster, it is also a LoadBalancer type service which has both a cluster IP and an external IP. To expose users to the web services in Sametime for Meetings and Web Chat, open port 443 to this external IP address. Some cloud providers enable this firewall rule automatically when the ingress controller is deployed into the cluster.\n\nOther Sametime components have services with cluster IP type service. To ensure that the websockets feature functions properly, ensure the video node IP can reach the Jitsi service cluster IP on ports 5280 and 5222 TCP/IP. This is because video uses a node IP address instead of one from the pod IP range. For details see the [Websockets fail to load after installing Sametime 11.6 or 12.0.x on Kubernetes](https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0101583) knowledge article.\n\nAll other Sametime components can communicate from inside the cluster to the service Cluster IP without additional firewall configuration.\n: When the connection from the community pod attempts to connect to an LDAP service outside the cluster, a source IP in the pod IP address range is used.
Network Address Translation (NAT) : If you cannot permit your firewall to allow the entire pod IP address range, consider deploying a Network Address Translation (NAT). A source NAT can replace the source IP address on a packet. Note that each Kubernetes cloud provider has its own implementation and features for NAT. For an overview, see the Using Source IP topic in the Kubernetes documentation.
: If you are deploying telephony, the Jitsi pod with Jigasi inside uses a source IP from the pod IP range when connecting to the ilink Teamcall Meeting Gateway (TMG) for SIP. You can enable a source NAT for the entire Kubernetes cluster which will cover both LDAP and Telephony traffic.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_qf1_nb5_swb","title":"Storage","text":"When you create a persistent volume there is a certain type of access mode associated with it. If you have more than one node in the main node pool, be sure to use read-write-many (RWX) access mode, this allows for more than one node to access the volume at a time. If you only have one main node in the node pool, the standard read-write-once access (RWO) is sufficient.
When configuring your persistent volume (PV), consider the types of data that are stored there, and what kinds of features users may utilize that place data in storage. Examples are:
Files : Users can upload files to chats in any of the clients including meetings. They are stored in the PV and are retained for 90 days (configurable).
Backgrounds : Users can upload their own virtual backgrounds to be used when they enable their video. These images are stored in the PV.
Recordings : Recordings are saved as MP4 files, and vary in size depending on duration.
Reports : When meeting reports are enabled, PDFs are saved in the PV containing the report.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_ltb_xb5_swb","title":"Monitoring and logging","text":"The Grafana dashboards shipped with Sametime provides multiple types of statistics. You can also deploy Elasticsearch, Fluentd and Kibana (EFK stack) to aggregate the logs and make them indexable. This is helpful to produce your own statistics, if the Grafana dashboard does not have the statistics you need. It can also aid in troubleshooting because the logs can be written to a PV outside of the pods. If the logs are not configured to be written to a PV using the EFK stack, then the logs are part of the pods and are lost when the pods are scaled. If you deploy the EFK stack, it has its own persistent volume separate from the Sametime pods.
While these tools are helpful, they do not provide proactive monitoring to alert the administrator of problems. Other products can be used for monitoring such as: Panopta or New Relic.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_brq_rd5_swb","title":"Container registry","text":"The Sametime container images can be stored and retrieved from a public or private container registry. Using a registry might require authenticated access or keys. The Sametime server authenticates with the container registry using a Kubernetes secret. The secret must be created prior to installing Sametime. During the install process container images are pushed to the container registry by running the load.sh script. The container images are retrieved by the pods when the pod is initialized. For additional information, see the Using a private registry topic in the Kubernetes documentation.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_qwd_zb5_swb","title":"MongoDB","text":"MongoDB is deployed separately from Sametime and can be deployed as a standalone virtual machine (VM), a cluster installed on VMs, or a Kubernetes cluster. MongoDB has options for both running your own Kubernetes cluster or a cloud hosted cluster. These options might require an enterprise license. For more information or questions about licensing, contact a MongoDB representative. Contact information can be found on the MongoDB, Inc website.
MongoDB can be also be installed into the same Kubernetes cluster as Sametime. Ensure that you allow for additional capacity if installing into the same node pool as the main node pool, or you can dedicate a node pool to MongoDB.
Parent Topic: Planning for Sametime in a Kubernetes environment
"},{"location":"admin/c_planning_openshift.html","title":"Planning for Openshift","text":"OpenShift is a cloud-based Kubernetes platform. Planning considerations and procedures used to deploy Sametime in an Openshift environment are the same as the Kubernetes platform with the additional considerations addressed in this topic.
While Openshift is similar to other Kubernetes platforms, the following are concepts and considerations that require understanding or a decision.
In the Openshift platform, there are namespace labels used to define a common set of arbitrary User IDs (UID) to be used as runAs UIDs for the pods running in that namespace. Sametime has some containers that require a constant UID of 1000. You must create a Security Context Constraints (SCC) within the namespace where Sametime is to be deployed to apply this MustRunAs policy to allow the service account which runs the deployments to assign this constant UID.
"},{"location":"admin/c_planning_openshift.html#section_lv3_4b3_xwb","title":"Deployment into the default namespace","text":"By default, labels are not created with a random name, which can cause a problem in the default namespace where all containers labels are random. When deploying in the default namespace, comment out the seLinuxOptions:false setting for each activities, files, and recordings in the default namespace.
You can use the Sametime supplied helm charts to deploy Sametime into the default namespace without any additional configuration.
"},{"location":"admin/c_planning_openshift.html#section_ddy_p13_xwb","title":"Deployment of video","text":"There are three ways to deploy video when using the Openshift platform.
Host port
This is the default which provides the best performance and scales automatically scalable. this method requires pod-to-node affinity restriction through node labels.
Load balancer
Using a load balancer is lower performance and has no pod-to-node restrictions. It requires the Kubernetes load balancing infrastructure.
Node port
Using a node port is also lower performance but is restricted to a single node. It requires a no host-network SCC.
For step details, see
Preparing to install an Openshift environment
"},{"location":"admin/c_planning_platforms.html","title":"Platforms","text":"Docker and Kubernetes have different goals and outcomes. The decision about which platform to use depends on your end goal.
Sametime is a containerized application that you can install on the following container platforms that manage containerized applications like Sametime:
Your organization\u2019s needs drive the container environment that you select. For example, your organization might value security, scalability, and other factors. The following concepts identify some aspects of container platforms. Both Docker and Podman are container engines that you use to manage containers. Sametime runs as if in a single, isolated container. When applications run in isolated containers, they run on a single-node container platform. On a single-node platform, each application runs as a separate container. A deployment environment that contains few containers to produce a solution works well in this type of platform environment. However, if you implement a solution that requires multiple containers to be managed as a unit, a single-node platform doesn\u2019t provide the required features.
A platform that performs container orchestration, such as Kubernetes and OpenShift, offers features that enterprise solution environments require. These features, which include deployment automation, scaling, and load balancing, provide great flexibility for enterprise solutions. Multiple nodes that contain various containers are used to implement enterprise solutions. They are referred to as multiple-node container platforms.
Sametime Meetings are sized according to server activity at any given time. A large single-node container platform instance can support up to 200 concurrent peak users. However, that load doesn\u2019t account for the number of meetings that are being recorded, which are processor-intensive. The autoscaling feature in a multiple-node container platform enables adding and removing nodes as needed based upon current usage and monitoring. For sizing and deployment-related questions,\u00a0contact HCL.
Running and managing containers with Docker and Podman
Planning for Sametime in a Kubernetes environment Kubernetes provides container orchestration for managing containers. When using this platform, you must consider how to manage operations, scalability, and security.
Parent Topic: Planning
"},{"location":"admin/c_planning_prereqs.html","title":"Prerequistes","text":"Before you begin the install process, ensure that the environment includes all prerequistes and system requirements.
Parent Topic: Planning
"},{"location":"admin/c_recording_lifecycle.html","title":"Recording lifecycle","text":"To save storage space, you can automatically remove old recordings after the specified time.
By default, recordings are available for download and playback for three (3) days. This is configured using the following parameter:
For Docker, modify the .env file.
EXPIRES_IN_DAYS=n\nWhere n defines the number of days the recordings are available before getting archived. For example, to change the value to seven days, enter EXPIRES_IN_DAYS=7.
For Kubernetes, modify the .yaml file.
recordingsExpireInDays: n\nWhere n defines the number of days the recordings are available before getting archived. For example, to change the value to seven days, enter recordingsExpireInDays: 7. For more information, see Applying configuration changes in Kubernetes or Openshift.
Parent Topic: Managing recording options
"},{"location":"admin/c_troubleshooting_supportstatement.html","title":"Getting help","text":"There are several resources available to troubleshoot and resolve a problem that you can use before contacting support. If you need to contact support, a support guide describes expectations.
The HCLSoftware Customer Support website provides a starting point to access various sites containing information about HCLSoftware products and contacting HCL support.
The Sametime community forum allows Sametime product users and developers to share information and ask questions. The forum is provided as a self-help tool to help you resolve your problem and answer questions without having to call HCL support.
See the HCLSoftware Support Guide for details related to support of HCL products. Included in the document are the following: - Overview of provided service - Priority levels and service objectives - Supported HCLSofware programs - Customer responsiblities - Technical support limitations - End of support policies
Parent Topic: Troubleshooting
"},{"location":"admin/change_mongodb_credentials_docker.html","title":"Changing MongoDB credentials in Sametime for Docker and Podman","text":"Edit the custom.env file and locate the MONGO_URL parameters in the file.
Sametime configures the MongoDB details in a Mongo URL, for example:
mongodb://sametime_user:mongodb_password.mongodb_host:port\nwhere:
Update the MONGO_URL values to the new user and password.
Save the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: MongoDB
"},{"location":"admin/change_mongodb_credentials_kubernetes.html","title":"Changing MongoDB credentials in Sametime for Kubernetes and Openshift","text":"A connection URL is used to configure the Sametime and MongoDB connection. The connection URL tells Sametime how to connect to your MongoDB.
It contains information, such as the user name and password to access the database, MongoDB host name and more.
Locate the MongoDB connection URL.
For information on the connectoin URL, see Connection String URI Format topic in the MongoDB documentation.
The MongoDB details are located in the string in the following format:
mongodb://sametime\\_user:mongodb\\_password@mongodb\\_host:port/?replicaSet=replica\\_set\nAfter you have the MongoDB connection URL, run the following command to convert the connection URL to base64 encode value.
echo -n connection\\_url | base64\nWhere connection_url is the MongoDB connection URL.
Change to the helm/templates directory where the templates are located.
Open the sametime-secrets.yaml file for editing.
Locate the MongoConnectionUrl: setting in the file. Replace the existing setting value with the updated base64 encoded value.
Save and close the sametime-secrets.yaml file.
Update the URL in the live configuration by editing the sametime-global-secrets secret.
kubectl edit secret sametime-global-secrets\nNote: If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure it is created in the correct namespace.
Press i to edit the secret.
Locate the MongoConnectionUrl: setting. Replace the existing value with the updated base64 encoded value.
Press wq! to save the secret.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nFor more information, see Managing secrets in Kubernetes.
Parent Topic: MongoDB
"},{"location":"admin/chat_configuring.html","title":"Chat","text":"This section contains Chat configuration considerations.
Most chat related settings pertain to the community container. The community container:
The community container interacts directly with LDAP and MongoDB.
Parent Topic: Configuring
"},{"location":"admin/chat_configuring_sametimeini.html","title":"Configuring the sametime.ini file","text":"There are many configuration options in Sametime to override the default behaviors. Community related configuration options are in the sametime.ini file.
The sametime.ini file is part of the community container. Most of the parameters within the file pertain to community related services such as interactions with LDAP, SAML, authentication, Connect client, chat, security, and more.
Beginning in Sametime version 12, the defaults for many parameters have changed. If you have questions about previous parameter from a previous Sametime release, contact HCL Support for guidance.
The STI setting prefix followed by two underscores, followed by the section name, then a two underscores, then the parameter and the value. For example, to add a setting called ST_COMMUNITY_ID to the [Config] section, the new parameter format is STI__Config__ST_COMMUNITY_ID.
The HCL documentation and support knowledge articles document various configuration parameters created before Sametime version 12. These documents might refer to the settings using the older parameter names.
"},{"location":"admin/chat_configuring_sametimeini.html#format","title":"Format","text":"The sametime.ini file is a sectioned configuration file. Sections are noted with square brackets, for example: [Config]. The parameters specified in the sametime.ini file are valid only when placed within the correct section. Use only characters allowed within an XML file.
Parameters are specified as a key and value pair. The format is different for Docker and Kubernetes.
Docker : key=value
Kubernetes : key:\"value\"
For example:
Docker
STI__Config__ST_COMMUNITY_ID=sametime \nKubernetes
STI__Config__ST_COMMUNITY_ID: \"sametime\"\nThese settings are documented throughout the help center as well as in the HCL support portal in knowledge articles. The various documentation may have the older (before Sametime 12) notation of the sametime.ini settings with the section name listed separately.
If you need to modify a sametime.ini setting, follow the guidance in the topic for your deployment on Docker or Kubernetes.
Configuring the sametime.ini file on Docker or Podman
Configuring the sametime.ini file on Kubernetes
Parent Topic: Chat
"},{"location":"admin/chat_configuring_sametimeini_docker.html","title":"Configuring the sametime.ini file on Docker or Podman","text":"Open the custom.env file for editing.
Insert the sametime.ini parameters.
Ensure that parameters ares specified in the correct format. See Configuring the sametime.ini file for parameter format.
Save and close the custom.env file.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Configuring the sametime.ini file
"},{"location":"admin/chat_configuring_sametimeini_kubernetes.html","title":"Configuring the sametime.ini file on Kubernetes","text":"Determine the setting format by reviewing the Configuring the sametime.ini file topic. If you are enabling the community server debug, do not use the following procedure, see the Enabling Community debug in Kubernetes topic for details.
Note: When modifying the values.yaml file indentation is important and should be done using spaces only.
Change directories to the helm directory.
Open the values.yaml file for editing.
Locate the sametimeIni: {} setting in the file.
Remove the double brackets ({}).
Remove the comment tag (#) and use the line as a guide for indentation on your settings.
When setting the value, end the parameter with a colon (:) and the value in double-quotes (\"value\").
After adding your changes, confirm that the indication is correct. There should be four spaces before the parameter.
When finished, save and close the values.yaml file.
Complete the steps Applying configuration changes in Kubernetes Applying configuration changes in Kubernetes or Openshift for the changes to take effect.
Parent Topic: Configuring the sametime.ini file
"},{"location":"admin/chat_msg_delete_options.html","title":"Defining chat message deletion limits","text":"The chat deletion settings define how long a user has the ability to delete a message and undo the deletion. The default deletion time is twenty-four hours and one hour to undo the deletion.
To change the default values, modify the following files.
Use the following table to determine the configuration option to add to the file.
Options Docker Kubernetes Maximum amount of time to delete a chat message. Specify the value in seconds. The default value is 1440. MESSAGE_MUTATION_ALLOWED_AGE_IN_MINUTES messageMutationAllowedAgeInMinutes Maximum amount of time to undo a message deletion. Specify the value in seconds. The default value is 60. MUTATION_UNDO_ALLOWED_AGE_IN_MINUTES mutationUndoAllowedAgeInMinutesNote: The configuration options are case sensitive.
After updating the configuration files, restart the Sametime server to apply the changes. For more information, refer to Starting and stopping servers
Parent Topic: Administering
"},{"location":"admin/cluster_highavailability.html","title":"Clustering and high availability","text":"High availability and high capacity configuration for Sametime is achieved in different ways depending on which component is being configured for HA. See the topics below to learn more about chat, meetings, and MongoDB.
Parent Topic: Planning
"},{"location":"admin/community_provisioning.html","title":"Creating a community provisioning URL for mobile users","text":"This section describes how to create a provisioning URL that automatically creates a Sametime community definition on mobile devices running Google Android or Apple iOS, so users can easily connect to Sametime.
A mobile user cannot connect to the Sametime server without a special mobile community definition that provides details needed for the connection. Creating the mobile community is often frustrating for users because they do not have ready access to required information such as the Sametime proxy server's hostname and port. A provisioning URL for the mobile community makes it easy for users to connect to Sametime from their mobile devices after installing the client.
To connect to Sametime, the user simply taps the provisioning link or scans the associated QR code, and then:
You can format the URL as a link or as a QR code, and distribute it in email or post it on a website. The provisioned URL is supported on the following mobile operating systems:
Note: Starting with HCL Sametime version 11, the browser client displays a QR code that can be used to configure the HCL Sametime client for Android or iOS. Once logged into the browser client, open Settings and then Configure Mobile Client. The QR code displayed represents a secure community configuration for the Sametime proxy server and port that the browser is connected to. The QR code also includes the users\u2019 ID and a default community name of Sametime. The user only needs to follow the instructions to scan the code and enter their password before connecting with a mobile device.
If you wish to use a different community name or perhaps the mobile clients need to connect through an authenticating proxy, the administrator can create a custom provisioning URL using the information contained in this article and then configure the Sametime proxy to display the QR code for the custom provisioning URL rather than the default one mentioned above.
Procedure to create the custom provisioning URL
Create and distribute a custom provisioning URL by completing the following steps:
Create the URL by defining its components:
The URL is formatted as shown:
hclsametime://st_user@stproxy_host:port/?action=AddCommunity&communityName=community_name\nwhere:
hclsametime:// is a required prefix to ensure that the URL is recognized and processed correctly.st_user the user name, or login ID, of a particular Sametime user; for example, myid@mycompany.com
If you are sending or posting a URL for use by multiple people, you will probably not want to code a specific user's ID into the URL because other users may find that confusing. Instead, you can supply a variable or a partial user name and instruct users to modify the URL with the completed user name on their own devices, or you can omit the user name entirely so that each user is prompted for credentials when logging in to Sametime. If you want users to be able to simply click a link or QR code to use the URL, you should omit the user name and allow the user to provide credentials at login.
Note:
In addition, you can optionally instruct users to include the associated password in the URL with the following syntax: st_user:st_password; however, this is not a good practice because the password could potentially be consumed by an untrusted app.
stproxy_host is the fully qualified host name of the Sametime Proxy Server; for example: stproxy.example.com.
port is the port that the Sametime Proxy Server is listening on. If omitted, 443 will be used.?action=AddCommunity is a required parameter that ensures the information within the URL is added to the mobile client as a community definition.&communityName=*community\\_name* is an optional URL-encoded string that provides a name for the new community. If you do not specify a name with this parameter, a default name will be created based on the Sametime Proxy Server's host name. The table below provides the complete list of parameters that you can include in the URL and indicates whether each parameter is required.Examples:
Encrypted (SSL) direct connection to server stproxyserver.example.com on default port 443 with no user-specified but the community name is specified as \"Sametime Server\" :
hclsametime://stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\nTo preserve correct URL syntax, the space in \"Sametime Server\" is represented with %20.
Encrypted (SSL) direct connection to server stproxyserver.example.com on port 9080 for user dmisawa:
hclsametime://dmisawa@stproxyserver.example.com:9080/?action=AddCommunity\nIf the user name itself contains the @ symbol you will need to format it as the URL-encoded character %40 to preserve correct syntax, as in
dmisawa%40auto_sales@stproxyserver.example.com:9080\nEncrypted (SSL) authenticating proxy connection to safelinx.example.com on default port 443 reusing authenticating proxy credentials and supplying a variable for the user name, which each user must replace with their own ID:
hclsametime://Your_Sametime_ID@safelinx.example.com/?action=AddCommunity&authProxyReuseCredentials=true\nIn this case both the auth proxy user ID and the sametime user ID would be set to Your_Sametime_ID.
Encrypted (SSL) authenticating proxy connection to safelinx.example.com on port 8881 reusing credentials, with no credentials specified so that each user will be prompted for credentials when logging into Sametime:
hclsametime://safelinx.example.com:8881/?action=AddCommunity&authProxyEnabled=true\nDistribute the URL to mobile users:
Configuring the Sametime server to use the custom provisioning URL
Before updating the stproxyconfig.xml, examine the URL. URL encode any ampersands or spaces. For example, if the URL.
hclsametime://stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\nThe ampersand character is replaced with %26.
hclsametime://stproxyserver.example.com/?action=AddCommunity%26communityName=Sametime%20Server\nAdd a <mobile> section if it does not exist with <configUrl> providing the provisioning URL as shown in the following example.
<mobile>\n<configUrl>CUSTOM_PROVISIONING_URL</configUrl>\n</mobile>\nSave and close the file
Restart the Sametime Proxy server to enable.
Creating a community provisioning URL on Docker or Podman As discussed in Creating a community provisioning URL for mobile users, mobile users cannot connect to the Sametime server without a special mobile community definition that provides details needed for the connection. This topic discusses the specific steps to set up the community provisioning URL on Docker or Podman.
Parent Topic: Sametime client configuration options
"},{"location":"admin/config_buscard.html","title":"Configuring business cards using an LDAP directory","text":"Configuring business cards is done in the UserInfoConfig.xml file in the community pod.
Before you start setting up your business cards, ensure the following:
Configuration settings for business cards are in the UserInfoConfig.xml file in the community container or pod. For most environments, the UserInfoConfig.xml file works with default settings. You can override the default configuration settings by modifying the UserInfoConfig.xml file. The procedure to update the UserInfoConfig.xml file is different on Kubernetes and Docker.
When modifying the XML file be sure to check the formatting using a browser. If there is an error with the formatting of the XML file, a business failure can occur.
When using multiple LDAP servers, each LDAP server requires its own settings. By default, only the first server is configured during setup. To add additional LDAP servers, use the existing settings as a template.
Locate the <StorageType=\u201dLDAP\u201d> section and copy everything between the <StorageType=\u201dLDAP\u201d> and </Storage> statements. Paste the statements at the end of the section below the </Storage> statement. This creates a new LDAP section. See Configuring additional LDAP servers on Kubernetes for information on configuring LDAP.
Configure an authenticated bind.
In some environments, not all the attributes are available to an anonymous bind, and an authenticated bind must be used. During the Sametime installation, anonymous binds to LDAP is configured by default. When a custom UserInfoConfig.xml file is being used, the LDAP bind credentials are being overridden. Bind credentials are located in the .env file for Docker and the sametime-global-secret in Kubernetes.
Use the echo command to find the base64 encoded value for the user name and password.
Specify the user name and password separated by a colon. For example, if the Bind user name is CN=stbind,O=example and the password is securePassword, enter the following command in a Linux shell:
echo -n \u2018CN=stbind,O=example:securePassword\u2019 | base64 \nThe results from the command is the value of a new argument called UserEncodedAuth.
Replace the user name and password parameters with UserEncodedAuth=\"value\".
For example:
<StorageDetails HostName=\"ldap2.example.com\" Port=\"1389\" UserEncodedAuth=\u201d 4oCYQ049c3RiaW5kLE89ZXhhbXBsZTpzZWN1cmVQYXNzd29yZOKAmQ==\u201d SslEnabled=\"true\" SslPort=\"636\" BaseDN=\"\" Scope=\"2\" SearchFilter=\"(&(objectclass=organizationalPerson)(|(cn=%s)(givenname=%s)(sn=%s)(displayName=%s)(mail=%s)))\"/>\nBy default, the LDAP operations are not encoded, and all communications are sent over clear text. To enable encryption, first follow the instructions in Securing connections between Sametime servers and LDAP.
After the keystore has been created, update the SSL properties to include the path to the keystore and its password. For example:
<SslProperties KeyStorePath=\"keys.p12\" KeyStorePassword=\"securePassword\"/> \nVerify the port number on the SslPort property. The default LDAP port number is 636.
SslPort=\"port\\_number\"\nChange the setting for SslEnabled to true.
SslEnabled=\"true\"\nReview the default search filter and make changes to fit your LDAP server\u2019s schema.
The BaseDN field specifies where to start searching in the directory. For example, if all users are located in cn=users,dc=example,dc=com, you could set your BaseDN=\u201dcn=users,dc=example,dc=com\u201c so that the rest of the directory is not searched. A BaseDN is required if using Microsoft Active Directory and is not required for Domino LDAP.
Scope specifies how deep the search is done, enter one of the following.
0 = Base : A lookup operation. Only a single entry described by the base DN is matched.
1 = One level : Searching is performed one level below the base DN and no further. This is like opening a folder in a file system and looking only at the direct elements inside the folder.
2 = Subtree : All child entries of the base DN are searched, whether direct or not, including the base DN itself.
The host name of the LDAP server is set during setup. Review the HostName setting and confirm that it is the fully qualified host name of the LDAP service, which might be a load balancer in front of a cluster of LDAP servers.
If the host name is not correct, update it in the helm/values.yaml file for Kubernetes or the .env file for Docker.
Map the business card fields to LDAP attributes
For each type of data, there is an Id and FieldName.
Id is the internal name used to identify each area of the business card.FieldName value is set to the LDAP attribute that contains the data to display inside the business card. Modify any values that do not match your LDAP schema. These settings are in the <Details> section.Note: ** If images are stored in a URL, see the step 8.
If you would like to map additional detail to these fields it is possible with additional configuration modify the appropriate line in the <Details> section.
For example, if there is both a desk phone number and a mobile phone number that you wish to include in the business card, you can use a separator between the two phone numbers when the information is displayed. Locate the <Detail> line with the telephone attributes. For desk phone number the attribute is telephoneNumber, and for mobile phone it is mobile. In the field name, include both attributes separated by a comma.
FieldName=\u201dtelephoneNumber,mobile\u201d\nAdd DisplaySeparator=\"separator\" to the statement identifying the separator. In the example, the forward slash is used as the separator. You can choose other characters as a separator.
<Detail Type=\"text/plain\" Id=\"Telephone\" FieldName=\"telephoneNumber,mobile\" DisplaySeparator=\u201d / \u201c/>\nIf photos are stored in a URL on a web server, the LDAP server must have an attribute that contains the URL. The attribute can be an existing attribute that has been repurposed or a new attribute can be created.
Note: If you are using HCL Connections Profiles for the photos, see the topic Configuring Business Cards on HCL Connections.
When using Connection Profile URLs, the photo name must be the email extension of .jpg.\u00a0For example, if a user\u2019s email address is jane@example.com, the file name must be jane@example.com.jpg.
Locate the <Details> section. Create a new <Details> line for the ImagePath to be used by desktop clients. In the FieldName setting, enter the attribute that contains the URL. For example,if the attribute that contains the photo URL is description the new line is:
<Detail Type=\"text/plain\" Id=\"ImagePath\" FieldName=\"description\"/>\nIf you have mobile clients, add an additional <DetailType> for PhotoURL. For example:
<Detail Type=\"text/plain\" Id=\"PhotoURL\" FieldName=\"description\"/>\nIn the Set params settings, select the Id names for the fields that you want to display as part of the business card. And remove any Ids that you do not want to include.
For example, if you do not want to include the company name, remove \u201cCompany\u201d from the list of attributes.
If you have added ImagePath, PhotoURL, or both, add these to the <Set params> and remove Photo.
There are two lines that begin with <Set params>, each one has a unique SetID=.
UserInfoConfig.xml file must be updated.Locate the StorageDetails tag of the relevant LDAP directory and add the following flags:
UserIdAttribute= attribute_name
Where attribute_name is the name of the attribute configured as the internal ID.
PersonObjectClass= object_class_name
Where object_class_name is the name of the person object class, for example: organizationalPerson.
When all updates are complete, save and close the UserInfoConfig.xml file.
Verify that there are not formatting errors by opening the file in a browser.
If no mistakes are found, update the Docker or Kubernetes deployment for the settings to take effect. See Customizing business cards in Docker and Podman or Customizing business cards in Kubernetes.
Parent Topic: Setting up business cards
"},{"location":"admin/config_buscard_custom_docker.html","title":"Customizing business cards in Docker and Podman","text":"You can override the default business cards configuration by editing a UserInfoConfig.xml file and adding it as a volume in the docker-compose.yml.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Copy the existing file out of the community container and place it in the current Sametime installation directory.
docker cp <container_name>:/local/notesdata/UserInfoConfig.xml . \nTo identify the community container ID, run the command docker container ls and look for the chat-server IMAGE. The NAME is the container name, as an example: sametime-community-1.
Make needed changes, then update volumes in the Community service section of docker-compose.yml by adding the following.
./UserInfoConfig.xml:/local/notesdata/UserInfoConfig.xml\nRestart the Sametime server to apply the changes.
docker-compose down\ndocker-compose up -d\nParent Topic: Setting up business cards
"},{"location":"admin/config_buscard_custom_kubernetes.html","title":"Customizing business cards in Kubernetes","text":"You can override the default business cards configuration by creating an extra-community-configs secret to hold the configuration files.
Kubectl commands are used to pull the existing file from the community pod to your local machine. You modify these files locally with the required settings, then create the secret containing the files.
The following procedures describes the steps to create a new secret. The example used in the steps shows creating a secret called extra-community-configs which overrides the values.yaml settings for LDAP. The extra-community-configs secret contains a copy of the configuration files used by the Community pod. For more information on secrets, see Managing secrets in Kubernetes.
Create a directory on your machine called extra-community-config at the root of where the Sametime installation package was decompressed.
mkdir extra-community-config\nUse the cd command to change to the extra-community-config directory.
cd extra-community-config\nFind the community pod name by running the get pods command.
The pod name has some hashes in it, for example: community-77d4695988-2bzrx): kubectl get pods.
Run the following command to pull a copy of the StCommunityConfig.xml file from the community pod specifying the name of the pod.
kubectl exec -it pod\\_name --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml\nThis file must be available. No changes to it are needed at this time.
Run the following command to pull a copy of the UserInfoConfig.xml file from the community pod specifying the name of the pod.
kubectl exec -it pod\\_name --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml\nUsing a text editor, open the local copy of the UserInfoConfig.xml file in edit mode. Modify the file as needed.
When finish, save and close the file.
Ensure that you are in the extra-community-config directory that was created earlier. Run the following command to create the secret. If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure it is created in the correct namespace.
kubectl\u202fcreate secret generic extra-community-config --from-file=./ \nUse the cd command to change to the helm directory where the Sametime installation package was decompressed.
cd helm\nOpen the values.yaml file and put in edit mode.
Add the following line to the values.yaml file.
overrideCommunityConfigSecret: extra-community-config\nWhen finished save and close the file..
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up business cards
"},{"location":"admin/config_chat_ldap_java_format.html","title":"Example: Writing a Java class to format names returned in a search","text":"To return a user name in a format that is not available in an LDAP directory entry attribute, you can write a Java\u2122 class that manipulates existing information in the LDAP directory to produce the user name in the desired format.
In most environments, the value of the The attribute of the person entry that defines the user's name setting can specify a common LDAP directory attribute, such as cn (common name) or mail (email address). When configured in this way, the search returns the value assigned to a user's cn or mail directory attribute and displays this value in the HCL\u00ae Sametime\u00ae client user interface.
To return names in a format different from the LDAP directory attributes, create a custom Java class. For example, you might create a Java class that does the following:
The sample code that follows shows how to combines the values of the sn and givenName attributes to return a user name with the surname shown first, assuming the following requirements:
Sample code
This example takes values from the sn and givenName directory attributes and combines these values into a single display name in the format of surname, given name.
public class StLdapCustomizedAttributes\n\n{\n\npublic static String displayName (String givenName, String sn) \n\n{\n\nString result = sn + \", \" + givenName;\n\nreturn result;\n\n}\n\n}\nAfter writing your Java class, complete the tasks in this section to implement it in either Docker or Kubernetes.
Parent Topic: Creating custom Java classes for searching LDAP
"},{"location":"admin/config_chat_ldap_java_people.html","title":"Example: Writing a Java class to filter searches for people and groups","text":"If a single search filter is not adequate to resolve user or group name searches, you can write a Java\u2122 class containing a method that specifies exactly how directory searches are conducted. The class can invoke different LDAP search filters depending on search criteria entered by users.
The Search filter for resolving person names and the Search filter for resolving group names settings in the LDAP directory settings of the Sametime\u00ae Administration Tool define the LDAP directory search filters responsible for selecting user and group names from the LDAP directory.
Note: You do not have to write Java classes to control the search behavior for both users and groups. You can use a Java class to control the search behavior for users while using a single LDAP search filter to control the search behavior for groups, or vice versa.
The specific source code that you write to support customized LDAP searches is entirely dependent on your environment. This section provides a code sample to help you understand how to write the Java class appropriate for your environment.
Note: The searched name must be escaped according to LDAP RFC2254 before adding it to the created LDAP filter. Use the escape and the isHex methods as is from the following example.
The following example invokes different LDAP directory search filters based on the text string that is entered into the Sametime user interface by a user. The search filters invoked by the method are dependent on the directory schema and the search behavior needed for the environment. Assume that three different users want to add the user Victor Lazlow to their Sametime Connect Client buddy lists. Each of the three users searches for Victor Lazlow in a different way. The logic of the Java class dictates the results of these three user searches:
User 1
Input: User 1 enters Victor L* into the Sametime client user interface to add Victor Lazlow to the Contacts list.
Results: This search attempt returns an error because the Java class is programmed to return an error when the user enters a text string that includes an asterisk.
User 2
Input: User 2 enters Victor_Lazlow@example.com into the Sametime client interface.
Results: This search attempt succeeds and returns the value \"Victor_Lazlow@example.com\" (Victor Lazlow's email address) from the LDAP directory. The search attempt succeeds in this way because the Java class is programmed to return an LDAP search filter that can resolve an LDAP directory search to a user's email address. The Java class returns this email address search filter if the search text string entered by the end user includes the \"at\" character (@).
User 3
Input: User 3 enters \"Victor L\" into the Sametime client interface. This search attempt succeeds and returns the common name (cn) directory attribute of \"Victor Lazlow.\"
Results: The search attempt succeeds in this way because the Java class is programmed to return an LDAP search filter that can resolve an LDAP directory search to a user's common name (cn). The Java class returns this common name search filter if the search text string entered by the end user does not include either an asterisk or \"at\" (@) character.
Sample code
The code sample that follows shows the Java source code that produces this search behavior. This code creates a Java class named StLdapCustomized that includes the peopleResolveFilter method. The if statements in the peopleResolveFilter method examine the text string entered by the user in the Sametime client user interface and return the appropriate LDAP search filter based on this text string. The comments in the source code explain the purpose of each if statement.
public class StLdapCustomized\n{\n /**\n * String representing an escaped forward slash sign '\\'\n */\n private final static String SLASH_SIGN_CONVERTED = \"\\\\5c\";\n\n /**\n * String representing an escaped * sign '*'\n */\n private final static String STAR_SIGN_CONVERTED = \"\\\\2a\";\n\n /**\n * String representing an escaped opening bracket sign '('\n */\n private final static String OPENING_BRACKET_SIGN_CONVERTED = \"\\\\28\";\n\n /**\n * String representing an escaped closing bracket sign ')'\n */\n private final static String CLOSING_BRACKET_SIGN_CONVERTED = \"\\\\29\";\n\n /**\n * Escape problematic characters in the name to match the LDAP filter escaping\n * criteria according to RFC2254\n * rfc2254 - The String Representation of LDAP Search \n * @param name the name to escape\n * @return an escaped string\n */\n private static String escape(String name)\n {\n StringBuffer escapedName = new StringBuffer();\n for (int i=0; i< name.length(); ){\n switch(name.charAt(i)){\n case '\\\\':\n // if the next 2 chars are hex we don't need to escape\n if((i< name.length()-2) && isHex(name.charAt(i+1)) &&\n isHex(name.charAt(i+2))){\n escapedName.append('\\\\');\n escapedName.append(name.charAt(++i));\n escapedName.append(name.charAt(++i));\n }\n else{\n escapedName.append(SLASH_SIGN_CONVERTED);\n }\n i++;\n break;\n\n case '*':\n escapedName.append(STAR_SIGN_CONVERTED);\n i++;\n break;\n\n case '(':\n escapedName.append(OPENING_BRACKET_SIGN_CONVERTED);\n i++;\n break;\n\n case ')':\n escapedName.append(CLOSING_BRACKET_SIGN_CONVERTED);\n i++;\n break;\n\n default:\n escapedName.append(name.charAt(i));\n i++;\n\n }\n }\n\n return escapedName.toString();\n }\n\n /**\n * Verifies whether this char is a hex char\n * @param c\n * @return\n */\n private static boolean isHex(char c){\n boolean hex = true;\n hex = !( Character.digit(c, 16) == -1);\n return hex;\n }\n\n /**\n * Generates a search filter for finding a user, given the user's \n * name. \n * The searched name is escaped according to LDAP filters escaping rules.\n * The checks on the searched name format should be done before escaping the value.\n * @param name The user's name as provided by the Sametime client.\n * @return The search filter, or null if the name is invalid. \n * */ \n\n public static String peopleResolveFilter (String name) \n { \n String escapedName;\n // prevent users from adding their own wildcards\n if (name.indexOf('*') != -1) \n return null;\n\n // if name looks like email, do not search with wildcards, and only search in mail attribute \n if (name.indexOf('@') != -1) \n {\n escapedName = escape(name);\n return \"(&(objectclass=person)(mail=\" + escapedName + \")) \";\n }\n\n // otherwise, search as CN with wildcard\n escapedName = escape(name);\n return \"(&(objectclass=person) (cn=\" + escapedName + \"*))\";\n }\n}\nAfter writing your Java class, complete the tasks in this section to implement it in either Docker or Kubernetes.
Parent Topic: Creating custom Java classes for searching LDAP
"},{"location":"admin/config_class_file_docker.html","title":"Configuring the class file on Docker and Podman","text":"Use a custom Java class file to transform your searches for LDAP for the community pod.
You must have already created and compiled the class file using Java 1.8.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
To configure a custom Java class file to transform your searches for LDAP for the Sametime server on Docker you need to complete the following tasks.
Override the default LDAP settings to use the class file
Name the compiled class file StLdapCustomizedAttributes.classfile.
Place the StLdapCustomizedAttributes.classfile into the Sametime installation directory or a sub directory, example: ldap-custom-filter.
Identify the chat-server container ID by running the docker container ls command and finding the chat-server IMAGE. The NAME is the container name. For example: sametime-community-1.
Pull a copy of the StCommunityConfig.xml from the chat-servercontainer by running the following command, where containerid is the container name for the chat server identified in step 2.
If the StCommunityConfig.xml has already been copied and edited previously for a different setting, skip this step and edit the existingStCommunityConfig.xml.
docker cp <container_name>:/local/notesdata/StCommunityConfig.xml . \nUpdate the configuration that pertains to your custom Java class. Open theStCommunityConfig.xml file that was copied from the chat-server contain and edit the <LDAP> section as it pertains to your configuration.
The changes depend on what you are modifying, refer to the following table for guidance.
Type of change Parameter name What to specify Example Search filter for resolving person names PersonResolveFilter classname.methodname() for your custom codeStLdapCustomized.peopleResolveFilter() Search filter for resolving group names GroupResolveFilter Class name and method name for a group filter, using the following format: Classname.methodname() StLdapCustomized.groupsResolveFilter(). Attribute of the person entry that defines the person's name DescAttribute Class name and method name for the formatting, with the name of the attribute inside, for example: Classname.methodname(attribute_name) StLdapCustomizedAttributes.displayName(cn) Save and close the StCommunityConfig.xmlfile.
Edit the docker-compose.yml file and add the following under the community section:
volumes: \n - ./ StLdapCustomizedAttributes.class:/local/notesdata/java/ StLdapCustomizedAttributes.class\nIf the class files is placed in a sub-directory, it must be specified in the above volume path.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Creating custom Java classes for searching LDAP
"},{"location":"admin/config_class_file_kubernetes.html","title":"Configuring the class file on Kubernetes","text":"You can use a custom Java class file to transform your searches for LDAP for the community pod.
You must have already created and compiled the class file using Java 1.8.
To configure a custom Java class file to transform your searches for LDAP for the community pod in Kubernetes you need to complete the following tasks.
The changes in this task affect the following pods:
community
Create a configmap with your compiled class file.
Name the compiled class file StLdapCustomizedAttributes.class.
Create a folder on the machine where you run the kubectl commands called ldap-custom-filter.
Place the StLdapCustomizedAttributes.class file into the ldap-custom-filter folder.
Change directories to the ldap-custom-filter folder.
Run the following command to create a ConfigMap with the StLdapCustomizedAttributes.class within it.
kubectl create configmap ldap-custom-filter --from-file=./ \nNote: If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure it is created in the correct namespace.
Modify the pod.yaml file for the community pod to load the ConfigMap.
Use a text editor to open the file pod.yaml in the helm/charts/community/templates/ directory.
Locate the volumeMounts: section and under the first mountPath, statement create a new line and add the following stanza.
- name: ldap-custom-filter \n configMap: ldap-custom-filter\n name: \nCorrect the indentation using only spaces so that the alignment of the new lines is the same as the lines above it. When finished it should look like the following:
Save and close the pod.yaml file.
Override the default LDAP settings to use the class file.
Make a directory on your machine called extra-community-config at the root of where the Sametime installation package was decompressed.
Change to the extra-community-config directory.
Find the community pod name by running the get pods command. The pod name has some hashes in it, for example: community-77d4695988-2bzrx):.
kubectl get pods\nPull a copy of the StCommunityConfig.xml file from the community pod.
Run the following command, where podname is the pod name found in the previous step.
kubectl exec -it pod\\_name --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nPull a copy of the StCommunityConfig.xml file from the community pod.
Run the following command, where podname is the pod name which is the same as the previous step.
kubectl exec -it pod\\_name --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nUpdate the configuration that pertains to your custom Java class. Open the StCommunityConfig.xml file that was copied to your machine. Then edit the <LDAP> section as it pertains to your configuration. The changes depend on what you are modifying, refer to the following table for guidance.
StLdapCustomized.peopleResolveFilter() Search filter for resolving group names GroupResolveFilter Class name and method name for a group filter, using the following format: Classname.methodname() StLdapCustomized.groupsResolveFilter(). Attribute of the person entry that defines the person's name DescAttribute Class name and method name for the formatting, with the name of the attribute inside, for example: Classname.methodname(attribute_name) StLdapCustomizedAttributes.displayName(cn) Save and close the StCommunityConfig.xml file.
Ensure you are in the extra-community-config directory that was created earlier then run the following command to create the secret.
kubectl\u202fcreate secret generic extra-community-config --from-file=./ \nNote: If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure it is created in the correct namespace.
Change to the helm directory where the Sametime installation package was decompressed.
Open thevalues.yaml file and place in edit mode.
Add the following line.
overrideCommunityConfigSecret: extra-community-config\nSave and close the values.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Creating custom Java classes for searching LDAP
"},{"location":"admin/config_client_access_pref.html","title":"Accessibility preferences","text":"The following table lists the accessibility preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release useAcc Boolean. Default is false. Specifies whether or not to optimize chat transcript for screen readers (will replace the transcript with a different format). 7.5.1 and later optimizeAlerts Boolean. Default is false. Specifies whether or not to optimize notification settings for screen readers (will turn off bring to front, flash window, turn on sounds). 7.5.1 and later useLessVerbose Boolean. Default is false. Specifies whether or not to set less verbose messages for screen readers (less verbose will not read status change events and typing events in the chat window). 7.5.1 and later useArrowKeyForQuickfind Boolean. Default is false. Specifies whether to use the arrow key for quick find. 8.5.1 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_cal_pref.html","title":"Calendar preferences","text":"The following table lists the calendar preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release alertMeWhenMeetingStarts Boolean In Auto-Status Changes for Meetings scheduled in my calendar, specify whether to alert user when user has a meeting scheduled in the calendar. 8.5.1.1 and later enabled Boolean Specify wether or not to enable auto status change for meetings scheduled in user's calendar. 8.0 and later promptMe Boolean In Auto-Status Changes for meetings scheduled in my calendar, specify whether to prompt user before changing the status when user have a meeting scheduled in the calendar. 8.0 and later statusMsg String In Auto-Status Changes for meetings scheduled in my calendar, specify the status message when user select \"Automatically change my status.\" 8.0 and later setback Boolean In Auto-Status Changes for meetings scheduled in my calendar, specify whether to return to user's previous status when the meeting is over. 8.0 and later outlook_enabled Boolean In Calendar Service page, specify whether to check Outlook calendar for meetings to allow auto status changes. It's valid only if the Outlook service is available. 8.0 and later notes_enabled Boolean In Calendar Service page, specify whether to check Notes calendar for meetings to allow auto status changes. It's valid only if the Notes service is available. 8.0 and later interval Positive integer value, unit is minutes. 10 minutes is the default. In Calendar Service page, specify the interval that Sametime retrieves calendar information for an auto-status change. This value is not for the interval to update auto-status. 8.0 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_chat_history_pref.html","title":"Chat preferences","text":"The following tables list the chat preferences for the HCL Sametime Connect Client and Sametime Embedded Client for Notes\u00ae.
Table 1. Application Preferences - com.ibm.collaboration.realtime.application release 8.5.1.1 and later
Attribute Variable type Description Release enableNwayRichText Boolean. Default is false. Specifies whether or not to enable the client to support rich text in a multi-user chat. Rich text is enabled in a multi-user chat session only if all clients participating in the chat session have this setting enabled. 8.5.1.1 and laterTable 2. Chat History Preferences - com.ibm.collaboration.realtime.chat.logging release 7.5.x and later
Attribute Variable type Description Release days.storage.max A positive number. Delete saved transcripts after this number of days. This setting will be overwritten by the value set on the server policy. 7.5.1 and later delete.old A positive number. The default is false. Delete saved transcripts. This setting will be overwritten by the value set on the server policy. If the policy allows transcripts to be deleted, set this value to true initially. 7.5.1 and later logging.default 0 = Automatically save chats, 1 = Do not automatically save chats, 2 = Prompt me to save chats Default chat logging action. 7.5.1 and later logging.enabled Boolean. Default is false. Specify whether or not to save a local copy of the chat history. If the server policy is not configured to allow save chat, this setting is ignored. 7.5.1 and later Note: Local chat history is unencrypted. To disable and restrict users from saving a local copy, refer to Updating client preferences with the managed-settings.xml file. display.context True = Display, false = Do not display Display the saved transcript between two users for the current day in the chat window. 7.5.1 and later display.context.background True = Display, false = Do not display Display background highlighting when displaying saved transcripts in chats. 7.5.1 and later root.location A string of a valid path on the computer. Location for automatically saved chats Directory path. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. Example using absolute path:com.ibm.collaboration. realtime.chat.logging/ root.location= C:\\\\Documents\\\\user\\\\ SametimeTranscripts Releases 8.0.2 and later support the use of a relative path. Example using a path relative to the user profile folder for Windows\u2122 and Mac: com.ibm.collaboration. realtime.chat.logging root.location= \\\\SametimeTranscripts For Linux com.ibm.collaboration. realtime.chat.logging root.location= \\\\SametimeTranscripts save.file.location A string of a valid path on the computer. Default location for manually saved chats. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. Example using absolute path: 7.5.1 and later com.ibm.collaboration.realtime.chat.logging/ave.file.location=C:\\\\Documents\\\\user\\\\SavedChats Releases 8.0.2 and later support the use of a relative path. Example using a path relative to the user profile folder for Windows and Mac: com.ibm.collaboration. realtime.chat.logging/ root.location= \\SametimeTranscripts For Linux, com.ibm.collaboration. realtime.chat.logging/ root.location= SametimeTranscripts prompt.save Boolean If using mail service for logging, specify whether to display a confirmation after manually saving chats to the mail file. 7.5.1 and later reset.user.resets.logging.prefs Boolean. Default is false. Specify whether to prompt user to reset logging preferences after resetting user. 7.5.1 and later firsttime.askprefs Boolean. Default is true. Specify whether to prompt user to set logging preferences when Sametime\u00ae launched for the first time. When the value is set to true, loggging.enabled should also be set to define the default enablement state for saving chat transcripts. 7.5.1 and later schedule.delete.old Boolean. Default is false. Specify whether or not to start the scheduled file-based chat history deletion task. The task is scheduled at a 12-hour interval, starting from the login time. The local chat history is deleted automatically only if the corresponding server policy is enabled for it. 8.5.2 IFR1 and later Table 3. Chat History UI Preferences - com.ibm.collaboration.realtime.chat.logging.ui release 7.5.x and later
Attribute Variable type Description Release allowSaveOverride Boolean. Default is true. Specifies whether to show menu item \"Prevent Transcript save\" in chat window Tools menu 7.5.1 and later noPersonListLiveNames Boolean. Default is false. Specifies whether to use Live Names in the chat history viewer person list. 8.5.2 and laterTable 4. Chat Window Preferences - com.ibm.collaboration.realtime.chatwindow release 7.5.x and later
Attribute Variable type Description Release showuserinfo Boolean. Default is true. Specifies whether or not to display the business card in the chat window. 7.5.1 and later showtimestamp Boolean. Default is true. Specifies whether or not to display timestamps in the chat transcript area. 7.5.1 and later showdatestamp Boolean. Specifies whether or not to display date stamps in the chat transcript area. 7.5.1 and later showemoticons Boolean. Default is true. Specifies whether or not to display emoticons in the chat transcript. 7.5.1 and later usemyfont Boolean. Default is false. Specifies whether or not to override chat partner's font settings with my own. 7.5.1 and later entersend Boolean. Default is true. Specifies whether or not Enter is used to send a message or Shift+Enter. Enter sends, Shift+Enter newline 7.5.1 and later showstatusupdates Boolean. Default is false. Specifies whether or not to display status updates for my chat partner in the transcript. 7.5.1 and later esccloses Boolean. Default is true. Specifies whether or not ESC closes the chat window. 7.5.1 and later showuserleft Boolean. Default is false. Specifies whether or not to display a message when my chat partner closes their chat window. 7.5.1 and later warnWhenInMtg Boolean. Default is true. Specifies whether or not to pop a warning message when I try to open a chat window when a person is in a meeting. 7.5.1 and later warnWhenAway Boolean. Default is true. Specifies whether or not to pop a warning message when I try to open a chat window when a person is away. 7.5.1 and later dontPopWhenMin Boolean. Default is true. Specifies whether or not the chat window pops to the front when I manually minimize the window. 7.5.1 and later showActionBar Boolean. Default is true. Specifies whether or not to show the actions toolbar. 7.5.1 and later showStatusBar Boolean. Default is true. Specifies whether or not to show the status message bar at the bottom. 7.5.1 and later showToolsBar Boolean. Default is true. Specifies whether or not to show the message tools bar. 7.5.1 and later showSendButton Boolean. Specifies whether or not to show send button in the chat window. 7.5.1 and later showQuickFind Boolean. Specifies whether or not to show quick find in the tabbed chat window. 7.5.1 and later useTabs Boolean. Default is false. Specifies whether or not to use a single tabbed window for all chats. 7.5.1 and later horizontalTabs Boolean. Default is false (vertical). Specifies whether to use horizontal or vertical tabs. Does not apply unless useTabs is true. 7.5.1 and later warnNewMessageArrived Boolean. Default is true. Specifies whether or not to pop a message dialog when I try to close the window at the same time I am receiving a message. 7.5.1 and later warnNewMessageArrived Threshhold Long. Default is 450. It is used in conjunction with the warnNewMessageArrived preference. When warnNewMessageArrived is true, if set this to 10000 (10 seconds) and try to close chat window 5 seconds after the last message, the warning dialog will pop up. It is not recommended to change the default value. 7.5.1 and later useDefaultGO Boolean. Default is true. Specifies whether or not to use the system's default orientation for typing or to manually set one. 7.5.1 and later sendAreaGO Integer. Specifies which orientation to use in the typing area if useDefaultGO is false. Not set by default because useDefaultGO is true. Only accepts two values, 67108864 (SWT.RIGHT_TO_LEFT) or 33554432 (SWT.LEFT_TO_RIGHT) 7.5.1 and later timeformat Integer. Default is 12. Specifies the default time format to use (12 or 24 hour clock). 7.5.1 and later maxChatsShowWarn Boolean If using tabbed window, specifies whether or not to show a warning dialog when current chat count exceeds the predefined value. 7.5.1 and later maxChats Integer. Default is 50. Specifies a predefined value for maxChatsShowWarn 7.5.1 and later saveChats Boolean Specifies whether or not to save opened chats across sessions. 7.5.1 and later transcript.view.limit Integer. Default is 0. Specifies a limit to the number of text/graphics lines that are maintained in the chat window. Setting to 0 means no limit. 8.5 and later ProvideTabbedBrowser Cache Boolean. Default is true. Specifies whether when using tabbed chats if the browser window can be cached to improve memory when the chat is not active. 8.5.1 and later persistPosition Boolean Specify whether to remember the position of chat windows. If it is set, the chat window position is remembered each time on window close action and used as the default location for next chat window open action. 8.5 and later xpos Integer Specify the X value of chat window position. 7.5.1 and later ypos Integer Specify the Y value of chat window position. 7.5.1 and later windowWidth Integer Specify the width of chat window. 7.5.1 and later windowHeight Integer Specify the height of chat window. 7.5.1 and later sendAreaHeight Integer Specify the height of the input box of chat window. 7.5.1 and later replyWithOfflineMessageContent Boolean. Default is true. Specify whether or not to include the received message when replying to an offline message. 8.5.2 IFR1 and later disableInlineIME Boolean. Default is false. Specify whether or not to disable inline mode for an input method in the chat input area of a chat window. Apply this setting if there is problem with a specific input method, such as a Traditional Chinese Input Method Editor (IME). 8.5.2 IFR1 and later participantsViewPosition String. Specifies the location of the n-way chat participant list panel on either the side of the chat transcript area. 9.0 and later sortTabs Boolean. Default is false. Specifies whether or not to sort the chat tabs in a tabbed chat window. 9.0 and later sortOrder String. Default is two_way:n_way:chat_room Specifies the order of chat tab types, if the setting is true for sortTabs. The user can change the sort of if desired. 9.0 and later autoAcceptInvitation Boolean. Default is true. Allows invitee to automatically join a multi-person chat without clicking Accept when invited to join the chat. 9.0 and later allowOthersToSeeTranscript Boolean. Default is true. Allows new chat invitees to see the previous chat transcript when they join the chat. 9.0 and laterTable 5. RTC Adapter Plugin Preferences - com.ibm.collaboration.realtime.rtcadapter release 8.5.2 and later
Attribute Variable type Description Release disableRichText Boolean. Default is false. Specifies whether or not to disable rich text for all chats. 8.5.2 and later disableRichTextWithAnon Boolean. Default is false. Specifies whether or not to disable rich text for chats with anonymous users. 8.5.2 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_comm_pref.html","title":"Community preferences","text":"The following tables list the default community preferences and alternate community preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description kioskMode Boolean Kiosk mode allows multiple users to share the same client on the same computer. If set to true, the client deletes personal information after each user logs out. When this setting is enabled, the automatic login, password saving, and locally stored contacts list features are not available because they require the use of personal information. logoutWhenIdle Boolean Specifies whether the client should disconnect from the server (and log out the user) when idle. logoutWhenIdleOverride Boolean Provides a mechanism to override the user's logoutWhenIdle setting. If set to true, then the client will always logout when idle, and the user will not be able to change the value the Preferences settings. logoutWhenLocked Boolean Sets the initial value of whether or not the Embedded client logs out when Notes is locked (disconnected from the server). This preference only applies to new users. logoutWhenLockedOverride Boolean Provides a mechanism to override the user's logoutWhenLocked setting. If set to true, then the client will always logout when locked, and the user will not be able to change the value in the Preferences settings. tokenLoginOnly Boolean Specifies the whether to force login by token for the default community. Takes effect the next time that the client connects to the Community Server. host String Specifies the initial community host value. Takes effect the next time that the client connects to the Community Server. authServerUrl String Specifies the initial authentication server URL value for the default community. Takes effect the next time that the client connects to the Community Server. defaultAuthType String Specifies the authentication type for the default community. For user name and password authentication, this setting should be left empty. For Domino\u00ae Single Sign-On in the Embedded client, the value should be set to ST-DOMINO-SSO. For a SAML authentication community, the value should be set to SAML. keepAlive Boolean. Default is true. The keepAlive feature allows the client remain connected to the Sametime Community Server even when the user is inactive, so that the user remains logged in to Sametime. In the client, use the Server tab of the Preferences > Server Communities > community page to specify how often a keep-alive signal should be sent to the server. keepAliveInterval Integer. Default is 60. Specifies the initial keep alive interval value for the default community. Takes effect the next time that the client connects to the Community Server. loginByToken Boolean If set to true, the client will log in to the community using a token other than user name and password pair. For example, the Embedded client can use Domino Single Sign-On with the LTPA token, and the Connect client uses can use the SAML token. Takes effect the next time that the client connects to the Community Server. name String Specifies the initial name for the default community. Takes effect the next time that the client connects to the Community Server. port Integer. Default is 1533. Specifies the initial community port value. Takes effect the next time that the client connects to the Community Server. savePassword Boolean. Default is false. Specifies whether the user's password is saved for the default community. Takes effect the next time that the client connects to the Community Server. connectionType String. Valid values include direct, tls-direct, http-direct, socks4-proxy, socks5-proxy, http-proxy, https-proxy, reverse-proxy, useBrowserSettings. Specifies the connection protocol that is used when the client connects to the default community. Takes effect the next time that the client connects to the Community Server. proxyHost String Specifies the host name for the Sametime Proxy Server that browser clients connect to before accessing the Community server where the default community is hosted. Takes effect the next time that the client connects to the Community Server. proxyPort Integer Specifies the port number that listens for browser client connections on the Sametime Proxy Server used with the Community server where the default community is hosted. Takes effect the next time that the client connects to the Community Server proxyUserName String Specifies the initial proxy user name for the default community. Takes effect the next time that the client connects to the Community Server. proxyPassword String Specifies the initial proxy password for the default community. Takes effect the next time that the client connects to the Community Server. proxyResolvesLocally Boolean Specifies the initial proxyResolvesLocally value for the default community. Takes effect the next the time that the client connects to the Community Server. loginTokenRefreshInterval Integer. Default is 900000. Specifies the login token refresh interval in milliseconds. The default is 900000, or 15 minutes. samlTrustedSites String Specifies the URL of a trusted site for use with SAML authentication. Example:samlTrustedSites=url1,url2. Attribute Variable type Description altCommunityConfig.managedIds String Required. A comma-delimited set of IDs that represents each alternate community. For example, altCommunityConfig.managedIDs=altHost1,altHost2 defines two alternate communities named altHost1 and altHost 2. altCommunityConfig.altHost.altHostID.targetCommunityHost String Required. The host name of the alternate community. altHostID represents the ID you defined for the alternate community in the managedIds preference, such as altHost1. altCommunityConfig.altHost.altHostID.enabled Boolean. Default is true. Enables the alternate community configuration. altCommunityConfig.altHost.altHostID.weight Integer. Default is 0. The weight of the alternate community configuration relative to other alternate communities. The higher the value, the greater the weight. For example, a connection to an alternate community with a weight of 2 is tried before one with a weight of 0. Regardless of the assigned weight, the client attempts a connection to the last successful alternate community first. altCommunityConfig.altHost.altHostID.type String. The default is postDefaultConfig. Determines if the alternate community connection is tried before the default community or after. A value of postDefaultConfig attempts the connection after trying to connect to the default community. A value of preDefaultConfig attempts to connect to the alternate community first. altCommunityConfig.altHost.altHostID.attemptCount Integer. The default is 1. Sets the number of times the client attempts to connect to the alternate community before trying another community. altCommunityConfig.altHost.altHostID.fallbackOnly String By default, this preference is not set and the client attempts a connection to the last successful alternate community first. If you set the preference fallbackOnly for a specific alternate community, it will never be retried first, even if it was the last successful connection. altCommunityConfig.altHost.altHostID.host String Defines a secondary alternate community host to connect to if the host defined in the targetCommunityHost preference cannot be reached. For example, if the targetCommunityHost is im1.example.com, the host could point to im2.example.com. altCommunityConfig.altHost.altHostID.authServerUrl String Specifies the server URL for Single Sign-on authentication. altCommunityConfig.altHost.altHostID.authType String Defines the method used for Single sign-on authentication. Use TAM-SPNEGO for SPNEGO authentication or ST-DOMINO-SSO for Domino authentication within Notes. altCommunityConfig.altHost.altHostID.port Integer The port to use if other than the default 1533. altCommunityConfig.altHost.altHostID.connectionType String. Valid values include direct, tls-direct, http-direct, socks4-proxy, socks5-proxy, http-proxy, https-proxy, reverse-proxy. Determines how the client connects to the alternate community. The default is direct. altCommunityConfig.altHost.altHostID.proxyHost String Specifies the initial proxy host value for the alternate community. altCommunityConfig.altHost.altHostID.proxyPort Integer The port of the proxy. altCommunityConfig.altHost.altHostID.loginByToken Boolean Determines if the client logs in by token. If the token login fails and the password is available, the client attempts password-based authentication instead. tryLastSuccesfulConfigFirst Boolean. Default is true. Determines if the client first tries the alternate community it last connected to successfully. If you change the value to false, the client always attempts Connections to the alternate communities in the default priority order set in the managedIDs list, regardless of which alternate community connection was successful last. Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_connect_pref.html","title":"Selecting preferences in the client","text":"In the Preferences dialog of the HCL\u00ae Sametime\u00ae Connect Client and the Notes\u00ae client, users can choose any Sametime preferences that have not been locked by the administrator.
Log in to the client.
Depending on the client, open preferences:
Embedded in the Notes client - Click File > Preferences > Sametime.
In the Sametime Connect Client - Click the Actions and Preferences menu (the gear icon).
Select a feature in the features list.
Choose the preferred behavior for that feature, and then select Apply.
Select OK.
Any preferences set using this method can be overwritten by Sametime policies. Preferences set using this method are stored in the end-user's profile directory either within an XML document or a .pref file.
Parent Topic: Sametime client configuration options
"},{"location":"admin/config_client_contact_list_pref.html","title":"Contact list preferences","text":"The following table lists the contact list preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release sortGroups Boolean. Default is true. Specifies whether by default to alphabetically sort groups in the contact list. 7.5.1 and later sortContacts Boolean. Default is true. Specifies whether by default to alphabetically sort contacts in the contact list. 7.5.1 and later alwaysEditStatusMsgActive Boolean. Default is true. Specifies whether by default to always edit the status message when changing status to available. 7.5.1 and later alwaysEditStatusMsgAway Boolean. Default is true. Specifies whether by default to always edit the status message when changing status to away. 7.5.1 and later alwaysEditStatusMsgInMtg Boolean. Default is true. Specifies whether by default to always edit the status message when changing status to in a meeting. 7.5.1 and later alwaysEditStatusMsgDnd Boolean. Default is true. Specifies whether by default to always edit the status message when changing status to in a do not disturb. 7.5.1 and later showActionToolBar Boolean. Default is true. Specifies whether by default to show the action toolbar in the contact list window. 7.5.1 and later showStatusBar Boolean. Default is true. Specifies whether by default to show the status bar in the contact list window. 7.5.1 and later showQuickFind Boolean. Default is true. Specifies whether by default to show quick find in the contact list window. 7.5.1 and later flashAddedContacts Boolean. Default is true. Specifies whether by default to flash newly added contacts. 7.5.1 and later showAddDialogSuccess Boolean. Default is true. Specifies whether by default to open a confirmation dialog after a contact has been added. 7.5.1 and later showAddGroupSuccess Boolean. Default is true. Specifies whether by default to open a confirmation dialog after a group has been added. 7.5.1 and later showAddPartnerSuccess Boolean. Default is true. Specifies whether by default to open a confirmation dialog after a chat partner has been added (through add button in chat window). 7.5.1 and later autoSyncDefaultCommunity BuddyList|Boolean. Default is true.|Specifies whether by default to synchronize the 7.5 XML buddylist with the previous pre 7.5 contact list used by older clients. Windows\u00ae only.|7.5.1 and later| |launchAtStartup|Boolean|Specifies whether or not to launch Sametime at system startup. The preference is valid only for stand-alone clients and windows platform. If the preference is set it in plugin_customization.ini or managed preferences framework, it does not work for the first launch of the Sametime client.|7.5.1 and later| |hideWhenMinimized|Boolean. Default is true.|Specifies whether by default to hide the contact list window when minimized. The preference is valid only for the Sametime Connect Client for Microsoft\u00ae Windows.|7.5.1 and later| |showCommunityIconBackground|Boolean. Default is false.|Specifies whether by default to show the community icon behind the contacts.|7.5.1 and later| |statusImgBackgroundTransparency|Integer. Default is 60.|Specifies the transparency of the community background image. 0 is very prominent, 100 is completely transparent.|7.5.1 and later| |showHoverBizCard|Boolean. Default is true.|Specifies whether or not to show the business card when hovering over contacts.|7.5.1 and later| |hideContactsWhenOffline|Boolean. Default is false.|Specifies whether or not to hide the contact list tree when offline.|7.5.1 and later| |showBuddyListConflictDialog|Boolean. Default is true.|Specifies whether or not to show the contact list conflict dialog when synchronizing the remote contact list.|7.5.1 and later| |buddyListConflictPref|String. Default is merge.|Specifies the default behavior to follow in case of a remote/local synchronization conflict. Options include \"merge\", \"keepLocal\", and \"replaceLocal\".|7.5.1 and later| |warnWhenWatchLimitExceeded|Boolean|When the watch limit is in effect, specifies whether or not to warn user when the number of contacts that can be monitored is exceeded.|7.5.1 and later| |warnWhenContactLimitExceeded|Boolean|When \"LimitContactListSize\" policy is set, specifies whether or not to warn user when the contact list is approaching the maximum number allowed.|7.5.1 and later| |showShortNames|Boolean|Specifies whether or not to show short names for contact list.|7.5.1 and later| |alwaysOnTop|Boolean|Specifies whether or not to make the contact list window stay visible.|7.5.1 and later| |showOnlineOnly|Boolean|Specifies whether or not to show online contacts only in the contact list window.|7.5.1 and later| |showStatusToolBar|Boolean|Specifies whether or not to show My Status ToolBar in the contact list window.|7.5.1 and later| |showContactList|Boolean|Specifies whether or not to show the contact list in the contact list window.|7.5.1 and later| |confirmMultiPartyChatInvitation ToMoreThanX
|Boolean|Specifies whether or not to confirm when users start events with groups larger than a specified number of people. The number value is specified by confirmMultiPartyChatInvitationToMoreThanXNumber
.|7.5.1 and later| |confirmMultiPartyChatInvitation ToMoreThanXNumber
|Integer|Specifies a limit number. See confirmMultiPartyChatInvitationToMoreThanX
.|7.5.1 and later| |launchMinimized|Boolean.|Specifies whether or not to minimize Sametime when launching. It's valid only for stand-alone clients and windows platform.|8.5 and later| |limitPublicGroupSubscriptions
|Boolean. Default is true.|Takes contact list size of public groups into account to calculate the contact list size limit. The default value is true, which means that users cannot add a public group to their contact lists if doing so exceeds the contact list size. If users already have public groups in their contact lists, this preference causes the client to subscribe to each group in the list, from smallest to largest, until the limit is reached. Any other groups remaining in the contact list are shown as unsubscribed groups. Disabling a group subscription causes the client to add as many groups from the unsubscribed list as it can until the contact list size is reached again. Setting the value to false does not include the contact list size of public groups to calculate the contact list size limit.|8.5.2 and later| |maxPublicGroupSize
|Integer|The maximum number of contacts a public group can have that allows users to subscribe to it. Groups that exceed this size cannot be added to the contact list. If the group already exists in the contact list, users cannot subscribe to the group. You can set this preference when the limitPublicGroupSubscriptions preference is enabled.|8.5.2 and later| |excludedPublicGroups
|String|A comma-delimited list of public group names that should not be subscribed to (for example, employees_Active,employees_All). Groups in this list cannot be added to the contact list. If the group already exists in the contact list, users cannot subscribe to the group. You can set this preference when the limitPublicGroupSubscriptions preference is enabled.|8.5.2 and later| |allowExportContactList|Boolean , default value is false|Specifies whether to allow users to export their contact list. When set to false, the Export Contact List option does not display on the Manage Contact List menu..|9.0.1 and later|
Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_discontinue_xml_file.html","title":"Discontinuing managed preferences","text":"To stop setting preferences through the Expeditor managed settings framework, remove the reference to the managed-settings.xml or managed-community-configs.xml files and unlock any previously read-only settings.
Managed settings that were previously pushed to the clients as read-only will continue to be used until they are specifically removed from the client. Unlock all managed settings by editing the XML file:
Change all \"isLocked=true\" instances to \"isLocked=false\".
If the lastModDate atribute was used previously, change the lastModDate attribute to a newer timestamp for all group settings. Otherwise, skip this step.
Provision the updated XML file to the client.
Discontinue use of the settings.xml file based on the method you used to distribute managed preferences.
Method 1:
The managed-settings.xml or managed-community-configs.xml file hosted on a web server
Method 2:
The managed-settings.xml file defined in a plugin_customization.ini file.
Parent Topic: Updating client preferences with the managed-settings.xml file
"},{"location":"admin/config_client_ext_app_pref.html","title":"External application preferences","text":"The following table lists the external application preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Table 1. External application Preferences - com.ibm.collaboration.realtime.ui release 7.5.x and later
Attribute Variable type Description Release external.application.use.default.mail Boolean. Default is true. Specifies whether or to use default mail program for email. 7.5.1 and later AllowEMailFunction Boolean. Default is true. Provides a mechanism for disable/enable the mail function entries. If set to true, user can use mail function in Sametime client; if set to false, the menu/toolbar about mail function will be disabled. 8.0 and later external.application.use.custom.browser Boolean Specifies whether or not to use a custom browser on Linux\u00ae. 7.5.1 and later external.application.use.custom.mail Boolean Specifies whether or not to use a custom mail application on Linux. 7.5.1 and later external.custom.browser String Specifies the custom browser on Linux. 7.5.1 and later external.application.mail String. \"System Default\", \"Notes\", \"Evolution\", \"KMail\" and \"Thunderbird\" on Linux. \" Specifies the default mail application. 7.5.1 and later Notes\", \"Outlook Express\u2122\" and other available mail applications on Windows\u00ae. external.application.use.default.mail Boolean Specifies whether or not to use default mail application. 7.5.1 and later external.custom.mail String Specifies the user mail application on Linux. 7.5.1 and later disableHostnameWarning Boolean. Default is false. Specifies whether or not to validate that the server name is a fully qualified domain name. 8.5.1 and laterParent topic: Sametime client preferences
"},{"location":"admin/config_client_file_tran_pref.html","title":"File transfer preferences","text":"The following table lists the file transfer preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Table 1. File Transfer Preferences - com.ibm.collaboration.realtime.filetransfer release 7.5.x and later
Attribute Variable type Description Release allowTransferToAnonymous Boolean. Default is true. Specifies whether or not to disable file transfers to anonymous users. Setting the value to true does not prevent incoming file transfers from anonymous users. 8.5.2 and later saveFileLocation A text string of a valid full path to a folder on the user's computer. Specifies the path on the user's computer where files from File Transfers will be saved. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. Example using absolute path: 7.5.1 and latercom.ibm.collaboration.realtime.filetransfer/saveFileLocation=C:\\\\Documents\\\\user\\\\SametimeFileTransfer Releases 8.0.2 and later support the use of a relative path. Example using a path relative to the user profile folder for Windows\u2122 and Mac: com.ibm.collaboration.realtime.filetransfer/saveFileLocation=\\\\SametimeFileTransfer For Linux\u2122: com.ibm.collaboration.realtime.filetransfer/saveFileLocation=SametimeFileTransfer Parent topic: Sametime client preferences
"},{"location":"admin/config_client_location_pref.html","title":"Location preferences","text":"The following table lists the location preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release manualModeSelected Boolean Specifies whether or not to detect location changes automatically. 8.5 and later manualModeVisible Boolean Specifies whether the check box \"Do not automatically detect location changes\" is visible. 8.5 and later optIn Boolean Specifies whether or not to share user's location information with other users. 7.5.1 and later advancedView Boolean Specifies whether or not to show the advanced view for Location. 7.5.1 and later showProfWindow Boolean. Default is false. Toggle for do not show the alert for editing location settings at location change again. 7.5.1 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_login_pref.html","title":"Login preferences","text":"The following table lists the login preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Table 1. Login Preferences - com.ibm.collaboration.realtime.login release 7.5.x and later
Attribute Variable type Description Release autoLogin Boolean. Default is true. Specifies whether or not to enable the auto-login feature for clients. If this setting is enabled, users can choose whether to use the feature with the Automatically log in setting in the client. 7.5.1 and later enableAutoReconnect Boolean. Default is true. Specifies whether or not to enable automatic re-connection to the Sametime server in case the client is inadvertently disconnected. 7.5.1 and later autoReconnectAttemptInterval long. Default is 20000. Specifies the interval in milliseconds at which the client will attempt to reconnect. 7.5.1 and later autoReconnectAttempts long. Default is -1. Specifies the number of attempts to reconnect. The value -1 means to never stop trying. 7.5.1 and later verifyConnectionPriorToLogin Boolean. Default is true. Specifies whether or not to verify that a network connection is available before logging in. 7.5.1 and later notifyWhenNetConnLost Boolean. Default is true. Specifies whether or not to alert the user when the network connection is lost. 7.5.1 and later alwaysLoggedIn Boolean Keeps \"Automatically log in\" and \"Remember password\" disabled and checked and disables all \"Log out\" menu items. 7.5.1 and later disableExit Boolean Keeps the \"Exit\" menu items disabled. 7.5.1 and later disableHostName Boolean Sets edit state of host name text field on login dialog. 7.5.1 and later displayResetUserBtn Boolean Makes the reset button show or not on the login dialog. If the preference is set to true and 7.5.1 and later `com.ibm.collaboration. realtime.communit/host` is set to true, the reset button will automatically be disabled. allowSave Boolean Specifies whether or not to allow saving password. 7.5.1 and later earlyStartupLogin Boolean Specifies whether or not to show login dialog when the client starts. 7.5.1 and later resetUser Boolean. Default is false. Specifies whether or not to reset user information when the client starts. 7.5.1 and later displayAuthServerSSO Boolean. Default is true. Specifies whether or not to display Authentication server information in the community Log In tab. 7.5.1 and laterParent topic: Sametime client preferences
"},{"location":"admin/config_client_mng_xml_pref.html","title":"Configuring Sametime client preferences with the Expeditor managed settings framework","text":"You can configure and manage the user's Sametime client preferences for capable clients using the Expeditor managed settings framework. The Sametime clients that are Expeditor based include the Sametime client for Windows or Mac, and the HCL Notes embedded Sametime client for Windows or Mac. This excludes the PWA, web and mobile clients.
The Expeditor managed settings framework pulls preference settings from a managed-settings.xml and/or managed-community-configs.xml file hosted on a web server or as a part of the Samtime client installation package.
There are two methods to deploy the settings to the user.
Method 1:
The settings files are hosted on a web server and the URL to the files is defined in either location:
In the plugin_customization.ini file as part of the Sametime installation package. This option requires customization of the client installation package.
In the user's Sametime policy.
The managed-settings.xml file can be packaged with the Sametime installation package. This option requires customization of the client installation package.
The following topics explain how to configure and update settings using the Expeditor managed settings framework.
Parent Topic: Sametime client configuration options
"},{"location":"admin/config_client_notes_pref.html","title":"Notes preferences","text":"The following table lists the Notes\u00ae preferences that can be managed for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes.
Attribute Variable type Description Release install_directory String. Should be a valid path for Notes. Specify the Notes installation directory. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.calendar.notes.connector/install_directory=D:\\\\Notes 8.0 and later notes_password String Specify the Notes password 8.0 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_notification_pref.html","title":"Notification preferences","text":"The following table lists the notification preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release pref_alertbubble_window_corner String. Default is \"SE\". Four possible values, \"NE\", \"NW\", \"SE\", SW\" (corresponding to northeast, northwest, southeast, southwest). This stores one of four possible values, which indicate the corner of the user's screen where alert bubble will appear. 7.5.1 and later pref_alertbubble_window_width Positive integer value Stores the width in pixels of the alert bubble. 7.5.1 and later pref_alertbubble_window_height Positive integer value Stores the height in pixels of the alert bubble. 7.5.1 and later pref_alertbubble_window_ edge_padding|Positive integer value|Stores the number of pixels to add as horizontal padding for the alert bubble to separate it from the edge of the desktop.|7.5.1 and later| |pref_alertbubble_show|String value, \"standard\" = show standard OS window, \"less\" or others = show alert bubble for an alert|Determines whether to show the alert bubble or a standard OS window for an alert.|7.5.1 and later| |pref_alertbubble_close_alerts|Boolean. TRUE = automatically close alert, FALSE = do not automatically close alert|Determines whether to automatically close an alert after it appears.|7.5.1 and later| |pref_alertbubble_close_alerts_ delay
|Positive integer value|If alerts are set to automatically close, this is the delay amount in seconds before the alert is closed.|7.5.1 and later| |pref_alertbubble_animation|String value, \"none\" = no window animation, \"slide\" = animate using slide effect, and \"fade\" = animate using fade effect. The default value is \"slide\"|Specify the Alert bubble animation type.|7.5.1 and later| |pref_alertbubble_bring_window_ to_front
|Boolean|The default value, whether to Bring the Popup window to front.|7.5.1 and later| |pref_alertbubble_flash_taskbar|Boolean|The default value, whether to Flash the taskbar to indicate new Popup window.|7.5.1 and later| |pref_event_0_playsound|Boolean|Determines whether to play sound when a new chat window opens.|7.5.1 and later| |pref_event_0_playsound_response|Boolean|For one-on-one chat, determines whether to play sound on chat response.|8.5.2 and later| |pref_event_1_playsound|Boolean|For multi-party chats, determines whether to play sound when there is an invitation to a multi-party chat.|7.5.1 and later| |pref_event_1_playsound_response|Boolean|For multi-party chats, determines whether to play sound on chat response.|8.5.2 and later| |pref_event_2_playsound|Boolean|Determines whether announcement events play a sound.|7.5.1 and later| |pref_event_3_playsound|Boolean|Determines whether Invitations to Sametime Classic online meeting play a sound.|7.5.1 and later| |pref_event_6_playsound|Boolean|Determines whether status alert events (Alert me When) play a sound.|7.5.1 and later| |pref_event_7_playsound|Boolean|Determines whether Location Awareness events play a sound.|7.5.1 and later| |pref_event_0_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for one-on-one chat events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.alertmanager/pref_event_0_soundfile=C:\\\\Documents\\\\sound.wav ``
|7.5.1 and later| |pref_event_1_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for Invitations to multi-party chat events, if playing sounds is enabled for this event. Do no't use '\\' as the file separator. Use '\\\\' or '/' instead. For example, ``com.ibm.collaboration.realtime.alertmanager/pref_event_1_soundfile=C:\\\\Documents\\\\sound.wav
|7.5.1 and later| |pref_event_2_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for announcement events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.alertmanager/pref_event_2_soundfile=C:\\\\Documents\\\\sound.wav.
|7.5.1 and later| |pref_event_3_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for Invitations to Sametime Classic online meeting events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.alertmanager/pref_event_3_soundfile=C:\\\\Documents\\\\sound.wav ``
|7.5.1 and later| |pref_event_6_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for status alert events (Alert me When) events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.alertmanager/pref_event_6_soundfile=C:\\\\Documents\\\\sound.wav.
|7.5.1 and later| |pref_event_7_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for Location Awareness events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration. realtime.alertmanager/ pref_event_7_soundfile= C:\\\\Documents\\\\ sound.wav.
|7.5.1 and later| |pref_event_0_option_1|Boolean|For one-on-one chats, determines whether to bring chat window to front.|7.5.1 and later| |pref_event_0_option_2|Boolean|For one-on-one chats, determines whether to flash the taskbar to indicate new window.|7.5.1 and later| |pref_event_0_option_3|Boolean|For one-on-one chats, determines whether to show a system tray icon to indicate new message.|7.5.1 and later| |pref_event_0_option_4|Boolean|For one-on-one chats, determines whether to bring chat window to front on chat response.|8.5.2 and later| |pref_event_0_option_5|Boolean|For one-on-one chats, determines whether to flash the taskbar to indicate new message on chat response.|8.5.2 and later| |pref_event_0_option_6|Boolean|For one-on-one chats, determines, whether to show a system tray icon to indicate new message on chat response.|8.5.2 and later| |pref_event_1_option_1|Boolean|For invitations to multi-party chats, determines whether to bring invitation window to front.|7.5.1 and later| |pref_event_1_option_2|Boolean|For invitations to multi-party chats, determines whether to flash the taskbar to indicate new invitation.|7.5.1 and later| |pref_event_1_option_4|Boolean|For multi-party chats, determines whether to bring multi-party chat window to front on chat response.|8.5.2 and later| |pref_event_1_option_5|Boolean|For multi-party chats, determines whether to flash the taskbar on chat response.|8.5.2 and later| |pref_event_1_option_6|Boolean|For multi-party chats, determines whether to show a system tray icon on chat response.|8.5.2 and later| |pref_event_9_option_1|Boolean|For calls, determines whether to bring the invitation window to front.|8.5 and later| |pref_event_9_option_2|Boolean|For calls, determines whether to flash the taskbar to indicate new window.|8.5 and later| |pref_event_9_timeout_seconds|Integer, unit is second|For calls, specify the seconds before incoming invitation time out.|8.5 and later| |allow_response|Boolean|For Send Announcement dialog, determines whether to allow recipients to send responses.|7.5.1 and later| |pref_event_9_alert_incoming|Boolean|For calls, determines whether to display incoming invitation.|8.5 and later| |pref_event_10_playsound|Boolean|Determines whether calendar events play a sound.|8.5 and later| |pref_event_10_soundfile|Boolean|The sound file that will play for calendar events, if playing sounds is enabled for this event.|8.5 and later|
Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_people_pref.html","title":"People preferences","text":"The following table lists the people preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release lookupExpirationDays Integer. Default is 7. Specifies the number of days a users directory info is considered up to date. A value of 0 means refresh a user's directory info for each client session. 7.5.1 and later wrapBusinessCard Boolean. Default is true. Specifies whether or not to wrap text in business card 7.5.1 and later showNoPhotoPhoto Boolean. Default is true. Specifies whether or not to show a placeholder image in business card when user doesn't have a photo. 7.5.1 and later isCaseInsensitive Boolean. Default is false. Specifies if it is case insensitive when looking up people. The default of false means the search is case-sensitive. If you plan to set this to true, first turn off case sensitivity in the HCL Sametime Community server and restart the server. 7.5.1 and later userInfoReplacesDefaultDisplayName Boolean. Default is false. When set to true, contact names refresh automatically with the contact's business card name. When this preference is enabled, users can also update contact names manually. They can update one name by right-clicking a contact name and choosing Refresh Person Info. They can also update all names by selecting Tools > Refresh Contact Nicknames. For the preference to work, the person attributes in the LDAP directory used with the Sametime Community Server must meet the following requirements. Verify or change these settings by using the Sametime System Console to administer the Sametime Community Server. 7.5.1 and later Community Services tab - The attribute used for the internal user ID must be different from the attribute used for the person's display name. Business card tab - The attribute used for the business card name must be the same as the attribute used for the person's display name. refreshNicknamesOnFirstStartup Boolean. Default is false. Determines whether clients automatically replace all existing display names and nicknames in the contact list with business card names after clients start up and log in. You can set this preference when theuserInfoReplaces DefaultDisplayName preference is enabled. 8.5.2 and later Tip: To prevent the task from running each time you install on a new computer or reset the workspace, use managed preferences to set this preference temporarily for all new and upgrading clients. Disable the preference after all clients have run once. bizCardShowExtendedStatus Boolean. Default is false. Determines whether the extended status, such as phone call status, is displayed in the business card. The default setting is not to display all of the extended statuses in business card. 9.0 and later Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_pref_plugin.html","title":"Configuring Sametime Connect Client preferences in the plugin_customization.ini file","text":"Defining a settings file in the plugin_customization.ini file is an alternate method for distributing preferences to the Sametime\u00ae Connect Client. Unlike the managed-settings.xml file posted on an update site, this method does not provide any policy-based distribution of preferences.
Follow these steps to create a settings XML file and define it in the plugin_customization.ini file.
Create a settings XML file with a name such as managed-settings.xml.
Define preferences in the settings XML file.
Copy the settings XML file to the location where it will be called from the plugin_customization.ini file.
Add a key that defines the Expeditor Managed settings framework com.ibm.rcp.managedsettings.provider.file/URL and the name and location of the settings XML file to be used. For example:
com.ibm.rcp.managedsettings.provider.file/URL=http://www.example.com/managed-settings.xml\nor\ncom.ibm.rcp.managedsettings.provider.file/URL=file://c:/data/mananged-settings.xml\nSave the file and make it available to clients.
Every time the client starts, the plugin_customization.ini preferences are read.
Parent Topic: Configuring Sametime client preferences with the Expeditor managed settings framework
"},{"location":"admin/config_client_pref_tables.html","title":"Sametime client preferences","text":"This section lists the preferences that can be managed for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Parent Topic: Sametime client configuration options
"},{"location":"admin/config_client_rules_mng_pref.html","title":"Rules manager preferences","text":"The following tables list the rules manager preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release blockIncomingCalls Boolean. Default is true. Block all incoming calls. 8.5.1 and later rulesForComputerOnlyUsers Boolean. Default is true. Causes default rules to only apply for computer only users. 8.5.1 and later hideCallRoutingPrefs Boolean. Default is false. Hide the call routing preference pages. 8.5.1 and later disableRulesEditing Boolean. Default is true. Disable the ability to edit call routing rules. 8.5.1 and later disableOfflineCalling Boolean. Default is true. Disable ability for a computer only user to call an offline contact. 8.5.1 and later disableExternalCalling Boolean. Default is true. Disable ability for a computer only user to call an external contact or phone number. 8.5.1 and later disableNonComputerCalls Boolean. Default is true. Disable ability for a computer only user to call using anything other than their computer. 8.5.1 and later hidePreferredDevices Boolean. Default is false. Hide the preferred device list. 8.5.1 and later disablePreferredDevices Boolean. Default is true. Disable the preferred devices list. 8.5.1 and later hideAllocatedDevices Boolean. Default is true. Hide allocated devices so they cannot be used to answer calls or as a transfer target. 8.5.1 and later disablePreferredNumber Changes|Boolean. Default is true.|Disable the ability to add new preferred numbers.|8.5.1 and later| |replaceConditions|Boolean. Default is true.|Replace the users conditions with the defaults.|8.5.1 and later| |computerOnlyPrefix|String. Default is +999.|Unified number prefix which identifies a user as a computer only user.|8.5.1 and later| |callRoutingConditions|String. Default is /config/callRoutingConditions.xml
.|URL pointing to an XML file which defines the default call routing rules.|8.5.1 and later|
Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_spellchecker_pref.html","title":"Spell checker preferences","text":"The following table lists the spell checker preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release checkSpelling Boolean. Default is true. Specifies whether by default to check spelling as you type. 7.5.1 and later dictionaryLanguage String. Default is en-US. Specifies the default language to use for spellchecking. Must have corresponding dictionary installed. 7.5.1 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_stadv_pref.html","title":"Sametime Advanced preferences (Sametime 9.0.1 only)","text":"These settings only apply to environments that include the Sametime 9.0.1 Advanced Server.
The following table lists the preferences that are available for the HCL\u00ae Sametime\u00ae Advanced client. These preferences are set in the plugin_customization.ini file.
Table 1. Global Preferences - com.ibm.collaboration.realtime
Attribute Variable type Description enableAdvanced Boolean (default value is false) When the value is set to true, the Sametime Advanced plug-ins installed with the client become active. enableInstantShare Boolean (default value is false) If enableAdvanced is set to false, but the value of enableInstantShare is set to true, the instant share feature is available. Otherwise, the value of enableInstantShare is ignored.Table 2. Sametime Advanced Preferences - com.ibm.collaboration.realtime.persistentChat
Attribute Variable type Description showAdvancedVersioningAlert Boolean Suppress client version warnings when accessing a Sametime 9.0 (or higher) server from an older Connect or Embedded client.Table 3. Broadcast and Persistent Chat Preferences - com.ibm.collaboration.realtime.bcs
Attribute Variable type Description sametimeAdvancedServerName String Required. Fully qualified Apache Tomcat\u00ae Application Server host name, for example: sales. sametimeAdvancedServerPort String Required. Sametime Advanced Server port number. sametimeCommunityServer String Required. Default Sametime Community Server host name. This is the server users log in to for awareness and chat. broadcastToolsServerName String Required. Fully qualified Apache Tomcat Application Server host name. broadcastToolsServerPort String Required. Apache Tomcat Application Server port number. The port number is normally 1883 for HTTP and 8883 for SSL, but can be any port specified by the administrator. useHTTPS Boolean If you are using SSL while connecting to the server, set to true. If you are using HTTP set to false. advancedServerConnectionType String Connection type to connect to the Sametime Advanced server. Set to 0 for a direct connection to the server. Set to 1 to connect through a reverse proxy. broadcastServerConnectionType String Connection type to connect to the Broadcast Tools server. Set to 1 for a direct connection to the server. Set to 2 to connect using SSL. useHttpProxy Boolean Set to true if you are using an HTTP forward proxy; otherwise set it to false. proxyHost String Type the proxy IP address or host name if you are using a HTTP proxy, otherwise leave it blank. proxyPort String Type the HTTP proxy port to which you are connecting. proxyUserName String Type the user name if the HTTP proxy requires one for authentication; otherwise leave it blank. reverseProxyBaseURL String Type the reverse proxy base URL to use if connecting through a reverse proxy. For example: http://mycompany.example.com/mycontext Leave blank otherwise. reverseProxyUserName String Enter the reverse proxy user name if the proxy is authenticating. Leave blank if you are not using reverse proxies. jmsProtocol String Indicate whether the client connects with a secure connection using the Security Secure Sockets Layer (SSL) or not. The default is disthub (to connect without SSL). Enter disthubs to connect with SSL. liveNameResolveTimeout String (the default is 10000 milliseconds) Time allowed in milliseconds for awareness names to resolve. The default is 10000. notifyNewOpenCommunities Boolean (the default istrue ) Alert users when a new open community is created. notifyNewModeratedCommunities Boolean (the default istrue ) Alert users when a new moderated community is created. notifyNewPrivateCommunities Boolean (the default istrue ) Alert users when a new private community is created blockBroadcastOnDoNotDisturb Boolean (the default istrue ) Blocks broadcasts when client is set to \"Do not disturb\". blockBroadcastOnInMeeting Boolean (the default isfalse ) Blocks broadcasts when client is set to \"In a meeting\". notifyChatRoomAddMember Boolean (the default istrue ) Alerts users when a chat room has a new member. blockChatRoomNotifyOnDoNotDisturb Boolean (the default istrue ) Blocks chat room notifications the client to \"Do not disturb\". blockChatRoomNotifyOnInMeeting Boolean (the default isfalse ) Blocks chat room notifications when user is in a meeting. broadcastServerUserIdType String (the default isemail ) Specifies the LDAP attribute used as the user ID. useTokens Boolean (the default istrue ) Determines whether the client uses an LTPA token at login. Set this to false only if there is no way to set up Single Sign-On between the Sametime Community Server and the Sametime Advanced Server. chatRoomLaunchURLRichClient Boolean Specifies what type of chat room window the users sees. The value true represents the Sametime client chat room and the value false represents the web browser chat room. onlyActiveChatRooms Boolean (default value is false) Limits the chat room list to active chat rooms, suppressing disabled and archived chat rooms from the list. showToolTip Boolean (default value is true) Displays the description associated with a chat room when the user mouses over the chat room name. updateInterval String (default value is 600000 milliseconds, or 10 minutes) Specifies the wait (in milliseconds) before chat room data is refreshed. You can improve server performance by refreshing less frequently.Table 4. Community Preferences - com.ibm.collaboration.community
Attribute Variable type Description loginTokenRefreshInterval String (default value is 900000 milliseconds, or 15 minutes) LTPA token timeout in seconds. Best practice is to set this value to 5 minutes less than the token expiration time configured on the WebSphere server hosting Sametime Advanced, and on the Community Server. The value should be specified in milliseconds. For example, if the server-side token expiration timeout is 24 hours, configure loginTokenRefreshInterval=86100000 (which is 23 hours and 55 minutes) on the client.Parent topic: Sametime client preferences
"},{"location":"admin/config_client_status_pref.html","title":"Auto-status change preferences","text":"The following table lists the auto-status change preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release lockPCWithOSLock Boolean. Default is true. Available \"Locking computer with operating system lock\" feature. 7.5.1 and later keyboardMouseInactivity Boolean. Default is true. Available \"Keyboard and mouse inactivity\" feature. 7.5.1 and later whenIamInAOnlineMtg Boolean. Default is false. Available \"When I am in an online meeting\" feature. 7.5.1 and later selectStatusOnlyScreenShare Boolean. Default is false. Determines whether to select the \"Change my status only when I'm sharing my screen\" check box. 7.5.1 and later autoChangeMyStatusInMtg Boolean. Default is false. Determines whether to select the \"Automatically change my status\" radio button. Note that if this radio button is set as true, then the \"Prompt me before changing my status\" radio button will be UNavailable. If this is set as \"false\", the \"Prompt me before changing my status\" radio button will be available. After 7.5.1 and latercom.ibm.collaboration. realtime.imhub/ selectStatusOnly ScreenShare is set to true com.ibm.collaboration. realtime.imhub/ autoChangeMyStatus InMtg works for screen share status. minutesForIdleKeyboardMouse Integer. Default is 20 Sets the \"When I have not used my keyboard or mouse for the following number of minutes:\" text field. 7.5.1 and later backWhenUnlocked Boolean. Default is true. Determines whether to select the \"Return to previous status when activity is resumed\" in \"Locking computer with operating system lock\" check box. 7.5.1 and later backWhenKeyboardMouseActive Boolean. Default is true. Determine whether to select the \"Return to previous status when activity is resumed\" in \"Keyboard and mouse inactivity\" check box. 7.5.1 and later blRetrievalRetryDelay Integer. Default is 15000 ms. Determines how long the client waits before trying again to retrieve the contact list from the storage service if the initial attempt times out. The default is 15 seconds, expressed as milliseconds. 8.5.2 IFR1 and later Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_update_interval_xml.html","title":"Changing the update interval for managed preferences","text":"To change the update interval for managed preferences, you can update the existingmanaged-settings.xml file.
By default, managed settings are updated every 12 hours and when the HCL\u00ae Sametime\u00ae Connect Client is started. To change the update interval, add a new setting group to the managed-settings.xml file.
Edit the managed-settings.xml file.
Add a new setting group that contains the UpdateIntervalInMins setting.
Verify that the following settings are set:
value : Specify the interval value in minutes. For example, for an update to occur every hour, specify value=\"60\".
isLocked : The value for this setting must be isLocked=\"false\".
<settingGroup name=\"com.ibm.rcp.managedsettings\"> \n <setting name=\"UpdateIntervalInMins\" value=\"interval\\_value\" isLocked=\"false\"/>\n</settingGroup>\nFor additonal information on the isLocked setting, seeDefining preferences in the managed-settings.xml file.
Parent Topic: Updating client preferences with the managed-settings.xml file
"},{"location":"admin/config_client_update_pref.html","title":"Update preferences","text":"The following table lists the update preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release firstTimeRestartDelayMinutes Integer. Default is 0. Defines how long to delay for the first prompt after an automatic update is completed. Prompts immediately by default. 8.5.2 and later restartAction restart.now - user is presented with a restart dialog with Restart Now button only.restart.now.or.later - user is presented with a restart dialog with Restart Now and Wait x minutes buttons.
restart.on.next.login - user is presented with an info message that the plug-in updates will be effected on next restart.
restart.now.no.prompt - the client is restarted automatically when update is completed without any user interaction.
Default is restart.now.or.later.
|Defines how restart should be initiated on the client after an update is completed. Note this preference is just valid for administrator-initiated updates, but be invalid for user's manual updates by Tools -> Plug-ins menu.|8.5 and later| |restartRemindDelayMinutes|Integer. Default is 5.|Defines how long to delay the restart of the client after an update is completed. This setting is ignored if restartAction is set to restart.now or restart.on.next.login.|8.5 and later|
Example entry in plugin_customization.ini:
com.ibm.collaboration.realtime.update/restartAction=restart.now.no.prompt\ncom.ibm.collaboration.realtime.update/restartRemindDelayMinutes=1 \nParent Topic: Sametime client preferences
"},{"location":"admin/config_client_url_xml_file.html","title":"Changing the URL for the settings XML file in the plugin_customization.ini file","text":"If you must change the URL for the managed settings file, do so by updating the plugin_customization.ini file.
Follow these steps to update the plugin_customization.ini file with the new file name or URL.
Verify that the settings XML file is in the location where it will be called from the plugin_customization.ini file.
In the plugin_customization.ini file, change the key that defines the Expeditor Managed settings framework and the name and location of the settings XML file.com.ibm.rcp.managedsettings.provider.file/URL and the name and location of the settings XML file to be used. For example:
com.ibm.rcp.managedsettings.provider.file/URL=http://sametime.example.com/demo/managed-settings.xml\nor\ncom.ibm.rcp.managedsettings.provider.file/URL=file://c:/data/managed-settings.xml\nThe next update runs with the old URL, but subsequent updates run with the new URL. If the new URL is not reachable at the time of the update, the setting will not be saved and the original URL will continue to be used. The URL will not be changed until it is updated at a time that the URL can be reached.
Parent Topic: Configuring Sametime Connect Client preferences in the plugin_customization.ini file
"},{"location":"admin/config_client_widg_pref.html","title":"Live Text and Widgets preferences","text":"The following scenarios show the Live Text and Widgets preferences for the HCL\u00ae Sametime\u00ae Connect Client. These scenarios apply to setting preferences for the stand-alone client.
Case 1 (default): Disable both Live Text and Widgets
This is the default scenario, set with the following preference in plugin_customization.ini:
com.hcl.rcp.toolbox.admin/toolboxvisibleMaster=false
Case 2: Enable both Live Text and Widgets
Enable both Live Text and Widgets by setting the following preference to true in plugin_customization.ini:
com.hcl.collaboration.realtime/enableSametimeLiveText=true
Note: This overrides the setting for toolboxvisibleMaster. You do not need to manually set toolboxvisibleMaster to true.
Case 3: Enable only Live Text, not Widgets
To enable only Live Text, managed preferences is required. Configure the following managed preferences:
<ManagedSettings>\n<settingGroup name=\"com.hcl.collaboration.realtime\">\n<!-- Enable live text support in Sametime -->\n<setting name=\"enableSametimeLiveText\" value=\"true\" isLocked=\"false\"/>\n</settingGroup>\n<settingGroup name=\"com.hcl.rcp.toolbox.admin\">\n<!-- Disable widget support in Sametime -->\n<setting name=\"toolboxvisible\" value=\"false\" isLocked=\"true\"/>\n<setting name=\"toolboxenableRecognizers\" value=\"true\" isLocked=\"true\"/>\n</settingGroup>\n</ManagedSettings>\nCase 4: Enable only Widgets, not Live Text
To enable only Widgets but not Live Text, managed preferences are required. Configure the following managed preferences:
<ManagedSettings>\n<settingGroup name=\"com.hcl.collaboration.realtime\">\n<!-- Disable live text support in Sametime -->\n<setting name=\"enableSametimeLiveText\" value=\"false\" isLocked=\"false\"/>\n</settingGroup>\n<settingGroup name=\"com.hcl.rcp.toolbox.admin\">\n<!-- Enable widget support in Sametime -->\n<setting name=\"toolboxvisible\" value=\"true\" isLocked=\"true\"/>\n<setting name=\"toolboxvisibleMaster\" value=\"true\" isLocked=\"true\"/>\n<setting name=\"toolboxenableRecognizers\" value=\"false\" isLocked=\"true\"/>\n</settingGroup>\n</ManagedSettings>\nParent topic: Sametime client preferences
"},{"location":"admin/config_client_xml_file.html","title":"Defining preferences in the managed-settings.xml file","text":"Follow these instructions to define preferences in a managed-settings.xml file.
All rules related to XML files apply. Additionally, the following items should be considered:
There is an example managed-settings.xml file attached to the troubleshooting article which can be used to test managed settings in place of creating a new one.
This procedure demonstrates how to create the managed-settings.xml and define chat history preferences for enabling automatically save chats for 7 days.
Procedure
Create a new file with UTF-8 encoding named managed-settings.xml.
Note: No other file names are supported.
Place the opening and ending statements in the file:
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n\n\n</ManagedSettings>\nIn between the <ManagedSettings> tags is where the settings must be defined. Thus the last line of the file should be </ManagedSettings>.
Review the settings that can be defined. For this example, the chat logging preferences should be changed.
Note: You can define other settings. This example is to only demonstrate the syntax.
Place the settingGroup tags in between the <ManagedSettings> tags.
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"\"> \n\n\n\n</settingGroup> \n\n</ManagedSettings> \nOn the preferences documentation pages, some tables provide the names of the settingGroup. For example, in the Chat Preferences, table 2 is for Chat History Preferences. The settingGroup name is com.ibm.collaboration.realtime.chat.logging. The settings that are used for this example are \u201cdays.storage.max\u201d and \u201clogging.default\u201d. These configure the user\u2019s client to automatically log all chats on the client-side and retain them for 7 days.
Place the name of the settingGroup in the <settingGroup name=\u201d\u201d> tag.
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\"> \n\n\n\n</settingGroup> \n\n</ManagedSettings> \nWhen you define the settings which are placed inside the settingGroup tags, there are several options. Refer to the table for the setting name.
In the example from above, the two settings used in the example are \u201cdays.storage.max\u201d and \u201clogging.default\u201d. These are defined in a tag called <setting name=\u201d\u201d value=\u201d\u201d/>. These lines are indented with two spaces.
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\"> \n\n <setting name=\u201dlogging.default\u201d value=\u201d0\u201d/> \n\n <setting name=\u201ddays.storage.max\u201d value=\u201d7\u201d/> \n\n</settingGroup> \n\n</ManagedSettings> \nYou can define settings from other settingGroups in the same file. Ensure that the formatting of spacing remains the same. For example, add a contact list preference to sort groups alphabetically by default. These settings are documented in the Contact list preferences topic.
Open the help center topic and locate the settingGroup name.
Locate the setting name.
Add the new settingGroup and setting names below the first settingGroup.
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\"> \n\n <setting name=\u201dlogging.default\u201d value=\u201d0\u201d/> \n\n <setting name=\u201ddays.storage.max\u201d value=\u201d7\u201d/> \n\n</settingGroup> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.imhub\"> \n\n <setting name=\u201dsortGroups\u201d value=\u201dtrue\u201d/> \n\n</settingGroup> \n\n</ManagedSettings> \nEnable optional features.
The settingGroup tag has an attribute called lastModDate which when present every change to a setting group must also be accompanied by a change to the lastModDate attribute or the new values are not updated. If you do not use the lastModDate attribute, the values are always updated, even if they are not new.
The format for the lastModDate value uses java.text.SimpleDateFormat timestamp format. The syntax is
YYYYMMDDThhmmss\n, where YYYY=year, MM=month, DD, hh=hours, mm=minutes, and ss=seconds. The values following the T are optional.
For example:
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\" lastModDate=\u201d2021-02-11T17:39:21-05\u201d> \n\n <setting name=\u201dlogging.default\u201d value=\u201d0\u201d/> \n\n <setting name=\u201ddays.storage.max\u201d value=\u201d7\u201d/> \n\n</settingGroup> \n\n</ManagedSettings> \nEach <setting> tag can have the following optional attributes:
isLocked : Boolean. The default value is true. If true, the setting is read-only and any changes that a user or application make to the value set by you, the administrator, are prevented or later overwritten. If this attribute is set to false, the administrator's setting is treated as a default value that can be changed by the user.
``` {#codeblock_i5l_5fp_jzb}\n<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\"> \n\n <setting name=\u201dlogging.default\u201d value=\u201d0\u201d isLocked=\u201dfalse\u201d/> \n\n <setting name=\u201ddays.storage.max\u201d value=\u201d7\u201d isLocked=\u201dtrue\u201d/> \n\n</settingGroup> \n\n</ManagedSettings> \n```\n\nIn the above example, all chats are saved automatically initially until the user changes the setting, and the chat history is retained for 7 days. Users are not able to change this setting because it is locked.\noverwriteUnlocked : Boolean. The default value is false. By default, a setting that is specified as being unlocked is treated as a default and would not overwrite any existing value on the client. This is to avoid undoing changes that the user might have legitimately made. However, if this setting is set to true, the unlocked value is overwritten with this new value even if it means clearing the user's existing value.
overwriteUnlocked : Boolean. The default value is false. By default, a setting that is specified as being unlocked is treated as a default and would not overwrite any existing value on the client. This is to avoid undoing changes that the user might have legitimately made. However, if this setting is set to true, the unlocked value is overwritten with this new value even if it means clearing the user's existing value.
restartRequired : Boolean. The default value is false. This attribute applies only when you automatically update client preferences with the managed-settings.xml file. Setting this to true creates a user prompt to restart the client as soon as the managed setting is applied. Use this optional attribute only if a restart of the client is required to activate the preference. The restart occurs only if the setting that includes this attribute is updated.
Test the managed-settings.xml file for formatting errors. Open the file in a web browser and ensure that there are no syntax errors. If errors are present, edit the file and correct the syntax problem.
Deploy managed-settings.xml or managed-community-configs.xml file to a web server.
Parent Topic: Updating client preferences with the managed-settings.xml file
"},{"location":"admin/config_client_xml_location.html","title":"Updating client preferences with the managed-settings.xml file","text":"Sametime rich clients such as the embedded Sametime client in HCL Notes and the full Sametime standalone client are based upon the Eclipse framework. These clients can process a managed-settings.xml file to receive new or updated preferences automatically. The managed-settings.xml file is policy based, and each policy can define a different xml file to apply preferences to different groups of users.
Use a managed-settings.xml file to manage and define client preferences. The file is hosted on a web server. At login time, the client receives policies then checks for the existence of the managed-settings.xml file according to the \"Sametime\u00ae update site URL\" policy.
For example, if the configured URL is http://example.com/updates, the client looks for updated preferences in http://example.com/updates/managed-settings.xml.
The managed-settings.xml file can override and control any client preference, including hidden configuration preferences and preferences in the client user interface. Many preferences can also be set as read-only by specifying a locked=\"true\" attribute for the preference.
The client settings which can be managed using managed-settings.xml are listed in Sametime client preferences as well as its subtopics.
There is a separate configuration file: managed-community-configs.xml which is used to manage or change client connectivity and connection preferences. See the topic: Updating connectivity settings with the managed-community-configs.xml file.
Note: Sametime embedded clients for Notes can also be managed through the Domino\u00ae Desktop policy settings document.
Follow these steps to create and post a managed-settings.xml file.
Create a settings XML file and save it as managed-settings.xml.
Define preferences in the settings XML file.
Place the managed-settings.xml file on a web server to host the file.
Update the Sametime Policy for the user in the policies.user.xml file.
Changes take effect the next time the user starts Sametime. Settings found in the managed-settings.xml take precedence over matching settings in the plugin_customization.ini file.
To test changes in a managed-settings.xml file, create a policy set that includes the administration update site URL and place the .xml file in the location specified by the update site URL. Apply the policy to yourself and log in to the client to verify the preferences.
To troubleshoot managed settings, see Troubleshooting Sametime Managed Settings.
Parent Topic: Configuring Sametime client preferences with the Expeditor managed settings framework
"},{"location":"admin/configuration_files.html","title":"Configuration files","text":"Configuration files maintain information used by the Sametime server for various reasons.
Override the defaults of the Sametime community container or pod.
In Sametime v12, configuration files are generated on demand based on information in the Docker or Kubernetes container management configuration file.
File Name Environment Description sametime.ini Kubernetes Docker Sectioned configuration file used by the Sametime server. It is generated on demand based on values in custom.env or values.yaml files. Settings can be over-ridden if needed. Note: The file must conform to the XML syntax rules. StCommunityConfig.xml Kubernetes Docker Contains LDAP settings and more. Note: In versions previous to V12 this file was named stconfig.nsf. UserInfoConfig.xml Kubernetes Docker Contains configuration data for business cards. Note: The file must conform to the XML syntax rules. Policies.server.xml Kubernetes Docker Policies.user.xml Kubernetes Docker Clustering KubernetesNote: In releases prior to version 12, there are several configuration files used by different Sametime servers.
Configuration values can be modified. Where a modification can be done it is covered in the appropriate topic. For example, updates to LTPA keys are covered in the Setting up SSO using LTPA topics.
Parent Topic: Administering
"},{"location":"admin/configuring.html","title":"Configuring","text":"This section provides information on configuring the HCL Sametime server. Configuration tasks are dependent on the deployment environment.
Sametime supports LDAP directory servers as the user repository.
The default LDAP configuration works for most environments. The settings are based on an Domino LDAP deployments that has not been modified. If using another LDAP environment, you might need to override the default settings.
You can customize how the Sametime server interacts with LDAP by modifying the StCommunityConfig.xml file located in the Community container. The UserInfoConfig.xml file also contains LDAP settings that can be customized for business cards.
For LDAP security, see the security section of the help center.
Note that when modifying XML files, it is important to keep the indentation preserved and not use any illegal XML characters including in passwords. Do not use copy and paste into the XML files, it might corrupt the files.
When using the StCommunityConfig.xml and UserInfoConfig.xml files to override default setting, the LDAP bind credentials are stored in these files. If the bind account password changes, these files need to be updated too. To change the bind password in these files, see Changing the LDAP service account password in Kubernetes.
You can customize the following:
The following table describes the configuration settings.
Setting Description Default setting DirRefreshInterval The amount of time users and groups are refreshed. The refreshed data is maintained in a cache. This cache can be a resource intensive operation for large directories and can be adjusted to happen at a less frequent interval. For example, if you have more than 200,000 entries in the directory, consider changing this to 240 minutes. 60 minutes ConfigRefreshInterval The amount of time that lapses before policy, sametime.ini, UserInfoConfig.xml and StCommunityConfig.xml files are re-read. There is typically no need to change this setting. 60 minutes Connection HostName The fully qualified host name of the LDAP server. If you are using a cluster, it is recommended to place a load balancer in front of the cluster and use the load balancer host name or IP address. The value for this setting is obtained from the values.yaml file. It is placed there when prompted during the prepareDeployment script. OrganizationName Do not specify. This setting is deprecated. Do not change. Note: Specifying a value might prevent users from logging in successfully. Port The unsecured LDAP port, if you are using an unsecure connection to LDAP. If an unsecured LDAP is specified when running prepareDeployment.sh, the port specified at the script prompt is used. If secure LDAP was specified, the default value is 1389. BindEntryDn The LDAP Bind account name, which can be in DN or email format. This is blank unless a value is provided during the prepareDeployment.sh, and then it is retrieved from the sametime-global-secrets. BindEntryPassword The password for the BindEntryDn. Blank or retrieved from sametime-global-secrets. SSLEnabled 0 Turn off SSL. The value for this is provided during prepareDeployment.sh and is pulled from values.yaml file. 1 Turn on SSL. SSLPort The LDAP secure port. The well-known port is 636, but some LDAP services use a proprietary port. This selection is made during the prepareDeployment.sh and is pulled from the values.yaml file. SearchOrder The order in which LDAP directories are searched. Do not change this value unless you have more than one LDAP server to configure. Each search order must be unique. PersonResolveBase The base DN used for searching users. If users are in a specific OU, you can list that OU and Sametime begins searching there. For example, if users are in OU=users,O=example, you can set this as your PersonResolveBase. None. The entire directory is searched. PersonResolveFilter The filter used to search LDAP when a user searches with Quickfind. (&(objectclass=organizationalPerson)(|(cn=%s*)(givenname=%s*)(sn=%s*)(mail=%s*))) PersonResolveScope The scope of the search. 'recursive (searches nested OUs)' recursive Search the entire directory recursively starting at the base DN. onelevel Search the base DN and not search OUs. GroupResolveBase The base DN for searching groups. For example if your groups are in a specific OU, you can list that OU and Sametime will begin searching there. For example if your groups all exist in OU=groups,O=example, you can use that as a base DN. None Note: Domino LDAP groups are flat and you should not use a GroupResolveBase if using Domino LDAP. GroupResolveFilter The filter used to resolve a group name to a group. The name of the objectClass used by Domino uses for groups is groupOfNames. Other LDAP providers might use a different name, such as groupOfUniqueNames. This filter is used when clients add groups to contact lists, or when Sametime clients calculate their policy. (&(objectclass=groupOfNames)(cn=%s*)) GroupResolveScope The scope of a search. recursive recursive Search all nested OUs. onelevel Searchonly the base DN. UserIdAttribute Defines the Sametime ID. The DN is used as the default NameAttribute The attribute used to display the user\u2019s name in meetings, chat and business cards. cn DescAttribute This setting is not used and should be left blank. None, do not change. GroupNameAttribute The name of the attribute that holds the group\u2019s name. cn PersonObjectClass The object class that defines a person in the LDAP directory. organizationalPerson GroupObjectClass The object class that defines a group in the LDAP directory. groupOfNames HomeServerAttribute Does not apply to version 12.0 and higher deployments. None UserDnSearchFilter The filter to resolve a user to a unique DN. Use this to customize how Sametime searches and finds a user and resolves them to their DN. \"(&(objectclass=organizationalPerson)(|(cn=%s)(givenname=%s)(sn=%s)(mail=%s)))\" GroupMemberAttribute The name of the attribute that holds the members of a group. Member EmailAttribute The name of the attribute that holds the email address. Mail GroupMembership The resolve filter used by policies to determine if a user is a member of a group. It might be more performant to change this to the memberOf attribute in lieu of a search. \"(&(objectclass=groupOfNames)(member=%s))\"Parent Topic: Configuring
"},{"location":"admin/configuring_ldap_kubernetes.html","title":"Overriding the default LDAP configuration in Kubernetes","text":"Configuration settings can be overridden using the extra-community-config secret.
You can override the default LDAP configuration settings with the StCommunityConfig.xml file and UserInfoConfig.xml file using a secret called extra-community-config.
If you do not need to modify the UserInfoConfig.xml file it does not need to be included in the secret If you need to modify the UserInfoConfig.xml file, you must also include the StCommunityConfig.xml file as well.
Create a directory on your machine called extra-community-config at the root of where the Sametime installation package was decompressed.
Change to the extra-community-config directory.
Find the Community pod name by running the get pods command.
The pod name has hashes in it. For example: community-77d4695988-2bzrx.
kubectl get pods\nPull a copy of the StCommunityConfig.xml from the Community pod by running the below command, where podname is the pod name found in the previous step.
kubectl exec -it podname --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nFor example, if the Community pod name is community-845d5d5755-z7zf7, the command to run is
kubectl exec -it community-845d5d5755-z7zf7 --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nPull a copy of the UserInfoConfig.xml file from the Community pod, by running the below command. Substitute the name of your Community pod for podname.
kubectl exec -it podname --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml \nFind the base64 encoded value of your bind credentials. If you are using an authenticated bind, issue the following command in a Linux shell that contains your user name and password separated by a colon.
The resulting value is used in a later step.
echo -n \u201cusername:password\u201d | base64 -d\nIf the Bind DN is CN=bind,O=Example and the password is password, then the command is:
echo -n \u201cCN=bind,O=Example:password\u201d | base64 -d \nOpen the local copy of the UserInfoConfig.xml for editing.
Update the configuration settings.
Configure the desired custom settings in the StCommunityConfig.xml and UserInfoConfig.xml files. See Configuring LDAP for configuration settings.
Use the Change Directory command to change to the extra-community-config directory that was created earlier. Run the following command to create the secret.
kubectl\u202fcreate secret generic extra-community-config --from-file=./ \nIf you have a namespace dedicated to Sametime add the -n argument with your namespace to ensure it is created in the correct namespace.
Change to the helm directory where the Sametime installation package was decompressed.
Open the values.yaml file and place in edit mode. Add the following line.
overrideCommunityConfigSecret: extra-community-config\nSave and close the file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Configuring LDAP
"},{"location":"admin/configuring_ldap_multiple_docker.html","title":"Configuring additional LDAP servers on Docker and Podman","text":"You can configure the Sametime server to connect to two or more LDAP servers.
When you connect to more than one LDAP server, it is important for the names to be unique. If you are trying to achieve high availability to the same directory, use a load balancer to front-end the connection between the multiple LDAP servers.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
When more than one LDAP is defined in an environment, they are searched in the order defined in the StCommunityConfig.xml and UserInfoConfig.xml files. When you define each LDAP server, the order in which they are listed in the configuration is the same order in which they are searched.
The process described in this procedure involves copying the StCommunityConfig.xml and UserInfoConfig.xml files from the Sametime community (chat) container. These copied configurations overrides the default LDAP configuration settings. The LDAP servers are defined within each configuration file.
Docker-compose commands are used to pull the existing configuration files from the Sametime server to your local machine. Modify these files locally with the required settings, then add a volume under the community section of the docker-compose.yml file to enable the modified settings.
This procedure is to configure Sametime to connect to two or more separate LDAP servers that have unique names.
Change to the sametime_installation_directory directory.
Identify the chat-server container ID by running the command 'docker container ls' and finding the chat-server IMAGE. The NAME is the container name, as an example: sametime-community-1.
Pull a copy of the StCommunityConfig.xml and UserInfoConfig.xml from the chat-server container by running the below command, where container_name is the container name for the chat-server identified in step 2.
docker cp <container_name>:/local/notesdata/UserInfoConfig.xml . \ndocker cp <container_name>:/local/notesdata/StCommunityConfig.xml .\nFind the base64 encoded value of your bind credentials. If you are using an authenticated bind, issue the following command in a Linux shell that contains your user name and password separated by a colon. The resulting value is used in a later step.
echo -n \u201cusername:password\u201d | base64 -d\nIf the Bind DN is CN=bind,O=Example and the password is password, then the command is:
echo -n \u201cCN=bind,O=Example:password\u201d | base64 -d \nOpen your local copy of the UserInfoConfig.xml file for editing.
Duplicate the line that begins with StorageDetails.
The order in which you list your StorageDetails statement is the search order to be used.
HostName : The fully qualified host name or IP address of the second LDAP server.
Port : If using unsecured LDAP, specify the port number used by LDAP. If you are using secure LDAP, you don't need to modify this field.
UserName : Set this field to empty double-quotes ( \u201c\u201d ).
Password : Set this field to empty double-quotes (\u201c\u201d). If using an authenticated bind, add a new parameter after UserName and Password called UserEncodedAuth= and set it to the value that was determined in a previous step.
BaseDN : Define a base DN for searching the directory. If left blank, the entire directory is searched.
SearchFilter : SearchFilter Modify the search filter if needed. The defaults work well with Domino LDAP.
You can make other changes to the business cards configuration if needed at this time.
When finished, save and close the UserInfoConfig.xml file.
Edit the StCommunityConfig.xml file with a text editor and make the following changes.
Within the <LDAP> section, duplicate the line that begins with <Connection Hostname.
Modify the new line to contain the details of the second LDAP server.
Modify the SearchOrder parameter for the additional LDAP server to a unique number. This must match the search order you selected for UserInfoConfig.xml.
Save and close the StCommunityConfig.xml file.
Edit the docker-compose.yml by adding the following under the community section:
volumes:\n - ./StCommunityConfig.xml:/local/notesdata/StCommunityConfig.xml\n - ./UserInfoConfig.xml:/local/notesdata/UserInfoConfig.xml \nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Configuring LDAP
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html","title":"Configuring additional LDAP servers on Kubernetes","text":"You can configure the Sametime Community pod to connect to two or more LDAP servers.
When you connect to more than one LDAP server, it is important for the names to be unique. If you are trying to achieve high availability to the same directory, use a load balancer to front-end the connection between the multiple LDAP servers.
When more than one LDAP is defined in an environment, they are searched in the order defined in the StCommunityConfig.xml file. When you define each LDAP server, the order in which they are listed in the configuration is the same order in which they are searched.
The process described in this procedures involves creating a new secret called extra-community-configs. This secret overrides the LDAP configuration settings in the values.yaml file. The extra-community-configs secret contains a copy of the configuration files used by the Community pod. The LDAP servers are defined within each configuration file. For more information on secrets, see Managing secrets in Kubernetes.
kubectl commands are used to pull the existing file from the Community pod to your local machine. Modify these files locally with the required settings, then create the secret containing the files.
This procedure is to configure Sametime to connect to two or more separate LDAP servers that have unique names.
Note: If you have already created a secret for extra-community-config, you can copy the UserInfoConfig.xml file from the pod to the extra-community-config directory and recreate the secret with the other required files.
The changes in this task affect the Community pods:
Create a directory on your machine called extra-community-config at the root of where the Sametime installation package was decompressed.
Change to the extra-community-config directory.
Find the Community pod name by running the get pods command.
The pod name has hashes in it. For example: community-77d4695988-2bzrx.
kubectl get pods\nPull a copy of the StCommunityConfig.xml from the community pod by running the below command, where podname is the pod name found in the previous step.
kubectl exec -it podname --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nFor example, if the Community pod name is community-845d5d5755-z7zf7, the command to run is
kubectl exec -it community-845d5d5755-z7zf7 --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nPull a copy of the UserInfoConfig.xml file from the Community pod, by running the below command. Substitute the name of your Community pod for podname.
kubectl exec -it podname --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml \nFind the base64 encoded value of your bind credentials. If you are using an authenticated bind, issue the following command in a Linux shell that contains your user name and password separated by a colon.
The resulting value is used in a later step.
echo -n \u201cusername:password\u201d | base64 -d\nIf the Bind DN is CN=bind,O=Example and the password is password, then the command is:
echo -n \u201cCN=bind,O=Example:password\u201d | base64 -d \nUse a text editor to open your local copy of UserInfoConfig.xml in edit mode.
Duplicate the line that begins with StorageDetails.
The order in which you list your StorageDetails statement is the search order to be used.
Configure your second LDAP server by completing the fields:
Edit the StCommunityConfig.xml file with a text editor and make the following changes.
Within the <LDAP> section, duplicate the line that begins with <Connection Hostname.
Modify the new line to contain the details of the second LDAP server.
Modify the SearchOrder parameter for the additional LDAP server to a unique number. This must match the search order you selected for UserInfoConfig.xml.
Save and close the file.
Change to the extra-community-config directory that was created earlier. Run the following command to create the secret.
kubectl\u202fcreate secret generic extra-community-config --from-file=./ \nIf you have a namespace dedicated to Sametime add the -n argument with your namespace to ensure it is created in the correct namespace.
Change to the helm directory where the Sametime installation package was decompressed.
Open the values.yaml file and place in edit mode. Add the following line.
overrideCommunityConfigSecret: extra-community-config\nSave and close the file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Configuring LDAP
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#hostname","title":"HostName","text":"The fully qualified host name or IP address of the second LDAP server.
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#port","title":"Port","text":"If using unsecured LDAP, specify the port number used by LDAP. If you are using secure LDAP, you don't need to modify this field.
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#username","title":"UserName","text":"Set this field to empty double-quotes ( \u201c\u201d ).
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#password","title":"Password","text":"Set this field to empty double-quotes (\u201c\u201d). If using an authenticated bind, add a new parameter after UserName and Password called UserEncodedAuth= and set it to the value that was determined in a previous step.
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#basedn","title":"BaseDN","text":"Define a base DN for searching the directory. If left blank, the entire directory is searched.
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#searchfilter","title":"SearchFilter","text":"Modify the search filter if needed. The defaults work well with Domino LDAP.
You can make other changes to the business cards configuration if needed at this time. When finished, save and close the file.
"},{"location":"admin/configuring_ldap_password.html","title":"Changing the LDAP service account password in Kubernetes","text":"If you are using an authenticated bind for LDAP, with a password that expires periodically, you'll need to update the LDAP bind credentials for Sametime clusters in Kubernetes with a new password.
The LDAP bind credentials are Base64 encoded and defined in the configuration as secrets. When updating the password, you'll need to complete the following tasks:
Update the bind credentials in the Kubernetes secrets.
The LDAP bind credentials are located in Kubernetes secrets:
sametime-global-secretsextra-community-config (optional) There is an optional configuration to override the default settings for LDAP and for business cards in a secret called extra-community-config. If you have implemented this secret, the LDAP Bind credentials must be updated in the XML configuration files and the extra-community-config secret should be deleted and recreatedThe changes in this task affect the following pods:
Community
Find the Base64 encoded values of your credentials.
If your LDAP DN is changing, you need to Base64 encode the complete DN.
For example, if your LDAP DN is CN=SametimeBind,O=Example take your DN and run the below command:
echo -n \u201cCN=SametimeBind,O=Example\u201d | base64\nFor this example, the resulting value is shown below and must be configured for the LdapBindEntryDn parameter in the sametime-secrets.yaml file.
LdapBindEntryDn: 4oCcQ049U2FtZXRpbWVCaW5kLE89RXhhbXBsZeKAnQ== \nIf your LDAP bind password is changing, you need to base64 encode the password.
For example, if your password is thepassword, then run the below command to base64 encode it:
echo -n \u201cthepassword\u201d | base64\nThe resulting value is used in your configuration for the password.
Now find the base64 encoded value of the two settings combined, separated by a colon.
For example if your Bind DN is CN=SametimeBind,O=Example and the password is thepassword then find the base64 encoded value of CN=SametimeBind,O=Example:thepassword:
echo -n \u201cCN=SametimeBind,O=Example:thepassword\u201d | base64 \nUpdate the secret for sametime-global-secrets.
Edit the sametime-global-secrets file. Run the following command.
kubectl edit secret sametime-global-secrets\nLocate LdapBindEntryDn and LdapBindEntryPassword in the helm/templates/sametime-secrets.yaml file. Set their values to the base64 encoded value of your name and password respectively.
LdapBindEntryDn: base64\\_encoded\\_DN \nLdapBindEntryPassword: base64\\_encoded\\_password\nSave and close the file.
Press Esc, w, q, ! on the keyboard to save your changes.
Update the extra-community-config secret.
Determine if there is already a extra-community-config secret by issuing the following command.
kubectl get secrets \nIf you are using a namespace for Sametime, you must include the -n namespace argument on the command to view the secrets scoped to the Sametime namespace.
If there is a secret, delete it. Otherwise skip to the next step.
Run the following command to delete the secret.
kubectl delete secret extra-community-configs\nCreate a new directory named extra-community-configs on the machine that is used to run kubectl commands.
Change directories to the extra-community-configs you just created.
Locate the pod name of the Community pod to be used in the next step by running following the command.
kubectl get pods\nThe name has hashes in it, for example: community-845d5d5755-z7zf7.
Pull a copy of the StCommunityConfigs.xml from the Community pod by running the below command, where podname is the Community pod name found in the previous step.
kubectl exec -it podname --container community -- cat /local/notesdata/StCommunityConfig >./StCommunityConfig.xml \nFor example, if the Community pod name is community-845d5d5755-z7zf7, the command to run is
kubectl exec -it community-845d5d5755-z7zf7 --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nPull a copy of the UserInfoConfig.xml file from the Community pod, by running the below command. Substitute the name of your Community pod for podname.
podname: kubectl exec -it <podname> --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml \nFor example, if the Community pod name is community-845d5d5755-z7zf7, the command to run is
kubectl exec -it community-845d5d5755-z7zf7 --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml \nAfter adding the two files to your machine, the new LDAP DN and password must be defined. Open the local copy of the StCommunityConfig.xml file using a file editor.
Locate the parameters to be changed and set them to their actual unencoded values. Do not specify the base64 encode values.
BindEntryDn= to the Bind DNBindEntryPwd= set to the new Bind password Save and close the file.Open the UserInfoConfig.xml file. Next change the UserEncodedAuth value.
Locate UserEncodedAuth in the file.
Change the current value to the base64 encoded values of the DN and password.
Combine the two values with a colon (:) between them. For example:
echo -n DN:password echo -n 'DN:password' | base64\nSave and close the file.
Create the extra-community-configs secret by issuing the following command.
kubectl create secret generic extra-community-config --from-file=./\nUpdate the configuration files.
If you did not have an extra-community-configs secret before you must update the values.yaml file for Sametime to use the secret.
Change to the helm directory, where the Sametime installation image was unzipped.
Open the values.yaml file with a text editor.
Add the following parameter to the global section.
overrideCommunityConfigSecret: \"extra-community-config\"\nSave and close the file.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Configuring LDAP
"},{"location":"admin/configuring_multi_tenacy.html","title":"Enabling multi-tenancy","text":"Multi-tenancy allows multiple organizations to be part of the Sametime community. With multi-tenancy, Sametime users can chat, add users and groups to contact lists, and have awareness of users in their organization or in other organizations that are configured to be visible to them.
The following conditions must be satisfied:
Ensure that users from all organizations reside under one tree, with multiple branches. For example, if the base DN is CN=ORGANIZATIONS,OU=COLLAB,DC=HCL,DC=COM, then an individual organization would be found at the following baseDN:
O=Organization A,CN=ORGANIZATIONS,OU=COLLAB,DC=HCL,DC=COM \nO=Organization B,CN=ORGANIZATIONS,OU=COLLAB,DC=HCL,DC=COM\nAdditionally, each user\u2019s entry in LDAP must contain an attribute that also contains the name of the organization that the user belongs to. For example, you can create an attribute called \u201corganizationName\u201d and the value set to the name of the organization:
organizationName=Organization A\nNote: For multi-tenant deployments, orgID in versions 12.0 and 12.0.1 does not support the dash ( -) character for Sametime Meetings.
By default, the multi-tenancy feature is disabled. This feature uses customized Java\u2122 code to dynamically generate a filter and base distinguished names for LDAP searches. The multi-tenancy feature is configured by running the setupMultitenancy.sh script.
The setupMultitenancy.sh script prompts for details from the LDAP configuration. Review your LDAP base DNs to determine which values should be used.
Complete the worksheet below to assist in completing the configuration:
Setting Name Description Example Your Value Base DN The top of your LDAP tree\u2014where to start searching the directory. CN=ORGANIZATIONS,OU=COLLAB, DC=HCL,DC=COM Organization BaseDN Thhe location of the individual organizations. O=Organization A,CN=ORGANIZATIONS, OU=COLLAB,DC=HCL,DC=COM \ufeffORG_PART_OF_DN The attribute in the LDAP DN that contains the organization name. O \ufeffPEOPLE_ROOT_BASE_DN The DN of the entry where to start searching for people. It should contain the lowest LDAP entry under which the entries of all the people in the organization are available. O=%S,CN=ORGANIZATIONS, OU=COLLAB,DC=HCL,DC=COM \ufeffGROUPS_ROOT_BASE_DN The DN of the entry where to start searching for groups. It should contain the lowest LDAP entry under which the entries of all the people in the organization are available. O=%S,CN=ORGANIZATIONS, OU=COLLAB,DC=HCL,DC=COM \ufeffPEOPLE_BASE_DN_TEMPLATE \ufeffThe DN of the entry at which to start the people or the groups LDAP search when the search is done in a sub tree of a particular organization. %S should always be present in the value. It is dynamically replaced by the organization name during the resolve operation. O=%S \ufeffGROUPS_BASE_DN_TEMPLATE The DN of the entry at which to start the people or the groups LDAP search when the search is done in a sub tree of a particular organization. %S should always be present in the value. It is dynamically replaced by the organization name during the resolve operation. O=%S \ufeffLDAP_ORG_ATTR \ufeffThe attribute in the LDAP directory that is present in every person and group entry and contains the organization name that this person or group belongs to. ORGANIZATIONNAMEChange directories to where the Sametime installation files are extracted. Then run setupMultitenancy.sh and follow the prompts to provide the required information.
When successful, do either of the following.
Parent Topic: Administering
"},{"location":"admin/configuring_sso_saml.html","title":"Configuration settings related to SAML authentication","text":"You can override default configuration settings in the sametime.ini file. Note that the settings are implemented differently depending on the platform: Docker, Podman, Kubernetes, and Openshift.
For details on configuring these parameters, see Configuring the sametime.ini file.
If the Sametime server is running when you set or modify a sametime.ini file setting, the setting takes effect after you restart the Sametime server.
The following sections, describe optional configuration settings to use with SAML authentication.
"},{"location":"admin/configuring_sso_saml.html#fips-140-2-compliance","title":"FIPS 140-2 compliance","text":"The default Sametime configuration is not FIPS 140-2 compliant. If your Sametime deployment requires FIPS 140-2 compliance, set FIPS 140-2 compliance to true in the TLS configuration, under the Server application connections column. This affects both TLS and SAML. For more information about applying settings in a TLS configuration, see Implementing the Global TLS Scope.
"},{"location":"admin/configuring_sso_saml.html#security-level","title":"Security level","text":"The default configuration imposes no restrictions on the use of cryptographic algorithms and certificate strength. If strong cryptography is required, change the Minimum security level setting in the TLS configuration, in the Server application connections column. This affects both TLS and SAML. For more information about applying settings in a TLS configuration, see Implementing the Global TLS Scope.
Alternatively, you can override the default values by configuring the sametime.ini file.
STI__Config__STSAML_SECURITY_LEVEL=numeric value between 0 and 4, inclusive \nA value of 0 implies no restriction on the cryptographic algorithms or certificate strength. The higher the value, the stronger the security level enforcement. Any security strength higher than 0 causes SAML validation to fail in case the SAML signature validation involves weak cryptography that does not comply with the minimum security level. For a list of available security levels, see Implementing the Global TLS Scope.
"},{"location":"admin/configuring_sso_saml.html#trusted-audiences","title":"Trusted audiences","text":"The SAML identity provider (IdP) might optionally address the assertion to a limited set of audiences. This information is included in the assertion element, according to the SAML standard, and typically contains one or more URLs that identify the trusted audiences. By default, Sametime ignores this information, and validates the assertion whether or not the Sametime Community Server is a member of the specified audiences. If the trusted audiences setting is present in a configuration, and the assertion contains a trusted audience condition, the Community Server matches the assertion audience condition against the trusted audiences setting, and validation fails if there is no match. The trusted audiences are set in the sametime.ini file.
STI__Config__STSAML_TRUSTED_AUDIENCES=trusted-audiences\nThe value of this setting is a comma-separated list of one or more host names. Each audience in the assertion condition is matched against each trusted audience in the configuration. At least one match is needed for passing the condition. Audience matching is performed by comparing the host portion of the audience URL to the host name in the configuration. If the strings are equal (ignoring letter case) there is a match. It is possible to set a trusted-audience string with wild card domain components, using the asterisk character (*) to represent a wild card domain component. For example, this setting uses the asterisk.
STI__Config__STSAML_TRUSTED_AUDIENCES=*.example.com \nAnd the following audience condition in the SAML assertion:
<saml:Audience>https://sametime.example.com/saml/<saml:Audience> \nGiven this configuration and audience condition, matching passes, because sametime.example.com matches *.example.com. In another example, sametime.example.com would not match *.com because the number of domain components is different. That is sametime.example.com contains three components, while *.com contains two.
The SAML authentication token contains a SAML response element, which in turn contains a child assertion element. According to the SAML standard, either element can be signed. The default Sametime configuration does not require a valid response signature if the underlying assertion has a valid signature. You can change the Sametime server to require a valid response signature, regardless of the underlying assertion signature, by setting the sametime.ini parameter. STI__Config__STSAML_REQUIRE_SIGNED_RESPONSE=1
Parent Topic: Setting up SSO using SAML
"},{"location":"admin/configuring_stun.html","title":"Configuring alternate STUN servers","text":"Sametime Meetings uses public Google STUN servers by default. To use different STUN servers, you must complete this procedure before installing Sametime Meetings.
For more information about STUN, see Session Traversal Utilities for NAT (STUN)
Kubernetes
To configure alternate STUN servers if you use Kubernetes, edit the following file:
heml/values.yaml \nChange the following line to refer to your preferred servers, following the same pattern.
jvbStunServers: stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302\nDocker
To configure alternate STUN servers if you use Docker, edit the following file:
.env\nChange the following line to refer to your preferred servers, following the same pattern.
# STUN servers used to discover the server's public IP.\nJVB_STUN_SERVERS=stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302\nParent Topic: Configuring
"},{"location":"admin/connections_photos.html","title":"Using HCL Connections photos for the Sametime business card","text":"You can use the HCL Connections profiles photos for the Sametime business cards. A benefits for using this method is that updated photos in Connections are automatically updated in Sametime.
Calculating the Connections Profiles Photo URL
The Connections user photo can be retrieved from /profiles/photo.do API (REST: GET) which can process different key values from the parameter sent to uniquely identify the user details. <protocol>://<connections server>:<port>/profiles/photo.do?parametername=value
The following parameters can be included on the API.
This configuration depends on which unique user identifier (userId) has been configured in the LDAP settings. The default setting is distinguishedName.
In many cases the Sametime server is configured to use the DN as the Sametime userId. For example: the DN is: CN=Foo Bar,OU=Users,O=Example,C=US In this case the distinguishedName key should be used. The protocol is either HTTP or HTTPS. For example:
http://connections.example.com:9080/profiles/photo.do?distinguishedName= \nIf the Connections server protocol is HTTP and the port is 9080, below is an example of the resulting URL after appending the user\u2019s DN and encoding the spaces:
http://connections.example.com:9080/profiles/photo.do?distinguishedName=CN%3DFoo%20Bar%2COU%3DUsers%2CO%3DExample%2CC%3DUS \nThe community service requires the absolute URL to be added to the person document or LDAP record as an attribute. Many LDAP servers including Domino LDAP and Microsoft Active Directory have an attribute that exists for this purpose called photoURL. Populate the full URL for the photo in the photoURL for each person record in the directory. For Domino LDAP directories, the photoURL is located on the person document, Miscellaneous tab.
Some LDAP servers may not display the photoURL attribute to an anonymous bind, for example, Domino LDAP. Use an authenticated bind to the LDAP server when configuring LDAP services, or configure the LDAP server to render the photoURL to anonymous users.
If the photoURL is a protected resource, Single Sign On (SSO) must be configured between the Sametime serve and Connections server. If the URL is available to anonymous users, SSO is not required.\u00a0 When configuring SSO, the Connections server and Sametime server must share a common directory. For additional information, see Configuring SSO between Connections and Sametime.
If you have not already configured the UserInfoConfig.xml file, review the applicable topic for your environment and complete the configuration before setting the photoURL.
Parent Topic: Setting up business cards
"},{"location":"admin/control_validity_length.html","title":"Managing user sign-on","text":"You can control how long your Sametime meeting credentials are maintained to reduce the number of times you have to sign in.
JWT_REFRESH_DURATION_DAYS environment variable in the YAML file. You can specify any number of whole days to retain login credentials. To disable this feature, set the value to 0.JWT_REFRESH_DURATION_DAYS environment variable. You can specify any number of whole days to retain login credentials. To disable this feature, set the value to 0.Parent Topic: Managing Sametime Meetings
"},{"location":"admin/creating_custom_java.html","title":"Creating custom Java classes for searching LDAP","text":"These topic are in progress Create custom Java\u2122 classes that provide greater control over how Sametime conducts name searches of an LDAP directory and how results are formatted.
Implementing a custom Java class file to transform LDAP searches helps with performance when the LDAP service has a complex directory schema.
If your configuration is using the UUID attribute as the attribute of the person entry that defines the internal ID of a Sametime user, include UUID in your customized filter.
Parent Topic: Configuring LDAP
"},{"location":"admin/customize_branding.html","title":"Adding corporate branding to meeting pages","text":"You can customize meetings to reflect your company's branding and visual presence.
You can include several levels of customizing for meetings to present a visual representation of your company. You can customize all or any combination of the three.
Add a company name and logo. The logo image is displayed on the login, in-meeting, and logout pages.
Change the Favicon and application icons.
Change the background image for meeting tile view.
Adding corporate branding to meeting pages using Kubernetes
Adding corporate branding to meeting pages using Docker or Podman
Parent Topic: Configuring
"},{"location":"admin/customize_docker.html","title":"Adding corporate branding to meeting pages using Docker or Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
To customize the product name, product logo, and banner edit the custom.env file in the directory where the installation package was decompressed.
Add the appropriate statements to the custom.env file to reflect your changes.
To change the product name, add the following statement specifying the new product name.
REACT_APP_PRODUCT_NAME=new\\_product\\_name\nTo change the logo used in meeting pages, add the following statement specifying the location and name of the new logo. The image file can be any size. It is re-sized to approximately 260x260 pixels.
REACT_APP_PRODUCT_LOGO=https://meetings.hcl-showcase.com/images/branding/Showcase_Logo.jpg\nYou can specify the relative or full URL to the logo. If you use the relative URL, the image must be placed on the system using the following command.
cp my-logo.png sametime-config/web/branding/.\nAdd the following statement containing the URL to the Sametime server where you access meetings. This is used for meeting reports.
REACT_APP_PRODUCT_LOGO_URL=https://meetings.hcl-showcase.com/images/branding/Showcase_Logo.jpg\"\nTo change the meeting banner, add the following statement specifying the location and name of the new banner.
REACT_APP_MEETING_BANNER_IMAGE=banner\\_image\nTo change the meeting background, add the following statement specifying the location and name of the new background.
REACT_APP_MEETING_BACKGROUND_IMAGE=background\\_image\nThe background image can be a URL to an accessible image like https://mycompany.com/assets/theme.png or it can be an absolute path like /images/branding/my-logo.png. If you use the absolute path, the image must be placed on the system using the following command.
cp my-theme.png sametime-config/web/branding/.\nRun docker-compose up -d command to apply all changes.
To update the favicon, replace the following files with your version.
To update the app icons, copy the files to the persistent volume. This replaces the following files.
Parent Topic: Adding corporate branding to meeting pages
"},{"location":"admin/customize_kubernetes.html","title":"Adding corporate branding to meeting pages using Kubernetes","text":"To customize the product name, product logo, and banner edit the values.yaml file in the /helm directory.
Add the appropriate statements to the YAML file to reflect your changes.
To change the product name, add the following statement specifying the new product name.
productName: new\\_product\\_name\nTo change the logo, add the following statement specifying the location and name of the new logo. The image file can be any size. It is re-sized to approximately 260x260 pixels.
productLogo: /images/branding/<your\\_logo\\_file\\>\nNote: /images/branding is static and you can not edit this part. It also does not represent where the referenced file resides outside the Kubernetes pods.
Copy the logo to the persistent volume and start the web pod again.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp <your_image_file> $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
Note: Alternatively, you can use an accessible URL that you do not have to copy to the persistent volume.
productLogo: \"http://mycompany.com/assets/<your_logo_file>\"\nTo change the meeting banner, add the following statement specifying the location and name of the new banner.
meetingBannerImage: /images/branding/<your\\_logo\\_file\\>\nNote: /images/branding is static and you can not edit this part. It also does not represent where the referenced file resides outside the Kubernetes pods.
Copy the image to the persistent volume and restart the web pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp <your_image_file> $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
Note: Alternatively, you can use an accessible URL that you do not have to copy to the persistent volume.
meetingBannerImage: http://mycompany.com/assets/<your\\_logo\\_file\\>\nTo change the meeting background, add the following statement specifying the location and name of the new background.
meetingBackgroundImage: /images/branding/<your\\_logo\\_file\\>\nNote: /images/branding is static and you can not edit this part. It also does not represent where the referenced file resides outside the Kubernetes pods.
Copy the image to the persistent volume and restart the web pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp <your_image_file> $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
Note: Alternatively, you can use an accessible URL that you do not have to copy to the persistent volume.
meetingBackgroundImage: http://mycompany.com/assets/<your\\_logo\\_file\\>\nRun a helm upgrade command to apply the changes to your registry.
helm upgrade {release-name} helm/.\nTo update the favicon, do the following.
Copy the files to the persistent volume. This replaces the following files with your version.
A PNG file type image can be used, just renamed to ICO file type.
Restart the pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp favicon.ico $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
To update the app icons, do the following.
Copy the files to the persistent volume. This replaces the following files. For the app icons, replace the following files with your version.
Restart the pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp app-512x512.png $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
Parent Topic: Adding corporate branding to meeting pages
"},{"location":"admin/disable_background.html","title":"Disabling virtual background","text":"By default, you can use a filter, blur your background, or use a default or custom image or video to obscure your surroundings. Depending on your organization's requirements, you can disable the virtual background feature by modifying the applicable file.
To restrict all users from using virtual backgrounds during a meeting, follow these steps:
Modify the configuration file. The default value is TRUE.
For Docker, update the value of the ENABLE_VIRTUAL_BACKGROUND parameter:
ENABLE_VIRTUAL_BACKGROUND=false\nFor Kubernetes, update the value of the VirtualBackgroundEnabled parameter:
virtualBackgroundEnabled: false\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping servers.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/disable_guest_access.html","title":"Preventing guest access","text":"You can disallow guest access to meeting.
There are two tasks to complete: turn off the meeting policy and meeting login prompt. The user receives a Guest not allowed for this meeting message.
Log into the Sametime Admin and open the Anonymous policy.
Guests are assigned the Anonymous policy.
Locate the Meeting section of the policy and turn off the Allow Sametime Meetings attribute.
Update the configuration file to not allow a login prompt to display.
For Docker, in the .env file, specify the following:
REACT_APP_ALLOW_GUEST_LOGIN=false \nFor Kubernetes, Specify the following setting in values.yaml file, specify the following:
REACT_APP_ALLOW_GUEST_LOGIN:false \nParent topic: Managing Sametime Meetings
"},{"location":"admin/disable_sharing_meetings.html","title":"Disable sharing of meeting recording","text":"By default meeting recordings can be shared with others. You can change a setting to disable sharing of meeting recordings.
To disable sharing of meetings recordings, set the SHARE_RECORDINGS_BY_DEFAULT parameter to false on the Meetings server. When the value is set to false, the option to share recordings when editing meeting settings or stopping a recording is not available.
For Docker, change SHARE_RECORDINGS_BY_DEFAULT setting in the custom.env file.
SHARE_RECORDINGS_BY_DEFAULT=false\nFor Kubernetes, add the following to the helm/values.yaml file.
shareRecordingsByDefault=false\nParent Topic: Meetings
"},{"location":"admin/download_content.html","title":"Downloading content to the server","text":"When downloading content to the Sametime sever, it must be downloaded to the web/download directory.
If in a Docker or Podman environment, copy files into the sametime-config/web/downloads directory. For example, the following command is copying the SametimeClient.exe file onto the Sametime server.
cp SametimeClient.exe sametime-config/web/downloads/\nFor Kubernetes environment, copy the files to the persistent volume. For example, the following command is copying the SametimeClient.exe file onto the Sametime server.
{{POD=$(kubectl get po --selector=app.kubernetes.io/name=web | tail -1 | awk ' { print $1 } ') \nkubectl cp SametimeClient.exe $POD:/usr/share/nginx/downloads/.}} \nAfter copying the files, restart the pod.
Parent Topic: Configuring
"},{"location":"admin/enable_dial_out.html","title":"Enabling meeting dial-out","text":"You can enable the dial-out option on Docker and Kubernetes.
The meeting dial-out feature leverages a third party product from ilink called Teamcall Meeting Gateway (TMG), as well as a SIP provider or carrier of your choice to allow users in the meeting to call other participants.
When dial-out is enabled, a new button appears in the meeting allowing a meeting participant to enter a phone number for dial out. The call is established with the SIP provider or carrier, and when the call is answered, the person called is joined to the meeting in an audio-only mode.
Enabling meeting dial-out on Docker or Podman
Enabling meeting dial-out on Kubernetes
Parent Topic: Meetings
"},{"location":"admin/enable_dialout_docker.html","title":"Enabling meeting dial-out on Docker or Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Edit the .env file and save the changes.
Do not include the comments which are in parentheses ().
JIGASI_SIP_SERVER= (This is the SIP server/proxy IP or hostname. For hostname, this must be in DNS or added as extra_hosts entry in docker-compose.yml for the jigasi service.)\n\nJIGASI_SIP_PORT=5060 (This is the SIP server/proxy port)\nJIGASI_SIP_TRANSPORT=UDP (This is SIP server/proxy protocol)\nJIGASI_SIP_URI= (This is the SIP URI, in plain text. Example: [mailto:mysipuser@mysipserver.com mysipuser@mysipserver.com] )\nJIGASI_SIP_PASSWORD= (This is the SIP user password, in plain text.)\nEdit the docker_compose.yml and save the changes.
Note: The \u201c-\u201c is required in front of the parameter.
Under the JIGASI environment section, add the statement: \u2013 JIGASI_PROXY_BYPASS.
Under NGINX environment section, add the statement: - ENABLE_INVITE_OTHERS=true.
Under JICOFO environment section, add the statement: - JIGASI_SIP_URI.
Apply the settings to Docker.
To apply these settings to Docker, perform the following:
cd to directory holding docker-compose.yml\n\n> docker-compose down\n> rm -rf sametime-config/jigasi\n> docker-compose up -d\nParent Topic: Enabling meeting dial-out
"},{"location":"admin/enable_dialout_kubernetes.html","title":"Enabling meeting dial-out on Kubernetes","text":"Edit the helm/values.yaml file and change the enableJigasi to true. The default is false.
Add the following settings. Do not include the comments which are in parentheses ().
jigasiSipServer: (This is the SIP server/proxy IP or hostname. For hostname, this must be in DNS or added to CoreDNS config of Kubernetes.)\njigasiSipPort: 5060 (This is the SIP server/proxy port)\njigasiSipTransport: UDP (This is the SIP server/proxy protocol)\njigasiProxyBypass: true (If the SIP proxy is the only network path to the SIP infrastructure, this must be \u201cfalse\u201d. If the meeting infrastructure can directly hit the SIP endpoints, such as the SIP gateway to the PSTN, \u201ctrue\u201d can be set to bypass the proxy after a call is set up.)\nENABLE_INVITE_OTHERS: true\nConfigure the SIP user account.
The TMG server has a randomly generated passcode that should be shared with the meeting server. This is known as the secret. To share the secret with the meeting server, the value needs to base-64 encoded along with the name. From a command prompt enter the command:
echo -n '{\"ilink-TMG\": \"<secret\\>\"}' | base64\nSubstitute the full secret for the <secret> variable in the command. The resulting value that is echoed to the screen is the credential that needs to be configured on the meeting server.
Open the /helm/templates/auth-config-secret.yaml file in edit mode. Locate the application-registry.json and remove the existing eyB9 value and replace it with the encoded secret.
Run the helm list command to find out the deployment name and current version. This is needed in the event a roll-back is needed.
To apply the changes, change directories to the helm directory where the Sametime Meeting installer was decompressed, then run the following command:
helm upgrade sametime-meetings \nParent Topic: Enabling meeting dial-out
"},{"location":"admin/enable_disable.html","title":"Configuring live streaming","text":"If you have a high number of users that need to attend a meeting that does not require two-way interaction, you can live stream the conference to YouTube, and users can access the meeting using a YouTube URL.
A meeting recorder must be enabled on the Sametime Meeting server. If the meeting recorder doesn't exist, live streaming isn't available.
The YouTube channel must be verified. See YouTube Studio help for the details.
The YouTube Studio tool is required to create the live stream and obtain a streaming key. The stream name/key and YouTube Live URL are needed for the Sametime meeting.
Meeting moderator must have a YouTube publishing enabled account. It can take up to 24 hours for YouTube to enable this feature on an account.
Only meeting moderators can start the live stream. Meeting moderators are indicated with a small star on their participant tile.
In the context of YouTube live streaming, the Sametime Meeting server is considered an encoder for YouTube. There is no requirement to install additional software.
Disabling live stream is a server-wide setting; there is no user-based policy available to disable the feature. The live stream is disabled if you do not have a Sametime Meeting recorder.
Note: All commands provided require running as ROOT or SUDO access. If not running as root user, preface all commands with sudo.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/enable_disable.html#task_dct_chx_wxb","title":"Configuring live streaming in a Docker environment","text":"Open the custom.env file for editing.
vi custom.env \nAdd the following line to the file.
REACT_APP_LIVE_STREAMING_ENABLED=false \nSave the custom.env file.
Restart the Sametime Meeting server.
Open the helm/values.yaml file for editing.
vi helm/values.yaml \nChange the value for the enableLiveStreaming to false.
enableLiveStreaming=false \nUpdate the deployment.
helm upgrade deployment helm/\nRestart the Sametime Meeting server.
To use the Sametime Meetings add-in for Microsoft Outlook, it must be enabled on the Sametime server. The add-in is provided as part of Sametime installation package.
For additonal information about Microsoft add-ins, see the following Microsoft documentation:
Parent Topic: Meetings
"},{"location":"admin/enable_microsoft_outlook.html#task_yck_p4k_3tb","title":"Enabling the add-in on Docker","text":"Edit the .envfile.
Change the ENABLE_OUTLOOK_ADDIN parameter from false to true.
Find the parameter COMPOSE_PROFILES=outlookAddin parmater and remove the comment character (#).
Save your changes and restart the server to apply the changes.
Edit the values.yaml file.
Change the enableOutlookAddin parameter from false to true.
Save your changes and restart the server to apply the changes.
This section provides steps to configure TCP for media streams using TCP port 4443.
The following external port must be opened on a firewall. You can use any network command to verify. For example: - netstat #4443/tcp is used for Real-time Transport Protocol (RTP) media over TCP.
Two types of communication can be configured: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). You can configure the video bridge for one or both.
Parent Topic: Meetings
"},{"location":"admin/enable_video_bridge.html#task_m5l_hfj_5tb","title":"Docker","text":"Use these settings to allow both UDP and TCP.
The client tries UDP first and if it fails, TCP is used.
Open the .env file, look for \u201cJVB_TCP_HARVESTER_DISABLED\u201d configuration and change the value to false.
JVB_TCP_HARVESTER_DISABLED=false\nIn the .env file, locate the entry for JVB_TCP_PORT field. If the value has a # in front, remove the comment # to enable the setting.
JVB_TCP_PORT=4443\nNote: #JVB_TCP_PORT is TCP port for media used by Jitsi Videobridge when the TCP Harvester is enabled.
Open the docker-compose.yml. Add JVB_TCP_PORT section for the JVB component:
# Video bridge\njvb:\nports:\n- '${JVB_PORT}:${JVB_PORT}/udp'\n- '${JVB_TCP_PORT}:${JVB_TCP_PORT}'\nWith above configuration, A/V media successfully flows through 4443 media-port and media-port state changes from Listening to Established
tcp6 0 475 a82b7a871950:4443 192.168.75.1:49295 ESTABLISHED\n*Use these settings to force TCP only.***
If there is need to completely switch to the TCP protocol and remove support for UDP, then complete the settings above, remove JVB_PORT in the docker-compose.yml file and remove the entry from .env file.
# Video bridge\njvb:\nports:\n#- '${JVB_PORT}:${JVB_PORT}/udp'\n- '${JVB_TCP_PORT}:${JVB_TCP_PORT}'\nTo enforce the changes made, follow the steps in Applying configuration changes in Docker or Podman.
"},{"location":"admin/enable_video_bridge.html#task_gvf_gfj_5tb","title":"Kubernetes","text":"Use these settings to allow both UDP and TCP.
UDP will be attempted first and if it fails, then TCP will be used. If you need to disable UDP entirely, UDP will need to be blocked at the network.
Open the helm/charts/video/templates/deployment.yaml, add the following as environment variables. Search for JVB_PORT to see where to insert them:
- name: JVB_TCP_PORT\nvalue: \"4443\"\n- name: JVB_TCP_HARVESTER_DISABLED\nvalue: \"false\"\nThese steps are required for AWS EKS only. In helm/charts/video/templates/deployment.yaml, find the lifecycle section. Below it you will see a preStop: section. Insert the following as a sibling section to preStop:
postStart:\nexec:\ncommand: [\"/bin/sh\", \"-c\", \"echo 'org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth0' >> /defaults/sip-communicator.properties\"]\nSave the settings and redeploy using the steps in Applying configuration changes in Kubernetes or Openshift.
To update a live deployment, use the following command:
kubectl set env deploy/video -e JVB_TCP_PORT=4443 -e JVB_TCP_HARVESTER_DISABLED=false\nUse these commands to update a live deployment if you are deployed on AWS:
kubectl patch deploy/video -p '{\"spec\":{\"template\":{\"spec\":{\"containers\":[{\"name\":\"jvb\",\"lifecycle\":{\"postStart\":{\"exec\":{\"command\":[\"/bin/sh\", \"-c\", \"echo \\\"org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth0\\\" >> /defaults/sip-communicator.properties\"]}}}}]}}}}'\nUse these steps to remove UDP port 30000 from AWS:
Ensure that Sametime Connect and Embedded clients can connect to the Sametime using SAML by adding the new trusted audience URL to the client preferences before installing or updating the clients.
Enable SAML authentication for the deployment as explained in Setting up SSO using SAML.
This task applies to the Sametime Connect and Embedded clients; it does not affect web or mobile clients. This topic includes parameters to pre-configure the clients for SAML, so that the users do not need to know any of the details.
During SAML log in process, Sametime redirects client connections to the Identity Provider (IdP) URL. If the IdP passes the user through multiple sites, Sametime stops loading the page and generates the following error message in the log: URL redirected_url is not in the trusted sites list.
Ensure that Sametime Connect and Embedded clients can connect using SAML by adding the trusted site's URL to the client preferences before installing or updating the clients. This is the URL that you assigned in the STSAML_TRUSTED_AUDIENCES setting, as explained in Configuration settings related to SAML authentication. For more information on configuring client installation packages, see Configuring Sametime Connect client preferences with the Expeditor managed settings framework.
Alternatively, users can manually enable SAML authentication by modifying settings in the client. For more information, see Enabling SAML authentication in installed clients. This topic outlines the steps required to determine the settings used in the plugin_customization.ini file. As you find the parameter name and value for each setting, save them in a temporary location, which is added to the plugin_customization.ini to configure the clients.
Determine the SAML prefix value.
The Sametime clients support connecting to more than one Sametime environment, which could possibly have different IdPs. Therefore, the parameters defined in the plugin_customization.ini file are prefixed with the host name of the server.
To determine the parameter prefix value:
com.ibm.collaboration.realtime.community/.The second part of the parameter prefix is the fully qualified host name of the Sametime server followed by a dot. For example:
sametime.example.com.\nFor example, if the Sametime host name is sametime.example.com, the resulting prefix using the example is the prefix added to each parameters.
com.ibm.collaboration.realtime.community/sametime.example.com\n.
Determine the IdP URL parameter name and value.
To determine the parameter name, use the prefix determined in the previous step and append idp=. For example:
com.ibm.collaboration.realtime.community/sametime.example.com.idp=\nSet the value of the parameter to the IdP URL. To find the IdP URL, refer to the Setting up SSO using SAML. For example:
com.ibm.collaboration.realtime.community/sametime.example.com.idp=https://idp.example.com/exampletenant&appid=1234?TARGET=https://sametime.example.com\nDetermine if you should use a form based login or a browser based login type.
The parameter name is the prefix determined in step one followed by idp.type= For example:
com.ibm.collaboration.realtime.community/sametime.example.com.idp.type=\nThe Sametime Connect and Embedded clients have two options for displaying the user login details:
Browse to your IdP URL, view the HTML source of the log-in form and collect the following values.
prefix.idp.form.username.tag : The value in the name attribute of the Intranet ID label's input statement. This value is user ID.
prefix.idp.form.password.tag : The value in the name attribute of the Password label's input statement. This value is password .
prefix.idp.form.submit.tag : The value in the name attribute of the Sign in input statement. This value is the submit tag.
For example, if you browse to the example IdP URL, the following shows where the values appear in the sample HTML source.
Based on the example, the resulting settings and values are:
com.ibm.collaboration.realtime.community/sametime.example.com.idp.form.username.tag=userID \ncom.ibm.collaboration.realtime.community/sametime.example.com.idp.form.password.tag=password \ncom.ibm.collaboration.realtime.community/sametime.example.com.idp.form.submit.tag=submit_button \nSet the samlTrustedSites parameter to list all redirecting URLs used by your IdP.
Separate multiple URLs with a comma (,). If your IdP does not use redirecting URLs, leave this setting blank. Each URL can be as simple as https://host_name, or you can include a path as in https://host_name/path as shown in the following example.
com.ibm.collaboration.realtime.community/samlTrustedSites=https://host1,https://host2/path\nNote: This parameter is scoped globally to Sametime and not to a particular community. If configuring multiple communities, enter all possible URLs.
Configure the parameter that lists the communities which use SAML.
Be sure to use the same fully qualified host name that was used in step 1 when the prefix was determined. For example:
com.ibm.collaboration.realtime.community/samlCommunities=sametime.example.com\nIf you have more than one community supporting SAML, enter the second server name as well. Use a comma to separate values.
Add the settings to the plugin_customization.ini file and include it in the client package that is distributed to users.
Parent Topic: Setting up SSO using SAML
"},{"location":"admin/enabling_saml_clients.html","title":"Enabling SAML authentication in installed clients","text":"Enable SAML authentication from within the HCL\u00ae Sametime\u00ae Connect or Embedded client that is already installed on a computer.
Enabling SAML authentication in an installed client requires the following information, which the Sametime administrator can provide to users:
These instructions only apply to a client that is already installed on a computer (the stand-alone Connect client or the Embedded client that runs in HCL Notes\u00ae).
Open the Sametime Preferences dialog box.
On the Server Communities page, click New Server Community.
On the New Server Community page, fill in the information listed in Table 1.
Server community type : Select Sametime.
Server community type : Server community name : Type the community name.
Click the Log In tab.
Turn on the Use token-based single sign-on parameter.
In the Authentication server field, type the authentication server's URL, which you can obtain from your administrator.
In the Authentication type field, select SAML and complete the following fields.
Login : If users log in to your company's authentication server by typing a user name and password in the browser login page, select Browser and do not specify a value for the User name and Password fields.
: If users log in to your company's authentication server by typing a user name and password in a Sametime dialog box, select Form and specify a value for the User name and Password fields.
User name tag : Specify either the HTML tag ID or the tag name of the user name field in the IdP.
Password tag : Specify either the HTML tag ID or the tag name of the password field in the IdP.
Submit tag : If Browser was selected, this field is optional. Specify a value for this field if you want to enable automatic log-ins after network interruptions, provide either the HTML tag ID or the tag name of the submit field in the IdP. If you do not specify a value, passwords are not retained from one log-in to the next.
: If Form was selected, specify either the HTML tag ID or the tag name of the submit field in the IdP.
Click the Server tab and provide the following information.
Host server : The fully qualified host name of the Sametime server.
Server community port : The Sametime server port, specify 1533.
Click OK to save your changes and close the dialog box.
Parent Topic: Setting up SSO using SAML
"},{"location":"admin/enabling_saml_docker.html","title":"Configuring SAML on Docker and Podman","text":"A truststore is needed for Sametime to decrypt SAML tokens. For information on creating a samltruststore.p12 file, see Creating a truststore with a third-party certificate.
The IdP URL is defined in the configuration. See Setting up SSO using SAML for information on determining the IdP URL value.
The changes in this task affect the following pods:
The steps in the following procedure must be completed with root access or you can use sudo which allows you to run commands as root.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Change directories to the root directory where the Sametime installation package was decompressed.
Place the samltruststore.p12 file in the directory where the docker-compose.yml file is located.
Create a file with the name saml.env.
vi saml.env\nAdd the following lines to the saml.env file.
STI__Config__STSAML_TRUST_STORE_TYPE=p12 \nSTI__Config__STSAML_TRUST_STORE_FILE=/local/notesdata/samltruststore.p12 \nSTI__Config__STSAML_TRUST_STORE_PASSWORD=samltruststorepass \nOpen the docker-compose.yml file for editing.
Locate the env_file: section under the community: subsection within the services: section.
Move custom.env to a new line.
Add the following line below custom.env.
saml.env\nThe results should look like the following:
services:\n community:\n env_file: \n - custom.env\n - saml.env\n environment:\nAdd a path to the SAML trust store.
volumes section in the docker-compose.yml file, create one under the networks section and add the following line to the section.volumes section, add the following line to the section. - ./samltruststore.p12:/local/notesdata/samltruststore.p12 \nThe section should look like the following example. Ensure that the indentations look like the example.
networks:\n - sametime.test\nvolumes:\n - ./samltruststore.p12:/local/notesdata/samltruststore.p12\nUpdate the custom.env file to include the IdP URL as well as the authentication options.
Authentication options to include are: Jwt, Ltpa, and Saml. If you are uncertain of the value to use for your IdP URL, see Setting up SSO using SAML for details. For example:
STI__ST_BB_NAMES__ST_AUTH_TOKEN=Fork:Jwt,Ltpa,Saml\nIDP_URL=https://idp.example.com/example_tenant&appid=1234?TARGET=https://sametime.example.com/chat\nNote: The TARGET parameter is for the re-direct after a SAML assertion is posted back to Sametime after it has been validated. Ensure that the target points back to the chat host name or chat (as the example shows).
Open the .env file for editing, and then add the STCONF_IDPURL parameter.
For example:
STCONF_IDPURL=https://idp.example.com/example_tenant&appid=1234?TARGET=https://sametime.example.com/chat\nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up SSO using SAML
"},{"location":"admin/enabling_saml_kubernetes.html","title":"Configuring SAML in Kubernetes","text":"You can implement SSO into your Kubernetes environment using Security Assertion Markup Language (SAML). The changes in this task affect the following pods: community, mux, and proxy.
Find the idpUrl value.
Modify the user access URL that was provided by your identity provider so that users are redirected properly.
Append the IdP user access URL with ?TARGET=https://fully_qualified_hostname/chat.
For example, if the following exists:
https://idp.example.com/example\\_tenant&appid=1234https://idp.example.com/example\\_tenant&appid=1234?TARGET=https://sametime.example.com/chat
If you are using a different host name for meetings and web chat, use the host name for the web chat client.
https://idp.example.com/exampletenant&appid=1234?TARGET=https://webchat.example.com/chat
Configure the Sametime server to use SAML.
Retrieve the certificate from your IdP and create a trust store in p12 format named samltruststore.p12. If your IdP provides more than one certificate, all certificates must be added to the trust store.
Create a secret with your trust store.
kubectl create secret generic saml-secret --from-literal=KeyStorePassword=password --from-file=samltruststore.p12\nWhere password is the password for the keystore. If you are using a namespace for Sametime, include the namespace argument in the command to ensure the secret is located in the same namespace as Sametime.
Change directories to helm in the location where the Sametime install was decompressed.
Open the values.yaml file in edit mode.
Remove the comment character (#) from the following line.
# samlConfigSecret: saml-secret
Type the IdP URL as the value for the idpUrl parameter.
Add the following line below the idpUrl line.
ReactAppShowGuestLoginByDefault: true\nSave and close the values.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up SSO using SAML
"},{"location":"admin/enabling_sso.html","title":"Enabling Single Sign-on","text":"The HCL Sametime server installer enables required JSON Web Token (JWT) authentication. Additionally, the Sametime server supports Security Assertion Markup Language (SAML) and Lightweight Third Party Authentication (LTPA) Single Sign-on (SSO).
SSO is required by the Sametime Community, Proxy, and Meeting services. Typically no further configuration is required, but in some situations you might need to configure SSO to work with other servers. For example, if you have Sametime Integration with Verse, you need to share the same SSO with the Verse servers.
With SSO configured, users who log in to any server within the configured DNS domain do not have to log in again when they access another participating server.
Note: When using SSO all servers must use the fully qualified host names, such as server.example.com for the LTPA tokens to be created correctly.
Parent Topic: Securing
"},{"location":"admin/enabling_sso_ltpa.html","title":"Setting up SSO using LTPA","text":"You can implement SSO into your environment using Lightweight Third Party Authentication (LTPA) which requires LTPA keys.
If you connecting to a HCL Connections server, the LTPA keys is generated by Connections. For other implementations, you'll need to generate the LTPA keys. It doesn't matter whether Sametime is running in Docker or Kubernetes, you can use the process is the same to generate the keys.
To complete the SSO connections, the LTPA keys must be configured in Docker or Kubernetes where Sametime is running. The process to configure LTPA on Docker and Kubernetes is different.
Parent Topic: Enabling Single Sign-on
"},{"location":"admin/enabling_sso_saml.html","title":"Setting up SSO using SAML","text":"You can implement SSO into your environment using Security Assertion Markup Language (SAML). The process is different for Kubernetes and Docker.
One user access URL for the Sametime server is needed for the identity provider (IdP). An IdP is a service that stores and verifies the identity of users. In previous Sametime releases, the community services for rich clients was separate from the web chat and meeting services. In Sametime 12, all services are under the Sametime server. Because there is only one server, only one host name is required for all three types of user access: rich clients, web chat, and meetings.
To use SAML, the IdP administrator must create a federated partnership or relying party trust for the Sametime server. Additionally, the user access URL for the Sametime configuration and a certificate to be trusted by the Sametime server must be provided.
If you are upgrading from a previous Sametime version, you might want to keep using the same host names. Use the following scenarios for IdP requirement guidance.
"},{"location":"admin/enabling_sso_saml.html#scenario-1","title":"Scenario 1","text":"If one host name is used for accessing rich clients, web chat clients, and meeting clients, then only one SAML partnership or relying party trust is needed.
"},{"location":"admin/enabling_sso_saml.html#scenario-2","title":"Scenario 2","text":"If using a different host name for rich clients and web chat clients, then include the following SAML partnerships or relying party trusts:
If using a different host name for rich client, web chat clients, and meeting clients, then include the following SAML partnerships or relying party trusts:
Note: Meeting authentication is processed through the web chat proxy and no specific SAML partnership is required for the meeting host name.
Each IdP varies in implementation and terminology. The following are some guidelines for configuring your IdP. Only IdP initiated sign-on is supported.
"},{"location":"admin/enabling_sso_saml.html#saml-assertion-consumer-service-url","title":"SAML assertion consumer service URL","text":"The fully-qualified URL of the Sametime server, add /stwebapi/user/connect. For example, https://sametime.example.com/stwebapi/user/connect at the end of the URL.
If you are using a separate name for the web chat client, you can use the webchat host name in the URL. For example: https://webchat.example.con/stwebapi/user/connect.
If the Community chat server has a separate host name from webchat or rich clients, use the community host name in the URL, for example: https://chat.example.com .
"},{"location":"admin/enabling_sso_saml.html#relay-state","title":"Relay State","text":"Specify the same value as the what is specified for the SAML assertion consumer service URL.
"},{"location":"admin/enabling_sso_saml.html#log-out-url","title":"Log out URL","text":"Do not specify a value for this property. The SAML logout specification is not supported in Sametime.
"},{"location":"admin/enabling_sso_saml.html#name-id","title":"Name ID","text":"Specify the attribute from the IdP that contains the user's email address.
"},{"location":"admin/enabling_sso_saml.html#certificate-for-tls","title":"Certificate for TLS","text":"A secure connection to the IdP is required and the IdP administrator must provide the certificate for Sametime to trust. If you have multiple relying party trusts, the IdP might have separate certificates for each host name trusted or a single certificate. Such as in the case of separated host names. If there are more than one certificate, each certificate and its full chain must be added to the trust store.
Configuring SAML on Docker and Podman
Configuring SAML in Kubernetes You can implement SSO into your Kubernetes environment using Security Assertion Markup Language (SAML).
Parent Topic: Enabling Single Sign-on
"},{"location":"admin/example_preferences.html","title":"Hosting client files for Sametime on Docker or Podman","text":"Sametime clients can be configured by administrators using a managed-settings.xml or managed-community-configs.xml file which is hosted by a web server. Additionally, the Sametime client can be pre-configured with settings such as the hostname, port, etc. The client package can be hosted on a web server for download. This topic has the steps to host files in the Sametime web container for Docker or Podman.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Shut down the Sametime server.
docker-compose down\nRun the following command to copy the managed-settings.xml or managed-community-configs.xml file into the sametime-config/web/downloads directory.
cp SametimeClient.exe sametime-config/web/downloads/.\nThe managed-settings.xml file must be named managed-settings.xml. If you require more than one managed-settings.xml file, you must place those files in different folders on the web server.
Optional: Create additional directories in the downloads folder. For example, create a folder named default under that tree.
sametime-config/web/downloads/default/\nThe Sametime client looks in the folder specified in the policy for both a managed-settings.xml and a managed-community-configs.xml. If you are using both types of files, the URL defined in the policy must be scoped to the folder path where the two files reside.
If you need to support multiple policies containing different managed-settings.xml and managed-community-configs.xml files, then place them in folders with different names.
For example:
http://www.example.com/default \n\nhttp://www.example.com/nomeetings\nNote: Do not use the following special characters in your folder names
Parent Topic: Defining preferences in the managed-settings.xml file
"},{"location":"admin/hcl_sametime_clients.html","title":"Sametime clients","text":"Several client types are supported providing flexibility in how users can access chats and meetings. A single deployment can implement several client types.
The following Sametime client types are supported:
"},{"location":"admin/hcl_sametime_clients.html#connect-client","title":"Connect client","text":"The Connect client is a stand-alone client that allows for connection to the Sametime server for meetings and chat. It is installed on the user's desktop and requires administrative privileges to perform the install. It can be installed on a Windows or MacOS platform. This client provides access to chat features. Documentation for this client is provided as Help within the client.
"},{"location":"admin/hcl_sametime_clients.html#embedded-client","title":"Embedded client","text":"An Embedded client provides connection to the Sametime server within another product. HCL Verse, HCL iNotes, HCL Connections, and HCL Digital contained an embedded Sametime client. Because it is part of the product, starting and using Sametime is done within the product where it is embedded. This client provides access to chat features. Documentation for this client is provided as Help within the client.
"},{"location":"admin/hcl_sametime_clients.html#mobile-client","title":"Mobile client","text":"Mobile clients provide access to a Sametime server using an iOS and Android mobile device. A HCL Sametime app must be installed on the mobile device to connect to the server. This client provides access to chat and meeting features.
The PWA is a standalone app that can be installed from the Web client onto your machine. It allows you to access chat and meeting features from the installed app. This client provides access to chat and meeting features.
"},{"location":"admin/hcl_sametime_clients.html#web-client","title":"Web client","text":"The Web client provides access to the Sametime server using a web browser. This client provides access to chat and meeting features.
Parent Topic: Planning
"},{"location":"admin/implement_tls_configuration.html","title":"Implementing the Global TLS Scope for Docker","text":"You must have a key store and trust store as a .p12 file. Both third party and self-signed certificates are supported.
Note: If you are supporting mobile clients, use a third-party certificate.
The following tables describe the required and optional configuration settings in the sametime.ini. To configure the sametime.ini file, see Configuring the sametime.ini file on Docker or Podman.
Table 1. Required parameters
Parameter Description STI_Config_ST_TLS_TRUST_STORE_TYPE The trust store type. Only p12 trust stores are supported. STI_Config_ST_TLS_KEY_STORE_TYPE The key store type. Only p12 trust stores are supported. STI_Config_ST_TLS_TRUST_STORE_FILE The full path and name of the trust store file. For example: /local/notesdata/truststore.p12 STI_Config_ST_TLS_TRUST_STORE_PASSWORD The password to the trust store.For example:SecureSametimePassw0rd STI_Config_ST_TLS_KEY_STORE_FILE The full path and name of the key store. For example: /local/notesdata/keystore.p12 STI_Config_ST_TLS_KEY_STORE_PASSWORD The password to the keystorel For example: SecureSametimePassw0rd Table 2. Optional Parameters
Parameter Description STI_Config_ST_TLS_FIPS_COMPLIANCE Set to 1 to enable FIPS compliance. STI_Config_ST_TLS_SECURITY_LEVEL The required security level. The minimum security level controls compliance with the security standards NIST SP800-131a and NSA Suite B. 0: No requirement 1: NIST SP800 -131a \u201cTransition mode\u201d 2: NIST SP800-131a \u201cStrict mode\u201d 3: NSA Suite B 128-bit level 4: NSA Suite B 192-bit level STI_Config_ST_TLS_MAX_SESSION_AGE The amount of time before re-negotiating a session. The time to keep a session, in seconds, before deleting it from cache. -1: No cache, which is generally sufficient for most Sametime deployments. This is the default value. 0: No limit on the age of cached sessions. STI_Config_ST_TLS_SESSION_CACHE_SIZE Applies only to inbound connections. The number of TLS sessions that a server keeps in memory, for session reuse. This option tells the server to keep a cache of the TLS session state after the connection is closed. -1: No session cache, which is generally sufficient for most Sametime deployments. This is the default value. 0: No limit on the number of cached sessions. It is useful after temporary network outage, when the client attempts to reconnect to the server, by reusing the session that was established earlier. - If the server finds the session in cache, the handshake is abbreviated, consuming less resources. - If the session is not in cache, a new session is established, including the full handshake. STI_Config_ST_TLS_SESSION_CACHE_TIME Applies only to inbound connections. The maximum age of a TLS session, in seconds before renegotiating a session, If the same session is used longer than this setting, a new session is renegotiated over the same connection. The default value 0 means that there is no session renegotiation. STI_Config_ST_TLS_MIN_PROTOCOL_VERSION= The oldest version of the SSL/TLS protocol to negotiate during handshake. The default value is TLS 1.2. 0x300: SSL v3 0x301: TLS v1.0 0x302: TLS v1.1 0x303: TLS v1.2. This is the default value used if the value for the parameter is blank. STI_Config_ST_TLS_MAX_PROTOCOL_VERSION The maximum TLS protocol. 0x300: SSL v3 0x301: TLS v1.0 0x302: TLS v1.1 0x303: TLS v1.2. This is the default value used if the value for the parameter is blank. STI_Config_ST_TLS_CIPHER_SUITES A comma-separated list of cipher suites. Leave blank to enable the default cipher suites.\u00a0 STI_Config_ST_TLS_CLIENT_AUTH Request a certificate from the client, does not apply to outbound connections. 0=None: The server does not request a certificate from the client. This is the default value. 1=Want: The server requests a certificate from the client, but will proceed with the handshake even if the client does not present one. 2=Need: The server requests a certificate from the client, and will fail the connection if the client does not present one. STI_Config_ST_TLS_TRUSTED_HOSTS A comma-separated list of one or more trusted hosts, to compare against the peer certificate. The comparison takes place during the TLS handshake, when receiving a certificate from the peer, when the client receives the server certificate, or when the server receives a client certificate. The name in the peer certificate is typically specified in either the subject CN (common name) or thesubjectAltName field. Validation passes if there is at least one match between the name in the peer certificate and a name in the trusted hosts list. A trusted host name may contain the wild card character (*) which can be used to compare domain components rather than the entire string as a whole. The comparison process follows the rules described in section 3.1 of RFC 2818. Certificate subject validation only applies when receiving a certificate from the peer. In order to ensure that a server performs this comparison, the server must require a client certificate, by setting ST_TLS_CLIENT_AUTH=2. STI_Config_ST_TLS_MIRROR_TRUSTED_HOSTS This parameter is needed when you have a key store with multiple key certificates. In which case, each certificate has a different alias in the key store. On the server side, specify the alias of the certificate that identifies the server. If the key store is used on the client side of TLS connections, specify the alias of the certificate that identifies the client. STI_Config_ST_TLS_KEY_LABEL This parameter is ignored if the STI_Config_ST_TLS_KEY_STORE_FILE parameter is missing or if there is only one key in the keystore. This parameter is needed when you have a key store with multiple key certificates. In which case, each certificate has a different alias in the key store. On the server side, specify the alias of the certificate that identifies the server. If the key store is used on the client side of TLS connections, specify the alias of the certificate that identifies the client. Note: When you enable TLS for the Sametime server connections, TLS version 1.2 is used by default. SSLv3 and TLSv1 have security vulnerabilities and should not be used.
Parent Topic: Securing connections
"},{"location":"admin/increase_activecameras.html","title":"Increasing the number of video streams displayed during a meeting","text":"The most recent active video streams are displayed in the meeting window up to the specified maximum value. The default is nine.
The maximum number includes the person viewing the meeting. If the value is increased and performance decreases, reduce the number. Note that specifying a value greater than nine is not supported by HCL.
Open the configuration file for editing.
Change the parameter in the configuration file. Note that the value doesn't include your camera which is always displayed.
For Docker, update the CHANNEL_LAST_N parameter. For example,
CHANNEL_LAST_N = 11\nWhen applied, up to twelve simultaneous video streams are displayed.
For Kubernetes environments, update the channelLastN parameter. For example,
channelLastN : 11\nThe parameters are case sensitive and must be entered as shown.
Apply the changes to the environment.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/installation_mongodb.html","title":"Installing MongoDB","text":"The MongoDB Community Server can be downloaded from the MongoDB website. You can install MongoDB on Windows and Linux platforms. For information on MongoDB about its purpose for Sametime and deployment options, see MongoDB.
Parent Topic: Installing
"},{"location":"admin/installation_prometheus.html","title":"Installing Prometheus","text":"Prometheus provides monitoring on the system. It is used in the auto-scaling feature, but can also be used to monitor your system usage and performance.
The Prometheus application must be installed to deploy the autoscaler and deploy Grafana on a Sametime Kubernetes environment.
The procedures in this topic install the Kube-Prometheus stack using Helm and the default helm charts. Refer to the prometheus-operator / kube-prometheus readme for the default settings. To customize the configuration, the prometheus-community/helm-charts can be downloaded and modified before installing them.
Add the prometheus-community helm repository.
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts\nCreate a namespace for monitoring.
kubectl create namespace monitoring\nRun the following command to install Prometheus. The command must be entered as a single line.
helm install -n monitoring prometheus --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false prometheus-community/kube-prometheus-stack\nParent Topic: Installing Sametime in a Kubernetes environment
Parent Topic: Monitoring your meeting and chat metrics with Grafana
"},{"location":"admin/installation_prompt_descriptions.html","title":"Information to provide during installation","text":"During the install process, you are prompted for information used to tailor the installation for your environment.
The Sametime install prompts for several details pertaining to the environment. Before initiating the process, gather the listed details.
"},{"location":"admin/installation_prompt_descriptions.html#sametime-server-name","title":"Sametime server name","text":"The fully qualified name of the Sametime server.
"},{"location":"admin/installation_prompt_descriptions.html#mongodb","title":"MongoDB","text":""},{"location":"admin/installation_prompt_descriptions.html#mongo-host","title":"Mongo host","text":"The host name of the MongoDB server.
"},{"location":"admin/installation_prompt_descriptions.html#mongo-port","title":"Mongo port","text":"The port number used to communicate with the MongoDB server.
"},{"location":"admin/installation_prompt_descriptions.html#administrator-user-name","title":"Administrator user name","text":"The user name of the MongoDB administrator defined when configuring the MongoDB. The default MongoDB administrator is sametimeUser.
"},{"location":"admin/installation_prompt_descriptions.html#password","title":"Password","text":"The password for the the MongoDB administrator defined when configuring the MongoDB. The default MongoDB password is sametime.
"},{"location":"admin/installation_prompt_descriptions.html#connection-url","title":"Connection URL","text":"A secure URL to connect to the MongoDB server. The supplied URL overrides the default MongoDB URL.
"},{"location":"admin/installation_prompt_descriptions.html#ldap","title":"LDAP","text":""},{"location":"admin/installation_prompt_descriptions.html#ldap-server","title":"LDAP server","text":"The host name or IP address of the LDAP server.
"},{"location":"admin/installation_prompt_descriptions.html#ldap-port","title":"LDAP port","text":"The port used to communicate with the LDAP server.
"},{"location":"admin/installation_prompt_descriptions.html#bind-name-and-password","title":"Bind name and password","text":"The bind account name and password for Sametime to access LDAP.
"},{"location":"admin/installation_prompt_descriptions.html#base-dn","title":"Base DN","text":"The base location where Sametime begins a search for users and groups.
"},{"location":"admin/installation_prompt_descriptions.html#tls-access","title":"TLS access","text":"If LDAP is access using TLS, provide the port number.
"},{"location":"admin/installation_prompt_descriptions.html#displayname-attributes","title":"displayName attributes","text":"The default is cn.
"},{"location":"admin/installation_prompt_descriptions.html#jwt-secret","title":"JWT Secret","text":"The Base64 encoded JWT_SECRET from the Sametime deployment. If migrating from another version of Sametime, you can re-use your existing secret. If you don't have one the install program generates it.
"},{"location":"admin/installation_prompt_descriptions.html#turn-server","title":"TURN server","text":""},{"location":"admin/installation_prompt_descriptions.html#turn-server-address","title":"TURN server address","text":"The fully-qualified host name of a TURN server.
"},{"location":"admin/installation_prompt_descriptions.html#turn-port","title":"TURN port","text":"The port used to communicate with the TURN server.
"},{"location":"admin/installation_prompt_descriptions.html#secret-to-turn-server","title":"Secret to TURN server","text":""},{"location":"admin/installation_prompt_descriptions.html#transport-for-stunturn-connection","title":"Transport for stun/turn connection","text":"Select either pct or udp.
"},{"location":"admin/installation_prompt_descriptions.html#tcp-configuration","title":"TCP configuration","text":"The port number used for TCP communications. The default is port number 4443.
"},{"location":"admin/installation_prompt_descriptions.html#ltpa-configuration","title":"LTPA configuration","text":""},{"location":"admin/installation_prompt_descriptions.html#path-to-the-ltpa-key-file","title":"Path to the LTPA key file","text":"Fully path to the LTPA key file. If you enable LTPA, LTAP keys are required.
Upon successful connection to the LTPA keys, the following message is displayed.LTPA configuration is OK
"},{"location":"admin/installation_prompt_descriptions.html#administrator-email","title":"Administrator email","text":"The email address for the Sametime administrator.
"},{"location":"admin/installation_prompt_descriptions.html#monitoring","title":"Monitoring","text":""},{"location":"admin/installation_prompt_descriptions.html#admin-user","title":"Admin user","text":"The Grafana administrator ID to access the Grafana console
"},{"location":"admin/installation_prompt_descriptions.html#password_1","title":"Password","text":"Password associated with the Grafana administrator ID.
"},{"location":"admin/installation_roadmap.html","title":"Installation road map","text":"The installation road map lists the high-level steps for installing your product. Reviewing the high-level steps before you start the installation process helps you be prepared when prompted for information during the installation.
Table 1. Where to find more information
Item More information System requirements HCL Sametime\u00ae System Requirements Planning - Planning the network topology and connectivity - Sametime client preferences - Sametime client configuration options Installing - Installing MongoDB - Installing Sametime - Installing Sametime clients - Configuring LDAP Clustering and high availability - Clustering and high availability - Installing Prometheus Migrating and upgrading - Planning for migration to Sametime 12Parent Topic: Installing
"},{"location":"admin/installation_sametime.html","title":"Installing Sametime","text":"You can install HCL Sametime Premium and HCL Sametime in a single- or multi-node container environment. The following platforms are supported: Docker, Podman, Kubernetes, OpenShift, and Windows.
The processes for installing Sametime Premium and Sametime are almost identical. Sametime Premium includes both the meetings and chat features. Sametime includes only the chat feature. When you install Sametime, steps related to meetings, recordings, audio, and video are not required.
There are several install options that should be considered before starting the install process. Based your choice on what is best for your environment.
"},{"location":"admin/installation_sametime.html#section_hd1_hj2_zyb","title":"Single-node container management environment","text":"All supported platforms support a single-node environment to manage the Sametime containers. All use a install procedure that is specific to the container management system. Because it is a single-node environment, installing additional software for things such as autoscaling is not needed.
Installing Sametime in a Kubernetes using managed charts
Information to provide during installation During the install process, you are prompted for information used to tailor the installation for your environment.
Parent Topic: Installing
"},{"location":"admin/installation_sametime_docker.html","title":"Installing Sametime in a Docker or Podman environment","text":"The process to install Sametime on Docker and Podman are identical. The installation process detects if you are installing Sametime on Docker or Podman and prompts for the appropriate information.
Before you can install Sametime, you must have a working Docker or Podman environment. Refer to the documentation for installing and configuring Docker or Podman which contain the latest information.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Parent Topic: Installing Sametime
"},{"location":"admin/installation_sametime_grafana.html","title":"Enabling monitoring and statistics","text":"You can configure Grafana during the installation process provided it has been enabled. Alternately, Grafana can be configured post-installation.
To include Grafana configuration during installation, run the following exportcommand before running the installation process.
export ENABLE_DARK_LAUNCH_MONITORING=true\nYou are then prompted during the install to enable Grafana: Do you want to enable monitoring?.
If configuring Grafana after installation, see the following topics:
A Sametime deployment can be configured on a single-node Kubernetes clusters, like K3s or Docker Desktop, on a cloud-based, or on-prem multi-node cluster with separate control plane or worker nodes.
An Ingress Controller is required for web traffic.
The following white papers are available to review this setup for GKE (Google), AWS (Amazon) and on-premise configurations. Use these white papers for additional details on the installation and configuration steps for Kubernetes.
References to the cluster.yaml file in the white papers are based on Sametime 11.6. For later Sametime versions, the file is located in the Sametime installation package directory: install_package_directory/ /kubernetes/stack/eks/cluster.yaml.
If you are installing on an Openshift platform, review the Preparing to install an Openshift environment topic before starting the install process.
See the HCL Sametime\u00ae System Requirements document for support in Kubernetes and Helm versions.
Promethus can be used for tracking metrics and overall health of the system. Managed charts with Prometheus and metrics enabled are provided for convenience, otherwise, Prometheus should be installed manually before starting the Sametime installation process. See Installing Prometheus for details.
After the Kubernetes cluster is built, complete the following tasks to deploy Sametime.
Note: The helm charts and templates provided were tested with 1.22. Later versions of Kubernetes might not be compatible.
Using Sametime images from the HCL Harbor registry
Loading the Sametime images to a Docker repository The Sametime images must be in a Docker repository so that they can be accessed when running Sametime. They can be in a local Docker repository or they can be accessed from the HCL Docker repository.
Parent Topic: Installing Sametime
"},{"location":"admin/installation_sametime_kubernetes_managedcharts.html","title":"Installing Sametime in a Kubernetes using managed charts","text":"The Sametime product image includes pre-configured managed Helm charts to deploy HCL Sametime and HCL Sametime Premium. The managed Helm charts allow you to get a Kubernetes-based deployment up and running.
The managed charts include everything needed for a running deployment, such as: MongoDB, OpenLDAP, and NGINX Ingress Controller; and are ready to go with a single install operation. There is a variant of each chart that includes Prometheus and Grafana so that metrics can be monitored without any additional configuration. Each managed chart is provided as a TGZ bundle and can be installed using Helm or Helm Dashboard.
Note: Using the provided manage charts can be used to deploy LDAP, MongoDB as proof of concept. For production use, you must modify the charts to match the needs of your network.
Within the managed chart TGZ bundle is a values.yaml file. You can create a custom values.yaml file with configuration settings to override the settings of the supplied file. For example, the managed chart uses lvh.me as the host name, so that it can only be accessed through the local host from where it is being installed. You can provide a different value in the custom values.yaml file.
The customized values.yaml file can be created manually or by using the supplied prepareDeployment.sh script. For more information about the script, see Preparing the deployment. After the file is created, the customized values.yaml file can be archived and version controlled as necessary so that it can be applied to future updates, duplicated deployments with slight variations between each, and backed up for safe keeping so that the deployment can be recovered if necessary.
The managed charts are hosted on the HCL Harbor Registry so that deploying the charts can be cloud-native, without having to separate manage docker images on a per-node basis within an on-premise private registry.
Managed-file name Description sametime-single-node Install Sametime as a single node. sametime-single-node-metrics Install Sametime as a single node and includes Promethus and Grafana. sametime-multi-node Install Sametime as a multi-node environment. It includes Promethus and Grafana. Managed-file name Description sametime-premium-single-node Install Sametime Premium as a single node. sametime-premium-single-node-metrics Installs Sametime Premium as a single node and includes Promethus and Grafana. sametime-premium-multi-node Install Sametime Premium as a multi-node environment. It includes Promethus and Grafana.Note: A single-node installation cannot be installed in a multi-node cluster. It is designed without aspects that are typical for large deployments where there is concern about balancing resources across available nodes for performance and fault tolerance. You are can install the single-node deployment in a multi-node cluster as a \"minimal footprint\" deployment. If doing so, follow the steps in the Creating the persistent volume topic as you would if you were installing the multi-node deployment.
"},{"location":"admin/installation_sametime_kubernetes_managedcharts.html#task_iy1_lnf_pzb","title":"Using command line","text":"Verify that the container images have been loaded into a registry that is accessible to the Kubernetes cluster. For additoinal information, see Loading the Sametime images to a Docker repository.
When you install using Helm, make sure to override the registry configuration.
Load images into a private registry.
helm install sametime chart-name.tgz --set global.hclImageRegistry=my-custom-registry.myco.com\nCreate an image pull secret used to pull the container images from the HCL Harbor Registry. See Using Sametime images from the HCL Harbor registry for more information before running the helm install command.
helm install sametime chart-name.tgz\nIf you have configured Helm with authenication, you can pull the charts directly from the HCL Harbor Registry. After following the steps about accessing the container images from Harbor, you can configure that access token with Helm:
helm registry login -u your\\_email\\_address hclcr.io\nWhen prompted for a password, use the access token from your account profile in Harbor.
Use the helm install command to run the managed chart.
helm install install\\_name oci://hclcr.io/st/sametime-premium-single-node
Any customizations that should be applied to the deployment can be supplied in a custom values.yaml file rather than using --set options. To see the default values, examples, and documentation about settings you might want to customize, use one of the command:
helm show values chart-name.tgz
helm show values oci://hclcr.io/st/sametime-premium-single-node
You can copy-paste and modify any of the default values and then apply those settings like this:
helm install sametime sametime-premium-single-node-12.0.2.tgz -f values.yaml
where values.yaml is the file you have customized.
Alternatively, you can run:
./prepareDeployment.yaml values.yaml
and follow the prompts to produce a new values.yaml file with your customized configuration. You can use that as a starting point to make further edits as needed, for example. See Preparing the deployment for more information about how to respond to the prompts in the prepareDeployment tool.
Note: when using the prepareDeployment tool with a managed chart, there are additional prompts about whether the embedded mongo/openldap/coturn/nginx-ingress should be deployed. You can choose these to meet your needs.
Tools like helm-dashboard provide a user interface to manage deployments in a Kubernetes environment.
Start the Helm dashboard and point it to the chart to install as a local-repository.
helm-dashboard --local-chart=sametime-premium-single-node-12.0.2.tgz
Windows:
helm-dashboard.exe /local-chart=sametime-premium-single-node-12.0.2.tgz
Select the Repository tab and highlight the TAR file to be used and click Install.
The Install window displays information about the Helm Chart. You can modify and add values before running the chart. When finished, click Confirm.
You must complete the tasks in this topic if you are installing in an Openshift environment before you can install Sametime.
Refer to Planning for Openshift for consideratons related to namespace and video.
Deploy in a namespace. You can either create a namespace or use the default namespace. If you deploy Sametime into the default namespace, there are modifications that must be appled to the Helm chart.
Deploy to a new namespace
Create a namespace
export NAMESPACE=sametime\noc create namespace $NAMESPACE\nCreate the sametimeUser service account.
kubectl -n $NAMESPACE create serviceaccount sametimeUser\nCreate the SCC for sametimeUser account
oc create -f kubernetes/stack/openshift/sametime-restricted-v2.yaml\nApply the SCC to the service account.
oc adm policy add-scc-to-user sametime-restricted-v2 -z sametimeUser -n $NAMESPACE\nDeploy to default namespace
Edit the values.yaml file.
Comment out the seLinuxOptions: false setting for each of the following sections.
activityfilesrecordings For example:activity:\n fullnameOverride: activity\n persistence: {}\n# seLinuxOptions: false\nDeploy the video using one of the following methods.
Host Port
This is the default which provides the best performance and scales automatically scalable. This method requires pod-to-node affinity restriction through node labels. A separate video service account is required and the hostnetwork-v2 must be assigned to it.
oc create -f kubernetes/stack/openshift/sametime-hostnetwork-v2.yaml \nkubectl -n $NAMESPACE create serviceaccount videoUser \noc adm policy add-scc-to-user sametime-hostnetwork-v2 -z videoUser -n $NAMESPACE \nEdit the values.yaml to reference this video service account:
video:\n serviceAccount:\n name: videoUser\nUsing a load balancer is lower performance and has no pod-to-node restrictions. It requires the Kubernetes load balancing infrastructure.
Edit the values.yaml file to enable the loadBalanceVideo setting and reference the Sametime service account.
global:\n loadBalanceVideo: true\n...\nvideo:\n serviceAccount:\n name: sametimeUser\nUsing a node port is also lower performance but is restricted to a single node. It requires a no host-network SCC.
Edit the values.yaml file to add the following to the Sametime service account:
global:\n disableHostNetwork: true\n...\nvideo:\n serviceAccount:\n name: sametimeUser\nEdit the values.yaml file to disable the fsGroup and runAsUser settings, and reference the Sametime service account that you created.
global:\n ...\n disableFsGroup: true\n disableRunAsUser: true\n sametimeServiceAccount: sametimeUser\nContinue with the topics for installing in a Kubernetes environment.
"},{"location":"admin/installation_sametime_windows.html","title":"Installing Sametime on Windows using Docker Desktop","text":"Sametime can be installed on a Windows OS as a single-node environment using a supplied Helm chart. The Sametime product image includes a pre-configured managed Helm Chart to deploy Sametime on Windows. The chart is run from a Helm dashboard a graphical user interface.
The values in the Helm Charts can be modified before running the Install step. For example, you must specify the value for the location of the Sametime images. Other values such as the location of LDAP and other servers also need to be reviewed for your environment. The input fields in the managed charts are the same as if you were using the install script and prompted for values. See installation_prompt_descriptions.md for more information. Additionally, the Helm Charts contain information for each field to assist you with necessary updates.
Open the Windows Feature window and turn on the Windows Subsystem for Linux feature.
From the Control Panel, click Programs > Turn Windows features on or off. This feature allows you to install a Linux system and run a Linux file system, along with Linux command-line tools and GUI apps on Windows.
Install Docker Desktop.
From the Docker website, see Install Docker Desktop on Windows for install information and product download.
Docker Desktop is a Windows interface for interacting with a Docker system to manage images and containers.
Start the Docker Desktop.
From the Start menu, locate and click Docker Desktop.
There are multiple manage-Helm Charts located in the root of the Sametime install ZIP file. For Windows, you can use one of the following.
sametime-single-node : Install Sametime as a single node.
sametime-single-node-metrics : Installs Sametime and includes Prometheus and Grafana.
sametime-premimum-single-node : Install Sametime Premium as a single node.
sametime-premimum-single-node-metrics : Installs Sametime Premium and includes Prometheus and Grafana.
Enable Kubernetes.
From the Docker Desktop dashboard, click the Settings icon and then Kubernetes. Turn on the Enable Kubernetes. Click Apply and Restart.
Install the Help dashboard.
https://github.com/komodorio/helm-dashboard
Run the Helm chart to deploy Sametime.
Run the Helm Dashboard including the location of the TAR file containing the Helm Chart.
run helm-dashboard.exe /local-chart tar\\_file\\_path\nSelect the Repository tab and highlight the sametime-premimum-single-node file and click Install.
The Install window displays information about the Helm Chart. Make the necessary changes such as the value for where the Sametime images are located. You can modify and add values before running the chart. When finished, click Confirm.
This section provides information on installing the servers for Sametime and Sametime Premium.
The Connect client can be installed on a user's machine either by sending the install package to the user or by pushing the installation to the user's machine. In either case, the installation is an silent install.
Silent install is available only on the Windows platform.
The batch file used to start the install process is setup.bat. This batch file contains the setup.exe command with default parameter values to run the installer. You can modify the parameters. The following table shows the command parameters and default values.
Table 1. Parameters in the setup.bat file
Parameter Description install.log The name of the log file created by the installer. The file is created in the same directory as the installer. INSTALLDIR=installation_directory The full path of the installation directory. STSILENTINIFILE=ini_file_name Name of the configuration INI file. The default is silentinstall.ini . STSILENTINSTALL=TRUE Indicates the install is a silent install. This value must be TRUE for silent execution.The setup.bat file contains several different commands that can be used to perform different installation functions. Some of the commands are commented out by default, you can remove the comment tag and updated if the function is needed. Detailed explanations are included in the setup.bat file.
The silentinstall.ini file contains configuration parameters for the Connect client. The settings are used to populate the community-config.xml file with server connection information and other parameters required by the installer. The following table describes the configuration parameters.
Table 2. Parameters in the silentinstall.ini file
Parameter Description LAPAGREE=NO Specify whether to accept the license agreement. This value must beYES. The default value is NO. You must change this parameter to YES for silent install to work. CREATECOMMUNITYTEMPLATE=true Specifies whether community properties such as STSERVERNAME and STCOMMUNITYNAME are ignored. When set to false, the community-config.xml is not created in the installation_directory\\rcp\\deploy folder. All community-config properties should be put in the plugin_customization.ini in the installation_media_root_directory-root_directory\\deploy directory. If using a custom plugin_customization.ini, ensure that the value is set to true. STSERVERNAME=stservername.domain.com The fully qualified host name of the Sametime server. Normally this is the same as the home server specified in the person document. STCOMMUNITYNAME= community_name The name of the community. STSERVERPORT=1533 The IP port number of the Sametime server. STSENDKEEPALIVE=true Flag for sending keep-alive signal. STKEEPALIVETIME=60 Indicates how often to check the connectivity between the client and server, allowing timely notification if disconnected. The default is 60 seconds. STCONNECTIONTYPE75=direct The type of connection. Valid values are: direct, useBrowserSettings, tls-direct, http-direct, socks4-proxy, socks5-proxy, http-proxy, https-proxy, and reverse-proxy. The default value is direct. STPROXYHOST=proxy_host_name The host name of the proxy server. If you are not using a proxy, leave this field blank. STPROXYPORT=proxy_port_number The port number of the proxy sever. If you are not using a proxy, leave this field blank. STRESOLVELOCALY75= The proxy resolves local flag . Specify true or false. STPROXYUSERNAME= The user name for the proxy server. If you are not using a proxy, leave this field blank. STPROXYPASSWORD= The password for the proxy server. If you are not using a proxy, leave this field blank. STCOUNTRYLANG=en The language to be used by the Connect client. Specify the language code for the language to be used. The default vlaue is English. If a value is not specified, the client computer's default language is used. STAUTHSERVERURL= The URL of the authorization server for the SSO token log in. If you are not using an authorization server, leave this field blank. STLOGINBYTOKEN=false Specify whether to use the Login By Token flag. The default value is false. STUSEAUTHSERVER=false Specify whether to use the authorization server flag. The default is false. STLOGINATSTARTUP=false Specify whether the client logins at startup. The default is false. STUNINSTALL75=1 Specify whether to uninstall an existing 7.5 client if present. 1 Uninstall 7.5.x client if found 0 Leave 7.5.x client installed STUNINSTALLPRE75=1 Specify whether to uninstall an existing pre-7.5 client if present. 1 Uninstall pre-7.5 client if found. This is the default value. 0 Leave pre-7.5 client installed After you have edited the files to tailor the installer for your specific requirements, you can distribute the files to your end users. If the users are to run the installer, instruct them users to copy both of the files to the same directory and then execute setup.bat to install Sametime Connect.
Download the client installation package.
Copy the setup.bat and the silentinstall.ini files from the root of the download, and then update the files to meet your requirements.
Update the setup.bat file if necessary.
Update the silentinstall.ini file to match the environment.
Send or copy the updated files to the user's computer.
To start the install, run the following command:
setup.bat -silentinstall.ini\nParent Topic: Installing Sametime clients
"},{"location":"admin/installing_docker.html","title":"Installing Docker","text":"This section provides information on how to install Docker.
All commands provided require running as ROOT or SUDO access. If not running as root user, preface all commands with sudo.
Before installing Docker Compose, make sure Docker Engine is installed either locally or remote, depending on the environment. On Linux systems, install the Docker Engine for your OS provided in Install Docker Engine documentation. If you are following the Docker documentation to install the Docker Engine, docker compose must also be installed.
The following is an example of the install Docker Engine on CentrOS based on Docker documentation to support docker compose commands used when installing Sametime. The example is for demonstration only.
Note: CentOS ships with Docker installed, but not the most recent which is required. Install supported Docker version. See the HCL Sametime\u00ae System Requirements for details.
Uninstall old versions using the yum remove command provided in the Docker Engine documentation.
Install Docker Engine using a repository. First, install the yum-utils package which provides the yum-config-manager utility.
sudo yum install -y yum-utils \nThen set up the stable repository.
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo\nInstall the latest version of Docker Engine and container.
yum install docker-ce docker-ce-cli containerd.io \nAt this point, Docker is installed but might not be started.
Start Docker.
systemctl start docker \nVerify that Docker Engine is installed correctly by running the hello-world image.
docker run hello-world \nNote: If you right click links like Install Docker Compose and choose Open link in Tab you can complete these tasks and then close that tab to start the next step.
Install Docker Compose following steps and commands provided in Install Docker Compose topic in the Docker documentation. Docker Compose 1.29 or higher is required.
The following is an example of the install Docker Engine on CentrOS based on Docker documentation. The example is for demostration only.
Install Compose on Linux systems.
curl -L \"https://github.com/docker/compose/releases/download/1.29.0/docker-compose-$(uname -s)-$(uname -m)\" -o /usr/local/bin/docker-compose \nApply executable permissions to the binary.
chmod +x /usr/local/bin/docker-compose \nTest the installation.
docker-compose --version \nAfter the install is complete, use the following Linux shell command to confirm that Docker is running, which returns the docker information.
docker info\nIf Docker is not running, an error message is displayed indicating that a connection to Docker cannot be completed.
To start the Docker service, run the following command.
service docker start\nParent topic: Installing Sametime in a Docker or Podman environment
"},{"location":"admin/installing_mongodb_linux.html","title":"Installing MongoDB on Linux","text":"MongoDB can be downloaded from the MongoDB website. This topic includes the steps for installing in CentOS and RHEL environments. For information on installing MongoDB on other operating systems, refer to Install MongoDB.
If you already have MongoDB installed and are upgrading to MongoDB 4.4 or to the latest patch release, see the Upgrade to the Latest Revision of MongoDB document.
The commands used during the installation process require running as ROOT or SUDO access. If not running as root user, preface all commands with sudo.
Note: In the following steps, MongoDB version 4.4 is used as an example. If you are using a different version of MongoDB, refer to the MongoDB documentation for how to issue commands for the version that you are using.
Create a repository file for YUM to install MongoDB. Use the VI command to create and edit the mongodb-org-4.4.repo file.
cd /etc/yum.repos.d \n vi mongodb-org-4.4.repo\nNote: The vi command is a screen-oriented text editor originally created for the Unix operating system.
To edit the file, use Insert (I) and then copy and paste the following content:
[mongodb-org-4.4] \nname=MongoDB Repository \nbaseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.4/x86_64/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://www.mongodb.org/static/pgp/server-4.4.asc \nNote: When copying and pasting, ensure to include all characters. The dash (-) in the baseurl can be removed in certain scenarios.
Press Esc to exit insert mode.
To save and exit, use the wq command. Precede the command with a colon (:).
If you receive a E212: Can\u2019t open file for writing error message, it means that a root user is not being used or sudo access is being used.
If the repo URL is not available, manually download and install the rpm files. You can download the files from the Index of RPMS download page. For example:
mongodb-database-tools-100.5.1.x86_64.rpm \nmongodb-org-shell-4.4.9-1.el7.x86_64.rpm \nmongodb-org-tools-4.4.9-1.el7.x86_64.rpm \nmongodb-org-server-4.4.9-1.el7.x86_64.rpm \nmongodb-org-mongos-4.4.9-1.el7.x86_64.rpm \nmongodb-org-database-tools-extra-4.4.9-1.el7.x86_64.rpm \nmongodb-org-4.4.9-1.el7.x86_64.rpm\nAfter the download completes, install:
yum localinstall mongodb-database-tools-100.5.1.x86_64.rpm -y \nyum localinstall -y mongodb-org-database-tools-extra-4.4.9-1.el7.x86_64.rpm \nyum localinstall -y mongodb-org-4.4.9-1.el7.x86_64.rpm mongodb-org-mongos-4.4.9-1.el7.x86_64.rpm mongodb-org-server-4.4.9-1.el7.x86_64.rpm mongodb-org-shell-4.4.9-1.el7.x86_64.rpm mongodb-org-tools-4.4.9-1.el7.x86_64.rpm -y \nExecute YUM to install the MongoDB package.
yum install mongodb-org \nType y to confirm the download size.
Type y to accept the GPG key import.
A Complete! message is displayed when the installation process is finished.
Verify that the MongoDB components, user, default log, and data directories are created by checking if the following directories exist and are owned by mongod.
/var/log/mongodb
/var/lib/mongo
To start the MongoDB server, enter the command:
service mongod start\nTo stop the MongoDB server, enter the command:
service mongod stop\nTo verify the status of the MongoDB service, enter the command:
systemctl status mongod\nSet up a replica set with keyfile access control
Parent Topic: Installing MongoDB
"},{"location":"admin/installing_mongodb_windows.html","title":"Installing MongoDB on Windows","text":"MongoDB can be downloaded from the MongoDB website. This topic guides you through the steps for installing MongoDB on Windows.
For additional information on installing MongoDB on Windows, refer to Install MongoDB Community Edition on Windows.
Note: In the following steps, MongoDB version 4.4 is used as an example. If you are using a different version of MongoDB, refer to the MongoDB documentation for instructions on how to issue commands for the version that you are using.
Download the latest MongoDB version from the Download MongoDB Community Server page.
In the Available Download section, select the version to download.
From the Platform field, select Windows.
From the Package field, selectmsi. You have the option to download a msi or zip file.
Select Download.
Navigate to the folder where the MongoDB installation file was downloaded and run the msi file. This starts the installation process.
Follow the MongoDB Setup Wizard to complete the install. Select Next to view the license agreement. To continue, accept the license and select Next.
On the Choose Setup Type window, select Complete.
On the Service Configuration window, specify the following options and then select Next.
Installing MongoDB Compass\u202fis optional and not required for deploying Sametime. Clear the checkbox for Install MongoDB Compassand select Next.
If MongoDB Compass is installed, it starts after the installation process completes. You can shut down the MongoDB Compass application, as it is not used for Sametime deployments.
Select Install to complete the MongoDB installation. During the installation process, you might be prompted about files that cannot be updated while the system is running. You can choose to continue and manually restart the computer later.
After the install process completes, you must restart your computer.
When the installation process is complete, select Finish.
After the system restart, MongoDB automatically runs as a Windows service.
Verify that MongoDB installed successfully by opening the MongoDB console. To open the console, navigate to the MongoDB installation directory and locate the bin directory. For example: C:\\Program Files\\MongoDB\\Server\\4.4\\bin. Start the mongo application.
To close the console, type Exit on the command line.
Set up a replica set with keyfile access control
Parent Topic: Installing MongoDB
"},{"location":"admin/installing_on_docker.html","title":"Installing Sametime on Docker or Podman","text":"Installing Sametime involves starting the install procedure and specifying configuration information for the server, such as the credentials, the ports, MongoDB, and LDAP that the server uses.
Download the product from the HCL Software Portal.
The installation process detects if you are installing Sametime on Docker or Podman and prompts for the appropriate information.
Docker commands are used throughout the install process. All commands require running as a root user. If not running as root user, you must preface all commands with sudo. If you are installing on Podman, the commands are the same but instead of being preceded with Docker, the command is preceded with Podman.
Verify that the product files downloaded and extract to the desired installation directory.
Change to the installation directory and verify that the permissions are set correctly by running the following commands:
cd sametime\\_install\nls -la\nWhere sametime_install is the installation directory.
From the installation directory, run the Sametime install command.
./install.sh\nThe install command begins the installation of the Sametime product.
Enter the information for the prompts.
You are prompted to enter the following information. See Information to provide during installation.
If you are defining extra hosts, see Defining extra hosts for Docker deployments.
After the installation is completed, the HCL Sametime services that support chat and meetings should be running.
Test the Sametime chat and meeting services. For details, see Testing Sametime chat and meeting clients.
Parent Topic: Installing Sametime in a Docker or Podman environment
"},{"location":"admin/installing_sametime_clients.html","title":"Installing Sametime clients","text":"Sametime clients can be installed on a Windows or Mac machines.
Beginning with Sametime version 11, all directories and registries are HCL branded. If you are upgrading from a previous Sametime client, you must uninstall that version and then install Sametime version 11 or later. For version 12, upgrades on Windows and Mac are supported from a Sametime 11 client. Upgrades from a 9.0.1 or earlier versions on Windows are not supported. If you run a version of Sametime that is not supported for upgrades, you must uninstall that version and then install Sametime 11.
"},{"location":"admin/installing_sametime_connect_and_embedded.html","title":"Installing Sametime Connect and Embedded clients on Windows","text":"This topic covers basic installation for the Sametime standalone client on Windows.
Before getting started, it review the client installation customization options. Customizing the client can ease your deployment.
Decompress the client installation package into a temporary directory.
In the temporary directory, locate and double-click SETUP.EXE.
The installation process begins. When prompted, select the language to be displayed in the installation wizard windows.
From the Welcome screen, click Next.
On the License Agreement screen, review the license information.
To continue click I accept the terms in the license agreement and then click Next.
On the next screen, specify where to install the client and then click Next.
The default value for the Install location field is C:\\HCL\\Sametime Connect. You can select another location, you must remember it for future tasks.
Click Install to start the install process.
After the install is complete, click Finish.
Parent Topic: Installing Sametime clients
"},{"location":"admin/installing_sametime_connect_and_embedded_macos.html","title":"Installing Sametime Connect and Embedded clients on MacOS","text":"This topic covers basic installation for the Sametime standalone client on MacOS.
Before getting started, it review the client installation customization options. Customizing the client can ease your deployment.
Decompress the client installation package into a temporary directory.
In the temporary directory, locate and double-click SETUP.EXE.
The installation process begins. When prompted, select the lanaguage to be displayed in the installation wizard windows.
From the Welcome screen, click Next.
Review the license information.
To contine, click I accept the terms in the license agreement and then Next.
On the next screen, specify where to install the client and then click Next.
The defalt value for the Install location is C:\\HCL\\Sametime Connect. You can select another location, you must remember it for future tasks.
Click Install to start the install process.
After the install is complete, click Finish.
Parent Topic: Installing Sametime clients
"},{"location":"admin/installing_sametime_ios_and_android.html","title":"Installing Sametime iOS and Android clients","text":"You can find the latest HCL Sametime mobile clients in the Apple App Store and Google Play Store.
Refer to the Sametime mobile documentation for more information on mobile clients.
Parent Topic: Installing Sametime clients
"},{"location":"admin/keystore_third_party.html","title":"Creating a keystore for Sametime mux: third-party CA","text":"Two scenarios are described in this topic.
Scenario 1: A single certificate and private key are issued from the CA. : 1. Run the command to create the keystore.
``` {#codeblock_ych_tnq_ywb}\nopenssl pkcs12 -export -in server.crt -inkey server.key -name \u2018mux\u2019 -out keystore.p12\n```\n\nThe sample command makes use of the following naming conventions.\n\n``` {#codeblock_yqh_vpq_ywb}\n`server.crt`: Signed certificate filename\n`server.key`: Private key filename\n`\u2018mux\u2019`: Alias name (how it appears in the keystore)\n`keystore.p12`: The resulting keystore file name\n```\nScenario 2: A chained certificate which consists of multiple certificate files are provided, along with the private key. : 1. Use cat to combine the certificates into a single file (cert-chain.txt), which is used in the command. These certificates must be combined in this order: server, intermediate, CA root.
``` {#codeblock_zst_fqq_ywb}\ncat signed.crt intermediate.crt root_CA.crt > cert-chain.txt \n```\n\nIn the above example, the server\u2019s signed cert is `signed.crt`, the intermediate certificate is `intermediate.crt`, and the root CA certificate is `root_CA.crt`.\nRun the command to create the keystore.
openssl pkcs12 -export -in cert-chain.txt -inkey server.key -name \u2018mux\u2019 -out keystore.p12\nThe sample command makes use of the following naming conventions.
cert-chain.txt: File created from step 1 containing chained cert\nserver.key: Private key filename\n\u2018mux\u2019: Alias name \n`keystore.p12`: The resulting keystore file name\nAfter the keystore is created, do the following:
Parent Topic: Creating a keystore for Sametime mux
"},{"location":"admin/ldap.html","title":"LDAP","text":"An LDAP directory is needed for Sametime user authentication. The LDAP server must be running before deploying Sametime.
"},{"location":"admin/ldap.html#section_u2g_vbh_fwb","title":"System requirements","text":"Sametime works with V3-compliant LDAP servers.
"},{"location":"admin/ldap.html#section_kzg_qch_fwb","title":"Performance","text":"LDAP performance is critical to a successful deployment. Sametime is going to put a heavy load on LDAP. Consider the performance requirements of all Sametime LDAP traffic:
Part of your deployment plan may include adding more cluster members to the LDAP cluster.
To minimize the burden on LDAP, use minimal search filters wherever possible. Log in choices such as name, email address, employee ID, and so on, create longer search filters and greater performance loads on LDAP.
When planning for LDAP, don't forget Single Sign-On (SSO). Talk to your company's application teams about SSO. Propose a standard way that you allow people to log in to keep logins simple and minimal. All applications should utilize LDAP in the same way. If applications have different search filters, then this creates search problems and authentication problems.
"},{"location":"admin/ldap.html#section_jvf_rch_fwb","title":"Mail attribute","text":"Sametime requires the LDAP mail attribute in each person record.
The mail attribute provides performance advantages since translation between attributes is not required; it also provides consistency and integrity by using a common and well-understood attribute.
This attribute is not required for anonymous (guest) users. The attribute must be a unique string, which preferably follows the syntax and length restrictions of email addresses. In addition, the mail attribute must be populated for every user to support audio and video communications.
The mail attribute is not used for email purposes and does not have to be assigned as a user name for logging into Sametime. Instead, it serves as a common attribute between the various Sametime subsystems, such as calendar integration, business cards, LDAP, and REST APIs.
"},{"location":"admin/ldap.html#section_pkk_tch_fwb","title":"Multiple directory support","text":"Multiple directories are supported with the following restrictions:
If you use multiple LDAP repositories, you must ensure that the base entries do not overlap, as that causes problems when Secure Socket Layer (SSL) is enabled.
For example, the following base entries have a field in common, so they overlap:
o=renovations\no=sales,o=renovations\nThese base entries use different fields and are acceptable:
o=renovations,c=us\no=sales\nSametime might experience difficulties when users include large public groups in their contact lists. To avoid problems, limit the size of public groups used with Sametime to 1000 users.
"},{"location":"admin/ldap.html#section_un4_xch_fwb","title":"Upgrade considerations","text":"If you are considering moving from a native Domino directory to an LDAP directory, you must convert the user\u2019s names in the vpuserinfo.nsf file to LDAP format. This is done using the Sametime Name Conversion utility.
"},{"location":"admin/ldap.html#section_vdc_zch_fwb","title":"Best Practices","text":"The Best Practices for using LDAP with Sametime white paper contains an overview of LDAP components and describes how the Sametime Community Server works with LDAP to provide authentication, name look-ups, and name resolution. The article describes best practices for creating search filters, setting sametime.ini parameters, and enhancing Sametime and LDAP performance.
Parent Topic: Prerequistes
"},{"location":"admin/load_stimages_local.html","title":"Loading the Sametime images to a Docker repository","text":"The Sametime images must be in a Docker repository so that they can be accessed when running Sametime. They can be in a local Docker repository or they can be accessed from the HCL Docker repository.
If you prefer to use a local Docker repository, move the Sametime images from the product download file into the repository.
Download the HCL Sametime installation file from the HCL Software download portal.
The compressed file contains Sametime images, managed charts, scripts, configuration files and more.
Extract the zip file to any directory on the master Kubernetes host itself or on a machine which has management access to the Kubernetes cluster.
Change to that directory and load the docker images into your docker registry using the following command.
./load.sh\nThe load script extracts the docker images to the local host by default. When prompted, specify your Docker registry host FQDN. This can be a cloud provider registry or a private registry accessible to all of the nodes. If you do not have your own registry, run the load script on each node in the Kubernetes cluster and use the script defaults.
Note: If the commands fails accessing the Docker daemon, you can run the following command:
sudo ./load.sh\nUsing the sudo command temporarily gives you administrator privileges. For security purposes, it is best that you have administrator access than running with elevated privileges.
See Preparing the deployment.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/ltpa_configure_connections.html","title":"Integrating with HCL Connections","text":"You can integrate Sametime to enable chat services in HCL Connections.
Sametime and Connections must share a common directory.
If you are enabling the HCL Connections Profiles Photo URLs in your Sametime business card configuration, single sign on (SSO) might be required for Sametime to access the URLs.
When integrating with Connections, the LTPA key is generated by HCL Connections. To integrate with Sametime, you need to complete the steps in this topic on the Connections server and then complete the configuration on environment which Sametime is running: Docker or Kubernetes.
For SPNEGO and KERBEROS enabled environments, find the realm name.
This step is not needed if not using SPNEGO and KERBEROS.
Log into the WebSphere Application Server Integrated Solutions Console on the Deployment Manager.
Click Security > Global security.
Click Configure \u2026
On the Federated Repositories page, the Realm Name field contains the name.
Locating the domain name.
Click Security > Global security.
In the Authentication mechanisms and expiration area, expand Web and SIP security and select Single sign-on (SSO).
The Domain name field...
In the Domain name field, ensure that the DNS suffix for the Connections environment is present and preceded with a dot. If the Sametime DNS suffix is different from the Connections DNS suffix, then append it to the Domain name field as well. All DNS suffixes listed should be preceded with a dot.
For example: .example1.com example2.com
Select the check boxes for Interoperability Mode (optional) and Web inbound security attribute propagation. Make sure Set security to HTTP Only is not enabled.
Restart your Connections deployment.
If LTPA Export the LTPA key file.
Log into the WebSphere Application Server Integrated Solutions Console on the Deployment Manager.
Click Security > Global security.
In Authentication > Authentication mechanism and expiration select LTPA.
In the Password and Confirm password fields, enter the password that protects the exported key.
In the Fully qualified key file name field enter the path and file name for the key file that you want to generate
Click Export keys
Select Apply and then select Save.
Enter a file name and path to save the LTPA keys. The file will be exported to the Deployment Manager. This file needs to be retrieved from the Deployment Manager machine to be imported into Sametime.
Retreive the exported LTPA key file.
After obtaining the LTPA keys from HCL Connections, follow the steps in the Configuring LTPA in Docker or Podman or Configuring LTPA in Kubernetes topic.
Parent Topic: Setting up SSO using LTPA
"},{"location":"admin/ltpa_configure_docker.html","title":"Configuring LTPA in Docker or Podman","text":"This topic includes the steps to configure LTPA keys on Docker.
Update the .env file to reflect the following attributes and values.
ENABLE_LTPA=true\nLTPA_KEYS_FILE_PATH=key\\_file\\_path\nLTPA_KEYS=/ltpa-config/ltpa.keys\nLTPA_KEYS_PASSWORD=liberty\\_server\\_password\nLTPA_DURATION_MINUTES=minutes\\_token\\_valid\nThe value for key_file_path must be the absolute path to the file. For example, if keys are in the ltpa.key file and in the /opt/hcl/sametime directory.
LTPA_KEYS_FILE_PATH=/opt/hcl/sametime/ltpa.keys\nThe value of LTPA_DURATION_MINUTES must be the same as the value for the Domino web SSO token expiration.
Update the custom.env file to include the following.
STI__ST_BB_NAMES__ST_AUTH_TOKEN=Fork:Jwt,Ltpa\nUpdate the docker-compose.yml file to include the following.
SAMETIME_EXTERNAL_WARINTEGRATION=true\nOptional: If integrating with Connections and using a realm, add the realm name to the .env. For more information on integrating with Connections, see Integrating with HCL Connections.
LTPA_REALM=<realmname>\nParent Topic: Setting up SSO using LTPA
"},{"location":"admin/ltpa_configure_domino.html","title":"Integrating Sametime with HCL Domino","text":"This topic includes the procedure to enable LTPA when Sametime is integrated with the Domino server for use with web based mail, Verse and iNotes.
Before you start you need an LTPA key which as an example can be generated by WebSphere Liberty. For more information on using WebSphere Liberty to generate LTPA keys, see Generating LTPA keys.
You also must configure the LTPA keys on the Sametime server.
To configure the Domino server, you must create a Web SSO configuration document and import the WebSphere LTPA keys. The following procedure describes the steps which are completed on the Domino mail server.
Open the names.nsf and select the Web Configurations. Edit the Web SSO LtpaToken document.
Note: If a Web SSO LtpaToken document does not exit, it must be created from the Notes or Admin client Create menu. See Creating a Web SSO configuration document for the details.
Select Keys > Import WebSphere LTPA Keys.
Specify the path to the LTPA Keys file created following Generating LTPA keys and select OK.
Note: If prompted, select Format: LtpaToken and LtpaToken2 as the Use Token value.
Save and close the Web SSO LtpaToken document.
In the Domino mail server document under Internet Protocols - Domino Web Engine, select Multiple Servers (SSO) as the session authentication.
Start the Domino and Sametime servers to apply the changes. For more information, refer to Starting and stopping the Sametime server.
Parent Topic: Setting up SSO using LTPA
"},{"location":"admin/ltpa_configure_kubernetes.html","title":"Configuring LTPA in Kubernetes","text":"If you did not enable LTPA authentication during the installation of Sametime, you can enable it manually.
You must have already obtain the LTPA keys before you can compete this task. For more information on using WebSphere Liberty to generate LTPA keys, see Generating LTPA keys.
The changes in this task affect the following pods:
Obtain the base64 encoded value for your LTPA key file. The LTPA key file can be named anything and might have a file extension. For example if your LTPA key file name is ltpa.keys. Enter the following command to base64 encode the file:
cat ltpa.keys | base64 -w 0\nFor managed charts: ltpaKeysBase64: value
For traditional charts: ltpa.keys: value
Obtain the base64 encoded password to the LTPA Key file. For example, if the password is ltpapassword, enter the following command:
echo -n \u2018ltpapassword\u2019 | base64\nltpaKeysPasswordBase64: value\nDetermine the SSO token expiration time, which must be the same for all participating servers. To find the value in Connections see Integrating with HCL Connections. To find the value in Domino, see Creating a Web SSO configuration.
Now that you know the number of minutes until the token expires, create a new parameter and set it to the number of minutes. For example if the number of minutes is 120, then the parameter is:
ltpaDurationMinutes: \"120\"\nltpa.key file and find the name of the WebSphere realm. cat ltpa.key\nLook for the com.ibm.websphere.ltpa.Realm=defaultWIMFileBasedRealm parameter.
Create a new parameter with the value, for example:
ltpa.realm: defaultWIMFileBasedRealm\nIf you are using the managed charts, use the following steps. If you are using traditional charts, scroll down to the next section for traditional charts.
values.yaml file for editing. In the global section, add the parameters determined from above. Each line is indented with two spaces.
ltpaKeysBase64: value\n ltpaKeysPasswordBase64: value\n ltpaDurationMinutes: \"value\"\n ltpa.realm: value (for Connections only)\nAdd the following parameter to enable LTPA.
enableLtpa: true\nSave and close your custom values.yaml file.
For these changes to take effect, you must uninstall Sametime, then re-install referencing your custom values.yaml file.
If you are enabling LTPA using traditional helm charts instead of using the managed charts, complete the following steps.
Open the values.yaml file in the helm directory for editing.
Locate the following line and change the value from false to true.
enableLtpa\nAdd the parameters:
ltpaDurationMinutes: \u201cvalue\u201d\nltpa.ream: value (for Connections only)\nltpaKeysPasswordBase64: value \nSave and close the values.yaml file.
Change directories to helm/templates.
Open the auth-config-secrets.yaml file for editing.
In the ltpa.keys field, remove the text that is there, and add the base64 encoded value from step 1.
Save and close the auth-config-secrets.yaml file.
For these changes to take effect, complete the steps in Applying Changes.
If you are integrating with HCL Connections or HCL Verse, it might be beneficial to add a content security policy that includes the DNS suffix of the servers participating in the LTPA Single Sign On. For information, see Enabling content security headers on Kubernetes.
"},{"location":"admin/ltpa_generate_key.html","title":"Generating LTPA keys","text":"Lightweight Third Party Authentication (LTPA) uses keys to encrypt and decrypt data being passed.
The generated keys must be shared and configured within the Sametime server and must be available before you can configure SSO using LTPA.
Using an instance of Websphere Liberty is one method that you can use to generate LTPA keys. When the Websphere Liberty server is started an LTPA key is created. You can copy the key onto both the host machine and the Domino server.
From Docker, issue the following command to start a Websphere Liberty server.
docker run -d -p 9080:9080 -p 9443:9443 websphere-liberty:latest\nCopy the key from ltpa.keys from that instance:
docker cp container\\_id:/output/resources/security/ltpa.keys ./ltpa.keys\ncontainer_id is the Websphere Liberty container ID. To obtain the container ID, open a terminal and issue the following command:
docker ps\nThe default password used by Websphere Liberty is WebAS.
Configure the LTPA keys in Docker or Kubernetes where Sametime is running.
Parent Topic: Setting up SSO using LTPA
"},{"location":"admin/managed_community.html","title":"Managed community settings","text":"Define managed community settings in the managed-community-configs.xml file.
The managed-community-configs.xml file uses these element types:
Only define attributes that are mandatory. For example, do not include the \"loginAtStartup\" attribute unless you want to prevent your users from changing that setting. If the user's configuration differs from any defined attribute, the user's configuration is updated. Although you cannot lock the user interface, any settings that a user changes during a session revert back at the next login.
The following tables describe the attributes for each element. The required attributes must be present in the file.
Attribute Required? Description deleteOverlappingCommunities No Whether or not overlapping duplicate communities should be deleted. The default is \"false\". An overlapping community is one in which the community host and userid are the same. An overlapping duplicate community can occur when you use a managed-community-configs.xml file to consolidate multiple hosts into a single community. The Sametime\u00ae client may have a community for each host; updating each to the same new host name would result in duplicate overlapping communities. To ensure that duplicate overlapping communities are consolidated into one, set this attribute to true. id Yes The unique ID of the managed community. This setting should be the same value as the \"host\" attribute. host Yes The host to manage. The client only updates communities whose host matches the host of the managed community. newHost No Attribute used to update the host of a community that matches the \"host\" attribute. This is the new host to connect to. The attribute only applies to \"update\" type managed community actions. The user's contact list is assumed to be valid for the new community. If the contact list is not valid, use the \"reset\" managed community action instead. name No The name of the community. Not recommended. To set the community ID, use ST_COMMUNITY_ID in the server's sametime.ini to set the community name for all clients. savePassword No Whether or not to save the password. Set the value to \"true\" to save the password. loginAtStartup No Whether or not to automatically log in. Set the value to \"true\" to log in automatically. useGlobalConnContext No Whether or not to use the global connection context. You must set this to \"true\" if you are updating connectionType to a value other than \"direct\". connectionType No The connection type corresponds to the options in the Connection settings page. Valid values include useBrowserSettings, direct, tls-direct, http-direct, socks4-proxy, socks5-proxy, http-proxy, and reverse-proxy. authServerUrl No The server URL for SSO authentication. authType No The authentication type for SSO. Value can either be TAM-SPNEGO or ST-DOMINO-SSO. port No The port to use if it is not the default 1533. proxyHost No The hostname of the proxy. proxyPort No The port of the proxy. loginByToken No Whether or not to log in by token. Set the value to \"true\" to log in by token. Note that if the token login fails and the password is available, the password-based authentication will proceed. sendKeepAlive No Whether or not to send the keep alive signal. Set the value to \"true\" to send the keep alive signal. keepAliveInterval No The interval at which to send the keep alive signal. Attribute Required? Description managed-community-id Yes The unique ID of the managed-community. Use the same value as the \"host\" attribute of the managed community type Yes The type of action. Values can be \"update\", \"add\", \"delete\" or \"reset\".- Add actions result in the addition of secondary communities. - Delete actions result in the deletion of secondary communities. The default community cannot be deleted. - Update actions result in an update to communities whose host value match the host value of the managed community. If no attributes are different, the update action does not result in any change. - Reset actions are used to reset the client configuration to a new default community. If a reset action is found, it is applied before any other action type and no other actions are processed. The user is prompted to restart, but may opt not to. The managed community referenced by the reset action represents the new default community that is to be used when the user next restarts.| |restart|No|By default, update actions only result in a restart if the host name is changed. Add this optional attribute and set the value to \"true\" to restart the client after other update events. To prevent the default restart after the host name is changed, add this attribute, but set it to \"false.\"| |applyDefaultCommunityUsername|No|Attribute that can be used with an \"add\" type managed community action to indicate whether or not the default community user name should be applied to the new community when it is added. Set the value to \"true\" apply the default community user name.| |createNewConfig|No|Optional attribute for use with the reset action type. When you set this to \"true,\" the previous default community is completely replaced by the new community. The user name and password are empty, requiring the user to repopulate these values. Without this attribute, or with the attribute set to false, the new default community configuration enabled with a reset action retains the user name, password, and connection options of the former default community.|
"},{"location":"admin/managed_community.html#sample-managed-community-configs-file","title":"Sample managed-community-configs file","text":"The following sample file adds a new community and updates two others. The connection type is reverse-proxy.
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<managed-communities>\n <managed-community id=\"sales.usma.example.com\" host=\"sales.usma.example.com\" loginByToken=\"true\" authServerUrl=\"http://sales.usma.example.com\" authType=\"SAMPLE\" useGlobalConnSettings=\"false\">\n <connection connectionType=\"reverse-proxy\" proxyHost=\"http://usma.example.com:81/sales\"/>\n </managed-community>\n <managed-community id=\"sametime.example.com\" host=\"sametime.example.com\" newHost=\"sametimenew.example.com\"/>\n <managed-community id=\"sametimenew.example.com\" host=\"sametimenew.example.com\"/>\n <managed-community-action type=\"update\" managed-community-id=\"sales.usma.example.com\"/>\n <managed-community-action type=\"update\" managed-community-id=\"sametime.example.com\"/>\n <managed-community-action type=\"add\" managed-community-id=\"sametimenew.example.com\"/>\n</managed-communities>\nAction examples
Adding a new community
The following example adds a new secondary community using the global connection defaults. Administrator-defined secondary communities are not impacted by the Allow user to add multiple server communities policy. Even if the policy is set to Not selected, the client recognizes they are defined by the administrator and allows the user to log into them. Administrator-defined communities cannot be deleted.
<managed-communities>\n<managed-community id=\"acct.sales.usma.example.com\" host=\"acct.sales.usma.example.com\"/>\n<managed-community-action type=\"add\" managed-community-id=\"acct.sales.usma.example.com\"/>\n</managed-communities>\nUpdating the default community host
This example updates the default community host from \"sales.usma.example.com\" to \"sales2.usma.example.com.\"
<managed-communities>\n<managed-community id=\"sales.usma.example.com\" host=\"sales.usma.example.com\" newHost=\"sales2.usma.example.com\"/>\n<managed-community-action type=\"update\" managed-community-id=\"sales.usma.example.com\"/>\n</managed-communities>\nUpdating the default community host again
This example updates the default community host from \"sales.usma.example.com\" or \"sales2.usma.example.com\" to \"sales3.usma.example.com.\"
<managed-communities>\n<managed-community id=\"sales.usma.example.com\" host=\"sales.usma.example.com\" newHost=\"sales3.usma.example.com\"/>\n<managed-community id=\"sales2.usma.example.com\" host=\"sales2.usma.example.com\" newHost=\"sales3.usma.example.com\"/>\n<!-- Ensure existing sales community hosts that missed the first \"sales2\" update, or that manually reverted, are updated to sales3 -->\n<managed-community-action type=\"update\" managed-community-id=\"sales.usma.example.com\"/>\n<!-- Ensure existing sales2 community hosts are updated to sales3 -->\n<managed-community-action type=\"update\" managed-community-id=\"sales.usma.example.com\"/>\n</managed-communities>\nUpdating the secondary community host
This example updates \"acct\" to \"acct2\" and ensures acct2 is added as a secondary community for all new users.
<managed-communities>\n<managed-community id=\"acct2.sales.usma.example.com\" host=\"acct2.sales.usma.example.com\" />\n<managed-community id=\"acct.sales.usma.example.com\" host=\"acct.sales.usma.example.com\" newHost=\"acct2.sales.usma.example.com\" />\n<!-- Ensure acct2.sales.usma.example.com community is created for all users that don't yet have it -->\n<managed-community-action type=\"add\" managed-community-id=\"acct2.sales.usma.example.com\"/>\n<!-- Ensure existing acct.sales.usma.example.com community hosts are updated to acct2.sales.usma.example.com -->\n<managed-community-action type=\"update\" managed-community-id=\"acct.sales.usma.example.com\"/>\n</managed-communities>\nUpdating the secondary community host again
This example updates \"acct2\" to \"acct3\", and also ensures acct3 is added as a secondary community for all new users.
<managed-communities>\n<managed-community id=\"acct3.sales.usma.example.com\" host=\"acct3.sales.usma.example.com\"/>\n<managed-community id=\"acct2.sales.usma.example.com\" host=\"acct2.sales.usma.example.com\" newHost=\"acct3.sales.usma.example.com\" />\n<managed-community id=\"acct.sales.usma.example.com\" host=\"acct.sales.usma.example.com\" newHost=\"acct3.sales.usma.example.com\" />\n<!-- Ensure acct3.swg.usma.hcl.com community is created for all new users -->\n<managed-community-action type=\"add\" managed-community-id=\"acct3.sales.usma.example.com\"/>\n<!-- Ensure existing acct2.sales.usma.hcl.com community hosts are updated to acct3.sales.usma.example.com -->\n<managed-community-action type=\"update\" managed-community-id=\"acct2.sales.usma.example.com\"/>\n<!-- Ensure existing acct2.sales.usma.example.com community hosts that missed the first \"acct2\" update, or that manually reverted, are updated to acct3.sales.usma.example.com -->\n<managed-community-action type=\"update\" managed-community-id=\"acct.sales.usma.example.com\"/>\n</managed-communities>\nSwitching users to a new default community with a different user directory
If the new community is a different community with a different user backend, use the reset managed-community-action type to reset the user to the new community. Assuming the user credentials are valid in the new community, after restarting, the user logs into the new community. To include additional secondary communities as part of this new configuration, define them on the new server's managed-community-configs.xml file, using add actions for the desired secondary communities. When the reset action is found, if the current default community does not match the community defined by the administrator, or if createNewConfig is set to true, the client saves the new configuration locally. When the client next restarts, the default community defined by the administrator replaces the previously defined default community.
<managed-communities>\n<managed-community id=\"acct.sales.usma.example.com\" host=\"acct.sales.usma.example.com\"/>\n<managed-community-action type=\"reset\" managed-community-id=\"acct.sales.usma.example.com\"/>\n</managed-communities>\nConsolidating multiple communities to a single community
This example consolidates multiple communities with various hosts into a single community with one host.
<managed-communities deleteOverlappingCommunities=\"true\">\n<managed-community id=\"sales1.usma.example.com\" host=\"sales1.usma.example.com\" newHost=\"sales.usma.example.com\"/>\n<managed-community id=\"sales2.usma.example.com\" host=\"sales2.usma.example.com\" newHost=\"sales.usma.example.com\"/>\n<managed-community id=\"sales3.usma.example.com\" host=\"sales3.usma.example.com\" newHost=\"sales.usma.example.com\"/>\n<managed-community-action type=\"update\" managed-community-id=\"sales1.usma.example.com\"/>\n<managed-community-action type=\"update\" managed-community-id=\"sales2.usma.example.com\"/>\n<managed-community-action type=\"update\" managed-community-id=\"sales3.usma.example.com\"/>\n</managed-communities>\nParent Topic: Updating connectivity settings with the managed-community-configs.xml file
"},{"location":"admin/managing_sametime_client_preferences.html","title":"Managing Sametime clients","text":"This section provides information on managing Sametime clients.
Parent Topic: Administering
"},{"location":"admin/managing_sametime_premium.html","title":"Managing Sametime features","text":"HCL Domino users are entitled to limited use of HCL Sametime chat capabilities.
The following chat features are not available to HCL Domino users. In Sametime version 12.0, these features are disabled by default.
For a complete list of Sametime features, see Sametime versus Sametime Premium.
Parent Topic: Considerations for Sametime Premium
"},{"location":"admin/managing_secrets_kubernetes.html","title":"Managing secrets in Kubernetes","text":"Sensitive information such as passwords, service account names, certificates, and other confidential data needed by Sametime pods are stored in secrets. In addition to helm charts and configuration map, the Sametime configuration is also derived from secrets.
A secret is considered part of the live runtime or the current configuration. Secrets are created based upon a template or a command line. You can modify the templates to re-create secrets if needed. An example is when you need to update your LDAP bind credentials. For more information see, Changing the LDAP service account password in Kubernetes.
For additional information about secrets in Kubernetes, see the Secrets topic in the Kubernetes documentation.
Some secrets are required by Sametime. They are created during the installation and configuration of Sametime.
Some secrets are required by Sametime and others are based on features being used, such as SAML. The following are global secrets that are required.
"},{"location":"admin/managing_secrets_kubernetes.html#table-1-required-secrets","title":"Table 1. Required secrets","text":"Secret Description Template sametime-global-secrets Thehelm/templates/sametime-secrets.yaml is used to define this secret. helm/templates/sametime-secrets.yaml Note: that all values within this secret are based64 encoded. The following parameters are contained in the global secret.JwtSecret The secret key used by the Sametime service to verify and decide the hash of JWT tokens. LdapBindEntryDn The LDAP Bind account. LdapBindEntryPassword The password for the LDAP bind account. MongoConnectionUrl The MongoDB formatted URL containing the login name and password used by Sametime. The host name and port number are also included. JigasiSipUri The name of the of the account and the host name of the SIP user fortelephony integration with ilink. JigasiSipPassword The password for telephony integration with ilink. ltpaKeysPassword The password for the LTPA keys. MeetingLocationSecret The secret key used to communicate to the primary location service. JvbAuthPassword The password for the JVB authentication account. sametime-internal-keys-secret Contains information about the certificate key store. None tls-secret The name of this secret can vary because it is configurable. The name can also vary depending on the ingress controller. The ingress controller might be secured with a certificate within a secret as well. None The following are default internal secrets and based off the listed template. Do not change the content within these secrets unless instructed by the software support team.
"},{"location":"admin/managing_secrets_kubernetes.html#table-2-internal-secrets","title":"Table 2. Internal secrets","text":"Secret Name Template app-registry-config-secret helm/templates/app-registry-config-secrets.yaml auth-config-secret helm/templates/auth-config-secrets.yaml catalog-config-secret helm/templates/catalog-config-secrets.yamlThe following is a list of optional secrets that are dependent on a feature being enabled, such as SAML.
"},{"location":"admin/managing_secrets_kubernetes.html#table-3-option-secrets","title":"Table 3. Option secrets","text":"Secret name Description extra-community-config A configurable secret that contains extra configuration details for the Community pod. It can contain a copy of the StCommunityConfig.xml, UserInfoConfig.xml, and other community files. ldap-config-secret The certificate trust store and password for LDAP. See Securing LDAP on Kubernetes for more details. saml-config-secret The certificate trust store and password for SAML. See Configuring SAML in Kubernetes for more details."},{"location":"admin/managing_secrets_kubernetes.html#considerations-for-when-namespaces-are-used","title":"Considerations for when namespaces are used","text":"In Kubernetes, the Sametime cluster can be deployed in a namespace which makes administration easier for organizations that have multiple users sharing cluster resources. For example, you might want to run MongoDB in the same Kubernetes cluster as Sametime. They could be separated into different namespaces.
When creating secrets in a Sametime cluster that is scoped to a namespace, the secrets also need to be scoped to the same namespace where Sametime is installed. To define the namespace, add the -n argument followed by the namespace name to the command. For example, the following shows the get command for a namespace with the name st.
kubectl get secrets -n st\nParent Topic: Configuring
"},{"location":"admin/meeting_report_kubernetes.html","title":"Disabling reports on Kubernetes","text":"Change to the helm directory where the Sametime installation package was decompressed.
cd helm\nOpen the values.yaml file and put in edit mode.
Locate the meetingReportsDisabled value and change the value to false.
MeetingReportsDisabled: false\nSave and close the values.yaml file.
Edit the docker-compose.yml file.
Locate the MEETING_REPORTS_DISABLED variable.
Specify true to disallow report generation or false to allow the meeting owner to determine if reports can be generated.
Save the changes.
To apply the changes, stop the Sametime server and then start it again.
Run the following command to stop the server.
docker-compose down\nRun the following command to start the server.
docker-compose up -d\nThis contains configuration steps specific to the HCL Sametime Meetings server.
Parent Topic: Configuring
"},{"location":"admin/meetings_configuring_max.html","title":"Configuring the maximum number of meeting participants","text":"A maximum of 100 users are supported in a meeting regardless of the selected meeting mode. To reach a wider audience, you can start a live stream and share the link to all intended participants.
You can lower the maximum capacity to any value below 100 as needed. Users who attempt to join a meeting that has reached maximum capacity receive a message indicating that the meeting room is full.
The number of meeting video streams that display in the Meeting window is based on the following:
For example, if the maximum number of participants is 50 and value for maximum video streams is 7. The number of participant tiles displayed is fifty. However, the number of displayed video streams is seven, which includes you. That is, six other video streams plus your video stream are displayed. The six participants displayed are the most active video streams and change as participation in the meeting changes.
The default for the maximum number of displayed video streams is nine. To set the maximum to a different value, see Increasing the number of video streams displayed during a meeting.
Parent Topic: Meetings
"},{"location":"admin/meetings_configuring_max.html#task_wwg_dfz_wxb","title":"Configuring the maximum number of meeting participants in Docker environment","text":"Open the docker-compose.yml file for editing.
Under the prosody section, specify the number of maximum participant in the MAX_OCCUPANTS parameter.
MAX_OCCUPANTS=max\\_number\\_meeting\\_participants\nSave the docker-compose.xml file.
Restart the Sametime Meeting server.
Open the helm/values.yaml for editing.
vi helm/values.yaml \nSpecify the number of maximum participant in the MaxOccupants parameter.
MaxOccupants=max\\_number\\_meeting\\_participants \nSave the file.
Restart the Sametime Meetings server.
You can set up your environment to allow users to dial in to a meeting using a SIP-capable phone system that is connected to a public switched telephone network (PSTN). This feature uses the ilink TeamCall Meeting Gateway (TMG).
To enable meeting dial-in, the following must be installed in your Sametime server:
To enable your Sametime environment for dial-in, you must contact an ilink sales representative at sales@ilink.de. The ilink professional service team performs a remote installation. After the TMG is installed, it runs in the background and no administrator support is required.
The TeamCall Meeting Gateway for HCL Sametime Premium provides audio waiting rooms for moderated meetings.
If the user experiences dial-in or telephony problems, they must contact ilink support at sales@ilink.de to open a ticket for assistance.
Additional information can be found at the following:
Parent Topic: Meetings
"},{"location":"admin/meetings_passwords.html","title":"Defining Meetings password requirements","text":"The default requirement for a meeting is that the password must be at least eight characters. To increase the password requirements, additional rules can be specified.
A meeting owner can define a meeting password when creating a meeting. When a meeting participant logs into the meeting and the password rules are displayed as the password is typed. As a requirement is met, a green circle with a check mark is displayed next to the requirement.
You can set one or more of the following rules to increase password strength.
Include at least one number. The default is false.
Edit one of the following files.
Locate and update the following parameters.
Docker
REACT_APP_PASSWORD_MIN_LENGTH=password\\_length\nREACT_APP_PASSWORD_SPECIAL_CHARS_REQUIRED=false\nREACT_APP_PASSWORD_UPPER_CASE_REQUIRED=false\nREACT_APP_PASSWORD_LOWER_CASE_REQUIRED=false\nREACT_APP_PASSWORD_DIGITS_REQUIRED=false\nKubernetes
passwordMinLengthRequired: password\\_length\n passwordSpecialCharsRequired: false\n passwordUpperCaseRequired: false\n passwordLowerCaseRequired: false\n passwordDigitsRequired: false\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping servers.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/microsoft_outlook_deploy.html","title":"Deploying Microsoft Outlook add-ins to users","text":"An administrator can centralize the deployment the HCL Microsoft Add-in so that it is available for users within the organization.
See Determine if Centralized Deployment of add-ins works for your organization.
To distribute the HCL Microsoft Outlook add-in within your environment use the Office 365 admin center. The deployment can be assigned to all users or to specific users and groups. When deployed, the Get Addin button to be available to users.
For additional information, see the Micorsoft Deploy add-ins in the Microsoft 365 admin center topic.
Open the Microsoft Outlook admin center.
Click Deploy Add-in and clickNext.
Click Upload custom apps.
Select where to upload the add-in from.
You should normally choose Add from URL and enter the URL for your Sametime Meetings add-in. For example: https://host_name_url/outlook/manifest.xml. If the URL is not publicly accessible, open the URL and save the XML file, then select the Add from file.
Click Upload.
Choose which users and groups to deploy to and whether the add-in is mandated or not.
Click Deploy.
Deployment can take up to 24 hours. Outlook clients must launched their Outlook client again for the add-in to appear in the user interface.
Parent topic: meetings_configuring.md
"},{"location":"admin/migrating.html","title":"Migrating and Upgrading","text":"This section provides information on migrating data from an earlier release to Sametime 12.
Review the Planning for migration to Sametime 12 topic.
In Sametime 9.x, 10.x and 11.x, vpuserinfo.nsf stores all the contact list for users. Before you can migrate contact lists to MongoDB, you must first convert the vpuserinfo.nsf data to LDAP using the Stnamechange utility on your current deployment environment.
On the Sametime server being migrated, decompress the notes-migration.zip file to the server's program directory where the Sametime 12 product image was placed.
You must run this command from the Sametime server's program directory where the sametime.ini and notes.ini files exist.
For Linux, run the following commands to setup the environment. Otherwise, skip to the nex step and perform the migration task.
source ./setenv.sh\nRun the following command to move your contact list to MongoDB. Before the migration begins, you are prompted for locations and options.
Linux
./notes-migration.sh\nWindows
notes-migration.bat\nParent Topic: Planning for migration to Sametime 12
"},{"location":"admin/migrating_dominodirectory.html","title":"Converting from native Domino directory to LDAP","text":"Review the Planning for migration to Sametime 12 topic.
If the older Sametime deployment is not configured for LDAP, the contact lists must be converted using the Stnamechange utility before migrating. The Stnamechange utility is not available on Sametime 12. Run the utility on Sametime 9, 10, or 11 before migrating.
For previous Sametime versions, see the Changing user names topic for the version that is being migrated to Sametime 12.
The LDAP task is used to convert to LDAP. Run the task on the older Sametime Community server.
Parent Topic: Planning for migration to Sametime 12
"},{"location":"admin/migrating_moveusers.html","title":"Moving the users","text":"Review the Planning for migration to Sametime 12 topic.
After you are finished testing of the new Sametime version and are ready to migrate the users, you can use one of the following strategies.
Parent Topic: Planning for migration to Sametime 12
"},{"location":"admin/mongodb.html","title":"MongoDB","text":"MongoDB is used to store data for persistent chat, mobile push notifications, meetings, and contact lists.
If you have an existing MongoDB deployment, you can use it. However, if you do not already have MongoDB installed, you must install one or use a cloud-based MongoDB. MongoDB can be installed on a separate server or in the same Kubernetes cluster as Sametime. As with the storage size needed, the use of a dedicated server depends on your organization. After MongoDB is installed or if using a cloud-based MongoDB, it must be defined to communicate with the Sametime server. If installing your own MongoDB, see Installing MongoDB for additional information. For information about using the cloud-based MongoDB, see Using MongoDB on cloud.
Data related to chats and meetings is stored in MongoDB. This includes screenshots, emojis, chat logs, meeting reservation information, and contact lists. By default, data is saved for 90 days. You can change the default on the time-to-live (TTL) setting. For more information, see Updating the time-to-live index for persistent chat.
Data is stored in the data/db path which is specified in the mongod.conf configuration file. When determining the size of your MongoDB, consider the activity used by users in your organization. Refer to the MongoDB documentation for information on setting the size of the database.
Parent Topic: Prerequistes
"},{"location":"admin/mongodb_cloud.html","title":"Using MongoDB on cloud","text":"MongoDB Atlas is a cloud-based database that can be used to maintain Sametime data.
Before the Sametime server can communicate with the MongoDB Atlas, you must have an Atlas account. To sign-up for an account, refer to the Try MongoDB Atlas website.
Log into your MongoDB Atlas account.
Access the Atlas user interface.
Click Connect.
Select the driver from the dropdown list.
Select whether to use password or x.509 encryption.
In the box under View full code example, is the URL to the MongoDB on Atlas. You can use the copy icon to copy the URL. The following is an example URL:
mongodb+srv://Admin:<password>@cluster0.EXAMPLE.mongodb.net/?retryWrites=true&w=majority\nAtlas requires TLS to connect to the service.
You must update the URL to add your truststore file location.
mongodb+srv://Admin:<password>@cluster0.EXAMPLE.mongodb.net/?retryWrites=true&w=majority&tlsCAFile=truststore\\_location\nMap the truststore file into the Community container.
volumes:\n - truststore\\_location\nSametime meetings generate two types of traffic: web traffic and RTP media streams. Web traffic is standard HTTPS. And media streams by default use UDP for optimal performance. If the UDP service is unavailable, enabling TCP for RTP media streams is supported.
To support the Sametime default configuration, use the following ports for client access:
If you enable TCP for media streams, you can configure it to use TCP port 443. However, it does not send media streams as HTTPS data. Confirm with your security and firewall teams that this non-standard use of HTTPS port 443 is permitted.
The amount of bandwidth consumed by Sametime Meetings depends on several factors, such as the quality of the video being shared, the number of video and audio streams being shared, and more. The default limit for simultaneous video streams is 8. Increasing this value affects bandwidth consumption. For more information, refer to Increasing the number of video streams displayed during a meeting.
You must discuss the design of your Sametime deployment with your network and security teams before implementation. Many common network layer devices and technologies introduce latency, which can degrade the user experience. Identify all potential bottlenecks, for example, firewall, proxy, VPN, packet shapers, and intrusion prevention devices before deploying servers.
Parent Topic: Planning
"},{"location":"admin/overview_encryption.html","title":"Encryption usage in Sametime","text":"HCL Sametime uses several types of encryption to protect data.
The following table lists the types of encryption for various types of data and the length of each type of encryption key.
Algorithm Mode Related key length Function HMAC-SHA256 Integrity check 256-bit (through server shared secret) Hash-based message authentication code (HMAC) that protects the integrity of JSON Web Tokens (JWT). SHA256 Signature 256-bit Generates an almost-unique 256-bit (32-byte) signature for a text or data file. RC2 Confidentiality (all applicable user data) Various key length (40-bit or 128-bit in different circumstances; generated using Diffie-Helman) Encrypts field data or messages between client to client and client to server. This is the default encryption used in the Sametime Connect and Embedded clients. TLS 1.2 In-transit data 128/256-bit depending on cipher chosen Provides security including privacy, by encrypting data sent over the internet through the use of certificates between a client and a server. DTLS/SRTP In-transit data 256-bit Prevents hacks or man-in-the-middle attacks against voice communications between a client and a server. OLM In-transit data 256-bit Provides end-to-end encryption between client-to-client media. bcrypt Stored data 10 salt rounds Hashes passwords stored in the database.Parent Topic: Securing
"},{"location":"admin/plan_cluster_chat.html","title":"Configure high capacity for chat","text":"Sametime supports up to 10,000 simultaneous log-ins with a standard single community pod, mux pod, and proxy pod in a Kubernetes deployment. Docker deployments of Sametime support 10,000 simultaneous log-ins.
The Sametime mux is used for front-end client connections between the Sametime Connect client and the Sametime Embedded client inside of HCL Notes. If you need additional capacity for these clients, you can deploy multiple community pods inside your Kubernetes cluster. The number of community pods is defined in the values.yaml file, and each additional pod supports up to 10,000 additional clients. The community pod does not axiomatically scale. It is important to estimate the number of pods needed and define the setting in the values.yaml file.
When changing
In the values.yaml file, ensure that this setting is set to true, which is the default setting:
enableMuxDeployment: true\nChange the below setting to the desired number of community pods:
numberOfCommunityServers: 1 \nTo find the Kubernetes service that front-ends the mux issue the command:
kubectl get svc | grep mux \nThe ingress controller in a Kubernetes cluster front-ends the connection to the web and mobile clients and the proxy pod services those connections. Additionally, the community pod validates log ins and service the users as well. Sametime supports up to 10,000 simultaneous connections in a Kubernetes environment, and if more are needed deploy an additional 1 ingress controller pod, 1 proxy pod, and 1 community pod per 10,000 web and mobile clients.
Apply your changes to the environment run the helm uninstall command and after it completes, run the helm install command.
If you are not changing the value from or to a value=1, run the helm upgrade command to apply the changes.
Parent Topic: Clustering and high availability
"},{"location":"admin/plan_cluster_meetings.html","title":"Configure high capacity for meetings","text":"High availability is supported for the front-end web traffic to the Kubernetes cluster. You can deploy multiple front ends on different physical and virtual nodes pointing to the same back end in order to distribute load and survive a node outage.
High availability is not supported for active meetings, but failover is supported. If a server hosting a meeting goes down, users who are in meetings on that server are briefly interrupted. The client reconnection timer reconnects the clients and distributes them to an available node. In some circumstances, a server that stops responding causes a client to disconnect from a meeting. Users can reconnect to the meeting from their recent meetings list and rejoin the meeting on an available server.
Sametime can be expanded to more than one geography or another network by deploying multiple video bridges. This is different from deploying multiple video nodes, which are all co-located. When you deploy multiple video bridges the user receives audio and video from the video bridge that is located the closest to them. For more details, see Configuring autoscaling for video.
For sizing and deployment related questions, contact an HCL support professional by completing the Talk to a Technical Expert form.
"},{"location":"admin/plan_cluster_meetings.html#section_mhc_fqk_bvb","title":"Docker","text":"Meetings are sized based on what is happening in the environment at any given time. For Docker deployments, there are many variables, including the CPU and memory size of the Docker instance. A large Docker instance can support up to 200 concurrent peak users, but that does not take into consideration how many of the meetings are being recorded. Meeting recordings are CPU intensive. A Docker instance is better suited for a small department or focused team than an enterprise-size deployment.
"},{"location":"admin/plan_cluster_meetings.html#section_wxt_hqk_bvb","title":"Kubernetes","text":"If you are deploying Sametime to your entire organization, Kubernetes is a better choice than Docker. The Kubernetes autoscaling feature provides the flexibility needed in an enterprise deployment. Autoscaling is a feature in which a cluster adjusts the number of nodes based on current usage and monitoring.
In Kubernetes environments, a horizontal pod autoscaler is leveraged to automatically scale the environment upon demand. There are two configurations: one for video and one for recorders. When you create your node pools for video and recorder it is important to estimate how many nodes are needed.
You can either have a node dedicated to one recorder or you can size your recorder node pool instances to support more than one recorder per node.
Parent Topic: Clustering and high availability
"},{"location":"admin/plan_cluster_meetings_recorder.html","title":"Configuring autoscaling for recorder","text":"A recorder is used when a meeting is being recorded and when live streaming a video. The Kubernetes autoscaler adjusts the use of recorder pods based on settings in the recorder.yaml file.
To deploy the autoscaler, Prometheus must be installed. See Installing Prometheus for the details.
When a recorder is being used in a meeting, it is dedicated to that meeting until the user stops the recorder or the meeting is stopped. At that time, the recorder is available to be used again. For example, if two recorders are deployed, only two meetings can be recorded at the same time. A recorder is not available until one of the meetings ends. The live streaming feature is also handled by the recorder.
Estimate how many recorders you may need and define the minimum and maximum number of recorder pods that are used by the autoscaler.
Change directories to installation_directory/ /kubernetes/autoscaling directory. Where installation_directory is the directory the install package is located.
Open the recorder.yaml file for editing.
Configure the minimum number and maximum number of recorders by adjusting the following settings.
minReplicas: minimum\\_value\nmaxReplicas: maximum\\_value\nFor example:
minReplicas: 2 \nmaxReplicas: 10\nSave and close the file.
To deploy the recorder autoscaler, run the following command from the autoscaling directory.
kubectl apply -f recorder.yaml\nIf the autoscaler has already been deployed, you can adjust the number of recorder pods available. The following command can be used to adjust the number of recorders.
kubectl edit hpa recorder\nParent Topic: Configure high capacity for meetings
"},{"location":"admin/plan_cluster_meetings_video.html","title":"Configuring autoscaling for video","text":"The Kubernetes autoscaler adjusts the use of video pods based on the configured values in the video.yaml file.
To deploy the autoscaler, Prometheus must be installed. See Installing Prometheus for the details.
When Sametime is installed for the first time, you must deploy a HorizontalPodAutoscaler.
Change directories to installation_directory/ /kubernetes/autoscaling directory. Where installation_directory is the directory the install package is located.
Open the video.yaml file for editing.
Configure the minimum number and maximum number of video pods by adjusting the following settings.
minReplicas: minimum\\_value\nmaxReplicas: maximum\\_value\nFor example:
minReplicas: 1 \nmaxReplicas: 3 \nSave and close the video.yaml file.
To deploy the video autoscaler, run the following command from the autoscaling directory.
kubectl apply -f video.yaml \nIf the autoscaler has already been deployed, you can adjust the number of video nodes available. The following command can be used to adjust the number of video nodes.
kubectl edit hpa video\nParent Topic: Configure high capacity for meetings
"},{"location":"admin/plan_cluster_mongodb.html","title":"Configuring MongoDB for high availability","text":"This topic covers the steps on how to configure MongoDB for high availability.
MongoDB clustering is handled during the installation process for both Docker and Kubernetes.
Note: In the MongoDB URL, if the user name or password includes the following characters, they must be converted by using a percent sign: / ? # [ ] : @.
Parent Topic: Clustering and high availability
"},{"location":"admin/plan_cluster_mongodb.html#ncl_ddm_x5b","title":"Configuring MongoDB clustering on Docker","text":"In the custom.env configuration file on the Sametime server, update the MONGO_URL field. For information about how to create the MongoDB URL, see the Connection String URI Format topic in the MongoDB documentation.
"},{"location":"admin/plan_cluster_mongodb.html#nky_cdm_x5b","title":"Configuring MongoDB clustering on Kubernetes","text":"Provide a single node MongoDB information while running the prepareDeployment script.
When the prepareDeployment process is complete, prepare your MongoDB cluster URL. For more details, see Connection String URI Format.
Use Base64 encoding to encrypt your MongoDB URL.
You can review online websites that provide Base64 encoding or you can set up one on your own.
Use the kubectl command to update the sametime-meetings-global-secrets secret configuration file.
kubectl edit secret sametime-meetings-global-secrets\nInside the sametime-meetings-global-secrets, locate the MongoConnectionUrl section. Replace the value for it with the value from step 3.
Save your changes.
This section describes the system requirements and server configurations needed for HCL Sametime and HCL Sametime Premium.
Network planning for meetings
Clustering and high availability High availability and high capacity configuration for Sametime is achieved in different ways depending on which component is being configured for HA. See the topics below to learn more about chat, meetings, and MongoDB.
The Meeting server routes media traffic.
"},{"location":"admin/planning_meetingserver.html#section_gmc_qlc_w5b","title":"Media quality and network connectivity performance","text":"How are media streams transferred? Is there any instance where this would occur peer to peer? : All media traffic is routed through the Sametime server.
If I need external access to meetings, in which firewall zone do I place the Sametime Meeting server? : See Determining where to install Sametime.
Are there any considerations for the network if I have a firewall? : See Planning the network topology and connectivity.
What is the recommended bandwidth for comfortable usage? : Whether you are attending online meetings, video conferences, or virtual gatherings, ensuring a reliable and smooth connection is key. Calculation can be tricky and is dependent on the business scale. For small organizations, 1 Gbits/s is often enough. For larger organizations, 10 Gbits/s or more is recommended. For large organizations that use multiple bridges for multiple deployments, 10 Gbits/s link per bridge is recommended. For more information, see the Jitsi Meet Handbook.
"},{"location":"admin/planning_meetingserver.html#section_nmw_qmc_w5b","title":"Chats within a meeting","text":"How long do chats in the meeting remain? : There are two places that chats are displayed. For authenticated users who are logged into the server, they see the chats in the Sametime clients as a group chat that includes the meeting participants. The chat persists if the user does not close the chat.
: For meetings where users are guests, or authenticated users are not logged into a Sametime client, the meeting chat is only inside the meeting room. When the meeting concludes, the meeting room chats are deleted from the meeting room.
Can I make the chats persist from one meeting to the next? : When the meeting concludes, the meeting room chats are deleted from the meeting room. Meeting chats do not persist to the next time the same meeting URL is used.
Can I enable logging of the chats inside the meeting? : The user can log the chats only if they log into the server using a Sametime client. There are three ways the user can log these chats:
- The Sametime Connect client or embedded client have a client-side chat logging feature enabled to save a local transcript.\n- The user enables persistent chats on the server and clients supporting persistent chats are in use, these chats are stored on the server in MongoDB. They are subject to the persistent chat configuration.\n- The server-side chat logging is enabled and chats are stored in the configured method.\nWhich authentication methods are supported? : The Sametime server handles all authentication requests. Any supported authentication model you configure on the Sametime server is supported for Meetings.
How can I disable guest (anonymous) access to meetings? : See Disabling guest access.
Which types of SSO are supported with meetings? : LTPA and SAML with LTPA are supported. See Enabling Single Sign-on.
"},{"location":"admin/planning_meetingserver.html#section_jxc_d4c_w5b","title":"Recordings","text":"Where are recordings stored? : Recordings are stored in a persistent volume which is configured when Sametime is installed. For more information, refer to Creating the persistent volume.
How can you disable meeting recordings? : See Managing recording options.
What type of recorded media is available for meetings? Is this configurable? : The user can save all recordings as MP4 files. It is not configurable.
Which part of a meeting is recorded? : Everything that displays on the screen share and all audio and video from cameras that were seen by users in the meeting are captured as part of the recording. Shared YouTube videos are captured as well.
Authenticated meeting attendees who log in with a Sametime client have a group chat for the meeting. The link for the recording is contained in the chat, and the chat persists if the clients keep the chat open. Persistent chats expire after a number of days. For more information, refer to [Updating the time-to-live index for persistent chat](update_ttl_index.md).\n\nThe meeting moderator has access to the meeting report which contains a full chat transcript, links to files that were shared, as well as a link to the recording if the recorder was started.\nHow long does recorded media remain on servers? Is this configurable? : The default is three days, which is configurable. See Managing recording options for the details.
"},{"location":"admin/planning_meetingserver.html#section_nsz_npc_w5b","title":"Configuration settings","text":"Which settings are configurable server-wide? : Meeting server configuration is all handled on the meeting server; each change is global.
Can the administrator restrict a number of participants in a meeting? : Yes, and the default number of participants in a meeting is 100. See Configuring the maximum number of meeting participants for the details.
Which settings are configurable though a policy? : The community policy only allows or disallows meetings. There are no other policy-based settings.
Can I disable the audio and video options? : No.
Can I integrate my telephony system with the Sametime meeting server? : Yes, see Enabling meeting dial-out.
"},{"location":"admin/planning_meetingserver.html#section_zpg_dqc_w5b","title":"Personal or reserved meetings","text":"Can a user own or reserve the name of a meeting, that is the meeting URL so that no one can use it? : Yes, the first user who requests the meeting name owns the reserved name.
Can I have a persistent meeting? : You can have a reserved meeting name. There is no data preserved or persisting between members entering or leaving.
Is a moderated meeting room not available until its owner enters the room? : Yes, the moderated meeting room is not available until the owner enters the room.
"},{"location":"admin/planning_meetingserver.html#section_ttf_lqc_w5b","title":"Migration and existing Sametime environments","text":"Can I migrate my Sametime 9.0.1 meeting data to the Sametime meeting server? : No. There is no slide share or file share tool in the new meeting server. There is no data that needs to be migrated.
Will my old Sametime meeting URLs work on the new server? : Users can expect the legacy meeting URLs to work. The DNS change from the old host name to the new host name handles the migration to the new server. After the DNS change, users can continue to use the original meeting URLs in calendar entries to join meetings. The new server does not support the legacy meeting client plug-in in the Sametime client, so users must join by URL.
Can I use the Sametime 9 meeting plug-in embedded in HCL Notes to connect to a Sametime Meetings server? : The introduction of the External Meeting Provider feature in the Sametime embedded and stand-alone clients deprecate the meeting plug-in in the Notes version 11.
"},{"location":"admin/planning_meetingserver.html#section_xv4_2rc_w5b","title":"Statics, reporting and auditing","text":"Are there meeting statistics or reports for Sametime? : Meeting reports can be downloaded. The reports provide information such as: a list of attendees, meeting start and end times, duration, meeting types such as moderated, guests allowed, the time participants were joined and left the meeting, a list of presenters, a link to meeting recording, and the chat transcript.
: A Grafana\u00ae dashboard is available with the Sametime install package. See Monitoring your meeting and chat metrics with Grafana.
Parent Topic: Planning
"},{"location":"admin/pod_apply_changes.html","title":"Applying changes","text":"After you have modified a secret, scale the pods for which changes were made. Scaling the pod is similar to a reboot, first the pod is scaled to zero and then scaled to one. For Sametime pods details, see Pods in Sametime. Scaling to zero removes all containers for the specified pods and scaling to one restarts their use. When scaled back up from zero, changes made are used by the pod.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/pods_descriptions.html","title":"Pods in Sametime","text":"A pod is a group of one or more containers that share storage and network resources.
The following table describes the Sametime pods and the containers in which the pod runs.
Pod Name Container Description Activity App-registry Auth NA Interacts with the Sametime server for SSO. backgrounds NA Provides the backgrounds in meetings. Catalog NA Maintains the list of meetings that belongs to a user and the the recent meetings list. Interacts with the MongoDB. Click2call NA Provides the click to call interface in web chat. Community community, pushgateway Performs all authentication, interacts directly with the LDAP service. Enforces policies. Interacts with MongoDB for persistent chat. Retrieves and serves business cards data. files files, scanner Provides file transfer service in meetings and web chat Jibri-web NA Provides a web interface to the recordings Jitsi prosody, jigasi, jicofo The video bridge that streams the media to users.Jigasi container for SIP messages(integration with telephony).Jicofo conference focus) \u2013 messages about features used in meetings, participants joining and dropping. Lobby NA Runs the lobby service for meetings. Location NA Used when telephony is integrated to assist users with the telephone numbers. Mux NA Allows the Connect and Embedded clients in Notes to connect over port 1533. Has a svc with an IP address for users to connect. Proxy NA Runs the web chat service allowing users to connect with mobile clients or web clients for chat. Recorder jibri, pushgateway, await-prosody Save meeting recordings when a user records a meeting. It is also used for live streaming. Recordings NA Interacts with the persistent volume to store recordings. Video jvb, prometheus-exporter Interacts with STUN server. Web NA Serves the web interface to the users Webhook NA Interacts with telephony and click to call feature Outlook NA When the Outlook add-in feature is enabled, this process interacts with the Outlook add-in.Parent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/ports_sametime.html","title":"Ports used by Sametime services","text":"Sametime services use several ports for communication. If firewalls are in use in your environment, all traffic on these ports should be permitted bidirectionally.
Port Number Description 389 Used for non-secure communications from the Sametime server to the LDAP server. 443 Used for HTTP communications over a secure connection. 636 Used for secure communications with LDAP for directory services. 1516 Used as an internal port between the community and proxy pods. 1533 Used to listen for direct TCP/IP connections from Sametime Connect clients.A direct TCP/IP connection is when a Sametime client uses a unique Sametime protocol over TCP/IP to establish a connection with community services. 1935 Used when streaming YouTube videos. 5280, 5222 Used to reach the service cluster IP for Jitsi. In Kubernetes environments, for websockets to function properly, the video pods using the node port must be able to reach the service Cluster IP for Jitsi on ports 5280 and 5222. See the Websockets fail to load after installing Sametime 11.6 or 12.0.x on Kubernetes article for more information. 8000 Used to listen for HTTP communications. All communication over this port is redirected to HTTPS port 443. Port 8000 is the default port assigned during the product installation process. 10000 Used by audio and video clients to stream media data when deploying Sametime on Docker. 19302 This UDP port is the default STUN port used by both the client and meeting server for NAT traversal. 27017 Used for communication with MongoDB. 30000 Used by audio and video clients to stream media data when deploying Sametime on Kubernetes.Parent Topic: Planning the network topology and connectivity
"},{"location":"admin/recording.html","title":"Managing recording options","text":"As the administrator, you have control over your recording settings. This section describes the features available to help you manage meeting recordings and where they are configured.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/sametime_client_configuration.html","title":"Sametime client configuration options","text":"There are several methods to customize the user experience for Sametime clients. This section covers Expeditor based clients that are capable of leveraging the Expeditor Managed Settings framework. These clients include the Sametime client for Windows or Mac, and the HCL Notes embedded Sametime client for Windows or Mac. This does not apply to the PWA, web or mobile clients.
Use managed-settings.xml and managed-community-configs.xml for clients which are already installed.
If your clients not not yet installed, the the plugin_customization.ini file can be configured and included with the client installation package.
File Location Purpose managed-community-configs.xml Web server This file is used to update connectivity preferences in the client. Update, add and delete servers, and manage connection settings (such as host name, port, connection method, authentication method, etc). The file is pushed using a policy, so you can define different settings for different users. This method applies to both the Sametime\u00ae rich client and to the Sametime client embedded in Notes\u00ae. This file is retrieved upon login and will take effect the next time the user restarts the client. managed-settings.xml Web server This file can be used to push client preferences to the users. The file is hosted on a web server and retrieved upon login from the Sametime policy. This method applies to the Sametime rich client and Sametime embedded client in Notes. Note: Do not add community config settings (connectivity settings) to this file. Community config settings must be added to the managed-community-configs.xml file. See the topic Updating Communities with the Managed-community-configs xml. plugin_customization.ini Client computer Set initial eclipse preferences when client install kits are deployed to desktops or when a new user launches the product for the first time. These preferences can be overridden at runtime for the logged in user base using the managed-settings.xml file. This method only applies to installed Sametime Connect clients. Community settings (such as loginAtStartup and host) can be entered here to prepopulate community settings for a first time user. After the user logs in, only the managed-community-configs.xml file can be used to change community settings.Parent Topic: Managing Sametime clients
"},{"location":"admin/sametime_meeting_administering.html","title":"Managing Sametime Meetings","text":"You can enable or disable meeting features. Note that these settings apply to the server and are not controlled by user policies.
The following table lists meeting features and whether they can be turn on or off by the administrator or meeting owner.
Table 1. Meeting Features
Feature Settings Audio and video Enabled by default, cannot disable. Sharing a video Enabled by default, cannot disable. Start live stream Live streaming is disabled if recordings are disabled. To allow recordings and disable live streaming, see Configuring Live Streaming. Disable recordings Recordings are enabled by default. To disable recordings, see Managing recording options. Change recording availability Recordings are available for 3 days by default, to change the setting, see Managing recording options. Secure the meeting with password The option to secure meetings with a password is by default enabled, cannot disable. A user can choose for any meeting owned whether or not to configure a password on that meeting. See [Defining Meetings password requirements] (meetings_passwords.md) for additional information. Guest users Guest access is enabled by default. To disable, see Preventing guest access Unmoderated meetings Enabled by default, cannot disable. Moderated meeting: invite others Enabling meeting dial-out. Raise hand Enabled by default, cannot disable. User Photos (authenticated users only) You can retrieve photos from the Sametime Proxy server. They will display if they are available to the meeting server. You can use Gravatar to configure an avatar based on your Sametime email ID. Use it if your photo is not available via the Sametime Proxy. Group Chat Enabled by default, cannot disable. Group Chat also in the rich client Enabled by default, cannot disable. Screenshare (Start Presenting) Screenshare is enabled by default on all meetings. In a moderated meeting, the moderator must grant access to screenshare. Multi-user screenshare By default, any user in an unmoderated meeting can share their screen, even if another user is already sharing. It is not possible to disable this feature. In a moderated meeting, you can share only a single screen at a time. Lock meeting Enabled by default, cannot disable. Moderated Meeting: Mute everyone else Enabled by default, cannot disable. Moderated Meeting: All cameras off Enabled by default, cannot disable. Moderated Meeting: Invite others See: Enabling a SIP Trunk for Meeting Dial OutThe following table displays settings that affect the functionality of the server.
Table 2. Server-side configuration settings
Description Setting Maximum number of attendees per meeting. Currently, the maximum supported number of users per meeting is 50. The default setting is 25 users. To change the setting, see: Configuring the maximum number of meeting participanats.Parent topic: Administering
"},{"location":"admin/sametime_premium.html","title":"Sametime versus Sametime Premium","text":"Depending on the Sametime product that is installed, certain Sametime features might be available. HCL Sametime provides secure real-time communication across devices, and HCL Sametime Premium expands those features to include video and file sharing.
The following tables show the features included in Sametime and Sametime Premium.
Feature HCL Sametime HCL Sametime Premium Sametime Embedded client in HCL Notes X X Sametime Connect client X X Presence awareness in HCL Notes X X Instant chat X X Persistent chat X X Local client chat history X X Screen capture and image transfer in chat X Support for multiple Sametime communities X External conferencing integration X File transfer X Feature HCL Sametime HCL Sametime Premium Sametime mobile chat X X Sametime web client chat X X Sametime presence and chat API for HCL Connections and HCL Digital Experience X X Sametime presence and chat in HCL Verse and iNotes X X Feature HCL Sametime HCL Sametime Premium Screen sharing X Multiple users screen sharing X Audio and video X Meeting group chat X Meeting group chat integration with desktop clients X Moderated meetings X Password protection X Reserved meeting names and URLs X Meeting recordings X Live streaming to YouTube XNote: For HCL Domino users with limited Sametime capabilities, see Managing Sametime features for the list of features that are not available.
Parent Topic: Planning
"},{"location":"admin/secrets_delete.html","title":"Deleting a secret","text":"The kubectl delete command can be used to delete a secret.
To delete a secret, issue the command specifying the secret.
kubectl delete secret secretname\nThe following example shows the command to delete extra-community-configs secret.
kubectl delete secret extra-community-configs\nParent Topic: Managing secrets in Kubernetes
"},{"location":"admin/secrets_modify.html","title":"Modifying secrets","text":"Some of the content within a secret can be changed using the edit secret command.
When the secret is in edit mode, you can modify the content by placing data in secrets. Most of the secret fields, such as user names, passwords, and URLs, are base64 encoded. To view a base64 encoded value, you can copy the value and decode using the following command:
echo -n secret\\_value | base64 -d\nTo change the value to a new encoded value, you can base64 encode the new value using the following command:
echo -n \"new\\_secret\\_value\" | base64\nFor example to set a new LdapBindEntryDn in the sametime-global-secrets, enter the command:
echo -n \u201cCN=LDAPBind,O=Example\u201d | base64\nThe resulting value should be used in the configuration.
The following are considerations when making configuration modifications:
If changes to the configuration helm charts are not committed, the next time you run a helm upgrade, the secret is overwritten with the values that are defined in the templates.
Issue the following command specifying the name of the secret.
kubectl edit secret secret\\_name\nType the letter i to get into insert mode and make modifications.
To save the changes, type the characters: Esc+ :wq!.
To close the file without saving changes, type in the characters Esc+ :q!.
Parent Topic: Managing secrets in Kubernetes
"},{"location":"admin/secrets_view.html","title":"Viewing secrets","text":"The get command can be used to list secrets and view their contents.
To view a list of all secrets, run the following command.
kubectl get secrets\nIf a namepace is beign used, the -n argument must be inclued.
kubectl get secrets -n namespace\\_name\nwhere namespace_name is the name of the namespace.
To view the content of a secret, run the following command.
kubectl describe secret secret\\_name\nwhere secret_name is the name of the secret.
Parent Topic: Managing secrets in Kubernetes
"},{"location":"admin/secure_rooms.html","title":"Disabling secure meeting room names","text":"Users are provisioned with a personal meeting room the first time that they log into their meeting. Their personal meeting room is created with a secure name that cannot be easily guessed by other users. For example: be:MeetMe.CWGRAff90q9HETLne4mhzA.
Meeting rooms with a user-friendly name or naming conventions might be preferred, for example: MeetMe.username~40company.com. If this is the case, the secure naming feature can be disabled.
Disabling secure meeting room name feature does not affect existing meeting rooms. Changing the setting affects only the meeting rooms provisioned after changing the setting.
Disabling secure rooms on Docker and Podman
Disabling secure rooms on Kubernetes
Parent Topic: Meetings
"},{"location":"admin/secure_rooms_docker.html","title":"Disabling secure rooms on Docker and Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Edit the docker-compose.yml file.
Locate the STCONF_MEETING_SECUREUSERROOMNAME variable in the Proxy section and set the value to false.
Save the changes.
To apply the changes, stop Sametime server and then start it again.
Run the following command to stop the server.
docker-compose down\nRun the following command to start the server.
docker-compose up -d\nParent Topic: Disabling secure meeting room names
"},{"location":"admin/secure_rooms_kubernetes.html","title":"Disabling secure rooms on Kubernetes","text":"Chang to the helm directory where the Sametime installation package was decompressed.
cd helm\nOpen the values.yaml file and put in edit mode.
Locate the useSecurePersonalRoomName value and change the value to false.
useSecurePersonalRoomName: false\nSave and close the values.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Disabling secure meeting room names
"},{"location":"admin/securing.html","title":"Securing","text":"This section provides information on securing your HCL Sametime environments.
The various connections to Sametime can be secured using TLS.
Desktop client to Sametime server : These are connections from the Sametime Connect client or Sametime embedded client inside HCL Notes that connect on port 1533 to the Sametime Multiplexer (Mux) by default. Sametime has legacy encryption enabled by default. These connections can be secured over TLS 1.2. For additional information, see Securing connections between the Sametime mux and the Connect and Embedded clients.
Sametime web and mobile clients : Sametime meetings and web chat come with a self-signed certificate. You can replace the self-signed certificate with a third party certificate. For more details on this configuration, see Replacing the TLS certificates for Web Chat and Meetings.
Sametime server to LDAP server : By default the LDAP operations are not encrypted. It is recommended to enable encryption using TLS to encrypt sensitive user data, such as names and passwords. The secure port for LDAPS is typically 636 but may be different in your environment. For more details on this configuration, see Securing connections between Sametime servers and LDAP.
Decrypting SAML assertions : When Sametime server is configured for SAML, the Sametime server can validate the encrypted assertions are from the Identity Provider (IdP). These settings is used for the decryption. For more information, see Setting up SSO using SAML.
MongoDB : The connection Sametime uses to access MongoDB can be secured with TLS. For more details, see Setting up TLS for the Mongo database.
Configuration scope : Beginning with Sametime 12, Kubernetes environments have a separate TLS scope for each type of connection as described above. Docker environments can be configured to use key and trust stores at the global level, where all certificates are shared among the different community services. For more details on this configuration, see Implementing the Global TLS Scope for Docker.
Obtaining the cert.key and cert.crt files for Sametime
Creating a truststore with a third-party certificate When creating a connection between the Sametime server and a service using TLS, a truststore is needed. The truststore is used to store certificates for Sametime.
Implementing the Global TLS Scope for Docker
Securing connections between the Sametime mux and the Connect and Embedded clients There are several connection methods to connect to the Sametime server. This topic includes the steps to encrypt connections between the clients and the Sametime mux using TLS.
Parent Topic: Securing
"},{"location":"admin/securing_connections_between_community_clients.html","title":"Securing connections between the Sametime mux and the Connect and Embedded clients","text":"There are several connection methods to connect to the Sametime server. This topic includes the steps to encrypt connections between the clients and the Sametime mux using TLS.
To implement the use of TLS, the clients must have the Direct connection using TLS connection option enabled. This setting is under Preferences > Server Communities > Global Connection Settings.
There are three methods to set the client connection preferences.
For additional information, see Updating connectivity settings with the managed-community-configs.xml file.
When you enable TLS for the Sametime server connections, TLS version 1.2 is used by default. SSLv3 and TLSv1 have security vulnerabilities and should not be used.
To configure the connection between the Sametime server and clients, there are two tasks that must be completed:
Sametime can be configured to allow legacy encryption along with TLS encryption (both enabled), or strict TLS where only TLS encrypted connections are allowed. The Sametime Mux can listen for both TLS and legacy encrypted connections on the same port number, so there is no need to have a unique port for the TLS encrypted connections, they can also use port 1533. The port number can be changed if desired.
For details on configuring the encryption settings, refer to the following topics.
Configuring TLS for Sametime mux on Kubernetes
In the HCL Notes client, select File > Preferences > Sametime > Server Communities. The Server Communities window defines the server communities defined for the client.
To select this connection method for only one server community, click Server Communities, select the server community name, and open the Connection tab. Disable the Use global connection setting, then click Direct connection using TLS. Click OK to close the Preferences window.
Creating a keystore for Sametime mux A keystore consists of a private key and a certificate. Sametime supports both a third-party certificate, signed by a Certification Authority (CA), or a self-signed certificate. Request a certificate and private key from your CA for the hostname used by the Sametime mux. This is the microservice that listens on port 1533 for requests from the Sametime Connect clients (installed clients on desktop). In Kubernetes, the mux is either a Kubernetes service (for example, a load balancer type service) or a Kubernetes ingress service for on-premise Kubernetes. For Docker deployments, the mux listens on port 1533 and does not require any additional service.
Configuring TLS for Sametime mux on Kubernetes
Configuring TLS for Sametime mux on Docker and Podman
Parent Topic: Securing connections
"},{"location":"admin/securing_connections_between_community_clients_docker.html","title":"Configuring TLS for Sametime mux on Docker and Podman","text":"The following steps enable TLS for the Sametime mux, which overrides the default security with TLS 1.2 between Sametime Connect clients and the Sametime mux. For more details, see Securing connections between the Sametime mux and the Connect and Embedded clients.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Create a mux.env with the following setting and values appropriate for your configuration.
STI__Debug__VPMX_DISABLE_CONFIGURATION_UPDATE=1\nSTI__Debug__VPMX_PORT=1533\nSTI__Debug__VPMX_TLS_PORT=1533\nSTI__Config__VPMX_CAPACITY=20000\nSTI__Config__ST_TLS_KEY_STORE_TYPE=p12\nSTI__Config__ST_TLS_KEY_STORE_FILE=/local/sametimemuxdata/keystore.p12\nSTI__Config__ST_TLS_KEY_STORE_PASSWORD=keystore\\_password\nSTI__Config__ST_TLS_SECURITY_LEVEL=2\nAdd mux.env to the environment file variable in to the mux section of docker-compose.yml file.
env file:\n -mux.env\nMap the keyfile into the container
volumes:\n - ./keystore.p12:/local/sametimemuxdata/keystore.p12 \nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Securing connections between the Sametime mux and the Connect and Embedded clients
"},{"location":"admin/securing_connections_between_community_clients_kubernetes.html","title":"Configuring TLS for Sametime mux on Kubernetes","text":"Ensure that the following conditions are satisfied.
These are the steps to secure the connection between the Sametime Connect client and Sametime embedded client inside of HCL Notes to the Sametime mux using TLS.
The changes in this task apply to the following pods:
mux
Create a secret that contains your trust store.
kubectl create secret generic mux-secret --from-literal=KeyStorePassword=samet1me --from-file=./keystore.p12\nIn the values.yaml file remove the comment tag (#) surrounding the muxTlsConfigSecret: mux-secret parameter.
Save and close the values.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Securing connections between the Sametime mux and the Connect and Embedded clients
"},{"location":"admin/securing_connections_sametime_community_and_ldap.html","title":"Securing connections between Sametime servers and LDAP","text":"When Sametime is configured to connect to an LDAP server, the Sametime servers makes five separate connections to the LDAP server.
The Sametime Community Server makes a separate connection to the LDAP server to perform each of these five tasks:
The Sametime Community Server and LDAP servers exchange directory information, including user names and passwords, over these connections. To ensure this information is secure, the administrator can use SSL to encrypt the data that passes over these connections. The administrator should consider the level of protection required before enabling SSL. Using SSL to encrypt these connections can slow the server performance.\u202f
The administrator has the following options when using SSL to encrypt the data transmitted between the Sametime and LDAP servers:
Prerequisites
You must already have created the TLS Trust Store in .p12 or .jks format.\u202f
You can configure Sametime LDAP to use the same TLS settings as the rest of the server by setting the configuration at the global scope, or the LDAP settings can be secured using its own key store and settings by following the instructions in the Individual TLS scope and using the pre-fix STLDAP_.\u202f\u202f You must configure the sametime.ini settings by completing one of these topics:\u202f
Follow these steps to encrypt all data as explained above.
Import the LDAP server\u2019s certificate into the trust store
If the LDAP server is using a public certificate, then you need to obtain the public root CA and import it into the trust store on the Sametime server. If your LDAP server is using a self-signed certificate, then you simply import the self-signed certificate. In the prerequisite topics, your trust store filename is defined in sametime.ini setting ST_TLS_TRUST_STORE_FILE or if using the individual scope in STLDAP_TLS_TRUST_STORE_FILE.\u202f If you are securing Sametime using the global scope, the LDAP connections can use the same key and trust stores and these sametime.ini parameters are not needed.
Update the stconfig.nsf to use the secure LDAP settings
See the configuring_ldap.md topic and
Update the userinfoconfig.xml to use the secure LDAP settings
By default, the business cards LDAP connection is unsecure. To secure these settings, see the topic Configuring Business cards using an LDAP Directory and complete the optional step \u201cEnabling Encryption\u201d.
Encrypt only password related operations
If you wish to only encrypt operations that involve passwords, the rest of the traffic can remain unencrypted (sent in the clear), follow these steps:
In the [Directory] section add the following line:
ST_DB_LDAP_SSL_ONLY_FOR_PASSWORDS=1
Save and close the sametime.ini file.
This topic covers the steps to import your LDAP trust store and password into Docker as a secret, then define the secret in the Sametime configuration.
Before getting started, create a trust store with the LDAP certificate from the LDAP server. Name the file ldaptruststore.p12 and place it into the directory where the docker-compose.yml file is located.
The steps in the following procedure must be completed with root access or you can use sudo which allows you to run commands as root.
Change directories to the root directory where Sametime installation package was decompressed.
Create a new file called tlsldap.env.
vi tlsldap.env\nAdd the following lines into the tlsldap.env file.
STI__Config__STLDAP_TLS_TRUST_STORE_TYPE=p12 \nSTI__Config__STLDAP_TLS_TRUST_STORE_FILE=/local/notesdata/ldaptruststore.p12 \nSTI__Config__STLDAP_TLS_TRUST_STORE_PASSWORD=ldaptruststorepass\nOpen the docker-compose.yml for editing.
Locate the env_file: section under the community: subsection within the services: section.
Move custom.env to a new line.
Add the following line below custom.env.
tlsldap.env\nThe results should look like the following:
services:\n community:\n env_file: \n - custom.env\n - tlsldap.env\n environment:\nAdd a path to the LDAP trust store under the community: section in the docker-compose.yml file.
networks section and add the following line.volumes section, add the following line to the section. - ./ldaptruststore.p12:/local/notesdata/ldaptruststore.p12 \nThe section should look like the following example. Ensure that the indentations look like the example.
networks:\n - sametime.test\nvolumes:\n - ./ldaptruststore.p12:/local/notesdata/ldaptruststore.p12\nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Securing connections between Sametime servers and LDAP
"},{"location":"admin/securing_ldap_kubernetes.html","title":"Securing LDAP on Kubernetes","text":"This section covers the steps to import your LDAP trust store and password into Kubernetes as a secret, then define the secret in the Sametime configuration.
Create a trust store in p12 format that contains a copy of the LDAP server\u2019s certificate. To perform this step you will need to know the password of your trust store.
The changes in this task affect the following pods:
community
Create a secret a secret that contains your certificate.
Rename your trust store file name to ldaptruststore.p12.ls.
Copy the ldaptruststore.p12 file to the machine where you are running kubectl.
Run the following command to create the Kubernetes secret.
kubectl create secret generic ldap-config-secret --from-literal=KeyStorePassword=password --from-file=./ldaptruststore.p12\nSubstitute your password for password. If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure the secret is created in the correct namespace.
Change to the helm directory where the Sametime installation package was decompressed. Open the values.yaml file to update the secret parameter.
Set the value of the ldapConfigSecret parameter to ldap-config-secret.
ldapConfigSecret: ldap-config-secret \nIf the parameter is commented out, remove the comment tag.
Save and close the file.
Ensure you are in the helm directory. To apply your changes to the environment run the following command, specifying the deployment name in your environment. The default for Sametime version 12 is sametime.
helm upgrade deployment\\_name.\nIf you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Note: Be sure to include the dot, it is part of the command.
Scale the Community pods to zero and then to one.
Run the following command to scale the pod to zero.
kubectl scale deploy community --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy community --replicas=1\nApply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Securing connections between Sametime servers and LDAP
"},{"location":"admin/security_mongodb_tls.html","title":"Setting up TLS for the Mongo database","text":"You can update the MongoDB connection with the Sametime server to encrypt data flowing between the Sametime server and a TLS-enabled MongoDB. This step is optional but is recommended for multi-Kubernetes-cluster deployments.
Ensure that the following conditions are met.
You can enable TLS on a connection to your MongoDB instance in two ways:
This topic covers the first method. During Sametime Meeting installation, the chatlogging.ini file is created to contain MongoDB server connection information. The connection configuration information within the chatlogging.ini file must be modified to include parameters necessary to establish a secure connection.
The Sametime administrator can specify a custom connection URL to the MongoDB server. The CL_MONGO_URL configuration parameter can be set with a MongoDB server URL which includes the required settings for the Sametime server to establish a secure connection to the MongoDB server. After adding the CL_MONGO_URL configuration parameter to the chatlogging.ini file, the default setting is overridden by the settings contained within the URL string.
If a self-signed certificate is being used, the certificate must be added to the Sametime certificate store.
Open the chatlogging.ini file which is in the HCL Notes data directory.
Update or add the CL_MONGO_URL configuration parameter.
This parameter is used to override existing configuration settings specified during installation. If changes were made post installation, this parameter exists in the file. If no changes have been made, add the parameter.
CL_MONGO_URL=mongodb://user:password@hostname\\_tcpip:port/tls\\_information\nwhere:
hostname_tcpip : The hostname or TCPIP address of the MongoDB server.
port : The port to be used for communication.
tls_information : The attributes that identify use of a TLS MongoDB. Copy and past the following into the CL_MONGO_URL parameter.
```\n /admin?retryWrites=true&w=majority&ssl=true&tlsCAFile=/local/notesdata/cacert.pem\n```\nFor example:
CL_MONGO_URL=mongodb://user:password@192.168.150.1:27017/admin?retryWrites=true&w=majority&ssl=true&tlsCAFile=/local/notesdata/cacert.pem\nSave the file and restart the Sametime server to apply the changes.
Enable TLS for the Mongo database on Kubernetes or Enable TLS for the Mongo database on Docker or Podman.
Verifying if TLS connection can be established
Enabling TLS for the Mongo database on Kubernetes
Enabling TLS for the Mongo database on Docker or Podman
Parent Topic: Securing
"},{"location":"admin/session_traversal_utilities.html","title":"Session Traversal Utilities for NAT (STUN)","text":"Session Traversal Utilities for NAT (STUN) is a standardized set of methods, including a network protocol, for NAT traversal of Network address translation (NAT) gateways in applications of real-time voice, video, messaging, and other interactive communications.
STUN is a tool used by other protocols, such as Interactive Connectivity Establishment (ICE), the Session Initiation Protocol (SIP), and WebRTC. It provides a tool for hosts to discover the presence of a network address translator and to discover the mapped, usually public, Internet Protocol (IP) address and port number that the NAT has allocated for the application's User Datagram Protocol (UDP) flows to remote hosts. The protocol requires assistance from a third-party network server STUN server located on the opposing public side of the NAT, usually the public Internet.
For more information, see Session Traversal Utilities for NAT (STUN).
"},{"location":"admin/session_traversal_utilities.html#section_p4l_jrw_v5b","title":"Why is STUN needed?","text":"Simply put, we use STUN as a tool to help clients determine their public IP address so that they can connect to each other and the Sametime server to send and receive audio and video data.
If your deployment of Sametime is all internal and there are no NAT or firewalls between the users and the server, then you might not need to use STUN.
If your deployment includes users external to your network, like people working from home, then you likely need a STUN server to help negotiate the audio and video sessions.
"},{"location":"admin/session_traversal_utilities.html#section_a5x_drw_v5b","title":"Default configuration","text":"By default, the Sametime server is configured to use the Google Public STUN servers.
For Docker, this information is configured in the .env file like this:
# STUN servers used to discover the server's public IP.\nJVB_STUN_SERVERS=stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302\nFor Kubernetes, this information is configured in the helm/values.yaml file:
jvbStunServers: stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302\nIn both cases, this configuration is telling the server to use these STUN servers:
stun.l.google.com\nstun1.l.google.com\nstun2.l.google.com\n\nUsing UDP port 19302.\nIt is important to note that if the server or clients is unable to reach the configured STUN servers, n-way meetings does not work properly. When planning your deployment, make sure that the STUN servers are available over the network.
"},{"location":"admin/session_traversal_utilities.html#section_ydm_drw_v5b","title":"Optional configurations","text":"If you already have a STUN server in your environment or wish to use an alternative public STUN server, simply update the appropriate settings above before you deploy the server. It can be modified post-deployment as well. For more information on this, see Configuring alternate STUN servers.
If your deployment does not require the use of STUN, then you can disable this by simply commenting out the appropriate line in either the .env or values.yaml file and installing the server.
Parent Topic: Network planning for meetings
"},{"location":"admin/starting_and_stopping_mongodb.html","title":"Starting and stopping MongoDB","text":"Configuring MongoDB for Sametime
When you complete the prerequisite task, a service is created. Use the service to start and stop the MongoDB server.
Windows:
Linux:
To start the server, enter the command:
service mongod start
To stop the server, enter the command:
service mongod stop
Parent Topic: Administering
"},{"location":"admin/starting_and_stopping_servers.html","title":"Starting and stopping the Sametime server","text":"Starting and stopping the Sametime server involves starting and stopping the Sametime services running in the container management system.
To manage the Sametime server on Docker, you use the docker-compose command.
To start the Sametime server on Docker, run the following command.
docker compose up -d\nTo stop the Sametime server, run the following command.
docker compose down\nOn Kubernetes, scaling the pods can be used to start and stop the Sametime service. The kubectl scale command is use.
Scale the pod to one, starts the service.
kubectl scale deploy deployment_name --replicas=1\nScale the pod to zero, where deployment_name is the pod name.
kubectl scale deploy deployment_name --replicas=0\nParent topic: Administering
"},{"location":"admin/storing_photos.html","title":"Storing photos in the Domino directory","text":"If the Sametime server is connected to a Domino LDAP server, you can store business cards photos in the Domino Directory.
The file name of the photo attached to the person document must be named ContactPhoto.jpg. Domino serves this photo as an attribute called Photo. It is possible to use a custom field with the attachment or thumbnail field type, photo types used by Domino are JPEG and GIF file types. Photo size should be smaller than 45 KB, for best results use a 10 KB sized photo. This option requires the Domino Designer Client and modifying the design, which is outside the scope of this document.
This configuration only applies to the rich clients. In order to display photos in Meetings or Web Chat, you must use the PhotoURL attribute.
The Domino directory has a field in the person document that allows the user to upload their contact. It is saved as a thumbnail which automatically reduces the size of the file.
Important considerations:
The Sametime server does not support this method of photo retrieval. If you have users with the mobile or web clients, consider using a PhotoURL instead of storing photos as attachments in the Domino directory.
Open the Notes contact file using a Notes client. The default file is names.nsf.
Locate and open the person document where the photos is to be attached.
Click Edit Person.
To the left of the First name and Last name fields, click the photo icon.
Locate the .jpeg photo file on your hard drive and rename the file to ContactPhoto.jpg.
Click the icon to upload the photo and browse to the location of the renamed photo file.
Confirm that the photo is correct and click Save and Close.
Parent Topic: Setting up business cards
"},{"location":"admin/system_requirements.html","title":"System requirements","text":"System requirements include the minimum HCL Sametime and HCL Sametime Premium requirements, such as operating systems, hardware, software, and more.
The minimum requirements must be available to install the product successfully. For details on system requirements, see the System requirements article.
The graphic below shows a simple topology with the required components: MongoDB and LDAP. The system requirements article, along with the installation and configuration topics, provides details for including them in your environment.
Parent Topic: Prerequistes
"},{"location":"admin/t_adding_signer_certs_k8s.html","title":"Retrieving photos from HTTPS hosts in Kubernetes","text":"Signer certificates establish the relationship in SSL communication. This step is needed by the Sametime server, specifically for cases where the PhotoURL is using SSL (HTTPS) to access business card photos.
After obtaining the certificate file for the host, follow these steps.
Create a generic secret containing the CA certificate.
kubectl create secret generic ca_certificates --from-file=ca-certificates.crt=ca_certificates\nPlace the values.yaml file in edit mode.
Add the following line to the values.yaml file.
caCertificateSecret: ca_certificates\nWhen done, save and close the file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up business cards
"},{"location":"admin/t_choose_connect_method.html","title":"Choosing a method for connecting to the Sametime server","text":"The Sametime Connect Client uses the connection method specified in Server Communities preferences. The global connection settings apply to all connections unless a specific server community uses an alternate connection method as defined on its Connection tab in the Preferences window.
This section explains how to configure the different types of connections.
Parent Topic: Connecting the Sametime Connect client to the Sametime server
"},{"location":"admin/t_client_connect_direct.html","title":"Connecting the client through a direct connection over TCP/IP","text":"When a user starts the Sametime Connect client with a Direct connection preference, the client connects to the Sametime server using a unique Sametime protocol over TCP/IP. By default, the server listens for this connection on port 1533. Use this preference when the connection does not need to occur through a proxy server, and the network does not block TCP/IP connections on the port used by the client.
A successful connection depends on these prerequisites.
The connection can fail if it passes through a proxy server or network that prevents direct TCP/IP Connections on the specified port.
Follow these steps to select the Direct connection method for the client.
From the Sametime Connect client, select File > Preferences.
Do one of the following:
Parent Topic: Choosing a method for connecting to the Sametime server
"},{"location":"admin/t_client_connect_proxy.html","title":"Connecting the client through a proxy connection","text":"When a user starts the Sametime Connect client with a Use proxy preference, the client connects to the Sametime server through a SOCKS, HTTP, or HTTPS proxy server.
Contact your Sametime administrator for the hostname, port, and type of proxy server in use.
The connection methods for the Use proxy option differ in the types of proxy servers they use for connecting.
SOCKS4 or SOCKS5 proxy
The client uses the Standard Sametime protocol over TCP/IP for this connection. The connection from the SOCKS proxy to the Community Services occurs on the \"Community port\" (default 1533) specified in the Sametime Connect Client Sametime Connectivity settings. This connection is the same as the Use my Internet Explorer HTTP settings preference for a user who has a SOCKS proxy server selected in Internet Explorer.
Reverse proxy
This selection allows the Sametime Connect Client to connect to a Sametime server over the Internet through a reverse proxy server. The reverse proxy server protects internal HTTP servers by providing a single point of access to the internal network.
HTTP Proxy
The client encases the standard Sametime protocol connection information within an HTTP request. Sametime Connect Client connects to the HTTP proxy, and the HTTP proxy server connects to the Community Services multiplexer on the Sametime server on behalf of the Sametime Connect Client. The HTTP connection to the Community Services multiplexer occurs on the \"Community port\" (default 1533) specified in the Sametime Connect Client Sametime Connectivity settings.
The Community Services multiplexer on the Sametime server listens for HTTP Connections on all ports specified in the Port number field in the Client Connections section within the Community Services settings of the Sametime configuration database.
Follow these steps to select the Use proxy method for the client.
From the Sametime Connect client, select File > Preferences.
Do one of the following:
Select the appropriate Proxy type.
Use SOCKS4 proxy
Specify the additional values for the proxy type you selected.
Use SOCKS4 proxy
Provide the Host name (DNS name or IP address) of the SOCKS proxy server and the port required to connect to the SOCKS proxy server.
Use SOCKS5 proxy
Parent Topic: Choosing a method for connecting to the Sametime server
"},{"location":"admin/t_client_connect_tls.html","title":"Connecting the client through a TLS connection","text":"When a user starts the Sametime Connect client with a Direct connection using TLS preference, the client connects to the Sametime server using the Transport Layer Security (TLS) protocol. Use this preference for clients that must connect through a FIPS proxy server.
Follow these steps to select the Direct connection using TLS method for the client.
From the Sametime Connect client, select File > Preferences.
Do one of the following:
Parent Topic: Choosing a method for connecting to the Sametime server
"},{"location":"admin/t_collecting_configuration_logging_data.html","title":"Collecting Sametime client configuration and log data","text":"You can collect client logs and configuration data into a zip file.
Go the Collect Support Data window.
Select one or more Sametime options, and then click Next.
If you want to reproduce the issue, click Collect. When the collection completes, a link to the collection zip file is provided.
Parent Topic: Troubleshooting Sametime clients
"},{"location":"admin/t_community_provisioning_docker.html","title":"Creating a community provisioning URL on Docker or Podman","text":"As discussed in Creating a community provisioning URL for mobile users, mobile users cannot connect to the Sametime server without a special mobile community definition that provides details needed for the connection. This topic discusses the specific steps to set up the community provisioning URL on Docker or Podman.
Ensure that you have read Creating a community provisioning URL for mobile users for the general guidelines on how to create and configure the custom provisioning URL.
Open the .env file for editing.
Add the following line.
MOBILE_CONFIGURL=hclsametime://stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\nNote: To use the user name as part of the provisioning URL, follow this format:
MOBILE_CONFIGURL=hclsametime://%s@stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\nWhen using the user name, take note of the % symbol preceding the hostname. The proxy adds the current user to the provisioning URL when the URL is generated using the web client.
Save the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Creating a community provisioning URL for mobile users
"},{"location":"admin/t_community_provisioning_k8s.html","title":"Creating a community provisioning on Kubernetes","text":"As discussed in Creating a community provisioning URL for mobile users, mobile users cannot connect to the Sametime server without a special mobile community definition that provides details needed for the connection. This topic discusses the steps to set up the community provisioning URL on Kubernetes.
Ensure that you have read Creating a community provisioning URL for mobile users for the general guidelines on how to create and configure the custom provisioning URL.
Update the environment using this format.
kubectl set env deploy/proxy 'MOBILE_CONFIGURL=hclsametime://stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server'\nThe changes persist in your deployment. To apply the changes to new deployments, you must edit the helm/charts/auth/templates/deployment.yaml file and add the new settings to the proxy: section.
containers:\n - proxy:\n<<< INSERT NEW SETTINGS HERE >>>\nInsert this, for example:
- name: MOBILE_CONFIGURL\n value: \"hclsametime:stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\"\nApply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Creating a community provisioning URL for mobile users
"},{"location":"admin/t_config_alt_client_connect.html","title":"Configuring alternate communities for clients","text":"Configuring alternate communities gives users more options for logging in from their Sametime Connect Client and Sametime Embedded Client for Notes. For example, you can have a default community that allows users to connect using a direct connection when they are in the office and you can add an alternate community that allows them to connect to the same community through a reverse proxy server connection from home.
Alternate communities are defined using preferences. Before clients install, you can define preferences with a plugin_customization.ini file that goes into effect when the client logs in after installation. You can also define preferences after installation and distribute them through the policy-based managed-settings.xml file.
First define the managed IDs for each alternate community using the \"com.ibm.collaboration.realtime.community/altCommunityConfig.managedIds\" preference. This is a comma-delimited set of IDs you define.
Then for each ID, add the Community preferences reserved for alternate communities.
For example:
com.ibm.collaboration.realtime.community/altCommunityConfig.managedIds=altHost1,altHost2\ncom.ibm.collaboration.realtime.community/altCommunityConfig.altHost1.<attribute>=<attribute value>\ncom.ibm.collaboration.realtime.community/altCommunityConfig.altHost2.<attribute>=<attribute value>\nAfter you configure alternate communities and distribute them through preferences, they become available when users attempt to log in to the default community. If the default community is not available, the client then tries the alternate communities that you have defined. The client continues through the list of alternate communities until it connects successfully or all attempts fail.
Parent Topic: Connecting the Sametime Connect client to the Sametime server
"},{"location":"admin/t_configure_default_virtual_background.html","title":"Adding virtual backgrounds to the global library","text":"By default, you can customize your meetings with virtual backgrounds. As an administrator, you can choose which backgrounds are available to all users.
Parent Topic: Configuring
"},{"location":"admin/t_configure_jitsi.html","title":"Deploying multiple videobridges in different geographic locations","text":"Deploying multiple Kubernetes clusters each with a separate Sametime deployment allows for the distribution of videobridges to different locations. This type of deployment improves video streaming by reducing latency and improves bandwidth when users are geographically far from a single videobridge. The Octo Protocol is required to route video streams between videobridge servers.
Obtain the geolocation license key from Geolocation DB. The location service determines the region matching and is needed for the primary installation.
This configuration must be done as part of installation.
Run the command to prepare the primary deployment.
./prepareDeployment.sh\nWhen prompted, answer Y to the Enable Octo prompt. For more information, refer to t_meetings_configure_deployment.md.
Deploy the helm charts. Save the deployed charts for future reference. For more information, refer to t_installing_deploy_kubernetes.md.
helm install sametime .\nNote:
. represents current directory.sametime, you can choose any descriptive name for the deployment. You can also deploy the application in a namespace through the -n or --namespace option. First create the namespace with kubectl create namespace.Obtain MeetingLocationSecret, JvbAuthPassword, and JwtSecret from the primary installation. You can find this in <ReleaseName>-global-secrets.
Ensure that the TCP primary prosody is open on port 5222 for the secondary JVB to connect. The prosody host is accessible through the network load balancer if one is available in your deployment. Every deployment has a different FQDN and region. Run the command to obtain the FQDN of the prosody host on the primary deployment.
kubectl get service jitsi -o yaml | grep -E 'hostname|ip'\nIf your deployment does not have a load balancer, you can use the nginx ingress controller to forward tcp-services for port 5222. Make sure you configure the nginx-ingress-controller to enable tcp-services. Then in the tcp-services configmap, add an entry. In the following example, the primary Sametime deployment is in the default namespace.
\"5222\": default/jitsi:5222\nRun the command for the second deployment, using the information gathered in step 4.
./prepareDeployment.sh \nOptional: Repeat step 6 for every deployment if you have more than one primary or secondary installation.
Switch to each remote regional cluster and deploy each deployment using helm. Save the deployed charts.
Note: Assuming you use a single kubectl client to deploy against the primary and remote clusters, you can run the command to see the possible cluster contexts.
kubectl config get-contexts\nYou can use the --kube-context on the helm command and the --context option on the kubectl command to switch the context as you perform tasks against each deployment.
After enabling multiple video bridges, you end up with a single primary installation and one or more secondary installations. Having multiple primary installations in one or multiple regions is not required.
Open the correct port to establish a UDP connection. Primary JVB talks to secondary JVB and vice versa through JVB_OCTO_BIND_PORT.
Test the UDP connection to ensure that the users who have joined from separate bridges are able to communicate.
LTPA tokens expire by design. In the process of enabling LTPA, you can define the amount of time after which a token expires in minutes. When necessary, you can update the token expiration interval again after the value has been defined during enablement.
The following conditions must be satisfied.
Ensure that the LTPA token created when you sign in to Sametime chat allows access to other Domino applications until the expiration time has elapsed.
Open the .env file for editing.
Update the value of LTPA_DURATION_MINUTES. Specify the duration in this format:
LTPA_DURATION_MINUTES=<minutes_token_valid>\nThe following example shows LTPA_DURATION_MINUTES set to 90 minutes.
LTPA_DURATION_MINUTES=90\nAdd or update the value of JWT_ACCESS_DURATION_MINUTES. Specify the duration in this format:
JWT_ACCESS_DURATION_MINUTES=minutes_token_valid\nThe following example shows JWT_ACCESS_DURATION_MINUTES set to 30 minutes.
JWT_ACCESS_DURATION_MINUTES=30\nSave the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up SSO using LTPA
"},{"location":"admin/t_configure_ltpa_duration_k8s.html","title":"Configuring the LTPA token expiry interval on Kubernetes","text":"LTPA tokens expire by design. In the process of enabling LTPA, you can define the amount of time after which a token expires in minutes. When necessary, you can update the token expiration interval again after the value has been defined during enablement.
The following conditions must be satisfied:
Ensure that the LTPA token created when you sign in to Sametime chat allows access to other Domino applications until the expiration time has elapsed.
Update the environment using this format:
kubectl set env deploy/auth -e LTPA_DURATION_MINUTES=<minutes_token_valid>\nThe following example shows LTPA_DURATION_MINUTES set to 30 minutes.
kubectl set env deploy/auth -e LTPA_DURATION_MINUTES=30\nAdd or update the JWT_ACCESS_DURATION_MINUTES environment variable. Specify the duration in this format:
JWT_ACCESS_DURATION_MINUTES=<minutes_token_valid>\nThe following example shows JWT_ACCESS_DURATION_MINUTES set to 30 minutes.
kubectl set env deploy/auth -e JWT_ACCESS_DURATION_MINUTES=30\nFor the changes persist in your deployment and to apply the changes to new deployments, you must edit the helm/charts/auth/templates/deployment.yaml file and add the new settings to the env: section.
containers:\n - env:\n<<< INSERT NEW SETTINGS HERE >>>\n{{- if (.Values.global.ltpaRealm) }}\n - name: LTPA_REALM\n value: {{ .Values.global.ltpaRealm | quote }}\n{{- end }} \nInsert this, for example:
- name: LTPA_DURATION_MINUTES\n value: \"30\"\n - name: JWT_ACCESS_DURATION_MINUTES\n value: \"30\"\nApply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up SSO using LTPA
"},{"location":"admin/t_configure_mongodb.html","title":"Configuring MongoDB for Sametime","text":"This topic describes how to configure MongoDB on both Windows and Linux platforms to support Sametime and Sametime Premium deployments.
MongoDB security is enabled by default. Securing MongoDB is not required for Sametime but provides the best results.
Note: In the following steps, MongoDB version 6.0 is used as an example. If you are using a different version of MongoDB, refer to the official MongoDB documentation for how to issue commands for the version that you are using.
Access the Mongo Shell on the Primary node of the MongoDB cluster.
Run the db.createUser()method to add the user administrator. The following example creates the user sametimeAdmin with the userAdminAnyDatabase role on the admin database.
admin = db.getSiblingDB(\"admin\")\nadmin.createUser(\n {\n user: \"sametimeAdmin\",\n pwd: \"sametime\", // or cleartext password\n roles: [ { role: \"userAdminAnyDatabase\", db: \"admin\"}, {role:\"readWrite\", db:\"chatlogging\"}, {role:\"dbAdmin\",db:\"chatlogging\"}, {role:\"readWrite\", db:\"mobileOffline\"}, {role:\"dbAdmin\", db:\"mobileOffline\"}, { role:\"readWrite\", db:\"meeting\"}, {role:\"dbAdmin\", db:\"meeting\"}, { role:\"readWrite\", db:\"privacy\"}, {role:\"dbAdmin\", db:\"privacy\"}, { role:\"readWrite\", db:\"userinfo\"}, {role:\"dbAdmin\", db:\"userinfo\"} \n ] \n }\n )\nEnsure that passwords are random, long, and complex to prevent security breaches.
Note: As previously mentioned, the localhost exception becomes unavailable after the first user is created. Ensure that the first user has the authority to create more users. Failure to do so could mean being unable to create or modify users with new privileges when you close the localhost exception.
From mongosh, run the db.auth()method to authenticate as the user administrator.
db.getSiblingDB(\"admin\").auth(\"sametimeAdmin\", \"sametime\") // or cleartext password\nRun the db.createUser()method to add the cluster administrator. The following example creates the user sametimeClusterAdmin with the clusterAdmin role on the admin database.
db.getSiblingDB(\"admin\").createUser( \n\n { \n\n \"user\" : \"sametimeClusterAdmin\", \n\n \"pwd\" : \"sametime\", \n\n roles: [ { \"role\" : \"clusterAdmin\", \"db\" : \"admin\" } ] \n\n } \n\n) \nThe following screen is displayed when the commands are completed successfully.
Optional: Create additional users by repeating steps 1\u20134 as required for your installation.
From the MongoDB console, run the following commands to create the chatloggingdatabase with events and sessions collections in MongoDB.
use chatlogging \n\ndb.EVENTS.insertOne({\"_id\" : \"dummy\"}) \n\ndb.SESSIONS.insertOne({\"_id\" : \"dummy\"}) \nNote: The commands are case-sensitive and must be typed as shown.
After the MongoDB is configured, you can install Sametime. Refer to Installing Sametime for the details.
Parent Topic: Installing MongoDB
"},{"location":"admin/t_configure_virtual_docker.html","title":"Adding default virtual backgrounds on Docker and Podman","text":"By default, virtual background is enabled. You can choose which backgrounds are available to users by default. Depending on your business needs, you can customize the global library and prevent users from uploading custom background images. For more information, refer to Disabling custom background uploads.
Ensure that all images are in JPG or GIF format.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Copy the image files into the sametime-config/web/virtual-background/custom directory.
Run docker compose up -d command to apply all changes.
Parent Topic: Adding virtual backgrounds to the global library
"},{"location":"admin/t_configure_virtual_docker.html#task_e31_gql_z5b","title":"Removing default virtual backgrounds on Docker","text":"Existing default background can be deleted from the global library.
Edit the custom.env file in the directory where the installation package was decompressed.
Add the following statement under the REMOVE_BACKGROUND_IMAGES variable specifying the image name.
REMOVE_VIRTUAL_BACKGROUNDS=<background-N>,*<background-N\\>*\nN is a number from 1 through 7.
Start the Sametime server to apply the changes.
docker compose up -d\nBy default, virtual background is enabled. You can choose which backgrounds are available to users by default. Depending on your business needs, you can customize the global library and prevent users from uploading custom background images. For more information, refer to Disabling custom background uploads.
Ensure that all images are in JPG or GIF format.
Copy the image files into the /usr/share/jitsi-meet/images/virtual-background/custom directory under the web pod and then restart the pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp <filename.gif> $POD:/usr/share/jitsi-meet/images/virtual-background/custom/.\nkubectl delete po $POD\nNote: Add the Namespace argument if Sametime is installed in a Namespace.
Parent Topic: Adding virtual backgrounds to the global library
"},{"location":"admin/t_configure_virtual_k8s.html#task_e31_gql_z5b","title":"Removing default virtual backgrounds on Kubernetes","text":"Existing default background can be deleted from the global library.
Edit the values.yaml file in the directory where the installation package was decompressed.
Add the following statement under the global.removeVirtualBackgrounds variable specifying the image name and then restart your pod.
global:\n removeVirtualBackgrounds=*<background-N\\>*,*<background-N\\>*\nN is a number from 1 through 7.
Note: You are not required to scale the backgrounds pod as these settings are global to the web app and only add to or subtract away from the default set of available \"system\" backgrounds. The backgrounds pod only deals with individual user settings and what background a user has selected.
The Sametime Connect client uses Server Communities preferences to connect to the Sametime server for presence and chat features.
The client uses the connection method selected in the global connection settings for all server communities unless the server community's Connection tab specifies an alternate method. This section explains how to configure the different types of connections.
Parent Topic: Managing Sametime clients
"},{"location":"admin/t_create_mongo_replset.html","title":"Setting up a replica set with keyfile access control","text":"Deploying a replica set with keyfile authentication is an important part of setting up a secure MongoDB cluster. This topic covers the said procedure as it applies to Sametime with MongoDB 6.0. For a detailed discussion on the topic and information regarding setup considerations, refer to the official MongoDB documentation.
Ensure that the following security settings have been configured.
Keyfile authentication requires each node in the replica set to have a shared keyfile that is used to authenticate each node to the others. Keyfile authentication is a powerful tool for securing a MongoDB cluster.
Note: As a best practice, use DNS hostnames instead of IP addresses when configuring replica set members or sharded cluster members and when configuring clusters across a split network horizon. Starting in MongoDB 5.0, nodes that are only configured with an IP address fail startup validation and do not start.
To set up a replica set with keyfile access control for Sametime, do the following.
Generate a keyfile. Run the following command using openssl.
openssl rand -base64 756 > /var/lib/mongo/keyfile\nchown mongod:mongod /var/lib/mongo/keyfile\nchmod 400 /var/lib/mongo/keyfile\nDistribute the keyfile to each node in the replica set. This can be done manually, by copying the keyfile to each node, or using a config file with the shared keyfile path. See the official MongoDB documentation for storage medium recommendations.
Note: Only the owner of the file can access the keyfile while running the mongod instances.
Update the MongoDB configuration file on each node to include the replica set name and the list of other members in the replica set.
If using the security.keyFile configuration file, do the following.
Define the keyfile path and replica set name in the configuration file. Include additional options as applicable.
security:\n keyFile: /var/lib/mongo/keyfile\nreplication:\n replSetName: rs0\nnet:\n bindIp: localhost,<hostname(s)|ip address(es)>\nRun the following command.
mongod --config <path-to-config-file>\nIf using the --keyFile command-line option, do the following:
Define the keyfile path and replica set name in the following command. Include additional options as applicable.
mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>\nWhere the keyfile path is /var/lib/mongo/keyfile and the replica set name is rs0.
Over the localhost interface, launch mongosh and connect to one of the mongod instances. Run mongosh on the same physical machine as the mongod instance.
Note: The localhost interface is solely accessible in the absence of any users created for the deployment.
Initiate the replica set.
From mongosh, run the following method. This procedure selects and assigns one of the members to be the primary.
Note: Ensure that you are running rs.initiate( in only one mongod instance for the replica set.
rs.initiate(\n {\n _id : \"myReplSet\",\n members: [\n { _id : 0, host : \"mongo1.example.net:27017\" },\n { _id : 1, host : \"mongo2.example.net:27017\" },\n { _id : 2, host : \"mongo3.example.net:27017\" }\n ]\n }\n)\nConnect to the primary member. To locate the primary member, run rs.status().
Parent Topic: Installing MongoDB
"},{"location":"admin/t_create_truststore.html","title":"Creating a truststore with a third-party certificate","text":"When creating a connection between the Sametime server and a service using TLS, a truststore is needed. The truststore is used to store certificates for Sametime.
To create a trust store, the Java Keytool command is used. The keytool utility must be installed to complete the steps. The command is part of the Oracle and OpenJDK toolkits. The OpenJDK is included with Sametime. For more information on keytool, see the OpenJDK The keytool Command or Oracle Tools Reference websites. Run the utility from the directory where it is installed.
Note: If you are using a Keytool version other than the version that comes installed with Sametime, see the Sametime unable to read trust store causing LDAP connection to fail knowledge article for additional configuration tasks.
The certificate used to trust the connection must be a CRT file type format. For chained certificates, you also need the root and intermediate certificates.
When using SAML connections, LDAP connections, and business card photos, there are additional considerations for creating the truststore.
Creating a truststore when using SAML
Creating a truststore when using LDAP
Creating a truststore when using business card photos
Parent Topic: Securing connections
"},{"location":"admin/t_create_truststore_LDAP.html","title":"Creating a truststore when using LDAP","text":"Ensure that you have read the section overview.
If the connection is secured using TLS, a certificate is needed to complete the SSL handshake with LDAP. If you are connecting to multiple LDAP servers that have different certificates, you need to trust each certificate in a single trust store.
The LDAP trust store file name must be ldaptruststore.p12. It is defined using the commands in this procedure.
Copy the certificates to be trusted to the machine where the keytool utility is installed, and stage them in a temporary directory.
Create a keystore by issuing the below command with the parameters:
keytool -importcert -storetype PKCS12 -keystore ldaptruststore.p12 -storepass truststore\\_password -alias alias\\_name -file file\\_to\\_trust.crt -noprompt\ntruststore_password : The desired password for your trust store. Save the password for later use.
alias_name : The value to display in the trust store, each certificate must have a unique alias.
file_to_trust.crt : The full path to the certificate you are adding to the trust store.
To import additional certificates into an existing trust store, run the below command, be sure to use a unique alias for each additional certificate.
keytool -importcert -storetype PKCS12 -keystore ldaptruststore.p12 -storepass truststore\\_password -alias aliasname -file file\\_to\\_trust.crt -noprompt\nTo implement the trust store, refer to the following topics.
Parent Topic: Creating a truststore with a third-party certificate
"},{"location":"admin/t_create_truststore_SAML.html","title":"Creating a truststore when using SAML","text":"Ensure that you have read the section overview.
When using a SAML connection, the Sametime server must be able to decode the SAML tokens. You need to know how many SAML partnerships or relying party trusts are required. For information on identifying the number, see Setting up SSO using SAML. If you are supporting more than one relying party trust, create one trust store that contains certificates for each one.
The SAML trust store file name must be samltruststore.p12.
Run the following command.
keytool -importcert -storetype PKCS12 -keystore samltruststore.p12 -storepass truststore\\_password -alias alias\\_name -file file\\_to\\_trust.crt -noprompt\ntruststore_password : The desired password for your trust store. Save the password for later use.
alias_name : The value to display in the trust store, each certificate must have a unique alias.
file_to_trust.crt : The full path to the certificate you are adding to the trust store.
Note: If you are using OpenJDK version 11 and later, add the -J-Dkeystore.pkcs12.legacy parameter to the command. For example:
keytool -importcert -storetype PKCS12 -keystore samltruststore.p12 -storepass truststore\\_password -alias alias\\_name -file file\\_to\\_trust.crt -noprompt -J-Dkeystore.pkcs12.legacy \nTo complete the configuration, refer to one of the following topics.
Parent Topic: Creating a truststore with a third-party certificate
"},{"location":"admin/t_create_truststore_businesscards.html","title":"Creating a truststore when using business card photos","text":"Ensure that you have read the section overview.
If you are retrieving photos from an HTTPS trusted URL, the Sametime Proxy service needs a truststore to properly retrieve the photos from the https-protected PhotoURL.
The truststore file name must be named proxytruststore.p12.
To create the truststore, run the following command.
keytool -importcert -storetype PKCS12 -keystore proxytruststore.p12 -storepass truststore_password -alias alias_name -file file_to_trust.crt -noprompt\ntruststore_password : The desired password for your truststore. Save the password for later use.
use.alias_name : The value to display in the truststore, each certificate must have a unique alias.
file_to_trust.crt : The full path to the certificate you are adding to the truststore.
After creating the truststore, see Retrieving photos from HTTPS hosts in Kubernetes and Retrieving photos from HTTPS hosts in Docker and Podman.
Parent Topic: Creating a truststore with a third-party certificate
"},{"location":"admin/t_dbutility_convertldap.html","title":"Converting chat history owner data from Domino directory to LDAP format","text":"The convert feature of the Sametime Database utility changes all contact list information from the Domino Directory format to LDAP format.
Stop the Sametime server prior to running the Sametime Database utility. Refer to Starting and stopping the Sametime server for the steps.
The convert task changes all contact list information from Domino Directory format to LDAP format. Changing all contact list information from Domino directory format to LDAP format converts forward slashes in the hierarchical name to commas.
Note: This task can only be performed once because you can only convert the directory format one time.
Create or edit a file that contains the environment variables.
Add the MongoDB access information to the file.
MONGO_CONNECTION_URL=mongodb://sametimeUser:xxxxxxxx@192.168.1.1:27017/admin?authSource=admin&authMechanism=SCRAM-SHA-256&readPreference=primary&directConnection=true&ssl=false\nNote: When applicable, using the values indicated, add or insert a new line below the last line for every environment variable.
Add the following statement.
TASK_LDAP=1\nRun the Database utility with the following command. The CSV file is mounted in the container in the /temp directory in the following example for the application to access and process. The tag attribute is the image tag to use.
docker run -v /temp:/temp:rw --env-file env\\_file\\_name hclcr.io/st/sametime-db-utility:tag\nTo verify your changes, view the report created in the data directory.
Parent Topic: Using the Sametime Database utility
"},{"location":"admin/t_dbutility_delete.html","title":"Deleting user IDs","text":"The delete feature of the Sametime Database utility removes specified individual contact names from contact lists and privacy lists.
Stop the Sametime server prior to running the Sametime Database utility. Refer to Starting and stopping the Sametime server for the steps.
The following is the format for the delete task in the CVS file. Each user ID to be deleted is listed on a separate line.
DELETE\n\"uid\"\nCSV files are case-sensitive and sensitive to spaces.
Create a CSV file. The file must be saved in UTF-8 format.
In the CVS file, specify the DELETE descriptor followed by the UIDs to be deleted. Specify each UID on a separate line. For example:
DELETE\nuid=John Deere,ou=sametime,dc=hcl,dc=com\nuid=Marta Smith,ou=sametime,dc=hcl,dc=com\ncn=portaladminid,o=example.com \nCopy the CSV file into an accessible read or writable location.
Create or edit a file that contains the environment variables.
Add the MongoDB access information to the file.
MONGO_CONNECTION_URL=mongodb://username:password@ip-address:port\u200b\nAdd the location of the CVS file.
DELETE_CSV=/temp/test_delete.csv\nTo delete the chat history of the affected IDs, add the following line.
DEEP_DELETE=1\nThe following is an example env_file_name file.
MONGO_CONNECTION_URL=mongodb://sametimeUser:xxxxxxxx@192.168.1.1:27017/admin?authSource=admin&authMechanism=SCRAM-SHA-256&readPreference=primary&directConnection=true&ssl=false\nDELETE_CSV=/temp/test_delete.csv\nDEEP_DELETE=1\nMount the CVS file in the container for the application to access and process.
Run the Database utility using the following command. The CSV file is mounted in the container in the/temp directory in the following example for the application to access and process. The tag attribute is the image tag to use.
docker run -v /temp:/temp:rw --env-file env\\_file\\_name.env hclcr.io/st/sametime-db-utility:tag\nTo verify your changes, view the report created in the data directory.
Parent Topic: Using the Sametime Database utility
"},{"location":"admin/t_dbutility_move.html","title":"Moving users","text":"The move feature of the Sametime Database utility allows you to move users from one organization to another.
Stop the Sametime server prior to running the Sametime Database utility. Refer to Starting and stopping the Sametime server for the steps.
The following is the format for the update task in the CVS file. Each ID to be updated is listed on a separate line. The syntax for the update task in the CVS files is:
ORGANIZATION\n\"current\\_org\",\"new\\_org\"\nCSV files are case-sensitive and sensitive to spaces.
Create a CSV file. The file must be saved in UTF-8 format.
In the CVS file, specify the ORGANIZATION descriptor followed by the UIDs to be deleted. Specify each UID on a separate line.
ORGANIZATION\n\"existing\\_organization\",\"new\\_organization\"\nFor example,
ORGANIZATION\n\"lotus\",\"ibm\" \nCopy the CSV file into an accessible read or writable location.
Create or edit a file that contains the environment variables.
Add the MongoDB access information to the file.
MONGO_CONNECTION_URL=mongodb://username:password@ip-address:port\u200b\nAdd the location of the CVS file.
DELETE_CSV=/temp/test_delete.csv\nTo delete the chat history of the affected IDs, add the following line.
DEEP_DELETE=1\nThe following is an example env_file_name file.
MONGO_CONNECTION_URL=mongodb://sametimeUser:xxxxxxxx@192.168.1.1:27017/admin?authSource=admin&authMechanism=SCRAM-SHA-256&readPreference=primary&directConnection=true&ssl=false\nDELETE_CSV=/temp/test_delete.csv\nDEEP_DELETE=1\nRun the Database utility using the following command. The CSV file is mounted in the container in the /temp directory in the following example for the application to access and process. The tag attribute is the image tag to use.
docker run -v /temp:/temp:rw --env-file env\\_file\\_name.env hclcr.io/st/sametime-db-utility:tag\nTo verify your changes, view the report created in the data directory.
Parent Topic: Using the Sametime Database utility
"},{"location":"admin/t_dbutility_update.html","title":"Updating user IDs","text":"The updates feature of the Sametime Database utility changes specified first names, last names, display names, or group names.
Stop the Sametime server prior to running the Sametime Database utility. Refer to Starting and stopping the Sametime server for the steps.
The following is the format for the update task in the CVS file. Each ID to be updated is listed on a separate line. The syntax for the update task in the CVS files is:
ID\n\"existing\\_ID\", \"new\\_ID\"[,\"new_display_name\"]\u200b\nCSV files are case-sensitive and sensitive to spaces.
The ID task works by comparing existing user IDs with the names provided in the CSV list, and replacing the IDs when a match is found. By default, comparisons are case sensitive. To allow case-insensitive comparisons of user IDs by adding the following statement to the sametime.ini file.
NC_ID_TASK_CASE_INSENSITIVE=1\nFor more information, refer to Configuring the sametime.ini file.
Create a CSV file. The file must be saved in UTF-8 format.
In the CVS file, specify the ID descriptor followed by the UIDs to be deleted. Specify each UID on a separate line. Note that
ID\n\"existing\\_ID\", \"new\\_ID\"[,\"new_display_name\"]\u200b\nFor example,
ID\n\"Maria Smith,\" \"Maria Smith-Brown\"[,\"Maria Brown\"]\nNote: The brackets [ ] indicate that the new display name is optional. If you use it, you must precede it with a comma. The new display name must immediately follow the comma. Do not leave a blank space between the comma and the new display name.
Copy the CSV file into an accessible read or writable location.
Create or edit a file that contains the environment variables.
Add the MongoDB access information to the file.
MONGO_CONNECTION_URL=mongodb://username:password@ip-address:port\u200b\nAdd the location of the CVS file.
DELETE_CSV=/temp/test_delete.csv\nTo delete the chat history of the affected IDs, add the following line.
DEEP_DELETE=1\nThe following is an example env_file_name file.
MONGO_CONNECTION_URL=mongodb://sametimeUser:xxxxxxxx@192.168.1.1:27017/admin?authSource=admin&authMechanism=SCRAM-SHA-256&readPreference=primary&directConnection=true&ssl=false\nDELETE_CSV=/temp/test_delete.csv\nDEEP_DELETE=1\nRun the Database utility using the following command. The CSV file is mounted in the container in the/temp directory in the following example for the application to access and process. The tag attribute is the image tag to use.
docker run -v /temp:/temp:rw --env-file env_file_name.env hclcr.io/st/sametime-db-utility:tag\nCopy the CSV file into an accessible read or writable location.
To verify your changes, view the report created in the data directory.
Parent Topic: Using the Sametime Database utility
"},{"location":"admin/t_define_hostserver.html","title":"Defining the host server and port for connecting to a Sametime server","text":"The Sametime Connect client uses the host and server community port preferences to determine the host name and port it should use when attempting a connection to the Sametime server.
Follow these instructions to define the host server and port for a server community.
Configuring client connectivity to the Sametime mux
Each user must update the Sametime Connect Client with the DNS name of the Sametime Community Mux server. If you have deployed multiple Sametime Community Mux servers, distribute users evenly among the servers. For example, with two multiplexers, direct half of your users to use multiplexer 1 and the other half to use multiplexer 2.
Open Sametime Connect client.
Choose File > Preferences > Server Communities.
In theServer Community field, type the fully qualified host name of the Sametime Community Mux server, such as messaging.example.com.
Parent Topic: Connecting the Sametime Connect client to the Sametime server
"},{"location":"admin/t_different_hostname.html","title":"Configuring alternate host name for Web Chat","text":"The default host name for Meetings and Web Chat are the same. However, you can configure Web Chat to use a different host name. In other words, you can use your chat host name instead of the default. There is a secondary cookie that is also used in the meeting authentication flow where if the cookie is present, then the redirect target is pulled from the cookie instead of the TARGET= parameter.
Parent Topic: Meetings
"},{"location":"admin/t_different_hostname.html#task_jww_2k2_rvb","title":"Configuring an alternate host name in Kubernetes","text":"To specify a different host name for your web chat access, update the values.yaml file. For example, if you want to webchat.company.comas your host name, add the following statement in the values.yaml file.
extraChatHostname: webchat.company.com\nTo specify a different host name, edit the custom.env file. For example, if you want to webchat.company.com as your host name add the following statement in the
REACT_APP_CHAT_SERVER_HOSTNAME\nBy default, you can upload any supported image type to use as your background during a meeting. Depending on your organization's requirements, you can disable custom background uploads by modifying the applicable file.
Kubernetes
Modify the configuration file. The default value is TRUE.
For Docker, update the value of the ENABLE_USER_VIRTUAL_BACKGROUND parameter:
ENABLE_USER_VIRTUAL_BACKGROUND=false\nFor Kubernetes, update the value of the UserVirtualBackgroundsEnabled parameter:
userVirtualBackgroundsEnabled: false\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping servers.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/t_disable_generate_report.html","title":"Disabling Sametime reports","text":"By default, meeting owners can generate meeting reports. You can change a setting to disable the ability for owners to generate meeting reports.
Update the following parameter.
For Docker, modify the value of MEETING_REPORTS_DISABLED in the .env file. The default value is false.
MEETING_REPORTS_DISABLED=true\nFor Kubernetes, modify the value of meetingReportsDisabled in the values.yaml file. The default value is false.
meetingReportsDisabled: true\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping the Sametime server.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/t_disable_recordings.html","title":"Disabling the recording feature","text":"By default, authenticated users can record meetings. As an administrator, you can disable this functionality.
Update the following parameter.
For Docker, modify the value of ENABLE_RECORDING in the .env file. The default value is 1.
ENABLE_RECORDING=0\nWhere 0 is false.
For Kubernetes, modify the value of enableRecording in the .yaml file. The default value is true
enableRecording: false\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping the Sametime server.
Parent Topic: Managing recording options
"},{"location":"admin/t_disabling_timer.html","title":"Disabling the meeting timer","text":"By default, Sametime is configured to display the meeting duration. You can change the setting to disable the timer.
To disable the meeting timer, set the parameter to true on the Meetings server.
Modify the configuration file. The default value is false.
For Docker, change the REACT_APP_HIDE_CONFERENCE_TIMER setting in the custom.env file.
REACT_APP_HIDE_CONFERENCE_TIMER=true\nFor Kubernetes, update the helm/values.yaml file.
hideConferenceTimer: true\nDepending on your environment, do the following.
For Kubernetes, run a helm upgrade command to apply the changes to your deployment.
helm upgrade {release-name} helm/.\nParent Topic: Managing Sametime Meetings
"},{"location":"admin/t_domino_ldap_docker.html","title":"Specifying a cipher for Sametime to connect to Domino LDAP on Docker or Podman","text":"Several options that are related to the LDAP server SSL or TLS secure communications can be controlled by environment variables that are used by System SSL. This topic discusses the steps on how to specify a cipher for Sametime to connect to Domino LDAP.
By default, Domino 12.0.x LDAP servers must be configured to support a certain cipher used by Sametime. For more information, see Sametime 12.0 TLS required ciphers to connect to Domino 12.0.2 LDAP.
This task involves defining the required cipher for Sametime to connect to Domino 12 LDAP servers. To support Domino 12.0.2 LDAP connections, follow these steps.
Open the custom.env file for editing.
Add the following line.
STI__Config__STLDAP_TLS_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384\nFor more information on how to configure the sametime.ini file, refer to Configuring the sametime.ini file on Docker or Podman.
Save and close the file.
Follow the steps in the Applying configuration changes in Docker or Podman topic.
Parent Topic: Securing connections between Sametime servers and LDAP
"},{"location":"admin/t_domino_ldap_k8s.html","title":"Specifying a cipher for Sametime to connect to Domino LDAP on Kubernetes","text":"This task involves defining the required cipher for Sametime to connect to Domino 12 LDAP servers.
By default, Domino 12.0.x LDAP servers must be configured to support a certain cipher used by Sametime. For more information, see Sametime 12.0 TLS required ciphers to connect to Domino 12.0.2 LDAP.
To support Domino 12.0.2 LDAP connections, follow these steps.
Place the values.yaml file in edit mode.
Locate the sametimeIni: setting in the file, and then add the new line, indented with four spaces:
STI__Config__STLDAP_TLS_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384\nFor more information on how to configure the sametime.ini file, refer to Configuring the sametime.ini file on Kubernetes.
Save and close the file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Securing connections between Sametime servers and LDAP
"},{"location":"admin/t_enabling_community_debug.html","title":"Enabling Community debug in Kubernetes","text":"The Sametime Community pod supports a variety of debug parameters as documented in Common debug parameters for Sametime Community Server article.
Note: In Sametime versions prior to version 12, the Community services debug was handled in the sametime.ini file.\u00a0 Beginning with Sametime 12, the parameters used for Community debug are in defined in a ConfigMap in Kubernetes.
The changes in this task affect the following pods:
community
Change directories to where helm is located.;
Open the values.yaml file for editing.
In theglobal section, add the following line:
enableCommunityDebug: true\nNote: Confirm the indentation matches the other settings (two spaces).
When finished, save and close the file.
Apply the changes.
Upgrade the deployment by following the instructions in Applying configuration changes in Kubernetes or Openshift.
Run the following command to open the ConfigMap.
kubectl edit cm sametime-community-logging\nPress i to switch to edit mode.
Configure any custom debug parameters. If you know the parameter, configured with the following format.
The first characters are STI__DEBUG.
Note: Enter two underscores to separate.
If your debug parameters belong in the [Debug] section of the sametime.ini originally, add two underscores and then your parameter, followed by a colon and its value in quotes. For example, if setting VP_LDAP_TRACE=1 at the [Debug] section of the sametime.ini file, then the configuration setting is:
STI__DEBUG__VP_LDAP_TRACE: \u201c1\u201d\nNote: In the example, there are two underscores between STI and DEBUG and then two more underscores before the parameter.
If your debug setting is a component level debug such as [Debug-StUsers], then the parameter must have the same beginning STI__DEBUG, followed by a single underscore and the component name, and then two underscores and the parameter. For example, if you are setting component level debug for VP_TRACE_ALL=1 for the [Debug-StUsers] component, then the configuration setting is like the following:
STI__Debug_StUsers__VP_TRACE_ALL: \"1\"\nSave and close the ConfigMap.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/t_example_preferences_2.html","title":"Hosting client files for Sametime on Kubernetes","text":"Sametime clients can be configured by administrators using a managed-settings.xml or managed-community-configs.xml file which is hosted by a web server. Additionally, the Sametime client can be pre-configured with settings such as the host name and port. The client package can be hosted on a web server for download.
Ensure that you have access to kubectl command line tool.
Note: If Sametime is deployed in a namespace, append the -n namespace argument to all kubectl commands.
This procedure copies the file from the machine that runs kubectl to the persistent volume and have the web pod automatically retrieve the file when it starts. Use this procedure for each file that you would host in the default downloads directory.
Place the file that you are making available to users on the machine that runs kubectl. Then change directories to where the files are located.
Run the following command to get the name of the web pod.
kubectl get pods\nRun the following command to copy the file from the machine that runs kubectl to the web pod.
kubectl cp filename pod:/usr/share/nginx/downloads/.\nWhere pod is the web pod name For example, suppose the following for the variables:
The file name is managed-settings.xml
web-6d4cc59bc9-v8gf4 Then the command should be:kubectl cp managed-settings.xml web-6d4cc59bc9-v8gf4:/usr/share/nginx/downloads/.\nNote: If using a namespace, add the -n namespace argument after kubectl and before cp.
Scale the web pod to 0, then up to 1.
kubectl scale deploy/web --replicas=0 \n\nkubectl scale deploy/web --replicas=1 \nConfirm the URL is working for download. Open a browser and enter the HTTPS formatted URL:
https://sametime.example.com/downloads/managed-settings.xml\nsametime.example.com is the host name of the Sametime serverHosting files containing the same file name This topic covers the additional steps necessary for environments that require hosting multiple managed-settings.xml or managed-community-configs.xml files.
Parent Topic: Defining preferences in the managed-settings.xml file
"},{"location":"admin/t_generate_certkey.html","title":"Obtaining the cert.key and cert.crt files for Sametime","text":"The CSR is generated on the same server you plan to install the certificate on and contains information the Certificate Authority (CA) uses to create your certificate. It also contains the public key that is included in your certificate and is signed with the corresponding private key.
The CSR contains three sets of information:
Open the terminal on your computer, and depending on the platform that you are using, run the applicable code to create the certificate signing request (CSR). If you see the name of your user account in the terminal, then the task is done. Two new files (.KEY and .CSR) are generated in this process.
Provide the needed business information and submit to the Certificate Authority for signing. When successful, the Certificate Authority sends back a .CRT file.
Rename the .KEY and .CRT files into cert.key and cert.crt respectively.
Place the renamed files in the following directory.
<installation_directory.>/sametime-config/web/keys/\nWhere installation_directory is the Sametime installation directory.
You can replace or update the TLS certificates. For more information, refer to Replacing the TLS certificates for Web Chat and Meetings, Updating the TLS certificates on Docker, and Updating the TLS certificates on Kubernetes.
Parent Topic: Securing connections
"},{"location":"admin/t_host_samefilename_k8s.html","title":"Hosting files containing the same file name","text":"This topic covers the additional steps necessary for environments that require hosting multiple managed-settings.xml or managed-community-configs.xml files.
Ensure that you have access to kubectl.
Note: If Sametime is deployed in a namespace, append the -n namespace argument to all kubectl commands.
When configuring managed settings or managed community configs for different groups of users, you might require the users to have different settings. Sametime requires the file name to be the same. To support multiple files with the same name, you must put them in separate directories. This is the procedure for creating the directories in the web pod to host the files. There is no limit to the number of directories that can be created.
In the following example, there are two managed-settings.xml files for a group named east and a group named west.
Run the following command to obtain the name of the web pod.
kubectl get pods\nRun the following command to remote into the web pod, where webpod_name is the name of the pod from the first command.
kubectl exec -it webpod_name -- bash\nWhen inside the web pod, change directories to /usr/share/nginx/downloads.
cd /usr/share/nginx/downloads\nMake a directory for each file you are hosting, where directory_name is the name of the directory you are creating.
mkdir directory_name\nFor example, if hosting a managed-settings.xml for a group called east and a separate group called west, then create the directories east and west.
mkdir east\n\nmkdir west\nRun the command to exit from the pod.
exit\nOn the machine that runs kubectl, copy the managed-settings.xml file for the first group; for example, east. Then change directories to where the file is located.
Run the following command to copy the file from the machine that runs kubectl to the web pod.
kubectl cp <filename> <pod>:/usr/share/nginx/downloads/<directory_name>/.\n<filename> is the name of the file you are copying<pod> is the web pod nameWhere <directory_name> is the name of the directory you created For example, suppose the following for the variables.
The file name is managed-settings.xml
web-6d4cc59bc9-v8gf4east Then the command should be:kubectl cp managed-settings.xml web-6d4cc59bc9-v8gf4:/usr/share/nginx/downloads/east/.\nNote: If using a namespace, add the -n argument after kubectl and before cp.
Repeat step 7 for the other files that are being configured.
Scale the web pod to 0, then up to 1.
kubectl scale deploy/web --replicas=0 \n\nkubectl scale deploy/web --replicas=1 \nConfirm the URL is working for download. Open a browser and enter the https formatted URL:
https://sametime.example.com/downloads/east/managed-settings.xml\nsametime.example.com is the host name of the Sametime servereast is the name of the custom directory that was created beforemanaged-settings.xml is the name of the file being hostedParent Topic: Hosting client files for Sametime on Kubernetes
"},{"location":"admin/t_ingress_configure.html","title":"Configuring Ingress for Mux","text":"Complete the steps in the topic Installing Ingress. It is recommended to save the file that you are creating as a result of this topic. Do not save the file in the helm folder; save it at the root directory or sub-directory where the Sametime installation package was unzipped.
Sametime mux serves connections from Sametime Connect and embedded clients on port 1533. This connection can be routed through the ingress controller as well. This is suitable for an on-premise Kubernetes cluster.
If you are deploying in a cloud hosted Kubernetes environment (Google Kubernetes Engine, Amazon Elastic Kubernetes Service, etc) the Sametime mux is deployed as a Kubernetes load balancer service automatically. These steps are not necessary for cloud hosted environments.
For traffic to flow through the Ingress controller, you must apply a configuration map to Ingress.
Create a file called mux-configmap.yaml with the following content.
apiVersion: v1\nkind: ConfigMap\nmetadata:\n name: tcp-services\n namespace: namespace\\_name\ndata:\n 1533: \"default/mux:mux\"\nIf ingress is installed in a namespace, include the namespace: namespace\\_name statement, otherwise remove it.
Apply the configMap values to the configuration by running the following command.
kubectl apply -f mux-configmap.yaml\nRun the following kubectl patch command so that port 1533 is available.
kubectl -n ingress-nginx patch deployment ingress-nginx-controller --type=json -p='[\\{\"op\": \"replace\", \"path\": \"/spec/template/spec/containers/0/args\", \"value\": [\"/nginx-ingress-controller\",\"--publish-service=$(POD_NAMESPACE)/ingress-nginx-controller\",\"--election-id=ingress-controller-leader\",\"--controller-class=k8s.io/ingress-nginx\",\"--configmap=$(POD_NAMESPACE)/ingress-nginx-controller\",\"--tcp-services-configmap=$(POD_NAMESPACE)/tcp-services\"] }]' \nVerify the service. For more information, see Testing Sametime chat and meeting clients.
Parent Topic: Installing Ingress
"},{"location":"admin/t_ingress_install.html","title":"Installing Ingress","text":"When running Kubernetes on-prem, managing load-balancing must be considered for Sametime Meetings and Web Chat. Both of these Sametime features require the addition of an ingress controller.
Ingress is secured with a TLS certificate which must be created. Create a secret for ingress by following the steps in Updating the TLS certificates on Kubernetes.
If different the host names for Web Chat and Meetings are different, open the values.yaml file and add the following line to identify the Web Chat host name.
extraChatHostname: web\\_chat\\_hostname\nVerify that there are two spaces at the beginning of the line. Save and close the values.yaml file.
Consider reserving a reserve a static IP address for Sametime to use. If one is not define during the installation, the IP address is dynamic and is subject to change.
There are many different ingress controllers available, however; not all of them have been tested with Sametime. The procedure in this topic describes deploying the NGINX Ingress controller. If you are using another ingress controller, refer to the documentation for that ingress controller.
An Ingress controller is also used for the Connect and Embedded clients mux traffic deployed on-premise Kubernetes. After installing the ingress controller, additional configuraiton steps are needed. See Configuring Ingress for Mux for details.
Helm commands are used to install and configure the NGINX Ingress controller.
Add the nginx repository using the helm repo command.
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx\nUpdate the repository with the following command.
helm repo update\nRun the following command to install NGINX.
helm install nginx-ingress ingress-nginx/ingress-nginx --set controller.service.loadBalancerIP=IP\\_address \nWhere IP_address is the reserved IP address.
If you have a namespace dedicated to Sametime, include the namespace option on the command.
Verify that nginx-ingress has accepted the correct static IP address by running the kubectl get command. To break free from this, use Ctrl+C.
kubectl get ingress\nUse Ctrl+C to return to the command prompt.
Configuring Ingress for Mux
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_installing_deploy_kubernetes.html","title":"Deploying Sametime to Kubernetes cluster","text":"Before you can deploy Sametime to a Kubernetes cluster, you must create the cluster.
Two types of server nodes are required:
Review the Planning for a Kubernetes cluster configuration topic for details and other considerations.
Change to the helm directory.
Deploy the helm chart.
helm install sametime .\nIf there are any errors, you must remove the installed product and fix the error before trying the installation again. See Uninstalling Sametime on Kubernetes for details.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_installing_docker_extrahosts.html","title":"Defining extra hosts for Docker deployments","text":"Extra hosts for Docker deployments can be defined when there are network or DNS issues. Defining extra hosts is optional and not a requirement to ensure the connections are successful.
In some cases on CentOS 8, the host names fail to resolve properly. If the DNS is unreliable in resolving host names to IP addresses, these can be defined manually in the configuration. The following steps work for all supported Linux versions.
Note: When modifying the yml file, the indentations use spaces to indent the text. Do not use tabs. The entries within the file must line up exactly.
Use the networks: placement as a reference for extra_hosts: and the sametime.test: placement as a reference for where the - is placed.
Open the docker-compose.yml file in edit mode.
The following components require a connection to the MongoDB server. Locate and update each section with the MongoDB host name and IP address.
networks add an extra_hosts statement, where mongoDB_host is the fully qualified hostname of the MongoDB server and mongoDB_IP_address is the IP address of the MongoDB server.extra_hosts: \n - mongoDB\\_host: mongoDB\\_IP\\_address\nFor example:
The community component requires a connection to the LDAP server. Locate and update this section with the LDAP host name and IP address.
After networks add an extra_hosts statement, where ldap_hostname is the fully qualified host name of the LDAP server and ldap_ip_address is the IP address of the LDAP server.
extra_hosts: \n - ldap.host: ldap\\_ip\\_address\nFor example:
The jvb component requires a connection to the STUN servers. In the jvb section, add an extra_hosts section an include a statement for each STUN server, where stun_host_name is the fully qualified host name of the STUN server, and stun_ip_address is the IP address of the STUN server.
- stun\\_host\\_name:stun\\_ip\\_address\nFor example:
extra_hosts:\n - stun_host_name:stun_ip_address\n - stun1_host_name:stun1_ip_address\n - stun2_host_name:stun2_ip_address \nResolve the host names of the STUN servers and use the corresponding IP address for your region. In the following graphic, the Google STUN servers are used with the regional resolved IP addresses.
Verify that the formatting is correct. Correct any indentations using spaces.
Save the changes.
Run the following commands to apply the changes.
docker-compose down\ndocker-compose up -d\nParent Topic: Installing Sametime in a Docker or Podman environment
"},{"location":"admin/t_installing_podman_extrahosts.html","title":"Configuring container networking with Podman","text":"The network layer does not have DNS resolve available between containers. This topic provides information on the network configurations needed to resolve network or DNS issues in Podman environments.
Ensure that the podman-compose version is 1.0.4 or higher. To update podman-compose, run the following command.
curl -o /usr/local/bin/podman-compose https://raw.githubusercontent.com/containers/podman-compose/devel/podman_compose.py\nchmod +x /usr/local/bin/podman-compose\nIf you are using Red Hat\u00ae Enterprise Linux\u00ae and Podman, you must configure the RHEL nodes to ensure the connections are successful.
Note: All commands provided require running as ROOT or SUDO access. If not running as root user, preface the commands in steps 1 and 2 with sudo.
Run the command to install Netavark.
dnf install netavark\nPlace the containers.conf file in edit mode.
sudo vi /etc/containers/containers.conf\n[network]\nnetwork_backend = \"netavark\"\nDo a force reset.
podman system reset --force\nBind Sametime to port 443.
sysctl net.ipv4.ip_unprivileged_port_start=443\nParent Topic: Installing Sametime in a Docker or Podman environment
"},{"location":"admin/t_keystore_mux.html","title":"Creating a keystore for Sametime mux","text":"A keystore consists of a private key and a certificate. Sametime supports both a third-party certificate, signed by a Certification Authority (CA), or a self-signed certificate. Request a certificate and private key from your CA for the hostname used by the Sametime mux. This is the microservice that listens on port 1533 for requests from the Sametime Connect clients (installed clients on desktop). In Kubernetes, the mux is either a Kubernetes service (for example, a load balancer type service) or a Kubernetes ingress service for on-premise Kubernetes. For Docker deployments, the mux listens on port 1533 and does not require any additional service.
Creating a keystore for Sametime mux: third-party CA
Creating a keystore for Sametime mux: self-signed certificate
Parent Topic: Securing connections between the Sametime mux and the Connect and Embedded clients
"},{"location":"admin/t_keystore_self_signed.html","title":"Creating a keystore for Sametime mux: self-signed certificate","text":"Run the following command to create a private key.
openssl genrsa -des3 -out server.key 2048\nThe key length can be modified to meet your requirements. The longer the key length, the more secure it is.
Note: The command prompts for a password. Record this password in a secure place for future reference.
Create a certificate signing request, which in this case, is signed by the self-signed CA. Run the command to create the self-signed x509 certificate.
openssl req -new -key server.key -out server.csr\nWhen you run the command, you must provide the following:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt\nIn the above command, the days parameter is 365 and can be modified.
Create the keystore.
openssl pkcs12 -export -in server.crt -inkey server.key -name \u2018mux\u2019 -out keystore.p12\nThe sample command makes use of the following naming conventions.
`server.crt`: Signed certificate filename\n`server.key`: Private key filename\n`\u2018mux\u2019`: Alias name (how it appears in the keystore)\n`keystore.p12`: The resulting keystore file name\nAfter the keystore is created, do the following:
Parent Topic: Creating a keystore for Sametime mux
"},{"location":"admin/t_logging_tracing.html","title":"Logging and tracing on the Sametime Embedded and Connect clients","text":"Trace logs are stored in a workspace folder on the user's local hard drive or a network drive. Sametime Embedded and Connect client users can enable tracing on their client with the following instructions.
Locate the client workspace.
On the computer where you use the client, use a text editor and open the rcpinstall.properties file which is located in the following directory according to the client:
C:\\Users\\user_name\\AppData\\Roaming\\HCL\\Sametime\\.config\\rcpinstall.propertiesC:\\Program Files\\HCL\\Notes\\Data\\workspace\\.config\\rcpinstall.propertiesC:\\users\\user_name\\AppData\\Local\\HCL\\Notes\\Data\\workspace\\.config\\rcpinstall.propertiesMac OS
Note: Use the Cmd+Shift+Dot keyboard combination to show hidden folders.
/Users/user_name/Library/Application Support/HCL Sametime Data/.config/rcpinstall.properties/Users/user_name/Library/Application Support/HCL Notes Data/Expeditor/Applications/.config/rcpinstall.propertiesC:\\users\\user_name\\AppData\\Local\\HCL\\Notes\\Data\\workspace\\.config\\rcpinstall.propertiesAdd the following lines to the end of the file, depending on what kind of issue you're diagnosing.
com.ibm.collaboration.realtime.level=FINEInstant messaging issues
com.lotus.sametime.community.kernel.level=FINER \ncom.lotus.sametime.im.level=FINEST\ncom.lotus.sametime.places.level=FINEST\ncom.ibm.collaboration.realtime.rtcadapter.level=FINEST \ncom.ibm.collaboration.realtime.people.internal.level=FINE \ncom.ibm.collaboration.realtime.internal.sametime.level=FINER \ncom.ibm.collaboration.realtime.login.level=FINEST\ncom.ibm.collaboration.realtime.community.internal.level=FINEST\nGeneral login failure
com.ibm.collaboration.realtime.community.internal.level=FINEST\ncom.ibm.collaboration.realtime.im.community.level=FINEST\norg.apache.commons.httpclient.level=FINE\ncom.ibm.rcp.internal.security.auth.module.level=FINEST\ncom.ibm.collaboration.realtime.login.level=FINEST\ncom.lotus.sametime.community.level=FINEST\nSSO failures
com.ibm.collaboration.realtime.community.internal.level=FINEST\ncom.ibm.collaboration.realtime.im.community.level=FINEST\norg.apache.commons.httpclient.level=FINE\ncom.ibm.rcp.internal.security.auth.module.level=FINEST\ncom.ibm.collaboration.realtime.login.level=FINEST\ncom.lotus.sametime.community.level=FINEST\ncom.ibm.rcp.internal.security.level=FINEST\ncom.ibm.rcp.security.level=FINEST\nManaged settings
com.ibm.collaboration.realtime.policy.sametime.managedsettings.level=FINEST\nCalendar integration issues
com.ibm.rtc.meetings.servers.level=FINEST\ncom.ibm.rtc.meetings.shelf.level=FINEST\ncom.ibm.rtc.meetings.shelf.ui.level=FINEST\ncom.ibm.rtc.meetings.util.level=FINEST\ncom.ibm.collaboration.realtime.calendar.level=FINER\ncom.ibm.collaboration.realtime.calendar.notes.level=FINEST\nConnectivity issues
com.ibm.rtccore.level=FINEST\ncom.ibm.rtc.spaces.level=FINER\nTo reduce the number of log and trace files from being overwritten, increase the option values of the following settings from the default values. The default values are:
com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.count=20\ncom.ibm.rcp.core.internal.logger.boot.RCPLogHandler.count=12\nSave and close the file.
Restart the Connect client.
View the error log and trace files in the Connect client, by clicking Help > Support > View Log and View Trace.
In most cases, View Trace provides the most useful information.
You can include logs and other data into a compressed ifle to send to support for diagnostics.
In the Notes embedded client, click Help > Support > Collect Support Data. In the stand-alone Connect Client, click Gear icon > Help > Support > Collect Support Data.
Select Enable Customized Tracing, and then click Next.
Select one or more Sametime options, and then click Next.
Specify if you want to reproduce the issue, and then click Collect. When the collection completes, a link to the zip file is provided.
The resulting file is located
Parent Topic: Troubleshooting Sametime clients
"},{"location":"admin/t_manage_user_login_docker.html","title":"Managing user sign-on on Docker or Podman","text":"A token is maintained by the Sametime server to control how often you sign in. The default value is 30 days. You can modify this value or turn off the feature by including the JWT_REFRESH_DURATION_DAYS environment variable in the YAML file. You can specify any number of whole days to retain login credentials. To disable this feature, set the value to 0.
When you modify the docker-compose.yml file, follow the syntax rules for YAML files to prevent coding errors. When you modify the YAML file, the indentations of entries are spaces, not tab characters.
Edit the docker-compose.yml file and locate the auth section within the file.
The file is in the root directory.
Add the JWT_REFRESH_DURATION_DAYS environment variable.
Specify the duration in this format:
JWT_REFRESH_DURATION_DAYS=number\\_of\\_days\nThe following example shows the auth section with the JWT_REFRESH_DURATION_DAYS environment variable set to 10 days.
Save the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Managing user sign-on
"},{"location":"admin/t_manage_user_login_k8s.html","title":"Managing user sign-on on Kubernetes","text":"A token is maintained by the Sametime server to control how often you sign in. The default value is 30 days. You can modify this value or turn off the feature by adding the JWT_REFRESH_DURATION_DAYS environment variable. You can specify any number of whole days to retain login credentials. To disable this feature, set the value to 0.
You can change settings temporarily or permanently. To temporarily change the setting, run the following command to change the setting in a deployed environment.
kubectl set env deploy/auth JWT_REFRESH_DURATION_DAYS=number\\_of\\_days\nTo permanently change the setting, complete the following steps:
Edit the deployment.yaml file, which contains the auth environment variables.
You can find the file in the helm/charts/auth/templates directory.
Add the JWT_REFRESH_DURATION_DAYS environment variable.
Specify the duration in this format:
name: JWT_REFRESH_DURATION_DAYS value: number\\_of\\_days\nThe following example shows the auth section with the JWT_REFRESH_DURATION_DAYS environment variable set to 10 days.
Save the changes.
Perform a helm upgrade to deploy the updated chart.
Parent Topic: Managing user sign-on
"},{"location":"admin/t_managing_transfer_data.html","title":"Managing file transfer data","text":"As with meeting recordings and reports, files that are shared in the chat are stored in a Docker volume or a Kubernetes persistent volume. By default, you can download these files within 90 days.
You can modify the limit by updating the following files.
Kubernetes
helm/values.yaml
Note: The values are case sensitive and must be entered as shown below.
Modify the configuration file. The minimum value is 1.
Parent Topic: Administering
"},{"location":"admin/t_meetings_configure_deployment.html","title":"Preparing the deployment","text":"This section provides information on how to configure secrets for deployment.
Run the following script to prepare the deployment.
./prepareDeployment.sh\nLDAP server host
Enter the fully qualified host name or the IP address of the LDAP server.
LDAP server port
Enter the port used by LDAP.
Configure advanced LDAP settings
Enter Y to configure advanced LDAP settings. Provide the following information.
-- LDAP bind user name
-- LDAP bind password
-- LDAP base DN for searching users
-- LDAP base DN for searching groups
Enter N to bypass the above prompts. This option results in an anonymous LDAP connection and sets the default settings for searching.
Sametime server name
Enter the fully qualified Sametime server name. This value needs to be the fully qualified host name of the Sametime server. If you are separating host names for meeting and chat, enter the meeting host name. Server domain name
Enter the server domain name. This should be the DNS suffix of the host name of the server.
Video bridge IP address
Enter the video bridge IP address. When left empty, the system automatically scans and populates the field with the discovered IP address.
Base64 encoded secret
Enter the Base64 encoded JWT_SECRET from the Sametime deployment. If migrating from another version of Sametime, you can re-use your existing secret. Otherwise, leave blank and press Enter to generate a new one.
Mongo host
Enter the fully qualified host name of your MongoDB server. The default value is mongo. If you have more than one host, provide any of the hosts. You can provide the rest later on when prompted.
Mongo port
Enter the MongoDB port. The default value is 27017.
Mongo admin user name
Enter the Mongo administrator user name.
Mongo admin user password
Enter the Mongo administrator password
MongoDB connection URL
The default Mongo connection URL is [($TEMP_URL)]. Would you like to override? [Y/N]
mongodb://<user>:<password>@<server1>:<port>,<server2>:<port>,<server3>:<port>\nTURN server address
Leave blank if you are not using TURN. Otherwise, enter the fully qualified host name of the TURN server.
For more information, refer to [Configuring the TURN server for Docker and Podman](turnserver_meetings_docker.md) and [Configuring the TURN server for Kubernetes](turnserver_meetings_kubernetes.md).\nConfigure LTPA
Lightweight Third-Party Authentication (LTPA) is useful for achieving single sign-on with HCL Domino (including HCL Verse and iNotes), HCL Connections, HCL Digital Experience, and IBM WebSphere Application Server. The default value is N.
To configure LTPA, enter Y and provide the following information.
- The full path to the LTPA keys file. This should be the full path on the machine where the `prepareDeployment.sh` script is running. For example: /tmp/ltpa.keys\n- LTPA keys password\nFor more information, refer to Setting up SSO using LTPA.
Enable Octo
Octo allows you to extend the audio-video traffic to another network in an efficient way. If enabled, at least one other secondary cluster must be configured in order for this to work. To enable octo, enter Y. The following prompts are displayed.
For more information, refer to Deploying multiple videobridges in different locations.
- Is this a primary installation?\n - Select **Yes** to set this instance as the primary server. For primary servers, you must provide the region name. Enter the name of the primary region.\n - Select **No** to set this instance as a regional server. For regional servers, you must provide the region name. Enter the secondary region name.\n - If no, you must enter the fully qualified host name of your primary installation. Provide the following information.\n - Prosody host from primary installation\n - Meeting location secret in base64 from primary installation\n - JVB authentication password in base64 from primary installation\n\n **Note:** On your primary cluster, run this script to obtain the values for the meeting location secret and JVB authentication password.\n\n ``` {#codeblock_pdy_r1l_z5b}\n kubectl get secret sametime-global-secrets -o yaml | grep -E 'MeetingLocationSecret|JvbAuthPassword'\nChange directories to helm.
Open values.yaml for editing.
Locate the setting hclImageRegistry: and then set the value to your image repository name. If you are using a secret to access the image repository, then set the hclImagePullSecret value with the name of the secret for the image repository.
This is the Docker repository where the Sametime Docker images are located. If you use a cloud provider image registry or your own private registry, you should update this setting to the base name of that image registry. The default is http://hclcr.io/st and assumes that you have executed the ./load.sh script with its default configuration on each Kubernetes node.
Locate the setting sametimeClaim. This is the name of the persistent storage volume claim that is used by recordings, proxy, files, and backgrounds for storage.
You can also modify other values at this time to enable, disable, or configure features.
Save and close values.yaml.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_meetings_kubernetes.html","title":"Configuring host aliases for Kubernetes deployments","text":"If your Kubernetes environment is unable to consistently resolve the host names of the supporting servers (MongoDB, Sametime Proxy, STUN) using DNS, configure the hosts manually.
In Kubernetes, you can add host names and their corresponding IP addresses to the host aliases. In a Sametime Meetings on Kubernetes deployment, this setting is defined in the deployment.yaml in the various templates for each Kubernetes pod.
Table 1 lists the pod name and template for each host to be resolved.
Modify each template specified in Table 1 to include the host name and IP address of the required supporting server.
Complete the following steps to modify each template in the table to include the host name and IP address of each supporting server.
Note:
Open the template for editing.
Locate the following line and insert a new line.
restartPolicy=Always\nUse this example text as a template and include the host names that need to be resolved:
hostAliases: \n - hostnames: \n - \"ldap.company.com\" \n ip: \"10.10.10.10\" \n - hostnames: \n - \"mongodb.company.com\" \n ip: \"10.10.10.11\" \nNote: In the hostnames field, your server might only be known as one host name. You can add multiple aliases.
Before saving the template, ensure the indentations are correct, using only spaces for indentation. The hostAliases: line should line up exactly under the restartPolicy line at the same level of indentation. You might need to correct the other lines as well after copying and pasting them.
Save and close the template when changes are complete.
After this process is complete, continue to the steps to install Sametime. See load_stimages_local.md. If Sametime is already installed, follow the procedures in the apply_configchanges_kubernetes.md topic to apply the changes.
"},{"location":"admin/t_meetings_prepare_network.html","title":"Preparing the network","text":"This section provides information on the network considerations needed to install Kubernetes.
Network considerations
Sametime Meetings uses UDP on port 30000 by default for media streams. Ensure that the clients to service have UDP inbound access to this port and that outbound UDP traffic from the deployment is unrestricted.
The Sametime server must be able to connect to MongoDB with a user account which has the authority to create databases. The database is created during the installation.
STUN Service
Sametime Meetings use internet accessible STUN servers to help clients and the server negotiate media paths for the exchange of audio/video/appshare data. Public Google STUN servers are configured by default.
These addresses must be reachable by the container. If they are not, there may be issues joining meetings.
stun.l.google.com:19302\nstun1.l.google.com:19302\nstun2.l.google.com:19302\nTo change the defult STUN server, see Configuring alternate STUN servers. For further information on STUN, see the topic Session Traversal Utilities for NAT (STUN).
Ingress Controller
Kubernetes uses internal private network addresses for deployed services. Sametime uses an Ingress for incoming web traffic and either a LoadBalancer, NodePort, hostNetwork binding for media traffic. An ingress controller is required for the incoming web traffic and either the LoadBalancer or the IP address of the video node must be accessible for the media traffic.
DNS Considerations
Your Kubernetes cluster must be able to resolve the supporting servers: MongoDB, Sametime Proxy, and STUN. If DNS is unreliable or not able to resolve these hostnames to their IP addresses, complete the topic Configuring Host Aliases for Kubernetes deployments.\"
See Loading the Sametime images to a Docker repository.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_meetings_recordings.html","title":"Creating the persistent volume","text":"This section provides information to create the persistent volume.
In previous releases of Sametime, only the recordings pod require access to the persistent volume. In Sametime 12, workloads moved from virtual or physical machines into Kubernetes pods. There is more than one type of pod that requires access to storage in Sametime 12. Sametime requires an access mode called read write many or RWX which allows more than one node to access the volume at a time.
Recordings
Meeting recordings are stored as MP4 files in a temp directory on the meeting recorder nodes during the meeting. After the meeting, the recordings are moved to a persistent volume. Allocate a volume accessible to the Kubernetes cluster that is substantial enough to handle the expected number of meeting recordings, assuming a rate of about 100M per 1 hour of meeting.
By default, recordings persist for three days, so keep that in consideration as well when sizing the volume.
Backgrounds
When users upload personal backgrounds to their meetings for use as a video background, these images are stored in the persistent volume.
Files
When users upload files to chats in the chat clients or meeting, the files are stored in the persistent volume.
Branding
When enabling custom meeting branding, the images used are stored in the persistent volume.
Reports
Meeting reports are saved in the persistent volume.
For additional information, see the Persistent Volumes topic in the Kubernetes documentation.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_proxy_docker.html","title":"Configuring Docker and Podman to use a proxy server for push messaging","text":"When Sametime proxy interacts with mobile devices (phones, pads, watches, and cars), it sends notifications through push networks such as Apple's \"APNS\" and Google's \"FCM.\" To send APNS or FCM messages through a proxy server in Docker or Podman, follow these steps:
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Update the following values in your custom.env file.
push-proxy.company.com. Alternatively, you can enter the IP address of the push-proxy. For example, 123.111.222.333.3128.STCONF\\_PUSH\\_PROXY\\_SERVER=\"push-proxy.company.com\"\nSTCONF\\_PUSH\\_PROXY\\_PORT=\"3128\"\nSTCONF_PUSH_PROXY_USER=\"\"\n`STCONF_PUSH_PROXY_PASSWORD`=\"\"\nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Push messaging through a proxy
"},{"location":"admin/t_proxy_k8s.html","title":"Configuring Kubernetes to use a proxy server for push messaging","text":"When Sametime proxy interacts with mobile devices (phones, pads, watches, and cars), it sends notifications through push networks such as Apple's \"APNS\" and Google's \"FCM.\" To send APNS or FCM messages through a proxy server in Kubernetes, follow these steps:
Update the following values in your values.yaml file.
push-proxy.company.com. Alternatively, you can enter the IP address of the push-proxy. For example, 123.111.222.333.3128.pushProxyServer: \"push-proxy.company.com\"\npushProxyPort: \"3128\"\npushProxyUser: \"\"\npushProxyPasswordBase64: \"\"\nRestart the pod.
Parent Topic: Push messaging through a proxy
"},{"location":"admin/t_push_proxy.html","title":"Push messaging through a proxy","text":"Depending on your network settings, your firewalls could prevent Sametime proxy from connecting to push networks like Apple Push Notification Service (APNS) and Firebase Cloud Messaging (FCM) through the Internet. Sametime supports the sending of APNS and FCM messages through a proxy server. If you need to send APNS or FCM message through a proxy server in your environment, you need to configure the settings for the messages you want routed through the proxy.
Configuring Docker and Podman to use a proxy server for push messaging
Configuring Kubernetes to use a proxy server for push messaging
Parent Topic: Configuring
"},{"location":"admin/t_resolving_business_cards.html","title":"Resolving problems with business cards","text":"If business cards are not displaying user information as expected, first check the server configuration, then the client, and finally, the business cards themselves.
To check the server configuration, verify that the storage repository, such as LDAP used with the Sametime server is configured correctly. A configuration problem is the most likely cause of problems with business cards. For more information, see Setting up business cards.
If the configuration is correct, next verify that the business card information on requested from the clients is working correctly. For this, trace the UserInfo servlet flows to verify that the UserInfo servlet is working correctly. The UserInfo servlet runs on the server retrieves business card information on request from clients and responds to client requests. To determine if there are errors on the exchange of information, enable the UserInfo Debug trace.
If the UserInfo servlet on the server is responding correctly, enable client-side tracing to determine what is happening on the client. Follow the instructions in Logging and tracing on the Sametime Embedded and Connect clients. For Web clients, review the Proxy service logs and capture a browser HTTP Archive (HAR) file to review the business card information received.
Parent topic: Troubleshooting
"},{"location":"admin/t_resolving_business_cards.html#task_cmx_2pp_r5b","title":"Enabling the UserInfo Debug trace on Docker","text":"If a debug.env doesn't exist in the directory where the installation package was decompress, you must create it.
Add the following line to the debug.env file.
STI__debug__USERINFO_DEBUG_LEVEL=5 \nAdd the debug.env in the community section of the docker_compose.yml file.
Save the file.
Start the Sametime server to apply the changes and enable the trace.
docker compose up -d\nEdit the values.yaml file, changing the enableCommunityDebug property from false to true. Save this change.
Edit sameteime-community-logging ConfigMap, and add the following line to the data section.
STI__debug__USERINFO_DEBUG_LEVEL: \"5\"\nFor example:
kubectl edit cm sametime-community-logging\nApply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nSigner certificates establish the relationship in SSL communication. This step is needed by the Sametime server, specifically for cases where the PhotoURL is using SSL (HTTPS) to access business card photos.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
After obtaining the certificate file for the host, follow these steps.
Place the docker-compose.yml file in edit mode.
Find the proxy section and add the following volume.
volumes: \n - custom-config/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt\nFor example,
proxy:\n image: hclcr.io/st/chat-proxy:${BUILD_LEVEL}\n restart: ${RESTART_POLICY}\n env_file: custom.env\n volumes:\n - custom-config/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt\n - proxy-workspace:/workspace/proxy-storage\n environment:\n - JAVA_TOOL_OPTIONS=-XX:MaxDirectMemorySize=64M -XX:MaxMetaspaceSize=192M\n - SAMETIME_EXTERNAL_WARINTEGRATION\nSave the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up business cards
"},{"location":"admin/t_security_mongodb_tls_docker.html","title":"Enabling TLS for the Mongo database on Docker or Podman","text":"Ensure that the you have read the introductory topic and verified that the TLS connection itself can be established. For more information, refer to Verifying if TLS connection can be established.
Locate the local .pem file to use with your Mongo deployment. For more information, refer to the official MongoDB documentation.
Modify your Mongo URL to use TLS. For more information, refer to Setting up TLS for the Mongo database.
Open the docker-compose.yml file in edit mode.
Add the volume mount to the Community section of the YAML file.
/opt/sametime/cacert.pem:/local/notesdata/cacert.pem\nSave the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up TLS for the Mongo database
"},{"location":"admin/t_security_tls_mongodb_k8s.html","title":"Enabling TLS for the Mongo database on Kubernetes","text":"Ensure that you have read the Setting up TLS for the Mongo database topic. Verify if you have a valid TLS certificate. See Creating a truststore with a third-party certificate for the details.
Configure the Sametime server to use TLS.
Create a secret with your certificate.
kubectl create secret generic mongo-secret --from-file=<ca.crt>\nOpen the values.yaml file in edit mode.
Add the following secret.
mongoSecret: mongo-secret\nSave the changes.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up TLS for the Mongo database
"},{"location":"admin/t_testing_sametime_chat.html","title":"Testing Sametime chat and meeting clients","text":"This article assumes that you have successfully installed and configured Sametime or Sametime Premium.
Before going live, it is important to test the following services to ensure that Sametime is working as expected.
Verify if the Sametime web client chat is running. Using a web browser, go to the URL:
https://yourserver.domain.com/chat\nThe yourserver.domain variable is the name of your Sametime server and the domain name.
Verify if the Sametime server is running. Using a web browser, go to the following URL:
https://yourserver.domain.com \nhttps://yourserver.domain.com/meeting\nVerify if the Sametime Connect client and Sametime embedded client (in HCL Notes) are running.
Add a Sametime Server Community under Preferences specifying the Host server and Server community port.
The default Server community port value is 1533.
Enter a username and password on the Log In tab.
Select OK to save the changes.
Log in using the new credentials.
Parent Topic: Administering
"},{"location":"admin/t_troubleshooting_clients.html","title":"Troubleshooting Sametime clients","text":"Use this information on troubleshooting and logging tools to diagnose and resolve problems affecting the HCL Sametime clients.
Parent Topic: Troubleshooting
"},{"location":"admin/t_troubleshooting_ldap_kubernetes.html","title":"Troubleshooting LDAP on the community pod","text":"If you are having difficulty connecting to a secure LDAP server, perform the following troubleshooting steps.
Log into the community pod.
Find the name of the community pod using the kubectl get pods command. The results shows the pod names which contains hashes.
Run the following command to log into the community pod. Include the pod name.
kubectl exec -it pod\\_name --container=community -\u2013 bash \nConfirm that the community pod is receiving the trust store. Look for the ldaptruststore.p12 file in /local/notesdata directory.
Confirm that LDAP secret has been created in the correct namespace if using namespaces.
Open the values.yaml file and confirm that the LDAP secret name is specified correctly in the ldapConfigSecret: \"ldap-config-secret\" format.
Confirm that the sametime.ini and UserInfoConfig.xml files are updated.
Open the /local/notesdata/sametime.ini file in the community pod. and confirm the LDAP TLS settings are present.
Locate the following statements in the file:
STLDAP_TLS_TRUST_STORE_TYPE=p12 \nSTLDAP_TLS_TRUST_STORE_FILE = /local/notesdata/ldaptruststore.p12 \nThe file name and path are hard coded and should not changed.
STLDAP_TLS_TRUST_STORE_PASSWORD= thepassword\nThis should be your actual password for the trust store. If these are missing, confirm the values.yaml settings are present as mentioned in the confirm you have the correct configuration details step.
Open the /local/notesdata/UserInfoConfig.xml and confirm that you see the correct details in the <Storage Details> section for the host name and port of the LDAP server.
Confirm that the below line is present, where \u201cthepassword\u201d is your trust store password:
<SslProperties KeyStorePath=\"/local/notesdata/ldaptruststore.p12\" KeyStorePassword=\"password\" />\nIf anything in this section is missing, examine the settings in the values.yaml file for accuracy as decribed in the next step.
Confirm you have correct configuration details .
Confirm your other values in the values.yaml pertaining to LDAP:
ldapHost:
ldapHost: server\\_host\\_name\nldapPort: \"636\"\nldapTls: true\nWhere server_host_name should be the LDAP server host name or IP address.
Check the bind credentials in the sametime-global-secrets, they are base64 encoded. First, issue the command: kubectl edit secret sametime-global-secrets
Locate the lines beginning with LdapBindEntryDn and LdapBindEntryPassword. Take the value of each setting and base64 decode them, they should be your Bind DN and the Bind password. If these are wrong, then base64 encode them. To decode the values, issue the following command:
echo -n \u2018value\u2019 | base64 -d \nWhere \u2018value\u2019 is the encoded value in the secret.
If you need to change the credentials, you can set it to the base64 encoded value of the correct Bind name and password, directly in the secret, but it should also be set in the template file as well. If you fail to update the template file, then your existing secrets are overridden when you run a helm upgrade command. The template file is located where the helm directory was saved, and it is found under /helm/templates/sametime-secrets.yaml
To change the Bind credentials, see Changing the LDAP service account password in Kubernetes. For more information on secrets, see the Managing secrets in Kubernetesand Modifying secrets topics.
If you are overriding the default configuration using an extra-community-config secret, there are additional steps to take to correct the Bind DN. See Changing the LDAP service account password in Kubernetes.
Confirm TLS is negotiating properly between Sametime and LDAP
Sametime connects to LDAP attempting to negotiate TLS with the following ciphers:
RSA_WITH_AES_256_GCM_SHA384 (0x009D) RSA_WITH_AES_128_CBC_SHA (0x002F)
Support for at least one of the ciphers might need to be added to your LDAP server, such is the case for HCL Domino 12.0.2, for details see Sametime 12.0 TLS required ciphers to connect to Domino 12.0.2 LDAP
There is a known issue when using a newer version of keytool to create the trust store, Sametime is unable to read it. To work around the problem, recreate the trust store with keytool and add the argument: -J-Dkeystore.pkcs12.legacy to the command. For more details, see the Sametime unable to read trust store causing LDAP connection to fail article.
An example of this is the Google Kubernetes Engine IP masquerade agent solution. For more information, see the IP masquerade agent Google Cloud topic. Each cloud provider has an unique solution, see your vendor\u2019s documentation for more details.
The community pod must resolve the host name of the LDAP server, or you can configure the IP address instead. If the host name of the LDAP server does not resolve in DNS, you can configure Host Aliases for the Community pod.
See the Configuring host aliases for Kubernetes deployments article for steps.
Netstat is installed on the community pod and can be helpful to understanding if the connectivity is succeeding or not succeeding.
To use netstat on the community pod enter the command:
netstat -an | grep 636 \nSubstitute your secure LDAP port number if you are not using port 636.
You might find that the default settings for LDAP are incompatible with your LDAP implementation and are causing problems
Parent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/t_troubleshooting_sametime_docker.html","title":"Troubleshooting Sametime on Docker","text":"Enabling Community trace in Docker
Viewing and saving log files Use the docker-compose logs command to view errors and events. You can view all containers or a specific container by specifying the container name.
Parent Topic: Troubleshooting
"},{"location":"admin/t_troubleshooting_sametime_kubernetes.html","title":"Troubleshooting Sametime on Kubernetes","text":"Enabling Community debug in Kubernetes
Viewing and saving log files Logs track pod events. You can gather a log for a specific pod and container within a pod or for all pods.
Transferring files from a pod to a Linux shell
Capturing a network trace in a pod
Applying changes
Troubleshooting LDAP on the community pod
Parent Topic: Troubleshooting
"},{"location":"admin/t_uninstall.html","title":"Uninstalling Sametime","text":"In the event that Sametime must be removed, follow the procedure for the platform that Sametime is installed on.
To uninstall Sametime on Docker, follow these steps.
Run the command to remove the images from the image repository.
For Docker,
docker rmi\nFor the full list of Docker commands, refer to Docker rmi in the Docker documentation for additional information.
For Podman,
$ podman rmi --all\nAttention: This command removes all images in the local storage, including the images that are not Sametime specific. For the full list of Podman commands, refer to Podman-rmi.
Find the installation directory and remove the extracted files from that folder. For more information, refer to Installing Sametime on Docker or Podman in the Podman documentation for additional information.
If you plan to re-install Sametime, refer to Installing Sametime in a Docker or Podman environment. To migrate or upgrade to a higher version, refer to Migrating and Upgrading.
Parent Topic: Uninstalling Sametime
"},{"location":"admin/t_uninstall_k8.html","title":"Uninstalling Sametime on Kubernetes","text":"To uninstall Sametime on Kubernetes, follow these steps.
Run the following commands.
# helm uninstall deployment name\n# kubectl delete job deployment name\n# kubectl delete clusterrolebinding deployment name\n# kubectl delete clusterrole deployment name\n# kubectl delete serviceaccount deployment name\nThe container images must be removed from the container registry manually. Each Kubernetes environment has different instructions. Consult your Kubernetes documentation for the complete steps.
Find the installation directory and remove the extracted files from that folder.
If you plan to re-install Sametime, refer to Installing Sametime in a Kubernetes environment. To migrate or upgrade to a higher version, refer to Migrating and Upgrading.
Parent Topic: Uninstalling Sametime
"},{"location":"admin/t_upgrade_telephony.html","title":"Upgrade considerations for telephony","text":"The prepareDeployment.sh script does not update the values.yaml file for telephony-related settings and does not update the settings from the existing secrets. For more information, refer to Preparing the deployment.
Configure the values.yaml file.
Compare the old values.yaml file and the new version of values.yaml file and port the settings over manually.
Locate these settings and change the value from false to true.
enableJigasi: true \nenableJigasiRestartOnTrunkFailure: true \ndialInEnabled: true \ndialInDisplayEnabled: true \nenableInviteOthers: false (set to true if dial-out is enabled) \nLocate these settings and configure to match the current environment. By default, these settings are blank.
defaultCountryCode: \"\" \nnumbers_json: {}\nIf necessary, add these settings to match the current environment.
jigasiSipServer: tmghost.example.com \njigasiSipPort: 5060 \njigasiSipTransport: TCP \njigasiProxyBypass: true \nConfigure the secrets for telephony. The secrets used by telephony are not carried over from the previous version of Sametime to the new version. This must be done manually.
Secret name: auth-config-secret
Template file name: helm/templates/auth-config-secrets.yaml
Copy the application-registry.json setting from the previous file to the new file.
Secret name: sametime-global-secrets (Sametime 12) or meeting-secrets (Sametime 11.6) Template file name: helm/templates/sametime-global-secrets.yaml
Copy the JigasiSipUri and JigasiSipPassword values from the previous file to the new file.
Secret name: catalog-config-secret Template file name: helm/templates/catalog-config-secrets.yaml
**Note:** If the TMG server is configured for a self-signed certificate for HTTPS, you might have the optional extra-certs configured. In this case, copy the extra-certs value from the old helm/templates/catalog-config-secrets.yaml file and paste into the new Sametime 12 helm/catalog-config-secrets.yaml file.\nApply the changes to the environment. See Applying configuration changes in Kubernetes or Openshift for the steps.
Parent Topic: Upgrading on Kubernetes
"},{"location":"admin/t_verify_tlsconnection.html","title":"Verifying if TLS connection can be established","text":"To verify if the TLS connection can be established, do the following.
Edit the custom.env file and locate the MONGO_URL parameters in the file.
Sametime configures the MongoDB details in a Mongo URL, for example:
mongodb://sametime\\_user:mongodb\\_password.mongodb\\_host:port\nwhere:
tlsAllowInvalidCertificates=true\nNote: Only use the option on systems where intrusion is not possible. This step bypasses the certificate check on the client side and is a viable option if both MongoDB and the Sametime components are all on the same host. Doing this step assumes that there would be no traffic on the network and there is no possibility of the mongo hostname being hijacked in DNS. For more information, refer to the official MongoDB documentation.
Save the changes.
Parent Topic: Setting up TLS for the Mongo database
"},{"location":"admin/tls_change_certificate.html","title":"Replacing the TLS certificates for Web Chat and Meetings","text":"The Sametime server is pre-configured with a self-signed certificate. You can replace the self-signed certificate with a third party certificate.
Updating the TLS certificates on Docker
Updating the TLS certificates on Kubernetes In Kubernetes, TLS certificates are contained within a secret called tls-secret.
Parent Topic: Securing
"},{"location":"admin/tls_change_certificate_docker.html","title":"Updating the TLS certificates on Docker","text":"Ensure that you have the certificate and private key to be used.
Run the following command to stop the Sametime services.
docker compose down\nCopy the two files to the /keys folder where the Sametime is deployed.
Replace the cert.key and cert.crt files with the new certificate files.
The files are located in the sametime-config/web/keys/ folder which is in the your installation directory.
Note: These changes are lost if you delete or remove the sametime-config directory.
Start the Sametime server to apply the changes.
docker compose up -d\nParent topic: Replacing the TLS certificates for Web Chat and Meetings
"},{"location":"admin/tls_change_certificate_kubernetes.html","title":"Updating the TLS certificates on Kubernetes","text":"In Kubernetes, TLS certificates are contained within a secret called tls-secret.
Ensure that you have the certificate and private key to be used.
To update the certificate on Kubernetes, first you must delete the existing secret and create it again with the new certificate information.
Run the following command to verify if the secret currently exists.
kubectl get secrets\nIf the tls-secret exists, delete it.
kubectl delete secret tls-secret\nCreate a new tls-secret secret with the new certificate and private key.
create secret tls tls-secret --key tls.key --cert tls.crt\nWhere the value for key is the private key file and cert is the certificate file.
Verify
kubectl get secret tls-secret -o yaml\nParent Topic: Replacing the TLS certificates for Web Chat and Meetings
"},{"location":"admin/topology.html","title":"Planning the network topology and connectivity","text":"This topic explains how Sametime components are connected and the default ports that are used. There are also example topologies to illustrate how Sametime can be deployed in different scenarios.
The following are components within the Sametime topology.
Clients are the interfaces used to connect with the Sametime server and product features. Each physical component communicates with the Sametime server using a specific port. See Sametime clients for more information on clients.
"},{"location":"admin/topology.html#section_i5j_rmt_v5b","title":"Directory services","text":"When choosing which LDAP directory to use, consider all the integrations with Sametime. It is important to understand how users authenticate with the server. Sametime can be integrated into many other HCL products, such as HCL iNotes, Verse, Connections, and Digital Experience. It is important to understand how users authenticate with the server and use a common LDAP directory.
Review the LDAP Planning section for additional information when choosing a directory.
"},{"location":"admin/topology.html#section_plw_cnt_v5b","title":"Single sign-on (SSO)","text":"Sametime requires Single Sign On and issues a JWT token to the users upon log in. All users are authenticated against the Community service, where tokens are generated to be shared with the other microservices.
As an optional configuration, Sametime supports LTPA Single Sign On as well as Security Assertion Markup Language (SAML). With LTPA SSO, the user is issued an LTPA token, which can be shared with other services that support LTPA authentication, such as HCL Domino, Verse, and Connections.
With SAML, the initial authentication is done by an Identity Provider which validates the user\u2019s identity with the Community service. The user is then provided a JWT token that is good for the duration of their session. For more information, see Enabling Single Sign-on.
Planning considerations for chat
Considerations for Sametime Premium Sametime Premium deployments are supported on Docker or Kubernetes.
Parent Topic: Planning
"},{"location":"admin/topology_chat.html","title":"Planning considerations for chat","text":"See Ports used by Sametime services for more details on which ports are required to be open on firewalls.
"},{"location":"admin/topology_chat.html#section_olj_3nt_v5b","title":"Small internal chat-only deployments","text":"For small internal deployments, a single Docker system can be deployed to support web chat, mobile chat, and chat users with desktop clients (such as the Sametime Connect and Embedded Sametime client in HCL Notes).
An example of a small deployment includes a single Docker deployment of Sametime, MongoDB Server, and the LDAP directory.
Figure 1 shows an example of a small internal deployment that only includes chat.
In the above example, \u201cdesktop clients\u201d are the Sametime Connect client and Sametime Embedded client (inside HCL Notes) for desktops. Browser clients can include other HCL applications such as HCL Verse, HCL iNotes, and HCL Connections, which have chat and presence integration with Sametime.
You can use the mobile client app on your internal Wi-Fi network if devices are able to connect to Sametime on port 443. Mobile apps can be used internally; however, be aware that the mobile clients still need access to the Apple (APNS) and Google (FCM) servers for push notifications (notifying the user of new messages). As an additional option, Sametime supports proxying the notifications if you have a third-party proxy to do so.
"},{"location":"admin/topology_chat.html#section_dzj_jqt_v5b","title":"Small chat-only environments with internet access","text":"Figure 2 shows a small chat-only environment that includes internet access to Sametime.
In this example, you can open port 443 on the firewall to support mobile clients on the internet. You can open TCP port 1533 to support desktop clients. Instead of placing Sametime in the internal zone, you can also place Sametime in a DMZ or on the external zone.
Parent Topic: Planning the network topology and connectivity
"},{"location":"admin/topology_premium.html","title":"Considerations for Sametime Premium","text":"Sametime Premium deployments are supported on Docker or Kubernetes.
If you are unfamiliar with these technologies, refer to Platforms. To learn more about Kubernetes, see An Overview of Kubernetes.
Media audio and video streams over UDP port 10,000 for Docker or UDP 30,000 for Kubernetes. Sametime requires a STUN server if any user is attending from behind a firewall. The default configuration comes with the public Google STUN server configured using UDP Port 19302 configured; however, any STUN server can be used. Both clients and the Sametime services need connectivity to the STUN service. For more information, see Session Traversal Utilities for NAT (STUN). The following examples show several scenarios on how to deploy Sametime to include external users.
"},{"location":"admin/topology_premium.html#section_lb3_tsv_v5b","title":"Small Sametime Premium deployment on Docker","text":"If your environment includes a DMZ, you can place Sametime in the DMZ and open the required ports.
In this example, clients can connect to Sametime from both inside the internal network as well as from the Internet. Browser clients and Mobile clients connect to Sametime using HTTPS port 443, and UDP port 10,000. These clients also connect directly to STUN on the Internet (or internally if installed as an optional configuration) on port 19302 UDP. Mobile clients must connect to the push notification services on the Internet in order to receive chat notifications in the client. Sametime desktop clients (those that are installed rich clients\u2014Sametime Connect and Sametime embedded) are connecting on port 1533 TCP.
The following graphic shows a small HCL Sametime Premium with internet access using Docker.
"},{"location":"admin/topology_premium.html#section_ftl_zsv_v5b","title":"Larger Sametime Premium deployments","text":"If you have a medium- or large-size user base, you can deploy Sametime with Kubernetes. Kubernetes can be installed as an on-premise configuration or by leveraging a third party Kubernetes service such as Google Kubernetes Engine (GKE) or Amazon\u2019s Elastic Kubernetes Service (EKS), among others.
When you deploy Sametime in Kubernetes, the Kubernetes cluster requires three node pools. Each node pool performs a different function. One node pool is dedicated to video, a second one for recorders, and a main node pool for all other Sametime pods. The number of nodes in each node pool determines the capacity of the environment. An ingress controller is used to handle front-end connections from users to the web chat and meeting https services. Media streams are over UDP port 30,000 and connect directly to the video node pool. Sametime desktop clients connect to a Sametime Mux Kubernetes service (svc) on port 1533 (TCP).
The following graphic shows Kubernetes node pools and ingress.
Connectivity for end users is very similar to the Docker deployment. The difference is UDP port 30,000 is used for media streams instead of port 10,000. There may be multiple nodes in the video node pool, and clients must be able to reach each one on port 30,000.
The following graphic shows an overview of connectivity in a Kubernetes deployment.
For a fully containerized environment, it is possible to also run MongoDB as a Kubernetes cluster, which may require additional licensing from MongoDB. LDAP can also run as a container, and Sametime supports LDAP v3 compliant directories. Domino LDAP can also run in Kubernetes.
The following graphic shows a fully containerized Sametime Premium Deployment.
Parent Topic: Planning the network topology and connectivity
"},{"location":"admin/topology_telephony.html","title":"Considerations for telephony","text":"Integration with the Teamcall Meeting Gateway (TMG) application from ilink enables telephony services to be added to your Sametime environment. The telephony feature allows telephone access to chats and meetings.
TMG provides two types of end-user experiences:
Dial in : Phone numbers are assigned to the Sametime Meeting service, and each telephony-enabled meeting has a unique pass code. This allows users to use their phones to dial into a meeting.
Dial out : Dial out allows users to dial a phone number from the meeting and invite another user to join that meeting.
The ilink TMG can leverage your existing on-premise SIP trunk, or a SIP provider or carrier service from a third party. With this configuration, the SIP and RTP protocols are used between:
For more details on the ilink product, see the ilink website.
The following graphic shows a network environment with ilink integration.
Parent Topic: Planning the network topology and connectivity
"},{"location":"admin/topology_turn.html","title":"Determining where to install Sametime","text":"You can extend access to Sametime outside of your internal network to attendees on the Internet. Sametime can be installed in the demilitarized network zone (DMZ); however, the required ports for connectivity need to be opened on the firewalls surrounding the DMZ. You can also use a third-party Kubernetes cloud provider such as Amazon EKS, Google GKE, or another third-party Kubernetes provider to deploy Sametime. For more information, see the Deploying Sametime 12 on Google Kubernetes Engine guide.
For example, Sametime can be installed in a demilitarized network zone (DMZ) or internal zone, which requires ports open to the network.
If there are users or attendees who might have a restrictive network environment, consider implementing a TURN service.
TURN (Traversal Using Relays over NAT) is a protocol that relays network traffic. It is an optional service that you can deploy with Sametime to improve the end user experience when attendees and users of Sametime Meetings do not have connectivity to UDP port 30,000. If the user has access to ports 10,000\u201320,000 UDP, then TURN can relay the traffic over this range instead. The user connects to the TURN server instead of Sametime directly. If the user is in a very restrictive environment and has no UDP ports available to use, then the TURN server can be used to relay traffic over TCP port 443. It is important to note that although port 443 is used for this purpose, it is not considered HTTP traffic; it is audio and video data.
Sametime does not ship with a TURN server, but a third-party server can be used, such as CoTURN. CoTURN is the TURN server that has been tested with Sametime.
For more details on TURN, see Setting up a TURN server.
Parent Topic: Network planning for meetings
"},{"location":"admin/troubleshooting.html","title":"Troubleshooting","text":"This section provides information on troubleshooting and supporting Sametime environments. Use this section to assist you with problems that you might experience and contacting support if needed.
"},{"location":"admin/troubleshooting.html#hcl-customer-support","title":"HCL Customer Support","text":""},{"location":"admin/troubleshooting.html#sametime-community-forum","title":"Sametime community forum","text":"Getting help There are several resources available to troubleshoot and resolve a problem that you can use before contacting support. If you need to contact support, a support guide describes expectations.
Working with HCL support HCL support is available to provide technical assistance with obtaining a solution to problems with Sametime.
Troubleshooting Sametime on Docker
Troubleshooting Sametime on Kubernetes
Troubleshooting Sametime clients Use this information on troubleshooting and logging tools to diagnose and resolve problems affecting the HCL Sametime clients.
HCL support is available to provide technical assistance with obtaining a solution to problems with Sametime.
To request technical assistance, open a support case with HCL to work with a support engineer in resolving the problem. See How to open HCL Support case knowledge article for details.
When working with the support engineer the following information is helpful in understanding the problem. Having the following information before talking with the support engineer saves time and reduces multiple calls.
You might be asked to share files with HCL support, see the HTTPS and SFTP upload and download instructions knowledge article for details.
Parent Topic: Troubleshooting
"},{"location":"admin/troubleshooting_debug_trace_docker.html","title":"Enabling Community trace in Docker","text":"The Community and STProxy traces can be used to troubleshoot problems with the Sametime. The traces capture the flow between the chat and meeting services.
To enable the trace modify the docker-compose.yml file. In the community: section, locate the env_file: statement.
community: \n image: hclcr.io/st/chat-server:${BUILD_LEVEL} \n restart: ${RESTART_POLICY} \n env_file: \n -custom.env \n -debug.env\n environment:\nAdd, the debug.env parameter to the statement as shown in the following example.
community: \n image: hclcr.io/st/chat-server:${BUILD_LEVEL} \n restart: ${RESTART_POLICY} \n env_file: - custom.env - debug.env\n environment:\nParent Topic: Troubleshooting Sametime on Docker
"},{"location":"admin/troubleshooting_docker_logs.html","title":"Viewing and saving log files","text":"Use the docker compose logs command to view errors and events. You can view all containers or a specific container by specifying the container name.
To view logs for all components, issue the following command:
docker compose logs\nTo view individual components, add the component name to the command. For example to view community logs:
docker compose logs community\nTo save logs to a file, use the > character followed by the path and file name for the saved file.
docker compose logs > /tmp/all_logs.txt\nParent topic: Troubleshooting Sametime on Docker
"},{"location":"admin/troubleshooting_kubernetes_logs.html","title":"Viewing and saving log files","text":"Logs track pod events. You can gather a log for a specific pod and container within a pod or for all pods.
Each Kubernetes pod and container performs a specific task, narrowing down which pod to gather a log allows you to focus on the problem being debugged. Review the Pods in Sametime topic to understand what each pod does.
Some pods have multiple containers and you can specify gathering the log for the specific container. For pods that only have one container, you do not need to specify the container name.
Run the kubectl get pods command to obtain the name of the pod. The command output includes all current pod names.
Note: Pod name have hashes in it that change each time a pod is started.
The following example shows the output from a kubectl get pods command.
NAME READY STATUS RESTARTS AGE\nactivity-5b75df6f6b-z98xs 1/1 Running 0 25d\napp-registry-7766fddd94-qbvsk 1/1 Running 0 25d\nauth-c6d8457cb-9j9z7 1/1 Running 0 24d\nbackgrounds-cb8966646-wtvqs 1/1 Running 0 25d\ncatalog-ff66944d5-vvfkx 1/1 Running 0 10d\nclick2call-86f8f4cbbb-wptch 1/1 Running 0 25d\ncommunity-775fc897c9-mmb84 2/2 Running 0 25d\nfiles-5b5865f8fc-h8hl5 2/2 Running 2 (9d ago) 25d\njibri-web-65b6849f67-9xxq9 1/1 Running 0 25d\njitsi-6c4754ffcf-n6t72 3/3 Running 0 25d\nlobby-b569fcdd5-5fkmf 1/1 Running 0 25d\nlocation-5894bcb6f7-kbkrb 1/1 Running 0 25d\nmux-f68c5868d-8vl6j 1/1 Running 0 25d\noutlook-7d7f54ff65-7cmzx 1/1 Running 2 (25d ago) 25d\nproxy-6d669b9b94-xmhvt 1/1 Running 0 25d\nrecorder-7c9dcfc646-2g66f 2/2 Running 9 (22m ago) 32h\nrecordings-7cdd5c8cf4-lg2hn 1/1 Running 0 25d\nvideo-7c477fbd86-2jn62 2/2 Running 0 25d\nweb-6d785f6479-tfmkb 1/1 Running 5 (14d ago) 25d\nwebhook-7cb587cd74-5t96w 1/1 Running 0 10d\nTo view the log for a specific pod, run the kubectl logs command specifying the name of the pod to gather log information. If there is a specific container to gather the log, include both the pod name and container name on the command.
kubectl logs pod\\_name container\\_name \nFor example, if you want to view the jvb logs from the video pod based on the output in the previous step enter the command:
kubectl logs video-7c477fbd86-2jn62 jvb \nYou can also use the --all-containers argument to see logs from all the containers on the pod.
kubectl logs video-58f8589f99-f4tcd --all-containers \nTo redirect the output to a file, add the greater than character (>) as an argument on the command and specifying a location that you have access to put the file. For example:
kubectl logs video-7c477fbd86-2jn62 --all-containers > /tmp/video.txt \nParent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/troubleshooting_kubernetes_pod_networktrace.html","title":"Capturing a network trace in a pod","text":"Get the name of the pod.
kubectl get pods \nStart a shell session in the pod. Issue the below command, and make the following substitutions:
kubectl exec -it <podname> --container=<container name> -- bash \npodname : The name of the pod.
container_name : is the name of the container. If the pod only has one container you can omit this parameter.
For example, if the pod name is jitsi-74d95d6d49-k5nts and the container name is jigasi, then the resulting command is:
kubectl exec -it jitsi-74d95d6d49-k5nts --container=jigasi --bash\nUpdate the repositories by issuing the below command:
apt-get update \nInstall tcpdump by issuing the below command:
apt-get install tcpdump \nCapture the network data, by issuing the command:
tcpdump -i any -w <filename>.pcap \nReproduce the problem.
To stop and save the capture press Ctrl+C.
Parent Topic: Troubleshooting Sametime on Kubernetes
Transferring files from a pod to a Linux shell
Pods in Sametime
"},{"location":"admin/troubleshooting_kubernetes_transfer_pods.html","title":"Transferring files from a pod to a Linux shell","text":"Obtain the name of the pod.
Pod names have hashes in it that change each time a pod is started. To get the name of the current pods, issue the command:
kubectl get pods \nTo copy a file from the pod, use the syntax below, and make the following substitutions:
kubectl cp <podname>:/<filename> /<path_on_local>/<filename> --container=<container_name> \npodname : The name of the pod.
filename : The file name inside the pod.
path_on_local : The path on the machine running kubectl.
container_name : The name of the container. If the pod only has one container you can omit this parameter. See Pods in Sametime for container names.
For example if:
kubectl cp jitsi-7b86fc4f64-vtrrb:/test1.pcap /tmp/test1.pcap --container=jigasi\nParent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/turnserver_centos.html","title":"Installing a TURN Server","text":"You can install and configure a TURN server to use with Sametime Meetings.
The following procedures uses Coturn and CentOS 7 to implement a TURN server.
Install the CentOS prerequisites.
sudo yum install -y make gcc cc gcc-c++ wget openssl-devel libevent libevent-devel\nDownload the Coturn source package that can be compiled from the Downloads repository. Ensure it is the latest version.
The following example is downloading v4.5.2.
mkdir /root/turn\ncd /root/turn\nwget https://coturn.net/turnserver/v4.5.2/turnserver-4.5.2.tar.gz\nCompile and install.
./configure --prefix=/usr/local/turnserver # Specify the installation directory\nmake\nsudo make install\nSet the environment variables.
vim ~/.bashrc\nAdd the following statements.
export turnserver_home=/usr/local/turnserver\nexport PATH=$PATH:$turnserver_home/bin\nConfigure the TURN server.
Create the turnserver.conf file.
vim /etc/turnserver.conf\nAdd the following content to define the Coturn server. Replace the option values with the appropriate values for your environment.
# Listener IP address of relay server. Multiple listeners can be specified.\n# If no IP(s) specified in the config file or in the command line options,\n# then all IPv4 and IPv6 system IPs will be used for listening.\nlistening-ip=0.0.0.0\n\n# External IP-Address of the TURN server\nexternal-ip=IP_ADDRESS\n\n# TURN listener port for UDP and TCP (Default: 3478).\nlistening-port=3478\n\n# 443 for TURN over TLS, which can bypass firewalls\ntls-listening-port=443\n\n# host domain name.\nrealm=mycompany.org\n\n# Path to the SSL certificate and private key.\n# Certificate file.\ncert=/usr/local/etc/turn_server_cert.pem\n\n# Private key file.\npkey=/usr/local/etc/turn_server_pkey.pem\n\n# Lower and upper bounds of the UDP relay endpoints:\n# Further ports that are open for communication\nmin-port=10000\nmax-port=20000\n\n# This allows TURN credentials to be accounted for a specific user id.\n# If you don't have a suitable id, the timestamp alone can be used.\n# This option is just turning on secret-based authentication.\n# The actual value of the secret is defined by option static-auth-secret,\nuse-auth-secret\n\nstatic-auth-secret=<YOUR_SECRET>\n\n# Option to set the log file name.\n# By default, the turnserver tries to open a log file in\n# /var/log, /var/tmp, /tmp and current directories directories\nlog-file=/var/log/turnserver.log\n\n# Enable verbose logging\nverbose\n\n# Do not allow an TLS/DTLS version of protocol\nno-tlsv1\nno-tlsv1_1\nno-tlsv1_2\nYou can make additional customizations to the file. For additional information, see the turnserver.conf file. Within the file, configuration options are described as comments.
Start the service.
turnserver -v -r extranet-ip:port -a -o -c /etc/turnserver.conf\nParent Topic: Setting up a TURN server
"},{"location":"admin/turnserver_intro.html","title":"Setting up a TURN server","text":"A TURN server can be configured to provide for efficient traffic flow within your Sametime meeting.
You need to install a TURN server and configure it for use with the Sametime Meeting server. There are several options for a TURN server. One option is the Coturn, which is an open source TURN server. The following two methods can be used to install the Coturn TURN server:
After the TURN is installed, follow the configuration method appropriate for your environment:
Configuring the TURN server for Kubernetes
Installing a TURN Server on Ubuntu You can install and configure a TURN server to use with Sametime Meeting on an Ubuntu operating system.
Parent Topic: Meetings
"},{"location":"admin/turnserver_meetings_docker.html","title":"Configuring the TURN server for Docker and Podman","text":"You can configure the Sametime Meeting service to enable a TURN server on port 443 for Docker.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Update the following configuration in the custom.env file.
# Enable TURN for JVB (bridge mode) connections\nTURN_ENABLE=1\n\n# Secret for connect to TURN server\n# Add the same secret that you used to configure TURN server.\nTURN_SECRET=secret\n\n# Announce FQDN/IP address of the turn server via XMPP server (XEP-0215).\n# If empty or not set, variable DOCKER_HOST_ADDRESS will be used by default.\nTURN_HOST=turn.example.com\n\n# TLS/TCP/UDP turn port for connection\nTURN_PORT=443\n\n# Transport for stun/turn connection. Can be tcp or udp.\nTURN_TRANSPORT=tcp\nAdd the following configuration to the custom.env file.
TURN_CREDENTIALS=secret\nUpdate the following configuration in the .env file.
GLOBAL_MODULES=turncredentials\nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up a TURN server
"},{"location":"admin/turnserver_meetings_kubernetes.html","title":"Configuring the TURN server for Kubernetes","text":"You can configure the Sametime server to enable a TURN server on port 443 for Kubernetes.
Note: Running the script to prepare deployment prompts for TURN server configuration. The following process is to enable TURN post deployment. For more information, refer to Preparing the deployment.
Update the values.yaml file with the following values. Ensure that the syntax for the YAML file is followed.
turnEnable: true\nglobalModules: turncredentials\nturnHost:<turn host name>\nturnPort: 443\nturnTransport: tcp\njvbTcpHarvesterDisabled: true\nUpdate the helm/templates/sametime-secrets.yaml file.
Locate the TurnSecret variable and set the value to the base64 encoded secret as set in the TURN configuration.
TurnSecret: <base64encoded secret as set in TURN configuration>\nNote: If you need to generate a base64 encoded secret, use the following command. Use the unencoded value provided in your TURN configuration.
/bin/echo -n $(openssl rand -hex 32) | base64\nRun the helm update command to enable the configuration changes.
Parent Topic: Setting up a TURN server
"},{"location":"admin/turnserver_ubuntu.html","title":"Installing a TURN Server on Ubuntu","text":"You can install and configure a TURN server to use with Sametime Meeting on an Ubuntu operating system.
You need the following:
The following procedures uses Coturn open source implementation of a TURN server. The procedure includes installing and configuring the Conturn server.
Install Coturn on the Ubuntu operating system.
sudo apt-get -y update\nsudo apt-get -y install coturn\nTo start the Coturn Daemon at Startup, modify the /etc/default/coturn file.
sudo vim /etc/default/coturn\nRemove the comment character (#) from the beginning of the following line.
TURNSERVER_ENABLED=1\nConfige the Coturn server.
Make a copy of your original configuration before making any changes.
This original configuration copy can be used if a problem occurs.
Create an empty file in the same directory to contain your configuration.
sudo vim /etc/turnserver.conf\nAdd the following content to define the Coturn server and replace the values with appropriate values for your configuration.
# Listener IP address of relay server. Multiple listeners can be specified.\n# If no IP(s) specified in the config file or in the command line options,\n# then all IPv4 and IPv6 system IPs will be used for listening.\nlistening-ip=0.0.0.0\n\n# External IP-Address of the TURN server\nexternal-ip=IP_ADDRESS\n\n# TURN listener port for UDP and TCP (Default: 3478).\nlistening-port=3478\n\n# 443 for TURN over TLS, which can bypass firewalls\ntls-listening-port=443\n\n# host domain name.\nrealm=mycompany.org\n\n# Path to the SSL certificate and private key.\n# Certificate file.\ncert=/usr/local/etc/turn_server_cert.pem\n\n# Private key file.\npkey=/usr/local/etc/turn_server_pkey.pem\n\n# Lower and upper bounds of the UDP relay endpoints:\n# Further ports that are open for communication\nmin-port=10000\nmax-port=20000\n\n# This allows TURN credentials to be accounted for a specific user id.\n# If you don't have a suitable id, the timestamp alone can be used.\n# This option is just turning on secret-based authentication.\n# The actual value of the secret is defined by option static-auth-secret,\nuse-auth-secret\n\nstatic-auth-secret=<YOUR_SECRET>\n\n# Option to set the log file name.\n# By default, the turnserver tries to open a log file in\n# /var/log, /var/tmp, /tmp and current directories directories\nlog-file=/var/log/turnserver.log\n\n# Enable verbose logging\nverbose\n\n# Do not allow an TLS/DTLS version of protocol\nno-tlsv1\nno-tlsv1_1\nno-tlsv1_2\nYou can make additional customizations to the file. For additional information, see the turnserver.conf file. Within the file, configuration options are described as comments.
Save the file and restart the Coturn server to apply the changes.
Parent Topic: Setting up a TURN server
"},{"location":"admin/update_ttl_index.html","title":"Updating the time-to-live index for persistent chat","text":"The time-to-live (TTL) setting defines how long the chat history is stored in the database. The default value is 90 days. However, administrators can update the value based on the organization's preferred setting.
The TTL index in MongoDB must be rebuilt. For more information, refer to Manage Indexes in the MongoDB documentation.
To update the TTL settings used by the Sametime server involves modifying the following files.
Note: These values are case sensitive and must be entered as shown below.
Modify the configuration file. The minimum value is 1.
For Docker, update the CLI__ChatLogging__CL_MONGO_HISTORY_TTL parameter. In the following example, the value is set to 7 days.
CLI__ChatLogging__CL_MONGO_HISTORY_TTL=7\nFor Kubernetes, update the CLI__ChatLogging__CL_MONGO_HISTORY_TTL parameter. In the following example, the value is set to 7 days.
CLI__ChatLogging__CL_MONGO_HISTORY_TTL: 7\nModify the Convomap Max Days configuration value to match the MongoDB TTL value. The minimum value is 1.
For Docker, update the STI__stconvomap__CONVOMAP_MAX_DAYS parameter. In the following example, the value is set to 7 days.
STI__stconvomap__CONVOMAP_MAX_DAYS=7\nFor Kubernetes, update the STI__stconvomap__CONVOMAP_MAX_DAYS parameters. In the following example, the value is set to 7 days.
STI__stconvomap__CONVOMAP_MAX_DAYS: 7\nYou can update the STI__stconvomap__CONVOMAP_MAX_HOURS parameter to add hours to the time frame. In the following examples, the value is set to 2 hours.
Docker:
STI__stconvomap__CONVOMAP_MAX_HOURS=2\nKubernetes:
STI__stconvomap__CONVOMAP_MAX_HOURS: 2\nIn the Mongo shell, run the following commands.
use chatlogging\ndb.EVENTS.getIndexes()\ndb.EVENTS.dropIndex(\"TimeStamp_1\")\ndb.USERS.dropIndex(\"date_1\")\nThe db.EVENTS.dropIndex command defines the name of the index to drop. The value is TimeStamp_1.
Restart the Sametime server to apply the changes. The TTL index is updated with the new value.
For more information, refer to Starting and stopping servers.
Run the following command to confirm that the value for TimeStamp_1 is updated.
db.EVENTS.getIndexes()\nParent Topic: Configuring
"},{"location":"admin/upgrade_install_fixpack.html","title":"Upgrading to a new version or applying a fixpack","text":"Newer versions and fix packs contain new features and fixes. You do not need to remove your current Sametime 12 installation when upgrading to a new version.
To install a new version or fix pack, the following conditions must be satisfied:
Sametime server has access to a MongoDB server
Upgrading on Docker
Upgrading on Kubernetes The Sametime upgrade packages contain full helm charts.
Parent Topic: Migrating and Upgrading
"},{"location":"admin/upgrade_install_fixpack_docker.html","title":"Upgrading on Docker","text":"To install a new version or fix pack, the following conditions must be satisfied:
Creating a backup of the installation directory, allows you to return to your previous version if a problem occurs related to installing the fix pack.
Note:
The docker-compose.yml file is replaced during the upgrade with a newer version. Do not restore this file from a previous version after the upgrade. Any needed modifications need to be implemented again in the new file version.
In the directory where Sametime is installed, issue the following command to stop the Sametime server.
docker compose down \nMake a copy of the Sametime installation directory as a backup before installing the fix pack.
Copy the contents of the installation directory into another directory. For example, /sametime_install_backup where sametime_install is the Sametime installation directory.
Download and decompress the Sametime fix pack archive to the Sametime installation directory.
unzip sametime\\_fixpack\\_zip -d /sametime\\_install\\_path \nIn the sametime_install directory, run the following script to initiate the installation process.
./install.sh\nFollow the prompts to provide the required information. The install process detects if the install is an upgrade or full install.
Parent topic: Upgrading to a new version or applying a fixpack
"},{"location":"admin/upgrade_install_fixpack_kubernetes.html","title":"Upgrading on Kubernetes","text":"The Sametime upgrade packages contain full helm charts.
When upgrading, the recorder workloads are assigned to the main worker nodes. Ensure that the existing main worker nodes have enough capacity to handle the workloads.
Because the upgrade package includes full helm charts to implemented, you must port your settings from the current values.yaml into the new values.yaml file. Do not restore the values.yaml file from a backup file which might contain deprecated settings.
Download and extract the Sametime fix pack zip files into a directory on either the master Kubernetes host or on a machine which has management access to the Kubernetes cluster.
Run the following command to load the fix pack Docker image to the Docker repository.
./load.sh\nIf your image repository requires a secret, define in the secret name on the hclImagePullSecret setting in the values.yaml file.
Edit the values.yaml file as needed.
Run the following script to update the current configuration to values.yaml file as needed. You are prompted for any missing information.
./prepareDeployment.sh\nWhen prompted to confirm the upgrade, answer Y to proceed with the current settings. If your response is No, you are prompted for necessary information.
If the community LDAP settings are overridden in your deployment using an extra-community-config secret, there are changes to these files that need to be included as a part of the upgrade.
Delete the secret by running the following command:
kubectl delete secret extra-community-config\nComment out the following line in the values.yaml file using the comment (#) character.
# overrideCommunityConfigSecret: extra-community-config\nWhen the upgrade is finished, pull new copies of StCommunityConfig.xml and UserInfoConfig.xml files. Modify the files to include your custom settings. Create the extra-community-config secret again with your changes.
If you have enabled telephony, copy the secrets from the old helm charts to the new ones.
Copy the existing setting application-registry.json from /helm/templates/auth-config-secrets.yaml into your new /helm/templates/auth-config-secrets.yaml file.
Copy the existing JigasiSipUri and JigasiSipPassword settings from the/helm/templates/sametime-secrets.yaml file to the new /helm/templates/sametime-secrets.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Upgrade considerations for telephony
The prepareDeployment.sh script does not update the values.yaml file for telephony-related settings and does not update the settings from the existing secrets. For more information, refer to Preparing the deployment.
Parent topic: Upgrading to a new version or applying a fixpack
"},{"location":"admin/upgrade_revert_kubernetes.html","title":"Reverting to a previous version on Kubernetes","text":"If you encounter a problem, you can return to the previous Sametime version. Helm commands to return to a previous release on Kubernetes. To roll back to the previous version, run the helm rollback command. For more information about the command, see the Helm Rollback topic in the Helm documentation. If you don't know the previous release number, you can use the helm history command. For additional information on how to identify the prior release number, see the Helm History topic in the Helm documentation.
Parent Topic: Upgrading to a new version or applying a fixpack
"},{"location":"admin/use_stimages_harbor.html","title":"Using Sametime images from the HCL Harbor registry","text":"Sign in to the HCL Harbor registry using the same credentials that you use for the HCL Software License & Download Portal. You are granted access through HCL's identity provider, Okta.
Obtain the access token you need for command line authentication with Harbor by clicking your account profile picture. The CLI secret that is displayed is the access token.
If you already have Docker installed, you can use your Docker login to create the necessary secret to give your Kubernetes environment access to the HCL Harbor Registry.
Run the command:
docker login hclcr.io -u your\\_email\\_address\nUse the access token you obtain in Step 2 when prompted for password. Make sure the case of your_email_address matches what is in the Harbor Registry user profile.
Create a secret that references your Docker config
kubectl create secret generic hcl-harbor-registry-secret \\\n --from-file=.dockerconfigjson=<path/to/.docker/config.json> \\\n --type=kubernetes.io/dockerconfigjson\nNote: If you are not using Docker, run the following command.
kubectl create secret docker-registry hcl-harbor-registry-secret --docker-server=hclcr.io '--docker-username=your\\_email\\_address\\>' '--docker-password=your\\_access\\_token'\nThe quote that surrounds the Docker user name and password parameters are needed. This is because the @ and possible special characters in a password might have special meaning in the command interpreter.
Edit the values.yaml file and include the following setting.
hclImagePullSecret: 'hcl-harbor-registry-secret'\nThis topic describes how to replace the self-signed certificate with a third-party certificate.
The Sametime server is preconfigured with a self-signed certificate.
Note: Let's Encrypt certificates expire every 90 days. To automatically renew the certificates, users can use Certbot. Otherwise, users can renew certificates when they expire. For details on setting up automatic renewal, refer to the Certbot documentation.
Parent Topic: Securing
"},{"location":"admin/using_meeting_servers.html#using_meeting_server_kubernetes","title":"Kubernetes","text":"Obtain one or more certificates and private key. Afterward, run the following commands to configure the Ingress to use them.
Run the following command to verify if the secret currently exists.
kubectl get secrets\nIf the tls-secret exists, delete it.
kubectl delete secret tls-secret\nCreate a new tls-secret secret with the new certificate and private key.
create secret tls tls-secret --key tls.key --cert tls.crt\nWhere the value for key is the private key file and cert is the certificate file.
Verify
kubectl get secret tls-secret -o yaml\nGenerate a Let's Encrypt certificate. Afterward, apply the encryption certificate on the Sametime server.
Set ENABLE_LETSENCRYPT to 1 in the docker-compose.yml file.
Retrieve the PEM files provided by Let's Encrypt and locate the following files
sametime-config/web/acme-certs/\nNote: If a value for the LETSENCRYPT_DOMAIN is specified, then the path is sametime-config/web/acme-certs/<LETSENCRYPT_DOMAIN>/.
Restart the server to apply the changes.
docker-compose down\ndocker-compose up -d\nIntegration with an application such as Verse prior to Sametime 12.0 requires the legacy web-client interface. Beginning in Sametime 12.0 the legacy web-client is not enabled by default, but can enabled when needed for integration with other products.
Enabling web client integration on Docker and Podman
Enabling web client integration on Kubernetes
Enabling content security headers on Docker and Podman
Enabling content security headers on Kubernetes
Parent Topic: Configuring
"},{"location":"admin/verse_integration_contentsecurity_docker.html","title":"Enabling content security headers on Docker and Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Edit the custom.env file.
Add the following parameter to the file, where company_domain is the domain name.
CONTENT_SECURITY_POLICY=frame-ancestors https://*.company\\_domain.com\nTo apply the changes, stop the Sametime server and start it again.
To stop the Sametime server, run the following script from the Sametime installation directory.
docker-compose down \nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Integrating with other applications
"},{"location":"admin/verse_integration_contentsecurity_kubernetes.html","title":"Enabling content security headers on Kubernetes","text":"The changes in this task affect the following pods:
web
Edit the values.yaml file.
Add the following parameter to the file, where company_domain is the domain name.
contentSecurityPolicy: frame-ancestors\u00a0https://*.company\\_domain\nApply the changes to the configuration.
Run the helm upgrade command from the helm directory where the Sametime installation package was unzipped.
Specify the Sametime deployment name.
helm upgrade sametime\\_deployment\\_name .\nNote: The dot is part of the command.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Integrating with other applications
"},{"location":"admin/verse_integration_docker.html","title":"Enabling web client integration on Docker and Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Edit the docker-compose.yml file.
Locate the SAMETIME_EXTERNAL_WARINTEGRATION variable and ensure that it is set to true.
If the statement doesn't exist, add it in the proxy section of the file.
SAMETIME_EXTERNAL_WARINTEGRATION=true\nTo apply the changes, stop the Sametime server and start it again.
To stop the Sametime server, run the following script from the Sametime installation directory.
docker-compose down \nTo apply the changes stop the Sametime server and start it again.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Integrating with other applications
"},{"location":"admin/verse_integration_kubernetes.html","title":"Enabling web client integration on Kubernetes","text":"The changes in this task affect the following pods:
proxy
Edit the values.yaml file.
Add the enableLegacyChatClient key with the value set to true.
enableLegacyChatClient: true\nApply the changes to the configuration.
Run the helm upgrade command from the helm directory where the Sametime installation package was unzipped.
Specify the Sametime deployment name.
helm upgrade sametime\\_deployment\\_name .\nNote: The dot is part of the command.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Integrating with other applications
"},{"location":"admin/whats_new.html","title":"What's new","text":"HCL Sametime and HCL Sametime Premium 12.0.2 provide many new features, enhancements and fixes to servers and clients. Additional releases to version 12.0.2 also provides updates to the product.
For information on these new features and enhancement, see the following article:
For a listing of fixes provided in 12.0.2, refer to the following article:
You can configure the Sametime server so that business card information about an individual displays when a user hovers over a name in a chat window or a contact list. Business card information also displays at the top of an active chat window.
Business cards are configured to access user information from the LDAP directory. To access the user information from the LDAP directory, Sametime provides a search engine called a black box.
By default, you can choose the following fields to display in the business card.
To troubleshoot problems with business cards, see Resolving problems with business cards.
Business card photos must meet the following requirements:
A single LDAP server must be used as the primary repository to retrieve user information. A secondary repository is optional and must be configured as a secondary LDAP server for business cards.
"},{"location":"admin/admin_st_buscard.html#tasktroubleshooting_ay3_nrv_4tb","title":"Planning for photos","text":"If photos are used in a business card , they can be stored in the LDAP directory or in the format of a URL hosted from a web server. For mobile and web clients using the Sametime Proxy server, they must be stored in the format of a URL. Importing photos into a directory using an image/jpeg type is only supported on the Connect and Embedded clients.
Importing photos into a directory increases the size of the directory. The increase in size can affect the performance of other applications that use the directory.
Depending on the Sametime client type, the attribute to defined the photo location is different.
PhotoURL supports the Web and Mobile clients.ImagePath supports the Connect and Notes Embedded clients.PhotoURL and ImagePath can be mapped to the same LDAP field. To support all Sametime client types using a URL:
PhotoURL and ImagePath.For example:
<Detail Type=\"text/plain\" FieldName=\"PhotoURL\" Id=\"ImagePath\"/>\n <Detail Type=\"text/plain\" FieldName=\"PhotoURL\" Id=\"PhotoURL\"/>\n\n<Set params=\"MailAddress,Name,Title,Location,Telephone,PhotoURL,ImagePath,Company\" SetId=\"0\"/>\n<Set params=\"MailAddress,Name,Title,Location,Telephone,PhotoURL,ImagePath,Company\" SetId=\"1\"/>\nAfter you have identified where the user information is stored, proceed to the applicable topic to configure business cards.
UserInfoConfig.xml file in the community pod.Parent Topic: Configuring
"},{"location":"admin/admin_st_mng_remotecomm.html","title":"Updating connectivity settings with the managed-community-configs.xml file","text":"You can distribute updates to HCL\u00ae Sametime\u00ae client communities automatically using a managed-community-configs.xml file. The managed-community-configs.xml file is policy-based, so you can control communities for different user groups.
You can also use the managed-community-configs.xml file to manage secondary communities, while preventing users from adding or deleting communities. Set the Allow Multiple Communities policy to false and use the managed-community-configs.xml to define the desired secondary communities. The client allows the user to log into secondary communities defined in the .xml file, but the user cannot delete secondary communities defined in the file.
At login time, the client receives policies and checks for the existence of a managed-community-configs.xml file according to the Sametime update site URL policy. For example, if the administration update site URL is http://example.com/updates, the client looks for the file in http://example.com/updates/managed-community-configs.xml.
Follow these steps to create and post a managed-community-configs.xml file.
Create a settings XML file and save it as managed-community-configs.xml.
Add settings for communities and actions in the file.
Place the file on a web server, and post the URL (starting with http://) for the file to the Sametime update site URL in the Chat section of the Instant Messaging policy.
If you changed the settings file to update the host name of a community to a new server that is part of the same community, users' contact lists are still valid with the new host. Set the ST_COMMUNITY_ID in the sametime.ini file of both servers to the same value and ensure that all the communities in your cluster are using the same community ID. This prevents duplicate communities from being created on the client when logging into the new host for the first time.
You can now test the\u00a0managed-community-configs.xml\u00a0file:
(Optional) Enable logging of the managed community settings to help debug problems. To enable logging for the handling of the remote\u00a0managed-community-configs.xml\u00a0file, set the following log level in your client's\u00a0user.home/HCL/Sametime/.config/rcpinstall.properties\u00a0file:\u00a0
com.ibm.collaboration.realtime.community.internal.config.level=FINEST\ncom.ibm.collaboration.realtime.policy.sametime.level=FINEST\nwhere user.home/HCL/Sametime represents the client's workspace location.
Managed community settings Define managed community settings in the managed-community-configs.xml file.
Parent Topic: Sametime client configuration options
"},{"location":"admin/administering.html","title":"Administering","text":"This section provides information on administering on Sametime environments.
Starting and stopping MongoDB
Configuration files Configuration files maintain information used by the Sametime server for various reasons.
This section provides information relating to administering MongoDB.
Changing MongoDB credentials in Sametime for Docker and Podman
Changing MongoDB credentials in Sametime for Kubernetes and Openshift A connection URL is used to configure the Sametime and MongoDB connection. The connection URL tells Sametime how to connect to your MongoDB.
Parent Topic: Administering
"},{"location":"admin/adminui_grafana_config_docker.html","title":"Configuring Grafana on Docker and Podman","text":"When using the managed charts to install Sametime, the Grafana dashboard is created. If using a manual install or update process, Grafana can be configured as a post-installation task.
After Grafana is configured, port 3001 is the default port used for Grafana.
Edit the .env file and add the following statement.
COMPOSE_PROFILES=monitoring\nNote: If you are have enabled the Outlook addin, the COMPOSE_PROFILES statement looks like the following:
COMPOSE_PROFILES=monitoring, outlookAddin\nEdit the custom.env file and add ensure that the following settings are set to true.
ENABLE_GRAFANA_PROXY=true\nMONITORING_ENABLED=true\nEdit the monitoring.env file and add the Grafana administrator ID and password.
GF_SECURITY_ADMIN_USER\nGF_SECURITY_ADMIN_PASSWORD\nStart the Sametime server to apply the changes.
docker compose up -d
Grafana can be configured as a post-installation task or during an upgrade.
To use Granfana, the Prometheus application must be installed.
To verify that the service was created correctly, run the following command to display a list of all services:
kubectl get svc -n monitoring\nEnsure that Grafana is listed as a service. Below is an example.
By default, Grafana is not available through an ingress controller.
Before you can create your first dashboard, you need to add your data source. Note that you must have Grafana administrator access to add data sources. Complete the following steps to run Grafana and import your dashboard.
Enable port forwarding for the Grafana service.
kubectl port-forward service/grafana 3000:3000 -n monitoring\nWhen using a remote setup, navigate to the Grafana sign-in page in your browser.
<Cluster-IP>:3000\nThe default port for Grafana is 3000. If you are on a local machine use localhost:3000.
Enter admin for both the user name and prom-operator, and then select Sign In.
You are prompted to change the password.
Select OK and enter the new password.
From the left panel, hover over + Create and select Import.
Upload the K8_Sametime_Dashboard.json file.
The K8_Sametime_Dashboard.json file is included in the Sametime Premium install product image. After decompressing the product image, the file is in the root directory.
Select Prometheus (default) as the data source and then select Import.
Save the dashboard.
Parent topic: Monitoring your meeting and chat metrics with Grafana
"},{"location":"admin/adminui_grafana_overview.html","title":"Monitoring your meeting and chat metrics with Grafana","text":"Sametime uses the third-party software, Grafana, to generate insightful graphs and visualizations derived from time-series database (TSDB) data. Integrating Grafana into your Sametime environment allows you to see analytic metrics about Sametime meetings and chats on a Grafana dashboard. The metrics can be used to monitor Sametime usage and resources.
Using Grafana involves that you have a running Grafana installation and then setting up the dashboard to view Sametime metrics. The Sametime Premium product image contains two JSON files that define Sametime metrics to display on the Grafana dashboard. One file is for a Docker environment and the other for Kubernetes. After you decompress the product image, the JSON files are located in the root folder. The files are:
The Sametime Grafana dashboard consists of four rows, you can expand and contract each row.
Overview : Provides total number currently active chat sessions and logins, group chat sessions, active meetings, and meeting participants.
Chat Server : Provides details related to chats usage such as the number of chat server logins, CPU usage, sent and received network traffic and more.
Chat Proxy : Provides details about web and mobile client sessions, such as number of sessions, app usage, threads, and CPU usage, and more.
Meetings : Provides malformation about meetings, such as number of active and inactive meetings, largest meetings, memory usage and more.
If you have Grafana administrator access, you can customize the dashboard to generate additional or different metrics. Refer to the Grafana documentation on Dashboards for the details.
Configuring Grafana on Docker and Podman
Configuring Kubernetes to run Grafana
Parent Topic: Administering
"},{"location":"admin/adminui_overview.html","title":"Sametime Admin overview","text":"The Sametime Admin is a web access interface used to work with policies and analytic data related to Sametime Meetings and chat features.
Only those users with access privileges can access the Sametime Admin after logging into Sametime. The access URL is: sametime\\_server\\_url/admin/.
The Admin UI contains a left pane, with icons that allow for accessing features. Click the icons to go from one feature to another.
Granfana dashboard displays provided that your environment includes a Grafana integration. A Grafana integration allows you to view various analytic metrics about your Sametime deployment. The Grafana dashboard provides charts, graphs, and alerts about Sametime Meetings and Chat features. You can use a predefined Sametime dashboard or create one. For more information, see Dashboards in the Grafana documentation.
If your environment does not include a Grafana integration this page is empty. For additional information on using Grafana, see adminui_grafana_overview.md.
Manage Sametime polices used to control user access to Sametime features. You can create, assign, and view policy assignments, and more.
See [adminui\\_policy\\_manage.md](adminui_policy_manage.md) for additional information.\nThe administrator is defined during the installation process. You can change or modify the administrator by updating the following files.
custom.env file for Docker or Podmanvalues.yaml file for Kubernete or OpenshiftYou can add a policy by creating a new policy, or by copying and modifying an existing policy.
The new policy is added to the table and assigned a weight higher than the current highest weight value. It is also in unassigned state.
Parent Topic: Managing policies
"},{"location":"admin/adminui_policy_add_copy.html","title":"Copying a policy","text":"You can create new policies by copying and editing a current policy.
The new policy is not in effect until the server is refreshed. After creating the new policy you can restart the sever or wait for the next refresh which happens every hour based on when the server was started.
Click the Copy icon() next to the policy to copy.
Type a name for the new policy and click Save Copy.
The new policy is added to the table and assigned a weight higher than the current highest weight value.
Edit the new policy by clicking the Edit icon.
When finished with changes, click Save Policy.
Parent Topic: Adding a policy
"},{"location":"admin/adminui_policy_assign.html","title":"Assigning users and groups to policies","text":"Policies are not used until assigned to users or groups.
Click the Assign icon () for the policy being assigned, type or search for the user or group name to assign the policy.
Select the name from the search results. The name is added to the Assign to list below the search field.
You can continue to search for names to assign the policy to. To remove a name, click the Delete icon next to the name.
When finished, clicked Save.
Note: For the policy to take immediate effect, restart the server. Otherwise, policy refresh happens every hour based on when the sever was started.
Parent Topic: Managing policies
"},{"location":"admin/adminui_policy_create_new.html","title":"Creating a policy","text":"You can create a custom policy that takes precedents over the Default and Anonymous policies. There can be many custom policies based on the requirements for your environment.
Newly created policies are assigned a weight higher than the current hightest weight value. The new policy is not in effect until the server is refreshed. After creating the new policy you can restart the sever or wait for the next refresh which happens every hour based on when the server was started.
Click the Add a policy for the policy to copy.
Enter a name for the policy in the Policy Name field.
Policy names must be unique.
Select the features to associate with the policy. When finished, click Add.
The new policy is added to the table.
Parent Topic: Adding a policy
"},{"location":"admin/adminui_policy_delete.html","title":"Deleting a policy","text":"You can delete policies no longer needed.
Click the Delete icon () next to the policy to delete.
Confirm the deletion by clicking Delete.
Sametime policies allow administrators to control user access to features.
Two predefined policies are automatically assigned to users. You can also create custom polices that fit your company's requirements and user access to Sametime feature. Which policy that is automatically assigned depends on whether the user is authenticated or not. You can also create custom polices that fit your company's requirements.
Policies are only applied from the primary Sametime community defined in the client. Additional server communities' policies are not pushed down to the users' desktops. A user's primary Sametime community is the first community listed in their Sametime client Server Communities Properties settings.
To manage Sametime policies, you need access to the Sametime Admin. After accessing Sametime Admin, click the Manage Policy icon on the left side of the window.
From the Manage Policies window, you can create, assign, and view policy assignments, and more using the icons under Actions. To the right of each policy is the policy weight followed by actions. To know more about a policy, click the policy name.
To know more about a policy, click the policy name. The View/Edit Policy window opens where you can view and change features related to the policy.
Parent topic: Administering
"},{"location":"admin/adminui_policy_modify.html","title":"Modifying a policy","text":"Policy attribute can be modified for all policy types.
Changes to a policy are not in effect until the server is refreshed. After creating the new policy you can restart the sever or wait for the next refresh which happens every hour based on when the server was started.
Click the Edit icon for the policy to modify.
The View/Edit Policy opens where you can modify features associated with the policy. When finished, click Save Policy.
You can change all attributes including the policy name.
Parent Topic: Managing policies
"},{"location":"admin/adminui_policy_sections.html","title":"Policy sections","text":"Each policy contains several sections.
Policy attributes are group into the following sections:
Chat
Meeting
File transfer
Mobile
Administration
Parent topic: Managing policies
"},{"location":"admin/adminui_policy_types.html","title":"Policy types","text":"There are three types of policies. The Anonymous and Default policies are predefined and cannot be deleted. There is only one of these policy types. All other policies are considered custom policies. There can be many of this type of policy.
The anonymous user policy and the default user policy are automatically assigned.
Policy type Description Anonymous Users who have not authenticated are assigned the anonymous policy by default. The anonymous policy cannot be deleted but can be edited if you want to allow or restrict access to certain Sametime features for unauthenticated users. The anonymous policy always has the lowest policy weight (0) and this weight cannot be changed. Default Users who have authenticated are assigned the default policy if no other policy can be found for that user. The default policy can be inherited or assigned. The default policy cannot be deleted but can be edited if you want to allow or restrict access to certain Sametime features. The default policy has the next lowest policy weight (1) after the anonymous policy and this weight cannot be changed. custom policies Custom policies can be designed for specific users or groups to allow or restrict access to certain Sametime features. When you create a new policy, the default policy settings are applied as the base settings of the new policy. You can update these settings.Parent topic: Managing policies
"},{"location":"admin/adminui_policy_view_active.html","title":"Finding active policies associated with user or group","text":"You can view policies assigned to a user or group.
Type the name of a user or group in the Find Active Policy search field and click \u200bthe Search icon. You must enter the complete name to search. The search results in a list of assigned policies.
"},{"location":"admin/adminui_policy_weight.html","title":"Policy weight","text":"Policy weights and group nesting levels are used to determine which policies take precedence over the attributes of other policies.
Policies with a higher weight take precedence over those with a lower weight. You can change the weight of policies to control their order of precedence by moving them up and down within the policy list. The policy weights of the anonymous and default policies, which are the lowest (0) and next-lowest (1) weights, cannot be changed.
For a user or group that is assigned two or more policies, the policy with the highest weight is used. For authenticated users, Sametime searches for an exact ID match, and then applies the highest weighted policy.
Policies are only applied from the primary Sametime community. Additional server communities' policies are not pushed down to the users' desktops. A user's primary Sametime community is the first community listed in their Sametime Server Communities Properties settings.
"},{"location":"admin/adminui_policy_weight.html#policies-applied-to-nested-groups","title":"Policies applied to nested groups","text":"You can configure how Sametime considers nested groups when it applies policies and how many levels deep that are searched for the highest weighted group. By default, four levels of nested groups are searched when it determines the highest weighted policy. The maximum search depth limit is 10 levels and the minimum is -1 level (no nesting).
Note: Entering a large number as the maximum nested group depth can have an impact on performance.
"},{"location":"admin/adminui_policy_weight.html#examples","title":"Examples","text":"In the following examples, the Renovations company has assigned employees to the following user groups. Notice that many of the groups have other groups nested within them.
Group name Members Renovations Group George Corporate Communications Group Corporate Communications Group Fernando Marketing & Merchandising Group Marketing & Merchandising Group Betty Marketing Group Marketing Group Samantha Sales Group Sales Group Anne Brand Specialist Group Brand Specialist Group TedThe Renovations company has created policies to control which user groups have access to different features in Sametime. The actual set of features available to each user depends on how these policies are weighted and nested.
"},{"location":"admin/adminui_policy_weight.html#nested-groups-inherit-policies","title":"Nested groups inherit policies","text":"Policy A is assigned to Renovations Group. The nesting level is set to the default 4.
George is assigned to Policy A because he belongs directly to the Renovations Group.
Fernando is assigned to Policy A because his group falls within the group search nesting limit of 4 levels from the Renovations Group.
Betty is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Renovations Group.
Samantha is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Renovations Group.
Anne is assigned to the default policy because her user group is nested more than the defined limit of 4 levels from the Renovations Group.
Ted is assigned to the default policy because his user group is also nested more than the defined limit of 4 levels from the Renovations Group.
"},{"location":"admin/adminui_policy_weight.html#highest-policy-weight-breaks-ties","title":"Highest policy weight breaks ties","text":"Policy A has a weight of 3 and is assigned to Renovations Group. Policy B has a weight of 2 and is also assigned to Renovations group. The nesting level is set to the default of 4.
George is assigned to Policy A because he belongs directly to the Renovations Group and Policy A has a higher weight.
Fernando is assigned to Policy A because his group falls within the group search nesting limit of 4 levels from the Renovations Group.
Betty is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Renovations Group.
Samantha is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Renovations Group.
Anne is assigned to the default policy because her user group is nested more than the defined limit of 4 levels from the Renovations Group.
Ted is assigned to the default policy because his user group is also nested more than the defined limit of 4 levels from the Renovations Group.
"},{"location":"admin/adminui_policy_weight.html#directly-assigned-policies-have-priority-over-inherited-policies-regardless-of-weight","title":"Directly assigned policies have priority over inherited policies, regardless of weight","text":"Policy A has a weight of 2 and is assigned to the Corporate Communications Group. Policy B has a weight of 3 and is assigned to the Renovations Group. The nesting level is set to the default of 4.
George is assigned to Policy A because he belongs directly to the Renovations Group.
Fernando is assigned to Policy A because he belongs directly to the Corporate Communications Group and Policy A has been directly assigned to the Corporate Communications Group.
Betty is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Corporate Communications Group.
Samantha is assigned to Policy A because her group falls within the group search nesting limit of 4 levels from the Corporate Communications Group.
Anne is assigned to Policy A because her groups falls within the group search nesting limit of 4 levels from the Corporate Communications Group.
Ted is assigned to the default policy because his user group is nested more than the defined limit of 4 levels from both the Renovations Group and the Corporate Communications Group.
"},{"location":"admin/adminui_policysection_administration.html","title":"Administration","text":"Policy Description Policy ID Attribute name Sametime update site URL Applied only to Installed clients. im.2012 imserver.policygroup.chat User can install plug-ins im.2013 imserver.policygroup.plugin Sametime optional plug-in site URLs A list of URLs separated by a comma, semicolon or pipe symbol. im.2022 imserver.policygroup.plugin"},{"location":"admin/adminui_policysection_chat.html","title":"Chat","text":"Policy Description Policy ID User can set the community server as the default server User must set this community as the default server community Applied only to Installed clients. im.2019 User can add multiple server communities Allow user to add multiple server communitiesApplied only to Installed clients. User can save chat transcripts Set this field to zero to allow users to save chat transcripts for an unlimited time. im.2002 Save chat transcripts automatically im.2004 Maximum number of days chat transcripts are saved Default 365 days. im.2006 Allow custom emoticons (Installed Client) im.2008 Limit contact list size set to 800 contacts per user im.2014 Allow all Sametime Connect features to be used with embedded clients Enable Sametime PWA Allow the Sametime PWA installation icon added to the desktop. Allow chat reactions Turn on and off the ability to react to a chat message im.chatReactionEnabled Allow delete chats Allow meeting links feature from chat clients User can capture screens and images im.2009 Maximum image size in KB for custom emoticons, screen captures, and in-line images The default value is 500 KB. im.2020Parent topic: Policy sections
"},{"location":"admin/adminui_policysection_filetransfer.html","title":"File transfer","text":"Policy Description Policy ID Users can transfer files im.1 Maximum file transfer size in KB: The default value is 1000 KB. im.2 Use exclude file types transfer list for files sent through the server im.3 File extensions for files to be excluded from transfer. List of filetypes to exclude from transfer. Type the three-letter extension of each file type, separated by a comma. im.4 Allow client-to-client file transfer This policy applies only to Installed clients. im.2005 Enable file transfer in group and meeting chatParent topic: Policy sections
"},{"location":"admin/adminui_policysection_meeting.html","title":"Meeting","text":"Policy Description Policy ID Allow Sametime Meetings Use this policy to allow and disallow meeting attendance. Note: Turing off this attribute doesn't prevent the login prompt. To remove guests from a meeting, see Preventing guest access for additional information."},{"location":"admin/adminui_policysection_mobile.html","title":"Mobile","text":"Policy Description Policy ID Allow mobile client im.2010 Disable untrusted SSL User cannot log into a server that doesn't have a certificate trusted by the device. Turn this setting off to enable the use of self-signed certificates. This rule also applies to pre-production environments that use self-signed certificates. The default value is on. im.mobile.disableUntrustedSsl Disable password save User cannot save password on their mobile device. Default value is on. To save your password for the next login, retain the default setting of this policy and enable Remember Password from the community settings. Turn this setting on to require users to enter their password at every login. When turned on, the client removes the password regardless if Remember Password is enabled. im.mobile.disablePasswordSave This policy also applies to meeting passwords. For safety reasons, Apple restricts users from texting while driving. The ability to save meeting passwords allows CarPlay users to safely enter meeting rooms while driving. When turned off, the Save Password switch is displayed on the password entry dialog when joining password-protected meetings. When turned on, the Save Password switch is disabled. In the event that a password has been saved prior to changing the default settings, then the password is stored in a secure storage. Allow mobile user to send files By default, you can upload files in a one-to-one chat. This policy only applies to the Choose from Files menu item in the chat window. Leave this setting on with Policy id = 1 to allow users to upload files in a one-to-one chat. Uploading files in a group chat will also require Policy id =im.allowTransferringFilesToNwayParticipants to be turned on. Sending photos from either the camera or the photos app is controlled with Policy id = im.mobile.allowSendImages which is discussed below. im.mobile.allowSendFiles User can share files with other apps Allow mobile user to send images This policy must be turned on to allow images from the device camera or photos app to be sent as inline images in a chat. It does not prevent image files such as PNG or JPG images from being sent through the Choose from Files menu. Default is on. m.mobile.allowSendImages Allow mobile user to share chat images with other apps By default, you can share images from the chat. Turn this setting off to restrict users from sharing images from the chat. m.mobile.allowShareChatImages Restrict copy/paste from chat Prevent users from copying clipboard data in to other apps. Enable URL preview User can export their Sametime contact information to a device contact application on their device Applied only to Android devices. Parent topic: Policy sections
"},{"location":"admin/alternate_client_configuration.html","title":"Configuring Sametime preferences using HCL Notes policies","text":"To configure preferences for the HCL Sametime Embedded Client for Notes, you can also use the Domino\u00ae Desktop policy settings document. These policies are applied when a Notes user logs into their home mail server and retrieves their desktop policy. These settings will not apply to any other client.
The Domino desktop policy settings document Custom Settings tab contains a Managed Settings option, through which you can define preferences.
If you do not use Domino Administrative policies in your organization, you can configure the same settings by leveraging the managed-settings.xml file and defining it in the Sametime policy.
If the preference is set in both the Domino Desktop policy settings document and the managed settings, the preference in the Desktop policy settings document takes precedence. Best practices indicate that it's preferable to set the preference in the Desktop policy settings document or the managed settings, but not in both places.
For step-by-step instructions see the article:
How to use a Notes desktop policy to push Sametime embedded client settings.
Parent Topic: Sametime client configuration options
"},{"location":"admin/apply_configchanges_docker.html","title":"Applying configuration changes in Docker or Podman","text":"Configuration files contain environment variables that can be changed and applied to the Sametime server.
You can make configuration changes by modifying the following files.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Note: Values in the Docker commands are case-sensitive and must be entered in lowercase.
Shut down the Sametime server.
docker compose down\nModify the configuration file.
Save changes to the configuration files.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Configuring
"},{"location":"admin/apply_configchanges_kubernetes.html","title":"Applying configuration changes in Kubernetes or Openshift","text":"Configuration files contain environment variables that can be changed and applied to the Sametime server.
You can make configuration changes to the Sametime deployment server by modifying the helm/values.yaml file.
Note: These settings are case sensitive and must be entered as shown.
Edit the helm charts and make modifications.
Go to the helm directory.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Configuring
"},{"location":"admin/c_dbutility.html","title":"Using the Sametime Database utility","text":"The Sametime Database utility is used to synchronize the information with that of the Sametime server database.
When you change user or group names in the directory, the change is not reflected in Sametime databases. In order to synchronize the directory names with the names in the Sametime databases, you must run the name conversion utility. You can run the name conversion utility manually on a stand-alone Community Server, or on a server in a cluster which replicates the change throughout the cluster.
Note: You do not need to run the Sametime Database utility when adding new users or groups to the Domino or LDAP directory.
The tool performs the following functions:
\u200b
Note: Refer to the Converting chat history owner data from Domino directory to LDAP format topic for the convert function.
The utility is loaded to your Docker repository during the Sametime install process, it is located in the image repository. The name of the utility image is sametime-db-utility. The Sametime Database utility uses a comma-separated value (CVS) file that you compile to update, convert, or delete names which includes the descriptor that corresponds to the task to be completed. To use the utility, create a CVS that corresponds to the task to be completed. The CVS file must contain only one type of task, that is you cannot run an update and convert using the same CVS file. Note that CSV files are case-sensitive and sensitive to spaces.
Descriptor Purpose DELETE Removes specified individual contact names from contact lists and privacy lists. ID Changes specified first names, last names, display names, or group names. TASK_LDAP Changes all contact list information from Domino Directory format to LDAP format. ORGANIZATION Change the organization name for all users.At the end of the Sametime Database utility run, a report file is generated containing a summary of changes applied to the database. You can view the report to verify your changes. The report contains a summary of changes applied to the database, including records touched, modified or deleted. It also has the count of records modified or deleted and which attribute is modified. The report file is created in the data folder. The report file name is in following format:
name_change_summary_report_[date_time].log\nParent Topic: Administering
"},{"location":"admin/c_migration_planning.html","title":"Planning for migration to Sametime 12","text":"Sametime 12 requires a new product install and migration of data from your previous version. Do not uninstall the previous version until the V12 installation is finalized and working as expected.
Because Sametime 12 is a fully containerized application, an in-place upgrades from a previous version cannot be done. Previous Sametime versions included a community and proxy server. The services provided by these servers are inclusive within the Sametime 12 container.
Before you begin the migration having a back-out plan is necessary in case the migration does not succeed. Understand the steps to reverse the changes to place the users back on the older environment if the upgrade is not successful.
"},{"location":"admin/c_migration_planning.html#section_ahy_55v_15b","title":"Contact lists","text":"In Sametime 9.x, 10.x and 11.x, vpuserinfo.nsf is used to store contact lists. Starting in Sametime 12, contact lists are maintained in MongoDB. There is a migration tool to move the contact list to MongoDB. If the deployment being migrated is not configured for LDAP, you must first convert the vpuserinfo.nsf data to LDAP using the Stnamechange utility on your current deployment environment. The utility is not available on Sametime 12 which is why you must run the utility on Sametime 9, 10, or 11 before migrating. The notes-migration tool is used to move the LDAP contact list data to MongoDB.
Before you begin the migration, purge stale users from vpuserinfo.nsf. This can be done manually with a Lotuscript agent or by using the NameChange utility. Domino database maintenance should be performed after purging stale users.
For details, see Migrating contact lists.
"},{"location":"admin/c_migration_planning.html#section_x3c_c4y_ryb","title":"Persistent chat","text":"If you were using persistent chat, you must convert it to LDAP format. For details, see Converting chat history owner data from Domino directory to LDAP format.
"},{"location":"admin/c_migration_planning.html#section_xvg_1xv_15b","title":"Customized settings","text":"Customized settings used to tune Sametime for your environment are maintained in the sametime.ini file. You'll need to make the same changes in the new environment, otherwise the settings are lost. The ST_COMMUNITY_ID parameter must match the old server to ensures that clients show awareness properly after migrating.
Policies are configured in policies.user.xml. You must start your new server configuration with the policies.user.xml file that comes with the Sametime 12 install and manually configure, when needed. There are settings in the new server version that were not in the older versions of Sametime and in the deployment. If you are using managed-settings.xml or managed-community-conf.xml, be sure to include these files in the new Sametime 12 policies.
"},{"location":"admin/c_migration_planning.html#section_yl4_f1b_b5b","title":"Moving the users","text":"After you complete testing of the new environment and ready to migrate the users, you can use one of the following strategies to migrate users.
For details, see Moving the users.
Converting from native Domino directory to LDAP
Migrating contact lists
Moving the users
Parent Topic: Migrating and Upgrading
"},{"location":"admin/c_planning_docker.html","title":"Running and managing containers with Docker and Podman","text":"Docker and Podman are third-party products. HCL support is available to assist in configuration and support-related issues as they pertain to the Sametime product. If you require assistance with a full platform deployment, contact HCL Services or one of our HCL Business Partners to inquire about professional services.
Note: Download the platform package directly from your vendor.
Docker and Podman are open-source tools used for developing, managing, and running containers on your Linux\u00ae systems. What differentiates Podman from Docker is Podman's daemon-less architecture. To learn more about these technologies, refer to Podman vs. Docker topic in the RedHat documentation.
"},{"location":"admin/c_planning_docker.html#section_vmd_vh3_ywb","title":"Deployment and support","text":"The number of concurrent users that Sametime can support depends on the size of the deployment.
System requirements : The minimum requirements must be available to install the product successfully. For details on system requirements, see the System requirements article.
Meeting size : By default, there is a limit of 100 participants for every meeting. To reach a wider audience, you can start a live stream and share the link with all intended participants. The limit is configurable. For more information, refer to Configuring the maximum number of meeting participants.
"},{"location":"admin/c_planning_docker.html#section_qgr_233_ywb","title":"Migration","text":"When moving to a new server, redeploy Sametime as a new configuration. If the server host name in the URL changes, you can push the new URL to the Connect and Embedded clients using Managed Settings or Domino Desktop policy (Embedded only). For more information, refer to Updating connectivity settings with the managed-community-configs.xml file.
Existing URLs work if the host name remains the same.
"},{"location":"admin/c_planning_docker.html#section_rvv_hw1_ftb","title":"Disaster recovery","text":"The backup and restore process is handled outside of Sametime. Consult with your Docker or Podman vendor for details.
Parent Topic: Platforms
"},{"location":"admin/c_planning_kubernetes.html","title":"Planning for Sametime in a Kubernetes environment","text":"Kubernetes provides container orchestration for managing containers. When using this platform, you must consider how to manage operations, scalability, and security.
Kubernetes is a third-party product. HCL support is available to assist in configuration and support-related issues as they pertain to the Sametime product. If you require assistance with a full Kubernetes deployment, reach out to HCL Services or one of our HCL Business Partners to inquire about professional services.
Note: Packages for Kubernetes can be downloaded directly from your vendor.
"},{"location":"admin/c_planning_kubernetes.html#section_sdv_x43_ywb","title":"Manage operations","text":"Kubernetes automates the deployment and management of containerized applications. The number of concurrent users that Sametime can support depends on the size of the deployment. For sizing and deployment-related questions, contact HCL. If you are unfamiliar with this technology, see An Overview of Kubernetes.
High-availability clusters : High availability is supported for the front-end web traffic to the Kubernetes cluster. You can deploy multiple web front ends on different physical or virtual nodes pointing to the same back end in order to both distribute load and survive a node outage.
High availability is not supported for active meetings. If a server hosting a meeting goes down, then ongoing meetings on that server are interrupted. There is a reconnection timer built into the client that causes all the clients to reconnect and be distributed to an available node. In some circumstances, a server going down results in the client thinking the meeting has ended. Users can quickly re-join the meeting from their Recent meetings list and meet again on an available server momentarily.\nCloud deployment : You can run a Kubernetes cluster on your own hardware or a different cloud provider. You can also use a third-party Kubernetes cloud provider, such as Amazon EKS, Google GKE, or other third-party Kubernetes provider to deploy Sametime. Each cloud provider makes security recommendations for running workloads securely in their environment. Refer to the cloud provider's security documentation for further details.
- [Deploying Sametime 12 on Google Kubernetes Engine](https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0099614) for Google GKE deployment.\n- [Deploying Sametime Meetings in Amazon's AWS Elastic Kubernetes Services](https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0085515) for Kubernetes Cloud deployment. The examples in this knowledge article are based on the version 11.5 guide and are not the exact steps for version 12. For version 12, the cluster.yaml file is found in the location of the Sametime 12 installation directory under /kubernetes/stack/eks/cluster.yaml. For additional information, see [Deploying Sametime 12 on Google Kubernetes Engine \\(GKE\\)](https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0099614).\nKubernetes automatically scales a cluster up and down in line with demand without increasing your operations team. To achieve optimal performance, you can provision the infrastructure for Kubernetes before you can install, configure, and connect a component to create a cluster.
Meeting size : By default, there is a limit of 100 participants for every meeting. To reach a wider audience, you can start a live stream and share the link with all intended participants. The limit is configurable. For more information, refer to Configuring the maximum number of meeting participants.
"},{"location":"admin/c_planning_kubernetes.html#section_hrd_ww2_jwb","title":"Security","text":"With Kubernetes, you must integrate security throughout the layers of the solution stack before deploying and running the container. Because cloud-native security is multilayer, it is an effective way to address threats across every level of workflow.
For additional information, see Overview of Cloud Native Security in the Kubernetes documentation.
"},{"location":"admin/c_planning_kubernetes.html#section_rvv_hw1_ftb","title":"Disaster recovery","text":"The backup and restore process is handled outside of Sametime. Consult with your Kubernetes vendor for details.
"},{"location":"admin/c_planning_kubernetes.html#section_n2b_1p3_ywb","title":"Beyond container orchestration","text":"Aside from container orchestration, you can also use Kubernetes to abstract the infrastructure away from higher-level services and applications, making these applications more portable and flexible. Furthermore, Kubernetes allows you to build a much-needed and future-ready architecture.
Planning for a Kubernetes cluster configuration
Planning for Openshift OpenShift is a cloud-based Kubernetes platform. Planning considerations and procedures used to deploy Sametime in an Openshift environment are the same as the Kubernetes platform with the additional considerations addressed in this topic.
Parent Topic: Platforms
"},{"location":"admin/c_planning_kubernetes_cluster.html","title":"Planning for a Kubernetes cluster configuration","text":"When installing Sametime in a Kubernetes cluster, there are several considerations, some are a prerequisite to installing Sametime. Sametime can also be installed into the same Kubernetes cluster as other products, for example, MongoDB as long as the system requirements are met.
Note: The Sametime documentation does not provide full step-by-step instructions on creating a Kubernetes cluster because each Kubernetes provider has different steps. Consult your Kubernetes provider documentation for details on creating a cluster.
Two types of server nodes with different requirements are required:
The nodes are labeled with Kubernetes labels which allows the Kubernetes pod scheduler to assign the Kubernetes pods to the proper node type.
The video node runs the video pods only. This allows the video pod full access to the machine. A video node is reached from clients by NodePort, directly to its Public IP address. There is no load balancer or service requirement for inbound media traffic, as the media traffic is addressed to the specific video bridge where the meeting is active. The machine type must be suitable for media, with a minimum of 4 CPU and 16GB of RAM. When creating the node, pool autoscaling must be enabled. The Sametime autoscaler uses CPU utilization to determine when to bring up more nodes. For guidance on how many nodes to include in the video node pool, contact HCL
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_mrc_fc5_swb","title":"Availability zones for resiliency","text":"If you are installing Sametime into a cloud hosted Kubernetes environment, such as Google Kubernetes Engine, or Amazon Elastic Kubernetes Service, consider creating nodes in more than one availability zone. This provides some additional resiliency if the cloud provider has an outage in a particular data center, having nodes in a different zone allow a fail over event to take place.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_dw3_1b5_swb","title":"Namespaces","text":"Many existing production environments use namespaces. A namespace can be used for Sametime, but it is not required. When you enable autoscaling, you are creating a namespace for monitoring and custom-metrics. If a namespace is created for Sametime, be sure to add the namespace argument to the helm and kubectl commands. For example, if you deploy Sametime in a namespace called sametime and you want to view a list of pod, issue the following command:
kubectl -n sametime get pods\nTo see a list of namespaces that are configured, issue the following command:
kubectl get namespaces\nFor additional information, see Namespace topic in the Kubernetes documentation.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_adc_db5_swb","title":"Network","text":"If you are new to Kubernetes, there are some concepts that are helpful to understand how to configure your firewall. There are small differences between cloud providers and on-prem providers where the names of the features may vary. The following information is generic to introduce the concept. It is important to understand the IP addresses used in a deployment have different ranges, and when configuring a firewall rule, the source IP and destination IP need to be considered.
Node : A node is the virtual machine or hardware running the Kubernetes cluster, it hosts the pods that run the Sametime workloads. A node has an IP address in the node IP range, it will have both an internal IP address and an external IP address. Video nodes are reached by end users from their public IP address directly to the node\u2019s external IP address.
Pod : A pod is a Kubernetes based workload, which has one or more containers inside. These are stateless in Sametime which means they have a defined life cycle and they do not persist. Each pod has its own unique cluster-wide IP address which changes as the pods are scaled. Typical container-to-container communications between pods on the same host are normally permitted without any additional configuration. For example, the community pod communicating to the proxy pod.
: Pods have no awareness of the node host ports or IP addresses. Additionally, you cannot directly reach a pod IP address from outside of the cluster. To expose an application that is running in your pods to be reachable from outside your cluster, Kubernetes services and ingress are used. Ingress is used to expose web services, like Web Chat and Meetings. For on-premise Kubernetes clusters, ingress is also used to expose the Sametime mux to Connect clients and embedded clients which use port 1533.
Service : A Kubernetes service is used by Sametime to expose various components running in pods outside the cluster. It provides a single endpoint to multiple back-ends. Kubernetes services have their own IP address range that is separate from the node IP and pod IP ranges. This provides a consistent IP address as a front-end since the IP addresses for pod change frequently. There are different types of services in Kubernetes, Sametime uses the LoadBalancer type service which directs traffic to back-end pods, each cloud provider has its own implementation of this and some cloud providers have more features than others.
: For cloud hosted Kubernetes clusters, Sametime deploys the mux as a service with the LoadBalancer type for both an internal IP and an external IP. The external IP is used for Sametime Connect and Embedded clients to connect to Sametime. Use the external IP to configure your firewall rules to allow external traffic if you are supporting these clients.
When you install an ingress controller in the cluster, it is also a LoadBalancer type service which has both a cluster IP and an external IP. To expose users to the web services in Sametime for Meetings and Web Chat, open port 443 to this external IP address. Some cloud providers enable this firewall rule automatically when the ingress controller is deployed into the cluster.\n\nOther Sametime components have services with cluster IP type service. To ensure that the websockets feature functions properly, ensure the video node IP can reach the Jitsi service cluster IP on ports 5280 and 5222 TCP/IP. This is because video uses a node IP address instead of one from the pod IP range. For details see the [Websockets fail to load after installing Sametime 11.6 or 12.0.x on Kubernetes](https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0101583) knowledge article.\n\nAll other Sametime components can communicate from inside the cluster to the service Cluster IP without additional firewall configuration.\n: When the connection from the community pod attempts to connect to an LDAP service outside the cluster, a source IP in the pod IP address range is used.
Network Address Translation (NAT) : If you cannot permit your firewall to allow the entire pod IP address range, consider deploying a Network Address Translation (NAT). A source NAT can replace the source IP address on a packet. Note that each Kubernetes cloud provider has its own implementation and features for NAT. For an overview, see the Using Source IP topic in the Kubernetes documentation.
: If you are deploying telephony, the Jitsi pod with Jigasi inside uses a source IP from the pod IP range when connecting to the ilink Teamcall Meeting Gateway (TMG) for SIP. You can enable a source NAT for the entire Kubernetes cluster which will cover both LDAP and Telephony traffic.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_qf1_nb5_swb","title":"Storage","text":"When you create a persistent volume there is a certain type of access mode associated with it. If you have more than one node in the main node pool, be sure to use read-write-many (RWX) access mode, this allows for more than one node to access the volume at a time. If you only have one main node in the node pool, the standard read-write-once access (RWO) is sufficient.
When configuring your persistent volume (PV), consider the types of data that are stored there, and what kinds of features users may utilize that place data in storage. Examples are:
Files : Users can upload files to chats in any of the clients including meetings. They are stored in the PV and are retained for 90 days (configurable).
Backgrounds : Users can upload their own virtual backgrounds to be used when they enable their video. These images are stored in the PV.
Recordings : Recordings are saved as MP4 files, and vary in size depending on duration.
Reports : When meeting reports are enabled, PDFs are saved in the PV containing the report.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_ltb_xb5_swb","title":"Monitoring and logging","text":"The Grafana dashboards shipped with Sametime provides multiple types of statistics. You can also deploy Elasticsearch, Fluentd and Kibana (EFK stack) to aggregate the logs and make them indexable. This is helpful to produce your own statistics, if the Grafana dashboard does not have the statistics you need. It can also aid in troubleshooting because the logs can be written to a PV outside of the pods. If the logs are not configured to be written to a PV using the EFK stack, then the logs are part of the pods and are lost when the pods are scaled. If you deploy the EFK stack, it has its own persistent volume separate from the Sametime pods.
While these tools are helpful, they do not provide proactive monitoring to alert the administrator of problems. Other products can be used for monitoring such as: Panopta or New Relic.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_brq_rd5_swb","title":"Container registry","text":"The Sametime container images can be stored and retrieved from a public or private container registry. Using a registry might require authenticated access or keys. The Sametime server authenticates with the container registry using a Kubernetes secret. The secret must be created prior to installing Sametime. During the install process container images are pushed to the container registry by running the load.sh script. The container images are retrieved by the pods when the pod is initialized. For additional information, see the Using a private registry topic in the Kubernetes documentation.
"},{"location":"admin/c_planning_kubernetes_cluster.html#section_qwd_zb5_swb","title":"MongoDB","text":"MongoDB is deployed separately from Sametime and can be deployed as a standalone virtual machine (VM), a cluster installed on VMs, or a Kubernetes cluster. MongoDB has options for both running your own Kubernetes cluster or a cloud hosted cluster. These options might require an enterprise license. For more information or questions about licensing, contact a MongoDB representative. Contact information can be found on the MongoDB, Inc website.
MongoDB can be also be installed into the same Kubernetes cluster as Sametime. Ensure that you allow for additional capacity if installing into the same node pool as the main node pool, or you can dedicate a node pool to MongoDB.
Parent Topic: Planning for Sametime in a Kubernetes environment
"},{"location":"admin/c_planning_openshift.html","title":"Planning for Openshift","text":"OpenShift is a cloud-based Kubernetes platform. Planning considerations and procedures used to deploy Sametime in an Openshift environment are the same as the Kubernetes platform with the additional considerations addressed in this topic.
While Openshift is similar to other Kubernetes platforms, the following are concepts and considerations that require understanding or a decision.
In the Openshift platform, there are namespace labels used to define a common set of arbitrary User IDs (UID) to be used as runAs UIDs for the pods running in that namespace. Sametime has some containers that require a constant UID of 1000. You must create a Security Context Constraints (SCC) within the namespace where Sametime is to be deployed to apply this MustRunAs policy to allow the service account which runs the deployments to assign this constant UID.
"},{"location":"admin/c_planning_openshift.html#section_lv3_4b3_xwb","title":"Deployment into the default namespace","text":"By default, labels are not created with a random name, which can cause a problem in the default namespace where all containers labels are random. When deploying in the default namespace, comment out the seLinuxOptions:false setting for each activities, files, and recordings in the default namespace.
You can use the Sametime supplied helm charts to deploy Sametime into the default namespace without any additional configuration.
"},{"location":"admin/c_planning_openshift.html#section_ddy_p13_xwb","title":"Deployment of video","text":"There are three ways to deploy video when using the Openshift platform.
Host port
This is the default which provides the best performance and scales automatically scalable. this method requires pod-to-node affinity restriction through node labels.
Load balancer
Using a load balancer is lower performance and has no pod-to-node restrictions. It requires the Kubernetes load balancing infrastructure.
Node port
Using a node port is also lower performance but is restricted to a single node. It requires a no host-network SCC.
For step details, see
Preparing to install an Openshift environment
"},{"location":"admin/c_planning_platforms.html","title":"Platforms","text":"Docker and Kubernetes have different goals and outcomes. The decision about which platform to use depends on your end goal.
Sametime is a containerized application that you can install on the following container platforms that manage containerized applications like Sametime:
Your organization\u2019s needs drive the container environment that you select. For example, your organization might value security, scalability, and other factors. The following concepts identify some aspects of container platforms. Both Docker and Podman are container engines that you use to manage containers. Sametime runs as if in a single, isolated container. When applications run in isolated containers, they run on a single-node container platform. On a single-node platform, each application runs as a separate container. A deployment environment that contains few containers to produce a solution works well in this type of platform environment. However, if you implement a solution that requires multiple containers to be managed as a unit, a single-node platform doesn\u2019t provide the required features.
A platform that performs container orchestration, such as Kubernetes and OpenShift, offers features that enterprise solution environments require. These features, which include deployment automation, scaling, and load balancing, provide great flexibility for enterprise solutions. Multiple nodes that contain various containers are used to implement enterprise solutions. They are referred to as multiple-node container platforms.
Sametime Meetings are sized according to server activity at any given time. A large single-node container platform instance can support up to 200 concurrent peak users. However, that load doesn\u2019t account for the number of meetings that are being recorded, which are processor-intensive. The autoscaling feature in a multiple-node container platform enables adding and removing nodes as needed based upon current usage and monitoring. For sizing and deployment-related questions,\u00a0contact HCL.
Running and managing containers with Docker and Podman
Planning for Sametime in a Kubernetes environment Kubernetes provides container orchestration for managing containers. When using this platform, you must consider how to manage operations, scalability, and security.
Parent Topic: Planning
"},{"location":"admin/c_planning_prereqs.html","title":"Prerequistes","text":"Before you begin the install process, ensure that the environment includes all prerequistes and system requirements.
Parent Topic: Planning
"},{"location":"admin/c_recording_lifecycle.html","title":"Recording lifecycle","text":"To save storage space, you can automatically remove old recordings after the specified time.
By default, recordings are available for download and playback for three (3) days. This is configured using the following parameter:
For Docker, modify the .env file.
EXPIRES_IN_DAYS=n\nWhere n defines the number of days the recordings are available before getting archived. For example, to change the value to seven days, enter EXPIRES_IN_DAYS=7.
For Kubernetes, modify the .yaml file.
recordingsExpireInDays: n\nWhere n defines the number of days the recordings are available before getting archived. For example, to change the value to seven days, enter recordingsExpireInDays: 7. For more information, see Applying configuration changes in Kubernetes or Openshift.
Parent Topic: Managing recording options
"},{"location":"admin/c_troubleshooting_supportstatement.html","title":"Getting help","text":"There are several resources available to troubleshoot and resolve a problem that you can use before contacting support. If you need to contact support, a support guide describes expectations.
The HCLSoftware Customer Support website provides a starting point to access various sites containing information about HCLSoftware products and contacting HCL support.
The Sametime community forum allows Sametime product users and developers to share information and ask questions. The forum is provided as a self-help tool to help you resolve your problem and answer questions without having to call HCL support.
See the HCLSoftware Support Guide for details related to support of HCL products. Included in the document are the following: - Overview of provided service - Priority levels and service objectives - Supported HCLSofware programs - Customer responsiblities - Technical support limitations - End of support policies
Parent Topic: Troubleshooting
"},{"location":"admin/change_mongodb_credentials_docker.html","title":"Changing MongoDB credentials in Sametime for Docker and Podman","text":"Edit the custom.env file and locate the MONGO_URL parameters in the file.
Sametime configures the MongoDB details in a Mongo URL, for example:
mongodb://sametime_user:mongodb_password.mongodb_host:port\nwhere:
Update the MONGO_URL values to the new user and password.
Save the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: MongoDB
"},{"location":"admin/change_mongodb_credentials_kubernetes.html","title":"Changing MongoDB credentials in Sametime for Kubernetes and Openshift","text":"A connection URL is used to configure the Sametime and MongoDB connection. The connection URL tells Sametime how to connect to your MongoDB.
It contains information, such as the user name and password to access the database, MongoDB host name and more.
Locate the MongoDB connection URL.
For information on the connectoin URL, see Connection String URI Format topic in the MongoDB documentation.
The MongoDB details are located in the string in the following format:
mongodb://sametime\\_user:mongodb\\_password@mongodb\\_host:port/?replicaSet=replica\\_set\nAfter you have the MongoDB connection URL, run the following command to convert the connection URL to base64 encode value.
echo -n connection\\_url | base64\nWhere connection_url is the MongoDB connection URL.
Change to the helm/templates directory where the templates are located.
Open the sametime-secrets.yaml file for editing.
Locate the MongoConnectionUrl: setting in the file. Replace the existing setting value with the updated base64 encoded value.
Save and close the sametime-secrets.yaml file.
Update the URL in the live configuration by editing the sametime-global-secrets secret.
kubectl edit secret sametime-global-secrets\nNote: If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure it is created in the correct namespace.
Press i to edit the secret.
Locate the MongoConnectionUrl: setting. Replace the existing value with the updated base64 encoded value.
Press wq! to save the secret.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nFor more information, see Managing secrets in Kubernetes.
Parent Topic: MongoDB
"},{"location":"admin/chat_configuring.html","title":"Chat","text":"This section contains Chat configuration considerations.
Most chat related settings pertain to the community container. The community container:
The community container interacts directly with LDAP and MongoDB.
Parent Topic: Configuring
"},{"location":"admin/chat_configuring_sametimeini.html","title":"Configuring the sametime.ini file","text":"There are many configuration options in Sametime to override the default behaviors. Community related configuration options are in the sametime.ini file.
The sametime.ini file is part of the community container. Most of the parameters within the file pertain to community related services such as interactions with LDAP, SAML, authentication, Connect client, chat, security, and more.
Beginning in Sametime version 12, the defaults for many parameters have changed. If you have questions about previous parameter from a previous Sametime release, contact HCL Support for guidance.
The STI setting prefix followed by two underscores, followed by the section name, then a two underscores, then the parameter and the value. For example, to add a setting called ST_COMMUNITY_ID to the [Config] section, the new parameter format is STI__Config__ST_COMMUNITY_ID.
The HCL documentation and support knowledge articles document various configuration parameters created before Sametime version 12. These documents might refer to the settings using the older parameter names.
"},{"location":"admin/chat_configuring_sametimeini.html#format","title":"Format","text":"The sametime.ini file is a sectioned configuration file. Sections are noted with square brackets, for example: [Config]. The parameters specified in the sametime.ini file are valid only when placed within the correct section. Use only characters allowed within an XML file.
Parameters are specified as a key and value pair. The format is different for Docker and Kubernetes.
Docker : key=value
Kubernetes : key:\"value\"
For example:
Docker
STI__Config__ST_COMMUNITY_ID=sametime \nKubernetes
STI__Config__ST_COMMUNITY_ID: \"sametime\"\nThese settings are documented throughout the help center as well as in the HCL support portal in knowledge articles. The various documentation may have the older (before Sametime 12) notation of the sametime.ini settings with the section name listed separately.
If you need to modify a sametime.ini setting, follow the guidance in the topic for your deployment on Docker or Kubernetes.
Configuring the sametime.ini file on Docker or Podman
Configuring the sametime.ini file on Kubernetes
Parent Topic: Chat
"},{"location":"admin/chat_configuring_sametimeini_docker.html","title":"Configuring the sametime.ini file on Docker or Podman","text":"Open the custom.env file for editing.
Insert the sametime.ini parameters.
Ensure that parameters ares specified in the correct format. See Configuring the sametime.ini file for parameter format.
Save and close the custom.env file.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Configuring the sametime.ini file
"},{"location":"admin/chat_configuring_sametimeini_kubernetes.html","title":"Configuring the sametime.ini file on Kubernetes","text":"Determine the setting format by reviewing the Configuring the sametime.ini file topic. If you are enabling the community server debug, do not use the following procedure, see the Enabling Community debug in Kubernetes topic for details.
Note: When modifying the values.yaml file indentation is important and should be done using spaces only.
Change directories to the helm directory.
Open the values.yaml file for editing.
Locate the sametimeIni: {} setting in the file.
Remove the double brackets ({}).
Remove the comment tag (#) and use the line as a guide for indentation on your settings.
When setting the value, end the parameter with a colon (:) and the value in double-quotes (\"value\").
After adding your changes, confirm that the indication is correct. There should be four spaces before the parameter.
When finished, save and close the values.yaml file.
Complete the steps Applying configuration changes in Kubernetes Applying configuration changes in Kubernetes or Openshift for the changes to take effect.
Parent Topic: Configuring the sametime.ini file
"},{"location":"admin/chat_msg_delete_options.html","title":"Defining chat message deletion limits","text":"The chat deletion settings define how long a user has the ability to delete a message and undo the deletion. The default deletion time is twenty-four hours and one hour to undo the deletion.
To change the default values, modify the following files.
Use the following table to determine the configuration option to add to the file.
Options Docker Kubernetes Maximum amount of time to delete a chat message. Specify the value in seconds. The default value is 1440. MESSAGE_MUTATION_ALLOWED_AGE_IN_MINUTES messageMutationAllowedAgeInMinutes Maximum amount of time to undo a message deletion. Specify the value in seconds. The default value is 60. MUTATION_UNDO_ALLOWED_AGE_IN_MINUTES mutationUndoAllowedAgeInMinutesNote: The configuration options are case sensitive.
After updating the configuration files, restart the Sametime server to apply the changes. For more information, refer to Starting and stopping servers
Parent Topic: Administering
"},{"location":"admin/cluster_highavailability.html","title":"Clustering and high availability","text":"High availability and high capacity configuration for Sametime is achieved in different ways depending on which component is being configured for HA. See the topics below to learn more about chat, meetings, and MongoDB.
Parent Topic: Planning
"},{"location":"admin/community_provisioning.html","title":"Creating a community provisioning URL for mobile users","text":"This section describes how to create a provisioning URL that automatically creates a Sametime community definition on mobile devices running Google Android or Apple iOS, so users can easily connect to Sametime.
A mobile user cannot connect to the Sametime server without a special mobile community definition that provides details needed for the connection. Creating the mobile community is often frustrating for users because they do not have ready access to required information such as the Sametime proxy server's hostname and port. A provisioning URL for the mobile community makes it easy for users to connect to Sametime from their mobile devices after installing the client.
To connect to Sametime, the user simply taps the provisioning link or scans the associated QR code, and then:
You can format the URL as a link or as a QR code, and distribute it in email or post it on a website. The provisioned URL is supported on the following mobile operating systems:
Note: Starting with HCL Sametime version 11, the browser client displays a QR code that can be used to configure the HCL Sametime client for Android or iOS. Once logged into the browser client, open Settings and then Configure Mobile Client. The QR code displayed represents a secure community configuration for the Sametime proxy server and port that the browser is connected to. The QR code also includes the users\u2019 ID and a default community name of Sametime. The user only needs to follow the instructions to scan the code and enter their password before connecting with a mobile device.
If you wish to use a different community name or perhaps the mobile clients need to connect through an authenticating proxy, the administrator can create a custom provisioning URL using the information contained in this article and then configure the Sametime proxy to display the QR code for the custom provisioning URL rather than the default one mentioned above.
Procedure to create the custom provisioning URL
Create and distribute a custom provisioning URL by completing the following steps:
Create the URL by defining its components:
The URL is formatted as shown:
hclsametime://st_user@stproxy_host:port/?action=AddCommunity&communityName=community_name\nwhere:
hclsametime:// is a required prefix to ensure that the URL is recognized and processed correctly.st_user the user name, or login ID, of a particular Sametime user; for example, myid@mycompany.com
If you are sending or posting a URL for use by multiple people, you will probably not want to code a specific user's ID into the URL because other users may find that confusing. Instead, you can supply a variable or a partial user name and instruct users to modify the URL with the completed user name on their own devices, or you can omit the user name entirely so that each user is prompted for credentials when logging in to Sametime. If you want users to be able to simply click a link or QR code to use the URL, you should omit the user name and allow the user to provide credentials at login.
Note:
In addition, you can optionally instruct users to include the associated password in the URL with the following syntax: st_user:st_password; however, this is not a good practice because the password could potentially be consumed by an untrusted app.
stproxy_host is the fully qualified host name of the Sametime Proxy Server; for example: stproxy.example.com.
port is the port that the Sametime Proxy Server is listening on. If omitted, 443 will be used.?action=AddCommunity is a required parameter that ensures the information within the URL is added to the mobile client as a community definition.&communityName=*community\\_name* is an optional URL-encoded string that provides a name for the new community. If you do not specify a name with this parameter, a default name will be created based on the Sametime Proxy Server's host name. The table below provides the complete list of parameters that you can include in the URL and indicates whether each parameter is required.Examples:
Encrypted (SSL) direct connection to server stproxyserver.example.com on default port 443 with no user-specified but the community name is specified as \"Sametime Server\" :
hclsametime://stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\nTo preserve correct URL syntax, the space in \"Sametime Server\" is represented with %20.
Encrypted (SSL) direct connection to server stproxyserver.example.com on port 9080 for user dmisawa:
hclsametime://dmisawa@stproxyserver.example.com:9080/?action=AddCommunity\nIf the user name itself contains the @ symbol you will need to format it as the URL-encoded character %40 to preserve correct syntax, as in
dmisawa%40auto_sales@stproxyserver.example.com:9080\nEncrypted (SSL) authenticating proxy connection to safelinx.example.com on default port 443 reusing authenticating proxy credentials and supplying a variable for the user name, which each user must replace with their own ID:
hclsametime://Your_Sametime_ID@safelinx.example.com/?action=AddCommunity&authProxyReuseCredentials=true\nIn this case both the auth proxy user ID and the sametime user ID would be set to Your_Sametime_ID.
Encrypted (SSL) authenticating proxy connection to safelinx.example.com on port 8881 reusing credentials, with no credentials specified so that each user will be prompted for credentials when logging into Sametime:
hclsametime://safelinx.example.com:8881/?action=AddCommunity&authProxyEnabled=true\nDistribute the URL to mobile users:
Configuring the Sametime server to use the custom provisioning URL
Before updating the stproxyconfig.xml, examine the URL. URL encode any ampersands or spaces. For example, if the URL.
hclsametime://stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\nThe ampersand character is replaced with %26.
hclsametime://stproxyserver.example.com/?action=AddCommunity%26communityName=Sametime%20Server\nAdd a <mobile> section if it does not exist with <configUrl> providing the provisioning URL as shown in the following example.
<mobile>\n<configUrl>CUSTOM_PROVISIONING_URL</configUrl>\n</mobile>\nSave and close the file
Restart the Sametime Proxy server to enable.
Creating a community provisioning URL on Docker or Podman As discussed in Creating a community provisioning URL for mobile users, mobile users cannot connect to the Sametime server without a special mobile community definition that provides details needed for the connection. This topic discusses the specific steps to set up the community provisioning URL on Docker or Podman.
Parent Topic: Sametime client configuration options
"},{"location":"admin/config_buscard.html","title":"Configuring business cards using an LDAP directory","text":"Configuring business cards is done in the UserInfoConfig.xml file in the community pod.
Before you start setting up your business cards, ensure the following:
Configuration settings for business cards are in the UserInfoConfig.xml file in the community container or pod. For most environments, the UserInfoConfig.xml file works with default settings. You can override the default configuration settings by modifying the UserInfoConfig.xml file. The procedure to update the UserInfoConfig.xml file is different on Kubernetes and Docker.
When modifying the XML file be sure to check the formatting using a browser. If there is an error with the formatting of the XML file, a business failure can occur.
When using multiple LDAP servers, each LDAP server requires its own settings. By default, only the first server is configured during setup. To add additional LDAP servers, use the existing settings as a template.
Locate the <StorageType=\u201dLDAP\u201d> section and copy everything between the <StorageType=\u201dLDAP\u201d> and </Storage> statements. Paste the statements at the end of the section below the </Storage> statement. This creates a new LDAP section. See Configuring additional LDAP servers on Kubernetes for information on configuring LDAP.
Configure an authenticated bind.
In some environments, not all the attributes are available to an anonymous bind, and an authenticated bind must be used. During the Sametime installation, anonymous binds to LDAP is configured by default. When a custom UserInfoConfig.xml file is being used, the LDAP bind credentials are being overridden. Bind credentials are located in the .env file for Docker and the sametime-global-secret in Kubernetes.
Use the echo command to find the base64 encoded value for the user name and password.
Specify the user name and password separated by a colon. For example, if the Bind user name is CN=stbind,O=example and the password is securePassword, enter the following command in a Linux shell:
echo -n \u2018CN=stbind,O=example:securePassword\u2019 | base64 \nThe results from the command is the value of a new argument called UserEncodedAuth.
Replace the user name and password parameters with UserEncodedAuth=\"value\".
For example:
<StorageDetails HostName=\"ldap2.example.com\" Port=\"1389\" UserEncodedAuth=\u201d 4oCYQ049c3RiaW5kLE89ZXhhbXBsZTpzZWN1cmVQYXNzd29yZOKAmQ==\u201d SslEnabled=\"true\" SslPort=\"636\" BaseDN=\"\" Scope=\"2\" SearchFilter=\"(&(objectclass=organizationalPerson)(|(cn=%s)(givenname=%s)(sn=%s)(displayName=%s)(mail=%s)))\"/>\nBy default, the LDAP operations are not encoded, and all communications are sent over clear text. To enable encryption, first follow the instructions in Securing connections between Sametime servers and LDAP.
After the keystore has been created, update the SSL properties to include the path to the keystore and its password. For example:
<SslProperties KeyStorePath=\"keys.p12\" KeyStorePassword=\"securePassword\"/> \nVerify the port number on the SslPort property. The default LDAP port number is 636.
SslPort=\"port\\_number\"\nChange the setting for SslEnabled to true.
SslEnabled=\"true\"\nReview the default search filter and make changes to fit your LDAP server\u2019s schema.
The BaseDN field specifies where to start searching in the directory. For example, if all users are located in cn=users,dc=example,dc=com, you could set your BaseDN=\u201dcn=users,dc=example,dc=com\u201c so that the rest of the directory is not searched. A BaseDN is required if using Microsoft Active Directory and is not required for Domino LDAP.
Scope specifies how deep the search is done, enter one of the following.
0 = Base : A lookup operation. Only a single entry described by the base DN is matched.
1 = One level : Searching is performed one level below the base DN and no further. This is like opening a folder in a file system and looking only at the direct elements inside the folder.
2 = Subtree : All child entries of the base DN are searched, whether direct or not, including the base DN itself.
The host name of the LDAP server is set during setup. Review the HostName setting and confirm that it is the fully qualified host name of the LDAP service, which might be a load balancer in front of a cluster of LDAP servers.
If the host name is not correct, update it in the helm/values.yaml file for Kubernetes or the .env file for Docker.
Map the business card fields to LDAP attributes
For each type of data, there is an Id and FieldName.
Id is the internal name used to identify each area of the business card.FieldName value is set to the LDAP attribute that contains the data to display inside the business card. Modify any values that do not match your LDAP schema. These settings are in the <Details> section.Note: ** If images are stored in a URL, see the step 8.
If you would like to map additional detail to these fields it is possible with additional configuration modify the appropriate line in the <Details> section.
For example, if there is both a desk phone number and a mobile phone number that you wish to include in the business card, you can use a separator between the two phone numbers when the information is displayed. Locate the <Detail> line with the telephone attributes. For desk phone number the attribute is telephoneNumber, and for mobile phone it is mobile. In the field name, include both attributes separated by a comma.
FieldName=\u201dtelephoneNumber,mobile\u201d\nAdd DisplaySeparator=\"separator\" to the statement identifying the separator. In the example, the forward slash is used as the separator. You can choose other characters as a separator.
<Detail Type=\"text/plain\" Id=\"Telephone\" FieldName=\"telephoneNumber,mobile\" DisplaySeparator=\u201d / \u201c/>\nIf photos are stored in a URL on a web server, the LDAP server must have an attribute that contains the URL. The attribute can be an existing attribute that has been repurposed or a new attribute can be created.
Note: If you are using HCL Connections Profiles for the photos, see the topic Configuring Business Cards on HCL Connections.
When using Connection Profile URLs, the photo name must be the email extension of .jpg.\u00a0For example, if a user\u2019s email address is jane@example.com, the file name must be jane@example.com.jpg.
Locate the <Details> section. Create a new <Details> line for the ImagePath to be used by desktop clients. In the FieldName setting, enter the attribute that contains the URL. For example,if the attribute that contains the photo URL is description the new line is:
<Detail Type=\"text/plain\" Id=\"ImagePath\" FieldName=\"description\"/>\nIf you have mobile clients, add an additional <DetailType> for PhotoURL. For example:
<Detail Type=\"text/plain\" Id=\"PhotoURL\" FieldName=\"description\"/>\nIn the Set params settings, select the Id names for the fields that you want to display as part of the business card. And remove any Ids that you do not want to include.
For example, if you do not want to include the company name, remove \u201cCompany\u201d from the list of attributes.
If you have added ImagePath, PhotoURL, or both, add these to the <Set params> and remove Photo.
There are two lines that begin with <Set params>, each one has a unique SetID=.
UserInfoConfig.xml file must be updated.Locate the StorageDetails tag of the relevant LDAP directory and add the following flags:
UserIdAttribute= attribute_name
Where attribute_name is the name of the attribute configured as the internal ID.
PersonObjectClass= object_class_name
Where object_class_name is the name of the person object class, for example: organizationalPerson.
When all updates are complete, save and close the UserInfoConfig.xml file.
Verify that there are not formatting errors by opening the file in a browser.
If no mistakes are found, update the Docker or Kubernetes deployment for the settings to take effect. See Customizing business cards in Docker and Podman or Customizing business cards in Kubernetes.
Parent Topic: Setting up business cards
"},{"location":"admin/config_buscard_custom_docker.html","title":"Customizing business cards in Docker and Podman","text":"You can override the default business cards configuration by editing a UserInfoConfig.xml file and adding it as a volume in the docker-compose.yml.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Copy the existing file out of the community container and place it in the current Sametime installation directory.
docker cp <container_name>:/local/notesdata/UserInfoConfig.xml . \nTo identify the community container ID, run the command docker container ls and look for the chat-server IMAGE. The NAME is the container name, as an example: sametime-community-1.
Make needed changes, then update volumes in the Community service section of docker-compose.yml by adding the following.
./UserInfoConfig.xml:/local/notesdata/UserInfoConfig.xml\nRestart the Sametime server to apply the changes.
docker-compose down\ndocker-compose up -d\nParent Topic: Setting up business cards
"},{"location":"admin/config_buscard_custom_kubernetes.html","title":"Customizing business cards in Kubernetes","text":"You can override the default business cards configuration by creating an extra-community-configs secret to hold the configuration files.
Kubectl commands are used to pull the existing file from the community pod to your local machine. You modify these files locally with the required settings, then create the secret containing the files.
The following procedures describes the steps to create a new secret. The example used in the steps shows creating a secret called extra-community-configs which overrides the values.yaml settings for LDAP. The extra-community-configs secret contains a copy of the configuration files used by the Community pod. For more information on secrets, see Managing secrets in Kubernetes.
Create a directory on your machine called extra-community-config at the root of where the Sametime installation package was decompressed.
mkdir extra-community-config\nUse the cd command to change to the extra-community-config directory.
cd extra-community-config\nFind the community pod name by running the get pods command.
The pod name has some hashes in it, for example: community-77d4695988-2bzrx): kubectl get pods.
Run the following command to pull a copy of the StCommunityConfig.xml file from the community pod specifying the name of the pod.
kubectl exec -it pod\\_name --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml\nThis file must be available. No changes to it are needed at this time.
Run the following command to pull a copy of the UserInfoConfig.xml file from the community pod specifying the name of the pod.
kubectl exec -it pod\\_name --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml\nUsing a text editor, open the local copy of the UserInfoConfig.xml file in edit mode. Modify the file as needed.
When finish, save and close the file.
Ensure that you are in the extra-community-config directory that was created earlier. Run the following command to create the secret. If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure it is created in the correct namespace.
kubectl\u202fcreate secret generic extra-community-config --from-file=./ \nUse the cd command to change to the helm directory where the Sametime installation package was decompressed.
cd helm\nOpen the values.yaml file and put in edit mode.
Add the following line to the values.yaml file.
overrideCommunityConfigSecret: extra-community-config\nWhen finished save and close the file..
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up business cards
"},{"location":"admin/config_chat_ldap_java_format.html","title":"Example: Writing a Java class to format names returned in a search","text":"To return a user name in a format that is not available in an LDAP directory entry attribute, you can write a Java\u2122 class that manipulates existing information in the LDAP directory to produce the user name in the desired format.
In most environments, the value of the The attribute of the person entry that defines the user's name setting can specify a common LDAP directory attribute, such as cn (common name) or mail (email address). When configured in this way, the search returns the value assigned to a user's cn or mail directory attribute and displays this value in the HCL\u00ae Sametime\u00ae client user interface.
To return names in a format different from the LDAP directory attributes, create a custom Java class. For example, you might create a Java class that does the following:
The sample code that follows shows how to combines the values of the sn and givenName attributes to return a user name with the surname shown first, assuming the following requirements:
Sample code
This example takes values from the sn and givenName directory attributes and combines these values into a single display name in the format of surname, given name.
public class StLdapCustomizedAttributes\n\n{\n\npublic static String displayName (String givenName, String sn) \n\n{\n\nString result = sn + \", \" + givenName;\n\nreturn result;\n\n}\n\n}\nAfter writing your Java class, complete the tasks in this section to implement it in either Docker or Kubernetes.
Parent Topic: Creating custom Java classes for searching LDAP
"},{"location":"admin/config_chat_ldap_java_people.html","title":"Example: Writing a Java class to filter searches for people and groups","text":"If a single search filter is not adequate to resolve user or group name searches, you can write a Java\u2122 class containing a method that specifies exactly how directory searches are conducted. The class can invoke different LDAP search filters depending on search criteria entered by users.
The Search filter for resolving person names and the Search filter for resolving group names settings in the LDAP directory settings of the Sametime\u00ae Administration Tool define the LDAP directory search filters responsible for selecting user and group names from the LDAP directory.
Note: You do not have to write Java classes to control the search behavior for both users and groups. You can use a Java class to control the search behavior for users while using a single LDAP search filter to control the search behavior for groups, or vice versa.
The specific source code that you write to support customized LDAP searches is entirely dependent on your environment. This section provides a code sample to help you understand how to write the Java class appropriate for your environment.
Note: The searched name must be escaped according to LDAP RFC2254 before adding it to the created LDAP filter. Use the escape and the isHex methods as is from the following example.
The following example invokes different LDAP directory search filters based on the text string that is entered into the Sametime user interface by a user. The search filters invoked by the method are dependent on the directory schema and the search behavior needed for the environment. Assume that three different users want to add the user Victor Lazlow to their Sametime Connect Client buddy lists. Each of the three users searches for Victor Lazlow in a different way. The logic of the Java class dictates the results of these three user searches:
User 1
Input: User 1 enters Victor L* into the Sametime client user interface to add Victor Lazlow to the Contacts list.
Results: This search attempt returns an error because the Java class is programmed to return an error when the user enters a text string that includes an asterisk.
User 2
Input: User 2 enters Victor_Lazlow@example.com into the Sametime client interface.
Results: This search attempt succeeds and returns the value \"Victor_Lazlow@example.com\" (Victor Lazlow's email address) from the LDAP directory. The search attempt succeeds in this way because the Java class is programmed to return an LDAP search filter that can resolve an LDAP directory search to a user's email address. The Java class returns this email address search filter if the search text string entered by the end user includes the \"at\" character (@).
User 3
Input: User 3 enters \"Victor L\" into the Sametime client interface. This search attempt succeeds and returns the common name (cn) directory attribute of \"Victor Lazlow.\"
Results: The search attempt succeeds in this way because the Java class is programmed to return an LDAP search filter that can resolve an LDAP directory search to a user's common name (cn). The Java class returns this common name search filter if the search text string entered by the end user does not include either an asterisk or \"at\" (@) character.
Sample code
The code sample that follows shows the Java source code that produces this search behavior. This code creates a Java class named StLdapCustomized that includes the peopleResolveFilter method. The if statements in the peopleResolveFilter method examine the text string entered by the user in the Sametime client user interface and return the appropriate LDAP search filter based on this text string. The comments in the source code explain the purpose of each if statement.
public class StLdapCustomized\n{\n /**\n * String representing an escaped forward slash sign '\\'\n */\n private final static String SLASH_SIGN_CONVERTED = \"\\\\5c\";\n\n /**\n * String representing an escaped * sign '*'\n */\n private final static String STAR_SIGN_CONVERTED = \"\\\\2a\";\n\n /**\n * String representing an escaped opening bracket sign '('\n */\n private final static String OPENING_BRACKET_SIGN_CONVERTED = \"\\\\28\";\n\n /**\n * String representing an escaped closing bracket sign ')'\n */\n private final static String CLOSING_BRACKET_SIGN_CONVERTED = \"\\\\29\";\n\n /**\n * Escape problematic characters in the name to match the LDAP filter escaping\n * criteria according to RFC2254\n * rfc2254 - The String Representation of LDAP Search \n * @param name the name to escape\n * @return an escaped string\n */\n private static String escape(String name)\n {\n StringBuffer escapedName = new StringBuffer();\n for (int i=0; i< name.length(); ){\n switch(name.charAt(i)){\n case '\\\\':\n // if the next 2 chars are hex we don't need to escape\n if((i< name.length()-2) && isHex(name.charAt(i+1)) &&\n isHex(name.charAt(i+2))){\n escapedName.append('\\\\');\n escapedName.append(name.charAt(++i));\n escapedName.append(name.charAt(++i));\n }\n else{\n escapedName.append(SLASH_SIGN_CONVERTED);\n }\n i++;\n break;\n\n case '*':\n escapedName.append(STAR_SIGN_CONVERTED);\n i++;\n break;\n\n case '(':\n escapedName.append(OPENING_BRACKET_SIGN_CONVERTED);\n i++;\n break;\n\n case ')':\n escapedName.append(CLOSING_BRACKET_SIGN_CONVERTED);\n i++;\n break;\n\n default:\n escapedName.append(name.charAt(i));\n i++;\n\n }\n }\n\n return escapedName.toString();\n }\n\n /**\n * Verifies whether this char is a hex char\n * @param c\n * @return\n */\n private static boolean isHex(char c){\n boolean hex = true;\n hex = !( Character.digit(c, 16) == -1);\n return hex;\n }\n\n /**\n * Generates a search filter for finding a user, given the user's \n * name. \n * The searched name is escaped according to LDAP filters escaping rules.\n * The checks on the searched name format should be done before escaping the value.\n * @param name The user's name as provided by the Sametime client.\n * @return The search filter, or null if the name is invalid. \n * */ \n\n public static String peopleResolveFilter (String name) \n { \n String escapedName;\n // prevent users from adding their own wildcards\n if (name.indexOf('*') != -1) \n return null;\n\n // if name looks like email, do not search with wildcards, and only search in mail attribute \n if (name.indexOf('@') != -1) \n {\n escapedName = escape(name);\n return \"(&(objectclass=person)(mail=\" + escapedName + \")) \";\n }\n\n // otherwise, search as CN with wildcard\n escapedName = escape(name);\n return \"(&(objectclass=person) (cn=\" + escapedName + \"*))\";\n }\n}\nAfter writing your Java class, complete the tasks in this section to implement it in either Docker or Kubernetes.
Parent Topic: Creating custom Java classes for searching LDAP
"},{"location":"admin/config_class_file_docker.html","title":"Configuring the class file on Docker and Podman","text":"Use a custom Java class file to transform your searches for LDAP for the community pod.
You must have already created and compiled the class file using Java 1.8.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
To configure a custom Java class file to transform your searches for LDAP for the Sametime server on Docker you need to complete the following tasks.
Override the default LDAP settings to use the class file
Name the compiled class file StLdapCustomizedAttributes.classfile.
Place the StLdapCustomizedAttributes.classfile into the Sametime installation directory or a sub directory, example: ldap-custom-filter.
Identify the chat-server container ID by running the docker container ls command and finding the chat-server IMAGE. The NAME is the container name. For example: sametime-community-1.
Pull a copy of the StCommunityConfig.xml from the chat-servercontainer by running the following command, where containerid is the container name for the chat server identified in step 2.
If the StCommunityConfig.xml has already been copied and edited previously for a different setting, skip this step and edit the existingStCommunityConfig.xml.
docker cp <container_name>:/local/notesdata/StCommunityConfig.xml . \nUpdate the configuration that pertains to your custom Java class. Open theStCommunityConfig.xml file that was copied from the chat-server contain and edit the <LDAP> section as it pertains to your configuration.
The changes depend on what you are modifying, refer to the following table for guidance.
Type of change Parameter name What to specify Example Search filter for resolving person names PersonResolveFilter classname.methodname() for your custom codeStLdapCustomized.peopleResolveFilter() Search filter for resolving group names GroupResolveFilter Class name and method name for a group filter, using the following format: Classname.methodname() StLdapCustomized.groupsResolveFilter(). Attribute of the person entry that defines the person's name DescAttribute Class name and method name for the formatting, with the name of the attribute inside, for example: Classname.methodname(attribute_name) StLdapCustomizedAttributes.displayName(cn) Save and close the StCommunityConfig.xmlfile.
Edit the docker-compose.yml file and add the following under the community section:
volumes: \n - ./ StLdapCustomizedAttributes.class:/local/notesdata/java/ StLdapCustomizedAttributes.class\nIf the class files is placed in a sub-directory, it must be specified in the above volume path.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Creating custom Java classes for searching LDAP
"},{"location":"admin/config_class_file_kubernetes.html","title":"Configuring the class file on Kubernetes","text":"You can use a custom Java class file to transform your searches for LDAP for the community pod.
You must have already created and compiled the class file using Java 1.8.
To configure a custom Java class file to transform your searches for LDAP for the community pod in Kubernetes you need to complete the following tasks.
The changes in this task affect the following pods:
community
Create a configmap with your compiled class file.
Name the compiled class file StLdapCustomizedAttributes.class.
Create a folder on the machine where you run the kubectl commands called ldap-custom-filter.
Place the StLdapCustomizedAttributes.class file into the ldap-custom-filter folder.
Change directories to the ldap-custom-filter folder.
Run the following command to create a ConfigMap with the StLdapCustomizedAttributes.class within it.
kubectl create configmap ldap-custom-filter --from-file=./ \nNote: If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure it is created in the correct namespace.
Modify the pod.yaml file for the community pod to load the ConfigMap.
Use a text editor to open the file pod.yaml in the helm/charts/community/templates/ directory.
Locate the volumeMounts: section and under the first mountPath, statement create a new line and add the following stanza.
- name: ldap-custom-filter \n configMap: ldap-custom-filter\n name: \nCorrect the indentation using only spaces so that the alignment of the new lines is the same as the lines above it. When finished it should look like the following:
Save and close the pod.yaml file.
Override the default LDAP settings to use the class file.
Make a directory on your machine called extra-community-config at the root of where the Sametime installation package was decompressed.
Change to the extra-community-config directory.
Find the community pod name by running the get pods command. The pod name has some hashes in it, for example: community-77d4695988-2bzrx):.
kubectl get pods\nPull a copy of the StCommunityConfig.xml file from the community pod.
Run the following command, where podname is the pod name found in the previous step.
kubectl exec -it pod\\_name --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nPull a copy of the StCommunityConfig.xml file from the community pod.
Run the following command, where podname is the pod name which is the same as the previous step.
kubectl exec -it pod\\_name --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nUpdate the configuration that pertains to your custom Java class. Open the StCommunityConfig.xml file that was copied to your machine. Then edit the <LDAP> section as it pertains to your configuration. The changes depend on what you are modifying, refer to the following table for guidance.
StLdapCustomized.peopleResolveFilter() Search filter for resolving group names GroupResolveFilter Class name and method name for a group filter, using the following format: Classname.methodname() StLdapCustomized.groupsResolveFilter(). Attribute of the person entry that defines the person's name DescAttribute Class name and method name for the formatting, with the name of the attribute inside, for example: Classname.methodname(attribute_name) StLdapCustomizedAttributes.displayName(cn) Save and close the StCommunityConfig.xml file.
Ensure you are in the extra-community-config directory that was created earlier then run the following command to create the secret.
kubectl\u202fcreate secret generic extra-community-config --from-file=./ \nNote: If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure it is created in the correct namespace.
Change to the helm directory where the Sametime installation package was decompressed.
Open thevalues.yaml file and place in edit mode.
Add the following line.
overrideCommunityConfigSecret: extra-community-config\nSave and close the values.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Creating custom Java classes for searching LDAP
"},{"location":"admin/config_client_access_pref.html","title":"Accessibility preferences","text":"The following table lists the accessibility preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release useAcc Boolean. Default is false. Specifies whether or not to optimize chat transcript for screen readers (will replace the transcript with a different format). 7.5.1 and later optimizeAlerts Boolean. Default is false. Specifies whether or not to optimize notification settings for screen readers (will turn off bring to front, flash window, turn on sounds). 7.5.1 and later useLessVerbose Boolean. Default is false. Specifies whether or not to set less verbose messages for screen readers (less verbose will not read status change events and typing events in the chat window). 7.5.1 and later useArrowKeyForQuickfind Boolean. Default is false. Specifies whether to use the arrow key for quick find. 8.5.1 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_cal_pref.html","title":"Calendar preferences","text":"The following table lists the calendar preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release alertMeWhenMeetingStarts Boolean In Auto-Status Changes for Meetings scheduled in my calendar, specify whether to alert user when user has a meeting scheduled in the calendar. 8.5.1.1 and later enabled Boolean Specify wether or not to enable auto status change for meetings scheduled in user's calendar. 8.0 and later promptMe Boolean In Auto-Status Changes for meetings scheduled in my calendar, specify whether to prompt user before changing the status when user have a meeting scheduled in the calendar. 8.0 and later statusMsg String In Auto-Status Changes for meetings scheduled in my calendar, specify the status message when user select \"Automatically change my status.\" 8.0 and later setback Boolean In Auto-Status Changes for meetings scheduled in my calendar, specify whether to return to user's previous status when the meeting is over. 8.0 and later outlook_enabled Boolean In Calendar Service page, specify whether to check Outlook calendar for meetings to allow auto status changes. It's valid only if the Outlook service is available. 8.0 and later notes_enabled Boolean In Calendar Service page, specify whether to check Notes calendar for meetings to allow auto status changes. It's valid only if the Notes service is available. 8.0 and later interval Positive integer value, unit is minutes. 10 minutes is the default. In Calendar Service page, specify the interval that Sametime retrieves calendar information for an auto-status change. This value is not for the interval to update auto-status. 8.0 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_chat_history_pref.html","title":"Chat preferences","text":"The following tables list the chat preferences for the HCL Sametime Connect Client and Sametime Embedded Client for Notes\u00ae.
Table 1. Application Preferences - com.ibm.collaboration.realtime.application release 8.5.1.1 and later
Attribute Variable type Description Release enableNwayRichText Boolean. Default is false. Specifies whether or not to enable the client to support rich text in a multi-user chat. Rich text is enabled in a multi-user chat session only if all clients participating in the chat session have this setting enabled. 8.5.1.1 and laterTable 2. Chat History Preferences - com.ibm.collaboration.realtime.chat.logging release 7.5.x and later
Attribute Variable type Description Release days.storage.max A positive number. Delete saved transcripts after this number of days. This setting will be overwritten by the value set on the server policy. 7.5.1 and later delete.old A positive number. The default is false. Delete saved transcripts. This setting will be overwritten by the value set on the server policy. If the policy allows transcripts to be deleted, set this value to true initially. 7.5.1 and later logging.default 0 = Automatically save chats, 1 = Do not automatically save chats, 2 = Prompt me to save chats Default chat logging action. 7.5.1 and later logging.enabled Boolean. Default is false. Specify whether or not to save a local copy of the chat history. If the server policy is not configured to allow save chat, this setting is ignored. 7.5.1 and later Note: Local chat history is unencrypted. To disable and restrict users from saving a local copy, refer to Updating client preferences with the managed-settings.xml file. display.context True = Display, false = Do not display Display the saved transcript between two users for the current day in the chat window. 7.5.1 and later display.context.background True = Display, false = Do not display Display background highlighting when displaying saved transcripts in chats. 7.5.1 and later root.location A string of a valid path on the computer. Location for automatically saved chats Directory path. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. Example using absolute path:com.ibm.collaboration. realtime.chat.logging/ root.location= C:\\\\Documents\\\\user\\\\ SametimeTranscripts Releases 8.0.2 and later support the use of a relative path. Example using a path relative to the user profile folder for Windows\u2122 and Mac: com.ibm.collaboration. realtime.chat.logging root.location= \\\\SametimeTranscripts For Linux com.ibm.collaboration. realtime.chat.logging root.location= \\\\SametimeTranscripts save.file.location A string of a valid path on the computer. Default location for manually saved chats. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. Example using absolute path: 7.5.1 and later com.ibm.collaboration.realtime.chat.logging/ave.file.location=C:\\\\Documents\\\\user\\\\SavedChats Releases 8.0.2 and later support the use of a relative path. Example using a path relative to the user profile folder for Windows and Mac: com.ibm.collaboration. realtime.chat.logging/ root.location= \\SametimeTranscripts For Linux, com.ibm.collaboration. realtime.chat.logging/ root.location= SametimeTranscripts prompt.save Boolean If using mail service for logging, specify whether to display a confirmation after manually saving chats to the mail file. 7.5.1 and later reset.user.resets.logging.prefs Boolean. Default is false. Specify whether to prompt user to reset logging preferences after resetting user. 7.5.1 and later firsttime.askprefs Boolean. Default is true. Specify whether to prompt user to set logging preferences when Sametime\u00ae launched for the first time. When the value is set to true, loggging.enabled should also be set to define the default enablement state for saving chat transcripts. 7.5.1 and later schedule.delete.old Boolean. Default is false. Specify whether or not to start the scheduled file-based chat history deletion task. The task is scheduled at a 12-hour interval, starting from the login time. The local chat history is deleted automatically only if the corresponding server policy is enabled for it. 8.5.2 IFR1 and later Table 3. Chat History UI Preferences - com.ibm.collaboration.realtime.chat.logging.ui release 7.5.x and later
Attribute Variable type Description Release allowSaveOverride Boolean. Default is true. Specifies whether to show menu item \"Prevent Transcript save\" in chat window Tools menu 7.5.1 and later noPersonListLiveNames Boolean. Default is false. Specifies whether to use Live Names in the chat history viewer person list. 8.5.2 and laterTable 4. Chat Window Preferences - com.ibm.collaboration.realtime.chatwindow release 7.5.x and later
Attribute Variable type Description Release showuserinfo Boolean. Default is true. Specifies whether or not to display the business card in the chat window. 7.5.1 and later showtimestamp Boolean. Default is true. Specifies whether or not to display timestamps in the chat transcript area. 7.5.1 and later showdatestamp Boolean. Specifies whether or not to display date stamps in the chat transcript area. 7.5.1 and later showemoticons Boolean. Default is true. Specifies whether or not to display emoticons in the chat transcript. 7.5.1 and later usemyfont Boolean. Default is false. Specifies whether or not to override chat partner's font settings with my own. 7.5.1 and later entersend Boolean. Default is true. Specifies whether or not Enter is used to send a message or Shift+Enter. Enter sends, Shift+Enter newline 7.5.1 and later showstatusupdates Boolean. Default is false. Specifies whether or not to display status updates for my chat partner in the transcript. 7.5.1 and later esccloses Boolean. Default is true. Specifies whether or not ESC closes the chat window. 7.5.1 and later showuserleft Boolean. Default is false. Specifies whether or not to display a message when my chat partner closes their chat window. 7.5.1 and later warnWhenInMtg Boolean. Default is true. Specifies whether or not to pop a warning message when I try to open a chat window when a person is in a meeting. 7.5.1 and later warnWhenAway Boolean. Default is true. Specifies whether or not to pop a warning message when I try to open a chat window when a person is away. 7.5.1 and later dontPopWhenMin Boolean. Default is true. Specifies whether or not the chat window pops to the front when I manually minimize the window. 7.5.1 and later showActionBar Boolean. Default is true. Specifies whether or not to show the actions toolbar. 7.5.1 and later showStatusBar Boolean. Default is true. Specifies whether or not to show the status message bar at the bottom. 7.5.1 and later showToolsBar Boolean. Default is true. Specifies whether or not to show the message tools bar. 7.5.1 and later showSendButton Boolean. Specifies whether or not to show send button in the chat window. 7.5.1 and later showQuickFind Boolean. Specifies whether or not to show quick find in the tabbed chat window. 7.5.1 and later useTabs Boolean. Default is false. Specifies whether or not to use a single tabbed window for all chats. 7.5.1 and later horizontalTabs Boolean. Default is false (vertical). Specifies whether to use horizontal or vertical tabs. Does not apply unless useTabs is true. 7.5.1 and later warnNewMessageArrived Boolean. Default is true. Specifies whether or not to pop a message dialog when I try to close the window at the same time I am receiving a message. 7.5.1 and later warnNewMessageArrived Threshhold Long. Default is 450. It is used in conjunction with the warnNewMessageArrived preference. When warnNewMessageArrived is true, if set this to 10000 (10 seconds) and try to close chat window 5 seconds after the last message, the warning dialog will pop up. It is not recommended to change the default value. 7.5.1 and later useDefaultGO Boolean. Default is true. Specifies whether or not to use the system's default orientation for typing or to manually set one. 7.5.1 and later sendAreaGO Integer. Specifies which orientation to use in the typing area if useDefaultGO is false. Not set by default because useDefaultGO is true. Only accepts two values, 67108864 (SWT.RIGHT_TO_LEFT) or 33554432 (SWT.LEFT_TO_RIGHT) 7.5.1 and later timeformat Integer. Default is 12. Specifies the default time format to use (12 or 24 hour clock). 7.5.1 and later maxChatsShowWarn Boolean If using tabbed window, specifies whether or not to show a warning dialog when current chat count exceeds the predefined value. 7.5.1 and later maxChats Integer. Default is 50. Specifies a predefined value for maxChatsShowWarn 7.5.1 and later saveChats Boolean Specifies whether or not to save opened chats across sessions. 7.5.1 and later transcript.view.limit Integer. Default is 0. Specifies a limit to the number of text/graphics lines that are maintained in the chat window. Setting to 0 means no limit. 8.5 and later ProvideTabbedBrowser Cache Boolean. Default is true. Specifies whether when using tabbed chats if the browser window can be cached to improve memory when the chat is not active. 8.5.1 and later persistPosition Boolean Specify whether to remember the position of chat windows. If it is set, the chat window position is remembered each time on window close action and used as the default location for next chat window open action. 8.5 and later xpos Integer Specify the X value of chat window position. 7.5.1 and later ypos Integer Specify the Y value of chat window position. 7.5.1 and later windowWidth Integer Specify the width of chat window. 7.5.1 and later windowHeight Integer Specify the height of chat window. 7.5.1 and later sendAreaHeight Integer Specify the height of the input box of chat window. 7.5.1 and later replyWithOfflineMessageContent Boolean. Default is true. Specify whether or not to include the received message when replying to an offline message. 8.5.2 IFR1 and later disableInlineIME Boolean. Default is false. Specify whether or not to disable inline mode for an input method in the chat input area of a chat window. Apply this setting if there is problem with a specific input method, such as a Traditional Chinese Input Method Editor (IME). 8.5.2 IFR1 and later participantsViewPosition String. Specifies the location of the n-way chat participant list panel on either the side of the chat transcript area. 9.0 and later sortTabs Boolean. Default is false. Specifies whether or not to sort the chat tabs in a tabbed chat window. 9.0 and later sortOrder String. Default is two_way:n_way:chat_room Specifies the order of chat tab types, if the setting is true for sortTabs. The user can change the sort of if desired. 9.0 and later autoAcceptInvitation Boolean. Default is true. Allows invitee to automatically join a multi-person chat without clicking Accept when invited to join the chat. 9.0 and later allowOthersToSeeTranscript Boolean. Default is true. Allows new chat invitees to see the previous chat transcript when they join the chat. 9.0 and laterTable 5. RTC Adapter Plugin Preferences - com.ibm.collaboration.realtime.rtcadapter release 8.5.2 and later
Attribute Variable type Description Release disableRichText Boolean. Default is false. Specifies whether or not to disable rich text for all chats. 8.5.2 and later disableRichTextWithAnon Boolean. Default is false. Specifies whether or not to disable rich text for chats with anonymous users. 8.5.2 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_comm_pref.html","title":"Community preferences","text":"The following tables list the default community preferences and alternate community preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description kioskMode Boolean Kiosk mode allows multiple users to share the same client on the same computer. If set to true, the client deletes personal information after each user logs out. When this setting is enabled, the automatic login, password saving, and locally stored contacts list features are not available because they require the use of personal information. logoutWhenIdle Boolean Specifies whether the client should disconnect from the server (and log out the user) when idle. logoutWhenIdleOverride Boolean Provides a mechanism to override the user's logoutWhenIdle setting. If set to true, then the client will always logout when idle, and the user will not be able to change the value the Preferences settings. logoutWhenLocked Boolean Sets the initial value of whether or not the Embedded client logs out when Notes is locked (disconnected from the server). This preference only applies to new users. logoutWhenLockedOverride Boolean Provides a mechanism to override the user's logoutWhenLocked setting. If set to true, then the client will always logout when locked, and the user will not be able to change the value in the Preferences settings. tokenLoginOnly Boolean Specifies the whether to force login by token for the default community. Takes effect the next time that the client connects to the Community Server. host String Specifies the initial community host value. Takes effect the next time that the client connects to the Community Server. authServerUrl String Specifies the initial authentication server URL value for the default community. Takes effect the next time that the client connects to the Community Server. defaultAuthType String Specifies the authentication type for the default community. For user name and password authentication, this setting should be left empty. For Domino\u00ae Single Sign-On in the Embedded client, the value should be set to ST-DOMINO-SSO. For a SAML authentication community, the value should be set to SAML. keepAlive Boolean. Default is true. The keepAlive feature allows the client remain connected to the Sametime Community Server even when the user is inactive, so that the user remains logged in to Sametime. In the client, use the Server tab of the Preferences > Server Communities > community page to specify how often a keep-alive signal should be sent to the server. keepAliveInterval Integer. Default is 60. Specifies the initial keep alive interval value for the default community. Takes effect the next time that the client connects to the Community Server. loginByToken Boolean If set to true, the client will log in to the community using a token other than user name and password pair. For example, the Embedded client can use Domino Single Sign-On with the LTPA token, and the Connect client uses can use the SAML token. Takes effect the next time that the client connects to the Community Server. name String Specifies the initial name for the default community. Takes effect the next time that the client connects to the Community Server. port Integer. Default is 1533. Specifies the initial community port value. Takes effect the next time that the client connects to the Community Server. savePassword Boolean. Default is false. Specifies whether the user's password is saved for the default community. Takes effect the next time that the client connects to the Community Server. connectionType String. Valid values include direct, tls-direct, http-direct, socks4-proxy, socks5-proxy, http-proxy, https-proxy, reverse-proxy, useBrowserSettings. Specifies the connection protocol that is used when the client connects to the default community. Takes effect the next time that the client connects to the Community Server. proxyHost String Specifies the host name for the Sametime Proxy Server that browser clients connect to before accessing the Community server where the default community is hosted. Takes effect the next time that the client connects to the Community Server. proxyPort Integer Specifies the port number that listens for browser client connections on the Sametime Proxy Server used with the Community server where the default community is hosted. Takes effect the next time that the client connects to the Community Server proxyUserName String Specifies the initial proxy user name for the default community. Takes effect the next time that the client connects to the Community Server. proxyPassword String Specifies the initial proxy password for the default community. Takes effect the next time that the client connects to the Community Server. proxyResolvesLocally Boolean Specifies the initial proxyResolvesLocally value for the default community. Takes effect the next the time that the client connects to the Community Server. loginTokenRefreshInterval Integer. Default is 900000. Specifies the login token refresh interval in milliseconds. The default is 900000, or 15 minutes. samlTrustedSites String Specifies the URL of a trusted site for use with SAML authentication. Example:samlTrustedSites=url1,url2. Attribute Variable type Description altCommunityConfig.managedIds String Required. A comma-delimited set of IDs that represents each alternate community. For example, altCommunityConfig.managedIDs=altHost1,altHost2 defines two alternate communities named altHost1 and altHost 2. altCommunityConfig.altHost.altHostID.targetCommunityHost String Required. The host name of the alternate community. altHostID represents the ID you defined for the alternate community in the managedIds preference, such as altHost1. altCommunityConfig.altHost.altHostID.enabled Boolean. Default is true. Enables the alternate community configuration. altCommunityConfig.altHost.altHostID.weight Integer. Default is 0. The weight of the alternate community configuration relative to other alternate communities. The higher the value, the greater the weight. For example, a connection to an alternate community with a weight of 2 is tried before one with a weight of 0. Regardless of the assigned weight, the client attempts a connection to the last successful alternate community first. altCommunityConfig.altHost.altHostID.type String. The default is postDefaultConfig. Determines if the alternate community connection is tried before the default community or after. A value of postDefaultConfig attempts the connection after trying to connect to the default community. A value of preDefaultConfig attempts to connect to the alternate community first. altCommunityConfig.altHost.altHostID.attemptCount Integer. The default is 1. Sets the number of times the client attempts to connect to the alternate community before trying another community. altCommunityConfig.altHost.altHostID.fallbackOnly String By default, this preference is not set and the client attempts a connection to the last successful alternate community first. If you set the preference fallbackOnly for a specific alternate community, it will never be retried first, even if it was the last successful connection. altCommunityConfig.altHost.altHostID.host String Defines a secondary alternate community host to connect to if the host defined in the targetCommunityHost preference cannot be reached. For example, if the targetCommunityHost is im1.example.com, the host could point to im2.example.com. altCommunityConfig.altHost.altHostID.authServerUrl String Specifies the server URL for Single Sign-on authentication. altCommunityConfig.altHost.altHostID.authType String Defines the method used for Single sign-on authentication. Use TAM-SPNEGO for SPNEGO authentication or ST-DOMINO-SSO for Domino authentication within Notes. altCommunityConfig.altHost.altHostID.port Integer The port to use if other than the default 1533. altCommunityConfig.altHost.altHostID.connectionType String. Valid values include direct, tls-direct, http-direct, socks4-proxy, socks5-proxy, http-proxy, https-proxy, reverse-proxy. Determines how the client connects to the alternate community. The default is direct. altCommunityConfig.altHost.altHostID.proxyHost String Specifies the initial proxy host value for the alternate community. altCommunityConfig.altHost.altHostID.proxyPort Integer The port of the proxy. altCommunityConfig.altHost.altHostID.loginByToken Boolean Determines if the client logs in by token. If the token login fails and the password is available, the client attempts password-based authentication instead. tryLastSuccesfulConfigFirst Boolean. Default is true. Determines if the client first tries the alternate community it last connected to successfully. If you change the value to false, the client always attempts Connections to the alternate communities in the default priority order set in the managedIDs list, regardless of which alternate community connection was successful last. Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_connect_pref.html","title":"Selecting preferences in the client","text":"In the Preferences dialog of the HCL\u00ae Sametime\u00ae Connect Client and the Notes\u00ae client, users can choose any Sametime preferences that have not been locked by the administrator.
Log in to the client.
Depending on the client, open preferences:
Embedded in the Notes client - Click File > Preferences > Sametime.
In the Sametime Connect Client - Click the Actions and Preferences menu (the gear icon).
Select a feature in the features list.
Choose the preferred behavior for that feature, and then select Apply.
Select OK.
Any preferences set using this method can be overwritten by Sametime policies. Preferences set using this method are stored in the end-user's profile directory either within an XML document or a .pref file.
Parent Topic: Sametime client configuration options
"},{"location":"admin/config_client_contact_list_pref.html","title":"Contact list preferences","text":"The following table lists the contact list preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release sortGroups Boolean. Default is true. Specifies whether by default to alphabetically sort groups in the contact list. 7.5.1 and later sortContacts Boolean. Default is true. Specifies whether by default to alphabetically sort contacts in the contact list. 7.5.1 and later alwaysEditStatusMsgActive Boolean. Default is true. Specifies whether by default to always edit the status message when changing status to available. 7.5.1 and later alwaysEditStatusMsgAway Boolean. Default is true. Specifies whether by default to always edit the status message when changing status to away. 7.5.1 and later alwaysEditStatusMsgInMtg Boolean. Default is true. Specifies whether by default to always edit the status message when changing status to in a meeting. 7.5.1 and later alwaysEditStatusMsgDnd Boolean. Default is true. Specifies whether by default to always edit the status message when changing status to in a do not disturb. 7.5.1 and later showActionToolBar Boolean. Default is true. Specifies whether by default to show the action toolbar in the contact list window. 7.5.1 and later showStatusBar Boolean. Default is true. Specifies whether by default to show the status bar in the contact list window. 7.5.1 and later showQuickFind Boolean. Default is true. Specifies whether by default to show quick find in the contact list window. 7.5.1 and later flashAddedContacts Boolean. Default is true. Specifies whether by default to flash newly added contacts. 7.5.1 and later showAddDialogSuccess Boolean. Default is true. Specifies whether by default to open a confirmation dialog after a contact has been added. 7.5.1 and later showAddGroupSuccess Boolean. Default is true. Specifies whether by default to open a confirmation dialog after a group has been added. 7.5.1 and later showAddPartnerSuccess Boolean. Default is true. Specifies whether by default to open a confirmation dialog after a chat partner has been added (through add button in chat window). 7.5.1 and later autoSyncDefaultCommunity BuddyList|Boolean. Default is true.|Specifies whether by default to synchronize the 7.5 XML buddylist with the previous pre 7.5 contact list used by older clients. Windows\u00ae only.|7.5.1 and later| |launchAtStartup|Boolean|Specifies whether or not to launch Sametime at system startup. The preference is valid only for stand-alone clients and windows platform. If the preference is set it in plugin_customization.ini or managed preferences framework, it does not work for the first launch of the Sametime client.|7.5.1 and later| |hideWhenMinimized|Boolean. Default is true.|Specifies whether by default to hide the contact list window when minimized. The preference is valid only for the Sametime Connect Client for Microsoft\u00ae Windows.|7.5.1 and later| |showCommunityIconBackground|Boolean. Default is false.|Specifies whether by default to show the community icon behind the contacts.|7.5.1 and later| |statusImgBackgroundTransparency|Integer. Default is 60.|Specifies the transparency of the community background image. 0 is very prominent, 100 is completely transparent.|7.5.1 and later| |showHoverBizCard|Boolean. Default is true.|Specifies whether or not to show the business card when hovering over contacts.|7.5.1 and later| |hideContactsWhenOffline|Boolean. Default is false.|Specifies whether or not to hide the contact list tree when offline.|7.5.1 and later| |showBuddyListConflictDialog|Boolean. Default is true.|Specifies whether or not to show the contact list conflict dialog when synchronizing the remote contact list.|7.5.1 and later| |buddyListConflictPref|String. Default is merge.|Specifies the default behavior to follow in case of a remote/local synchronization conflict. Options include \"merge\", \"keepLocal\", and \"replaceLocal\".|7.5.1 and later| |warnWhenWatchLimitExceeded|Boolean|When the watch limit is in effect, specifies whether or not to warn user when the number of contacts that can be monitored is exceeded.|7.5.1 and later| |warnWhenContactLimitExceeded|Boolean|When \"LimitContactListSize\" policy is set, specifies whether or not to warn user when the contact list is approaching the maximum number allowed.|7.5.1 and later| |showShortNames|Boolean|Specifies whether or not to show short names for contact list.|7.5.1 and later| |alwaysOnTop|Boolean|Specifies whether or not to make the contact list window stay visible.|7.5.1 and later| |showOnlineOnly|Boolean|Specifies whether or not to show online contacts only in the contact list window.|7.5.1 and later| |showStatusToolBar|Boolean|Specifies whether or not to show My Status ToolBar in the contact list window.|7.5.1 and later| |showContactList|Boolean|Specifies whether or not to show the contact list in the contact list window.|7.5.1 and later| |confirmMultiPartyChatInvitation ToMoreThanX
|Boolean|Specifies whether or not to confirm when users start events with groups larger than a specified number of people. The number value is specified by confirmMultiPartyChatInvitationToMoreThanXNumber
.|7.5.1 and later| |confirmMultiPartyChatInvitation ToMoreThanXNumber
|Integer|Specifies a limit number. See confirmMultiPartyChatInvitationToMoreThanX
.|7.5.1 and later| |launchMinimized|Boolean.|Specifies whether or not to minimize Sametime when launching. It's valid only for stand-alone clients and windows platform.|8.5 and later| |limitPublicGroupSubscriptions
|Boolean. Default is true.|Takes contact list size of public groups into account to calculate the contact list size limit. The default value is true, which means that users cannot add a public group to their contact lists if doing so exceeds the contact list size. If users already have public groups in their contact lists, this preference causes the client to subscribe to each group in the list, from smallest to largest, until the limit is reached. Any other groups remaining in the contact list are shown as unsubscribed groups. Disabling a group subscription causes the client to add as many groups from the unsubscribed list as it can until the contact list size is reached again. Setting the value to false does not include the contact list size of public groups to calculate the contact list size limit.|8.5.2 and later| |maxPublicGroupSize
|Integer|The maximum number of contacts a public group can have that allows users to subscribe to it. Groups that exceed this size cannot be added to the contact list. If the group already exists in the contact list, users cannot subscribe to the group. You can set this preference when the limitPublicGroupSubscriptions preference is enabled.|8.5.2 and later| |excludedPublicGroups
|String|A comma-delimited list of public group names that should not be subscribed to (for example, employees_Active,employees_All). Groups in this list cannot be added to the contact list. If the group already exists in the contact list, users cannot subscribe to the group. You can set this preference when the limitPublicGroupSubscriptions preference is enabled.|8.5.2 and later| |allowExportContactList|Boolean , default value is false|Specifies whether to allow users to export their contact list. When set to false, the Export Contact List option does not display on the Manage Contact List menu..|9.0.1 and later|
Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_discontinue_xml_file.html","title":"Discontinuing managed preferences","text":"To stop setting preferences through the Expeditor managed settings framework, remove the reference to the managed-settings.xml or managed-community-configs.xml files and unlock any previously read-only settings.
Managed settings that were previously pushed to the clients as read-only will continue to be used until they are specifically removed from the client. Unlock all managed settings by editing the XML file:
Change all \"isLocked=true\" instances to \"isLocked=false\".
If the lastModDate atribute was used previously, change the lastModDate attribute to a newer timestamp for all group settings. Otherwise, skip this step.
Provision the updated XML file to the client.
Discontinue use of the settings.xml file based on the method you used to distribute managed preferences.
Method 1:
The managed-settings.xml or managed-community-configs.xml file hosted on a web server
Method 2:
The managed-settings.xml file defined in a plugin_customization.ini file.
Parent Topic: Updating client preferences with the managed-settings.xml file
"},{"location":"admin/config_client_ext_app_pref.html","title":"External application preferences","text":"The following table lists the external application preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Table 1. External application Preferences - com.ibm.collaboration.realtime.ui release 7.5.x and later
Attribute Variable type Description Release external.application.use.default.mail Boolean. Default is true. Specifies whether or to use default mail program for email. 7.5.1 and later AllowEMailFunction Boolean. Default is true. Provides a mechanism for disable/enable the mail function entries. If set to true, user can use mail function in Sametime client; if set to false, the menu/toolbar about mail function will be disabled. 8.0 and later external.application.use.custom.browser Boolean Specifies whether or not to use a custom browser on Linux\u00ae. 7.5.1 and later external.application.use.custom.mail Boolean Specifies whether or not to use a custom mail application on Linux. 7.5.1 and later external.custom.browser String Specifies the custom browser on Linux. 7.5.1 and later external.application.mail String. \"System Default\", \"Notes\", \"Evolution\", \"KMail\" and \"Thunderbird\" on Linux. \" Specifies the default mail application. 7.5.1 and later Notes\", \"Outlook Express\u2122\" and other available mail applications on Windows\u00ae. external.application.use.default.mail Boolean Specifies whether or not to use default mail application. 7.5.1 and later external.custom.mail String Specifies the user mail application on Linux. 7.5.1 and later disableHostnameWarning Boolean. Default is false. Specifies whether or not to validate that the server name is a fully qualified domain name. 8.5.1 and laterParent topic: Sametime client preferences
"},{"location":"admin/config_client_file_tran_pref.html","title":"File transfer preferences","text":"The following table lists the file transfer preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Table 1. File Transfer Preferences - com.ibm.collaboration.realtime.filetransfer release 7.5.x and later
Attribute Variable type Description Release allowTransferToAnonymous Boolean. Default is true. Specifies whether or not to disable file transfers to anonymous users. Setting the value to true does not prevent incoming file transfers from anonymous users. 8.5.2 and later saveFileLocation A text string of a valid full path to a folder on the user's computer. Specifies the path on the user's computer where files from File Transfers will be saved. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. Example using absolute path: 7.5.1 and latercom.ibm.collaboration.realtime.filetransfer/saveFileLocation=C:\\\\Documents\\\\user\\\\SametimeFileTransfer Releases 8.0.2 and later support the use of a relative path. Example using a path relative to the user profile folder for Windows\u2122 and Mac: com.ibm.collaboration.realtime.filetransfer/saveFileLocation=\\\\SametimeFileTransfer For Linux\u2122: com.ibm.collaboration.realtime.filetransfer/saveFileLocation=SametimeFileTransfer Parent topic: Sametime client preferences
"},{"location":"admin/config_client_location_pref.html","title":"Location preferences","text":"The following table lists the location preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release manualModeSelected Boolean Specifies whether or not to detect location changes automatically. 8.5 and later manualModeVisible Boolean Specifies whether the check box \"Do not automatically detect location changes\" is visible. 8.5 and later optIn Boolean Specifies whether or not to share user's location information with other users. 7.5.1 and later advancedView Boolean Specifies whether or not to show the advanced view for Location. 7.5.1 and later showProfWindow Boolean. Default is false. Toggle for do not show the alert for editing location settings at location change again. 7.5.1 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_login_pref.html","title":"Login preferences","text":"The following table lists the login preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Table 1. Login Preferences - com.ibm.collaboration.realtime.login release 7.5.x and later
Attribute Variable type Description Release autoLogin Boolean. Default is true. Specifies whether or not to enable the auto-login feature for clients. If this setting is enabled, users can choose whether to use the feature with the Automatically log in setting in the client. 7.5.1 and later enableAutoReconnect Boolean. Default is true. Specifies whether or not to enable automatic re-connection to the Sametime server in case the client is inadvertently disconnected. 7.5.1 and later autoReconnectAttemptInterval long. Default is 20000. Specifies the interval in milliseconds at which the client will attempt to reconnect. 7.5.1 and later autoReconnectAttempts long. Default is -1. Specifies the number of attempts to reconnect. The value -1 means to never stop trying. 7.5.1 and later verifyConnectionPriorToLogin Boolean. Default is true. Specifies whether or not to verify that a network connection is available before logging in. 7.5.1 and later notifyWhenNetConnLost Boolean. Default is true. Specifies whether or not to alert the user when the network connection is lost. 7.5.1 and later alwaysLoggedIn Boolean Keeps \"Automatically log in\" and \"Remember password\" disabled and checked and disables all \"Log out\" menu items. 7.5.1 and later disableExit Boolean Keeps the \"Exit\" menu items disabled. 7.5.1 and later disableHostName Boolean Sets edit state of host name text field on login dialog. 7.5.1 and later displayResetUserBtn Boolean Makes the reset button show or not on the login dialog. If the preference is set to true and 7.5.1 and later `com.ibm.collaboration. realtime.communit/host` is set to true, the reset button will automatically be disabled. allowSave Boolean Specifies whether or not to allow saving password. 7.5.1 and later earlyStartupLogin Boolean Specifies whether or not to show login dialog when the client starts. 7.5.1 and later resetUser Boolean. Default is false. Specifies whether or not to reset user information when the client starts. 7.5.1 and later displayAuthServerSSO Boolean. Default is true. Specifies whether or not to display Authentication server information in the community Log In tab. 7.5.1 and laterParent topic: Sametime client preferences
"},{"location":"admin/config_client_mng_xml_pref.html","title":"Configuring Sametime client preferences with the Expeditor managed settings framework","text":"You can configure and manage the user's Sametime client preferences for capable clients using the Expeditor managed settings framework. The Sametime clients that are Expeditor based include the Sametime client for Windows or Mac, and the HCL Notes embedded Sametime client for Windows or Mac. This excludes the PWA, web and mobile clients.
The Expeditor managed settings framework pulls preference settings from a managed-settings.xml and/or managed-community-configs.xml file hosted on a web server or as a part of the Samtime client installation package.
There are two methods to deploy the settings to the user.
Method 1:
The settings files are hosted on a web server and the URL to the files is defined in either location:
In the plugin_customization.ini file as part of the Sametime installation package. This option requires customization of the client installation package.
In the user's Sametime policy.
The managed-settings.xml file can be packaged with the Sametime installation package. This option requires customization of the client installation package.
The following topics explain how to configure and update settings using the Expeditor managed settings framework.
Parent Topic: Sametime client configuration options
"},{"location":"admin/config_client_notes_pref.html","title":"Notes preferences","text":"The following table lists the Notes\u00ae preferences that can be managed for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes.
Attribute Variable type Description Release install_directory String. Should be a valid path for Notes. Specify the Notes installation directory. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.calendar.notes.connector/install_directory=D:\\\\Notes 8.0 and later notes_password String Specify the Notes password 8.0 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_notification_pref.html","title":"Notification preferences","text":"The following table lists the notification preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release pref_alertbubble_window_corner String. Default is \"SE\". Four possible values, \"NE\", \"NW\", \"SE\", SW\" (corresponding to northeast, northwest, southeast, southwest). This stores one of four possible values, which indicate the corner of the user's screen where alert bubble will appear. 7.5.1 and later pref_alertbubble_window_width Positive integer value Stores the width in pixels of the alert bubble. 7.5.1 and later pref_alertbubble_window_height Positive integer value Stores the height in pixels of the alert bubble. 7.5.1 and later pref_alertbubble_window_ edge_padding|Positive integer value|Stores the number of pixels to add as horizontal padding for the alert bubble to separate it from the edge of the desktop.|7.5.1 and later| |pref_alertbubble_show|String value, \"standard\" = show standard OS window, \"less\" or others = show alert bubble for an alert|Determines whether to show the alert bubble or a standard OS window for an alert.|7.5.1 and later| |pref_alertbubble_close_alerts|Boolean. TRUE = automatically close alert, FALSE = do not automatically close alert|Determines whether to automatically close an alert after it appears.|7.5.1 and later| |pref_alertbubble_close_alerts_ delay
|Positive integer value|If alerts are set to automatically close, this is the delay amount in seconds before the alert is closed.|7.5.1 and later| |pref_alertbubble_animation|String value, \"none\" = no window animation, \"slide\" = animate using slide effect, and \"fade\" = animate using fade effect. The default value is \"slide\"|Specify the Alert bubble animation type.|7.5.1 and later| |pref_alertbubble_bring_window_ to_front
|Boolean|The default value, whether to Bring the Popup window to front.|7.5.1 and later| |pref_alertbubble_flash_taskbar|Boolean|The default value, whether to Flash the taskbar to indicate new Popup window.|7.5.1 and later| |pref_event_0_playsound|Boolean|Determines whether to play sound when a new chat window opens.|7.5.1 and later| |pref_event_0_playsound_response|Boolean|For one-on-one chat, determines whether to play sound on chat response.|8.5.2 and later| |pref_event_1_playsound|Boolean|For multi-party chats, determines whether to play sound when there is an invitation to a multi-party chat.|7.5.1 and later| |pref_event_1_playsound_response|Boolean|For multi-party chats, determines whether to play sound on chat response.|8.5.2 and later| |pref_event_2_playsound|Boolean|Determines whether announcement events play a sound.|7.5.1 and later| |pref_event_3_playsound|Boolean|Determines whether Invitations to Sametime Classic online meeting play a sound.|7.5.1 and later| |pref_event_6_playsound|Boolean|Determines whether status alert events (Alert me When) play a sound.|7.5.1 and later| |pref_event_7_playsound|Boolean|Determines whether Location Awareness events play a sound.|7.5.1 and later| |pref_event_0_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for one-on-one chat events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.alertmanager/pref_event_0_soundfile=C:\\\\Documents\\\\sound.wav ``
|7.5.1 and later| |pref_event_1_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for Invitations to multi-party chat events, if playing sounds is enabled for this event. Do no't use '\\' as the file separator. Use '\\\\' or '/' instead. For example, ``com.ibm.collaboration.realtime.alertmanager/pref_event_1_soundfile=C:\\\\Documents\\\\sound.wav
|7.5.1 and later| |pref_event_2_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for announcement events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.alertmanager/pref_event_2_soundfile=C:\\\\Documents\\\\sound.wav.
|7.5.1 and later| |pref_event_3_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for Invitations to Sametime Classic online meeting events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.alertmanager/pref_event_3_soundfile=C:\\\\Documents\\\\sound.wav ``
|7.5.1 and later| |pref_event_6_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for status alert events (Alert me When) events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration.realtime.alertmanager/pref_event_6_soundfile=C:\\\\Documents\\\\sound.wav.
|7.5.1 and later| |pref_event_7_soundfile|Text string. Full path to a valid sound file of .WAV format.|The sound file that will play for Location Awareness events, if playing sounds is enabled for this event. Do not use '\\' as the file separator. Use '\\\\' or '/' instead. For example, com.ibm.collaboration. realtime.alertmanager/ pref_event_7_soundfile= C:\\\\Documents\\\\ sound.wav.
|7.5.1 and later| |pref_event_0_option_1|Boolean|For one-on-one chats, determines whether to bring chat window to front.|7.5.1 and later| |pref_event_0_option_2|Boolean|For one-on-one chats, determines whether to flash the taskbar to indicate new window.|7.5.1 and later| |pref_event_0_option_3|Boolean|For one-on-one chats, determines whether to show a system tray icon to indicate new message.|7.5.1 and later| |pref_event_0_option_4|Boolean|For one-on-one chats, determines whether to bring chat window to front on chat response.|8.5.2 and later| |pref_event_0_option_5|Boolean|For one-on-one chats, determines whether to flash the taskbar to indicate new message on chat response.|8.5.2 and later| |pref_event_0_option_6|Boolean|For one-on-one chats, determines, whether to show a system tray icon to indicate new message on chat response.|8.5.2 and later| |pref_event_1_option_1|Boolean|For invitations to multi-party chats, determines whether to bring invitation window to front.|7.5.1 and later| |pref_event_1_option_2|Boolean|For invitations to multi-party chats, determines whether to flash the taskbar to indicate new invitation.|7.5.1 and later| |pref_event_1_option_4|Boolean|For multi-party chats, determines whether to bring multi-party chat window to front on chat response.|8.5.2 and later| |pref_event_1_option_5|Boolean|For multi-party chats, determines whether to flash the taskbar on chat response.|8.5.2 and later| |pref_event_1_option_6|Boolean|For multi-party chats, determines whether to show a system tray icon on chat response.|8.5.2 and later| |pref_event_9_option_1|Boolean|For calls, determines whether to bring the invitation window to front.|8.5 and later| |pref_event_9_option_2|Boolean|For calls, determines whether to flash the taskbar to indicate new window.|8.5 and later| |pref_event_9_timeout_seconds|Integer, unit is second|For calls, specify the seconds before incoming invitation time out.|8.5 and later| |allow_response|Boolean|For Send Announcement dialog, determines whether to allow recipients to send responses.|7.5.1 and later| |pref_event_9_alert_incoming|Boolean|For calls, determines whether to display incoming invitation.|8.5 and later| |pref_event_10_playsound|Boolean|Determines whether calendar events play a sound.|8.5 and later| |pref_event_10_soundfile|Boolean|The sound file that will play for calendar events, if playing sounds is enabled for this event.|8.5 and later|
Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_people_pref.html","title":"People preferences","text":"The following table lists the people preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release lookupExpirationDays Integer. Default is 7. Specifies the number of days a users directory info is considered up to date. A value of 0 means refresh a user's directory info for each client session. 7.5.1 and later wrapBusinessCard Boolean. Default is true. Specifies whether or not to wrap text in business card 7.5.1 and later showNoPhotoPhoto Boolean. Default is true. Specifies whether or not to show a placeholder image in business card when user doesn't have a photo. 7.5.1 and later isCaseInsensitive Boolean. Default is false. Specifies if it is case insensitive when looking up people. The default of false means the search is case-sensitive. If you plan to set this to true, first turn off case sensitivity in the HCL Sametime Community server and restart the server. 7.5.1 and later userInfoReplacesDefaultDisplayName Boolean. Default is false. When set to true, contact names refresh automatically with the contact's business card name. When this preference is enabled, users can also update contact names manually. They can update one name by right-clicking a contact name and choosing Refresh Person Info. They can also update all names by selecting Tools > Refresh Contact Nicknames. For the preference to work, the person attributes in the LDAP directory used with the Sametime Community Server must meet the following requirements. Verify or change these settings by using the Sametime System Console to administer the Sametime Community Server. 7.5.1 and later Community Services tab - The attribute used for the internal user ID must be different from the attribute used for the person's display name. Business card tab - The attribute used for the business card name must be the same as the attribute used for the person's display name. refreshNicknamesOnFirstStartup Boolean. Default is false. Determines whether clients automatically replace all existing display names and nicknames in the contact list with business card names after clients start up and log in. You can set this preference when theuserInfoReplaces DefaultDisplayName preference is enabled. 8.5.2 and later Tip: To prevent the task from running each time you install on a new computer or reset the workspace, use managed preferences to set this preference temporarily for all new and upgrading clients. Disable the preference after all clients have run once. bizCardShowExtendedStatus Boolean. Default is false. Determines whether the extended status, such as phone call status, is displayed in the business card. The default setting is not to display all of the extended statuses in business card. 9.0 and later Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_pref_plugin.html","title":"Configuring Sametime Connect Client preferences in the plugin_customization.ini file","text":"Defining a settings file in the plugin_customization.ini file is an alternate method for distributing preferences to the Sametime\u00ae Connect Client. Unlike the managed-settings.xml file posted on an update site, this method does not provide any policy-based distribution of preferences.
Follow these steps to create a settings XML file and define it in the plugin_customization.ini file.
Create a settings XML file with a name such as managed-settings.xml.
Define preferences in the settings XML file.
Copy the settings XML file to the location where it will be called from the plugin_customization.ini file.
Add a key that defines the Expeditor Managed settings framework com.ibm.rcp.managedsettings.provider.file/URL and the name and location of the settings XML file to be used. For example:
com.ibm.rcp.managedsettings.provider.file/URL=http://www.example.com/managed-settings.xml\nor\ncom.ibm.rcp.managedsettings.provider.file/URL=file://c:/data/mananged-settings.xml\nSave the file and make it available to clients.
Every time the client starts, the plugin_customization.ini preferences are read.
Parent Topic: Configuring Sametime client preferences with the Expeditor managed settings framework
"},{"location":"admin/config_client_pref_tables.html","title":"Sametime client preferences","text":"This section lists the preferences that can be managed for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Parent Topic: Sametime client configuration options
"},{"location":"admin/config_client_rules_mng_pref.html","title":"Rules manager preferences","text":"The following tables list the rules manager preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release blockIncomingCalls Boolean. Default is true. Block all incoming calls. 8.5.1 and later rulesForComputerOnlyUsers Boolean. Default is true. Causes default rules to only apply for computer only users. 8.5.1 and later hideCallRoutingPrefs Boolean. Default is false. Hide the call routing preference pages. 8.5.1 and later disableRulesEditing Boolean. Default is true. Disable the ability to edit call routing rules. 8.5.1 and later disableOfflineCalling Boolean. Default is true. Disable ability for a computer only user to call an offline contact. 8.5.1 and later disableExternalCalling Boolean. Default is true. Disable ability for a computer only user to call an external contact or phone number. 8.5.1 and later disableNonComputerCalls Boolean. Default is true. Disable ability for a computer only user to call using anything other than their computer. 8.5.1 and later hidePreferredDevices Boolean. Default is false. Hide the preferred device list. 8.5.1 and later disablePreferredDevices Boolean. Default is true. Disable the preferred devices list. 8.5.1 and later hideAllocatedDevices Boolean. Default is true. Hide allocated devices so they cannot be used to answer calls or as a transfer target. 8.5.1 and later disablePreferredNumber Changes|Boolean. Default is true.|Disable the ability to add new preferred numbers.|8.5.1 and later| |replaceConditions|Boolean. Default is true.|Replace the users conditions with the defaults.|8.5.1 and later| |computerOnlyPrefix|String. Default is +999.|Unified number prefix which identifies a user as a computer only user.|8.5.1 and later| |callRoutingConditions|String. Default is /config/callRoutingConditions.xml
.|URL pointing to an XML file which defines the default call routing rules.|8.5.1 and later|
Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_spellchecker_pref.html","title":"Spell checker preferences","text":"The following table lists the spell checker preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release checkSpelling Boolean. Default is true. Specifies whether by default to check spelling as you type. 7.5.1 and later dictionaryLanguage String. Default is en-US. Specifies the default language to use for spellchecking. Must have corresponding dictionary installed. 7.5.1 and laterParent Topic: Sametime client preferences
"},{"location":"admin/config_client_stadv_pref.html","title":"Sametime Advanced preferences (Sametime 9.0.1 only)","text":"These settings only apply to environments that include the Sametime 9.0.1 Advanced Server.
The following table lists the preferences that are available for the HCL\u00ae Sametime\u00ae Advanced client. These preferences are set in the plugin_customization.ini file.
Table 1. Global Preferences - com.ibm.collaboration.realtime
Attribute Variable type Description enableAdvanced Boolean (default value is false) When the value is set to true, the Sametime Advanced plug-ins installed with the client become active. enableInstantShare Boolean (default value is false) If enableAdvanced is set to false, but the value of enableInstantShare is set to true, the instant share feature is available. Otherwise, the value of enableInstantShare is ignored.Table 2. Sametime Advanced Preferences - com.ibm.collaboration.realtime.persistentChat
Attribute Variable type Description showAdvancedVersioningAlert Boolean Suppress client version warnings when accessing a Sametime 9.0 (or higher) server from an older Connect or Embedded client.Table 3. Broadcast and Persistent Chat Preferences - com.ibm.collaboration.realtime.bcs
Attribute Variable type Description sametimeAdvancedServerName String Required. Fully qualified Apache Tomcat\u00ae Application Server host name, for example: sales. sametimeAdvancedServerPort String Required. Sametime Advanced Server port number. sametimeCommunityServer String Required. Default Sametime Community Server host name. This is the server users log in to for awareness and chat. broadcastToolsServerName String Required. Fully qualified Apache Tomcat Application Server host name. broadcastToolsServerPort String Required. Apache Tomcat Application Server port number. The port number is normally 1883 for HTTP and 8883 for SSL, but can be any port specified by the administrator. useHTTPS Boolean If you are using SSL while connecting to the server, set to true. If you are using HTTP set to false. advancedServerConnectionType String Connection type to connect to the Sametime Advanced server. Set to 0 for a direct connection to the server. Set to 1 to connect through a reverse proxy. broadcastServerConnectionType String Connection type to connect to the Broadcast Tools server. Set to 1 for a direct connection to the server. Set to 2 to connect using SSL. useHttpProxy Boolean Set to true if you are using an HTTP forward proxy; otherwise set it to false. proxyHost String Type the proxy IP address or host name if you are using a HTTP proxy, otherwise leave it blank. proxyPort String Type the HTTP proxy port to which you are connecting. proxyUserName String Type the user name if the HTTP proxy requires one for authentication; otherwise leave it blank. reverseProxyBaseURL String Type the reverse proxy base URL to use if connecting through a reverse proxy. For example: http://mycompany.example.com/mycontext Leave blank otherwise. reverseProxyUserName String Enter the reverse proxy user name if the proxy is authenticating. Leave blank if you are not using reverse proxies. jmsProtocol String Indicate whether the client connects with a secure connection using the Security Secure Sockets Layer (SSL) or not. The default is disthub (to connect without SSL). Enter disthubs to connect with SSL. liveNameResolveTimeout String (the default is 10000 milliseconds) Time allowed in milliseconds for awareness names to resolve. The default is 10000. notifyNewOpenCommunities Boolean (the default istrue ) Alert users when a new open community is created. notifyNewModeratedCommunities Boolean (the default istrue ) Alert users when a new moderated community is created. notifyNewPrivateCommunities Boolean (the default istrue ) Alert users when a new private community is created blockBroadcastOnDoNotDisturb Boolean (the default istrue ) Blocks broadcasts when client is set to \"Do not disturb\". blockBroadcastOnInMeeting Boolean (the default isfalse ) Blocks broadcasts when client is set to \"In a meeting\". notifyChatRoomAddMember Boolean (the default istrue ) Alerts users when a chat room has a new member. blockChatRoomNotifyOnDoNotDisturb Boolean (the default istrue ) Blocks chat room notifications the client to \"Do not disturb\". blockChatRoomNotifyOnInMeeting Boolean (the default isfalse ) Blocks chat room notifications when user is in a meeting. broadcastServerUserIdType String (the default isemail ) Specifies the LDAP attribute used as the user ID. useTokens Boolean (the default istrue ) Determines whether the client uses an LTPA token at login. Set this to false only if there is no way to set up Single Sign-On between the Sametime Community Server and the Sametime Advanced Server. chatRoomLaunchURLRichClient Boolean Specifies what type of chat room window the users sees. The value true represents the Sametime client chat room and the value false represents the web browser chat room. onlyActiveChatRooms Boolean (default value is false) Limits the chat room list to active chat rooms, suppressing disabled and archived chat rooms from the list. showToolTip Boolean (default value is true) Displays the description associated with a chat room when the user mouses over the chat room name. updateInterval String (default value is 600000 milliseconds, or 10 minutes) Specifies the wait (in milliseconds) before chat room data is refreshed. You can improve server performance by refreshing less frequently.Table 4. Community Preferences - com.ibm.collaboration.community
Attribute Variable type Description loginTokenRefreshInterval String (default value is 900000 milliseconds, or 15 minutes) LTPA token timeout in seconds. Best practice is to set this value to 5 minutes less than the token expiration time configured on the WebSphere server hosting Sametime Advanced, and on the Community Server. The value should be specified in milliseconds. For example, if the server-side token expiration timeout is 24 hours, configure loginTokenRefreshInterval=86100000 (which is 23 hours and 55 minutes) on the client.Parent topic: Sametime client preferences
"},{"location":"admin/config_client_status_pref.html","title":"Auto-status change preferences","text":"The following table lists the auto-status change preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release lockPCWithOSLock Boolean. Default is true. Available \"Locking computer with operating system lock\" feature. 7.5.1 and later keyboardMouseInactivity Boolean. Default is true. Available \"Keyboard and mouse inactivity\" feature. 7.5.1 and later whenIamInAOnlineMtg Boolean. Default is false. Available \"When I am in an online meeting\" feature. 7.5.1 and later selectStatusOnlyScreenShare Boolean. Default is false. Determines whether to select the \"Change my status only when I'm sharing my screen\" check box. 7.5.1 and later autoChangeMyStatusInMtg Boolean. Default is false. Determines whether to select the \"Automatically change my status\" radio button. Note that if this radio button is set as true, then the \"Prompt me before changing my status\" radio button will be UNavailable. If this is set as \"false\", the \"Prompt me before changing my status\" radio button will be available. After 7.5.1 and latercom.ibm.collaboration. realtime.imhub/ selectStatusOnly ScreenShare is set to true com.ibm.collaboration. realtime.imhub/ autoChangeMyStatus InMtg works for screen share status. minutesForIdleKeyboardMouse Integer. Default is 20 Sets the \"When I have not used my keyboard or mouse for the following number of minutes:\" text field. 7.5.1 and later backWhenUnlocked Boolean. Default is true. Determines whether to select the \"Return to previous status when activity is resumed\" in \"Locking computer with operating system lock\" check box. 7.5.1 and later backWhenKeyboardMouseActive Boolean. Default is true. Determine whether to select the \"Return to previous status when activity is resumed\" in \"Keyboard and mouse inactivity\" check box. 7.5.1 and later blRetrievalRetryDelay Integer. Default is 15000 ms. Determines how long the client waits before trying again to retrieve the contact list from the storage service if the initial attempt times out. The default is 15 seconds, expressed as milliseconds. 8.5.2 IFR1 and later Parent Topic: Sametime client preferences
"},{"location":"admin/config_client_update_interval_xml.html","title":"Changing the update interval for managed preferences","text":"To change the update interval for managed preferences, you can update the existingmanaged-settings.xml file.
By default, managed settings are updated every 12 hours and when the HCL\u00ae Sametime\u00ae Connect Client is started. To change the update interval, add a new setting group to the managed-settings.xml file.
Edit the managed-settings.xml file.
Add a new setting group that contains the UpdateIntervalInMins setting.
Verify that the following settings are set:
value : Specify the interval value in minutes. For example, for an update to occur every hour, specify value=\"60\".
isLocked : The value for this setting must be isLocked=\"false\".
<settingGroup name=\"com.ibm.rcp.managedsettings\"> \n <setting name=\"UpdateIntervalInMins\" value=\"interval\\_value\" isLocked=\"false\"/>\n</settingGroup>\nFor additonal information on the isLocked setting, seeDefining preferences in the managed-settings.xml file.
Parent Topic: Updating client preferences with the managed-settings.xml file
"},{"location":"admin/config_client_update_pref.html","title":"Update preferences","text":"The following table lists the update preferences for the HCL\u00ae Sametime\u00ae Connect Client and Sametime Embedded Client for Notes\u00ae.
Attribute Variable type Description Release firstTimeRestartDelayMinutes Integer. Default is 0. Defines how long to delay for the first prompt after an automatic update is completed. Prompts immediately by default. 8.5.2 and later restartAction restart.now - user is presented with a restart dialog with Restart Now button only.restart.now.or.later - user is presented with a restart dialog with Restart Now and Wait x minutes buttons.
restart.on.next.login - user is presented with an info message that the plug-in updates will be effected on next restart.
restart.now.no.prompt - the client is restarted automatically when update is completed without any user interaction.
Default is restart.now.or.later.
|Defines how restart should be initiated on the client after an update is completed. Note this preference is just valid for administrator-initiated updates, but be invalid for user's manual updates by Tools -> Plug-ins menu.|8.5 and later| |restartRemindDelayMinutes|Integer. Default is 5.|Defines how long to delay the restart of the client after an update is completed. This setting is ignored if restartAction is set to restart.now or restart.on.next.login.|8.5 and later|
Example entry in plugin_customization.ini:
com.ibm.collaboration.realtime.update/restartAction=restart.now.no.prompt\ncom.ibm.collaboration.realtime.update/restartRemindDelayMinutes=1 \nParent Topic: Sametime client preferences
"},{"location":"admin/config_client_url_xml_file.html","title":"Changing the URL for the settings XML file in the plugin_customization.ini file","text":"If you must change the URL for the managed settings file, do so by updating the plugin_customization.ini file.
Follow these steps to update the plugin_customization.ini file with the new file name or URL.
Verify that the settings XML file is in the location where it will be called from the plugin_customization.ini file.
In the plugin_customization.ini file, change the key that defines the Expeditor Managed settings framework and the name and location of the settings XML file.com.ibm.rcp.managedsettings.provider.file/URL and the name and location of the settings XML file to be used. For example:
com.ibm.rcp.managedsettings.provider.file/URL=http://sametime.example.com/demo/managed-settings.xml\nor\ncom.ibm.rcp.managedsettings.provider.file/URL=file://c:/data/managed-settings.xml\nThe next update runs with the old URL, but subsequent updates run with the new URL. If the new URL is not reachable at the time of the update, the setting will not be saved and the original URL will continue to be used. The URL will not be changed until it is updated at a time that the URL can be reached.
Parent Topic: Configuring Sametime Connect Client preferences in the plugin_customization.ini file
"},{"location":"admin/config_client_widg_pref.html","title":"Live Text and Widgets preferences","text":"The following scenarios show the Live Text and Widgets preferences for the HCL\u00ae Sametime\u00ae Connect Client. These scenarios apply to setting preferences for the stand-alone client.
Case 1 (default): Disable both Live Text and Widgets
This is the default scenario, set with the following preference in plugin_customization.ini:
com.hcl.rcp.toolbox.admin/toolboxvisibleMaster=false
Case 2: Enable both Live Text and Widgets
Enable both Live Text and Widgets by setting the following preference to true in plugin_customization.ini:
com.hcl.collaboration.realtime/enableSametimeLiveText=true
Note: This overrides the setting for toolboxvisibleMaster. You do not need to manually set toolboxvisibleMaster to true.
Case 3: Enable only Live Text, not Widgets
To enable only Live Text, managed preferences is required. Configure the following managed preferences:
<ManagedSettings>\n<settingGroup name=\"com.hcl.collaboration.realtime\">\n<!-- Enable live text support in Sametime -->\n<setting name=\"enableSametimeLiveText\" value=\"true\" isLocked=\"false\"/>\n</settingGroup>\n<settingGroup name=\"com.hcl.rcp.toolbox.admin\">\n<!-- Disable widget support in Sametime -->\n<setting name=\"toolboxvisible\" value=\"false\" isLocked=\"true\"/>\n<setting name=\"toolboxenableRecognizers\" value=\"true\" isLocked=\"true\"/>\n</settingGroup>\n</ManagedSettings>\nCase 4: Enable only Widgets, not Live Text
To enable only Widgets but not Live Text, managed preferences are required. Configure the following managed preferences:
<ManagedSettings>\n<settingGroup name=\"com.hcl.collaboration.realtime\">\n<!-- Disable live text support in Sametime -->\n<setting name=\"enableSametimeLiveText\" value=\"false\" isLocked=\"false\"/>\n</settingGroup>\n<settingGroup name=\"com.hcl.rcp.toolbox.admin\">\n<!-- Enable widget support in Sametime -->\n<setting name=\"toolboxvisible\" value=\"true\" isLocked=\"true\"/>\n<setting name=\"toolboxvisibleMaster\" value=\"true\" isLocked=\"true\"/>\n<setting name=\"toolboxenableRecognizers\" value=\"false\" isLocked=\"true\"/>\n</settingGroup>\n</ManagedSettings>\nParent topic: Sametime client preferences
"},{"location":"admin/config_client_xml_file.html","title":"Defining preferences in the managed-settings.xml file","text":"Follow these instructions to define preferences in a managed-settings.xml file.
All rules related to XML files apply. Additionally, the following items should be considered:
There is an example managed-settings.xml file attached to the troubleshooting article which can be used to test managed settings in place of creating a new one.
This procedure demonstrates how to create the managed-settings.xml and define chat history preferences for enabling automatically save chats for 7 days.
Procedure
Create a new file with UTF-8 encoding named managed-settings.xml.
Note: No other file names are supported.
Place the opening and ending statements in the file:
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n\n\n</ManagedSettings>\nIn between the <ManagedSettings> tags is where the settings must be defined. Thus the last line of the file should be </ManagedSettings>.
Review the settings that can be defined. For this example, the chat logging preferences should be changed.
Note: You can define other settings. This example is to only demonstrate the syntax.
Place the settingGroup tags in between the <ManagedSettings> tags.
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"\"> \n\n\n\n</settingGroup> \n\n</ManagedSettings> \nOn the preferences documentation pages, some tables provide the names of the settingGroup. For example, in the Chat Preferences, table 2 is for Chat History Preferences. The settingGroup name is com.ibm.collaboration.realtime.chat.logging. The settings that are used for this example are \u201cdays.storage.max\u201d and \u201clogging.default\u201d. These configure the user\u2019s client to automatically log all chats on the client-side and retain them for 7 days.
Place the name of the settingGroup in the <settingGroup name=\u201d\u201d> tag.
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\"> \n\n\n\n</settingGroup> \n\n</ManagedSettings> \nWhen you define the settings which are placed inside the settingGroup tags, there are several options. Refer to the table for the setting name.
In the example from above, the two settings used in the example are \u201cdays.storage.max\u201d and \u201clogging.default\u201d. These are defined in a tag called <setting name=\u201d\u201d value=\u201d\u201d/>. These lines are indented with two spaces.
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\"> \n\n <setting name=\u201dlogging.default\u201d value=\u201d0\u201d/> \n\n <setting name=\u201ddays.storage.max\u201d value=\u201d7\u201d/> \n\n</settingGroup> \n\n</ManagedSettings> \nYou can define settings from other settingGroups in the same file. Ensure that the formatting of spacing remains the same. For example, add a contact list preference to sort groups alphabetically by default. These settings are documented in the Contact list preferences topic.
Open the help center topic and locate the settingGroup name.
Locate the setting name.
Add the new settingGroup and setting names below the first settingGroup.
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\"> \n\n <setting name=\u201dlogging.default\u201d value=\u201d0\u201d/> \n\n <setting name=\u201ddays.storage.max\u201d value=\u201d7\u201d/> \n\n</settingGroup> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.imhub\"> \n\n <setting name=\u201dsortGroups\u201d value=\u201dtrue\u201d/> \n\n</settingGroup> \n\n</ManagedSettings> \nEnable optional features.
The settingGroup tag has an attribute called lastModDate which when present every change to a setting group must also be accompanied by a change to the lastModDate attribute or the new values are not updated. If you do not use the lastModDate attribute, the values are always updated, even if they are not new.
The format for the lastModDate value uses java.text.SimpleDateFormat timestamp format. The syntax is
YYYYMMDDThhmmss\n, where YYYY=year, MM=month, DD, hh=hours, mm=minutes, and ss=seconds. The values following the T are optional.
For example:
<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\" lastModDate=\u201d2021-02-11T17:39:21-05\u201d> \n\n <setting name=\u201dlogging.default\u201d value=\u201d0\u201d/> \n\n <setting name=\u201ddays.storage.max\u201d value=\u201d7\u201d/> \n\n</settingGroup> \n\n</ManagedSettings> \nEach <setting> tag can have the following optional attributes:
isLocked : Boolean. The default value is true. If true, the setting is read-only and any changes that a user or application make to the value set by you, the administrator, are prevented or later overwritten. If this attribute is set to false, the administrator's setting is treated as a default value that can be changed by the user.
``` {#codeblock_i5l_5fp_jzb}\n<?xml version=\"1.0\"?> \n\n<ManagedSettings> \n\n<settingGroup name=\"com.ibm.collaboration.realtime.chat.logging\"> \n\n <setting name=\u201dlogging.default\u201d value=\u201d0\u201d isLocked=\u201dfalse\u201d/> \n\n <setting name=\u201ddays.storage.max\u201d value=\u201d7\u201d isLocked=\u201dtrue\u201d/> \n\n</settingGroup> \n\n</ManagedSettings> \n```\n\nIn the above example, all chats are saved automatically initially until the user changes the setting, and the chat history is retained for 7 days. Users are not able to change this setting because it is locked.\noverwriteUnlocked : Boolean. The default value is false. By default, a setting that is specified as being unlocked is treated as a default and would not overwrite any existing value on the client. This is to avoid undoing changes that the user might have legitimately made. However, if this setting is set to true, the unlocked value is overwritten with this new value even if it means clearing the user's existing value.
overwriteUnlocked : Boolean. The default value is false. By default, a setting that is specified as being unlocked is treated as a default and would not overwrite any existing value on the client. This is to avoid undoing changes that the user might have legitimately made. However, if this setting is set to true, the unlocked value is overwritten with this new value even if it means clearing the user's existing value.
restartRequired : Boolean. The default value is false. This attribute applies only when you automatically update client preferences with the managed-settings.xml file. Setting this to true creates a user prompt to restart the client as soon as the managed setting is applied. Use this optional attribute only if a restart of the client is required to activate the preference. The restart occurs only if the setting that includes this attribute is updated.
Test the managed-settings.xml file for formatting errors. Open the file in a web browser and ensure that there are no syntax errors. If errors are present, edit the file and correct the syntax problem.
Deploy managed-settings.xml or managed-community-configs.xml file to a web server.
Parent Topic: Updating client preferences with the managed-settings.xml file
"},{"location":"admin/config_client_xml_location.html","title":"Updating client preferences with the managed-settings.xml file","text":"Sametime rich clients such as the embedded Sametime client in HCL Notes and the full Sametime standalone client are based upon the Eclipse framework. These clients can process a managed-settings.xml file to receive new or updated preferences automatically. The managed-settings.xml file is policy based, and each policy can define a different xml file to apply preferences to different groups of users.
Use a managed-settings.xml file to manage and define client preferences. The file is hosted on a web server. At login time, the client receives policies then checks for the existence of the managed-settings.xml file according to the \"Sametime\u00ae update site URL\" policy.
For example, if the configured URL is http://example.com/updates, the client looks for updated preferences in http://example.com/updates/managed-settings.xml.
The managed-settings.xml file can override and control any client preference, including hidden configuration preferences and preferences in the client user interface. Many preferences can also be set as read-only by specifying a locked=\"true\" attribute for the preference.
The client settings which can be managed using managed-settings.xml are listed in Sametime client preferences as well as its subtopics.
There is a separate configuration file: managed-community-configs.xml which is used to manage or change client connectivity and connection preferences. See the topic: Updating connectivity settings with the managed-community-configs.xml file.
Note: Sametime embedded clients for Notes can also be managed through the Domino\u00ae Desktop policy settings document.
Follow these steps to create and post a managed-settings.xml file.
Create a settings XML file and save it as managed-settings.xml.
Define preferences in the settings XML file.
Place the managed-settings.xml file on a web server to host the file.
Update the Sametime Policy for the user in the policies.user.xml file.
Changes take effect the next time the user starts Sametime. Settings found in the managed-settings.xml take precedence over matching settings in the plugin_customization.ini file.
To test changes in a managed-settings.xml file, create a policy set that includes the administration update site URL and place the .xml file in the location specified by the update site URL. Apply the policy to yourself and log in to the client to verify the preferences.
To troubleshoot managed settings, see Troubleshooting Sametime Managed Settings.
Parent Topic: Configuring Sametime client preferences with the Expeditor managed settings framework
"},{"location":"admin/configuration_files.html","title":"Configuration files","text":"Configuration files maintain information used by the Sametime server for various reasons.
Override the defaults of the Sametime community container or pod.
In Sametime v12, configuration files are generated on demand based on information in the Docker or Kubernetes container management configuration file.
File Name Environment Description sametime.ini Kubernetes Docker Sectioned configuration file used by the Sametime server. It is generated on demand based on values in custom.env or values.yaml files. Settings can be over-ridden if needed. Note: The file must conform to the XML syntax rules. StCommunityConfig.xml Kubernetes Docker Contains LDAP settings and more. Note: In versions previous to V12 this file was named stconfig.nsf. UserInfoConfig.xml Kubernetes Docker Contains configuration data for business cards. Note: The file must conform to the XML syntax rules. Policies.server.xml Kubernetes Docker Policies.user.xml Kubernetes Docker Clustering KubernetesNote: In releases prior to version 12, there are several configuration files used by different Sametime servers.
Configuration values can be modified. Where a modification can be done it is covered in the appropriate topic. For example, updates to LTPA keys are covered in the Setting up SSO using LTPA topics.
Parent Topic: Administering
"},{"location":"admin/configuring.html","title":"Configuring","text":"This section provides information on configuring the HCL Sametime server. Configuration tasks are dependent on the deployment environment.
Sametime supports LDAP directory servers as the user repository.
The default LDAP configuration works for most environments. The settings are based on an Domino LDAP deployments that has not been modified. If using another LDAP environment, you might need to override the default settings.
You can customize how the Sametime server interacts with LDAP by modifying the StCommunityConfig.xml file located in the Community container. The UserInfoConfig.xml file also contains LDAP settings that can be customized for business cards.
For LDAP security, see the security section of the help center.
Note that when modifying XML files, it is important to keep the indentation preserved and not use any illegal XML characters including in passwords. Do not use copy and paste into the XML files, it might corrupt the files.
When using the StCommunityConfig.xml and UserInfoConfig.xml files to override default setting, the LDAP bind credentials are stored in these files. If the bind account password changes, these files need to be updated too. To change the bind password in these files, see Changing the LDAP service account password in Kubernetes.
You can customize the following:
The following table describes the configuration settings.
Setting Description Default setting DirRefreshInterval The amount of time users and groups are refreshed. The refreshed data is maintained in a cache. This cache can be a resource intensive operation for large directories and can be adjusted to happen at a less frequent interval. For example, if you have more than 200,000 entries in the directory, consider changing this to 240 minutes. 60 minutes ConfigRefreshInterval The amount of time that lapses before policy, sametime.ini, UserInfoConfig.xml and StCommunityConfig.xml files are re-read. There is typically no need to change this setting. 60 minutes Connection HostName The fully qualified host name of the LDAP server. If you are using a cluster, it is recommended to place a load balancer in front of the cluster and use the load balancer host name or IP address. The value for this setting is obtained from the values.yaml file. It is placed there when prompted during the prepareDeployment script. OrganizationName Do not specify. This setting is deprecated. Do not change. Note: Specifying a value might prevent users from logging in successfully. Port The unsecured LDAP port, if you are using an unsecure connection to LDAP. If an unsecured LDAP is specified when running prepareDeployment.sh, the port specified at the script prompt is used. If secure LDAP was specified, the default value is 1389. BindEntryDn The LDAP Bind account name, which can be in DN or email format. This is blank unless a value is provided during the prepareDeployment.sh, and then it is retrieved from the sametime-global-secrets. BindEntryPassword The password for the BindEntryDn. Blank or retrieved from sametime-global-secrets. SSLEnabled 0 Turn off SSL. The value for this is provided during prepareDeployment.sh and is pulled from values.yaml file. 1 Turn on SSL. SSLPort The LDAP secure port. The well-known port is 636, but some LDAP services use a proprietary port. This selection is made during the prepareDeployment.sh and is pulled from the values.yaml file. SearchOrder The order in which LDAP directories are searched. Do not change this value unless you have more than one LDAP server to configure. Each search order must be unique. PersonResolveBase The base DN used for searching users. If users are in a specific OU, you can list that OU and Sametime begins searching there. For example, if users are in OU=users,O=example, you can set this as your PersonResolveBase. None. The entire directory is searched. PersonResolveFilter The filter used to search LDAP when a user searches with Quickfind. (&(objectclass=organizationalPerson)(|(cn=%s*)(givenname=%s*)(sn=%s*)(mail=%s*))) PersonResolveScope The scope of the search. 'recursive (searches nested OUs)' recursive Search the entire directory recursively starting at the base DN. onelevel Search the base DN and not search OUs. GroupResolveBase The base DN for searching groups. For example if your groups are in a specific OU, you can list that OU and Sametime will begin searching there. For example if your groups all exist in OU=groups,O=example, you can use that as a base DN. None Note: Domino LDAP groups are flat and you should not use a GroupResolveBase if using Domino LDAP. GroupResolveFilter The filter used to resolve a group name to a group. The name of the objectClass used by Domino uses for groups is groupOfNames. Other LDAP providers might use a different name, such as groupOfUniqueNames. This filter is used when clients add groups to contact lists, or when Sametime clients calculate their policy. (&(objectclass=groupOfNames)(cn=%s*)) GroupResolveScope The scope of a search. recursive recursive Search all nested OUs. onelevel Searchonly the base DN. UserIdAttribute Defines the Sametime ID. The DN is used as the default NameAttribute The attribute used to display the user\u2019s name in meetings, chat and business cards. cn DescAttribute This setting is not used and should be left blank. None, do not change. GroupNameAttribute The name of the attribute that holds the group\u2019s name. cn PersonObjectClass The object class that defines a person in the LDAP directory. organizationalPerson GroupObjectClass The object class that defines a group in the LDAP directory. groupOfNames HomeServerAttribute Does not apply to version 12.0 and higher deployments. None UserDnSearchFilter The filter to resolve a user to a unique DN. Use this to customize how Sametime searches and finds a user and resolves them to their DN. \"(&(objectclass=organizationalPerson)(|(cn=%s)(givenname=%s)(sn=%s)(mail=%s)))\" GroupMemberAttribute The name of the attribute that holds the members of a group. Member EmailAttribute The name of the attribute that holds the email address. Mail GroupMembership The resolve filter used by policies to determine if a user is a member of a group. It might be more performant to change this to the memberOf attribute in lieu of a search. \"(&(objectclass=groupOfNames)(member=%s))\"Parent Topic: Configuring
"},{"location":"admin/configuring_ldap_kubernetes.html","title":"Overriding the default LDAP configuration in Kubernetes","text":"Configuration settings can be overridden using the extra-community-config secret.
You can override the default LDAP configuration settings with the StCommunityConfig.xml file and UserInfoConfig.xml file using a secret called extra-community-config.
If you do not need to modify the UserInfoConfig.xml file it does not need to be included in the secret If you need to modify the UserInfoConfig.xml file, you must also include the StCommunityConfig.xml file as well.
Create a directory on your machine called extra-community-config at the root of where the Sametime installation package was decompressed.
Change to the extra-community-config directory.
Find the Community pod name by running the get pods command.
The pod name has hashes in it. For example: community-77d4695988-2bzrx.
kubectl get pods\nPull a copy of the StCommunityConfig.xml from the Community pod by running the below command, where podname is the pod name found in the previous step.
kubectl exec -it podname --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nFor example, if the Community pod name is community-845d5d5755-z7zf7, the command to run is
kubectl exec -it community-845d5d5755-z7zf7 --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nPull a copy of the UserInfoConfig.xml file from the Community pod, by running the below command. Substitute the name of your Community pod for podname.
kubectl exec -it podname --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml \nFind the base64 encoded value of your bind credentials. If you are using an authenticated bind, issue the following command in a Linux shell that contains your user name and password separated by a colon.
The resulting value is used in a later step.
echo -n \u201cusername:password\u201d | base64 -d\nIf the Bind DN is CN=bind,O=Example and the password is password, then the command is:
echo -n \u201cCN=bind,O=Example:password\u201d | base64 -d \nOpen the local copy of the UserInfoConfig.xml for editing.
Update the configuration settings.
Configure the desired custom settings in the StCommunityConfig.xml and UserInfoConfig.xml files. See Configuring LDAP for configuration settings.
Use the Change Directory command to change to the extra-community-config directory that was created earlier. Run the following command to create the secret.
kubectl\u202fcreate secret generic extra-community-config --from-file=./ \nIf you have a namespace dedicated to Sametime add the -n argument with your namespace to ensure it is created in the correct namespace.
Change to the helm directory where the Sametime installation package was decompressed.
Open the values.yaml file and place in edit mode. Add the following line.
overrideCommunityConfigSecret: extra-community-config\nSave and close the file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Configuring LDAP
"},{"location":"admin/configuring_ldap_multiple_docker.html","title":"Configuring additional LDAP servers on Docker and Podman","text":"You can configure the Sametime server to connect to two or more LDAP servers.
When you connect to more than one LDAP server, it is important for the names to be unique. If you are trying to achieve high availability to the same directory, use a load balancer to front-end the connection between the multiple LDAP servers.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
When more than one LDAP is defined in an environment, they are searched in the order defined in the StCommunityConfig.xml and UserInfoConfig.xml files. When you define each LDAP server, the order in which they are listed in the configuration is the same order in which they are searched.
The process described in this procedure involves copying the StCommunityConfig.xml and UserInfoConfig.xml files from the Sametime community (chat) container. These copied configurations overrides the default LDAP configuration settings. The LDAP servers are defined within each configuration file.
Docker-compose commands are used to pull the existing configuration files from the Sametime server to your local machine. Modify these files locally with the required settings, then add a volume under the community section of the docker-compose.yml file to enable the modified settings.
This procedure is to configure Sametime to connect to two or more separate LDAP servers that have unique names.
Change to the sametime_installation_directory directory.
Identify the chat-server container ID by running the command 'docker container ls' and finding the chat-server IMAGE. The NAME is the container name, as an example: sametime-community-1.
Pull a copy of the StCommunityConfig.xml and UserInfoConfig.xml from the chat-server container by running the below command, where container_name is the container name for the chat-server identified in step 2.
docker cp <container_name>:/local/notesdata/UserInfoConfig.xml . \ndocker cp <container_name>:/local/notesdata/StCommunityConfig.xml .\nFind the base64 encoded value of your bind credentials. If you are using an authenticated bind, issue the following command in a Linux shell that contains your user name and password separated by a colon. The resulting value is used in a later step.
echo -n \u201cusername:password\u201d | base64 -d\nIf the Bind DN is CN=bind,O=Example and the password is password, then the command is:
echo -n \u201cCN=bind,O=Example:password\u201d | base64 -d \nOpen your local copy of the UserInfoConfig.xml file for editing.
Duplicate the line that begins with StorageDetails.
The order in which you list your StorageDetails statement is the search order to be used.
HostName : The fully qualified host name or IP address of the second LDAP server.
Port : If using unsecured LDAP, specify the port number used by LDAP. If you are using secure LDAP, you don't need to modify this field.
UserName : Set this field to empty double-quotes ( \u201c\u201d ).
Password : Set this field to empty double-quotes (\u201c\u201d). If using an authenticated bind, add a new parameter after UserName and Password called UserEncodedAuth= and set it to the value that was determined in a previous step.
BaseDN : Define a base DN for searching the directory. If left blank, the entire directory is searched.
SearchFilter : SearchFilter Modify the search filter if needed. The defaults work well with Domino LDAP.
You can make other changes to the business cards configuration if needed at this time.
When finished, save and close the UserInfoConfig.xml file.
Edit the StCommunityConfig.xml file with a text editor and make the following changes.
Within the <LDAP> section, duplicate the line that begins with <Connection Hostname.
Modify the new line to contain the details of the second LDAP server.
Modify the SearchOrder parameter for the additional LDAP server to a unique number. This must match the search order you selected for UserInfoConfig.xml.
Save and close the StCommunityConfig.xml file.
Edit the docker-compose.yml by adding the following under the community section:
volumes:\n - ./StCommunityConfig.xml:/local/notesdata/StCommunityConfig.xml\n - ./UserInfoConfig.xml:/local/notesdata/UserInfoConfig.xml \nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Configuring LDAP
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html","title":"Configuring additional LDAP servers on Kubernetes","text":"You can configure the Sametime Community pod to connect to two or more LDAP servers.
When you connect to more than one LDAP server, it is important for the names to be unique. If you are trying to achieve high availability to the same directory, use a load balancer to front-end the connection between the multiple LDAP servers.
When more than one LDAP is defined in an environment, they are searched in the order defined in the StCommunityConfig.xml file. When you define each LDAP server, the order in which they are listed in the configuration is the same order in which they are searched.
The process described in this procedures involves creating a new secret called extra-community-configs. This secret overrides the LDAP configuration settings in the values.yaml file. The extra-community-configs secret contains a copy of the configuration files used by the Community pod. The LDAP servers are defined within each configuration file. For more information on secrets, see Managing secrets in Kubernetes.
kubectl commands are used to pull the existing file from the Community pod to your local machine. Modify these files locally with the required settings, then create the secret containing the files.
This procedure is to configure Sametime to connect to two or more separate LDAP servers that have unique names.
Note: If you have already created a secret for extra-community-config, you can copy the UserInfoConfig.xml file from the pod to the extra-community-config directory and recreate the secret with the other required files.
The changes in this task affect the Community pods:
Create a directory on your machine called extra-community-config at the root of where the Sametime installation package was decompressed.
Change to the extra-community-config directory.
Find the Community pod name by running the get pods command.
The pod name has hashes in it. For example: community-77d4695988-2bzrx.
kubectl get pods\nPull a copy of the StCommunityConfig.xml from the community pod by running the below command, where podname is the pod name found in the previous step.
kubectl exec -it podname --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nFor example, if the Community pod name is community-845d5d5755-z7zf7, the command to run is
kubectl exec -it community-845d5d5755-z7zf7 --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nPull a copy of the UserInfoConfig.xml file from the Community pod, by running the below command. Substitute the name of your Community pod for podname.
kubectl exec -it podname --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml \nFind the base64 encoded value of your bind credentials. If you are using an authenticated bind, issue the following command in a Linux shell that contains your user name and password separated by a colon.
The resulting value is used in a later step.
echo -n \u201cusername:password\u201d | base64 -d\nIf the Bind DN is CN=bind,O=Example and the password is password, then the command is:
echo -n \u201cCN=bind,O=Example:password\u201d | base64 -d \nUse a text editor to open your local copy of UserInfoConfig.xml in edit mode.
Duplicate the line that begins with StorageDetails.
The order in which you list your StorageDetails statement is the search order to be used.
Configure your second LDAP server by completing the fields:
Edit the StCommunityConfig.xml file with a text editor and make the following changes.
Within the <LDAP> section, duplicate the line that begins with <Connection Hostname.
Modify the new line to contain the details of the second LDAP server.
Modify the SearchOrder parameter for the additional LDAP server to a unique number. This must match the search order you selected for UserInfoConfig.xml.
Save and close the file.
Change to the extra-community-config directory that was created earlier. Run the following command to create the secret.
kubectl\u202fcreate secret generic extra-community-config --from-file=./ \nIf you have a namespace dedicated to Sametime add the -n argument with your namespace to ensure it is created in the correct namespace.
Change to the helm directory where the Sametime installation package was decompressed.
Open the values.yaml file and place in edit mode. Add the following line.
overrideCommunityConfigSecret: extra-community-config\nSave and close the file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Configuring LDAP
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#hostname","title":"HostName","text":"The fully qualified host name or IP address of the second LDAP server.
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#port","title":"Port","text":"If using unsecured LDAP, specify the port number used by LDAP. If you are using secure LDAP, you don't need to modify this field.
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#username","title":"UserName","text":"Set this field to empty double-quotes ( \u201c\u201d ).
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#password","title":"Password","text":"Set this field to empty double-quotes (\u201c\u201d). If using an authenticated bind, add a new parameter after UserName and Password called UserEncodedAuth= and set it to the value that was determined in a previous step.
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#basedn","title":"BaseDN","text":"Define a base DN for searching the directory. If left blank, the entire directory is searched.
"},{"location":"admin/configuring_ldap_multiple_kubernetes.html#searchfilter","title":"SearchFilter","text":"Modify the search filter if needed. The defaults work well with Domino LDAP.
You can make other changes to the business cards configuration if needed at this time. When finished, save and close the file.
"},{"location":"admin/configuring_ldap_password.html","title":"Changing the LDAP service account password in Kubernetes","text":"If you are using an authenticated bind for LDAP, with a password that expires periodically, you'll need to update the LDAP bind credentials for Sametime clusters in Kubernetes with a new password.
The LDAP bind credentials are Base64 encoded and defined in the configuration as secrets. When updating the password, you'll need to complete the following tasks:
Update the bind credentials in the Kubernetes secrets.
The LDAP bind credentials are located in Kubernetes secrets:
sametime-global-secretsextra-community-config (optional) There is an optional configuration to override the default settings for LDAP and for business cards in a secret called extra-community-config. If you have implemented this secret, the LDAP Bind credentials must be updated in the XML configuration files and the extra-community-config secret should be deleted and recreatedThe changes in this task affect the following pods:
Community
Find the Base64 encoded values of your credentials.
If your LDAP DN is changing, you need to Base64 encode the complete DN.
For example, if your LDAP DN is CN=SametimeBind,O=Example take your DN and run the below command:
echo -n \u201cCN=SametimeBind,O=Example\u201d | base64\nFor this example, the resulting value is shown below and must be configured for the LdapBindEntryDn parameter in the sametime-secrets.yaml file.
LdapBindEntryDn: 4oCcQ049U2FtZXRpbWVCaW5kLE89RXhhbXBsZeKAnQ== \nIf your LDAP bind password is changing, you need to base64 encode the password.
For example, if your password is thepassword, then run the below command to base64 encode it:
echo -n \u201cthepassword\u201d | base64\nThe resulting value is used in your configuration for the password.
Now find the base64 encoded value of the two settings combined, separated by a colon.
For example if your Bind DN is CN=SametimeBind,O=Example and the password is thepassword then find the base64 encoded value of CN=SametimeBind,O=Example:thepassword:
echo -n \u201cCN=SametimeBind,O=Example:thepassword\u201d | base64 \nUpdate the secret for sametime-global-secrets.
Edit the sametime-global-secrets file. Run the following command.
kubectl edit secret sametime-global-secrets\nLocate LdapBindEntryDn and LdapBindEntryPassword in the helm/templates/sametime-secrets.yaml file. Set their values to the base64 encoded value of your name and password respectively.
LdapBindEntryDn: base64\\_encoded\\_DN \nLdapBindEntryPassword: base64\\_encoded\\_password\nSave and close the file.
Press Esc, w, q, ! on the keyboard to save your changes.
Update the extra-community-config secret.
Determine if there is already a extra-community-config secret by issuing the following command.
kubectl get secrets \nIf you are using a namespace for Sametime, you must include the -n namespace argument on the command to view the secrets scoped to the Sametime namespace.
If there is a secret, delete it. Otherwise skip to the next step.
Run the following command to delete the secret.
kubectl delete secret extra-community-configs\nCreate a new directory named extra-community-configs on the machine that is used to run kubectl commands.
Change directories to the extra-community-configs you just created.
Locate the pod name of the Community pod to be used in the next step by running following the command.
kubectl get pods\nThe name has hashes in it, for example: community-845d5d5755-z7zf7.
Pull a copy of the StCommunityConfigs.xml from the Community pod by running the below command, where podname is the Community pod name found in the previous step.
kubectl exec -it podname --container community -- cat /local/notesdata/StCommunityConfig >./StCommunityConfig.xml \nFor example, if the Community pod name is community-845d5d5755-z7zf7, the command to run is
kubectl exec -it community-845d5d5755-z7zf7 --container community -- cat /local/notesdata/StCommunityConfig.xml >./StCommunityConfig.xml \nPull a copy of the UserInfoConfig.xml file from the Community pod, by running the below command. Substitute the name of your Community pod for podname.
podname: kubectl exec -it <podname> --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml \nFor example, if the Community pod name is community-845d5d5755-z7zf7, the command to run is
kubectl exec -it community-845d5d5755-z7zf7 --container community -- cat /local/notesdata/UserInfoConfig.xml >./UserInfoConfig.xml \nAfter adding the two files to your machine, the new LDAP DN and password must be defined. Open the local copy of the StCommunityConfig.xml file using a file editor.
Locate the parameters to be changed and set them to their actual unencoded values. Do not specify the base64 encode values.
BindEntryDn= to the Bind DNBindEntryPwd= set to the new Bind password Save and close the file.Open the UserInfoConfig.xml file. Next change the UserEncodedAuth value.
Locate UserEncodedAuth in the file.
Change the current value to the base64 encoded values of the DN and password.
Combine the two values with a colon (:) between them. For example:
echo -n DN:password echo -n 'DN:password' | base64\nSave and close the file.
Create the extra-community-configs secret by issuing the following command.
kubectl create secret generic extra-community-config --from-file=./\nUpdate the configuration files.
If you did not have an extra-community-configs secret before you must update the values.yaml file for Sametime to use the secret.
Change to the helm directory, where the Sametime installation image was unzipped.
Open the values.yaml file with a text editor.
Add the following parameter to the global section.
overrideCommunityConfigSecret: \"extra-community-config\"\nSave and close the file.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Configuring LDAP
"},{"location":"admin/configuring_multi_tenacy.html","title":"Enabling multi-tenancy","text":"Multi-tenancy allows multiple organizations to be part of the Sametime community. With multi-tenancy, Sametime users can chat, add users and groups to contact lists, and have awareness of users in their organization or in other organizations that are configured to be visible to them.
The following conditions must be satisfied:
Ensure that users from all organizations reside under one tree, with multiple branches. For example, if the base DN is CN=ORGANIZATIONS,OU=COLLAB,DC=HCL,DC=COM, then an individual organization would be found at the following baseDN:
O=Organization A,CN=ORGANIZATIONS,OU=COLLAB,DC=HCL,DC=COM \nO=Organization B,CN=ORGANIZATIONS,OU=COLLAB,DC=HCL,DC=COM\nAdditionally, each user\u2019s entry in LDAP must contain an attribute that also contains the name of the organization that the user belongs to. For example, you can create an attribute called \u201corganizationName\u201d and the value set to the name of the organization:
organizationName=Organization A\nNote: For multi-tenant deployments, orgID in versions 12.0 and 12.0.1 does not support the dash ( -) character for Sametime Meetings.
By default, the multi-tenancy feature is disabled. This feature uses customized Java\u2122 code to dynamically generate a filter and base distinguished names for LDAP searches. The multi-tenancy feature is configured by running the setupMultitenancy.sh script.
The setupMultitenancy.sh script prompts for details from the LDAP configuration. Review your LDAP base DNs to determine which values should be used.
Complete the worksheet below to assist in completing the configuration:
Setting Name Description Example Your Value Base DN The top of your LDAP tree\u2014where to start searching the directory. CN=ORGANIZATIONS,OU=COLLAB, DC=HCL,DC=COM Organization BaseDN Thhe location of the individual organizations. O=Organization A,CN=ORGANIZATIONS, OU=COLLAB,DC=HCL,DC=COM \ufeffORG_PART_OF_DN The attribute in the LDAP DN that contains the organization name. O \ufeffPEOPLE_ROOT_BASE_DN The DN of the entry where to start searching for people. It should contain the lowest LDAP entry under which the entries of all the people in the organization are available. O=%S,CN=ORGANIZATIONS, OU=COLLAB,DC=HCL,DC=COM \ufeffGROUPS_ROOT_BASE_DN The DN of the entry where to start searching for groups. It should contain the lowest LDAP entry under which the entries of all the people in the organization are available. O=%S,CN=ORGANIZATIONS, OU=COLLAB,DC=HCL,DC=COM \ufeffPEOPLE_BASE_DN_TEMPLATE \ufeffThe DN of the entry at which to start the people or the groups LDAP search when the search is done in a sub tree of a particular organization. %S should always be present in the value. It is dynamically replaced by the organization name during the resolve operation. O=%S \ufeffGROUPS_BASE_DN_TEMPLATE The DN of the entry at which to start the people or the groups LDAP search when the search is done in a sub tree of a particular organization. %S should always be present in the value. It is dynamically replaced by the organization name during the resolve operation. O=%S \ufeffLDAP_ORG_ATTR \ufeffThe attribute in the LDAP directory that is present in every person and group entry and contains the organization name that this person or group belongs to. ORGANIZATIONNAMEChange directories to where the Sametime installation files are extracted. Then run setupMultitenancy.sh and follow the prompts to provide the required information.
When successful, do either of the following.
Parent Topic: Administering
"},{"location":"admin/configuring_sso_saml.html","title":"Configuration settings related to SAML authentication","text":"You can override default configuration settings in the sametime.ini file. Note that the settings are implemented differently depending on the platform: Docker, Podman, Kubernetes, and Openshift.
For details on configuring these parameters, see Configuring the sametime.ini file.
If the Sametime server is running when you set or modify a sametime.ini file setting, the setting takes effect after you restart the Sametime server.
The following sections, describe optional configuration settings to use with SAML authentication.
"},{"location":"admin/configuring_sso_saml.html#fips-140-2-compliance","title":"FIPS 140-2 compliance","text":"The default Sametime configuration is not FIPS 140-2 compliant. If your Sametime deployment requires FIPS 140-2 compliance, set FIPS 140-2 compliance to true in the TLS configuration, under the Server application connections column. This affects both TLS and SAML. For more information about applying settings in a TLS configuration, see Implementing the Global TLS Scope.
"},{"location":"admin/configuring_sso_saml.html#security-level","title":"Security level","text":"The default configuration imposes no restrictions on the use of cryptographic algorithms and certificate strength. If strong cryptography is required, change the Minimum security level setting in the TLS configuration, in the Server application connections column. This affects both TLS and SAML. For more information about applying settings in a TLS configuration, see Implementing the Global TLS Scope.
Alternatively, you can override the default values by configuring the sametime.ini file.
STI__Config__STSAML_SECURITY_LEVEL=numeric value between 0 and 4, inclusive \nA value of 0 implies no restriction on the cryptographic algorithms or certificate strength. The higher the value, the stronger the security level enforcement. Any security strength higher than 0 causes SAML validation to fail in case the SAML signature validation involves weak cryptography that does not comply with the minimum security level. For a list of available security levels, see Implementing the Global TLS Scope.
"},{"location":"admin/configuring_sso_saml.html#trusted-audiences","title":"Trusted audiences","text":"The SAML identity provider (IdP) might optionally address the assertion to a limited set of audiences. This information is included in the assertion element, according to the SAML standard, and typically contains one or more URLs that identify the trusted audiences. By default, Sametime ignores this information, and validates the assertion whether or not the Sametime Community Server is a member of the specified audiences. If the trusted audiences setting is present in a configuration, and the assertion contains a trusted audience condition, the Community Server matches the assertion audience condition against the trusted audiences setting, and validation fails if there is no match. The trusted audiences are set in the sametime.ini file.
STI__Config__STSAML_TRUSTED_AUDIENCES=trusted-audiences\nThe value of this setting is a comma-separated list of one or more host names. Each audience in the assertion condition is matched against each trusted audience in the configuration. At least one match is needed for passing the condition. Audience matching is performed by comparing the host portion of the audience URL to the host name in the configuration. If the strings are equal (ignoring letter case) there is a match. It is possible to set a trusted-audience string with wild card domain components, using the asterisk character (*) to represent a wild card domain component. For example, this setting uses the asterisk.
STI__Config__STSAML_TRUSTED_AUDIENCES=*.example.com \nAnd the following audience condition in the SAML assertion:
<saml:Audience>https://sametime.example.com/saml/<saml:Audience> \nGiven this configuration and audience condition, matching passes, because sametime.example.com matches *.example.com. In another example, sametime.example.com would not match *.com because the number of domain components is different. That is sametime.example.com contains three components, while *.com contains two.
The SAML authentication token contains a SAML response element, which in turn contains a child assertion element. According to the SAML standard, either element can be signed. The default Sametime configuration does not require a valid response signature if the underlying assertion has a valid signature. You can change the Sametime server to require a valid response signature, regardless of the underlying assertion signature, by setting the sametime.ini parameter. STI__Config__STSAML_REQUIRE_SIGNED_RESPONSE=1
Parent Topic: Setting up SSO using SAML
"},{"location":"admin/configuring_stun.html","title":"Configuring alternate STUN servers","text":"Sametime Meetings uses public Google STUN servers by default. To use different STUN servers, you must complete this procedure before installing Sametime Meetings.
For more information about STUN, see Session Traversal Utilities for NAT (STUN)
Kubernetes
To configure alternate STUN servers if you use Kubernetes, edit the following file:
heml/values.yaml \nChange the following line to refer to your preferred servers, following the same pattern.
jvbStunServers: stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302\nDocker
To configure alternate STUN servers if you use Docker, edit the following file:
.env\nChange the following line to refer to your preferred servers, following the same pattern.
# STUN servers used to discover the server's public IP.\nJVB_STUN_SERVERS=stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302\nParent Topic: Configuring
"},{"location":"admin/connections_photos.html","title":"Using HCL Connections photos for the Sametime business card","text":"You can use the HCL Connections profiles photos for the Sametime business cards. A benefits for using this method is that updated photos in Connections are automatically updated in Sametime.
Calculating the Connections Profiles Photo URL
The Connections user photo can be retrieved from /profiles/photo.do API (REST: GET) which can process different key values from the parameter sent to uniquely identify the user details. <protocol>://<connections server>:<port>/profiles/photo.do?parametername=value
The following parameters can be included on the API.
This configuration depends on which unique user identifier (userId) has been configured in the LDAP settings. The default setting is distinguishedName.
In many cases the Sametime server is configured to use the DN as the Sametime userId. For example: the DN is: CN=Foo Bar,OU=Users,O=Example,C=US In this case the distinguishedName key should be used. The protocol is either HTTP or HTTPS. For example:
http://connections.example.com:9080/profiles/photo.do?distinguishedName= \nIf the Connections server protocol is HTTP and the port is 9080, below is an example of the resulting URL after appending the user\u2019s DN and encoding the spaces:
http://connections.example.com:9080/profiles/photo.do?distinguishedName=CN%3DFoo%20Bar%2COU%3DUsers%2CO%3DExample%2CC%3DUS \nThe community service requires the absolute URL to be added to the person document or LDAP record as an attribute. Many LDAP servers including Domino LDAP and Microsoft Active Directory have an attribute that exists for this purpose called photoURL. Populate the full URL for the photo in the photoURL for each person record in the directory. For Domino LDAP directories, the photoURL is located on the person document, Miscellaneous tab.
Some LDAP servers may not display the photoURL attribute to an anonymous bind, for example, Domino LDAP. Use an authenticated bind to the LDAP server when configuring LDAP services, or configure the LDAP server to render the photoURL to anonymous users.
If the photoURL is a protected resource, Single Sign On (SSO) must be configured between the Sametime serve and Connections server. If the URL is available to anonymous users, SSO is not required.\u00a0 When configuring SSO, the Connections server and Sametime server must share a common directory. For additional information, see Configuring SSO between Connections and Sametime.
If you have not already configured the UserInfoConfig.xml file, review the applicable topic for your environment and complete the configuration before setting the photoURL.
Parent Topic: Setting up business cards
"},{"location":"admin/control_validity_length.html","title":"Managing user sign-on","text":"You can control how long your Sametime meeting credentials are maintained to reduce the number of times you have to sign in.
JWT_REFRESH_DURATION_DAYS environment variable in the YAML file. You can specify any number of whole days to retain login credentials. To disable this feature, set the value to 0.JWT_REFRESH_DURATION_DAYS environment variable. You can specify any number of whole days to retain login credentials. To disable this feature, set the value to 0.Parent Topic: Managing Sametime Meetings
"},{"location":"admin/creating_custom_java.html","title":"Creating custom Java classes for searching LDAP","text":"These topic are in progress Create custom Java\u2122 classes that provide greater control over how Sametime conducts name searches of an LDAP directory and how results are formatted.
Implementing a custom Java class file to transform LDAP searches helps with performance when the LDAP service has a complex directory schema.
If your configuration is using the UUID attribute as the attribute of the person entry that defines the internal ID of a Sametime user, include UUID in your customized filter.
Parent Topic: Configuring LDAP
"},{"location":"admin/customize_branding.html","title":"Adding corporate branding to meeting pages","text":"You can customize meetings to reflect your company's branding and visual presence.
You can include several levels of customizing for meetings to present a visual representation of your company. You can customize all or any combination of the three.
Add a company name and logo. The logo image is displayed on the login, in-meeting, and logout pages.
Change the Favicon and application icons.
Change the background image for meeting tile view.
Adding corporate branding to meeting pages using Kubernetes
Adding corporate branding to meeting pages using Docker or Podman
Parent Topic: Configuring
"},{"location":"admin/customize_docker.html","title":"Adding corporate branding to meeting pages using Docker or Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
To customize the product name, product logo, and banner edit the custom.env file in the directory where the installation package was decompressed.
Add the appropriate statements to the custom.env file to reflect your changes.
To change the product name, add the following statement specifying the new product name.
REACT_APP_PRODUCT_NAME=new\\_product\\_name\nTo change the logo used in meeting pages, add the following statement specifying the location and name of the new logo. The image file can be any size. It is re-sized to approximately 260x260 pixels.
REACT_APP_PRODUCT_LOGO=https://meetings.hcl-showcase.com/images/branding/Showcase_Logo.jpg\nYou can specify the relative or full URL to the logo. If you use the relative URL, the image must be placed on the system using the following command.
cp my-logo.png sametime-config/web/branding/.\nAdd the following statement containing the URL to the Sametime server where you access meetings. This is used for meeting reports.
REACT_APP_PRODUCT_LOGO_URL=https://meetings.hcl-showcase.com/images/branding/Showcase_Logo.jpg\"\nTo change the meeting banner, add the following statement specifying the location and name of the new banner.
REACT_APP_MEETING_BANNER_IMAGE=banner\\_image\nTo change the meeting background, add the following statement specifying the location and name of the new background.
REACT_APP_MEETING_BACKGROUND_IMAGE=background\\_image\nThe background image can be a URL to an accessible image like https://mycompany.com/assets/theme.png or it can be an absolute path like /images/branding/my-logo.png. If you use the absolute path, the image must be placed on the system using the following command.
cp my-theme.png sametime-config/web/branding/.\nRun docker-compose up -d command to apply all changes.
To update the favicon, replace the following files with your version.
To update the app icons, copy the files to the persistent volume. This replaces the following files.
Parent Topic: Adding corporate branding to meeting pages
"},{"location":"admin/customize_kubernetes.html","title":"Adding corporate branding to meeting pages using Kubernetes","text":"To customize the product name, product logo, and banner edit the values.yaml file in the /helm directory.
Add the appropriate statements to the YAML file to reflect your changes.
To change the product name, add the following statement specifying the new product name.
productName: new\\_product\\_name\nTo change the logo, add the following statement specifying the location and name of the new logo. The image file can be any size. It is re-sized to approximately 260x260 pixels.
productLogo: /images/branding/<your\\_logo\\_file\\>\nNote: /images/branding is static and you can not edit this part. It also does not represent where the referenced file resides outside the Kubernetes pods.
Copy the logo to the persistent volume and start the web pod again.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp <your_image_file> $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
Note: Alternatively, you can use an accessible URL that you do not have to copy to the persistent volume.
productLogo: \"http://mycompany.com/assets/<your_logo_file>\"\nTo change the meeting banner, add the following statement specifying the location and name of the new banner.
meetingBannerImage: /images/branding/<your\\_logo\\_file\\>\nNote: /images/branding is static and you can not edit this part. It also does not represent where the referenced file resides outside the Kubernetes pods.
Copy the image to the persistent volume and restart the web pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp <your_image_file> $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
Note: Alternatively, you can use an accessible URL that you do not have to copy to the persistent volume.
meetingBannerImage: http://mycompany.com/assets/<your\\_logo\\_file\\>\nTo change the meeting background, add the following statement specifying the location and name of the new background.
meetingBackgroundImage: /images/branding/<your\\_logo\\_file\\>\nNote: /images/branding is static and you can not edit this part. It also does not represent where the referenced file resides outside the Kubernetes pods.
Copy the image to the persistent volume and restart the web pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp <your_image_file> $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
Note: Alternatively, you can use an accessible URL that you do not have to copy to the persistent volume.
meetingBackgroundImage: http://mycompany.com/assets/<your\\_logo\\_file\\>\nRun a helm upgrade command to apply the changes to your registry.
helm upgrade {release-name} helm/.\nTo update the favicon, do the following.
Copy the files to the persistent volume. This replaces the following files with your version.
A PNG file type image can be used, just renamed to ICO file type.
Restart the pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp favicon.ico $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
To update the app icons, do the following.
Copy the files to the persistent volume. This replaces the following files. For the app icons, replace the following files with your version.
Restart the pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp app-512x512.png $POD:/usr/share/jitsi-meet/images/branding/.\nkubectl delete po $POD\nAttention: Check the access rights after copying the files by running chmod 744 inside of the server-brandingdirectory on the Sametime NFS.
Parent Topic: Adding corporate branding to meeting pages
"},{"location":"admin/disable_background.html","title":"Disabling virtual background","text":"By default, you can use a filter, blur your background, or use a default or custom image or video to obscure your surroundings. Depending on your organization's requirements, you can disable the virtual background feature by modifying the applicable file.
To restrict all users from using virtual backgrounds during a meeting, follow these steps:
Modify the configuration file. The default value is TRUE.
For Docker, update the value of the ENABLE_VIRTUAL_BACKGROUND parameter:
ENABLE_VIRTUAL_BACKGROUND=false\nFor Kubernetes, update the value of the VirtualBackgroundEnabled parameter:
virtualBackgroundEnabled: false\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping servers.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/disable_guest_access.html","title":"Preventing guest access","text":"You can disallow guest access to meeting.
There are two tasks to complete: turn off the meeting policy and meeting login prompt. The user receives a Guest not allowed for this meeting message.
Log into the Sametime Admin and open the Anonymous policy.
Guests are assigned the Anonymous policy.
Locate the Meeting section of the policy and turn off the Allow Sametime Meetings attribute.
Update the configuration file to not allow a login prompt to display.
For Docker, in the .env file, specify the following:
REACT_APP_ALLOW_GUEST_LOGIN=false \nFor Kubernetes, Specify the following setting in values.yaml file, specify the following:
REACT_APP_ALLOW_GUEST_LOGIN:false \nParent topic: Managing Sametime Meetings
"},{"location":"admin/disable_sharing_meetings.html","title":"Disable sharing of meeting recording","text":"By default meeting recordings can be shared with others. You can change a setting to disable sharing of meeting recordings.
To disable sharing of meetings recordings, set the SHARE_RECORDINGS_BY_DEFAULT parameter to false on the Meetings server. When the value is set to false, the option to share recordings when editing meeting settings or stopping a recording is not available.
For Docker, change SHARE_RECORDINGS_BY_DEFAULT setting in the custom.env file.
SHARE_RECORDINGS_BY_DEFAULT=false\nFor Kubernetes, add the following to the helm/values.yaml file.
shareRecordingsByDefault=false\nParent Topic: Meetings
"},{"location":"admin/download_content.html","title":"Downloading content to the server","text":"When downloading content to the Sametime sever, it must be downloaded to the web/download directory.
If in a Docker or Podman environment, copy files into the sametime-config/web/downloads directory. For example, the following command is copying the SametimeClient.exe file onto the Sametime server.
cp SametimeClient.exe sametime-config/web/downloads/\nFor Kubernetes environment, copy the files to the persistent volume. For example, the following command is copying the SametimeClient.exe file onto the Sametime server.
{{POD=$(kubectl get po --selector=app.kubernetes.io/name=web | tail -1 | awk ' { print $1 } ') \nkubectl cp SametimeClient.exe $POD:/usr/share/nginx/downloads/.}} \nAfter copying the files, restart the pod.
Parent Topic: Configuring
"},{"location":"admin/enable_dial_out.html","title":"Enabling meeting dial-out","text":"You can enable the dial-out option on Docker and Kubernetes.
The meeting dial-out feature leverages a third party product from ilink called Teamcall Meeting Gateway (TMG), as well as a SIP provider or carrier of your choice to allow users in the meeting to call other participants.
When dial-out is enabled, a new button appears in the meeting allowing a meeting participant to enter a phone number for dial out. The call is established with the SIP provider or carrier, and when the call is answered, the person called is joined to the meeting in an audio-only mode.
Enabling meeting dial-out on Docker or Podman
Enabling meeting dial-out on Kubernetes
Parent Topic: Meetings
"},{"location":"admin/enable_dialout_docker.html","title":"Enabling meeting dial-out on Docker or Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Edit the .env file and save the changes.
Do not include the comments which are in parentheses ().
JIGASI_SIP_SERVER= (This is the SIP server/proxy IP or hostname. For hostname, this must be in DNS or added as extra_hosts entry in docker-compose.yml for the jigasi service.)\n\nJIGASI_SIP_PORT=5060 (This is the SIP server/proxy port)\nJIGASI_SIP_TRANSPORT=UDP (This is SIP server/proxy protocol)\nJIGASI_SIP_URI= (This is the SIP URI, in plain text. Example: [mailto:mysipuser@mysipserver.com mysipuser@mysipserver.com] )\nJIGASI_SIP_PASSWORD= (This is the SIP user password, in plain text.)\nEdit the docker_compose.yml and save the changes.
Note: The \u201c-\u201c is required in front of the parameter.
Under the JIGASI environment section, add the statement: \u2013 JIGASI_PROXY_BYPASS.
Under NGINX environment section, add the statement: - ENABLE_INVITE_OTHERS=true.
Under JICOFO environment section, add the statement: - JIGASI_SIP_URI.
Apply the settings to Docker.
To apply these settings to Docker, perform the following:
cd to directory holding docker-compose.yml\n\n> docker-compose down\n> rm -rf sametime-config/jigasi\n> docker-compose up -d\nParent Topic: Enabling meeting dial-out
"},{"location":"admin/enable_dialout_kubernetes.html","title":"Enabling meeting dial-out on Kubernetes","text":"Edit the helm/values.yaml file and change the enableJigasi to true. The default is false.
Add the following settings. Do not include the comments which are in parentheses ().
jigasiSipServer: (This is the SIP server/proxy IP or hostname. For hostname, this must be in DNS or added to CoreDNS config of Kubernetes.)\njigasiSipPort: 5060 (This is the SIP server/proxy port)\njigasiSipTransport: UDP (This is the SIP server/proxy protocol)\njigasiProxyBypass: true (If the SIP proxy is the only network path to the SIP infrastructure, this must be \u201cfalse\u201d. If the meeting infrastructure can directly hit the SIP endpoints, such as the SIP gateway to the PSTN, \u201ctrue\u201d can be set to bypass the proxy after a call is set up.)\nENABLE_INVITE_OTHERS: true\nConfigure the SIP user account.
The TMG server has a randomly generated passcode that should be shared with the meeting server. This is known as the secret. To share the secret with the meeting server, the value needs to base-64 encoded along with the name. From a command prompt enter the command:
echo -n '{\"ilink-TMG\": \"<secret\\>\"}' | base64\nSubstitute the full secret for the <secret> variable in the command. The resulting value that is echoed to the screen is the credential that needs to be configured on the meeting server.
Open the /helm/templates/auth-config-secret.yaml file in edit mode. Locate the application-registry.json and remove the existing eyB9 value and replace it with the encoded secret.
Run the helm list command to find out the deployment name and current version. This is needed in the event a roll-back is needed.
To apply the changes, change directories to the helm directory where the Sametime Meeting installer was decompressed, then run the following command:
helm upgrade sametime-meetings \nParent Topic: Enabling meeting dial-out
"},{"location":"admin/enable_disable.html","title":"Configuring live streaming","text":"If you have a high number of users that need to attend a meeting that does not require two-way interaction, you can live stream the conference to YouTube, and users can access the meeting using a YouTube URL.
A meeting recorder must be enabled on the Sametime Meeting server. If the meeting recorder doesn't exist, live streaming isn't available.
The YouTube channel must be verified. See YouTube Studio help for the details.
The YouTube Studio tool is required to create the live stream and obtain a streaming key. The stream name/key and YouTube Live URL are needed for the Sametime meeting.
Meeting moderator must have a YouTube publishing enabled account. It can take up to 24 hours for YouTube to enable this feature on an account.
Only meeting moderators can start the live stream. Meeting moderators are indicated with a small star on their participant tile.
In the context of YouTube live streaming, the Sametime Meeting server is considered an encoder for YouTube. There is no requirement to install additional software.
Disabling live stream is a server-wide setting; there is no user-based policy available to disable the feature. The live stream is disabled if you do not have a Sametime Meeting recorder.
Note: All commands provided require running as ROOT or SUDO access. If not running as root user, preface all commands with sudo.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/enable_disable.html#task_dct_chx_wxb","title":"Configuring live streaming in a Docker environment","text":"Open the custom.env file for editing.
vi custom.env \nAdd the following line to the file.
REACT_APP_LIVE_STREAMING_ENABLED=false \nSave the custom.env file.
Restart the Sametime Meeting server.
Open the helm/values.yaml file for editing.
vi helm/values.yaml \nChange the value for the enableLiveStreaming to false.
enableLiveStreaming=false \nUpdate the deployment.
helm upgrade deployment helm/\nRestart the Sametime Meeting server.
To use the Sametime Meetings add-in for Microsoft Outlook, it must be enabled on the Sametime server. The add-in is provided as part of Sametime installation package.
For additonal information about Microsoft add-ins, see the following Microsoft documentation:
Parent Topic: Meetings
"},{"location":"admin/enable_microsoft_outlook.html#task_yck_p4k_3tb","title":"Enabling the add-in on Docker","text":"Edit the .envfile.
Change the ENABLE_OUTLOOK_ADDIN parameter from false to true.
Find the parameter COMPOSE_PROFILES=outlookAddin parmater and remove the comment character (#).
Save your changes and restart the server to apply the changes.
Edit the values.yaml file.
Change the enableOutlookAddin parameter from false to true.
Save your changes and restart the server to apply the changes.
This section provides steps to configure TCP for media streams using TCP port 4443.
The following external port must be opened on a firewall. You can use any network command to verify. For example: - netstat #4443/tcp is used for Real-time Transport Protocol (RTP) media over TCP.
Two types of communication can be configured: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). You can configure the video bridge for one or both.
Parent Topic: Meetings
"},{"location":"admin/enable_video_bridge.html#task_m5l_hfj_5tb","title":"Docker","text":"Use these settings to allow both UDP and TCP.
The client tries UDP first and if it fails, TCP is used.
Open the .env file, look for \u201cJVB_TCP_HARVESTER_DISABLED\u201d configuration and change the value to false.
JVB_TCP_HARVESTER_DISABLED=false\nIn the .env file, locate the entry for JVB_TCP_PORT field. If the value has a # in front, remove the comment # to enable the setting.
JVB_TCP_PORT=4443\nNote: #JVB_TCP_PORT is TCP port for media used by Jitsi Videobridge when the TCP Harvester is enabled.
Open the docker-compose.yml. Add JVB_TCP_PORT section for the JVB component:
# Video bridge\njvb:\nports:\n- '${JVB_PORT}:${JVB_PORT}/udp'\n- '${JVB_TCP_PORT}:${JVB_TCP_PORT}'\nWith above configuration, A/V media successfully flows through 4443 media-port and media-port state changes from Listening to Established
tcp6 0 475 a82b7a871950:4443 192.168.75.1:49295 ESTABLISHED\n*Use these settings to force TCP only.***
If there is need to completely switch to the TCP protocol and remove support for UDP, then complete the settings above, remove JVB_PORT in the docker-compose.yml file and remove the entry from .env file.
# Video bridge\njvb:\nports:\n#- '${JVB_PORT}:${JVB_PORT}/udp'\n- '${JVB_TCP_PORT}:${JVB_TCP_PORT}'\nTo enforce the changes made, follow the steps in Applying configuration changes in Docker or Podman.
"},{"location":"admin/enable_video_bridge.html#task_gvf_gfj_5tb","title":"Kubernetes","text":"Use these settings to allow both UDP and TCP.
UDP will be attempted first and if it fails, then TCP will be used. If you need to disable UDP entirely, UDP will need to be blocked at the network.
Open the helm/charts/video/templates/deployment.yaml, add the following as environment variables. Search for JVB_PORT to see where to insert them:
- name: JVB_TCP_PORT\nvalue: \"4443\"\n- name: JVB_TCP_HARVESTER_DISABLED\nvalue: \"false\"\nThese steps are required for AWS EKS only. In helm/charts/video/templates/deployment.yaml, find the lifecycle section. Below it you will see a preStop: section. Insert the following as a sibling section to preStop:
postStart:\nexec:\ncommand: [\"/bin/sh\", \"-c\", \"echo 'org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth0' >> /defaults/sip-communicator.properties\"]\nSave the settings and redeploy using the steps in Applying configuration changes in Kubernetes or Openshift.
To update a live deployment, use the following command:
kubectl set env deploy/video -e JVB_TCP_PORT=4443 -e JVB_TCP_HARVESTER_DISABLED=false\nUse these commands to update a live deployment if you are deployed on AWS:
kubectl patch deploy/video -p '{\"spec\":{\"template\":{\"spec\":{\"containers\":[{\"name\":\"jvb\",\"lifecycle\":{\"postStart\":{\"exec\":{\"command\":[\"/bin/sh\", \"-c\", \"echo \\\"org.ice4j.ice.harvest.ALLOWED_INTERFACES=eth0\\\" >> /defaults/sip-communicator.properties\"]}}}}]}}}}'\nUse these steps to remove UDP port 30000 from AWS:
Ensure that Sametime Connect and Embedded clients can connect to the Sametime using SAML by adding the new trusted audience URL to the client preferences before installing or updating the clients.
Enable SAML authentication for the deployment as explained in Setting up SSO using SAML.
This task applies to the Sametime Connect and Embedded clients; it does not affect web or mobile clients. This topic includes parameters to pre-configure the clients for SAML, so that the users do not need to know any of the details.
During SAML log in process, Sametime redirects client connections to the Identity Provider (IdP) URL. If the IdP passes the user through multiple sites, Sametime stops loading the page and generates the following error message in the log: URL redirected_url is not in the trusted sites list.
Ensure that Sametime Connect and Embedded clients can connect using SAML by adding the trusted site's URL to the client preferences before installing or updating the clients. This is the URL that you assigned in the STSAML_TRUSTED_AUDIENCES setting, as explained in Configuration settings related to SAML authentication. For more information on configuring client installation packages, see Configuring Sametime Connect client preferences with the Expeditor managed settings framework.
Alternatively, users can manually enable SAML authentication by modifying settings in the client. For more information, see Enabling SAML authentication in installed clients. This topic outlines the steps required to determine the settings used in the plugin_customization.ini file. As you find the parameter name and value for each setting, save them in a temporary location, which is added to the plugin_customization.ini to configure the clients.
Determine the SAML prefix value.
The Sametime clients support connecting to more than one Sametime environment, which could possibly have different IdPs. Therefore, the parameters defined in the plugin_customization.ini file are prefixed with the host name of the server.
To determine the parameter prefix value:
com.ibm.collaboration.realtime.community/.The second part of the parameter prefix is the fully qualified host name of the Sametime server followed by a dot. For example:
sametime.example.com.\nFor example, if the Sametime host name is sametime.example.com, the resulting prefix using the example is the prefix added to each parameters.
com.ibm.collaboration.realtime.community/sametime.example.com\n.
Determine the IdP URL parameter name and value.
To determine the parameter name, use the prefix determined in the previous step and append idp=. For example:
com.ibm.collaboration.realtime.community/sametime.example.com.idp=\nSet the value of the parameter to the IdP URL. To find the IdP URL, refer to the Setting up SSO using SAML. For example:
com.ibm.collaboration.realtime.community/sametime.example.com.idp=https://idp.example.com/exampletenant&appid=1234?TARGET=https://sametime.example.com\nDetermine if you should use a form based login or a browser based login type.
The parameter name is the prefix determined in step one followed by idp.type= For example:
com.ibm.collaboration.realtime.community/sametime.example.com.idp.type=\nThe Sametime Connect and Embedded clients have two options for displaying the user login details:
Browse to your IdP URL, view the HTML source of the log-in form and collect the following values.
prefix.idp.form.username.tag : The value in the name attribute of the Intranet ID label's input statement. This value is user ID.
prefix.idp.form.password.tag : The value in the name attribute of the Password label's input statement. This value is password .
prefix.idp.form.submit.tag : The value in the name attribute of the Sign in input statement. This value is the submit tag.
For example, if you browse to the example IdP URL, the following shows where the values appear in the sample HTML source.
Based on the example, the resulting settings and values are:
com.ibm.collaboration.realtime.community/sametime.example.com.idp.form.username.tag=userID \ncom.ibm.collaboration.realtime.community/sametime.example.com.idp.form.password.tag=password \ncom.ibm.collaboration.realtime.community/sametime.example.com.idp.form.submit.tag=submit_button \nSet the samlTrustedSites parameter to list all redirecting URLs used by your IdP.
Separate multiple URLs with a comma (,). If your IdP does not use redirecting URLs, leave this setting blank. Each URL can be as simple as https://host_name, or you can include a path as in https://host_name/path as shown in the following example.
com.ibm.collaboration.realtime.community/samlTrustedSites=https://host1,https://host2/path\nNote: This parameter is scoped globally to Sametime and not to a particular community. If configuring multiple communities, enter all possible URLs.
Configure the parameter that lists the communities which use SAML.
Be sure to use the same fully qualified host name that was used in step 1 when the prefix was determined. For example:
com.ibm.collaboration.realtime.community/samlCommunities=sametime.example.com\nIf you have more than one community supporting SAML, enter the second server name as well. Use a comma to separate values.
Add the settings to the plugin_customization.ini file and include it in the client package that is distributed to users.
Parent Topic: Setting up SSO using SAML
"},{"location":"admin/enabling_saml_clients.html","title":"Enabling SAML authentication in installed clients","text":"Enable SAML authentication from within the HCL\u00ae Sametime\u00ae Connect or Embedded client that is already installed on a computer.
Enabling SAML authentication in an installed client requires the following information, which the Sametime administrator can provide to users:
These instructions only apply to a client that is already installed on a computer (the stand-alone Connect client or the Embedded client that runs in HCL Notes\u00ae).
Open the Sametime Preferences dialog box.
On the Server Communities page, click New Server Community.
On the New Server Community page, fill in the information listed in Table 1.
Server community type : Select Sametime.
Server community type : Server community name : Type the community name.
Click the Log In tab.
Turn on the Use token-based single sign-on parameter.
In the Authentication server field, type the authentication server's URL, which you can obtain from your administrator.
In the Authentication type field, select SAML and complete the following fields.
Login : If users log in to your company's authentication server by typing a user name and password in the browser login page, select Browser and do not specify a value for the User name and Password fields.
: If users log in to your company's authentication server by typing a user name and password in a Sametime dialog box, select Form and specify a value for the User name and Password fields.
User name tag : Specify either the HTML tag ID or the tag name of the user name field in the IdP.
Password tag : Specify either the HTML tag ID or the tag name of the password field in the IdP.
Submit tag : If Browser was selected, this field is optional. Specify a value for this field if you want to enable automatic log-ins after network interruptions, provide either the HTML tag ID or the tag name of the submit field in the IdP. If you do not specify a value, passwords are not retained from one log-in to the next.
: If Form was selected, specify either the HTML tag ID or the tag name of the submit field in the IdP.
Click the Server tab and provide the following information.
Host server : The fully qualified host name of the Sametime server.
Server community port : The Sametime server port, specify 1533.
Click OK to save your changes and close the dialog box.
Parent Topic: Setting up SSO using SAML
"},{"location":"admin/enabling_saml_docker.html","title":"Configuring SAML on Docker and Podman","text":"A truststore is needed for Sametime to decrypt SAML tokens. For information on creating a samltruststore.p12 file, see Creating a truststore with a third-party certificate.
The IdP URL is defined in the configuration. See Setting up SSO using SAML for information on determining the IdP URL value.
The changes in this task affect the following pods:
The steps in the following procedure must be completed with root access or you can use sudo which allows you to run commands as root.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Change directories to the root directory where the Sametime installation package was decompressed.
Place the samltruststore.p12 file in the directory where the docker-compose.yml file is located.
Create a file with the name saml.env.
vi saml.env\nAdd the following lines to the saml.env file.
STI__Config__STSAML_TRUST_STORE_TYPE=p12 \nSTI__Config__STSAML_TRUST_STORE_FILE=/local/notesdata/samltruststore.p12 \nSTI__Config__STSAML_TRUST_STORE_PASSWORD=samltruststorepass \nOpen the docker-compose.yml file for editing.
Locate the env_file: section under the community: subsection within the services: section.
Move custom.env to a new line.
Add the following line below custom.env.
saml.env\nThe results should look like the following:
services:\n community:\n env_file: \n - custom.env\n - saml.env\n environment:\nAdd a path to the SAML trust store.
volumes section in the docker-compose.yml file, create one under the networks section and add the following line to the section.volumes section, add the following line to the section. - ./samltruststore.p12:/local/notesdata/samltruststore.p12 \nThe section should look like the following example. Ensure that the indentations look like the example.
networks:\n - sametime.test\nvolumes:\n - ./samltruststore.p12:/local/notesdata/samltruststore.p12\nUpdate the custom.env file to include the IdP URL as well as the authentication options.
Authentication options to include are: Jwt, Ltpa, and Saml. If you are uncertain of the value to use for your IdP URL, see Setting up SSO using SAML for details. For example:
STI__ST_BB_NAMES__ST_AUTH_TOKEN=Fork:Jwt,Ltpa,Saml\nIDP_URL=https://idp.example.com/example_tenant&appid=1234?TARGET=https://sametime.example.com/chat\nNote: The TARGET parameter is for the re-direct after a SAML assertion is posted back to Sametime after it has been validated. Ensure that the target points back to the chat host name or chat (as the example shows).
Open the .env file for editing, and then add the STCONF_IDPURL parameter.
For example:
STCONF_IDPURL=https://idp.example.com/example_tenant&appid=1234?TARGET=https://sametime.example.com/chat\nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up SSO using SAML
"},{"location":"admin/enabling_saml_kubernetes.html","title":"Configuring SAML in Kubernetes","text":"You can implement SSO into your Kubernetes environment using Security Assertion Markup Language (SAML). The changes in this task affect the following pods: community, mux, and proxy.
Find the idpUrl value.
Modify the user access URL that was provided by your identity provider so that users are redirected properly.
Append the IdP user access URL with ?TARGET=https://fully_qualified_hostname/chat.
For example, if the following exists:
https://idp.example.com/example\\_tenant&appid=1234https://idp.example.com/example\\_tenant&appid=1234?TARGET=https://sametime.example.com/chat
If you are using a different host name for meetings and web chat, use the host name for the web chat client.
https://idp.example.com/exampletenant&appid=1234?TARGET=https://webchat.example.com/chat
Configure the Sametime server to use SAML.
Retrieve the certificate from your IdP and create a trust store in p12 format named samltruststore.p12. If your IdP provides more than one certificate, all certificates must be added to the trust store.
Create a secret with your trust store.
kubectl create secret generic saml-secret --from-literal=KeyStorePassword=password --from-file=samltruststore.p12\nWhere password is the password for the keystore. If you are using a namespace for Sametime, include the namespace argument in the command to ensure the secret is located in the same namespace as Sametime.
Change directories to helm in the location where the Sametime install was decompressed.
Open the values.yaml file in edit mode.
Remove the comment character (#) from the following line.
# samlConfigSecret: saml-secret
Type the IdP URL as the value for the idpUrl parameter.
Add the following line below the idpUrl line.
ReactAppShowGuestLoginByDefault: true\nSave and close the values.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up SSO using SAML
"},{"location":"admin/enabling_sso.html","title":"Enabling Single Sign-on","text":"The HCL Sametime server installer enables required JSON Web Token (JWT) authentication. Additionally, the Sametime server supports Security Assertion Markup Language (SAML) and Lightweight Third Party Authentication (LTPA) Single Sign-on (SSO).
SSO is required by the Sametime Community, Proxy, and Meeting services. Typically no further configuration is required, but in some situations you might need to configure SSO to work with other servers. For example, if you have Sametime Integration with Verse, you need to share the same SSO with the Verse servers.
With SSO configured, users who log in to any server within the configured DNS domain do not have to log in again when they access another participating server.
Note: When using SSO all servers must use the fully qualified host names, such as server.example.com for the LTPA tokens to be created correctly.
Parent Topic: Securing
"},{"location":"admin/enabling_sso_ltpa.html","title":"Setting up SSO using LTPA","text":"You can implement SSO into your environment using Lightweight Third Party Authentication (LTPA) which requires LTPA keys.
If you connecting to a HCL Connections server, the LTPA keys is generated by Connections. For other implementations, you'll need to generate the LTPA keys. It doesn't matter whether Sametime is running in Docker or Kubernetes, you can use the process is the same to generate the keys.
To complete the SSO connections, the LTPA keys must be configured in Docker or Kubernetes where Sametime is running. The process to configure LTPA on Docker and Kubernetes is different.
Parent Topic: Enabling Single Sign-on
"},{"location":"admin/enabling_sso_saml.html","title":"Setting up SSO using SAML","text":"You can implement SSO into your environment using Security Assertion Markup Language (SAML). The process is different for Kubernetes and Docker.
One user access URL for the Sametime server is needed for the identity provider (IdP). An IdP is a service that stores and verifies the identity of users. In previous Sametime releases, the community services for rich clients was separate from the web chat and meeting services. In Sametime 12, all services are under the Sametime server. Because there is only one server, only one host name is required for all three types of user access: rich clients, web chat, and meetings.
To use SAML, the IdP administrator must create a federated partnership or relying party trust for the Sametime server. Additionally, the user access URL for the Sametime configuration and a certificate to be trusted by the Sametime server must be provided.
If you are upgrading from a previous Sametime version, you might want to keep using the same host names. Use the following scenarios for IdP requirement guidance.
"},{"location":"admin/enabling_sso_saml.html#scenario-1","title":"Scenario 1","text":"If one host name is used for accessing rich clients, web chat clients, and meeting clients, then only one SAML partnership or relying party trust is needed.
"},{"location":"admin/enabling_sso_saml.html#scenario-2","title":"Scenario 2","text":"If using a different host name for rich clients and web chat clients, then include the following SAML partnerships or relying party trusts:
If using a different host name for rich client, web chat clients, and meeting clients, then include the following SAML partnerships or relying party trusts:
Note: Meeting authentication is processed through the web chat proxy and no specific SAML partnership is required for the meeting host name.
Each IdP varies in implementation and terminology. The following are some guidelines for configuring your IdP. Only IdP initiated sign-on is supported.
"},{"location":"admin/enabling_sso_saml.html#saml-assertion-consumer-service-url","title":"SAML assertion consumer service URL","text":"The fully-qualified URL of the Sametime server, add /stwebapi/user/connect. For example, https://sametime.example.com/stwebapi/user/connect at the end of the URL.
If you are using a separate name for the web chat client, you can use the webchat host name in the URL. For example: https://webchat.example.con/stwebapi/user/connect.
If the Community chat server has a separate host name from webchat or rich clients, use the community host name in the URL, for example: https://chat.example.com .
"},{"location":"admin/enabling_sso_saml.html#relay-state","title":"Relay State","text":"Specify the same value as the what is specified for the SAML assertion consumer service URL.
"},{"location":"admin/enabling_sso_saml.html#log-out-url","title":"Log out URL","text":"Do not specify a value for this property. The SAML logout specification is not supported in Sametime.
"},{"location":"admin/enabling_sso_saml.html#name-id","title":"Name ID","text":"Specify the attribute from the IdP that contains the user's email address.
"},{"location":"admin/enabling_sso_saml.html#certificate-for-tls","title":"Certificate for TLS","text":"A secure connection to the IdP is required and the IdP administrator must provide the certificate for Sametime to trust. If you have multiple relying party trusts, the IdP might have separate certificates for each host name trusted or a single certificate. Such as in the case of separated host names. If there are more than one certificate, each certificate and its full chain must be added to the trust store.
Configuring SAML on Docker and Podman
Configuring SAML in Kubernetes You can implement SSO into your Kubernetes environment using Security Assertion Markup Language (SAML).
Parent Topic: Enabling Single Sign-on
"},{"location":"admin/example_preferences.html","title":"Hosting client files for Sametime on Docker or Podman","text":"Sametime clients can be configured by administrators using a managed-settings.xml or managed-community-configs.xml file which is hosted by a web server. Additionally, the Sametime client can be pre-configured with settings such as the hostname, port, etc. The client package can be hosted on a web server for download. This topic has the steps to host files in the Sametime web container for Docker or Podman.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Shut down the Sametime server.
docker-compose down\nRun the following command to copy the managed-settings.xml or managed-community-configs.xml file into the sametime-config/web/downloads directory.
cp SametimeClient.exe sametime-config/web/downloads/.\nThe managed-settings.xml file must be named managed-settings.xml. If you require more than one managed-settings.xml file, you must place those files in different folders on the web server.
Optional: Create additional directories in the downloads folder. For example, create a folder named default under that tree.
sametime-config/web/downloads/default/\nThe Sametime client looks in the folder specified in the policy for both a managed-settings.xml and a managed-community-configs.xml. If you are using both types of files, the URL defined in the policy must be scoped to the folder path where the two files reside.
If you need to support multiple policies containing different managed-settings.xml and managed-community-configs.xml files, then place them in folders with different names.
For example:
http://www.example.com/default \n\nhttp://www.example.com/nomeetings\nNote: Do not use the following special characters in your folder names
Parent Topic: Defining preferences in the managed-settings.xml file
"},{"location":"admin/hcl_sametime_clients.html","title":"Sametime clients","text":"Several client types are supported providing flexibility in how users can access chats and meetings. A single deployment can implement several client types.
The following Sametime client types are supported:
"},{"location":"admin/hcl_sametime_clients.html#connect-client","title":"Connect client","text":"The Connect client is a stand-alone client that allows for connection to the Sametime server for meetings and chat. It is installed on the user's desktop and requires administrative privileges to perform the install. It can be installed on a Windows or MacOS platform. This client provides access to chat features. Documentation for this client is provided as Help within the client.
"},{"location":"admin/hcl_sametime_clients.html#embedded-client","title":"Embedded client","text":"An Embedded client provides connection to the Sametime server within another product. HCL Verse, HCL iNotes, HCL Connections, and HCL Digital contained an embedded Sametime client. Because it is part of the product, starting and using Sametime is done within the product where it is embedded. This client provides access to chat features. Documentation for this client is provided as Help within the client.
"},{"location":"admin/hcl_sametime_clients.html#mobile-client","title":"Mobile client","text":"Mobile clients provide access to a Sametime server using an iOS and Android mobile device. A HCL Sametime app must be installed on the mobile device to connect to the server. This client provides access to chat and meeting features.
The PWA is a standalone app that can be installed from the Web client onto your machine. It allows you to access chat and meeting features from the installed app. This client provides access to chat and meeting features.
"},{"location":"admin/hcl_sametime_clients.html#web-client","title":"Web client","text":"The Web client provides access to the Sametime server using a web browser. This client provides access to chat and meeting features.
Parent Topic: Planning
"},{"location":"admin/implement_tls_configuration.html","title":"Implementing the Global TLS Scope for Docker","text":"You must have a key store and trust store as a .p12 file. Both third party and self-signed certificates are supported.
Note: If you are supporting mobile clients, use a third-party certificate.
The following tables describe the required and optional configuration settings in the sametime.ini. To configure the sametime.ini file, see Configuring the sametime.ini file on Docker or Podman.
Table 1. Required parameters
Parameter Description STI_Config_ST_TLS_TRUST_STORE_TYPE The trust store type. Only p12 trust stores are supported. STI_Config_ST_TLS_KEY_STORE_TYPE The key store type. Only p12 trust stores are supported. STI_Config_ST_TLS_TRUST_STORE_FILE The full path and name of the trust store file. For example: /local/notesdata/truststore.p12 STI_Config_ST_TLS_TRUST_STORE_PASSWORD The password to the trust store.For example:SecureSametimePassw0rd STI_Config_ST_TLS_KEY_STORE_FILE The full path and name of the key store. For example: /local/notesdata/keystore.p12 STI_Config_ST_TLS_KEY_STORE_PASSWORD The password to the keystorel For example: SecureSametimePassw0rd Table 2. Optional Parameters
Parameter Description STI_Config_ST_TLS_FIPS_COMPLIANCE Set to 1 to enable FIPS compliance. STI_Config_ST_TLS_SECURITY_LEVEL The required security level. The minimum security level controls compliance with the security standards NIST SP800-131a and NSA Suite B. 0: No requirement 1: NIST SP800 -131a \u201cTransition mode\u201d 2: NIST SP800-131a \u201cStrict mode\u201d 3: NSA Suite B 128-bit level 4: NSA Suite B 192-bit level STI_Config_ST_TLS_MAX_SESSION_AGE The amount of time before re-negotiating a session. The time to keep a session, in seconds, before deleting it from cache. -1: No cache, which is generally sufficient for most Sametime deployments. This is the default value. 0: No limit on the age of cached sessions. STI_Config_ST_TLS_SESSION_CACHE_SIZE Applies only to inbound connections. The number of TLS sessions that a server keeps in memory, for session reuse. This option tells the server to keep a cache of the TLS session state after the connection is closed. -1: No session cache, which is generally sufficient for most Sametime deployments. This is the default value. 0: No limit on the number of cached sessions. It is useful after temporary network outage, when the client attempts to reconnect to the server, by reusing the session that was established earlier. - If the server finds the session in cache, the handshake is abbreviated, consuming less resources. - If the session is not in cache, a new session is established, including the full handshake. STI_Config_ST_TLS_SESSION_CACHE_TIME Applies only to inbound connections. The maximum age of a TLS session, in seconds before renegotiating a session, If the same session is used longer than this setting, a new session is renegotiated over the same connection. The default value 0 means that there is no session renegotiation. STI_Config_ST_TLS_MIN_PROTOCOL_VERSION= The oldest version of the SSL/TLS protocol to negotiate during handshake. The default value is TLS 1.2. 0x300: SSL v3 0x301: TLS v1.0 0x302: TLS v1.1 0x303: TLS v1.2. This is the default value used if the value for the parameter is blank. STI_Config_ST_TLS_MAX_PROTOCOL_VERSION The maximum TLS protocol. 0x300: SSL v3 0x301: TLS v1.0 0x302: TLS v1.1 0x303: TLS v1.2. This is the default value used if the value for the parameter is blank. STI_Config_ST_TLS_CIPHER_SUITES A comma-separated list of cipher suites. Leave blank to enable the default cipher suites.\u00a0 STI_Config_ST_TLS_CLIENT_AUTH Request a certificate from the client, does not apply to outbound connections. 0=None: The server does not request a certificate from the client. This is the default value. 1=Want: The server requests a certificate from the client, but will proceed with the handshake even if the client does not present one. 2=Need: The server requests a certificate from the client, and will fail the connection if the client does not present one. STI_Config_ST_TLS_TRUSTED_HOSTS A comma-separated list of one or more trusted hosts, to compare against the peer certificate. The comparison takes place during the TLS handshake, when receiving a certificate from the peer, when the client receives the server certificate, or when the server receives a client certificate. The name in the peer certificate is typically specified in either the subject CN (common name) or thesubjectAltName field. Validation passes if there is at least one match between the name in the peer certificate and a name in the trusted hosts list. A trusted host name may contain the wild card character (*) which can be used to compare domain components rather than the entire string as a whole. The comparison process follows the rules described in section 3.1 of RFC 2818. Certificate subject validation only applies when receiving a certificate from the peer. In order to ensure that a server performs this comparison, the server must require a client certificate, by setting ST_TLS_CLIENT_AUTH=2. STI_Config_ST_TLS_MIRROR_TRUSTED_HOSTS This parameter is needed when you have a key store with multiple key certificates. In which case, each certificate has a different alias in the key store. On the server side, specify the alias of the certificate that identifies the server. If the key store is used on the client side of TLS connections, specify the alias of the certificate that identifies the client. STI_Config_ST_TLS_KEY_LABEL This parameter is ignored if the STI_Config_ST_TLS_KEY_STORE_FILE parameter is missing or if there is only one key in the keystore. This parameter is needed when you have a key store with multiple key certificates. In which case, each certificate has a different alias in the key store. On the server side, specify the alias of the certificate that identifies the server. If the key store is used on the client side of TLS connections, specify the alias of the certificate that identifies the client. Note: When you enable TLS for the Sametime server connections, TLS version 1.2 is used by default. SSLv3 and TLSv1 have security vulnerabilities and should not be used.
Parent Topic: Securing connections
"},{"location":"admin/increase_activecameras.html","title":"Increasing the number of video streams displayed during a meeting","text":"The most recent active video streams are displayed in the meeting window up to the specified maximum value. The default is nine.
The maximum number includes the person viewing the meeting. If the value is increased and performance decreases, reduce the number. Note that specifying a value greater than nine is not supported by HCL.
Open the configuration file for editing.
Change the parameter in the configuration file. Note that the value doesn't include your camera which is always displayed.
For Docker, update the CHANNEL_LAST_N parameter. For example,
CHANNEL_LAST_N = 11\nWhen applied, up to twelve simultaneous video streams are displayed.
For Kubernetes environments, update the channelLastN parameter. For example,
channelLastN : 11\nThe parameters are case sensitive and must be entered as shown.
Apply the changes to the environment.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/installation_mongodb.html","title":"Installing MongoDB","text":"The MongoDB Community Server can be downloaded from the MongoDB website. You can install MongoDB on Windows and Linux platforms. For information on MongoDB about its purpose for Sametime and deployment options, see MongoDB.
Parent Topic: Installing
"},{"location":"admin/installation_prometheus.html","title":"Installing Prometheus","text":"Prometheus provides monitoring on the system. It is used in the auto-scaling feature, but can also be used to monitor your system usage and performance.
The Prometheus application must be installed to deploy the autoscaler and deploy Grafana on a Sametime Kubernetes environment.
The procedures in this topic install the Kube-Prometheus stack using Helm and the default helm charts. Refer to the prometheus-operator / kube-prometheus readme for the default settings. To customize the configuration, the prometheus-community/helm-charts can be downloaded and modified before installing them.
Add the prometheus-community helm repository.
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts\nCreate a namespace for monitoring.
kubectl create namespace monitoring\nRun the following command to install Prometheus. The command must be entered as a single line.
helm install -n monitoring prometheus --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false prometheus-community/kube-prometheus-stack\nParent Topic: Installing Sametime in a Kubernetes environment
Parent Topic: Monitoring your meeting and chat metrics with Grafana
"},{"location":"admin/installation_prompt_descriptions.html","title":"Information to provide during installation","text":"During the install process, you are prompted for information used to tailor the installation for your environment.
The Sametime install prompts for several details pertaining to the environment. Before initiating the process, gather the listed details.
"},{"location":"admin/installation_prompt_descriptions.html#sametime-server-name","title":"Sametime server name","text":"The fully qualified name of the Sametime server.
"},{"location":"admin/installation_prompt_descriptions.html#mongodb","title":"MongoDB","text":""},{"location":"admin/installation_prompt_descriptions.html#mongo-host","title":"Mongo host","text":"The host name of the MongoDB server.
"},{"location":"admin/installation_prompt_descriptions.html#mongo-port","title":"Mongo port","text":"The port number used to communicate with the MongoDB server.
"},{"location":"admin/installation_prompt_descriptions.html#administrator-user-name","title":"Administrator user name","text":"The user name of the MongoDB administrator defined when configuring the MongoDB. The default MongoDB administrator is sametimeUser.
"},{"location":"admin/installation_prompt_descriptions.html#password","title":"Password","text":"The password for the the MongoDB administrator defined when configuring the MongoDB. The default MongoDB password is sametime.
"},{"location":"admin/installation_prompt_descriptions.html#connection-url","title":"Connection URL","text":"A secure URL to connect to the MongoDB server. The supplied URL overrides the default MongoDB URL.
"},{"location":"admin/installation_prompt_descriptions.html#ldap","title":"LDAP","text":""},{"location":"admin/installation_prompt_descriptions.html#ldap-server","title":"LDAP server","text":"The host name or IP address of the LDAP server.
"},{"location":"admin/installation_prompt_descriptions.html#ldap-port","title":"LDAP port","text":"The port used to communicate with the LDAP server.
"},{"location":"admin/installation_prompt_descriptions.html#bind-name-and-password","title":"Bind name and password","text":"The bind account name and password for Sametime to access LDAP.
"},{"location":"admin/installation_prompt_descriptions.html#base-dn","title":"Base DN","text":"The base location where Sametime begins a search for users and groups.
"},{"location":"admin/installation_prompt_descriptions.html#tls-access","title":"TLS access","text":"If LDAP is access using TLS, provide the port number.
"},{"location":"admin/installation_prompt_descriptions.html#displayname-attributes","title":"displayName attributes","text":"The default is cn.
"},{"location":"admin/installation_prompt_descriptions.html#jwt-secret","title":"JWT Secret","text":"The Base64 encoded JWT_SECRET from the Sametime deployment. If migrating from another version of Sametime, you can re-use your existing secret. If you don't have one the install program generates it.
"},{"location":"admin/installation_prompt_descriptions.html#turn-server","title":"TURN server","text":""},{"location":"admin/installation_prompt_descriptions.html#turn-server-address","title":"TURN server address","text":"The fully-qualified host name of a TURN server.
"},{"location":"admin/installation_prompt_descriptions.html#turn-port","title":"TURN port","text":"The port used to communicate with the TURN server.
"},{"location":"admin/installation_prompt_descriptions.html#secret-to-turn-server","title":"Secret to TURN server","text":""},{"location":"admin/installation_prompt_descriptions.html#transport-for-stunturn-connection","title":"Transport for stun/turn connection","text":"Select either pct or udp.
"},{"location":"admin/installation_prompt_descriptions.html#tcp-configuration","title":"TCP configuration","text":"The port number used for TCP communications. The default is port number 4443.
"},{"location":"admin/installation_prompt_descriptions.html#ltpa-configuration","title":"LTPA configuration","text":""},{"location":"admin/installation_prompt_descriptions.html#path-to-the-ltpa-key-file","title":"Path to the LTPA key file","text":"Fully path to the LTPA key file. If you enable LTPA, LTAP keys are required.
Upon successful connection to the LTPA keys, the following message is displayed.LTPA configuration is OK
"},{"location":"admin/installation_prompt_descriptions.html#administrator-email","title":"Administrator email","text":"The email address for the Sametime administrator.
"},{"location":"admin/installation_prompt_descriptions.html#monitoring","title":"Monitoring","text":""},{"location":"admin/installation_prompt_descriptions.html#admin-user","title":"Admin user","text":"The Grafana administrator ID to access the Grafana console
"},{"location":"admin/installation_prompt_descriptions.html#password_1","title":"Password","text":"Password associated with the Grafana administrator ID.
"},{"location":"admin/installation_roadmap.html","title":"Installation road map","text":"The installation road map lists the high-level steps for installing your product. Reviewing the high-level steps before you start the installation process helps you be prepared when prompted for information during the installation.
Table 1. Where to find more information
Item More information System requirements HCL Sametime\u00ae System Requirements Planning - Planning the network topology and connectivity - Sametime client preferences - Sametime client configuration options Installing - Installing MongoDB - Installing Sametime - Installing Sametime clients - Configuring LDAP Clustering and high availability - Clustering and high availability - Installing Prometheus Migrating and upgrading - Planning for migration to Sametime 12Parent Topic: Installing
"},{"location":"admin/installation_sametime.html","title":"Installing Sametime","text":"You can install HCL Sametime Premium and HCL Sametime in a single- or multi-node container environment. The following platforms are supported: Docker, Podman, Kubernetes, OpenShift, and Windows.
The processes for installing Sametime Premium and Sametime are almost identical. Sametime Premium includes both the meetings and chat features. Sametime includes only the chat feature. When you install Sametime, steps related to meetings, recordings, audio, and video are not required.
There are several install options that should be considered before starting the install process. Based your choice on what is best for your environment.
"},{"location":"admin/installation_sametime.html#section_hd1_hj2_zyb","title":"Single-node container management environment","text":"All supported platforms support a single-node environment to manage the Sametime containers. All use a install procedure that is specific to the container management system. Because it is a single-node environment, installing additional software for things such as autoscaling is not needed.
Installing Sametime in a Kubernetes using managed charts
Information to provide during installation During the install process, you are prompted for information used to tailor the installation for your environment.
Parent Topic: Installing
"},{"location":"admin/installation_sametime_docker.html","title":"Installing Sametime in a Docker or Podman environment","text":"The process to install Sametime on Docker and Podman are identical. The installation process detects if you are installing Sametime on Docker or Podman and prompts for the appropriate information.
Before you can install Sametime, you must have a working Docker or Podman environment. Refer to the documentation for installing and configuring Docker or Podman which contain the latest information.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Parent Topic: Installing Sametime
"},{"location":"admin/installation_sametime_grafana.html","title":"Enabling monitoring and statistics","text":"You can configure Grafana during the installation process provided it has been enabled. Alternately, Grafana can be configured post-installation.
To include Grafana configuration during installation, run the following exportcommand before running the installation process.
export ENABLE_DARK_LAUNCH_MONITORING=true\nYou are then prompted during the install to enable Grafana: Do you want to enable monitoring?.
If configuring Grafana after installation, see the following topics:
A Sametime deployment can be configured on a single-node Kubernetes clusters, like K3s or Docker Desktop, on a cloud-based, or on-prem multi-node cluster with separate control plane or worker nodes.
An Ingress Controller is required for web traffic.
The following white papers are available to review this setup for GKE (Google), AWS (Amazon) and on-premise configurations. Use these white papers for additional details on the installation and configuration steps for Kubernetes.
References to the cluster.yaml file in the white papers are based on Sametime 11.6. For later Sametime versions, the file is located in the Sametime installation package directory: install_package_directory/ /kubernetes/stack/eks/cluster.yaml.
If you are installing on an Openshift platform, review the Preparing to install an Openshift environment topic before starting the install process.
See the HCL Sametime\u00ae System Requirements document for support in Kubernetes and Helm versions.
Promethus can be used for tracking metrics and overall health of the system. Managed charts with Prometheus and metrics enabled are provided for convenience, otherwise, Prometheus should be installed manually before starting the Sametime installation process. See Installing Prometheus for details.
After the Kubernetes cluster is built, complete the following tasks to deploy Sametime.
Note: The helm charts and templates provided were tested with 1.22. Later versions of Kubernetes might not be compatible.
Using Sametime images from the HCL Harbor registry
Loading the Sametime images to a Docker repository The Sametime images must be in a Docker repository so that they can be accessed when running Sametime. They can be in a local Docker repository or they can be accessed from the HCL Docker repository.
Parent Topic: Installing Sametime
"},{"location":"admin/installation_sametime_kubernetes_managedcharts.html","title":"Installing Sametime in a Kubernetes using managed charts","text":"The Sametime product image includes pre-configured managed Helm charts to deploy HCL Sametime and HCL Sametime Premium. The managed Helm charts allow you to get a Kubernetes-based deployment up and running.
The managed charts include everything needed for a running deployment, such as: MongoDB, OpenLDAP, and NGINX Ingress Controller; and are ready to go with a single install operation. There is a variant of each chart that includes Prometheus and Grafana so that metrics can be monitored without any additional configuration. Each managed chart is provided as a TGZ bundle and can be installed using Helm or Helm Dashboard.
Note: Using the provided manage charts can be used to deploy LDAP, MongoDB as proof of concept. For production use, you must modify the charts to match the needs of your network.
Within the managed chart TGZ bundle is a values.yaml file. You can create a custom values.yaml file with configuration settings to override the settings of the supplied file. For example, the managed chart uses lvh.me as the host name, so that it can only be accessed through the local host from where it is being installed. You can provide a different value in the custom values.yaml file.
The customized values.yaml file can be created manually or by using the supplied prepareDeployment.sh script. For more information about the script, see Preparing the deployment. After the file is created, the customized values.yaml file can be archived and version controlled as necessary so that it can be applied to future updates, duplicated deployments with slight variations between each, and backed up for safe keeping so that the deployment can be recovered if necessary.
The managed charts are hosted on the HCL Harbor Registry so that deploying the charts can be cloud-native, without having to separate manage docker images on a per-node basis within an on-premise private registry.
Managed-file name Description sametime-single-node Install Sametime as a single node. sametime-single-node-metrics Install Sametime as a single node and includes Promethus and Grafana. sametime-multi-node Install Sametime as a multi-node environment. It includes Promethus and Grafana. Managed-file name Description sametime-premium-single-node Install Sametime Premium as a single node. sametime-premium-single-node-metrics Installs Sametime Premium as a single node and includes Promethus and Grafana. sametime-premium-multi-node Install Sametime Premium as a multi-node environment. It includes Promethus and Grafana.Note: A single-node installation cannot be installed in a multi-node cluster. It is designed without aspects that are typical for large deployments where there is concern about balancing resources across available nodes for performance and fault tolerance. You are can install the single-node deployment in a multi-node cluster as a \"minimal footprint\" deployment. If doing so, follow the steps in the Creating the persistent volume topic as you would if you were installing the multi-node deployment.
"},{"location":"admin/installation_sametime_kubernetes_managedcharts.html#task_iy1_lnf_pzb","title":"Using command line","text":"Verify that the container images have been loaded into a registry that is accessible to the Kubernetes cluster. For additoinal information, see Loading the Sametime images to a Docker repository.
When you install using Helm, make sure to override the registry configuration.
Load images into a private registry.
helm install sametime chart-name.tgz --set global.hclImageRegistry=my-custom-registry.myco.com\nCreate an image pull secret used to pull the container images from the HCL Harbor Registry. See Using Sametime images from the HCL Harbor registry for more information before running the helm install command.
helm install sametime chart-name.tgz\nIf you have configured Helm with authenication, you can pull the charts directly from the HCL Harbor Registry. After following the steps about accessing the container images from Harbor, you can configure that access token with Helm:
helm registry login -u your\\_email\\_address hclcr.io\nWhen prompted for a password, use the access token from your account profile in Harbor.
Use the helm install command to run the managed chart.
helm install install\\_name oci://hclcr.io/st/sametime-premium-single-node
Any customizations that should be applied to the deployment can be supplied in a custom values.yaml file rather than using --set options. To see the default values, examples, and documentation about settings you might want to customize, use one of the command:
helm show values chart-name.tgz
helm show values oci://hclcr.io/st/sametime-premium-single-node
You can copy-paste and modify any of the default values and then apply those settings like this:
helm install sametime sametime-premium-single-node-12.0.2.tgz -f values.yaml
where values.yaml is the file you have customized.
Alternatively, you can run:
./prepareDeployment.yaml values.yaml
and follow the prompts to produce a new values.yaml file with your customized configuration. You can use that as a starting point to make further edits as needed, for example. See Preparing the deployment for more information about how to respond to the prompts in the prepareDeployment tool.
Note: when using the prepareDeployment tool with a managed chart, there are additional prompts about whether the embedded mongo/openldap/coturn/nginx-ingress should be deployed. You can choose these to meet your needs.
Tools like helm-dashboard provide a user interface to manage deployments in a Kubernetes environment.
Start the Helm dashboard and point it to the chart to install as a local-repository.
helm-dashboard --local-chart=sametime-premium-single-node-12.0.2.tgz
Windows:
helm-dashboard.exe /local-chart=sametime-premium-single-node-12.0.2.tgz
Select the Repository tab and highlight the TAR file to be used and click Install.
The Install window displays information about the Helm Chart. You can modify and add values before running the chart. When finished, click Confirm.
You must complete the tasks in this topic if you are installing in an Openshift environment before you can install Sametime.
Refer to Planning for Openshift for consideratons related to namespace and video.
Deploy in a namespace. You can either create a namespace or use the default namespace. If you deploy Sametime into the default namespace, there are modifications that must be appled to the Helm chart.
Deploy to a new namespace
Create a namespace
export NAMESPACE=sametime\noc create namespace $NAMESPACE\nCreate the sametimeUser service account.
kubectl -n $NAMESPACE create serviceaccount sametimeUser\nCreate the SCC for sametimeUser account
oc create -f kubernetes/stack/openshift/sametime-restricted-v2.yaml\nApply the SCC to the service account.
oc adm policy add-scc-to-user sametime-restricted-v2 -z sametimeUser -n $NAMESPACE\nDeploy to default namespace
Edit the values.yaml file.
Comment out the seLinuxOptions: false setting for each of the following sections.
activityfilesrecordings For example:activity:\n fullnameOverride: activity\n persistence: {}\n# seLinuxOptions: false\nDeploy the video using one of the following methods.
Host Port
This is the default which provides the best performance and scales automatically scalable. This method requires pod-to-node affinity restriction through node labels. A separate video service account is required and the hostnetwork-v2 must be assigned to it.
oc create -f kubernetes/stack/openshift/sametime-hostnetwork-v2.yaml \nkubectl -n $NAMESPACE create serviceaccount videoUser \noc adm policy add-scc-to-user sametime-hostnetwork-v2 -z videoUser -n $NAMESPACE \nEdit the values.yaml to reference this video service account:
video:\n serviceAccount:\n name: videoUser\nUsing a load balancer is lower performance and has no pod-to-node restrictions. It requires the Kubernetes load balancing infrastructure.
Edit the values.yaml file to enable the loadBalanceVideo setting and reference the Sametime service account.
global:\n loadBalanceVideo: true\n...\nvideo:\n serviceAccount:\n name: sametimeUser\nUsing a node port is also lower performance but is restricted to a single node. It requires a no host-network SCC.
Edit the values.yaml file to add the following to the Sametime service account:
global:\n disableHostNetwork: true\n...\nvideo:\n serviceAccount:\n name: sametimeUser\nEdit the values.yaml file to disable the fsGroup and runAsUser settings, and reference the Sametime service account that you created.
global:\n ...\n disableFsGroup: true\n disableRunAsUser: true\n sametimeServiceAccount: sametimeUser\nContinue with the topics for installing in a Kubernetes environment.
"},{"location":"admin/installation_sametime_windows.html","title":"Installing Sametime on Windows using Docker Desktop","text":"Sametime can be installed on a Windows OS as a single-node environment using a supplied Helm chart. The Sametime product image includes a pre-configured managed Helm Chart to deploy Sametime on Windows. The chart is run from a Helm dashboard a graphical user interface.
The values in the Helm Charts can be modified before running the Install step. For example, you must specify the value for the location of the Sametime images. Other values such as the location of LDAP and other servers also need to be reviewed for your environment. The input fields in the managed charts are the same as if you were using the install script and prompted for values. See installation_prompt_descriptions.md for more information. Additionally, the Helm Charts contain information for each field to assist you with necessary updates.
Open the Windows Feature window and turn on the Windows Subsystem for Linux feature.
From the Control Panel, click Programs > Turn Windows features on or off. This feature allows you to install a Linux system and run a Linux file system, along with Linux command-line tools and GUI apps on Windows.
Install Docker Desktop.
From the Docker website, see Install Docker Desktop on Windows for install information and product download.
Docker Desktop is a Windows interface for interacting with a Docker system to manage images and containers.
Start the Docker Desktop.
From the Start menu, locate and click Docker Desktop.
There are multiple manage-Helm Charts located in the root of the Sametime install ZIP file. For Windows, you can use one of the following.
sametime-single-node : Install Sametime as a single node.
sametime-single-node-metrics : Installs Sametime and includes Prometheus and Grafana.
sametime-premimum-single-node : Install Sametime Premium as a single node.
sametime-premimum-single-node-metrics : Installs Sametime Premium and includes Prometheus and Grafana.
Enable Kubernetes.
From the Docker Desktop dashboard, click the Settings icon and then Kubernetes. Turn on the Enable Kubernetes. Click Apply and Restart.
Install the Help dashboard.
https://github.com/komodorio/helm-dashboard
Run the Helm chart to deploy Sametime.
Run the Helm Dashboard including the location of the TAR file containing the Helm Chart.
run helm-dashboard.exe /local-chart tar\\_file\\_path\nSelect the Repository tab and highlight the sametime-premimum-single-node file and click Install.
The Install window displays information about the Helm Chart. Make the necessary changes such as the value for where the Sametime images are located. You can modify and add values before running the chart. When finished, click Confirm.
This section provides information on installing the servers for Sametime and Sametime Premium.
The Connect client can be installed on a user's machine either by sending the install package to the user or by pushing the installation to the user's machine. In either case, the installation is an silent install.
Silent install is available only on the Windows platform.
The batch file used to start the install process is setup.bat. This batch file contains the setup.exe command with default parameter values to run the installer. You can modify the parameters. The following table shows the command parameters and default values.
Table 1. Parameters in the setup.bat file
Parameter Description install.log The name of the log file created by the installer. The file is created in the same directory as the installer. INSTALLDIR=installation_directory The full path of the installation directory. STSILENTINIFILE=ini_file_name Name of the configuration INI file. The default is silentinstall.ini . STSILENTINSTALL=TRUE Indicates the install is a silent install. This value must be TRUE for silent execution.The setup.bat file contains several different commands that can be used to perform different installation functions. Some of the commands are commented out by default, you can remove the comment tag and updated if the function is needed. Detailed explanations are included in the setup.bat file.
The silentinstall.ini file contains configuration parameters for the Connect client. The settings are used to populate the community-config.xml file with server connection information and other parameters required by the installer. The following table describes the configuration parameters.
Table 2. Parameters in the silentinstall.ini file
Parameter Description LAPAGREE=NO Specify whether to accept the license agreement. This value must beYES. The default value is NO. You must change this parameter to YES for silent install to work. CREATECOMMUNITYTEMPLATE=true Specifies whether community properties such as STSERVERNAME and STCOMMUNITYNAME are ignored. When set to false, the community-config.xml is not created in the installation_directory\\rcp\\deploy folder. All community-config properties should be put in the plugin_customization.ini in the installation_media_root_directory-root_directory\\deploy directory. If using a custom plugin_customization.ini, ensure that the value is set to true. STSERVERNAME=stservername.domain.com The fully qualified host name of the Sametime server. Normally this is the same as the home server specified in the person document. STCOMMUNITYNAME= community_name The name of the community. STSERVERPORT=1533 The IP port number of the Sametime server. STSENDKEEPALIVE=true Flag for sending keep-alive signal. STKEEPALIVETIME=60 Indicates how often to check the connectivity between the client and server, allowing timely notification if disconnected. The default is 60 seconds. STCONNECTIONTYPE75=direct The type of connection. Valid values are: direct, useBrowserSettings, tls-direct, http-direct, socks4-proxy, socks5-proxy, http-proxy, https-proxy, and reverse-proxy. The default value is direct. STPROXYHOST=proxy_host_name The host name of the proxy server. If you are not using a proxy, leave this field blank. STPROXYPORT=proxy_port_number The port number of the proxy sever. If you are not using a proxy, leave this field blank. STRESOLVELOCALY75= The proxy resolves local flag . Specify true or false. STPROXYUSERNAME= The user name for the proxy server. If you are not using a proxy, leave this field blank. STPROXYPASSWORD= The password for the proxy server. If you are not using a proxy, leave this field blank. STCOUNTRYLANG=en The language to be used by the Connect client. Specify the language code for the language to be used. The default vlaue is English. If a value is not specified, the client computer's default language is used. STAUTHSERVERURL= The URL of the authorization server for the SSO token log in. If you are not using an authorization server, leave this field blank. STLOGINBYTOKEN=false Specify whether to use the Login By Token flag. The default value is false. STUSEAUTHSERVER=false Specify whether to use the authorization server flag. The default is false. STLOGINATSTARTUP=false Specify whether the client logins at startup. The default is false. STUNINSTALL75=1 Specify whether to uninstall an existing 7.5 client if present. 1 Uninstall 7.5.x client if found 0 Leave 7.5.x client installed STUNINSTALLPRE75=1 Specify whether to uninstall an existing pre-7.5 client if present. 1 Uninstall pre-7.5 client if found. This is the default value. 0 Leave pre-7.5 client installed After you have edited the files to tailor the installer for your specific requirements, you can distribute the files to your end users. If the users are to run the installer, instruct them users to copy both of the files to the same directory and then execute setup.bat to install Sametime Connect.
Download the client installation package.
Copy the setup.bat and the silentinstall.ini files from the root of the download, and then update the files to meet your requirements.
Update the setup.bat file if necessary.
Update the silentinstall.ini file to match the environment.
Send or copy the updated files to the user's computer.
To start the install, run the following command:
setup.bat -silentinstall.ini\nParent Topic: Installing Sametime clients
"},{"location":"admin/installing_docker.html","title":"Installing Docker","text":"This section provides information on how to install Docker.
All commands provided require running as ROOT or SUDO access. If not running as root user, preface all commands with sudo.
Before installing Docker Compose, make sure Docker Engine is installed either locally or remote, depending on the environment. On Linux systems, install the Docker Engine for your OS provided in Install Docker Engine documentation. If you are following the Docker documentation to install the Docker Engine, docker compose must also be installed.
The following is an example of the install Docker Engine on CentrOS based on Docker documentation to support docker compose commands used when installing Sametime. The example is for demonstration only.
Note: CentOS ships with Docker installed, but not the most recent which is required. Install supported Docker version. See the HCL Sametime\u00ae System Requirements for details.
Uninstall old versions using the yum remove command provided in the Docker Engine documentation.
Install Docker Engine using a repository. First, install the yum-utils package which provides the yum-config-manager utility.
sudo yum install -y yum-utils \nThen set up the stable repository.
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo\nInstall the latest version of Docker Engine and container.
yum install docker-ce docker-ce-cli containerd.io \nAt this point, Docker is installed but might not be started.
Start Docker.
systemctl start docker \nVerify that Docker Engine is installed correctly by running the hello-world image.
docker run hello-world \nNote: If you right click links like Install Docker Compose and choose Open link in Tab you can complete these tasks and then close that tab to start the next step.
Install Docker Compose following steps and commands provided in Install Docker Compose topic in the Docker documentation. Docker Compose 1.29 or higher is required.
The following is an example of the install Docker Engine on CentrOS based on Docker documentation. The example is for demostration only.
Install Compose on Linux systems.
curl -L \"https://github.com/docker/compose/releases/download/1.29.0/docker-compose-$(uname -s)-$(uname -m)\" -o /usr/local/bin/docker-compose \nApply executable permissions to the binary.
chmod +x /usr/local/bin/docker-compose \nTest the installation.
docker-compose --version \nAfter the install is complete, use the following Linux shell command to confirm that Docker is running, which returns the docker information.
docker info\nIf Docker is not running, an error message is displayed indicating that a connection to Docker cannot be completed.
To start the Docker service, run the following command.
service docker start\nParent topic: Installing Sametime in a Docker or Podman environment
"},{"location":"admin/installing_mongodb_linux.html","title":"Installing MongoDB on Linux","text":"MongoDB can be downloaded from the MongoDB website. This topic includes the steps for installing in CentOS and RHEL environments. For information on installing MongoDB on other operating systems, refer to Install MongoDB.
If you already have MongoDB installed and are upgrading to MongoDB 4.4 or to the latest patch release, see the Upgrade to the Latest Revision of MongoDB document.
The commands used during the installation process require running as ROOT or SUDO access. If not running as root user, preface all commands with sudo.
Note: In the following steps, MongoDB version 4.4 is used as an example. If you are using a different version of MongoDB, refer to the MongoDB documentation for how to issue commands for the version that you are using.
Create a repository file for YUM to install MongoDB. Use the VI command to create and edit the mongodb-org-4.4.repo file.
cd /etc/yum.repos.d \n vi mongodb-org-4.4.repo\nNote: The vi command is a screen-oriented text editor originally created for the Unix operating system.
To edit the file, use Insert (I) and then copy and paste the following content:
[mongodb-org-4.4] \nname=MongoDB Repository \nbaseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.4/x86_64/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://www.mongodb.org/static/pgp/server-4.4.asc \nNote: When copying and pasting, ensure to include all characters. The dash (-) in the baseurl can be removed in certain scenarios.
Press Esc to exit insert mode.
To save and exit, use the wq command. Precede the command with a colon (:).
If you receive a E212: Can\u2019t open file for writing error message, it means that a root user is not being used or sudo access is being used.
If the repo URL is not available, manually download and install the rpm files. You can download the files from the Index of RPMS download page. For example:
mongodb-database-tools-100.5.1.x86_64.rpm \nmongodb-org-shell-4.4.9-1.el7.x86_64.rpm \nmongodb-org-tools-4.4.9-1.el7.x86_64.rpm \nmongodb-org-server-4.4.9-1.el7.x86_64.rpm \nmongodb-org-mongos-4.4.9-1.el7.x86_64.rpm \nmongodb-org-database-tools-extra-4.4.9-1.el7.x86_64.rpm \nmongodb-org-4.4.9-1.el7.x86_64.rpm\nAfter the download completes, install:
yum localinstall mongodb-database-tools-100.5.1.x86_64.rpm -y \nyum localinstall -y mongodb-org-database-tools-extra-4.4.9-1.el7.x86_64.rpm \nyum localinstall -y mongodb-org-4.4.9-1.el7.x86_64.rpm mongodb-org-mongos-4.4.9-1.el7.x86_64.rpm mongodb-org-server-4.4.9-1.el7.x86_64.rpm mongodb-org-shell-4.4.9-1.el7.x86_64.rpm mongodb-org-tools-4.4.9-1.el7.x86_64.rpm -y \nExecute YUM to install the MongoDB package.
yum install mongodb-org \nType y to confirm the download size.
Type y to accept the GPG key import.
A Complete! message is displayed when the installation process is finished.
Verify that the MongoDB components, user, default log, and data directories are created by checking if the following directories exist and are owned by mongod.
/var/log/mongodb
/var/lib/mongo
To start the MongoDB server, enter the command:
service mongod start\nTo stop the MongoDB server, enter the command:
service mongod stop\nTo verify the status of the MongoDB service, enter the command:
systemctl status mongod\nSet up a replica set with keyfile access control
Parent Topic: Installing MongoDB
"},{"location":"admin/installing_mongodb_windows.html","title":"Installing MongoDB on Windows","text":"MongoDB can be downloaded from the MongoDB website. This topic guides you through the steps for installing MongoDB on Windows.
For additional information on installing MongoDB on Windows, refer to Install MongoDB Community Edition on Windows.
Note: In the following steps, MongoDB version 4.4 is used as an example. If you are using a different version of MongoDB, refer to the MongoDB documentation for instructions on how to issue commands for the version that you are using.
Download the latest MongoDB version from the Download MongoDB Community Server page.
In the Available Download section, select the version to download.
From the Platform field, select Windows.
From the Package field, selectmsi. You have the option to download a msi or zip file.
Select Download.
Navigate to the folder where the MongoDB installation file was downloaded and run the msi file. This starts the installation process.
Follow the MongoDB Setup Wizard to complete the install. Select Next to view the license agreement. To continue, accept the license and select Next.
On the Choose Setup Type window, select Complete.
On the Service Configuration window, specify the following options and then select Next.
Installing MongoDB Compass\u202fis optional and not required for deploying Sametime. Clear the checkbox for Install MongoDB Compassand select Next.
If MongoDB Compass is installed, it starts after the installation process completes. You can shut down the MongoDB Compass application, as it is not used for Sametime deployments.
Select Install to complete the MongoDB installation. During the installation process, you might be prompted about files that cannot be updated while the system is running. You can choose to continue and manually restart the computer later.
After the install process completes, you must restart your computer.
When the installation process is complete, select Finish.
After the system restart, MongoDB automatically runs as a Windows service.
Verify that MongoDB installed successfully by opening the MongoDB console. To open the console, navigate to the MongoDB installation directory and locate the bin directory. For example: C:\\Program Files\\MongoDB\\Server\\4.4\\bin. Start the mongo application.
To close the console, type Exit on the command line.
Set up a replica set with keyfile access control
Parent Topic: Installing MongoDB
"},{"location":"admin/installing_on_docker.html","title":"Installing Sametime on Docker or Podman","text":"Installing Sametime involves starting the install procedure and specifying configuration information for the server, such as the credentials, the ports, MongoDB, and LDAP that the server uses.
Download the product from the HCL Software Portal.
The installation process detects if you are installing Sametime on Docker or Podman and prompts for the appropriate information.
Docker commands are used throughout the install process. All commands require running as a root user. If not running as root user, you must preface all commands with sudo. If you are installing on Podman, the commands are the same but instead of being preceded with Docker, the command is preceded with Podman.
Verify that the product files downloaded and extract to the desired installation directory.
Change to the installation directory and verify that the permissions are set correctly by running the following commands:
cd sametime\\_install\nls -la\nWhere sametime_install is the installation directory.
From the installation directory, run the Sametime install command.
./install.sh\nThe install command begins the installation of the Sametime product.
Enter the information for the prompts.
You are prompted to enter the following information. See Information to provide during installation.
If you are defining extra hosts, see Defining extra hosts for Docker deployments.
After the installation is completed, the HCL Sametime services that support chat and meetings should be running.
Test the Sametime chat and meeting services. For details, see Testing Sametime chat and meeting clients.
Parent Topic: Installing Sametime in a Docker or Podman environment
"},{"location":"admin/installing_sametime_clients.html","title":"Installing Sametime clients","text":"Sametime clients can be installed on a Windows or Mac machines.
Beginning with Sametime version 11, all directories and registries are HCL branded. If you are upgrading from a previous Sametime client, you must uninstall that version and then install Sametime version 11 or later. For version 12, upgrades on Windows and Mac are supported from a Sametime 11 client. Upgrades from a 9.0.1 or earlier versions on Windows are not supported. If you run a version of Sametime that is not supported for upgrades, you must uninstall that version and then install Sametime 11.
"},{"location":"admin/installing_sametime_connect_and_embedded.html","title":"Installing Sametime Connect and Embedded clients on Windows","text":"This topic covers basic installation for the Sametime standalone client on Windows.
Before getting started, it review the client installation customization options. Customizing the client can ease your deployment.
Decompress the client installation package into a temporary directory.
In the temporary directory, locate and double-click SETUP.EXE.
The installation process begins. When prompted, select the language to be displayed in the installation wizard windows.
From the Welcome screen, click Next.
On the License Agreement screen, review the license information.
To continue click I accept the terms in the license agreement and then click Next.
On the next screen, specify where to install the client and then click Next.
The default value for the Install location field is C:\\HCL\\Sametime Connect. You can select another location, you must remember it for future tasks.
Click Install to start the install process.
After the install is complete, click Finish.
Parent Topic: Installing Sametime clients
"},{"location":"admin/installing_sametime_connect_and_embedded_macos.html","title":"Installing Sametime Connect and Embedded clients on MacOS","text":"This topic covers basic installation for the Sametime standalone client on MacOS.
Before getting started, it review the client installation customization options. Customizing the client can ease your deployment.
Decompress the client installation package into a temporary directory.
In the temporary directory, locate and double-click SETUP.EXE.
The installation process begins. When prompted, select the lanaguage to be displayed in the installation wizard windows.
From the Welcome screen, click Next.
Review the license information.
To contine, click I accept the terms in the license agreement and then Next.
On the next screen, specify where to install the client and then click Next.
The defalt value for the Install location is C:\\HCL\\Sametime Connect. You can select another location, you must remember it for future tasks.
Click Install to start the install process.
After the install is complete, click Finish.
Parent Topic: Installing Sametime clients
"},{"location":"admin/installing_sametime_ios_and_android.html","title":"Installing Sametime iOS and Android clients","text":"You can find the latest HCL Sametime mobile clients in the Apple App Store and Google Play Store.
Refer to the Sametime mobile documentation for more information on mobile clients.
Parent Topic: Installing Sametime clients
"},{"location":"admin/keystore_third_party.html","title":"Creating a keystore for Sametime mux: third-party CA","text":"Two scenarios are described in this topic.
Scenario 1: A single certificate and private key are issued from the CA. : 1. Run the command to create the keystore.
``` {#codeblock_ych_tnq_ywb}\nopenssl pkcs12 -export -in server.crt -inkey server.key -name \u2018mux\u2019 -out keystore.p12\n```\n\nThe sample command makes use of the following naming conventions.\n\n``` {#codeblock_yqh_vpq_ywb}\n`server.crt`: Signed certificate filename\n`server.key`: Private key filename\n`\u2018mux\u2019`: Alias name (how it appears in the keystore)\n`keystore.p12`: The resulting keystore file name\n```\nScenario 2: A chained certificate which consists of multiple certificate files are provided, along with the private key. : 1. Use cat to combine the certificates into a single file (cert-chain.txt), which is used in the command. These certificates must be combined in this order: server, intermediate, CA root.
``` {#codeblock_zst_fqq_ywb}\ncat signed.crt intermediate.crt root_CA.crt > cert-chain.txt \n```\n\nIn the above example, the server\u2019s signed cert is `signed.crt`, the intermediate certificate is `intermediate.crt`, and the root CA certificate is `root_CA.crt`.\nRun the command to create the keystore.
openssl pkcs12 -export -in cert-chain.txt -inkey server.key -name \u2018mux\u2019 -out keystore.p12\nThe sample command makes use of the following naming conventions.
cert-chain.txt: File created from step 1 containing chained cert\nserver.key: Private key filename\n\u2018mux\u2019: Alias name \n`keystore.p12`: The resulting keystore file name\nAfter the keystore is created, do the following:
Parent Topic: Creating a keystore for Sametime mux
"},{"location":"admin/ldap.html","title":"LDAP","text":"An LDAP directory is needed for Sametime user authentication. The LDAP server must be running before deploying Sametime.
"},{"location":"admin/ldap.html#section_u2g_vbh_fwb","title":"System requirements","text":"Sametime works with V3-compliant LDAP servers.
"},{"location":"admin/ldap.html#section_kzg_qch_fwb","title":"Performance","text":"LDAP performance is critical to a successful deployment. Sametime is going to put a heavy load on LDAP. Consider the performance requirements of all Sametime LDAP traffic:
Part of your deployment plan may include adding more cluster members to the LDAP cluster.
To minimize the burden on LDAP, use minimal search filters wherever possible. Log in choices such as name, email address, employee ID, and so on, create longer search filters and greater performance loads on LDAP.
When planning for LDAP, don't forget Single Sign-On (SSO). Talk to your company's application teams about SSO. Propose a standard way that you allow people to log in to keep logins simple and minimal. All applications should utilize LDAP in the same way. If applications have different search filters, then this creates search problems and authentication problems.
"},{"location":"admin/ldap.html#section_jvf_rch_fwb","title":"Mail attribute","text":"Sametime requires the LDAP mail attribute in each person record.
The mail attribute provides performance advantages since translation between attributes is not required; it also provides consistency and integrity by using a common and well-understood attribute.
This attribute is not required for anonymous (guest) users. The attribute must be a unique string, which preferably follows the syntax and length restrictions of email addresses. In addition, the mail attribute must be populated for every user to support audio and video communications.
The mail attribute is not used for email purposes and does not have to be assigned as a user name for logging into Sametime. Instead, it serves as a common attribute between the various Sametime subsystems, such as calendar integration, business cards, LDAP, and REST APIs.
"},{"location":"admin/ldap.html#section_pkk_tch_fwb","title":"Multiple directory support","text":"Multiple directories are supported with the following restrictions:
If you use multiple LDAP repositories, you must ensure that the base entries do not overlap, as that causes problems when Secure Socket Layer (SSL) is enabled.
For example, the following base entries have a field in common, so they overlap:
o=renovations\no=sales,o=renovations\nThese base entries use different fields and are acceptable:
o=renovations,c=us\no=sales\nSametime might experience difficulties when users include large public groups in their contact lists. To avoid problems, limit the size of public groups used with Sametime to 1000 users.
"},{"location":"admin/ldap.html#section_un4_xch_fwb","title":"Upgrade considerations","text":"If you are considering moving from a native Domino directory to an LDAP directory, you must convert the user\u2019s names in the vpuserinfo.nsf file to LDAP format. This is done using the Sametime Name Conversion utility.
"},{"location":"admin/ldap.html#section_vdc_zch_fwb","title":"Best Practices","text":"The Best Practices for using LDAP with Sametime white paper contains an overview of LDAP components and describes how the Sametime Community Server works with LDAP to provide authentication, name look-ups, and name resolution. The article describes best practices for creating search filters, setting sametime.ini parameters, and enhancing Sametime and LDAP performance.
Parent Topic: Prerequistes
"},{"location":"admin/load_stimages_local.html","title":"Loading the Sametime images to a Docker repository","text":"The Sametime images must be in a Docker repository so that they can be accessed when running Sametime. They can be in a local Docker repository or they can be accessed from the HCL Docker repository.
If you prefer to use a local Docker repository, move the Sametime images from the product download file into the repository.
Download the HCL Sametime installation file from the HCL Software download portal.
The compressed file contains Sametime images, managed charts, scripts, configuration files and more.
Extract the zip file to any directory on the master Kubernetes host itself or on a machine which has management access to the Kubernetes cluster.
Change to that directory and load the docker images into your docker registry using the following command.
./load.sh\nThe load script extracts the docker images to the local host by default. When prompted, specify your Docker registry host FQDN. This can be a cloud provider registry or a private registry accessible to all of the nodes. If you do not have your own registry, run the load script on each node in the Kubernetes cluster and use the script defaults.
Note: If the commands fails accessing the Docker daemon, you can run the following command:
sudo ./load.sh\nUsing the sudo command temporarily gives you administrator privileges. For security purposes, it is best that you have administrator access than running with elevated privileges.
See Preparing the deployment.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/ltpa_configure_connections.html","title":"Integrating with HCL Connections","text":"You can integrate Sametime to enable chat services in HCL Connections.
Sametime and Connections must share a common directory.
If you are enabling the HCL Connections Profiles Photo URLs in your Sametime business card configuration, single sign on (SSO) might be required for Sametime to access the URLs.
When integrating with Connections, the LTPA key is generated by HCL Connections. To integrate with Sametime, you need to complete the steps in this topic on the Connections server and then complete the configuration on environment which Sametime is running: Docker or Kubernetes.
For SPNEGO and KERBEROS enabled environments, find the realm name.
This step is not needed if not using SPNEGO and KERBEROS.
Log into the WebSphere Application Server Integrated Solutions Console on the Deployment Manager.
Click Security > Global security.
Click Configure \u2026
On the Federated Repositories page, the Realm Name field contains the name.
Locating the domain name.
Click Security > Global security.
In the Authentication mechanisms and expiration area, expand Web and SIP security and select Single sign-on (SSO).
The Domain name field...
In the Domain name field, ensure that the DNS suffix for the Connections environment is present and preceded with a dot. If the Sametime DNS suffix is different from the Connections DNS suffix, then append it to the Domain name field as well. All DNS suffixes listed should be preceded with a dot.
For example: .example1.com example2.com
Select the check boxes for Interoperability Mode (optional) and Web inbound security attribute propagation. Make sure Set security to HTTP Only is not enabled.
Restart your Connections deployment.
If LTPA Export the LTPA key file.
Log into the WebSphere Application Server Integrated Solutions Console on the Deployment Manager.
Click Security > Global security.
In Authentication > Authentication mechanism and expiration select LTPA.
In the Password and Confirm password fields, enter the password that protects the exported key.
In the Fully qualified key file name field enter the path and file name for the key file that you want to generate
Click Export keys
Select Apply and then select Save.
Enter a file name and path to save the LTPA keys. The file will be exported to the Deployment Manager. This file needs to be retrieved from the Deployment Manager machine to be imported into Sametime.
Retreive the exported LTPA key file.
After obtaining the LTPA keys from HCL Connections, follow the steps in the Configuring LTPA in Docker or Podman or Configuring LTPA in Kubernetes topic.
Parent Topic: Setting up SSO using LTPA
"},{"location":"admin/ltpa_configure_docker.html","title":"Configuring LTPA in Docker or Podman","text":"This topic includes the steps to configure LTPA keys on Docker.
Update the .env file to reflect the following attributes and values.
ENABLE_LTPA=true\nLTPA_KEYS_FILE_PATH=key\\_file\\_path\nLTPA_KEYS=/ltpa-config/ltpa.keys\nLTPA_KEYS_PASSWORD=liberty\\_server\\_password\nLTPA_DURATION_MINUTES=minutes\\_token\\_valid\nThe value for key_file_path must be the absolute path to the file. For example, if keys are in the ltpa.key file and in the /opt/hcl/sametime directory.
LTPA_KEYS_FILE_PATH=/opt/hcl/sametime/ltpa.keys\nThe value of LTPA_DURATION_MINUTES must be the same as the value for the Domino web SSO token expiration.
Update the custom.env file to include the following.
STI__ST_BB_NAMES__ST_AUTH_TOKEN=Fork:Jwt,Ltpa\nUpdate the docker-compose.yml file to include the following.
SAMETIME_EXTERNAL_WARINTEGRATION=true\nOptional: If integrating with Connections and using a realm, add the realm name to the .env. For more information on integrating with Connections, see Integrating with HCL Connections.
LTPA_REALM=<realmname>\nParent Topic: Setting up SSO using LTPA
"},{"location":"admin/ltpa_configure_domino.html","title":"Integrating Sametime with HCL Domino","text":"This topic includes the procedure to enable LTPA when Sametime is integrated with the Domino server for use with web based mail, Verse and iNotes.
Before you start you need an LTPA key which as an example can be generated by WebSphere Liberty. For more information on using WebSphere Liberty to generate LTPA keys, see Generating LTPA keys.
You also must configure the LTPA keys on the Sametime server.
To configure the Domino server, you must create a Web SSO configuration document and import the WebSphere LTPA keys. The following procedure describes the steps which are completed on the Domino mail server.
Open the names.nsf and select the Web Configurations. Edit the Web SSO LtpaToken document.
Note: If a Web SSO LtpaToken document does not exit, it must be created from the Notes or Admin client Create menu. See Creating a Web SSO configuration document for the details.
Select Keys > Import WebSphere LTPA Keys.
Specify the path to the LTPA Keys file created following Generating LTPA keys and select OK.
Note: If prompted, select Format: LtpaToken and LtpaToken2 as the Use Token value.
Save and close the Web SSO LtpaToken document.
In the Domino mail server document under Internet Protocols - Domino Web Engine, select Multiple Servers (SSO) as the session authentication.
Start the Domino and Sametime servers to apply the changes. For more information, refer to Starting and stopping the Sametime server.
Parent Topic: Setting up SSO using LTPA
"},{"location":"admin/ltpa_configure_kubernetes.html","title":"Configuring LTPA in Kubernetes","text":"If you did not enable LTPA authentication during the installation of Sametime, you can enable it manually.
You must have already obtain the LTPA keys before you can compete this task. For more information on using WebSphere Liberty to generate LTPA keys, see Generating LTPA keys.
The changes in this task affect the following pods:
Obtain the base64 encoded value for your LTPA key file. The LTPA key file can be named anything and might have a file extension. For example if your LTPA key file name is ltpa.keys. Enter the following command to base64 encode the file:
cat ltpa.keys | base64 -w 0\nFor managed charts: ltpaKeysBase64: value
For traditional charts: ltpa.keys: value
Obtain the base64 encoded password to the LTPA Key file. For example, if the password is ltpapassword, enter the following command:
echo -n \u2018ltpapassword\u2019 | base64\nltpaKeysPasswordBase64: value\nDetermine the SSO token expiration time, which must be the same for all participating servers. To find the value in Connections see Integrating with HCL Connections. To find the value in Domino, see Creating a Web SSO configuration.
Now that you know the number of minutes until the token expires, create a new parameter and set it to the number of minutes. For example if the number of minutes is 120, then the parameter is:
ltpaDurationMinutes: \"120\"\nltpa.key file and find the name of the WebSphere realm. cat ltpa.key\nLook for the com.ibm.websphere.ltpa.Realm=defaultWIMFileBasedRealm parameter.
Create a new parameter with the value, for example:
ltpa.realm: defaultWIMFileBasedRealm\nIf you are using the managed charts, use the following steps. If you are using traditional charts, scroll down to the next section for traditional charts.
values.yaml file for editing. In the global section, add the parameters determined from above. Each line is indented with two spaces.
ltpaKeysBase64: value\n ltpaKeysPasswordBase64: value\n ltpaDurationMinutes: \"value\"\n ltpa.realm: value (for Connections only)\nAdd the following parameter to enable LTPA.
enableLtpa: true\nSave and close your custom values.yaml file.
For these changes to take effect, you must uninstall Sametime, then re-install referencing your custom values.yaml file.
If you are enabling LTPA using traditional helm charts instead of using the managed charts, complete the following steps.
Open the values.yaml file in the helm directory for editing.
Locate the following line and change the value from false to true.
enableLtpa\nAdd the parameters:
ltpaDurationMinutes: \u201cvalue\u201d\nltpa.ream: value (for Connections only)\nltpaKeysPasswordBase64: value \nSave and close the values.yaml file.
Change directories to helm/templates.
Open the auth-config-secrets.yaml file for editing.
In the ltpa.keys field, remove the text that is there, and add the base64 encoded value from step 1.
Save and close the auth-config-secrets.yaml file.
For these changes to take effect, complete the steps in Applying Changes.
If you are integrating with HCL Connections or HCL Verse, it might be beneficial to add a content security policy that includes the DNS suffix of the servers participating in the LTPA Single Sign On. For information, see Enabling content security headers on Kubernetes.
"},{"location":"admin/ltpa_generate_key.html","title":"Generating LTPA keys","text":"Lightweight Third Party Authentication (LTPA) uses keys to encrypt and decrypt data being passed.
The generated keys must be shared and configured within the Sametime server and must be available before you can configure SSO using LTPA.
Using an instance of Websphere Liberty is one method that you can use to generate LTPA keys. When the Websphere Liberty server is started an LTPA key is created. You can copy the key onto both the host machine and the Domino server.
From Docker, issue the following command to start a Websphere Liberty server.
docker run -d -p 9080:9080 -p 9443:9443 websphere-liberty:latest\nCopy the key from ltpa.keys from that instance:
docker cp container\\_id:/output/resources/security/ltpa.keys ./ltpa.keys\ncontainer_id is the Websphere Liberty container ID. To obtain the container ID, open a terminal and issue the following command:
docker ps\nThe default password used by Websphere Liberty is WebAS.
Configure the LTPA keys in Docker or Kubernetes where Sametime is running.
Parent Topic: Setting up SSO using LTPA
"},{"location":"admin/managed_community.html","title":"Managed community settings","text":"Define managed community settings in the managed-community-configs.xml file.
The managed-community-configs.xml file uses these element types:
Only define attributes that are mandatory. For example, do not include the \"loginAtStartup\" attribute unless you want to prevent your users from changing that setting. If the user's configuration differs from any defined attribute, the user's configuration is updated. Although you cannot lock the user interface, any settings that a user changes during a session revert back at the next login.
The following tables describe the attributes for each element. The required attributes must be present in the file.
Attribute Required? Description deleteOverlappingCommunities No Whether or not overlapping duplicate communities should be deleted. The default is \"false\". An overlapping community is one in which the community host and userid are the same. An overlapping duplicate community can occur when you use a managed-community-configs.xml file to consolidate multiple hosts into a single community. The Sametime\u00ae client may have a community for each host; updating each to the same new host name would result in duplicate overlapping communities. To ensure that duplicate overlapping communities are consolidated into one, set this attribute to true. id Yes The unique ID of the managed community. This setting should be the same value as the \"host\" attribute. host Yes The host to manage. The client only updates communities whose host matches the host of the managed community. newHost No Attribute used to update the host of a community that matches the \"host\" attribute. This is the new host to connect to. The attribute only applies to \"update\" type managed community actions. The user's contact list is assumed to be valid for the new community. If the contact list is not valid, use the \"reset\" managed community action instead. name No The name of the community. Not recommended. To set the community ID, use ST_COMMUNITY_ID in the server's sametime.ini to set the community name for all clients. savePassword No Whether or not to save the password. Set the value to \"true\" to save the password. loginAtStartup No Whether or not to automatically log in. Set the value to \"true\" to log in automatically. useGlobalConnContext No Whether or not to use the global connection context. You must set this to \"true\" if you are updating connectionType to a value other than \"direct\". connectionType No The connection type corresponds to the options in the Connection settings page. Valid values include useBrowserSettings, direct, tls-direct, http-direct, socks4-proxy, socks5-proxy, http-proxy, and reverse-proxy. authServerUrl No The server URL for SSO authentication. authType No The authentication type for SSO. Value can either be TAM-SPNEGO or ST-DOMINO-SSO. port No The port to use if it is not the default 1533. proxyHost No The hostname of the proxy. proxyPort No The port of the proxy. loginByToken No Whether or not to log in by token. Set the value to \"true\" to log in by token. Note that if the token login fails and the password is available, the password-based authentication will proceed. sendKeepAlive No Whether or not to send the keep alive signal. Set the value to \"true\" to send the keep alive signal. keepAliveInterval No The interval at which to send the keep alive signal. Attribute Required? Description managed-community-id Yes The unique ID of the managed-community. Use the same value as the \"host\" attribute of the managed community type Yes The type of action. Values can be \"update\", \"add\", \"delete\" or \"reset\".- Add actions result in the addition of secondary communities. - Delete actions result in the deletion of secondary communities. The default community cannot be deleted. - Update actions result in an update to communities whose host value match the host value of the managed community. If no attributes are different, the update action does not result in any change. - Reset actions are used to reset the client configuration to a new default community. If a reset action is found, it is applied before any other action type and no other actions are processed. The user is prompted to restart, but may opt not to. The managed community referenced by the reset action represents the new default community that is to be used when the user next restarts.| |restart|No|By default, update actions only result in a restart if the host name is changed. Add this optional attribute and set the value to \"true\" to restart the client after other update events. To prevent the default restart after the host name is changed, add this attribute, but set it to \"false.\"| |applyDefaultCommunityUsername|No|Attribute that can be used with an \"add\" type managed community action to indicate whether or not the default community user name should be applied to the new community when it is added. Set the value to \"true\" apply the default community user name.| |createNewConfig|No|Optional attribute for use with the reset action type. When you set this to \"true,\" the previous default community is completely replaced by the new community. The user name and password are empty, requiring the user to repopulate these values. Without this attribute, or with the attribute set to false, the new default community configuration enabled with a reset action retains the user name, password, and connection options of the former default community.|
"},{"location":"admin/managed_community.html#sample-managed-community-configs-file","title":"Sample managed-community-configs file","text":"The following sample file adds a new community and updates two others. The connection type is reverse-proxy.
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<managed-communities>\n <managed-community id=\"sales.usma.example.com\" host=\"sales.usma.example.com\" loginByToken=\"true\" authServerUrl=\"http://sales.usma.example.com\" authType=\"SAMPLE\" useGlobalConnSettings=\"false\">\n <connection connectionType=\"reverse-proxy\" proxyHost=\"http://usma.example.com:81/sales\"/>\n </managed-community>\n <managed-community id=\"sametime.example.com\" host=\"sametime.example.com\" newHost=\"sametimenew.example.com\"/>\n <managed-community id=\"sametimenew.example.com\" host=\"sametimenew.example.com\"/>\n <managed-community-action type=\"update\" managed-community-id=\"sales.usma.example.com\"/>\n <managed-community-action type=\"update\" managed-community-id=\"sametime.example.com\"/>\n <managed-community-action type=\"add\" managed-community-id=\"sametimenew.example.com\"/>\n</managed-communities>\nAction examples
Adding a new community
The following example adds a new secondary community using the global connection defaults. Administrator-defined secondary communities are not impacted by the Allow user to add multiple server communities policy. Even if the policy is set to Not selected, the client recognizes they are defined by the administrator and allows the user to log into them. Administrator-defined communities cannot be deleted.
<managed-communities>\n<managed-community id=\"acct.sales.usma.example.com\" host=\"acct.sales.usma.example.com\"/>\n<managed-community-action type=\"add\" managed-community-id=\"acct.sales.usma.example.com\"/>\n</managed-communities>\nUpdating the default community host
This example updates the default community host from \"sales.usma.example.com\" to \"sales2.usma.example.com.\"
<managed-communities>\n<managed-community id=\"sales.usma.example.com\" host=\"sales.usma.example.com\" newHost=\"sales2.usma.example.com\"/>\n<managed-community-action type=\"update\" managed-community-id=\"sales.usma.example.com\"/>\n</managed-communities>\nUpdating the default community host again
This example updates the default community host from \"sales.usma.example.com\" or \"sales2.usma.example.com\" to \"sales3.usma.example.com.\"
<managed-communities>\n<managed-community id=\"sales.usma.example.com\" host=\"sales.usma.example.com\" newHost=\"sales3.usma.example.com\"/>\n<managed-community id=\"sales2.usma.example.com\" host=\"sales2.usma.example.com\" newHost=\"sales3.usma.example.com\"/>\n<!-- Ensure existing sales community hosts that missed the first \"sales2\" update, or that manually reverted, are updated to sales3 -->\n<managed-community-action type=\"update\" managed-community-id=\"sales.usma.example.com\"/>\n<!-- Ensure existing sales2 community hosts are updated to sales3 -->\n<managed-community-action type=\"update\" managed-community-id=\"sales.usma.example.com\"/>\n</managed-communities>\nUpdating the secondary community host
This example updates \"acct\" to \"acct2\" and ensures acct2 is added as a secondary community for all new users.
<managed-communities>\n<managed-community id=\"acct2.sales.usma.example.com\" host=\"acct2.sales.usma.example.com\" />\n<managed-community id=\"acct.sales.usma.example.com\" host=\"acct.sales.usma.example.com\" newHost=\"acct2.sales.usma.example.com\" />\n<!-- Ensure acct2.sales.usma.example.com community is created for all users that don't yet have it -->\n<managed-community-action type=\"add\" managed-community-id=\"acct2.sales.usma.example.com\"/>\n<!-- Ensure existing acct.sales.usma.example.com community hosts are updated to acct2.sales.usma.example.com -->\n<managed-community-action type=\"update\" managed-community-id=\"acct.sales.usma.example.com\"/>\n</managed-communities>\nUpdating the secondary community host again
This example updates \"acct2\" to \"acct3\", and also ensures acct3 is added as a secondary community for all new users.
<managed-communities>\n<managed-community id=\"acct3.sales.usma.example.com\" host=\"acct3.sales.usma.example.com\"/>\n<managed-community id=\"acct2.sales.usma.example.com\" host=\"acct2.sales.usma.example.com\" newHost=\"acct3.sales.usma.example.com\" />\n<managed-community id=\"acct.sales.usma.example.com\" host=\"acct.sales.usma.example.com\" newHost=\"acct3.sales.usma.example.com\" />\n<!-- Ensure acct3.swg.usma.hcl.com community is created for all new users -->\n<managed-community-action type=\"add\" managed-community-id=\"acct3.sales.usma.example.com\"/>\n<!-- Ensure existing acct2.sales.usma.hcl.com community hosts are updated to acct3.sales.usma.example.com -->\n<managed-community-action type=\"update\" managed-community-id=\"acct2.sales.usma.example.com\"/>\n<!-- Ensure existing acct2.sales.usma.example.com community hosts that missed the first \"acct2\" update, or that manually reverted, are updated to acct3.sales.usma.example.com -->\n<managed-community-action type=\"update\" managed-community-id=\"acct.sales.usma.example.com\"/>\n</managed-communities>\nSwitching users to a new default community with a different user directory
If the new community is a different community with a different user backend, use the reset managed-community-action type to reset the user to the new community. Assuming the user credentials are valid in the new community, after restarting, the user logs into the new community. To include additional secondary communities as part of this new configuration, define them on the new server's managed-community-configs.xml file, using add actions for the desired secondary communities. When the reset action is found, if the current default community does not match the community defined by the administrator, or if createNewConfig is set to true, the client saves the new configuration locally. When the client next restarts, the default community defined by the administrator replaces the previously defined default community.
<managed-communities>\n<managed-community id=\"acct.sales.usma.example.com\" host=\"acct.sales.usma.example.com\"/>\n<managed-community-action type=\"reset\" managed-community-id=\"acct.sales.usma.example.com\"/>\n</managed-communities>\nConsolidating multiple communities to a single community
This example consolidates multiple communities with various hosts into a single community with one host.
<managed-communities deleteOverlappingCommunities=\"true\">\n<managed-community id=\"sales1.usma.example.com\" host=\"sales1.usma.example.com\" newHost=\"sales.usma.example.com\"/>\n<managed-community id=\"sales2.usma.example.com\" host=\"sales2.usma.example.com\" newHost=\"sales.usma.example.com\"/>\n<managed-community id=\"sales3.usma.example.com\" host=\"sales3.usma.example.com\" newHost=\"sales.usma.example.com\"/>\n<managed-community-action type=\"update\" managed-community-id=\"sales1.usma.example.com\"/>\n<managed-community-action type=\"update\" managed-community-id=\"sales2.usma.example.com\"/>\n<managed-community-action type=\"update\" managed-community-id=\"sales3.usma.example.com\"/>\n</managed-communities>\nParent Topic: Updating connectivity settings with the managed-community-configs.xml file
"},{"location":"admin/managing_sametime_client_preferences.html","title":"Managing Sametime clients","text":"This section provides information on managing Sametime clients.
Parent Topic: Administering
"},{"location":"admin/managing_sametime_premium.html","title":"Managing Sametime features","text":"HCL Domino users are entitled to limited use of HCL Sametime chat capabilities.
The following chat features are not available to HCL Domino users. In Sametime version 12.0, these features are disabled by default.
For a complete list of Sametime features, see Sametime versus Sametime Premium.
Parent Topic: Considerations for Sametime Premium
"},{"location":"admin/managing_secrets_kubernetes.html","title":"Managing secrets in Kubernetes","text":"Sensitive information such as passwords, service account names, certificates, and other confidential data needed by Sametime pods are stored in secrets. In addition to helm charts and configuration map, the Sametime configuration is also derived from secrets.
A secret is considered part of the live runtime or the current configuration. Secrets are created based upon a template or a command line. You can modify the templates to re-create secrets if needed. An example is when you need to update your LDAP bind credentials. For more information see, Changing the LDAP service account password in Kubernetes.
For additional information about secrets in Kubernetes, see the Secrets topic in the Kubernetes documentation.
Some secrets are required by Sametime. They are created during the installation and configuration of Sametime.
Some secrets are required by Sametime and others are based on features being used, such as SAML. The following are global secrets that are required.
"},{"location":"admin/managing_secrets_kubernetes.html#table-1-required-secrets","title":"Table 1. Required secrets","text":"Secret Description Template sametime-global-secrets Thehelm/templates/sametime-secrets.yaml is used to define this secret. helm/templates/sametime-secrets.yaml Note: that all values within this secret are based64 encoded. The following parameters are contained in the global secret.JwtSecret The secret key used by the Sametime service to verify and decide the hash of JWT tokens. LdapBindEntryDn The LDAP Bind account. LdapBindEntryPassword The password for the LDAP bind account. MongoConnectionUrl The MongoDB formatted URL containing the login name and password used by Sametime. The host name and port number are also included. JigasiSipUri The name of the of the account and the host name of the SIP user fortelephony integration with ilink. JigasiSipPassword The password for telephony integration with ilink. ltpaKeysPassword The password for the LTPA keys. MeetingLocationSecret The secret key used to communicate to the primary location service. JvbAuthPassword The password for the JVB authentication account. sametime-internal-keys-secret Contains information about the certificate key store. None tls-secret The name of this secret can vary because it is configurable. The name can also vary depending on the ingress controller. The ingress controller might be secured with a certificate within a secret as well. None The following are default internal secrets and based off the listed template. Do not change the content within these secrets unless instructed by the software support team.
"},{"location":"admin/managing_secrets_kubernetes.html#table-2-internal-secrets","title":"Table 2. Internal secrets","text":"Secret Name Template app-registry-config-secret helm/templates/app-registry-config-secrets.yaml auth-config-secret helm/templates/auth-config-secrets.yaml catalog-config-secret helm/templates/catalog-config-secrets.yamlThe following is a list of optional secrets that are dependent on a feature being enabled, such as SAML.
"},{"location":"admin/managing_secrets_kubernetes.html#table-3-option-secrets","title":"Table 3. Option secrets","text":"Secret name Description extra-community-config A configurable secret that contains extra configuration details for the Community pod. It can contain a copy of the StCommunityConfig.xml, UserInfoConfig.xml, and other community files. ldap-config-secret The certificate trust store and password for LDAP. See Securing LDAP on Kubernetes for more details. saml-config-secret The certificate trust store and password for SAML. See Configuring SAML in Kubernetes for more details."},{"location":"admin/managing_secrets_kubernetes.html#considerations-for-when-namespaces-are-used","title":"Considerations for when namespaces are used","text":"In Kubernetes, the Sametime cluster can be deployed in a namespace which makes administration easier for organizations that have multiple users sharing cluster resources. For example, you might want to run MongoDB in the same Kubernetes cluster as Sametime. They could be separated into different namespaces.
When creating secrets in a Sametime cluster that is scoped to a namespace, the secrets also need to be scoped to the same namespace where Sametime is installed. To define the namespace, add the -n argument followed by the namespace name to the command. For example, the following shows the get command for a namespace with the name st.
kubectl get secrets -n st\nParent Topic: Configuring
"},{"location":"admin/meeting_report_kubernetes.html","title":"Disabling reports on Kubernetes","text":"Change to the helm directory where the Sametime installation package was decompressed.
cd helm\nOpen the values.yaml file and put in edit mode.
Locate the meetingReportsDisabled value and change the value to false.
MeetingReportsDisabled: false\nSave and close the values.yaml file.
Edit the docker-compose.yml file.
Locate the MEETING_REPORTS_DISABLED variable.
Specify true to disallow report generation or false to allow the meeting owner to determine if reports can be generated.
Save the changes.
To apply the changes, stop the Sametime server and then start it again.
Run the following command to stop the server.
docker-compose down\nRun the following command to start the server.
docker-compose up -d\nThis contains configuration steps specific to the HCL Sametime Meetings server.
Parent Topic: Configuring
"},{"location":"admin/meetings_configuring_max.html","title":"Configuring the maximum number of meeting participants","text":"A maximum of 100 users are supported in a meeting regardless of the selected meeting mode. To reach a wider audience, you can start a live stream and share the link to all intended participants.
You can lower the maximum capacity to any value below 100 as needed. Users who attempt to join a meeting that has reached maximum capacity receive a message indicating that the meeting room is full.
The number of meeting video streams that display in the Meeting window is based on the following:
For example, if the maximum number of participants is 50 and value for maximum video streams is 7. The number of participant tiles displayed is fifty. However, the number of displayed video streams is seven, which includes you. That is, six other video streams plus your video stream are displayed. The six participants displayed are the most active video streams and change as participation in the meeting changes.
The default for the maximum number of displayed video streams is nine. To set the maximum to a different value, see Increasing the number of video streams displayed during a meeting.
Parent Topic: Meetings
"},{"location":"admin/meetings_configuring_max.html#task_wwg_dfz_wxb","title":"Configuring the maximum number of meeting participants in Docker environment","text":"Open the docker-compose.yml file for editing.
Under the prosody section, specify the number of maximum participant in the MAX_OCCUPANTS parameter.
MAX_OCCUPANTS=max\\_number\\_meeting\\_participants\nSave the docker-compose.xml file.
Restart the Sametime Meeting server.
Open the helm/values.yaml for editing.
vi helm/values.yaml \nSpecify the number of maximum participant in the MaxOccupants parameter.
MaxOccupants=max\\_number\\_meeting\\_participants \nSave the file.
Restart the Sametime Meetings server.
You can set up your environment to allow users to dial in to a meeting using a SIP-capable phone system that is connected to a public switched telephone network (PSTN). This feature uses the ilink TeamCall Meeting Gateway (TMG).
To enable meeting dial-in, the following must be installed in your Sametime server:
To enable your Sametime environment for dial-in, you must contact an ilink sales representative at sales@ilink.de. The ilink professional service team performs a remote installation. After the TMG is installed, it runs in the background and no administrator support is required.
The TeamCall Meeting Gateway for HCL Sametime Premium provides audio waiting rooms for moderated meetings.
If the user experiences dial-in or telephony problems, they must contact ilink support at sales@ilink.de to open a ticket for assistance.
Additional information can be found at the following:
Parent Topic: Meetings
"},{"location":"admin/meetings_passwords.html","title":"Defining Meetings password requirements","text":"The default requirement for a meeting is that the password must be at least eight characters. To increase the password requirements, additional rules can be specified.
A meeting owner can define a meeting password when creating a meeting. When a meeting participant logs into the meeting and the password rules are displayed as the password is typed. As a requirement is met, a green circle with a check mark is displayed next to the requirement.
You can set one or more of the following rules to increase password strength.
Include at least one number. The default is false.
Edit one of the following files.
Locate and update the following parameters.
Docker
REACT_APP_PASSWORD_MIN_LENGTH=password\\_length\nREACT_APP_PASSWORD_SPECIAL_CHARS_REQUIRED=false\nREACT_APP_PASSWORD_UPPER_CASE_REQUIRED=false\nREACT_APP_PASSWORD_LOWER_CASE_REQUIRED=false\nREACT_APP_PASSWORD_DIGITS_REQUIRED=false\nKubernetes
passwordMinLengthRequired: password\\_length\n passwordSpecialCharsRequired: false\n passwordUpperCaseRequired: false\n passwordLowerCaseRequired: false\n passwordDigitsRequired: false\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping servers.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/microsoft_outlook_deploy.html","title":"Deploying Microsoft Outlook add-ins to users","text":"An administrator can centralize the deployment the HCL Microsoft Add-in so that it is available for users within the organization.
See Determine if Centralized Deployment of add-ins works for your organization.
To distribute the HCL Microsoft Outlook add-in within your environment use the Office 365 admin center. The deployment can be assigned to all users or to specific users and groups. When deployed, the Get Addin button to be available to users.
For additional information, see the Micorsoft Deploy add-ins in the Microsoft 365 admin center topic.
Open the Microsoft Outlook admin center.
Click Deploy Add-in and clickNext.
Click Upload custom apps.
Select where to upload the add-in from.
You should normally choose Add from URL and enter the URL for your Sametime Meetings add-in. For example: https://host_name_url/outlook/manifest.xml. If the URL is not publicly accessible, open the URL and save the XML file, then select the Add from file.
Click Upload.
Choose which users and groups to deploy to and whether the add-in is mandated or not.
Click Deploy.
Deployment can take up to 24 hours. Outlook clients must launched their Outlook client again for the add-in to appear in the user interface.
Parent topic: meetings_configuring.md
"},{"location":"admin/migrating.html","title":"Migrating and Upgrading","text":"This section provides information on migrating data from an earlier release to Sametime 12.
Review the Planning for migration to Sametime 12 topic.
In Sametime 9.x, 10.x and 11.x, vpuserinfo.nsf stores all the contact list for users. Before you can migrate contact lists to MongoDB, you must first convert the vpuserinfo.nsf data to LDAP using the Stnamechange utility on your current deployment environment.
On the Sametime server being migrated, decompress the notes-migration.zip file to the server's program directory where the Sametime 12 product image was placed.
You must run this command from the Sametime server's program directory where the sametime.ini and notes.ini files exist.
For Linux, run the following commands to setup the environment. Otherwise, skip to the nex step and perform the migration task.
source ./setenv.sh\nRun the following command to move your contact list to MongoDB. Before the migration begins, you are prompted for locations and options.
Linux
./notes-migration.sh\nWindows
notes-migration.bat\nParent Topic: Planning for migration to Sametime 12
"},{"location":"admin/migrating_dominodirectory.html","title":"Converting from native Domino directory to LDAP","text":"Review the Planning for migration to Sametime 12 topic.
If the older Sametime deployment is not configured for LDAP, the contact lists must be converted using the Stnamechange utility before migrating. The Stnamechange utility is not available on Sametime 12. Run the utility on Sametime 9, 10, or 11 before migrating.
For previous Sametime versions, see the Changing user names topic for the version that is being migrated to Sametime 12.
The LDAP task is used to convert to LDAP. Run the task on the older Sametime Community server.
Parent Topic: Planning for migration to Sametime 12
"},{"location":"admin/migrating_moveusers.html","title":"Moving the users","text":"Review the Planning for migration to Sametime 12 topic.
After you are finished testing of the new Sametime version and are ready to migrate the users, you can use one of the following strategies.
Parent Topic: Planning for migration to Sametime 12
"},{"location":"admin/mongodb.html","title":"MongoDB","text":"MongoDB is used to store data for persistent chat, mobile push notifications, meetings, and contact lists.
If you have an existing MongoDB deployment, you can use it. However, if you do not already have MongoDB installed, you must install one or use a cloud-based MongoDB. MongoDB can be installed on a separate server or in the same Kubernetes cluster as Sametime. As with the storage size needed, the use of a dedicated server depends on your organization. After MongoDB is installed or if using a cloud-based MongoDB, it must be defined to communicate with the Sametime server. If installing your own MongoDB, see Installing MongoDB for additional information. For information about using the cloud-based MongoDB, see Using MongoDB on cloud.
Data related to chats and meetings is stored in MongoDB. This includes screenshots, emojis, chat logs, meeting reservation information, and contact lists. By default, data is saved for 90 days. You can change the default on the time-to-live (TTL) setting. For more information, see Updating the time-to-live index for persistent chat.
Data is stored in the data/db path which is specified in the mongod.conf configuration file. When determining the size of your MongoDB, consider the activity used by users in your organization. Refer to the MongoDB documentation for information on setting the size of the database.
Parent Topic: Prerequistes
"},{"location":"admin/mongodb_cloud.html","title":"Using MongoDB on cloud","text":"MongoDB Atlas is a cloud-based database that can be used to maintain Sametime data.
Before the Sametime server can communicate with the MongoDB Atlas, you must have an Atlas account. To sign-up for an account, refer to the Try MongoDB Atlas website.
Log into your MongoDB Atlas account.
Access the Atlas user interface.
Click Connect.
Select the driver from the dropdown list.
Select whether to use password or x.509 encryption.
In the box under View full code example, is the URL to the MongoDB on Atlas. You can use the copy icon to copy the URL. The following is an example URL:
mongodb+srv://Admin:<password>@cluster0.EXAMPLE.mongodb.net/?retryWrites=true&w=majority\nAtlas requires TLS to connect to the service.
You must update the URL to add your truststore file location.
mongodb+srv://Admin:<password>@cluster0.EXAMPLE.mongodb.net/?retryWrites=true&w=majority&tlsCAFile=truststore\\_location\nMap the truststore file into the Community container.
volumes:\n - truststore\\_location\nSametime meetings generate two types of traffic: web traffic and RTP media streams. Web traffic is standard HTTPS. And media streams by default use UDP for optimal performance. If the UDP service is unavailable, enabling TCP for RTP media streams is supported.
To support the Sametime default configuration, use the following ports for client access:
If you enable TCP for media streams, you can configure it to use TCP port 443. However, it does not send media streams as HTTPS data. Confirm with your security and firewall teams that this non-standard use of HTTPS port 443 is permitted.
The amount of bandwidth consumed by Sametime Meetings depends on several factors, such as the quality of the video being shared, the number of video and audio streams being shared, and more. The default limit for simultaneous video streams is 8. Increasing this value affects bandwidth consumption. For more information, refer to Increasing the number of video streams displayed during a meeting.
You must discuss the design of your Sametime deployment with your network and security teams before implementation. Many common network layer devices and technologies introduce latency, which can degrade the user experience. Identify all potential bottlenecks, for example, firewall, proxy, VPN, packet shapers, and intrusion prevention devices before deploying servers.
Parent Topic: Planning
"},{"location":"admin/overview_encryption.html","title":"Encryption usage in Sametime","text":"HCL Sametime uses several types of encryption to protect data.
The following table lists the types of encryption for various types of data and the length of each type of encryption key.
Algorithm Mode Related key length Function HMAC-SHA256 Integrity check 256-bit (through server shared secret) Hash-based message authentication code (HMAC) that protects the integrity of JSON Web Tokens (JWT). SHA256 Signature 256-bit Generates an almost-unique 256-bit (32-byte) signature for a text or data file. RC2 Confidentiality (all applicable user data) Various key length (40-bit or 128-bit in different circumstances; generated using Diffie-Helman) Encrypts field data or messages between client to client and client to server. This is the default encryption used in the Sametime Connect and Embedded clients. TLS 1.2 In-transit data 128/256-bit depending on cipher chosen Provides security including privacy, by encrypting data sent over the internet through the use of certificates between a client and a server. DTLS/SRTP In-transit data 256-bit Prevents hacks or man-in-the-middle attacks against voice communications between a client and a server. OLM In-transit data 256-bit Provides end-to-end encryption between client-to-client media. bcrypt Stored data 10 salt rounds Hashes passwords stored in the database.Parent Topic: Securing
"},{"location":"admin/plan_cluster_chat.html","title":"Configure high capacity for chat","text":"Sametime supports up to 10,000 simultaneous log-ins with a standard single community pod, mux pod, and proxy pod in a Kubernetes deployment. Docker deployments of Sametime support 10,000 simultaneous log-ins.
The Sametime mux is used for front-end client connections between the Sametime Connect client and the Sametime Embedded client inside of HCL Notes. If you need additional capacity for these clients, you can deploy multiple community pods inside your Kubernetes cluster. The number of community pods is defined in the values.yaml file, and each additional pod supports up to 10,000 additional clients. The community pod does not axiomatically scale. It is important to estimate the number of pods needed and define the setting in the values.yaml file.
When changing
In the values.yaml file, ensure that this setting is set to true, which is the default setting:
enableMuxDeployment: true\nChange the below setting to the desired number of community pods:
numberOfCommunityServers: 1 \nTo find the Kubernetes service that front-ends the mux issue the command:
kubectl get svc | grep mux \nThe ingress controller in a Kubernetes cluster front-ends the connection to the web and mobile clients and the proxy pod services those connections. Additionally, the community pod validates log ins and service the users as well. Sametime supports up to 10,000 simultaneous connections in a Kubernetes environment, and if more are needed deploy an additional 1 ingress controller pod, 1 proxy pod, and 1 community pod per 10,000 web and mobile clients.
Apply your changes to the environment run the helm uninstall command and after it completes, run the helm install command.
If you are not changing the value from or to a value=1, run the helm upgrade command to apply the changes.
Parent Topic: Clustering and high availability
"},{"location":"admin/plan_cluster_meetings.html","title":"Configure high capacity for meetings","text":"High availability is supported for the front-end web traffic to the Kubernetes cluster. You can deploy multiple front ends on different physical and virtual nodes pointing to the same back end in order to distribute load and survive a node outage.
High availability is not supported for active meetings, but failover is supported. If a server hosting a meeting goes down, users who are in meetings on that server are briefly interrupted. The client reconnection timer reconnects the clients and distributes them to an available node. In some circumstances, a server that stops responding causes a client to disconnect from a meeting. Users can reconnect to the meeting from their recent meetings list and rejoin the meeting on an available server.
Sametime can be expanded to more than one geography or another network by deploying multiple video bridges. This is different from deploying multiple video nodes, which are all co-located. When you deploy multiple video bridges the user receives audio and video from the video bridge that is located the closest to them. For more details, see Configuring autoscaling for video.
For sizing and deployment related questions, contact an HCL support professional by completing the Talk to a Technical Expert form.
"},{"location":"admin/plan_cluster_meetings.html#section_mhc_fqk_bvb","title":"Docker","text":"Meetings are sized based on what is happening in the environment at any given time. For Docker deployments, there are many variables, including the CPU and memory size of the Docker instance. A large Docker instance can support up to 200 concurrent peak users, but that does not take into consideration how many of the meetings are being recorded. Meeting recordings are CPU intensive. A Docker instance is better suited for a small department or focused team than an enterprise-size deployment.
"},{"location":"admin/plan_cluster_meetings.html#section_wxt_hqk_bvb","title":"Kubernetes","text":"If you are deploying Sametime to your entire organization, Kubernetes is a better choice than Docker. The Kubernetes autoscaling feature provides the flexibility needed in an enterprise deployment. Autoscaling is a feature in which a cluster adjusts the number of nodes based on current usage and monitoring.
In Kubernetes environments, a horizontal pod autoscaler is leveraged to automatically scale the environment upon demand. There are two configurations: one for video and one for recorders. When you create your node pools for video and recorder it is important to estimate how many nodes are needed.
You can either have a node dedicated to one recorder or you can size your recorder node pool instances to support more than one recorder per node.
Parent Topic: Clustering and high availability
"},{"location":"admin/plan_cluster_meetings_recorder.html","title":"Configuring autoscaling for recorder","text":"A recorder is used when a meeting is being recorded and when live streaming a video. The Kubernetes autoscaler adjusts the use of recorder pods based on settings in the recorder.yaml file.
To deploy the autoscaler, Prometheus must be installed. See Installing Prometheus for the details.
When a recorder is being used in a meeting, it is dedicated to that meeting until the user stops the recorder or the meeting is stopped. At that time, the recorder is available to be used again. For example, if two recorders are deployed, only two meetings can be recorded at the same time. A recorder is not available until one of the meetings ends. The live streaming feature is also handled by the recorder.
Estimate how many recorders you may need and define the minimum and maximum number of recorder pods that are used by the autoscaler.
Change directories to installation_directory/ /kubernetes/autoscaling directory. Where installation_directory is the directory the install package is located.
Open the recorder.yaml file for editing.
Configure the minimum number and maximum number of recorders by adjusting the following settings.
minReplicas: minimum\\_value\nmaxReplicas: maximum\\_value\nFor example:
minReplicas: 2 \nmaxReplicas: 10\nSave and close the file.
To deploy the recorder autoscaler, run the following command from the autoscaling directory.
kubectl apply -f recorder.yaml\nIf the autoscaler has already been deployed, you can adjust the number of recorder pods available. The following command can be used to adjust the number of recorders.
kubectl edit hpa recorder\nParent Topic: Configure high capacity for meetings
"},{"location":"admin/plan_cluster_meetings_video.html","title":"Configuring autoscaling for video","text":"The Kubernetes autoscaler adjusts the use of video pods based on the configured values in the video.yaml file.
To deploy the autoscaler, Prometheus must be installed. See Installing Prometheus for the details.
When Sametime is installed for the first time, you must deploy a HorizontalPodAutoscaler.
Change directories to installation_directory/ /kubernetes/autoscaling directory. Where installation_directory is the directory the install package is located.
Open the video.yaml file for editing.
Configure the minimum number and maximum number of video pods by adjusting the following settings.
minReplicas: minimum\\_value\nmaxReplicas: maximum\\_value\nFor example:
minReplicas: 1 \nmaxReplicas: 3 \nSave and close the video.yaml file.
To deploy the video autoscaler, run the following command from the autoscaling directory.
kubectl apply -f video.yaml \nIf the autoscaler has already been deployed, you can adjust the number of video nodes available. The following command can be used to adjust the number of video nodes.
kubectl edit hpa video\nParent Topic: Configure high capacity for meetings
"},{"location":"admin/plan_cluster_mongodb.html","title":"Configuring MongoDB for high availability","text":"This topic covers the steps on how to configure MongoDB for high availability.
MongoDB clustering is handled during the installation process for both Docker and Kubernetes.
Note: In the MongoDB URL, if the user name or password includes the following characters, they must be converted by using a percent sign: / ? # [ ] : @.
Parent Topic: Clustering and high availability
"},{"location":"admin/plan_cluster_mongodb.html#ncl_ddm_x5b","title":"Configuring MongoDB clustering on Docker","text":"In the custom.env configuration file on the Sametime server, update the MONGO_URL field. For information about how to create the MongoDB URL, see the Connection String URI Format topic in the MongoDB documentation.
"},{"location":"admin/plan_cluster_mongodb.html#nky_cdm_x5b","title":"Configuring MongoDB clustering on Kubernetes","text":"Provide a single node MongoDB information while running the prepareDeployment script.
When the prepareDeployment process is complete, prepare your MongoDB cluster URL. For more details, see Connection String URI Format.
Use Base64 encoding to encrypt your MongoDB URL.
You can review online websites that provide Base64 encoding or you can set up one on your own.
Use the kubectl command to update the sametime-meetings-global-secrets secret configuration file.
kubectl edit secret sametime-meetings-global-secrets\nInside the sametime-meetings-global-secrets, locate the MongoConnectionUrl section. Replace the value for it with the value from step 3.
Save your changes.
This section describes the system requirements and server configurations needed for HCL Sametime and HCL Sametime Premium.
Network planning for meetings
Clustering and high availability High availability and high capacity configuration for Sametime is achieved in different ways depending on which component is being configured for HA. See the topics below to learn more about chat, meetings, and MongoDB.
The Meeting server routes media traffic.
"},{"location":"admin/planning_meetingserver.html#section_gmc_qlc_w5b","title":"Media quality and network connectivity performance","text":"How are media streams transferred? Is there any instance where this would occur peer to peer? : All media traffic is routed through the Sametime server.
If I need external access to meetings, in which firewall zone do I place the Sametime Meeting server? : See Determining where to install Sametime.
Are there any considerations for the network if I have a firewall? : See Planning the network topology and connectivity.
What is the recommended bandwidth for comfortable usage? : Whether you are attending online meetings, video conferences, or virtual gatherings, ensuring a reliable and smooth connection is key. Calculation can be tricky and is dependent on the business scale. For small organizations, 1 Gbits/s is often enough. For larger organizations, 10 Gbits/s or more is recommended. For large organizations that use multiple bridges for multiple deployments, 10 Gbits/s link per bridge is recommended. For more information, see the Jitsi Meet Handbook.
"},{"location":"admin/planning_meetingserver.html#section_nmw_qmc_w5b","title":"Chats within a meeting","text":"How long do chats in the meeting remain? : There are two places that chats are displayed. For authenticated users who are logged into the server, they see the chats in the Sametime clients as a group chat that includes the meeting participants. The chat persists if the user does not close the chat.
: For meetings where users are guests, or authenticated users are not logged into a Sametime client, the meeting chat is only inside the meeting room. When the meeting concludes, the meeting room chats are deleted from the meeting room.
Can I make the chats persist from one meeting to the next? : When the meeting concludes, the meeting room chats are deleted from the meeting room. Meeting chats do not persist to the next time the same meeting URL is used.
Can I enable logging of the chats inside the meeting? : The user can log the chats only if they log into the server using a Sametime client. There are three ways the user can log these chats:
- The Sametime Connect client or embedded client have a client-side chat logging feature enabled to save a local transcript.\n- The user enables persistent chats on the server and clients supporting persistent chats are in use, these chats are stored on the server in MongoDB. They are subject to the persistent chat configuration.\n- The server-side chat logging is enabled and chats are stored in the configured method.\nWhich authentication methods are supported? : The Sametime server handles all authentication requests. Any supported authentication model you configure on the Sametime server is supported for Meetings.
How can I disable guest (anonymous) access to meetings? : See Disabling guest access.
Which types of SSO are supported with meetings? : LTPA and SAML with LTPA are supported. See Enabling Single Sign-on.
"},{"location":"admin/planning_meetingserver.html#section_jxc_d4c_w5b","title":"Recordings","text":"Where are recordings stored? : Recordings are stored in a persistent volume which is configured when Sametime is installed. For more information, refer to Creating the persistent volume.
How can you disable meeting recordings? : See Managing recording options.
What type of recorded media is available for meetings? Is this configurable? : The user can save all recordings as MP4 files. It is not configurable.
Which part of a meeting is recorded? : Everything that displays on the screen share and all audio and video from cameras that were seen by users in the meeting are captured as part of the recording. Shared YouTube videos are captured as well.
Authenticated meeting attendees who log in with a Sametime client have a group chat for the meeting. The link for the recording is contained in the chat, and the chat persists if the clients keep the chat open. Persistent chats expire after a number of days. For more information, refer to [Updating the time-to-live index for persistent chat](update_ttl_index.md).\n\nThe meeting moderator has access to the meeting report which contains a full chat transcript, links to files that were shared, as well as a link to the recording if the recorder was started.\nHow long does recorded media remain on servers? Is this configurable? : The default is three days, which is configurable. See Managing recording options for the details.
"},{"location":"admin/planning_meetingserver.html#section_nsz_npc_w5b","title":"Configuration settings","text":"Which settings are configurable server-wide? : Meeting server configuration is all handled on the meeting server; each change is global.
Can the administrator restrict a number of participants in a meeting? : Yes, and the default number of participants in a meeting is 100. See Configuring the maximum number of meeting participants for the details.
Which settings are configurable though a policy? : The community policy only allows or disallows meetings. There are no other policy-based settings.
Can I disable the audio and video options? : No.
Can I integrate my telephony system with the Sametime meeting server? : Yes, see Enabling meeting dial-out.
"},{"location":"admin/planning_meetingserver.html#section_zpg_dqc_w5b","title":"Personal or reserved meetings","text":"Can a user own or reserve the name of a meeting, that is the meeting URL so that no one can use it? : Yes, the first user who requests the meeting name owns the reserved name.
Can I have a persistent meeting? : You can have a reserved meeting name. There is no data preserved or persisting between members entering or leaving.
Is a moderated meeting room not available until its owner enters the room? : Yes, the moderated meeting room is not available until the owner enters the room.
"},{"location":"admin/planning_meetingserver.html#section_ttf_lqc_w5b","title":"Migration and existing Sametime environments","text":"Can I migrate my Sametime 9.0.1 meeting data to the Sametime meeting server? : No. There is no slide share or file share tool in the new meeting server. There is no data that needs to be migrated.
Will my old Sametime meeting URLs work on the new server? : Users can expect the legacy meeting URLs to work. The DNS change from the old host name to the new host name handles the migration to the new server. After the DNS change, users can continue to use the original meeting URLs in calendar entries to join meetings. The new server does not support the legacy meeting client plug-in in the Sametime client, so users must join by URL.
Can I use the Sametime 9 meeting plug-in embedded in HCL Notes to connect to a Sametime Meetings server? : The introduction of the External Meeting Provider feature in the Sametime embedded and stand-alone clients deprecate the meeting plug-in in the Notes version 11.
"},{"location":"admin/planning_meetingserver.html#section_xv4_2rc_w5b","title":"Statics, reporting and auditing","text":"Are there meeting statistics or reports for Sametime? : Meeting reports can be downloaded. The reports provide information such as: a list of attendees, meeting start and end times, duration, meeting types such as moderated, guests allowed, the time participants were joined and left the meeting, a list of presenters, a link to meeting recording, and the chat transcript.
: A Grafana\u00ae dashboard is available with the Sametime install package. See Monitoring your meeting and chat metrics with Grafana.
Parent Topic: Planning
"},{"location":"admin/pod_apply_changes.html","title":"Applying changes","text":"After you have modified a secret, scale the pods for which changes were made. Scaling the pod is similar to a reboot, first the pod is scaled to zero and then scaled to one. For Sametime pods details, see Pods in Sametime. Scaling to zero removes all containers for the specified pods and scaling to one restarts their use. When scaled back up from zero, changes made are used by the pod.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/pods_descriptions.html","title":"Pods in Sametime","text":"A pod is a group of one or more containers that share storage and network resources.
The following table describes the Sametime pods and the containers in which the pod runs.
Pod Name Container Description Activity App-registry Auth NA Interacts with the Sametime server for SSO. backgrounds NA Provides the backgrounds in meetings. Catalog NA Maintains the list of meetings that belongs to a user and the the recent meetings list. Interacts with the MongoDB. Click2call NA Provides the click to call interface in web chat. Community community, pushgateway Performs all authentication, interacts directly with the LDAP service. Enforces policies. Interacts with MongoDB for persistent chat. Retrieves and serves business cards data. files files, scanner Provides file transfer service in meetings and web chat Jibri-web NA Provides a web interface to the recordings Jitsi prosody, jigasi, jicofo The video bridge that streams the media to users.Jigasi container for SIP messages(integration with telephony).Jicofo conference focus) \u2013 messages about features used in meetings, participants joining and dropping. Lobby NA Runs the lobby service for meetings. Location NA Used when telephony is integrated to assist users with the telephone numbers. Mux NA Allows the Connect and Embedded clients in Notes to connect over port 1533. Has a svc with an IP address for users to connect. Proxy NA Runs the web chat service allowing users to connect with mobile clients or web clients for chat. Recorder jibri, pushgateway, await-prosody Save meeting recordings when a user records a meeting. It is also used for live streaming. Recordings NA Interacts with the persistent volume to store recordings. Video jvb, prometheus-exporter Interacts with STUN server. Web NA Serves the web interface to the users Webhook NA Interacts with telephony and click to call feature Outlook NA When the Outlook add-in feature is enabled, this process interacts with the Outlook add-in.Parent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/ports_sametime.html","title":"Ports used by Sametime services","text":"Sametime services use several ports for communication. If firewalls are in use in your environment, all traffic on these ports should be permitted bidirectionally.
Port Number Description 389 Used for non-secure communications from the Sametime server to the LDAP server. 443 Used for HTTP communications over a secure connection. 636 Used for secure communications with LDAP for directory services. 1516 Used as an internal port between the community and proxy pods. 1533 Used to listen for direct TCP/IP connections from Sametime Connect clients.A direct TCP/IP connection is when a Sametime client uses a unique Sametime protocol over TCP/IP to establish a connection with community services. 1935 Used when streaming YouTube videos. 5280, 5222 Used to reach the service cluster IP for Jitsi. In Kubernetes environments, for websockets to function properly, the video pods using the node port must be able to reach the service Cluster IP for Jitsi on ports 5280 and 5222. See the Websockets fail to load after installing Sametime 11.6 or 12.0.x on Kubernetes article for more information. 8000 Used to listen for HTTP communications. All communication over this port is redirected to HTTPS port 443. Port 8000 is the default port assigned during the product installation process. 10000 Used by audio and video clients to stream media data when deploying Sametime on Docker. 19302 This UDP port is the default STUN port used by both the client and meeting server for NAT traversal. 27017 Used for communication with MongoDB. 30000 Used by audio and video clients to stream media data when deploying Sametime on Kubernetes.Parent Topic: Planning the network topology and connectivity
"},{"location":"admin/recording.html","title":"Managing recording options","text":"As the administrator, you have control over your recording settings. This section describes the features available to help you manage meeting recordings and where they are configured.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/sametime_client_configuration.html","title":"Sametime client configuration options","text":"There are several methods to customize the user experience for Sametime clients. This section covers Expeditor based clients that are capable of leveraging the Expeditor Managed Settings framework. These clients include the Sametime client for Windows or Mac, and the HCL Notes embedded Sametime client for Windows or Mac. This does not apply to the PWA, web or mobile clients.
Use managed-settings.xml and managed-community-configs.xml for clients which are already installed.
If your clients not not yet installed, the the plugin_customization.ini file can be configured and included with the client installation package.
File Location Purpose managed-community-configs.xml Web server This file is used to update connectivity preferences in the client. Update, add and delete servers, and manage connection settings (such as host name, port, connection method, authentication method, etc). The file is pushed using a policy, so you can define different settings for different users. This method applies to both the Sametime\u00ae rich client and to the Sametime client embedded in Notes\u00ae. This file is retrieved upon login and will take effect the next time the user restarts the client. managed-settings.xml Web server This file can be used to push client preferences to the users. The file is hosted on a web server and retrieved upon login from the Sametime policy. This method applies to the Sametime rich client and Sametime embedded client in Notes. Note: Do not add community config settings (connectivity settings) to this file. Community config settings must be added to the managed-community-configs.xml file. See the topic Updating Communities with the Managed-community-configs xml. plugin_customization.ini Client computer Set initial eclipse preferences when client install kits are deployed to desktops or when a new user launches the product for the first time. These preferences can be overridden at runtime for the logged in user base using the managed-settings.xml file. This method only applies to installed Sametime Connect clients. Community settings (such as loginAtStartup and host) can be entered here to prepopulate community settings for a first time user. After the user logs in, only the managed-community-configs.xml file can be used to change community settings.Parent Topic: Managing Sametime clients
"},{"location":"admin/sametime_meeting_administering.html","title":"Managing Sametime Meetings","text":"You can enable or disable meeting features. Note that these settings apply to the server and are not controlled by user policies.
The following table lists meeting features and whether they can be turn on or off by the administrator or meeting owner.
Table 1. Meeting Features
Feature Settings Audio and video Enabled by default, cannot disable. Sharing a video Enabled by default, cannot disable. Start live stream Live streaming is disabled if recordings are disabled. To allow recordings and disable live streaming, see Configuring Live Streaming. Disable recordings Recordings are enabled by default. To disable recordings, see Managing recording options. Change recording availability Recordings are available for 3 days by default, to change the setting, see Managing recording options. Secure the meeting with password The option to secure meetings with a password is by default enabled, cannot disable. A user can choose for any meeting owned whether or not to configure a password on that meeting. See [Defining Meetings password requirements] (meetings_passwords.md) for additional information. Guest users Guest access is enabled by default. To disable, see Preventing guest access Unmoderated meetings Enabled by default, cannot disable. Moderated meeting: invite others Enabling meeting dial-out. Raise hand Enabled by default, cannot disable. User Photos (authenticated users only) You can retrieve photos from the Sametime Proxy server. They will display if they are available to the meeting server. You can use Gravatar to configure an avatar based on your Sametime email ID. Use it if your photo is not available via the Sametime Proxy. Group Chat Enabled by default, cannot disable. Group Chat also in the rich client Enabled by default, cannot disable. Screenshare (Start Presenting) Screenshare is enabled by default on all meetings. In a moderated meeting, the moderator must grant access to screenshare. Multi-user screenshare By default, any user in an unmoderated meeting can share their screen, even if another user is already sharing. It is not possible to disable this feature. In a moderated meeting, you can share only a single screen at a time. Lock meeting Enabled by default, cannot disable. Moderated Meeting: Mute everyone else Enabled by default, cannot disable. Moderated Meeting: All cameras off Enabled by default, cannot disable. Moderated Meeting: Invite others See: Enabling a SIP Trunk for Meeting Dial OutThe following table displays settings that affect the functionality of the server.
Table 2. Server-side configuration settings
Description Setting Maximum number of attendees per meeting. Currently, the maximum supported number of users per meeting is 50. The default setting is 25 users. To change the setting, see: Configuring the maximum number of meeting participanats.Parent topic: Administering
"},{"location":"admin/sametime_premium.html","title":"Sametime versus Sametime Premium","text":"Depending on the Sametime product that is installed, certain Sametime features might be available. HCL Sametime provides secure real-time communication across devices, and HCL Sametime Premium expands those features to include video and file sharing.
The following tables show the features included in Sametime and Sametime Premium.
Feature HCL Sametime HCL Sametime Premium Sametime Embedded client in HCL Notes X X Sametime Connect client X X Presence awareness in HCL Notes X X Instant chat X X Persistent chat X X Local client chat history X X Screen capture and image transfer in chat X Support for multiple Sametime communities X External conferencing integration X File transfer X Feature HCL Sametime HCL Sametime Premium Sametime mobile chat X X Sametime web client chat X X Sametime presence and chat API for HCL Connections and HCL Digital Experience X X Sametime presence and chat in HCL Verse and iNotes X X Feature HCL Sametime HCL Sametime Premium Screen sharing X Multiple users screen sharing X Audio and video X Meeting group chat X Meeting group chat integration with desktop clients X Moderated meetings X Password protection X Reserved meeting names and URLs X Meeting recordings X Live streaming to YouTube XNote: For HCL Domino users with limited Sametime capabilities, see Managing Sametime features for the list of features that are not available.
Parent Topic: Planning
"},{"location":"admin/secrets_delete.html","title":"Deleting a secret","text":"The kubectl delete command can be used to delete a secret.
To delete a secret, issue the command specifying the secret.
kubectl delete secret secretname\nThe following example shows the command to delete extra-community-configs secret.
kubectl delete secret extra-community-configs\nParent Topic: Managing secrets in Kubernetes
"},{"location":"admin/secrets_modify.html","title":"Modifying secrets","text":"Some of the content within a secret can be changed using the edit secret command.
When the secret is in edit mode, you can modify the content by placing data in secrets. Most of the secret fields, such as user names, passwords, and URLs, are base64 encoded. To view a base64 encoded value, you can copy the value and decode using the following command:
echo -n secret\\_value | base64 -d\nTo change the value to a new encoded value, you can base64 encode the new value using the following command:
echo -n \"new\\_secret\\_value\" | base64\nFor example to set a new LdapBindEntryDn in the sametime-global-secrets, enter the command:
echo -n \u201cCN=LDAPBind,O=Example\u201d | base64\nThe resulting value should be used in the configuration.
The following are considerations when making configuration modifications:
If changes to the configuration helm charts are not committed, the next time you run a helm upgrade, the secret is overwritten with the values that are defined in the templates.
Issue the following command specifying the name of the secret.
kubectl edit secret secret\\_name\nType the letter i to get into insert mode and make modifications.
To save the changes, type the characters: Esc+ :wq!.
To close the file without saving changes, type in the characters Esc+ :q!.
Parent Topic: Managing secrets in Kubernetes
"},{"location":"admin/secrets_view.html","title":"Viewing secrets","text":"The get command can be used to list secrets and view their contents.
To view a list of all secrets, run the following command.
kubectl get secrets\nIf a namepace is beign used, the -n argument must be inclued.
kubectl get secrets -n namespace\\_name\nwhere namespace_name is the name of the namespace.
To view the content of a secret, run the following command.
kubectl describe secret secret\\_name\nwhere secret_name is the name of the secret.
Parent Topic: Managing secrets in Kubernetes
"},{"location":"admin/secure_rooms.html","title":"Disabling secure meeting room names","text":"Users are provisioned with a personal meeting room the first time that they log into their meeting. Their personal meeting room is created with a secure name that cannot be easily guessed by other users. For example: be:MeetMe.CWGRAff90q9HETLne4mhzA.
Meeting rooms with a user-friendly name or naming conventions might be preferred, for example: MeetMe.username~40company.com. If this is the case, the secure naming feature can be disabled.
Disabling secure meeting room name feature does not affect existing meeting rooms. Changing the setting affects only the meeting rooms provisioned after changing the setting.
Disabling secure rooms on Docker and Podman
Disabling secure rooms on Kubernetes
Parent Topic: Meetings
"},{"location":"admin/secure_rooms_docker.html","title":"Disabling secure rooms on Docker and Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Edit the docker-compose.yml file.
Locate the STCONF_MEETING_SECUREUSERROOMNAME variable in the Proxy section and set the value to false.
Save the changes.
To apply the changes, stop Sametime server and then start it again.
Run the following command to stop the server.
docker-compose down\nRun the following command to start the server.
docker-compose up -d\nParent Topic: Disabling secure meeting room names
"},{"location":"admin/secure_rooms_kubernetes.html","title":"Disabling secure rooms on Kubernetes","text":"Chang to the helm directory where the Sametime installation package was decompressed.
cd helm\nOpen the values.yaml file and put in edit mode.
Locate the useSecurePersonalRoomName value and change the value to false.
useSecurePersonalRoomName: false\nSave and close the values.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Disabling secure meeting room names
"},{"location":"admin/securing.html","title":"Securing","text":"This section provides information on securing your HCL Sametime environments.
The various connections to Sametime can be secured using TLS.
Desktop client to Sametime server : These are connections from the Sametime Connect client or Sametime embedded client inside HCL Notes that connect on port 1533 to the Sametime Multiplexer (Mux) by default. Sametime has legacy encryption enabled by default. These connections can be secured over TLS 1.2. For additional information, see Securing connections between the Sametime mux and the Connect and Embedded clients.
Sametime web and mobile clients : Sametime meetings and web chat come with a self-signed certificate. You can replace the self-signed certificate with a third party certificate. For more details on this configuration, see Replacing the TLS certificates for Web Chat and Meetings.
Sametime server to LDAP server : By default the LDAP operations are not encrypted. It is recommended to enable encryption using TLS to encrypt sensitive user data, such as names and passwords. The secure port for LDAPS is typically 636 but may be different in your environment. For more details on this configuration, see Securing connections between Sametime servers and LDAP.
Decrypting SAML assertions : When Sametime server is configured for SAML, the Sametime server can validate the encrypted assertions are from the Identity Provider (IdP). These settings is used for the decryption. For more information, see Setting up SSO using SAML.
MongoDB : The connection Sametime uses to access MongoDB can be secured with TLS. For more details, see Setting up TLS for the Mongo database.
Configuration scope : Beginning with Sametime 12, Kubernetes environments have a separate TLS scope for each type of connection as described above. Docker environments can be configured to use key and trust stores at the global level, where all certificates are shared among the different community services. For more details on this configuration, see Implementing the Global TLS Scope for Docker.
Obtaining the cert.key and cert.crt files for Sametime
Creating a truststore with a third-party certificate When creating a connection between the Sametime server and a service using TLS, a truststore is needed. The truststore is used to store certificates for Sametime.
Implementing the Global TLS Scope for Docker
Securing connections between the Sametime mux and the Connect and Embedded clients There are several connection methods to connect to the Sametime server. This topic includes the steps to encrypt connections between the clients and the Sametime mux using TLS.
Parent Topic: Securing
"},{"location":"admin/securing_connections_between_community_clients.html","title":"Securing connections between the Sametime mux and the Connect and Embedded clients","text":"There are several connection methods to connect to the Sametime server. This topic includes the steps to encrypt connections between the clients and the Sametime mux using TLS.
To implement the use of TLS, the clients must have the Direct connection using TLS connection option enabled. This setting is under Preferences > Server Communities > Global Connection Settings.
There are three methods to set the client connection preferences.
For additional information, see Updating connectivity settings with the managed-community-configs.xml file.
When you enable TLS for the Sametime server connections, TLS version 1.2 is used by default. SSLv3 and TLSv1 have security vulnerabilities and should not be used.
To configure the connection between the Sametime server and clients, there are two tasks that must be completed:
Sametime can be configured to allow legacy encryption along with TLS encryption (both enabled), or strict TLS where only TLS encrypted connections are allowed. The Sametime Mux can listen for both TLS and legacy encrypted connections on the same port number, so there is no need to have a unique port for the TLS encrypted connections, they can also use port 1533. The port number can be changed if desired.
For details on configuring the encryption settings, refer to the following topics.
Configuring TLS for Sametime mux on Kubernetes
In the HCL Notes client, select File > Preferences > Sametime > Server Communities. The Server Communities window defines the server communities defined for the client.
To select this connection method for only one server community, click Server Communities, select the server community name, and open the Connection tab. Disable the Use global connection setting, then click Direct connection using TLS. Click OK to close the Preferences window.
Creating a keystore for Sametime mux A keystore consists of a private key and a certificate. Sametime supports both a third-party certificate, signed by a Certification Authority (CA), or a self-signed certificate. Request a certificate and private key from your CA for the hostname used by the Sametime mux. This is the microservice that listens on port 1533 for requests from the Sametime Connect clients (installed clients on desktop). In Kubernetes, the mux is either a Kubernetes service (for example, a load balancer type service) or a Kubernetes ingress service for on-premise Kubernetes. For Docker deployments, the mux listens on port 1533 and does not require any additional service.
Configuring TLS for Sametime mux on Kubernetes
Configuring TLS for Sametime mux on Docker and Podman
Parent Topic: Securing connections
"},{"location":"admin/securing_connections_between_community_clients_docker.html","title":"Configuring TLS for Sametime mux on Docker and Podman","text":"The following steps enable TLS for the Sametime mux, which overrides the default security with TLS 1.2 between Sametime Connect clients and the Sametime mux. For more details, see Securing connections between the Sametime mux and the Connect and Embedded clients.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Create a mux.env with the following setting and values appropriate for your configuration.
STI__Debug__VPMX_DISABLE_CONFIGURATION_UPDATE=1\nSTI__Debug__VPMX_PORT=1533\nSTI__Debug__VPMX_TLS_PORT=1533\nSTI__Config__VPMX_CAPACITY=20000\nSTI__Config__ST_TLS_KEY_STORE_TYPE=p12\nSTI__Config__ST_TLS_KEY_STORE_FILE=/local/sametimemuxdata/keystore.p12\nSTI__Config__ST_TLS_KEY_STORE_PASSWORD=keystore\\_password\nSTI__Config__ST_TLS_SECURITY_LEVEL=2\nAdd mux.env to the environment file variable in to the mux section of docker-compose.yml file.
env file:\n -mux.env\nMap the keyfile into the container
volumes:\n - ./keystore.p12:/local/sametimemuxdata/keystore.p12 \nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Securing connections between the Sametime mux and the Connect and Embedded clients
"},{"location":"admin/securing_connections_between_community_clients_kubernetes.html","title":"Configuring TLS for Sametime mux on Kubernetes","text":"Ensure that the following conditions are satisfied.
These are the steps to secure the connection between the Sametime Connect client and Sametime embedded client inside of HCL Notes to the Sametime mux using TLS.
The changes in this task apply to the following pods:
mux
Create a secret that contains your trust store.
kubectl create secret generic mux-secret --from-literal=KeyStorePassword=samet1me --from-file=./keystore.p12\nIn the values.yaml file remove the comment tag (#) surrounding the muxTlsConfigSecret: mux-secret parameter.
Save and close the values.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Securing connections between the Sametime mux and the Connect and Embedded clients
"},{"location":"admin/securing_connections_sametime_community_and_ldap.html","title":"Securing connections between Sametime servers and LDAP","text":"When Sametime is configured to connect to an LDAP server, the Sametime servers makes five separate connections to the LDAP server.
The Sametime Community Server makes a separate connection to the LDAP server to perform each of these five tasks:
The Sametime Community Server and LDAP servers exchange directory information, including user names and passwords, over these connections. To ensure this information is secure, the administrator can use SSL to encrypt the data that passes over these connections. The administrator should consider the level of protection required before enabling SSL. Using SSL to encrypt these connections can slow the server performance.\u202f
The administrator has the following options when using SSL to encrypt the data transmitted between the Sametime and LDAP servers:
Prerequisites
You must already have created the TLS Trust Store in .p12 or .jks format.\u202f
You can configure Sametime LDAP to use the same TLS settings as the rest of the server by setting the configuration at the global scope, or the LDAP settings can be secured using its own key store and settings by following the instructions in the Individual TLS scope and using the pre-fix STLDAP_.\u202f\u202f You must configure the sametime.ini settings by completing one of these topics:\u202f
Follow these steps to encrypt all data as explained above.
Import the LDAP server\u2019s certificate into the trust store
If the LDAP server is using a public certificate, then you need to obtain the public root CA and import it into the trust store on the Sametime server. If your LDAP server is using a self-signed certificate, then you simply import the self-signed certificate. In the prerequisite topics, your trust store filename is defined in sametime.ini setting ST_TLS_TRUST_STORE_FILE or if using the individual scope in STLDAP_TLS_TRUST_STORE_FILE.\u202f If you are securing Sametime using the global scope, the LDAP connections can use the same key and trust stores and these sametime.ini parameters are not needed.
Update the stconfig.nsf to use the secure LDAP settings
See the configuring_ldap.md topic and
Update the userinfoconfig.xml to use the secure LDAP settings
By default, the business cards LDAP connection is unsecure. To secure these settings, see the topic Configuring Business cards using an LDAP Directory and complete the optional step \u201cEnabling Encryption\u201d.
Encrypt only password related operations
If you wish to only encrypt operations that involve passwords, the rest of the traffic can remain unencrypted (sent in the clear), follow these steps:
In the [Directory] section add the following line:
ST_DB_LDAP_SSL_ONLY_FOR_PASSWORDS=1
Save and close the sametime.ini file.
This topic covers the steps to import your LDAP trust store and password into Docker as a secret, then define the secret in the Sametime configuration.
Before getting started, create a trust store with the LDAP certificate from the LDAP server. Name the file ldaptruststore.p12 and place it into the directory where the docker-compose.yml file is located.
The steps in the following procedure must be completed with root access or you can use sudo which allows you to run commands as root.
Change directories to the root directory where Sametime installation package was decompressed.
Create a new file called tlsldap.env.
vi tlsldap.env\nAdd the following lines into the tlsldap.env file.
STI__Config__STLDAP_TLS_TRUST_STORE_TYPE=p12 \nSTI__Config__STLDAP_TLS_TRUST_STORE_FILE=/local/notesdata/ldaptruststore.p12 \nSTI__Config__STLDAP_TLS_TRUST_STORE_PASSWORD=ldaptruststorepass\nOpen the docker-compose.yml for editing.
Locate the env_file: section under the community: subsection within the services: section.
Move custom.env to a new line.
Add the following line below custom.env.
tlsldap.env\nThe results should look like the following:
services:\n community:\n env_file: \n - custom.env\n - tlsldap.env\n environment:\nAdd a path to the LDAP trust store under the community: section in the docker-compose.yml file.
networks section and add the following line.volumes section, add the following line to the section. - ./ldaptruststore.p12:/local/notesdata/ldaptruststore.p12 \nThe section should look like the following example. Ensure that the indentations look like the example.
networks:\n - sametime.test\nvolumes:\n - ./ldaptruststore.p12:/local/notesdata/ldaptruststore.p12\nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Securing connections between Sametime servers and LDAP
"},{"location":"admin/securing_ldap_kubernetes.html","title":"Securing LDAP on Kubernetes","text":"This section covers the steps to import your LDAP trust store and password into Kubernetes as a secret, then define the secret in the Sametime configuration.
Create a trust store in p12 format that contains a copy of the LDAP server\u2019s certificate. To perform this step you will need to know the password of your trust store.
The changes in this task affect the following pods:
community
Create a secret a secret that contains your certificate.
Rename your trust store file name to ldaptruststore.p12.ls.
Copy the ldaptruststore.p12 file to the machine where you are running kubectl.
Run the following command to create the Kubernetes secret.
kubectl create secret generic ldap-config-secret --from-literal=KeyStorePassword=password --from-file=./ldaptruststore.p12\nSubstitute your password for password. If you have a namespace dedicated to Sametime, add the -n argument with your namespace to ensure the secret is created in the correct namespace.
Change to the helm directory where the Sametime installation package was decompressed. Open the values.yaml file to update the secret parameter.
Set the value of the ldapConfigSecret parameter to ldap-config-secret.
ldapConfigSecret: ldap-config-secret \nIf the parameter is commented out, remove the comment tag.
Save and close the file.
Ensure you are in the helm directory. To apply your changes to the environment run the following command, specifying the deployment name in your environment. The default for Sametime version 12 is sametime.
helm upgrade deployment\\_name.\nIf you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Note: Be sure to include the dot, it is part of the command.
Scale the Community pods to zero and then to one.
Run the following command to scale the pod to zero.
kubectl scale deploy community --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy community --replicas=1\nApply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Securing connections between Sametime servers and LDAP
"},{"location":"admin/security_mongodb_tls.html","title":"Setting up TLS for the Mongo database","text":"You can update the MongoDB connection with the Sametime server to encrypt data flowing between the Sametime server and a TLS-enabled MongoDB. This step is optional but is recommended for multi-Kubernetes-cluster deployments.
Ensure that the following conditions are met.
You can enable TLS on a connection to your MongoDB instance in two ways:
This topic covers the first method. During Sametime Meeting installation, the chatlogging.ini file is created to contain MongoDB server connection information. The connection configuration information within the chatlogging.ini file must be modified to include parameters necessary to establish a secure connection.
The Sametime administrator can specify a custom connection URL to the MongoDB server. The CL_MONGO_URL configuration parameter can be set with a MongoDB server URL which includes the required settings for the Sametime server to establish a secure connection to the MongoDB server. After adding the CL_MONGO_URL configuration parameter to the chatlogging.ini file, the default setting is overridden by the settings contained within the URL string.
If a self-signed certificate is being used, the certificate must be added to the Sametime certificate store.
Open the chatlogging.ini file which is in the HCL Notes data directory.
Update or add the CL_MONGO_URL configuration parameter.
This parameter is used to override existing configuration settings specified during installation. If changes were made post installation, this parameter exists in the file. If no changes have been made, add the parameter.
CL_MONGO_URL=mongodb://user:password@hostname\\_tcpip:port/tls\\_information\nwhere:
hostname_tcpip : The hostname or TCPIP address of the MongoDB server.
port : The port to be used for communication.
tls_information : The attributes that identify use of a TLS MongoDB. Copy and past the following into the CL_MONGO_URL parameter.
```\n /admin?retryWrites=true&w=majority&ssl=true&tlsCAFile=/local/notesdata/cacert.pem\n```\nFor example:
CL_MONGO_URL=mongodb://user:password@192.168.150.1:27017/admin?retryWrites=true&w=majority&ssl=true&tlsCAFile=/local/notesdata/cacert.pem\nSave the file and restart the Sametime server to apply the changes.
Enable TLS for the Mongo database on Kubernetes or Enable TLS for the Mongo database on Docker or Podman.
Verifying if TLS connection can be established
Enabling TLS for the Mongo database on Kubernetes
Enabling TLS for the Mongo database on Docker or Podman
Parent Topic: Securing
"},{"location":"admin/session_traversal_utilities.html","title":"Session Traversal Utilities for NAT (STUN)","text":"Session Traversal Utilities for NAT (STUN) is a standardized set of methods, including a network protocol, for NAT traversal of Network address translation (NAT) gateways in applications of real-time voice, video, messaging, and other interactive communications.
STUN is a tool used by other protocols, such as Interactive Connectivity Establishment (ICE), the Session Initiation Protocol (SIP), and WebRTC. It provides a tool for hosts to discover the presence of a network address translator and to discover the mapped, usually public, Internet Protocol (IP) address and port number that the NAT has allocated for the application's User Datagram Protocol (UDP) flows to remote hosts. The protocol requires assistance from a third-party network server STUN server located on the opposing public side of the NAT, usually the public Internet.
For more information, see Session Traversal Utilities for NAT (STUN).
"},{"location":"admin/session_traversal_utilities.html#section_p4l_jrw_v5b","title":"Why is STUN needed?","text":"Simply put, we use STUN as a tool to help clients determine their public IP address so that they can connect to each other and the Sametime server to send and receive audio and video data.
If your deployment of Sametime is all internal and there are no NAT or firewalls between the users and the server, then you might not need to use STUN.
If your deployment includes users external to your network, like people working from home, then you likely need a STUN server to help negotiate the audio and video sessions.
"},{"location":"admin/session_traversal_utilities.html#section_a5x_drw_v5b","title":"Default configuration","text":"By default, the Sametime server is configured to use the Google Public STUN servers.
For Docker, this information is configured in the .env file like this:
# STUN servers used to discover the server's public IP.\nJVB_STUN_SERVERS=stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302\nFor Kubernetes, this information is configured in the helm/values.yaml file:
jvbStunServers: stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302\nIn both cases, this configuration is telling the server to use these STUN servers:
stun.l.google.com\nstun1.l.google.com\nstun2.l.google.com\n\nUsing UDP port 19302.\nIt is important to note that if the server or clients is unable to reach the configured STUN servers, n-way meetings does not work properly. When planning your deployment, make sure that the STUN servers are available over the network.
"},{"location":"admin/session_traversal_utilities.html#section_ydm_drw_v5b","title":"Optional configurations","text":"If you already have a STUN server in your environment or wish to use an alternative public STUN server, simply update the appropriate settings above before you deploy the server. It can be modified post-deployment as well. For more information on this, see Configuring alternate STUN servers.
If your deployment does not require the use of STUN, then you can disable this by simply commenting out the appropriate line in either the .env or values.yaml file and installing the server.
Parent Topic: Network planning for meetings
"},{"location":"admin/starting_and_stopping_mongodb.html","title":"Starting and stopping MongoDB","text":"Configuring MongoDB for Sametime
When you complete the prerequisite task, a service is created. Use the service to start and stop the MongoDB server.
Windows:
Linux:
To start the server, enter the command:
service mongod start
To stop the server, enter the command:
service mongod stop
Parent Topic: Administering
"},{"location":"admin/starting_and_stopping_servers.html","title":"Starting and stopping the Sametime server","text":"Starting and stopping the Sametime server involves starting and stopping the Sametime services running in the container management system.
To manage the Sametime server on Docker, you use the docker-compose command.
To start the Sametime server on Docker, run the following command.
docker compose up -d\nTo stop the Sametime server, run the following command.
docker compose down\nOn Kubernetes, scaling the pods can be used to start and stop the Sametime service. The kubectl scale command is use.
Scale the pod to one, starts the service.
kubectl scale deploy deployment_name --replicas=1\nScale the pod to zero, where deployment_name is the pod name.
kubectl scale deploy deployment_name --replicas=0\nParent topic: Administering
"},{"location":"admin/storing_photos.html","title":"Storing photos in the Domino directory","text":"If the Sametime server is connected to a Domino LDAP server, you can store business cards photos in the Domino Directory.
The file name of the photo attached to the person document must be named ContactPhoto.jpg. Domino serves this photo as an attribute called Photo. It is possible to use a custom field with the attachment or thumbnail field type, photo types used by Domino are JPEG and GIF file types. Photo size should be smaller than 45 KB, for best results use a 10 KB sized photo. This option requires the Domino Designer Client and modifying the design, which is outside the scope of this document.
This configuration only applies to the rich clients. In order to display photos in Meetings or Web Chat, you must use the PhotoURL attribute.
The Domino directory has a field in the person document that allows the user to upload their contact. It is saved as a thumbnail which automatically reduces the size of the file.
Important considerations:
The Sametime server does not support this method of photo retrieval. If you have users with the mobile or web clients, consider using a PhotoURL instead of storing photos as attachments in the Domino directory.
Open the Notes contact file using a Notes client. The default file is names.nsf.
Locate and open the person document where the photos is to be attached.
Click Edit Person.
To the left of the First name and Last name fields, click the photo icon.
Locate the .jpeg photo file on your hard drive and rename the file to ContactPhoto.jpg.
Click the icon to upload the photo and browse to the location of the renamed photo file.
Confirm that the photo is correct and click Save and Close.
Parent Topic: Setting up business cards
"},{"location":"admin/system_requirements.html","title":"System requirements","text":"System requirements include the minimum HCL Sametime and HCL Sametime Premium requirements, such as operating systems, hardware, software, and more.
The minimum requirements must be available to install the product successfully. For details on system requirements, see the System requirements article.
The graphic below shows a simple topology with the required components: MongoDB and LDAP. The system requirements article, along with the installation and configuration topics, provides details for including them in your environment.
Parent Topic: Prerequistes
"},{"location":"admin/t_adding_signer_certs_k8s.html","title":"Retrieving photos from HTTPS hosts in Kubernetes","text":"Signer certificates establish the relationship in SSL communication. This step is needed by the Sametime server, specifically for cases where the PhotoURL is using SSL (HTTPS) to access business card photos.
After obtaining the certificate file for the host, follow these steps.
Create a generic secret containing the CA certificate.
kubectl create secret generic ca_certificates --from-file=ca-certificates.crt=ca_certificates\nPlace the values.yaml file in edit mode.
Add the following line to the values.yaml file.
caCertificateSecret: ca_certificates\nWhen done, save and close the file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up business cards
"},{"location":"admin/t_choose_connect_method.html","title":"Choosing a method for connecting to the Sametime server","text":"The Sametime Connect Client uses the connection method specified in Server Communities preferences. The global connection settings apply to all connections unless a specific server community uses an alternate connection method as defined on its Connection tab in the Preferences window.
This section explains how to configure the different types of connections.
Parent Topic: Connecting the Sametime Connect client to the Sametime server
"},{"location":"admin/t_client_connect_direct.html","title":"Connecting the client through a direct connection over TCP/IP","text":"When a user starts the Sametime Connect client with a Direct connection preference, the client connects to the Sametime server using a unique Sametime protocol over TCP/IP. By default, the server listens for this connection on port 1533. Use this preference when the connection does not need to occur through a proxy server, and the network does not block TCP/IP connections on the port used by the client.
A successful connection depends on these prerequisites.
The connection can fail if it passes through a proxy server or network that prevents direct TCP/IP Connections on the specified port.
Follow these steps to select the Direct connection method for the client.
From the Sametime Connect client, select File > Preferences.
Do one of the following:
Parent Topic: Choosing a method for connecting to the Sametime server
"},{"location":"admin/t_client_connect_proxy.html","title":"Connecting the client through a proxy connection","text":"When a user starts the Sametime Connect client with a Use proxy preference, the client connects to the Sametime server through a SOCKS, HTTP, or HTTPS proxy server.
Contact your Sametime administrator for the hostname, port, and type of proxy server in use.
The connection methods for the Use proxy option differ in the types of proxy servers they use for connecting.
SOCKS4 or SOCKS5 proxy
The client uses the Standard Sametime protocol over TCP/IP for this connection. The connection from the SOCKS proxy to the Community Services occurs on the \"Community port\" (default 1533) specified in the Sametime Connect Client Sametime Connectivity settings. This connection is the same as the Use my Internet Explorer HTTP settings preference for a user who has a SOCKS proxy server selected in Internet Explorer.
Reverse proxy
This selection allows the Sametime Connect Client to connect to a Sametime server over the Internet through a reverse proxy server. The reverse proxy server protects internal HTTP servers by providing a single point of access to the internal network.
HTTP Proxy
The client encases the standard Sametime protocol connection information within an HTTP request. Sametime Connect Client connects to the HTTP proxy, and the HTTP proxy server connects to the Community Services multiplexer on the Sametime server on behalf of the Sametime Connect Client. The HTTP connection to the Community Services multiplexer occurs on the \"Community port\" (default 1533) specified in the Sametime Connect Client Sametime Connectivity settings.
The Community Services multiplexer on the Sametime server listens for HTTP Connections on all ports specified in the Port number field in the Client Connections section within the Community Services settings of the Sametime configuration database.
Follow these steps to select the Use proxy method for the client.
From the Sametime Connect client, select File > Preferences.
Do one of the following:
Select the appropriate Proxy type.
Use SOCKS4 proxy
Specify the additional values for the proxy type you selected.
Use SOCKS4 proxy
Provide the Host name (DNS name or IP address) of the SOCKS proxy server and the port required to connect to the SOCKS proxy server.
Use SOCKS5 proxy
Parent Topic: Choosing a method for connecting to the Sametime server
"},{"location":"admin/t_client_connect_tls.html","title":"Connecting the client through a TLS connection","text":"When a user starts the Sametime Connect client with a Direct connection using TLS preference, the client connects to the Sametime server using the Transport Layer Security (TLS) protocol. Use this preference for clients that must connect through a FIPS proxy server.
Follow these steps to select the Direct connection using TLS method for the client.
From the Sametime Connect client, select File > Preferences.
Do one of the following:
Parent Topic: Choosing a method for connecting to the Sametime server
"},{"location":"admin/t_collecting_configuration_logging_data.html","title":"Collecting Sametime client configuration and log data","text":"You can collect client logs and configuration data into a zip file.
Go the Collect Support Data window.
Select one or more Sametime options, and then click Next.
If you want to reproduce the issue, click Collect. When the collection completes, a link to the collection zip file is provided.
Parent Topic: Troubleshooting Sametime clients
"},{"location":"admin/t_community_provisioning_docker.html","title":"Creating a community provisioning URL on Docker or Podman","text":"As discussed in Creating a community provisioning URL for mobile users, mobile users cannot connect to the Sametime server without a special mobile community definition that provides details needed for the connection. This topic discusses the specific steps to set up the community provisioning URL on Docker or Podman.
Ensure that you have read Creating a community provisioning URL for mobile users for the general guidelines on how to create and configure the custom provisioning URL.
Open the .env file for editing.
Add the following line.
MOBILE_CONFIGURL=hclsametime://stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\nNote: To use the user name as part of the provisioning URL, follow this format:
MOBILE_CONFIGURL=hclsametime://%s@stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\nWhen using the user name, take note of the % symbol preceding the hostname. The proxy adds the current user to the provisioning URL when the URL is generated using the web client.
Save the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Creating a community provisioning URL for mobile users
"},{"location":"admin/t_community_provisioning_k8s.html","title":"Creating a community provisioning on Kubernetes","text":"As discussed in Creating a community provisioning URL for mobile users, mobile users cannot connect to the Sametime server without a special mobile community definition that provides details needed for the connection. This topic discusses the steps to set up the community provisioning URL on Kubernetes.
Ensure that you have read Creating a community provisioning URL for mobile users for the general guidelines on how to create and configure the custom provisioning URL.
Update the environment using this format.
kubectl set env deploy/proxy 'MOBILE_CONFIGURL=hclsametime://stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server'\nThe changes persist in your deployment. To apply the changes to new deployments, you must edit the helm/charts/auth/templates/deployment.yaml file and add the new settings to the proxy: section.
containers:\n - proxy:\n<<< INSERT NEW SETTINGS HERE >>>\nInsert this, for example:
- name: MOBILE_CONFIGURL\n value: \"hclsametime:stproxyserver.example.com/?action=AddCommunity&communityName=Sametime%20Server\"\nApply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Creating a community provisioning URL for mobile users
"},{"location":"admin/t_config_alt_client_connect.html","title":"Configuring alternate communities for clients","text":"Configuring alternate communities gives users more options for logging in from their Sametime Connect Client and Sametime Embedded Client for Notes. For example, you can have a default community that allows users to connect using a direct connection when they are in the office and you can add an alternate community that allows them to connect to the same community through a reverse proxy server connection from home.
Alternate communities are defined using preferences. Before clients install, you can define preferences with a plugin_customization.ini file that goes into effect when the client logs in after installation. You can also define preferences after installation and distribute them through the policy-based managed-settings.xml file.
First define the managed IDs for each alternate community using the \"com.ibm.collaboration.realtime.community/altCommunityConfig.managedIds\" preference. This is a comma-delimited set of IDs you define.
Then for each ID, add the Community preferences reserved for alternate communities.
For example:
com.ibm.collaboration.realtime.community/altCommunityConfig.managedIds=altHost1,altHost2\ncom.ibm.collaboration.realtime.community/altCommunityConfig.altHost1.<attribute>=<attribute value>\ncom.ibm.collaboration.realtime.community/altCommunityConfig.altHost2.<attribute>=<attribute value>\nAfter you configure alternate communities and distribute them through preferences, they become available when users attempt to log in to the default community. If the default community is not available, the client then tries the alternate communities that you have defined. The client continues through the list of alternate communities until it connects successfully or all attempts fail.
Parent Topic: Connecting the Sametime Connect client to the Sametime server
"},{"location":"admin/t_configure_default_virtual_background.html","title":"Adding virtual backgrounds to the global library","text":"By default, you can customize your meetings with virtual backgrounds. As an administrator, you can choose which backgrounds are available to all users.
Parent Topic: Configuring
"},{"location":"admin/t_configure_jitsi.html","title":"Deploying multiple videobridges in different geographic locations","text":"Deploying multiple Kubernetes clusters each with a separate Sametime deployment allows for the distribution of videobridges to different locations. This type of deployment improves video streaming by reducing latency and improves bandwidth when users are geographically far from a single videobridge. The Octo Protocol is required to route video streams between videobridge servers.
Obtain the geolocation license key from Geolocation DB. The location service determines the region matching and is needed for the primary installation.
This configuration must be done as part of installation.
Run the command to prepare the primary deployment.
./prepareDeployment.sh\nWhen prompted, answer Y to the Enable Octo prompt. For more information, refer to t_meetings_configure_deployment.md.
Deploy the helm charts. Save the deployed charts for future reference. For more information, refer to t_installing_deploy_kubernetes.md.
helm install sametime .\nNote:
. represents current directory.sametime, you can choose any descriptive name for the deployment. You can also deploy the application in a namespace through the -n or --namespace option. First create the namespace with kubectl create namespace.Obtain MeetingLocationSecret, JvbAuthPassword, and JwtSecret from the primary installation. You can find this in <ReleaseName>-global-secrets.
Ensure that the TCP primary prosody is open on port 5222 for the secondary JVB to connect. The prosody host is accessible through the network load balancer if one is available in your deployment. Every deployment has a different FQDN and region. Run the command to obtain the FQDN of the prosody host on the primary deployment.
kubectl get service jitsi -o yaml | grep -E 'hostname|ip'\nIf your deployment does not have a load balancer, you can use the nginx ingress controller to forward tcp-services for port 5222. Make sure you configure the nginx-ingress-controller to enable tcp-services. Then in the tcp-services configmap, add an entry. In the following example, the primary Sametime deployment is in the default namespace.
\"5222\": default/jitsi:5222\nRun the command for the second deployment, using the information gathered in step 4.
./prepareDeployment.sh \nOptional: Repeat step 6 for every deployment if you have more than one primary or secondary installation.
Switch to each remote regional cluster and deploy each deployment using helm. Save the deployed charts.
Note: Assuming you use a single kubectl client to deploy against the primary and remote clusters, you can run the command to see the possible cluster contexts.
kubectl config get-contexts\nYou can use the --kube-context on the helm command and the --context option on the kubectl command to switch the context as you perform tasks against each deployment.
After enabling multiple video bridges, you end up with a single primary installation and one or more secondary installations. Having multiple primary installations in one or multiple regions is not required.
Open the correct port to establish a UDP connection. Primary JVB talks to secondary JVB and vice versa through JVB_OCTO_BIND_PORT.
Test the UDP connection to ensure that the users who have joined from separate bridges are able to communicate.
LTPA tokens expire by design. In the process of enabling LTPA, you can define the amount of time after which a token expires in minutes. When necessary, you can update the token expiration interval again after the value has been defined during enablement.
The following conditions must be satisfied.
Ensure that the LTPA token created when you sign in to Sametime chat allows access to other Domino applications until the expiration time has elapsed.
Open the .env file for editing.
Update the value of LTPA_DURATION_MINUTES. Specify the duration in this format:
LTPA_DURATION_MINUTES=<minutes_token_valid>\nThe following example shows LTPA_DURATION_MINUTES set to 90 minutes.
LTPA_DURATION_MINUTES=90\nAdd or update the value of JWT_ACCESS_DURATION_MINUTES. Specify the duration in this format:
JWT_ACCESS_DURATION_MINUTES=minutes_token_valid\nThe following example shows JWT_ACCESS_DURATION_MINUTES set to 30 minutes.
JWT_ACCESS_DURATION_MINUTES=30\nSave the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up SSO using LTPA
"},{"location":"admin/t_configure_ltpa_duration_k8s.html","title":"Configuring the LTPA token expiry interval on Kubernetes","text":"LTPA tokens expire by design. In the process of enabling LTPA, you can define the amount of time after which a token expires in minutes. When necessary, you can update the token expiration interval again after the value has been defined during enablement.
The following conditions must be satisfied:
Ensure that the LTPA token created when you sign in to Sametime chat allows access to other Domino applications until the expiration time has elapsed.
Update the environment using this format:
kubectl set env deploy/auth -e LTPA_DURATION_MINUTES=<minutes_token_valid>\nThe following example shows LTPA_DURATION_MINUTES set to 30 minutes.
kubectl set env deploy/auth -e LTPA_DURATION_MINUTES=30\nAdd or update the JWT_ACCESS_DURATION_MINUTES environment variable. Specify the duration in this format:
JWT_ACCESS_DURATION_MINUTES=<minutes_token_valid>\nThe following example shows JWT_ACCESS_DURATION_MINUTES set to 30 minutes.
kubectl set env deploy/auth -e JWT_ACCESS_DURATION_MINUTES=30\nFor the changes persist in your deployment and to apply the changes to new deployments, you must edit the helm/charts/auth/templates/deployment.yaml file and add the new settings to the env: section.
containers:\n - env:\n<<< INSERT NEW SETTINGS HERE >>>\n{{- if (.Values.global.ltpaRealm) }}\n - name: LTPA_REALM\n value: {{ .Values.global.ltpaRealm | quote }}\n{{- end }} \nInsert this, for example:
- name: LTPA_DURATION_MINUTES\n value: \"30\"\n - name: JWT_ACCESS_DURATION_MINUTES\n value: \"30\"\nApply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up SSO using LTPA
"},{"location":"admin/t_configure_mongodb.html","title":"Configuring MongoDB for Sametime","text":"This topic describes how to configure MongoDB on both Windows and Linux platforms to support Sametime and Sametime Premium deployments.
MongoDB security is enabled by default. Securing MongoDB is not required for Sametime but provides the best results.
Note: In the following steps, MongoDB version 6.0 is used as an example. If you are using a different version of MongoDB, refer to the official MongoDB documentation for how to issue commands for the version that you are using.
Access the Mongo Shell on the Primary node of the MongoDB cluster.
Run the db.createUser()method to add the user administrator. The following example creates the user sametimeAdmin with the userAdminAnyDatabase role on the admin database.
admin = db.getSiblingDB(\"admin\")\nadmin.createUser(\n {\n user: \"sametimeAdmin\",\n pwd: \"sametime\", // or cleartext password\n roles: [ { role: \"userAdminAnyDatabase\", db: \"admin\"}, {role:\"readWrite\", db:\"chatlogging\"}, {role:\"dbAdmin\",db:\"chatlogging\"}, {role:\"readWrite\", db:\"mobileOffline\"}, {role:\"dbAdmin\", db:\"mobileOffline\"}, { role:\"readWrite\", db:\"meeting\"}, {role:\"dbAdmin\", db:\"meeting\"}, { role:\"readWrite\", db:\"privacy\"}, {role:\"dbAdmin\", db:\"privacy\"}, { role:\"readWrite\", db:\"userinfo\"}, {role:\"dbAdmin\", db:\"userinfo\"} \n ] \n }\n )\nEnsure that passwords are random, long, and complex to prevent security breaches.
Note: As previously mentioned, the localhost exception becomes unavailable after the first user is created. Ensure that the first user has the authority to create more users. Failure to do so could mean being unable to create or modify users with new privileges when you close the localhost exception.
From mongosh, run the db.auth()method to authenticate as the user administrator.
db.getSiblingDB(\"admin\").auth(\"sametimeAdmin\", \"sametime\") // or cleartext password\nRun the db.createUser()method to add the cluster administrator. The following example creates the user sametimeClusterAdmin with the clusterAdmin role on the admin database.
db.getSiblingDB(\"admin\").createUser( \n\n { \n\n \"user\" : \"sametimeClusterAdmin\", \n\n \"pwd\" : \"sametime\", \n\n roles: [ { \"role\" : \"clusterAdmin\", \"db\" : \"admin\" } ] \n\n } \n\n) \nThe following screen is displayed when the commands are completed successfully.
Optional: Create additional users by repeating steps 1\u20134 as required for your installation.
From the MongoDB console, run the following commands to create the chatloggingdatabase with events and sessions collections in MongoDB.
use chatlogging \n\ndb.EVENTS.insertOne({\"_id\" : \"dummy\"}) \n\ndb.SESSIONS.insertOne({\"_id\" : \"dummy\"}) \nNote: The commands are case-sensitive and must be typed as shown.
After the MongoDB is configured, you can install Sametime. Refer to Installing Sametime for the details.
Parent Topic: Installing MongoDB
"},{"location":"admin/t_configure_virtual_docker.html","title":"Adding default virtual backgrounds on Docker and Podman","text":"By default, virtual background is enabled. You can choose which backgrounds are available to users by default. Depending on your business needs, you can customize the global library and prevent users from uploading custom background images. For more information, refer to Disabling custom background uploads.
Ensure that all images are in JPG or GIF format.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Copy the image files into the sametime-config/web/virtual-background/custom directory.
Run docker compose up -d command to apply all changes.
Parent Topic: Adding virtual backgrounds to the global library
"},{"location":"admin/t_configure_virtual_docker.html#task_e31_gql_z5b","title":"Removing default virtual backgrounds on Docker","text":"Existing default background can be deleted from the global library.
Edit the custom.env file in the directory where the installation package was decompressed.
Add the following statement under the REMOVE_BACKGROUND_IMAGES variable specifying the image name.
REMOVE_VIRTUAL_BACKGROUNDS=<background-N>,*<background-N\\>*\nN is a number from 1 through 7.
Start the Sametime server to apply the changes.
docker compose up -d\nBy default, virtual background is enabled. You can choose which backgrounds are available to users by default. Depending on your business needs, you can customize the global library and prevent users from uploading custom background images. For more information, refer to Disabling custom background uploads.
Ensure that all images are in JPG or GIF format.
Copy the image files into the /usr/share/jitsi-meet/images/virtual-background/custom directory under the web pod and then restart the pod.
POD=$(kubectl get po --selector=name=web-0 | tail -1 | awk ' { print $1 } ')\nkubectl cp <filename.gif> $POD:/usr/share/jitsi-meet/images/virtual-background/custom/.\nkubectl delete po $POD\nNote: Add the Namespace argument if Sametime is installed in a Namespace.
Parent Topic: Adding virtual backgrounds to the global library
"},{"location":"admin/t_configure_virtual_k8s.html#task_e31_gql_z5b","title":"Removing default virtual backgrounds on Kubernetes","text":"Existing default background can be deleted from the global library.
Edit the values.yaml file in the directory where the installation package was decompressed.
Add the following statement under the global.removeVirtualBackgrounds variable specifying the image name and then restart your pod.
global:\n removeVirtualBackgrounds=*<background-N\\>*,*<background-N\\>*\nN is a number from 1 through 7.
Note: You are not required to scale the backgrounds pod as these settings are global to the web app and only add to or subtract away from the default set of available \"system\" backgrounds. The backgrounds pod only deals with individual user settings and what background a user has selected.
The Sametime Connect client uses Server Communities preferences to connect to the Sametime server for presence and chat features.
The client uses the connection method selected in the global connection settings for all server communities unless the server community's Connection tab specifies an alternate method. This section explains how to configure the different types of connections.
Parent Topic: Managing Sametime clients
"},{"location":"admin/t_create_mongo_replset.html","title":"Setting up a replica set with keyfile access control","text":"Deploying a replica set with keyfile authentication is an important part of setting up a secure MongoDB cluster. This topic covers the said procedure as it applies to Sametime with MongoDB 6.0. For a detailed discussion on the topic and information regarding setup considerations, refer to the official MongoDB documentation.
Ensure that the following security settings have been configured.
Keyfile authentication requires each node in the replica set to have a shared keyfile that is used to authenticate each node to the others. Keyfile authentication is a powerful tool for securing a MongoDB cluster.
Note: As a best practice, use DNS hostnames instead of IP addresses when configuring replica set members or sharded cluster members and when configuring clusters across a split network horizon. Starting in MongoDB 5.0, nodes that are only configured with an IP address fail startup validation and do not start.
To set up a replica set with keyfile access control for Sametime, do the following.
Generate a keyfile. Run the following command using openssl.
openssl rand -base64 756 > /var/lib/mongo/keyfile\nchown mongod:mongod /var/lib/mongo/keyfile\nchmod 400 /var/lib/mongo/keyfile\nDistribute the keyfile to each node in the replica set. This can be done manually, by copying the keyfile to each node, or using a config file with the shared keyfile path. See the official MongoDB documentation for storage medium recommendations.
Note: Only the owner of the file can access the keyfile while running the mongod instances.
Update the MongoDB configuration file on each node to include the replica set name and the list of other members in the replica set.
If using the security.keyFile configuration file, do the following.
Define the keyfile path and replica set name in the configuration file. Include additional options as applicable.
security:\n keyFile: /var/lib/mongo/keyfile\nreplication:\n replSetName: rs0\nnet:\n bindIp: localhost,<hostname(s)|ip address(es)>\nRun the following command.
mongod --config <path-to-config-file>\nIf using the --keyFile command-line option, do the following:
Define the keyfile path and replica set name in the following command. Include additional options as applicable.
mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>\nWhere the keyfile path is /var/lib/mongo/keyfile and the replica set name is rs0.
Over the localhost interface, launch mongosh and connect to one of the mongod instances. Run mongosh on the same physical machine as the mongod instance.
Note: The localhost interface is solely accessible in the absence of any users created for the deployment.
Initiate the replica set.
From mongosh, run the following method. This procedure selects and assigns one of the members to be the primary.
Note: Ensure that you are running rs.initiate( in only one mongod instance for the replica set.
rs.initiate(\n {\n _id : \"myReplSet\",\n members: [\n { _id : 0, host : \"mongo1.example.net:27017\" },\n { _id : 1, host : \"mongo2.example.net:27017\" },\n { _id : 2, host : \"mongo3.example.net:27017\" }\n ]\n }\n)\nConnect to the primary member. To locate the primary member, run rs.status().
Parent Topic: Installing MongoDB
"},{"location":"admin/t_create_truststore.html","title":"Creating a truststore with a third-party certificate","text":"When creating a connection between the Sametime server and a service using TLS, a truststore is needed. The truststore is used to store certificates for Sametime.
To create a trust store, the Java Keytool command is used. The keytool utility must be installed to complete the steps. The command is part of the Oracle and OpenJDK toolkits. The OpenJDK is included with Sametime. For more information on keytool, see the OpenJDK The keytool Command or Oracle Tools Reference websites. Run the utility from the directory where it is installed.
Note: If you are using a Keytool version other than the version that comes installed with Sametime, see the Sametime unable to read trust store causing LDAP connection to fail knowledge article for additional configuration tasks.
The certificate used to trust the connection must be a CRT file type format. For chained certificates, you also need the root and intermediate certificates.
When using SAML connections, LDAP connections, and business card photos, there are additional considerations for creating the truststore.
Creating a truststore when using SAML
Creating a truststore when using LDAP
Creating a truststore when using business card photos
Parent Topic: Securing connections
"},{"location":"admin/t_create_truststore_LDAP.html","title":"Creating a truststore when using LDAP","text":"Ensure that you have read the section overview.
If the connection is secured using TLS, a certificate is needed to complete the SSL handshake with LDAP. If you are connecting to multiple LDAP servers that have different certificates, you need to trust each certificate in a single trust store.
The LDAP trust store file name must be ldaptruststore.p12. It is defined using the commands in this procedure.
Copy the certificates to be trusted to the machine where the keytool utility is installed, and stage them in a temporary directory.
Create a keystore by issuing the below command with the parameters:
keytool -importcert -storetype PKCS12 -keystore ldaptruststore.p12 -storepass truststore\\_password -alias alias\\_name -file file\\_to\\_trust.crt -noprompt\ntruststore_password : The desired password for your trust store. Save the password for later use.
alias_name : The value to display in the trust store, each certificate must have a unique alias.
file_to_trust.crt : The full path to the certificate you are adding to the trust store.
To import additional certificates into an existing trust store, run the below command, be sure to use a unique alias for each additional certificate.
keytool -importcert -storetype PKCS12 -keystore ldaptruststore.p12 -storepass truststore\\_password -alias aliasname -file file\\_to\\_trust.crt -noprompt\nTo implement the trust store, refer to the following topics.
Parent Topic: Creating a truststore with a third-party certificate
"},{"location":"admin/t_create_truststore_SAML.html","title":"Creating a truststore when using SAML","text":"Ensure that you have read the section overview.
When using a SAML connection, the Sametime server must be able to decode the SAML tokens. You need to know how many SAML partnerships or relying party trusts are required. For information on identifying the number, see Setting up SSO using SAML. If you are supporting more than one relying party trust, create one trust store that contains certificates for each one.
The SAML trust store file name must be samltruststore.p12.
Run the following command.
keytool -importcert -storetype PKCS12 -keystore samltruststore.p12 -storepass truststore\\_password -alias alias\\_name -file file\\_to\\_trust.crt -noprompt\ntruststore_password : The desired password for your trust store. Save the password for later use.
alias_name : The value to display in the trust store, each certificate must have a unique alias.
file_to_trust.crt : The full path to the certificate you are adding to the trust store.
Note: If you are using OpenJDK version 11 and later, add the -J-Dkeystore.pkcs12.legacy parameter to the command. For example:
keytool -importcert -storetype PKCS12 -keystore samltruststore.p12 -storepass truststore\\_password -alias alias\\_name -file file\\_to\\_trust.crt -noprompt -J-Dkeystore.pkcs12.legacy \nTo complete the configuration, refer to one of the following topics.
Parent Topic: Creating a truststore with a third-party certificate
"},{"location":"admin/t_create_truststore_businesscards.html","title":"Creating a truststore when using business card photos","text":"Ensure that you have read the section overview.
If you are retrieving photos from an HTTPS trusted URL, the Sametime Proxy service needs a truststore to properly retrieve the photos from the https-protected PhotoURL.
The truststore file name must be named proxytruststore.p12.
To create the truststore, run the following command.
keytool -importcert -storetype PKCS12 -keystore proxytruststore.p12 -storepass truststore_password -alias alias_name -file file_to_trust.crt -noprompt\ntruststore_password : The desired password for your truststore. Save the password for later use.
use.alias_name : The value to display in the truststore, each certificate must have a unique alias.
file_to_trust.crt : The full path to the certificate you are adding to the truststore.
After creating the truststore, see Retrieving photos from HTTPS hosts in Kubernetes and Retrieving photos from HTTPS hosts in Docker and Podman.
Parent Topic: Creating a truststore with a third-party certificate
"},{"location":"admin/t_dbutility_convertldap.html","title":"Converting chat history owner data from Domino directory to LDAP format","text":"The convert feature of the Sametime Database utility changes all contact list information from the Domino Directory format to LDAP format.
Stop the Sametime server prior to running the Sametime Database utility. Refer to Starting and stopping the Sametime server for the steps.
The convert task changes all contact list information from Domino Directory format to LDAP format. Changing all contact list information from Domino directory format to LDAP format converts forward slashes in the hierarchical name to commas.
Note: This task can only be performed once because you can only convert the directory format one time.
Create or edit a file that contains the environment variables.
Add the MongoDB access information to the file.
MONGO_CONNECTION_URL=mongodb://sametimeUser:xxxxxxxx@192.168.1.1:27017/admin?authSource=admin&authMechanism=SCRAM-SHA-256&readPreference=primary&directConnection=true&ssl=false\nNote: When applicable, using the values indicated, add or insert a new line below the last line for every environment variable.
Add the following statement.
TASK_LDAP=1\nRun the Database utility with the following command. The CSV file is mounted in the container in the /temp directory in the following example for the application to access and process. The tag attribute is the image tag to use.
docker run -v /temp:/temp:rw --env-file env\\_file\\_name hclcr.io/st/sametime-db-utility:tag\nTo verify your changes, view the report created in the data directory.
Parent Topic: Using the Sametime Database utility
"},{"location":"admin/t_dbutility_delete.html","title":"Deleting user IDs","text":"The delete feature of the Sametime Database utility removes specified individual contact names from contact lists and privacy lists.
Stop the Sametime server prior to running the Sametime Database utility. Refer to Starting and stopping the Sametime server for the steps.
The following is the format for the delete task in the CVS file. Each user ID to be deleted is listed on a separate line.
DELETE\n\"uid\"\nCSV files are case-sensitive and sensitive to spaces.
Create a CSV file. The file must be saved in UTF-8 format.
In the CVS file, specify the DELETE descriptor followed by the UIDs to be deleted. Specify each UID on a separate line. For example:
DELETE\nuid=John Deere,ou=sametime,dc=hcl,dc=com\nuid=Marta Smith,ou=sametime,dc=hcl,dc=com\ncn=portaladminid,o=example.com \nCopy the CSV file into an accessible read or writable location.
Create or edit a file that contains the environment variables.
Add the MongoDB access information to the file.
MONGO_CONNECTION_URL=mongodb://username:password@ip-address:port\u200b\nAdd the location of the CVS file.
DELETE_CSV=/temp/test_delete.csv\nTo delete the chat history of the affected IDs, add the following line.
DEEP_DELETE=1\nThe following is an example env_file_name file.
MONGO_CONNECTION_URL=mongodb://sametimeUser:xxxxxxxx@192.168.1.1:27017/admin?authSource=admin&authMechanism=SCRAM-SHA-256&readPreference=primary&directConnection=true&ssl=false\nDELETE_CSV=/temp/test_delete.csv\nDEEP_DELETE=1\nMount the CVS file in the container for the application to access and process.
Run the Database utility using the following command. The CSV file is mounted in the container in the/temp directory in the following example for the application to access and process. The tag attribute is the image tag to use.
docker run -v /temp:/temp:rw --env-file env\\_file\\_name.env hclcr.io/st/sametime-db-utility:tag\nTo verify your changes, view the report created in the data directory.
Parent Topic: Using the Sametime Database utility
"},{"location":"admin/t_dbutility_move.html","title":"Moving users","text":"The move feature of the Sametime Database utility allows you to move users from one organization to another.
Stop the Sametime server prior to running the Sametime Database utility. Refer to Starting and stopping the Sametime server for the steps.
The following is the format for the update task in the CVS file. Each ID to be updated is listed on a separate line. The syntax for the update task in the CVS files is:
ORGANIZATION\n\"current\\_org\",\"new\\_org\"\nCSV files are case-sensitive and sensitive to spaces.
Create a CSV file. The file must be saved in UTF-8 format.
In the CVS file, specify the ORGANIZATION descriptor followed by the UIDs to be deleted. Specify each UID on a separate line.
ORGANIZATION\n\"existing\\_organization\",\"new\\_organization\"\nFor example,
ORGANIZATION\n\"lotus\",\"ibm\" \nCopy the CSV file into an accessible read or writable location.
Create or edit a file that contains the environment variables.
Add the MongoDB access information to the file.
MONGO_CONNECTION_URL=mongodb://username:password@ip-address:port\u200b\nAdd the location of the CVS file.
DELETE_CSV=/temp/test_delete.csv\nTo delete the chat history of the affected IDs, add the following line.
DEEP_DELETE=1\nThe following is an example env_file_name file.
MONGO_CONNECTION_URL=mongodb://sametimeUser:xxxxxxxx@192.168.1.1:27017/admin?authSource=admin&authMechanism=SCRAM-SHA-256&readPreference=primary&directConnection=true&ssl=false\nDELETE_CSV=/temp/test_delete.csv\nDEEP_DELETE=1\nRun the Database utility using the following command. The CSV file is mounted in the container in the /temp directory in the following example for the application to access and process. The tag attribute is the image tag to use.
docker run -v /temp:/temp:rw --env-file env\\_file\\_name.env hclcr.io/st/sametime-db-utility:tag\nTo verify your changes, view the report created in the data directory.
Parent Topic: Using the Sametime Database utility
"},{"location":"admin/t_dbutility_update.html","title":"Updating user IDs","text":"The updates feature of the Sametime Database utility changes specified first names, last names, display names, or group names.
Stop the Sametime server prior to running the Sametime Database utility. Refer to Starting and stopping the Sametime server for the steps.
The following is the format for the update task in the CVS file. Each ID to be updated is listed on a separate line. The syntax for the update task in the CVS files is:
ID\n\"existing\\_ID\", \"new\\_ID\"[,\"new_display_name\"]\u200b\nCSV files are case-sensitive and sensitive to spaces.
The ID task works by comparing existing user IDs with the names provided in the CSV list, and replacing the IDs when a match is found. By default, comparisons are case sensitive. To allow case-insensitive comparisons of user IDs by adding the following statement to the sametime.ini file.
NC_ID_TASK_CASE_INSENSITIVE=1\nFor more information, refer to Configuring the sametime.ini file.
Create a CSV file. The file must be saved in UTF-8 format.
In the CVS file, specify the ID descriptor followed by the UIDs to be deleted. Specify each UID on a separate line. Note that
ID\n\"existing\\_ID\", \"new\\_ID\"[,\"new_display_name\"]\u200b\nFor example,
ID\n\"Maria Smith,\" \"Maria Smith-Brown\"[,\"Maria Brown\"]\nNote: The brackets [ ] indicate that the new display name is optional. If you use it, you must precede it with a comma. The new display name must immediately follow the comma. Do not leave a blank space between the comma and the new display name.
Copy the CSV file into an accessible read or writable location.
Create or edit a file that contains the environment variables.
Add the MongoDB access information to the file.
MONGO_CONNECTION_URL=mongodb://username:password@ip-address:port\u200b\nAdd the location of the CVS file.
DELETE_CSV=/temp/test_delete.csv\nTo delete the chat history of the affected IDs, add the following line.
DEEP_DELETE=1\nThe following is an example env_file_name file.
MONGO_CONNECTION_URL=mongodb://sametimeUser:xxxxxxxx@192.168.1.1:27017/admin?authSource=admin&authMechanism=SCRAM-SHA-256&readPreference=primary&directConnection=true&ssl=false\nDELETE_CSV=/temp/test_delete.csv\nDEEP_DELETE=1\nRun the Database utility using the following command. The CSV file is mounted in the container in the/temp directory in the following example for the application to access and process. The tag attribute is the image tag to use.
docker run -v /temp:/temp:rw --env-file env_file_name.env hclcr.io/st/sametime-db-utility:tag\nCopy the CSV file into an accessible read or writable location.
To verify your changes, view the report created in the data directory.
Parent Topic: Using the Sametime Database utility
"},{"location":"admin/t_define_hostserver.html","title":"Defining the host server and port for connecting to a Sametime server","text":"The Sametime Connect client uses the host and server community port preferences to determine the host name and port it should use when attempting a connection to the Sametime server.
Follow these instructions to define the host server and port for a server community.
Configuring client connectivity to the Sametime mux
Each user must update the Sametime Connect Client with the DNS name of the Sametime Community Mux server. If you have deployed multiple Sametime Community Mux servers, distribute users evenly among the servers. For example, with two multiplexers, direct half of your users to use multiplexer 1 and the other half to use multiplexer 2.
Open Sametime Connect client.
Choose File > Preferences > Server Communities.
In theServer Community field, type the fully qualified host name of the Sametime Community Mux server, such as messaging.example.com.
Parent Topic: Connecting the Sametime Connect client to the Sametime server
"},{"location":"admin/t_different_hostname.html","title":"Configuring alternate host name for Web Chat","text":"The default host name for Meetings and Web Chat are the same. However, you can configure Web Chat to use a different host name. In other words, you can use your chat host name instead of the default. There is a secondary cookie that is also used in the meeting authentication flow where if the cookie is present, then the redirect target is pulled from the cookie instead of the TARGET= parameter.
Parent Topic: Meetings
"},{"location":"admin/t_different_hostname.html#task_jww_2k2_rvb","title":"Configuring an alternate host name in Kubernetes","text":"To specify a different host name for your web chat access, update the values.yaml file. For example, if you want to webchat.company.comas your host name, add the following statement in the values.yaml file.
extraChatHostname: webchat.company.com\nTo specify a different host name, edit the custom.env file. For example, if you want to webchat.company.com as your host name add the following statement in the
REACT_APP_CHAT_SERVER_HOSTNAME\nBy default, you can upload any supported image type to use as your background during a meeting. Depending on your organization's requirements, you can disable custom background uploads by modifying the applicable file.
Kubernetes
Modify the configuration file. The default value is TRUE.
For Docker, update the value of the ENABLE_USER_VIRTUAL_BACKGROUND parameter:
ENABLE_USER_VIRTUAL_BACKGROUND=false\nFor Kubernetes, update the value of the UserVirtualBackgroundsEnabled parameter:
userVirtualBackgroundsEnabled: false\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping servers.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/t_disable_generate_report.html","title":"Disabling Sametime reports","text":"By default, meeting owners can generate meeting reports. You can change a setting to disable the ability for owners to generate meeting reports.
Update the following parameter.
For Docker, modify the value of MEETING_REPORTS_DISABLED in the .env file. The default value is false.
MEETING_REPORTS_DISABLED=true\nFor Kubernetes, modify the value of meetingReportsDisabled in the values.yaml file. The default value is false.
meetingReportsDisabled: true\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping the Sametime server.
Parent Topic: Managing Sametime Meetings
"},{"location":"admin/t_disable_recordings.html","title":"Disabling the recording feature","text":"By default, authenticated users can record meetings. As an administrator, you can disable this functionality.
Update the following parameter.
For Docker, modify the value of ENABLE_RECORDING in the .env file. The default value is 1.
ENABLE_RECORDING=0\nWhere 0 is false.
For Kubernetes, modify the value of enableRecording in the .yaml file. The default value is true
enableRecording: false\nRestart the Sametime server to apply the changes. For more information, refer to Starting and stopping the Sametime server.
Parent Topic: Managing recording options
"},{"location":"admin/t_disabling_timer.html","title":"Disabling the meeting timer","text":"By default, Sametime is configured to display the meeting duration. You can change the setting to disable the timer.
To disable the meeting timer, set the parameter to true on the Meetings server.
Modify the configuration file. The default value is false.
For Docker, change the REACT_APP_HIDE_CONFERENCE_TIMER setting in the custom.env file.
REACT_APP_HIDE_CONFERENCE_TIMER=true\nFor Kubernetes, update the helm/values.yaml file.
hideConferenceTimer: true\nDepending on your environment, do the following.
For Kubernetes, run a helm upgrade command to apply the changes to your deployment.
helm upgrade {release-name} helm/.\nParent Topic: Managing Sametime Meetings
"},{"location":"admin/t_domino_ldap_docker.html","title":"Specifying a cipher for Sametime to connect to Domino LDAP on Docker or Podman","text":"Several options that are related to the LDAP server SSL or TLS secure communications can be controlled by environment variables that are used by System SSL. This topic discusses the steps on how to specify a cipher for Sametime to connect to Domino LDAP.
By default, Domino 12.0.x LDAP servers must be configured to support a certain cipher used by Sametime. For more information, see Sametime 12.0 TLS required ciphers to connect to Domino 12.0.2 LDAP.
This task involves defining the required cipher for Sametime to connect to Domino 12 LDAP servers. To support Domino 12.0.2 LDAP connections, follow these steps.
Open the custom.env file for editing.
Add the following line.
STI__Config__STLDAP_TLS_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384\nFor more information on how to configure the sametime.ini file, refer to Configuring the sametime.ini file on Docker or Podman.
Save and close the file.
Follow the steps in the Applying configuration changes in Docker or Podman topic.
Parent Topic: Securing connections between Sametime servers and LDAP
"},{"location":"admin/t_domino_ldap_k8s.html","title":"Specifying a cipher for Sametime to connect to Domino LDAP on Kubernetes","text":"This task involves defining the required cipher for Sametime to connect to Domino 12 LDAP servers.
By default, Domino 12.0.x LDAP servers must be configured to support a certain cipher used by Sametime. For more information, see Sametime 12.0 TLS required ciphers to connect to Domino 12.0.2 LDAP.
To support Domino 12.0.2 LDAP connections, follow these steps.
Place the values.yaml file in edit mode.
Locate the sametimeIni: setting in the file, and then add the new line, indented with four spaces:
STI__Config__STLDAP_TLS_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384\nFor more information on how to configure the sametime.ini file, refer to Configuring the sametime.ini file on Kubernetes.
Save and close the file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Securing connections between Sametime servers and LDAP
"},{"location":"admin/t_enabling_community_debug.html","title":"Enabling Community debug in Kubernetes","text":"The Sametime Community pod supports a variety of debug parameters as documented in Common debug parameters for Sametime Community Server article.
Note: In Sametime versions prior to version 12, the Community services debug was handled in the sametime.ini file.\u00a0 Beginning with Sametime 12, the parameters used for Community debug are in defined in a ConfigMap in Kubernetes.
The changes in this task affect the following pods:
community
Change directories to where helm is located.;
Open the values.yaml file for editing.
In theglobal section, add the following line:
enableCommunityDebug: true\nNote: Confirm the indentation matches the other settings (two spaces).
When finished, save and close the file.
Apply the changes.
Upgrade the deployment by following the instructions in Applying configuration changes in Kubernetes or Openshift.
Run the following command to open the ConfigMap.
kubectl edit cm sametime-community-logging\nPress i to switch to edit mode.
Configure any custom debug parameters. If you know the parameter, configured with the following format.
The first characters are STI__DEBUG.
Note: Enter two underscores to separate.
If your debug parameters belong in the [Debug] section of the sametime.ini originally, add two underscores and then your parameter, followed by a colon and its value in quotes. For example, if setting VP_LDAP_TRACE=1 at the [Debug] section of the sametime.ini file, then the configuration setting is:
STI__DEBUG__VP_LDAP_TRACE: \u201c1\u201d\nNote: In the example, there are two underscores between STI and DEBUG and then two more underscores before the parameter.
If your debug setting is a component level debug such as [Debug-StUsers], then the parameter must have the same beginning STI__DEBUG, followed by a single underscore and the component name, and then two underscores and the parameter. For example, if you are setting component level debug for VP_TRACE_ALL=1 for the [Debug-StUsers] component, then the configuration setting is like the following:
STI__Debug_StUsers__VP_TRACE_ALL: \"1\"\nSave and close the ConfigMap.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/t_example_preferences_2.html","title":"Hosting client files for Sametime on Kubernetes","text":"Sametime clients can be configured by administrators using a managed-settings.xml or managed-community-configs.xml file which is hosted by a web server. Additionally, the Sametime client can be pre-configured with settings such as the host name and port. The client package can be hosted on a web server for download.
Ensure that you have access to kubectl command line tool.
Note: If Sametime is deployed in a namespace, append the -n namespace argument to all kubectl commands.
This procedure copies the file from the machine that runs kubectl to the persistent volume and have the web pod automatically retrieve the file when it starts. Use this procedure for each file that you would host in the default downloads directory.
Place the file that you are making available to users on the machine that runs kubectl. Then change directories to where the files are located.
Run the following command to get the name of the web pod.
kubectl get pods\nRun the following command to copy the file from the machine that runs kubectl to the web pod.
kubectl cp filename pod:/usr/share/nginx/downloads/.\nWhere pod is the web pod name For example, suppose the following for the variables:
The file name is managed-settings.xml
web-6d4cc59bc9-v8gf4 Then the command should be:kubectl cp managed-settings.xml web-6d4cc59bc9-v8gf4:/usr/share/nginx/downloads/.\nNote: If using a namespace, add the -n namespace argument after kubectl and before cp.
Scale the web pod to 0, then up to 1.
kubectl scale deploy/web --replicas=0 \n\nkubectl scale deploy/web --replicas=1 \nConfirm the URL is working for download. Open a browser and enter the HTTPS formatted URL:
https://sametime.example.com/downloads/managed-settings.xml\nsametime.example.com is the host name of the Sametime serverHosting files containing the same file name This topic covers the additional steps necessary for environments that require hosting multiple managed-settings.xml or managed-community-configs.xml files.
Parent Topic: Defining preferences in the managed-settings.xml file
"},{"location":"admin/t_generate_certkey.html","title":"Obtaining the cert.key and cert.crt files for Sametime","text":"The CSR is generated on the same server you plan to install the certificate on and contains information the Certificate Authority (CA) uses to create your certificate. It also contains the public key that is included in your certificate and is signed with the corresponding private key.
The CSR contains three sets of information:
Open the terminal on your computer, and depending on the platform that you are using, run the applicable code to create the certificate signing request (CSR). If you see the name of your user account in the terminal, then the task is done. Two new files (.KEY and .CSR) are generated in this process.
Provide the needed business information and submit to the Certificate Authority for signing. When successful, the Certificate Authority sends back a .CRT file.
Rename the .KEY and .CRT files into cert.key and cert.crt respectively.
Place the renamed files in the following directory.
<installation_directory.>/sametime-config/web/keys/\nWhere installation_directory is the Sametime installation directory.
You can replace or update the TLS certificates. For more information, refer to Replacing the TLS certificates for Web Chat and Meetings, Updating the TLS certificates on Docker, and Updating the TLS certificates on Kubernetes.
Parent Topic: Securing connections
"},{"location":"admin/t_host_samefilename_k8s.html","title":"Hosting files containing the same file name","text":"This topic covers the additional steps necessary for environments that require hosting multiple managed-settings.xml or managed-community-configs.xml files.
Ensure that you have access to kubectl.
Note: If Sametime is deployed in a namespace, append the -n namespace argument to all kubectl commands.
When configuring managed settings or managed community configs for different groups of users, you might require the users to have different settings. Sametime requires the file name to be the same. To support multiple files with the same name, you must put them in separate directories. This is the procedure for creating the directories in the web pod to host the files. There is no limit to the number of directories that can be created.
In the following example, there are two managed-settings.xml files for a group named east and a group named west.
Run the following command to obtain the name of the web pod.
kubectl get pods\nRun the following command to remote into the web pod, where webpod_name is the name of the pod from the first command.
kubectl exec -it webpod_name -- bash\nWhen inside the web pod, change directories to /usr/share/nginx/downloads.
cd /usr/share/nginx/downloads\nMake a directory for each file you are hosting, where directory_name is the name of the directory you are creating.
mkdir directory_name\nFor example, if hosting a managed-settings.xml for a group called east and a separate group called west, then create the directories east and west.
mkdir east\n\nmkdir west\nRun the command to exit from the pod.
exit\nOn the machine that runs kubectl, copy the managed-settings.xml file for the first group; for example, east. Then change directories to where the file is located.
Run the following command to copy the file from the machine that runs kubectl to the web pod.
kubectl cp <filename> <pod>:/usr/share/nginx/downloads/<directory_name>/.\n<filename> is the name of the file you are copying<pod> is the web pod nameWhere <directory_name> is the name of the directory you created For example, suppose the following for the variables.
The file name is managed-settings.xml
web-6d4cc59bc9-v8gf4east Then the command should be:kubectl cp managed-settings.xml web-6d4cc59bc9-v8gf4:/usr/share/nginx/downloads/east/.\nNote: If using a namespace, add the -n argument after kubectl and before cp.
Repeat step 7 for the other files that are being configured.
Scale the web pod to 0, then up to 1.
kubectl scale deploy/web --replicas=0 \n\nkubectl scale deploy/web --replicas=1 \nConfirm the URL is working for download. Open a browser and enter the https formatted URL:
https://sametime.example.com/downloads/east/managed-settings.xml\nsametime.example.com is the host name of the Sametime servereast is the name of the custom directory that was created beforemanaged-settings.xml is the name of the file being hostedParent Topic: Hosting client files for Sametime on Kubernetes
"},{"location":"admin/t_ingress_configure.html","title":"Configuring Ingress for Mux","text":"Complete the steps in the topic Installing Ingress. It is recommended to save the file that you are creating as a result of this topic. Do not save the file in the helm folder; save it at the root directory or sub-directory where the Sametime installation package was unzipped.
Sametime mux serves connections from Sametime Connect and embedded clients on port 1533. This connection can be routed through the ingress controller as well. This is suitable for an on-premise Kubernetes cluster.
If you are deploying in a cloud hosted Kubernetes environment (Google Kubernetes Engine, Amazon Elastic Kubernetes Service, etc) the Sametime mux is deployed as a Kubernetes load balancer service automatically. These steps are not necessary for cloud hosted environments.
For traffic to flow through the Ingress controller, you must apply a configuration map to Ingress.
Create a file called mux-configmap.yaml with the following content.
apiVersion: v1\nkind: ConfigMap\nmetadata:\n name: tcp-services\n namespace: namespace\\_name\ndata:\n 1533: \"default/mux:mux\"\nIf ingress is installed in a namespace, include the namespace: namespace\\_name statement, otherwise remove it.
Apply the configMap values to the configuration by running the following command.
kubectl apply -f mux-configmap.yaml\nRun the following kubectl patch command so that port 1533 is available.
kubectl -n ingress-nginx patch deployment ingress-nginx-controller --type=json -p='[\\{\"op\": \"replace\", \"path\": \"/spec/template/spec/containers/0/args\", \"value\": [\"/nginx-ingress-controller\",\"--publish-service=$(POD_NAMESPACE)/ingress-nginx-controller\",\"--election-id=ingress-controller-leader\",\"--controller-class=k8s.io/ingress-nginx\",\"--configmap=$(POD_NAMESPACE)/ingress-nginx-controller\",\"--tcp-services-configmap=$(POD_NAMESPACE)/tcp-services\"] }]' \nVerify the service. For more information, see Testing Sametime chat and meeting clients.
Parent Topic: Installing Ingress
"},{"location":"admin/t_ingress_install.html","title":"Installing Ingress","text":"When running Kubernetes on-prem, managing load-balancing must be considered for Sametime Meetings and Web Chat. Both of these Sametime features require the addition of an ingress controller.
Ingress is secured with a TLS certificate which must be created. Create a secret for ingress by following the steps in Updating the TLS certificates on Kubernetes.
If different the host names for Web Chat and Meetings are different, open the values.yaml file and add the following line to identify the Web Chat host name.
extraChatHostname: web\\_chat\\_hostname\nVerify that there are two spaces at the beginning of the line. Save and close the values.yaml file.
Consider reserving a reserve a static IP address for Sametime to use. If one is not define during the installation, the IP address is dynamic and is subject to change.
There are many different ingress controllers available, however; not all of them have been tested with Sametime. The procedure in this topic describes deploying the NGINX Ingress controller. If you are using another ingress controller, refer to the documentation for that ingress controller.
An Ingress controller is also used for the Connect and Embedded clients mux traffic deployed on-premise Kubernetes. After installing the ingress controller, additional configuraiton steps are needed. See Configuring Ingress for Mux for details.
Helm commands are used to install and configure the NGINX Ingress controller.
Add the nginx repository using the helm repo command.
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx\nUpdate the repository with the following command.
helm repo update\nRun the following command to install NGINX.
helm install nginx-ingress ingress-nginx/ingress-nginx --set controller.service.loadBalancerIP=IP\\_address \nWhere IP_address is the reserved IP address.
If you have a namespace dedicated to Sametime, include the namespace option on the command.
Verify that nginx-ingress has accepted the correct static IP address by running the kubectl get command. To break free from this, use Ctrl+C.
kubectl get ingress\nUse Ctrl+C to return to the command prompt.
Configuring Ingress for Mux
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_installing_deploy_kubernetes.html","title":"Deploying Sametime to Kubernetes cluster","text":"Before you can deploy Sametime to a Kubernetes cluster, you must create the cluster.
Two types of server nodes are required:
Review the Planning for a Kubernetes cluster configuration topic for details and other considerations.
Change to the helm directory.
Deploy the helm chart.
helm install sametime .\nIf there are any errors, you must remove the installed product and fix the error before trying the installation again. See Uninstalling Sametime on Kubernetes for details.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_installing_docker_extrahosts.html","title":"Defining extra hosts for Docker deployments","text":"Extra hosts for Docker deployments can be defined when there are network or DNS issues. Defining extra hosts is optional and not a requirement to ensure the connections are successful.
In some cases on CentOS 8, the host names fail to resolve properly. If the DNS is unreliable in resolving host names to IP addresses, these can be defined manually in the configuration. The following steps work for all supported Linux versions.
Note: When modifying the yml file, the indentations use spaces to indent the text. Do not use tabs. The entries within the file must line up exactly.
Use the networks: placement as a reference for extra_hosts: and the sametime.test: placement as a reference for where the - is placed.
Open the docker-compose.yml file in edit mode.
The following components require a connection to the MongoDB server. Locate and update each section with the MongoDB host name and IP address.
networks add an extra_hosts statement, where mongoDB_host is the fully qualified hostname of the MongoDB server and mongoDB_IP_address is the IP address of the MongoDB server.extra_hosts: \n - mongoDB\\_host: mongoDB\\_IP\\_address\nFor example:
The community component requires a connection to the LDAP server. Locate and update this section with the LDAP host name and IP address.
After networks add an extra_hosts statement, where ldap_hostname is the fully qualified host name of the LDAP server and ldap_ip_address is the IP address of the LDAP server.
extra_hosts: \n - ldap.host: ldap\\_ip\\_address\nFor example:
The jvb component requires a connection to the STUN servers. In the jvb section, add an extra_hosts section an include a statement for each STUN server, where stun_host_name is the fully qualified host name of the STUN server, and stun_ip_address is the IP address of the STUN server.
- stun\\_host\\_name:stun\\_ip\\_address\nFor example:
extra_hosts:\n - stun_host_name:stun_ip_address\n - stun1_host_name:stun1_ip_address\n - stun2_host_name:stun2_ip_address \nResolve the host names of the STUN servers and use the corresponding IP address for your region. In the following graphic, the Google STUN servers are used with the regional resolved IP addresses.
Verify that the formatting is correct. Correct any indentations using spaces.
Save the changes.
Run the following commands to apply the changes.
docker-compose down\ndocker-compose up -d\nParent Topic: Installing Sametime in a Docker or Podman environment
"},{"location":"admin/t_installing_podman_extrahosts.html","title":"Configuring container networking with Podman","text":"The network layer does not have DNS resolve available between containers. This topic provides information on the network configurations needed to resolve network or DNS issues in Podman environments.
Ensure that the podman-compose version is 1.0.4 or higher. To update podman-compose, run the following command.
curl -o /usr/local/bin/podman-compose https://raw.githubusercontent.com/containers/podman-compose/devel/podman_compose.py\nchmod +x /usr/local/bin/podman-compose\nIf you are using Red Hat\u00ae Enterprise Linux\u00ae and Podman, you must configure the RHEL nodes to ensure the connections are successful.
Note: All commands provided require running as ROOT or SUDO access. If not running as root user, preface the commands in steps 1 and 2 with sudo.
Run the command to install Netavark.
dnf install netavark\nPlace the containers.conf file in edit mode.
sudo vi /etc/containers/containers.conf\n[network]\nnetwork_backend = \"netavark\"\nDo a force reset.
podman system reset --force\nBind Sametime to port 443.
sysctl net.ipv4.ip_unprivileged_port_start=443\nParent Topic: Installing Sametime in a Docker or Podman environment
"},{"location":"admin/t_keystore_mux.html","title":"Creating a keystore for Sametime mux","text":"A keystore consists of a private key and a certificate. Sametime supports both a third-party certificate, signed by a Certification Authority (CA), or a self-signed certificate. Request a certificate and private key from your CA for the hostname used by the Sametime mux. This is the microservice that listens on port 1533 for requests from the Sametime Connect clients (installed clients on desktop). In Kubernetes, the mux is either a Kubernetes service (for example, a load balancer type service) or a Kubernetes ingress service for on-premise Kubernetes. For Docker deployments, the mux listens on port 1533 and does not require any additional service.
Creating a keystore for Sametime mux: third-party CA
Creating a keystore for Sametime mux: self-signed certificate
Parent Topic: Securing connections between the Sametime mux and the Connect and Embedded clients
"},{"location":"admin/t_keystore_self_signed.html","title":"Creating a keystore for Sametime mux: self-signed certificate","text":"Run the following command to create a private key.
openssl genrsa -des3 -out server.key 2048\nThe key length can be modified to meet your requirements. The longer the key length, the more secure it is.
Note: The command prompts for a password. Record this password in a secure place for future reference.
Create a certificate signing request, which in this case, is signed by the self-signed CA. Run the command to create the self-signed x509 certificate.
openssl req -new -key server.key -out server.csr\nWhen you run the command, you must provide the following:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt\nIn the above command, the days parameter is 365 and can be modified.
Create the keystore.
openssl pkcs12 -export -in server.crt -inkey server.key -name \u2018mux\u2019 -out keystore.p12\nThe sample command makes use of the following naming conventions.
`server.crt`: Signed certificate filename\n`server.key`: Private key filename\n`\u2018mux\u2019`: Alias name (how it appears in the keystore)\n`keystore.p12`: The resulting keystore file name\nAfter the keystore is created, do the following:
Parent Topic: Creating a keystore for Sametime mux
"},{"location":"admin/t_logging_tracing.html","title":"Logging and tracing on the Sametime Embedded and Connect clients","text":"Trace logs are stored in a workspace folder on the user's local hard drive or a network drive. Sametime Embedded and Connect client users can enable tracing on their client with the following instructions.
Locate the client workspace.
On the computer where you use the client, use a text editor and open the rcpinstall.properties file which is located in the following directory according to the client:
C:\\Users\\user_name\\AppData\\Roaming\\HCL\\Sametime\\.config\\rcpinstall.propertiesC:\\Program Files\\HCL\\Notes\\Data\\workspace\\.config\\rcpinstall.propertiesC:\\users\\user_name\\AppData\\Local\\HCL\\Notes\\Data\\workspace\\.config\\rcpinstall.propertiesMac OS
Note: Use the Cmd+Shift+Dot keyboard combination to show hidden folders.
/Users/user_name/Library/Application Support/HCL Sametime Data/.config/rcpinstall.properties/Users/user_name/Library/Application Support/HCL Notes Data/Expeditor/Applications/.config/rcpinstall.propertiesC:\\users\\user_name\\AppData\\Local\\HCL\\Notes\\Data\\workspace\\.config\\rcpinstall.propertiesAdd the following lines to the end of the file, depending on what kind of issue you're diagnosing.
com.ibm.collaboration.realtime.level=FINEInstant messaging issues
com.lotus.sametime.community.kernel.level=FINER \ncom.lotus.sametime.im.level=FINEST\ncom.lotus.sametime.places.level=FINEST\ncom.ibm.collaboration.realtime.rtcadapter.level=FINEST \ncom.ibm.collaboration.realtime.people.internal.level=FINE \ncom.ibm.collaboration.realtime.internal.sametime.level=FINER \ncom.ibm.collaboration.realtime.login.level=FINEST\ncom.ibm.collaboration.realtime.community.internal.level=FINEST\nGeneral login failure
com.ibm.collaboration.realtime.community.internal.level=FINEST\ncom.ibm.collaboration.realtime.im.community.level=FINEST\norg.apache.commons.httpclient.level=FINE\ncom.ibm.rcp.internal.security.auth.module.level=FINEST\ncom.ibm.collaboration.realtime.login.level=FINEST\ncom.lotus.sametime.community.level=FINEST\nSSO failures
com.ibm.collaboration.realtime.community.internal.level=FINEST\ncom.ibm.collaboration.realtime.im.community.level=FINEST\norg.apache.commons.httpclient.level=FINE\ncom.ibm.rcp.internal.security.auth.module.level=FINEST\ncom.ibm.collaboration.realtime.login.level=FINEST\ncom.lotus.sametime.community.level=FINEST\ncom.ibm.rcp.internal.security.level=FINEST\ncom.ibm.rcp.security.level=FINEST\nManaged settings
com.ibm.collaboration.realtime.policy.sametime.managedsettings.level=FINEST\nCalendar integration issues
com.ibm.rtc.meetings.servers.level=FINEST\ncom.ibm.rtc.meetings.shelf.level=FINEST\ncom.ibm.rtc.meetings.shelf.ui.level=FINEST\ncom.ibm.rtc.meetings.util.level=FINEST\ncom.ibm.collaboration.realtime.calendar.level=FINER\ncom.ibm.collaboration.realtime.calendar.notes.level=FINEST\nConnectivity issues
com.ibm.rtccore.level=FINEST\ncom.ibm.rtc.spaces.level=FINER\nTo reduce the number of log and trace files from being overwritten, increase the option values of the following settings from the default values. The default values are:
com.ibm.rcp.core.internal.logger.boot.RCPTraceHandler.count=20\ncom.ibm.rcp.core.internal.logger.boot.RCPLogHandler.count=12\nSave and close the file.
Restart the Connect client.
View the error log and trace files in the Connect client, by clicking Help > Support > View Log and View Trace.
In most cases, View Trace provides the most useful information.
You can include logs and other data into a compressed ifle to send to support for diagnostics.
In the Notes embedded client, click Help > Support > Collect Support Data. In the stand-alone Connect Client, click Gear icon > Help > Support > Collect Support Data.
Select Enable Customized Tracing, and then click Next.
Select one or more Sametime options, and then click Next.
Specify if you want to reproduce the issue, and then click Collect. When the collection completes, a link to the zip file is provided.
The resulting file is located
Parent Topic: Troubleshooting Sametime clients
"},{"location":"admin/t_manage_user_login_docker.html","title":"Managing user sign-on on Docker or Podman","text":"A token is maintained by the Sametime server to control how often you sign in. The default value is 30 days. You can modify this value or turn off the feature by including the JWT_REFRESH_DURATION_DAYS environment variable in the YAML file. You can specify any number of whole days to retain login credentials. To disable this feature, set the value to 0.
When you modify the docker-compose.yml file, follow the syntax rules for YAML files to prevent coding errors. When you modify the YAML file, the indentations of entries are spaces, not tab characters.
Edit the docker-compose.yml file and locate the auth section within the file.
The file is in the root directory.
Add the JWT_REFRESH_DURATION_DAYS environment variable.
Specify the duration in this format:
JWT_REFRESH_DURATION_DAYS=number\\_of\\_days\nThe following example shows the auth section with the JWT_REFRESH_DURATION_DAYS environment variable set to 10 days.
Save the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Managing user sign-on
"},{"location":"admin/t_manage_user_login_k8s.html","title":"Managing user sign-on on Kubernetes","text":"A token is maintained by the Sametime server to control how often you sign in. The default value is 30 days. You can modify this value or turn off the feature by adding the JWT_REFRESH_DURATION_DAYS environment variable. You can specify any number of whole days to retain login credentials. To disable this feature, set the value to 0.
You can change settings temporarily or permanently. To temporarily change the setting, run the following command to change the setting in a deployed environment.
kubectl set env deploy/auth JWT_REFRESH_DURATION_DAYS=number\\_of\\_days\nTo permanently change the setting, complete the following steps:
Edit the deployment.yaml file, which contains the auth environment variables.
You can find the file in the helm/charts/auth/templates directory.
Add the JWT_REFRESH_DURATION_DAYS environment variable.
Specify the duration in this format:
name: JWT_REFRESH_DURATION_DAYS value: number\\_of\\_days\nThe following example shows the auth section with the JWT_REFRESH_DURATION_DAYS environment variable set to 10 days.
Save the changes.
Perform a helm upgrade to deploy the updated chart.
Parent Topic: Managing user sign-on
"},{"location":"admin/t_managing_transfer_data.html","title":"Managing file transfer data","text":"As with meeting recordings and reports, files that are shared in the chat are stored in a Docker volume or a Kubernetes persistent volume. By default, you can download these files within 90 days.
You can modify the limit by updating the following files.
Kubernetes
helm/values.yaml
Note: The values are case sensitive and must be entered as shown below.
Modify the configuration file. The minimum value is 1.
Parent Topic: Administering
"},{"location":"admin/t_meetings_configure_deployment.html","title":"Preparing the deployment","text":"This section provides information on how to configure secrets for deployment.
Run the following script to prepare the deployment.
./prepareDeployment.sh\nLDAP server host
Enter the fully qualified host name or the IP address of the LDAP server.
LDAP server port
Enter the port used by LDAP.
Configure advanced LDAP settings
Enter Y to configure advanced LDAP settings. Provide the following information.
-- LDAP bind user name
-- LDAP bind password
-- LDAP base DN for searching users
-- LDAP base DN for searching groups
Enter N to bypass the above prompts. This option results in an anonymous LDAP connection and sets the default settings for searching.
Sametime server name
Enter the fully qualified Sametime server name. This value needs to be the fully qualified host name of the Sametime server. If you are separating host names for meeting and chat, enter the meeting host name. Server domain name
Enter the server domain name. This should be the DNS suffix of the host name of the server.
Video bridge IP address
Enter the video bridge IP address. When left empty, the system automatically scans and populates the field with the discovered IP address.
Base64 encoded secret
Enter the Base64 encoded JWT_SECRET from the Sametime deployment. If migrating from another version of Sametime, you can re-use your existing secret. Otherwise, leave blank and press Enter to generate a new one.
Mongo host
Enter the fully qualified host name of your MongoDB server. The default value is mongo. If you have more than one host, provide any of the hosts. You can provide the rest later on when prompted.
Mongo port
Enter the MongoDB port. The default value is 27017.
Mongo admin user name
Enter the Mongo administrator user name.
Mongo admin user password
Enter the Mongo administrator password
MongoDB connection URL
The default Mongo connection URL is [($TEMP_URL)]. Would you like to override? [Y/N]
mongodb://<user>:<password>@<server1>:<port>,<server2>:<port>,<server3>:<port>\nTURN server address
Leave blank if you are not using TURN. Otherwise, enter the fully qualified host name of the TURN server.
For more information, refer to [Configuring the TURN server for Docker and Podman](turnserver_meetings_docker.md) and [Configuring the TURN server for Kubernetes](turnserver_meetings_kubernetes.md).\nConfigure LTPA
Lightweight Third-Party Authentication (LTPA) is useful for achieving single sign-on with HCL Domino (including HCL Verse and iNotes), HCL Connections, HCL Digital Experience, and IBM WebSphere Application Server. The default value is N.
To configure LTPA, enter Y and provide the following information.
- The full path to the LTPA keys file. This should be the full path on the machine where the `prepareDeployment.sh` script is running. For example: /tmp/ltpa.keys\n- LTPA keys password\nFor more information, refer to Setting up SSO using LTPA.
Enable Octo
Octo allows you to extend the audio-video traffic to another network in an efficient way. If enabled, at least one other secondary cluster must be configured in order for this to work. To enable octo, enter Y. The following prompts are displayed.
For more information, refer to Deploying multiple videobridges in different locations.
- Is this a primary installation?\n - Select **Yes** to set this instance as the primary server. For primary servers, you must provide the region name. Enter the name of the primary region.\n - Select **No** to set this instance as a regional server. For regional servers, you must provide the region name. Enter the secondary region name.\n - If no, you must enter the fully qualified host name of your primary installation. Provide the following information.\n - Prosody host from primary installation\n - Meeting location secret in base64 from primary installation\n - JVB authentication password in base64 from primary installation\n\n **Note:** On your primary cluster, run this script to obtain the values for the meeting location secret and JVB authentication password.\n\n ``` {#codeblock_pdy_r1l_z5b}\n kubectl get secret sametime-global-secrets -o yaml | grep -E 'MeetingLocationSecret|JvbAuthPassword'\nChange directories to helm.
Open values.yaml for editing.
Locate the setting hclImageRegistry: and then set the value to your image repository name. If you are using a secret to access the image repository, then set the hclImagePullSecret value with the name of the secret for the image repository.
This is the Docker repository where the Sametime Docker images are located. If you use a cloud provider image registry or your own private registry, you should update this setting to the base name of that image registry. The default is http://hclcr.io/st and assumes that you have executed the ./load.sh script with its default configuration on each Kubernetes node.
Locate the setting sametimeClaim. This is the name of the persistent storage volume claim that is used by recordings, proxy, files, and backgrounds for storage.
You can also modify other values at this time to enable, disable, or configure features.
Save and close values.yaml.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_meetings_kubernetes.html","title":"Configuring host aliases for Kubernetes deployments","text":"If your Kubernetes environment is unable to consistently resolve the host names of the supporting servers (MongoDB, Sametime Proxy, STUN) using DNS, configure the hosts manually.
In Kubernetes, you can add host names and their corresponding IP addresses to the host aliases. In a Sametime Meetings on Kubernetes deployment, this setting is defined in the deployment.yaml in the various templates for each Kubernetes pod.
Table 1 lists the pod name and template for each host to be resolved.
Modify each template specified in Table 1 to include the host name and IP address of the required supporting server.
Complete the following steps to modify each template in the table to include the host name and IP address of each supporting server.
Note:
Open the template for editing.
Locate the following line and insert a new line.
restartPolicy=Always\nUse this example text as a template and include the host names that need to be resolved:
hostAliases: \n - hostnames: \n - \"ldap.company.com\" \n ip: \"10.10.10.10\" \n - hostnames: \n - \"mongodb.company.com\" \n ip: \"10.10.10.11\" \nNote: In the hostnames field, your server might only be known as one host name. You can add multiple aliases.
Before saving the template, ensure the indentations are correct, using only spaces for indentation. The hostAliases: line should line up exactly under the restartPolicy line at the same level of indentation. You might need to correct the other lines as well after copying and pasting them.
Save and close the template when changes are complete.
After this process is complete, continue to the steps to install Sametime. See load_stimages_local.md. If Sametime is already installed, follow the procedures in the apply_configchanges_kubernetes.md topic to apply the changes.
"},{"location":"admin/t_meetings_prepare_network.html","title":"Preparing the network","text":"This section provides information on the network considerations needed to install Kubernetes.
Network considerations
Sametime Meetings uses UDP on port 30000 by default for media streams. Ensure that the clients to service have UDP inbound access to this port and that outbound UDP traffic from the deployment is unrestricted.
The Sametime server must be able to connect to MongoDB with a user account which has the authority to create databases. The database is created during the installation.
STUN Service
Sametime Meetings use internet accessible STUN servers to help clients and the server negotiate media paths for the exchange of audio/video/appshare data. Public Google STUN servers are configured by default.
These addresses must be reachable by the container. If they are not, there may be issues joining meetings.
stun.l.google.com:19302\nstun1.l.google.com:19302\nstun2.l.google.com:19302\nTo change the defult STUN server, see Configuring alternate STUN servers. For further information on STUN, see the topic Session Traversal Utilities for NAT (STUN).
Ingress Controller
Kubernetes uses internal private network addresses for deployed services. Sametime uses an Ingress for incoming web traffic and either a LoadBalancer, NodePort, hostNetwork binding for media traffic. An ingress controller is required for the incoming web traffic and either the LoadBalancer or the IP address of the video node must be accessible for the media traffic.
DNS Considerations
Your Kubernetes cluster must be able to resolve the supporting servers: MongoDB, Sametime Proxy, and STUN. If DNS is unreliable or not able to resolve these hostnames to their IP addresses, complete the topic Configuring Host Aliases for Kubernetes deployments.\"
See Loading the Sametime images to a Docker repository.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_meetings_recordings.html","title":"Creating the persistent volume","text":"This section provides information to create the persistent volume.
In previous releases of Sametime, only the recordings pod require access to the persistent volume. In Sametime 12, workloads moved from virtual or physical machines into Kubernetes pods. There is more than one type of pod that requires access to storage in Sametime 12. Sametime requires an access mode called read write many or RWX which allows more than one node to access the volume at a time.
Recordings
Meeting recordings are stored as MP4 files in a temp directory on the meeting recorder nodes during the meeting. After the meeting, the recordings are moved to a persistent volume. Allocate a volume accessible to the Kubernetes cluster that is substantial enough to handle the expected number of meeting recordings, assuming a rate of about 100M per 1 hour of meeting.
By default, recordings persist for three days, so keep that in consideration as well when sizing the volume.
Backgrounds
When users upload personal backgrounds to their meetings for use as a video background, these images are stored in the persistent volume.
Files
When users upload files to chats in the chat clients or meeting, the files are stored in the persistent volume.
Branding
When enabling custom meeting branding, the images used are stored in the persistent volume.
Reports
Meeting reports are saved in the persistent volume.
For additional information, see the Persistent Volumes topic in the Kubernetes documentation.
Parent Topic: Installing Sametime in a Kubernetes environment
"},{"location":"admin/t_proxy_docker.html","title":"Configuring Docker and Podman to use a proxy server for push messaging","text":"When Sametime proxy interacts with mobile devices (phones, pads, watches, and cars), it sends notifications through push networks such as Apple's \"APNS\" and Google's \"FCM.\" To send APNS or FCM messages through a proxy server in Docker or Podman, follow these steps:
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Update the following values in your custom.env file.
push-proxy.company.com. Alternatively, you can enter the IP address of the push-proxy. For example, 123.111.222.333.3128.STCONF\\_PUSH\\_PROXY\\_SERVER=\"push-proxy.company.com\"\nSTCONF\\_PUSH\\_PROXY\\_PORT=\"3128\"\nSTCONF_PUSH_PROXY_USER=\"\"\n`STCONF_PUSH_PROXY_PASSWORD`=\"\"\nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Push messaging through a proxy
"},{"location":"admin/t_proxy_k8s.html","title":"Configuring Kubernetes to use a proxy server for push messaging","text":"When Sametime proxy interacts with mobile devices (phones, pads, watches, and cars), it sends notifications through push networks such as Apple's \"APNS\" and Google's \"FCM.\" To send APNS or FCM messages through a proxy server in Kubernetes, follow these steps:
Update the following values in your values.yaml file.
push-proxy.company.com. Alternatively, you can enter the IP address of the push-proxy. For example, 123.111.222.333.3128.pushProxyServer: \"push-proxy.company.com\"\npushProxyPort: \"3128\"\npushProxyUser: \"\"\npushProxyPasswordBase64: \"\"\nRestart the pod.
Parent Topic: Push messaging through a proxy
"},{"location":"admin/t_push_proxy.html","title":"Push messaging through a proxy","text":"Depending on your network settings, your firewalls could prevent Sametime proxy from connecting to push networks like Apple Push Notification Service (APNS) and Firebase Cloud Messaging (FCM) through the Internet. Sametime supports the sending of APNS and FCM messages through a proxy server. If you need to send APNS or FCM message through a proxy server in your environment, you need to configure the settings for the messages you want routed through the proxy.
Configuring Docker and Podman to use a proxy server for push messaging
Configuring Kubernetes to use a proxy server for push messaging
Parent Topic: Configuring
"},{"location":"admin/t_resolving_business_cards.html","title":"Resolving problems with business cards","text":"If business cards are not displaying user information as expected, first check the server configuration, then the client, and finally, the business cards themselves.
To check the server configuration, verify that the storage repository, such as LDAP used with the Sametime server is configured correctly. A configuration problem is the most likely cause of problems with business cards. For more information, see Setting up business cards.
If the configuration is correct, next verify that the business card information on requested from the clients is working correctly. For this, trace the UserInfo servlet flows to verify that the UserInfo servlet is working correctly. The UserInfo servlet runs on the server retrieves business card information on request from clients and responds to client requests. To determine if there are errors on the exchange of information, enable the UserInfo Debug trace.
If the UserInfo servlet on the server is responding correctly, enable client-side tracing to determine what is happening on the client. Follow the instructions in Logging and tracing on the Sametime Embedded and Connect clients. For Web clients, review the Proxy service logs and capture a browser HTTP Archive (HAR) file to review the business card information received.
Parent topic: Troubleshooting
"},{"location":"admin/t_resolving_business_cards.html#task_cmx_2pp_r5b","title":"Enabling the UserInfo Debug trace on Docker","text":"If a debug.env doesn't exist in the directory where the installation package was decompress, you must create it.
Add the following line to the debug.env file.
STI__debug__USERINFO_DEBUG_LEVEL=5 \nAdd the debug.env in the community section of the docker_compose.yml file.
Save the file.
Start the Sametime server to apply the changes and enable the trace.
docker compose up -d\nEdit the values.yaml file, changing the enableCommunityDebug property from false to true. Save this change.
Edit sameteime-community-logging ConfigMap, and add the following line to the data section.
STI__debug__USERINFO_DEBUG_LEVEL: \"5\"\nFor example:
kubectl edit cm sametime-community-logging\nApply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nSigner certificates establish the relationship in SSL communication. This step is needed by the Sametime server, specifically for cases where the PhotoURL is using SSL (HTTPS) to access business card photos.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
After obtaining the certificate file for the host, follow these steps.
Place the docker-compose.yml file in edit mode.
Find the proxy section and add the following volume.
volumes: \n - custom-config/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt\nFor example,
proxy:\n image: hclcr.io/st/chat-proxy:${BUILD_LEVEL}\n restart: ${RESTART_POLICY}\n env_file: custom.env\n volumes:\n - custom-config/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt\n - proxy-workspace:/workspace/proxy-storage\n environment:\n - JAVA_TOOL_OPTIONS=-XX:MaxDirectMemorySize=64M -XX:MaxMetaspaceSize=192M\n - SAMETIME_EXTERNAL_WARINTEGRATION\nSave the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up business cards
"},{"location":"admin/t_security_mongodb_tls_docker.html","title":"Enabling TLS for the Mongo database on Docker or Podman","text":"Ensure that the you have read the introductory topic and verified that the TLS connection itself can be established. For more information, refer to Verifying if TLS connection can be established.
Locate the local .pem file to use with your Mongo deployment. For more information, refer to the official MongoDB documentation.
Modify your Mongo URL to use TLS. For more information, refer to Setting up TLS for the Mongo database.
Open the docker-compose.yml file in edit mode.
Add the volume mount to the Community section of the YAML file.
/opt/sametime/cacert.pem:/local/notesdata/cacert.pem\nSave the changes.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up TLS for the Mongo database
"},{"location":"admin/t_security_tls_mongodb_k8s.html","title":"Enabling TLS for the Mongo database on Kubernetes","text":"Ensure that you have read the Setting up TLS for the Mongo database topic. Verify if you have a valid TLS certificate. See Creating a truststore with a third-party certificate for the details.
Configure the Sametime server to use TLS.
Create a secret with your certificate.
kubectl create secret generic mongo-secret --from-file=<ca.crt>\nOpen the values.yaml file in edit mode.
Add the following secret.
mongoSecret: mongo-secret\nSave the changes.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Setting up TLS for the Mongo database
"},{"location":"admin/t_testing_sametime_chat.html","title":"Testing Sametime chat and meeting clients","text":"This article assumes that you have successfully installed and configured Sametime or Sametime Premium.
Before going live, it is important to test the following services to ensure that Sametime is working as expected.
Verify if the Sametime web client chat is running. Using a web browser, go to the URL:
https://yourserver.domain.com/chat\nThe yourserver.domain variable is the name of your Sametime server and the domain name.
Verify if the Sametime server is running. Using a web browser, go to the following URL:
https://yourserver.domain.com \nhttps://yourserver.domain.com/meeting\nVerify if the Sametime Connect client and Sametime embedded client (in HCL Notes) are running.
Add a Sametime Server Community under Preferences specifying the Host server and Server community port.
The default Server community port value is 1533.
Enter a username and password on the Log In tab.
Select OK to save the changes.
Log in using the new credentials.
Parent Topic: Administering
"},{"location":"admin/t_troubleshooting_clients.html","title":"Troubleshooting Sametime clients","text":"Use this information on troubleshooting and logging tools to diagnose and resolve problems affecting the HCL Sametime clients.
Parent Topic: Troubleshooting
"},{"location":"admin/t_troubleshooting_ldap_kubernetes.html","title":"Troubleshooting LDAP on the community pod","text":"If you are having difficulty connecting to a secure LDAP server, perform the following troubleshooting steps.
Log into the community pod.
Find the name of the community pod using the kubectl get pods command. The results shows the pod names which contains hashes.
Run the following command to log into the community pod. Include the pod name.
kubectl exec -it pod\\_name --container=community -\u2013 bash \nConfirm that the community pod is receiving the trust store. Look for the ldaptruststore.p12 file in /local/notesdata directory.
Confirm that LDAP secret has been created in the correct namespace if using namespaces.
Open the values.yaml file and confirm that the LDAP secret name is specified correctly in the ldapConfigSecret: \"ldap-config-secret\" format.
Confirm that the sametime.ini and UserInfoConfig.xml files are updated.
Open the /local/notesdata/sametime.ini file in the community pod. and confirm the LDAP TLS settings are present.
Locate the following statements in the file:
STLDAP_TLS_TRUST_STORE_TYPE=p12 \nSTLDAP_TLS_TRUST_STORE_FILE = /local/notesdata/ldaptruststore.p12 \nThe file name and path are hard coded and should not changed.
STLDAP_TLS_TRUST_STORE_PASSWORD= thepassword\nThis should be your actual password for the trust store. If these are missing, confirm the values.yaml settings are present as mentioned in the confirm you have the correct configuration details step.
Open the /local/notesdata/UserInfoConfig.xml and confirm that you see the correct details in the <Storage Details> section for the host name and port of the LDAP server.
Confirm that the below line is present, where \u201cthepassword\u201d is your trust store password:
<SslProperties KeyStorePath=\"/local/notesdata/ldaptruststore.p12\" KeyStorePassword=\"password\" />\nIf anything in this section is missing, examine the settings in the values.yaml file for accuracy as decribed in the next step.
Confirm you have correct configuration details .
Confirm your other values in the values.yaml pertaining to LDAP:
ldapHost:
ldapHost: server\\_host\\_name\nldapPort: \"636\"\nldapTls: true\nWhere server_host_name should be the LDAP server host name or IP address.
Check the bind credentials in the sametime-global-secrets, they are base64 encoded. First, issue the command: kubectl edit secret sametime-global-secrets
Locate the lines beginning with LdapBindEntryDn and LdapBindEntryPassword. Take the value of each setting and base64 decode them, they should be your Bind DN and the Bind password. If these are wrong, then base64 encode them. To decode the values, issue the following command:
echo -n \u2018value\u2019 | base64 -d \nWhere \u2018value\u2019 is the encoded value in the secret.
If you need to change the credentials, you can set it to the base64 encoded value of the correct Bind name and password, directly in the secret, but it should also be set in the template file as well. If you fail to update the template file, then your existing secrets are overridden when you run a helm upgrade command. The template file is located where the helm directory was saved, and it is found under /helm/templates/sametime-secrets.yaml
To change the Bind credentials, see Changing the LDAP service account password in Kubernetes. For more information on secrets, see the Managing secrets in Kubernetesand Modifying secrets topics.
If you are overriding the default configuration using an extra-community-config secret, there are additional steps to take to correct the Bind DN. See Changing the LDAP service account password in Kubernetes.
Confirm TLS is negotiating properly between Sametime and LDAP
Sametime connects to LDAP attempting to negotiate TLS with the following ciphers:
RSA_WITH_AES_256_GCM_SHA384 (0x009D) RSA_WITH_AES_128_CBC_SHA (0x002F)
Support for at least one of the ciphers might need to be added to your LDAP server, such is the case for HCL Domino 12.0.2, for details see Sametime 12.0 TLS required ciphers to connect to Domino 12.0.2 LDAP
There is a known issue when using a newer version of keytool to create the trust store, Sametime is unable to read it. To work around the problem, recreate the trust store with keytool and add the argument: -J-Dkeystore.pkcs12.legacy to the command. For more details, see the Sametime unable to read trust store causing LDAP connection to fail article.
An example of this is the Google Kubernetes Engine IP masquerade agent solution. For more information, see the IP masquerade agent Google Cloud topic. Each cloud provider has an unique solution, see your vendor\u2019s documentation for more details.
The community pod must resolve the host name of the LDAP server, or you can configure the IP address instead. If the host name of the LDAP server does not resolve in DNS, you can configure Host Aliases for the Community pod.
See the Configuring host aliases for Kubernetes deployments article for steps.
Netstat is installed on the community pod and can be helpful to understanding if the connectivity is succeeding or not succeeding.
To use netstat on the community pod enter the command:
netstat -an | grep 636 \nSubstitute your secure LDAP port number if you are not using port 636.
You might find that the default settings for LDAP are incompatible with your LDAP implementation and are causing problems
Parent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/t_troubleshooting_sametime_docker.html","title":"Troubleshooting Sametime on Docker","text":"Enabling Community trace in Docker
Viewing and saving log files Use the docker-compose logs command to view errors and events. You can view all containers or a specific container by specifying the container name.
Parent Topic: Troubleshooting
"},{"location":"admin/t_troubleshooting_sametime_kubernetes.html","title":"Troubleshooting Sametime on Kubernetes","text":"Enabling Community debug in Kubernetes
Viewing and saving log files Logs track pod events. You can gather a log for a specific pod and container within a pod or for all pods.
Transferring files from a pod to a Linux shell
Capturing a network trace in a pod
Applying changes
Troubleshooting LDAP on the community pod
Parent Topic: Troubleshooting
"},{"location":"admin/t_uninstall.html","title":"Uninstalling Sametime","text":"In the event that Sametime must be removed, follow the procedure for the platform that Sametime is installed on.
To uninstall Sametime on Docker, follow these steps.
Run the command to remove the images from the image repository.
For Docker,
docker rmi\nFor the full list of Docker commands, refer to Docker rmi in the Docker documentation for additional information.
For Podman,
$ podman rmi --all\nAttention: This command removes all images in the local storage, including the images that are not Sametime specific. For the full list of Podman commands, refer to Podman-rmi.
Find the installation directory and remove the extracted files from that folder. For more information, refer to Installing Sametime on Docker or Podman in the Podman documentation for additional information.
If you plan to re-install Sametime, refer to Installing Sametime in a Docker or Podman environment. To migrate or upgrade to a higher version, refer to Migrating and Upgrading.
Parent Topic: Uninstalling Sametime
"},{"location":"admin/t_uninstall_k8.html","title":"Uninstalling Sametime on Kubernetes","text":"To uninstall Sametime on Kubernetes, follow these steps.
Run the following commands.
# helm uninstall deployment name\n# kubectl delete job deployment name\n# kubectl delete clusterrolebinding deployment name\n# kubectl delete clusterrole deployment name\n# kubectl delete serviceaccount deployment name\nThe container images must be removed from the container registry manually. Each Kubernetes environment has different instructions. Consult your Kubernetes documentation for the complete steps.
Find the installation directory and remove the extracted files from that folder.
If you plan to re-install Sametime, refer to Installing Sametime in a Kubernetes environment. To migrate or upgrade to a higher version, refer to Migrating and Upgrading.
Parent Topic: Uninstalling Sametime
"},{"location":"admin/t_upgrade_telephony.html","title":"Upgrade considerations for telephony","text":"The prepareDeployment.sh script does not update the values.yaml file for telephony-related settings and does not update the settings from the existing secrets. For more information, refer to Preparing the deployment.
Configure the values.yaml file.
Compare the old values.yaml file and the new version of values.yaml file and port the settings over manually.
Locate these settings and change the value from false to true.
enableJigasi: true \nenableJigasiRestartOnTrunkFailure: true \ndialInEnabled: true \ndialInDisplayEnabled: true \nenableInviteOthers: false (set to true if dial-out is enabled) \nLocate these settings and configure to match the current environment. By default, these settings are blank.
defaultCountryCode: \"\" \nnumbers_json: {}\nIf necessary, add these settings to match the current environment.
jigasiSipServer: tmghost.example.com \njigasiSipPort: 5060 \njigasiSipTransport: TCP \njigasiProxyBypass: true \nConfigure the secrets for telephony. The secrets used by telephony are not carried over from the previous version of Sametime to the new version. This must be done manually.
Secret name: auth-config-secret
Template file name: helm/templates/auth-config-secrets.yaml
Copy the application-registry.json setting from the previous file to the new file.
Secret name: sametime-global-secrets (Sametime 12) or meeting-secrets (Sametime 11.6) Template file name: helm/templates/sametime-global-secrets.yaml
Copy the JigasiSipUri and JigasiSipPassword values from the previous file to the new file.
Secret name: catalog-config-secret Template file name: helm/templates/catalog-config-secrets.yaml
**Note:** If the TMG server is configured for a self-signed certificate for HTTPS, you might have the optional extra-certs configured. In this case, copy the extra-certs value from the old helm/templates/catalog-config-secrets.yaml file and paste into the new Sametime 12 helm/catalog-config-secrets.yaml file.\nApply the changes to the environment. See Applying configuration changes in Kubernetes or Openshift for the steps.
Parent Topic: Upgrading on Kubernetes
"},{"location":"admin/t_verify_tlsconnection.html","title":"Verifying if TLS connection can be established","text":"To verify if the TLS connection can be established, do the following.
Edit the custom.env file and locate the MONGO_URL parameters in the file.
Sametime configures the MongoDB details in a Mongo URL, for example:
mongodb://sametime\\_user:mongodb\\_password.mongodb\\_host:port\nwhere:
tlsAllowInvalidCertificates=true\nNote: Only use the option on systems where intrusion is not possible. This step bypasses the certificate check on the client side and is a viable option if both MongoDB and the Sametime components are all on the same host. Doing this step assumes that there would be no traffic on the network and there is no possibility of the mongo hostname being hijacked in DNS. For more information, refer to the official MongoDB documentation.
Save the changes.
Parent Topic: Setting up TLS for the Mongo database
"},{"location":"admin/tls_change_certificate.html","title":"Replacing the TLS certificates for Web Chat and Meetings","text":"The Sametime server is pre-configured with a self-signed certificate. You can replace the self-signed certificate with a third party certificate.
Updating the TLS certificates on Docker
Updating the TLS certificates on Kubernetes In Kubernetes, TLS certificates are contained within a secret called tls-secret.
Parent Topic: Securing
"},{"location":"admin/tls_change_certificate_docker.html","title":"Updating the TLS certificates on Docker","text":"Ensure that you have the certificate and private key to be used.
Run the following command to stop the Sametime services.
docker compose down\nCopy the two files to the /keys folder where the Sametime is deployed.
Replace the cert.key and cert.crt files with the new certificate files.
The files are located in the sametime-config/web/keys/ folder which is in the your installation directory.
Note: These changes are lost if you delete or remove the sametime-config directory.
Start the Sametime server to apply the changes.
docker compose up -d\nParent topic: Replacing the TLS certificates for Web Chat and Meetings
"},{"location":"admin/tls_change_certificate_kubernetes.html","title":"Updating the TLS certificates on Kubernetes","text":"In Kubernetes, TLS certificates are contained within a secret called tls-secret.
Ensure that you have the certificate and private key to be used.
To update the certificate on Kubernetes, first you must delete the existing secret and create it again with the new certificate information.
Run the following command to verify if the secret currently exists.
kubectl get secrets\nIf the tls-secret exists, delete it.
kubectl delete secret tls-secret\nCreate a new tls-secret secret with the new certificate and private key.
create secret tls tls-secret --key tls.key --cert tls.crt\nWhere the value for key is the private key file and cert is the certificate file.
Verify
kubectl get secret tls-secret -o yaml\nParent Topic: Replacing the TLS certificates for Web Chat and Meetings
"},{"location":"admin/topology.html","title":"Planning the network topology and connectivity","text":"This topic explains how Sametime components are connected and the default ports that are used. There are also example topologies to illustrate how Sametime can be deployed in different scenarios.
The following are components within the Sametime topology.
Clients are the interfaces used to connect with the Sametime server and product features. Each physical component communicates with the Sametime server using a specific port. See Sametime clients for more information on clients.
"},{"location":"admin/topology.html#section_i5j_rmt_v5b","title":"Directory services","text":"When choosing which LDAP directory to use, consider all the integrations with Sametime. It is important to understand how users authenticate with the server. Sametime can be integrated into many other HCL products, such as HCL iNotes, Verse, Connections, and Digital Experience. It is important to understand how users authenticate with the server and use a common LDAP directory.
Review the LDAP Planning section for additional information when choosing a directory.
"},{"location":"admin/topology.html#section_plw_cnt_v5b","title":"Single sign-on (SSO)","text":"Sametime requires Single Sign On and issues a JWT token to the users upon log in. All users are authenticated against the Community service, where tokens are generated to be shared with the other microservices.
As an optional configuration, Sametime supports LTPA Single Sign On as well as Security Assertion Markup Language (SAML). With LTPA SSO, the user is issued an LTPA token, which can be shared with other services that support LTPA authentication, such as HCL Domino, Verse, and Connections.
With SAML, the initial authentication is done by an Identity Provider which validates the user\u2019s identity with the Community service. The user is then provided a JWT token that is good for the duration of their session. For more information, see Enabling Single Sign-on.
Planning considerations for chat
Considerations for Sametime Premium Sametime Premium deployments are supported on Docker or Kubernetes.
Parent Topic: Planning
"},{"location":"admin/topology_chat.html","title":"Planning considerations for chat","text":"See Ports used by Sametime services for more details on which ports are required to be open on firewalls.
"},{"location":"admin/topology_chat.html#section_olj_3nt_v5b","title":"Small internal chat-only deployments","text":"For small internal deployments, a single Docker system can be deployed to support web chat, mobile chat, and chat users with desktop clients (such as the Sametime Connect and Embedded Sametime client in HCL Notes).
An example of a small deployment includes a single Docker deployment of Sametime, MongoDB Server, and the LDAP directory.
Figure 1 shows an example of a small internal deployment that only includes chat.
In the above example, \u201cdesktop clients\u201d are the Sametime Connect client and Sametime Embedded client (inside HCL Notes) for desktops. Browser clients can include other HCL applications such as HCL Verse, HCL iNotes, and HCL Connections, which have chat and presence integration with Sametime.
You can use the mobile client app on your internal Wi-Fi network if devices are able to connect to Sametime on port 443. Mobile apps can be used internally; however, be aware that the mobile clients still need access to the Apple (APNS) and Google (FCM) servers for push notifications (notifying the user of new messages). As an additional option, Sametime supports proxying the notifications if you have a third-party proxy to do so.
"},{"location":"admin/topology_chat.html#section_dzj_jqt_v5b","title":"Small chat-only environments with internet access","text":"Figure 2 shows a small chat-only environment that includes internet access to Sametime.
In this example, you can open port 443 on the firewall to support mobile clients on the internet. You can open TCP port 1533 to support desktop clients. Instead of placing Sametime in the internal zone, you can also place Sametime in a DMZ or on the external zone.
Parent Topic: Planning the network topology and connectivity
"},{"location":"admin/topology_premium.html","title":"Considerations for Sametime Premium","text":"Sametime Premium deployments are supported on Docker or Kubernetes.
If you are unfamiliar with these technologies, refer to Platforms. To learn more about Kubernetes, see An Overview of Kubernetes.
Media audio and video streams over UDP port 10,000 for Docker or UDP 30,000 for Kubernetes. Sametime requires a STUN server if any user is attending from behind a firewall. The default configuration comes with the public Google STUN server configured using UDP Port 19302 configured; however, any STUN server can be used. Both clients and the Sametime services need connectivity to the STUN service. For more information, see Session Traversal Utilities for NAT (STUN). The following examples show several scenarios on how to deploy Sametime to include external users.
"},{"location":"admin/topology_premium.html#section_lb3_tsv_v5b","title":"Small Sametime Premium deployment on Docker","text":"If your environment includes a DMZ, you can place Sametime in the DMZ and open the required ports.
In this example, clients can connect to Sametime from both inside the internal network as well as from the Internet. Browser clients and Mobile clients connect to Sametime using HTTPS port 443, and UDP port 10,000. These clients also connect directly to STUN on the Internet (or internally if installed as an optional configuration) on port 19302 UDP. Mobile clients must connect to the push notification services on the Internet in order to receive chat notifications in the client. Sametime desktop clients (those that are installed rich clients\u2014Sametime Connect and Sametime embedded) are connecting on port 1533 TCP.
The following graphic shows a small HCL Sametime Premium with internet access using Docker.
"},{"location":"admin/topology_premium.html#section_ftl_zsv_v5b","title":"Larger Sametime Premium deployments","text":"If you have a medium- or large-size user base, you can deploy Sametime with Kubernetes. Kubernetes can be installed as an on-premise configuration or by leveraging a third party Kubernetes service such as Google Kubernetes Engine (GKE) or Amazon\u2019s Elastic Kubernetes Service (EKS), among others.
When you deploy Sametime in Kubernetes, the Kubernetes cluster requires three node pools. Each node pool performs a different function. One node pool is dedicated to video, a second one for recorders, and a main node pool for all other Sametime pods. The number of nodes in each node pool determines the capacity of the environment. An ingress controller is used to handle front-end connections from users to the web chat and meeting https services. Media streams are over UDP port 30,000 and connect directly to the video node pool. Sametime desktop clients connect to a Sametime Mux Kubernetes service (svc) on port 1533 (TCP).
The following graphic shows Kubernetes node pools and ingress.
Connectivity for end users is very similar to the Docker deployment. The difference is UDP port 30,000 is used for media streams instead of port 10,000. There may be multiple nodes in the video node pool, and clients must be able to reach each one on port 30,000.
The following graphic shows an overview of connectivity in a Kubernetes deployment.
For a fully containerized environment, it is possible to also run MongoDB as a Kubernetes cluster, which may require additional licensing from MongoDB. LDAP can also run as a container, and Sametime supports LDAP v3 compliant directories. Domino LDAP can also run in Kubernetes.
The following graphic shows a fully containerized Sametime Premium Deployment.
Parent Topic: Planning the network topology and connectivity
"},{"location":"admin/topology_telephony.html","title":"Considerations for telephony","text":"Integration with the Teamcall Meeting Gateway (TMG) application from ilink enables telephony services to be added to your Sametime environment. The telephony feature allows telephone access to chats and meetings.
TMG provides two types of end-user experiences:
Dial in : Phone numbers are assigned to the Sametime Meeting service, and each telephony-enabled meeting has a unique pass code. This allows users to use their phones to dial into a meeting.
Dial out : Dial out allows users to dial a phone number from the meeting and invite another user to join that meeting.
The ilink TMG can leverage your existing on-premise SIP trunk, or a SIP provider or carrier service from a third party. With this configuration, the SIP and RTP protocols are used between:
For more details on the ilink product, see the ilink website.
The following graphic shows a network environment with ilink integration.
Parent Topic: Planning the network topology and connectivity
"},{"location":"admin/topology_turn.html","title":"Determining where to install Sametime","text":"You can extend access to Sametime outside of your internal network to attendees on the Internet. Sametime can be installed in the demilitarized network zone (DMZ); however, the required ports for connectivity need to be opened on the firewalls surrounding the DMZ. You can also use a third-party Kubernetes cloud provider such as Amazon EKS, Google GKE, or another third-party Kubernetes provider to deploy Sametime. For more information, see the Deploying Sametime 12 on Google Kubernetes Engine guide.
For example, Sametime can be installed in a demilitarized network zone (DMZ) or internal zone, which requires ports open to the network.
If there are users or attendees who might have a restrictive network environment, consider implementing a TURN service.
TURN (Traversal Using Relays over NAT) is a protocol that relays network traffic. It is an optional service that you can deploy with Sametime to improve the end user experience when attendees and users of Sametime Meetings do not have connectivity to UDP port 30,000. If the user has access to ports 10,000\u201320,000 UDP, then TURN can relay the traffic over this range instead. The user connects to the TURN server instead of Sametime directly. If the user is in a very restrictive environment and has no UDP ports available to use, then the TURN server can be used to relay traffic over TCP port 443. It is important to note that although port 443 is used for this purpose, it is not considered HTTP traffic; it is audio and video data.
Sametime does not ship with a TURN server, but a third-party server can be used, such as CoTURN. CoTURN is the TURN server that has been tested with Sametime.
For more details on TURN, see Setting up a TURN server.
Parent Topic: Network planning for meetings
"},{"location":"admin/troubleshooting.html","title":"Troubleshooting","text":"This section provides information on troubleshooting and supporting Sametime environments. Use this section to assist you with problems that you might experience and contacting support if needed.
Getting help There are several resources available to troubleshoot and resolve a problem that you can use before contacting support. If you need to contact support, a support guide describes expectations.
Working with HCL support HCL support is available to provide technical assistance with obtaining a solution to problems with Sametime.
Troubleshooting Sametime on Docker
Troubleshooting Sametime on Kubernetes
Troubleshooting Sametime clients Use this information on troubleshooting and logging tools to diagnose and resolve problems affecting the HCL Sametime clients.
HCL support is available to provide technical assistance with obtaining a solution to problems with Sametime.
To request technical assistance, open a support case with HCL to work with a support engineer in resolving the problem. See How to open HCL Support case knowledge article for details.
When working with the support engineer the following information is helpful in understanding the problem. Having the following information before talking with the support engineer saves time and reduces multiple calls.
You might be asked to share files with HCL support, see the HTTPS and SFTP upload and download instructions knowledge article for details.
Parent Topic: Troubleshooting
"},{"location":"admin/troubleshooting_debug_trace_docker.html","title":"Enabling Community trace in Docker","text":"The Community and STProxy traces can be used to troubleshoot problems with the Sametime. The traces capture the flow between the chat and meeting services.
To enable the trace modify the docker-compose.yml file. In the community: section, locate the env_file: statement.
community: \n image: hclcr.io/st/chat-server:${BUILD_LEVEL} \n restart: ${RESTART_POLICY} \n env_file: \n -custom.env \n -debug.env\n environment:\nAdd, the debug.env parameter to the statement as shown in the following example.
community: \n image: hclcr.io/st/chat-server:${BUILD_LEVEL} \n restart: ${RESTART_POLICY} \n env_file: - custom.env - debug.env\n environment:\nParent Topic: Troubleshooting Sametime on Docker
"},{"location":"admin/troubleshooting_docker_logs.html","title":"Viewing and saving log files","text":"Use the docker compose logs command to view errors and events. You can view all containers or a specific container by specifying the container name.
To view logs for all components, issue the following command:
docker compose logs\nTo view individual components, add the component name to the command. For example to view community logs:
docker compose logs community\nTo save logs to a file, use the > character followed by the path and file name for the saved file.
docker compose logs > /tmp/all_logs.txt\nParent topic: Troubleshooting Sametime on Docker
"},{"location":"admin/troubleshooting_kubernetes_logs.html","title":"Viewing and saving log files","text":"Logs track pod events. You can gather a log for a specific pod and container within a pod or for all pods.
Each Kubernetes pod and container performs a specific task, narrowing down which pod to gather a log allows you to focus on the problem being debugged. Review the Pods in Sametime topic to understand what each pod does.
Some pods have multiple containers and you can specify gathering the log for the specific container. For pods that only have one container, you do not need to specify the container name.
Run the kubectl get pods command to obtain the name of the pod. The command output includes all current pod names.
Note: Pod name have hashes in it that change each time a pod is started.
The following example shows the output from a kubectl get pods command.
NAME READY STATUS RESTARTS AGE\nactivity-5b75df6f6b-z98xs 1/1 Running 0 25d\napp-registry-7766fddd94-qbvsk 1/1 Running 0 25d\nauth-c6d8457cb-9j9z7 1/1 Running 0 24d\nbackgrounds-cb8966646-wtvqs 1/1 Running 0 25d\ncatalog-ff66944d5-vvfkx 1/1 Running 0 10d\nclick2call-86f8f4cbbb-wptch 1/1 Running 0 25d\ncommunity-775fc897c9-mmb84 2/2 Running 0 25d\nfiles-5b5865f8fc-h8hl5 2/2 Running 2 (9d ago) 25d\njibri-web-65b6849f67-9xxq9 1/1 Running 0 25d\njitsi-6c4754ffcf-n6t72 3/3 Running 0 25d\nlobby-b569fcdd5-5fkmf 1/1 Running 0 25d\nlocation-5894bcb6f7-kbkrb 1/1 Running 0 25d\nmux-f68c5868d-8vl6j 1/1 Running 0 25d\noutlook-7d7f54ff65-7cmzx 1/1 Running 2 (25d ago) 25d\nproxy-6d669b9b94-xmhvt 1/1 Running 0 25d\nrecorder-7c9dcfc646-2g66f 2/2 Running 9 (22m ago) 32h\nrecordings-7cdd5c8cf4-lg2hn 1/1 Running 0 25d\nvideo-7c477fbd86-2jn62 2/2 Running 0 25d\nweb-6d785f6479-tfmkb 1/1 Running 5 (14d ago) 25d\nwebhook-7cb587cd74-5t96w 1/1 Running 0 10d\nTo view the log for a specific pod, run the kubectl logs command specifying the name of the pod to gather log information. If there is a specific container to gather the log, include both the pod name and container name on the command.
kubectl logs pod\\_name container\\_name \nFor example, if you want to view the jvb logs from the video pod based on the output in the previous step enter the command:
kubectl logs video-7c477fbd86-2jn62 jvb \nYou can also use the --all-containers argument to see logs from all the containers on the pod.
kubectl logs video-58f8589f99-f4tcd --all-containers \nTo redirect the output to a file, add the greater than character (>) as an argument on the command and specifying a location that you have access to put the file. For example:
kubectl logs video-7c477fbd86-2jn62 --all-containers > /tmp/video.txt \nParent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/troubleshooting_kubernetes_pod_networktrace.html","title":"Capturing a network trace in a pod","text":"Get the name of the pod.
kubectl get pods \nStart a shell session in the pod. Issue the below command, and make the following substitutions:
kubectl exec -it <podname> --container=<container name> -- bash \npodname : The name of the pod.
container_name : is the name of the container. If the pod only has one container you can omit this parameter.
For example, if the pod name is jitsi-74d95d6d49-k5nts and the container name is jigasi, then the resulting command is:
kubectl exec -it jitsi-74d95d6d49-k5nts --container=jigasi --bash\nUpdate the repositories by issuing the below command:
apt-get update \nInstall tcpdump by issuing the below command:
apt-get install tcpdump \nCapture the network data, by issuing the command:
tcpdump -i any -w <filename>.pcap \nReproduce the problem.
To stop and save the capture press Ctrl+C.
Parent Topic: Troubleshooting Sametime on Kubernetes
Transferring files from a pod to a Linux shell
Pods in Sametime
"},{"location":"admin/troubleshooting_kubernetes_transfer_pods.html","title":"Transferring files from a pod to a Linux shell","text":"Obtain the name of the pod.
Pod names have hashes in it that change each time a pod is started. To get the name of the current pods, issue the command:
kubectl get pods \nTo copy a file from the pod, use the syntax below, and make the following substitutions:
kubectl cp <podname>:/<filename> /<path_on_local>/<filename> --container=<container_name> \npodname : The name of the pod.
filename : The file name inside the pod.
path_on_local : The path on the machine running kubectl.
container_name : The name of the container. If the pod only has one container you can omit this parameter. See Pods in Sametime for container names.
For example if:
kubectl cp jitsi-7b86fc4f64-vtrrb:/test1.pcap /tmp/test1.pcap --container=jigasi\nParent Topic: Troubleshooting Sametime on Kubernetes
"},{"location":"admin/turnserver_centos.html","title":"Installing a TURN Server","text":"You can install and configure a TURN server to use with Sametime Meetings.
The following procedures uses Coturn and CentOS 7 to implement a TURN server.
Install the CentOS prerequisites.
sudo yum install -y make gcc cc gcc-c++ wget openssl-devel libevent libevent-devel\nDownload the Coturn source package that can be compiled from the Downloads repository. Ensure it is the latest version.
The following example is downloading v4.5.2.
mkdir /root/turn\ncd /root/turn\nwget https://coturn.net/turnserver/v4.5.2/turnserver-4.5.2.tar.gz\nCompile and install.
./configure --prefix=/usr/local/turnserver # Specify the installation directory\nmake\nsudo make install\nSet the environment variables.
vim ~/.bashrc\nAdd the following statements.
export turnserver_home=/usr/local/turnserver\nexport PATH=$PATH:$turnserver_home/bin\nConfigure the TURN server.
Create the turnserver.conf file.
vim /etc/turnserver.conf\nAdd the following content to define the Coturn server. Replace the option values with the appropriate values for your environment.
# Listener IP address of relay server. Multiple listeners can be specified.\n# If no IP(s) specified in the config file or in the command line options,\n# then all IPv4 and IPv6 system IPs will be used for listening.\nlistening-ip=0.0.0.0\n\n# External IP-Address of the TURN server\nexternal-ip=IP_ADDRESS\n\n# TURN listener port for UDP and TCP (Default: 3478).\nlistening-port=3478\n\n# 443 for TURN over TLS, which can bypass firewalls\ntls-listening-port=443\n\n# host domain name.\nrealm=mycompany.org\n\n# Path to the SSL certificate and private key.\n# Certificate file.\ncert=/usr/local/etc/turn_server_cert.pem\n\n# Private key file.\npkey=/usr/local/etc/turn_server_pkey.pem\n\n# Lower and upper bounds of the UDP relay endpoints:\n# Further ports that are open for communication\nmin-port=10000\nmax-port=20000\n\n# This allows TURN credentials to be accounted for a specific user id.\n# If you don't have a suitable id, the timestamp alone can be used.\n# This option is just turning on secret-based authentication.\n# The actual value of the secret is defined by option static-auth-secret,\nuse-auth-secret\n\nstatic-auth-secret=<YOUR_SECRET>\n\n# Option to set the log file name.\n# By default, the turnserver tries to open a log file in\n# /var/log, /var/tmp, /tmp and current directories directories\nlog-file=/var/log/turnserver.log\n\n# Enable verbose logging\nverbose\n\n# Do not allow an TLS/DTLS version of protocol\nno-tlsv1\nno-tlsv1_1\nno-tlsv1_2\nYou can make additional customizations to the file. For additional information, see the turnserver.conf file. Within the file, configuration options are described as comments.
Start the service.
turnserver -v -r extranet-ip:port -a -o -c /etc/turnserver.conf\nParent Topic: Setting up a TURN server
"},{"location":"admin/turnserver_intro.html","title":"Setting up a TURN server","text":"A TURN server can be configured to provide for efficient traffic flow within your Sametime meeting.
You need to install a TURN server and configure it for use with the Sametime Meeting server. There are several options for a TURN server. One option is the Coturn, which is an open source TURN server. The following two methods can be used to install the Coturn TURN server:
After the TURN is installed, follow the configuration method appropriate for your environment:
Configuring the TURN server for Kubernetes
Installing a TURN Server on Ubuntu You can install and configure a TURN server to use with Sametime Meeting on an Ubuntu operating system.
Parent Topic: Meetings
"},{"location":"admin/turnserver_meetings_docker.html","title":"Configuring the TURN server for Docker and Podman","text":"You can configure the Sametime Meeting service to enable a TURN server on port 443 for Docker.
The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Update the following configuration in the custom.env file.
# Enable TURN for JVB (bridge mode) connections\nTURN_ENABLE=1\n\n# Secret for connect to TURN server\n# Add the same secret that you used to configure TURN server.\nTURN_SECRET=secret\n\n# Announce FQDN/IP address of the turn server via XMPP server (XEP-0215).\n# If empty or not set, variable DOCKER_HOST_ADDRESS will be used by default.\nTURN_HOST=turn.example.com\n\n# TLS/TCP/UDP turn port for connection\nTURN_PORT=443\n\n# Transport for stun/turn connection. Can be tcp or udp.\nTURN_TRANSPORT=tcp\nAdd the following configuration to the custom.env file.
TURN_CREDENTIALS=secret\nUpdate the following configuration in the .env file.
GLOBAL_MODULES=turncredentials\nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Setting up a TURN server
"},{"location":"admin/turnserver_meetings_kubernetes.html","title":"Configuring the TURN server for Kubernetes","text":"You can configure the Sametime server to enable a TURN server on port 443 for Kubernetes.
Note: Running the script to prepare deployment prompts for TURN server configuration. The following process is to enable TURN post deployment. For more information, refer to Preparing the deployment.
Update the values.yaml file with the following values. Ensure that the syntax for the YAML file is followed.
turnEnable: true\nglobalModules: turncredentials\nturnHost:<turn host name>\nturnPort: 443\nturnTransport: tcp\njvbTcpHarvesterDisabled: true\nUpdate the helm/templates/sametime-secrets.yaml file.
Locate the TurnSecret variable and set the value to the base64 encoded secret as set in the TURN configuration.
TurnSecret: <base64encoded secret as set in TURN configuration>\nNote: If you need to generate a base64 encoded secret, use the following command. Use the unencoded value provided in your TURN configuration.
/bin/echo -n $(openssl rand -hex 32) | base64\nRun the helm update command to enable the configuration changes.
Parent Topic: Setting up a TURN server
"},{"location":"admin/turnserver_ubuntu.html","title":"Installing a TURN Server on Ubuntu","text":"You can install and configure a TURN server to use with Sametime Meeting on an Ubuntu operating system.
You need the following:
The following procedures uses Coturn open source implementation of a TURN server. The procedure includes installing and configuring the Conturn server.
Install Coturn on the Ubuntu operating system.
sudo apt-get -y update\nsudo apt-get -y install coturn\nTo start the Coturn Daemon at Startup, modify the /etc/default/coturn file.
sudo vim /etc/default/coturn\nRemove the comment character (#) from the beginning of the following line.
TURNSERVER_ENABLED=1\nConfige the Coturn server.
Make a copy of your original configuration before making any changes.
This original configuration copy can be used if a problem occurs.
Create an empty file in the same directory to contain your configuration.
sudo vim /etc/turnserver.conf\nAdd the following content to define the Coturn server and replace the values with appropriate values for your configuration.
# Listener IP address of relay server. Multiple listeners can be specified.\n# If no IP(s) specified in the config file or in the command line options,\n# then all IPv4 and IPv6 system IPs will be used for listening.\nlistening-ip=0.0.0.0\n\n# External IP-Address of the TURN server\nexternal-ip=IP_ADDRESS\n\n# TURN listener port for UDP and TCP (Default: 3478).\nlistening-port=3478\n\n# 443 for TURN over TLS, which can bypass firewalls\ntls-listening-port=443\n\n# host domain name.\nrealm=mycompany.org\n\n# Path to the SSL certificate and private key.\n# Certificate file.\ncert=/usr/local/etc/turn_server_cert.pem\n\n# Private key file.\npkey=/usr/local/etc/turn_server_pkey.pem\n\n# Lower and upper bounds of the UDP relay endpoints:\n# Further ports that are open for communication\nmin-port=10000\nmax-port=20000\n\n# This allows TURN credentials to be accounted for a specific user id.\n# If you don't have a suitable id, the timestamp alone can be used.\n# This option is just turning on secret-based authentication.\n# The actual value of the secret is defined by option static-auth-secret,\nuse-auth-secret\n\nstatic-auth-secret=<YOUR_SECRET>\n\n# Option to set the log file name.\n# By default, the turnserver tries to open a log file in\n# /var/log, /var/tmp, /tmp and current directories directories\nlog-file=/var/log/turnserver.log\n\n# Enable verbose logging\nverbose\n\n# Do not allow an TLS/DTLS version of protocol\nno-tlsv1\nno-tlsv1_1\nno-tlsv1_2\nYou can make additional customizations to the file. For additional information, see the turnserver.conf file. Within the file, configuration options are described as comments.
Save the file and restart the Coturn server to apply the changes.
Parent Topic: Setting up a TURN server
"},{"location":"admin/update_ttl_index.html","title":"Updating the time-to-live index for persistent chat","text":"The time-to-live (TTL) setting defines how long the chat history is stored in the database. The default value is 90 days. However, administrators can update the value based on the organization's preferred setting.
The TTL index in MongoDB must be rebuilt. For more information, refer to Manage Indexes in the MongoDB documentation.
To update the TTL settings used by the Sametime server involves modifying the following files.
Note: These values are case sensitive and must be entered as shown below.
Modify the configuration file. The minimum value is 1.
For Docker, update the CLI__ChatLogging__CL_MONGO_HISTORY_TTL parameter. In the following example, the value is set to 7 days.
CLI__ChatLogging__CL_MONGO_HISTORY_TTL=7\nFor Kubernetes, update the CLI__ChatLogging__CL_MONGO_HISTORY_TTL parameter. In the following example, the value is set to 7 days.
CLI__ChatLogging__CL_MONGO_HISTORY_TTL: 7\nModify the Convomap Max Days configuration value to match the MongoDB TTL value. The minimum value is 1.
For Docker, update the STI__stconvomap__CONVOMAP_MAX_DAYS parameter. In the following example, the value is set to 7 days.
STI__stconvomap__CONVOMAP_MAX_DAYS=7\nFor Kubernetes, update the STI__stconvomap__CONVOMAP_MAX_DAYS parameters. In the following example, the value is set to 7 days.
STI__stconvomap__CONVOMAP_MAX_DAYS: 7\nYou can update the STI__stconvomap__CONVOMAP_MAX_HOURS parameter to add hours to the time frame. In the following examples, the value is set to 2 hours.
Docker:
STI__stconvomap__CONVOMAP_MAX_HOURS=2\nKubernetes:
STI__stconvomap__CONVOMAP_MAX_HOURS: 2\nIn the Mongo shell, run the following commands.
use chatlogging\ndb.EVENTS.getIndexes()\ndb.EVENTS.dropIndex(\"TimeStamp_1\")\ndb.USERS.dropIndex(\"date_1\")\nThe db.EVENTS.dropIndex command defines the name of the index to drop. The value is TimeStamp_1.
Restart the Sametime server to apply the changes. The TTL index is updated with the new value.
For more information, refer to Starting and stopping servers.
Run the following command to confirm that the value for TimeStamp_1 is updated.
db.EVENTS.getIndexes()\nParent Topic: Configuring
"},{"location":"admin/upgrade_install_fixpack.html","title":"Upgrading to a new version or applying a fixpack","text":"Newer versions and fix packs contain new features and fixes. You do not need to remove your current Sametime 12 installation when upgrading to a new version.
To install a new version or fix pack, the following conditions must be satisfied:
Sametime server has access to a MongoDB server
Upgrading on Docker
Upgrading on Kubernetes The Sametime upgrade packages contain full helm charts.
Parent Topic: Migrating and Upgrading
"},{"location":"admin/upgrade_install_fixpack_docker.html","title":"Upgrading on Docker","text":"To install a new version or fix pack, the following conditions must be satisfied:
Creating a backup of the installation directory, allows you to return to your previous version if a problem occurs related to installing the fix pack.
Note:
The docker-compose.yml file is replaced during the upgrade with a newer version. Do not restore this file from a previous version after the upgrade. Any needed modifications need to be implemented again in the new file version.
In the directory where Sametime is installed, issue the following command to stop the Sametime server.
docker compose down \nMake a copy of the Sametime installation directory as a backup before installing the fix pack.
Copy the contents of the installation directory into another directory. For example, /sametime_install_backup where sametime_install is the Sametime installation directory.
Download and decompress the Sametime fix pack archive to the Sametime installation directory.
unzip sametime\\_fixpack\\_zip -d /sametime\\_install\\_path \nIn the sametime_install directory, run the following script to initiate the installation process.
./install.sh\nFollow the prompts to provide the required information. The install process detects if the install is an upgrade or full install.
Parent topic: Upgrading to a new version or applying a fixpack
"},{"location":"admin/upgrade_install_fixpack_kubernetes.html","title":"Upgrading on Kubernetes","text":"The Sametime upgrade packages contain full helm charts.
When upgrading, the recorder workloads are assigned to the main worker nodes. Ensure that the existing main worker nodes have enough capacity to handle the workloads.
Because the upgrade package includes full helm charts to implemented, you must port your settings from the current values.yaml into the new values.yaml file. Do not restore the values.yaml file from a backup file which might contain deprecated settings.
Download and extract the Sametime fix pack zip files into a directory on either the master Kubernetes host or on a machine which has management access to the Kubernetes cluster.
Run the following command to load the fix pack Docker image to the Docker repository.
./load.sh\nIf your image repository requires a secret, define in the secret name on the hclImagePullSecret setting in the values.yaml file.
Edit the values.yaml file as needed.
Run the following script to update the current configuration to values.yaml file as needed. You are prompted for any missing information.
./prepareDeployment.sh\nWhen prompted to confirm the upgrade, answer Y to proceed with the current settings. If your response is No, you are prompted for necessary information.
If the community LDAP settings are overridden in your deployment using an extra-community-config secret, there are changes to these files that need to be included as a part of the upgrade.
Delete the secret by running the following command:
kubectl delete secret extra-community-config\nComment out the following line in the values.yaml file using the comment (#) character.
# overrideCommunityConfigSecret: extra-community-config\nWhen the upgrade is finished, pull new copies of StCommunityConfig.xml and UserInfoConfig.xml files. Modify the files to include your custom settings. Create the extra-community-config secret again with your changes.
If you have enabled telephony, copy the secrets from the old helm charts to the new ones.
Copy the existing setting application-registry.json from /helm/templates/auth-config-secrets.yaml into your new /helm/templates/auth-config-secrets.yaml file.
Copy the existing JigasiSipUri and JigasiSipPassword settings from the/helm/templates/sametime-secrets.yaml file to the new /helm/templates/sametime-secrets.yaml file.
Apply your changes to the environment.
Verify that you are in the helm directory and run the following command to apply changes. Specify the Sametime deployment name for your environment. The default for Sametime Premium version 12 is sametime.
helm upgrade sametime\\_deployment\\_name .\nNote: Be sure to include the dot at the end. It is part of the command.
If you are unsure of your deployment name, issue the helm list command to find the name. If you upgraded from an earlier Sametime release, the default name is sametime-meetings.
Upgrade considerations for telephony
The prepareDeployment.sh script does not update the values.yaml file for telephony-related settings and does not update the settings from the existing secrets. For more information, refer to Preparing the deployment.
Parent topic: Upgrading to a new version or applying a fixpack
"},{"location":"admin/upgrade_revert_kubernetes.html","title":"Reverting to a previous version on Kubernetes","text":"If you encounter a problem, you can return to the previous Sametime version. Helm commands to return to a previous release on Kubernetes. To roll back to the previous version, run the helm rollback command. For more information about the command, see the Helm Rollback topic in the Helm documentation. If you don't know the previous release number, you can use the helm history command. For additional information on how to identify the prior release number, see the Helm History topic in the Helm documentation.
Parent Topic: Upgrading to a new version or applying a fixpack
"},{"location":"admin/use_stimages_harbor.html","title":"Using Sametime images from the HCL Harbor registry","text":"Sign in to the HCL Harbor registry using the same credentials that you use for the HCL Software License & Download Portal. You are granted access through HCL's identity provider, Okta.
Obtain the access token you need for command line authentication with Harbor by clicking your account profile picture. The CLI secret that is displayed is the access token.
If you already have Docker installed, you can use your Docker login to create the necessary secret to give your Kubernetes environment access to the HCL Harbor Registry.
Run the command:
docker login hclcr.io -u your\\_email\\_address\nUse the access token you obtain in Step 2 when prompted for password. Make sure the case of your_email_address matches what is in the Harbor Registry user profile.
Create a secret that references your Docker config
kubectl create secret generic hcl-harbor-registry-secret \\\n --from-file=.dockerconfigjson=<path/to/.docker/config.json> \\\n --type=kubernetes.io/dockerconfigjson\nNote: If you are not using Docker, run the following command.
kubectl create secret docker-registry hcl-harbor-registry-secret --docker-server=hclcr.io '--docker-username=your\\_email\\_address\\>' '--docker-password=your\\_access\\_token'\nThe quote that surrounds the Docker user name and password parameters are needed. This is because the @ and possible special characters in a password might have special meaning in the command interpreter.
Edit the values.yaml file and include the following setting.
hclImagePullSecret: 'hcl-harbor-registry-secret'\nThis topic describes how to replace the self-signed certificate with a third-party certificate.
The Sametime server is preconfigured with a self-signed certificate.
Note: Let's Encrypt certificates expire every 90 days. To automatically renew the certificates, users can use Certbot. Otherwise, users can renew certificates when they expire. For details on setting up automatic renewal, refer to the Certbot documentation.
Parent Topic: Securing
"},{"location":"admin/using_meeting_servers.html#using_meeting_server_kubernetes","title":"Kubernetes","text":"Obtain one or more certificates and private key. Afterward, run the following commands to configure the Ingress to use them.
Run the following command to verify if the secret currently exists.
kubectl get secrets\nIf the tls-secret exists, delete it.
kubectl delete secret tls-secret\nCreate a new tls-secret secret with the new certificate and private key.
create secret tls tls-secret --key tls.key --cert tls.crt\nWhere the value for key is the private key file and cert is the certificate file.
Verify
kubectl get secret tls-secret -o yaml\nGenerate a Let's Encrypt certificate. Afterward, apply the encryption certificate on the Sametime server.
Set ENABLE_LETSENCRYPT to 1 in the docker-compose.yml file.
Retrieve the PEM files provided by Let's Encrypt and locate the following files
sametime-config/web/acme-certs/\nNote: If a value for the LETSENCRYPT_DOMAIN is specified, then the path is sametime-config/web/acme-certs/<LETSENCRYPT_DOMAIN>/.
Restart the server to apply the changes.
docker-compose down\ndocker-compose up -d\nIntegration with an application such as Verse prior to Sametime 12.0 requires the legacy web-client interface. Beginning in Sametime 12.0 the legacy web-client is not enabled by default, but can enabled when needed for integration with other products.
Enabling web client integration on Docker and Podman
Enabling web client integration on Kubernetes
Enabling content security headers on Docker and Podman
Enabling content security headers on Kubernetes
Parent Topic: Configuring
"},{"location":"admin/verse_integration_contentsecurity_docker.html","title":"Enabling content security headers on Docker and Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Edit the custom.env file.
Add the following parameter to the file, where company_domain is the domain name.
CONTENT_SECURITY_POLICY=frame-ancestors https://*.company\\_domain.com\nTo apply the changes, stop the Sametime server and start it again.
To stop the Sametime server, run the following script from the Sametime installation directory.
docker-compose down \nStart the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Integrating with other applications
"},{"location":"admin/verse_integration_contentsecurity_kubernetes.html","title":"Enabling content security headers on Kubernetes","text":"The changes in this task affect the following pods:
web
Edit the values.yaml file.
Add the following parameter to the file, where company_domain is the domain name.
contentSecurityPolicy: frame-ancestors\u00a0https://*.company\\_domain\nApply the changes to the configuration.
Run the helm upgrade command from the helm directory where the Sametime installation package was unzipped.
Specify the Sametime deployment name.
helm upgrade sametime\\_deployment\\_name .\nNote: The dot is part of the command.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Integrating with other applications
"},{"location":"admin/verse_integration_docker.html","title":"Enabling web client integration on Docker and Podman","text":"The Docker and Podman commands are similar. The only difference is that docker precedes the command when issued in a Docker environment and podman precedes the name in a Podman environment. Example commands used in the Sametime documentation are shown using Docker. For Podman, change docker to podman.
Edit the docker-compose.yml file.
Locate the SAMETIME_EXTERNAL_WARINTEGRATION variable and ensure that it is set to true.
If the statement doesn't exist, add it in the proxy section of the file.
SAMETIME_EXTERNAL_WARINTEGRATION=true\nTo apply the changes, stop the Sametime server and start it again.
To stop the Sametime server, run the following script from the Sametime installation directory.
docker-compose down \nTo apply the changes stop the Sametime server and start it again.
Start the Sametime server to apply the changes.
docker compose up -d\nParent Topic: Integrating with other applications
"},{"location":"admin/verse_integration_kubernetes.html","title":"Enabling web client integration on Kubernetes","text":"The changes in this task affect the following pods:
proxy
Edit the values.yaml file.
Add the enableLegacyChatClient key with the value set to true.
enableLegacyChatClient: true\nApply the changes to the configuration.
Run the helm upgrade command from the helm directory where the Sametime installation package was unzipped.
Specify the Sametime deployment name.
helm upgrade sametime\\_deployment\\_name .\nNote: The dot is part of the command.
Restart the pods with the changes. Use the kubectl scale command to scale the pods to zero and then to one that have been changed. You must run the commands for each pod that the change affects.
Run the following command to scale the pod to zero.
Scale the pod to zero, where pod_deployment_name is the pod name.
kubectl scale deploy pod\\_deployment\\_name --replicas=0\nRun the following command to scale the pod to one.
kubectl scale deploy pod\\_deployment\\_name --replicas=1\nParent Topic: Integrating with other applications
"},{"location":"admin/whats_new.html","title":"What's new","text":"HCL Sametime and HCL Sametime Premium 12.0.2 provide many new features, enhancements and fixes to servers and clients. Additional releases to version 12.0.2 also provides updates to the product.
For information on these new features and enhancement, see the following article:
For a listing of fixes provided in 12.0.2, refer to the following article: