Sametime Community configure HTTP tunneling + push settings

Per default Sametime will listen on port 1533. As some network infrastructures will
not allow outgoing connections on this port, as an alternative you can specify to
use the HTTP port 80. This technique is called HTTP tunneling.

To configure your Domino/Sametime Community setup for this you can
follow the steps in the Blog item.

With your Notes client open the names.nsf on your Sametime Community server. Navigate to Configuration -> Servers -> “All server documents” and double click on the entry of the Sametime Community server

Within this document go to Ports ->Internet Ports -> Web.

ports 1


ports 2








Change the TPC/IP port number to something different then port 80. We will
go with port 8080.

Save the changes and restart the http task.

In the Domino console use the following commands to do this.

tell http quit

load http

Change the connection for the Sametime Community server in the SSC. Per default the SSC will make contact to the Sametime server through the Domino HTTP port.

As this changes you will need to change this connection setting in the SSC.

Navigate to the Community server.





Click edit “Connection Properties”


Change the HTTP port to the value you now configured as the HTTP port for Domino.
In our situation this is port 8080. Press Save.





Now click on the “Deployment Identifier” link.

The configuration page of the Community server should open without any errors.






Scroll down to the “HTTP Tunneled Client Connections” section on the Connectivity tab.







Set the port to 80. Now press OK at the bottom of the page to save the changes.

Now switch back to the Domino console and restart the Sametime Community server.

res server

Now with “managed-settings.xml” and “managed-community-configs.xml” you can
push these setting to the clients. Pushing settings to Sametime clients with these files
is the preferred way to go. Working with Domino policies is far from predictable.

Follow these steps to configure the location from where to provide these two XML files.

Within the SSC menu on the left side go to “Manage policies”






policy 2
Click Edit for the “Sametime Instant Messaging Default Policy”.

policy 3




Find the “Sametime update site URL (IC):” entry.

We use the FQDN of the Sametime Community server + the update directory.

policy 4



On filesystem level on the Community server you should create this update
directory under /local/notesdata/domino/html/

When done press OK at the bottom of the page.

For initially setting the correct port you can configure the following settings in the
managed-settings.xml file.

<?xml version=”1.0″ encoding=”UTF-8″?>



<settingGroup name=””>
<setting name=”loginByToken” value=”true” isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”loginAtStartup” value=”true” isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”useCanonicalNamesOverride” value=”1″ isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”name” value=”” isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”host” value=”” isLocked=”false” overwriteUnlocked=”true”/>
<setting name=”port” value=”80″ isLocked=”false” overwriteUnlocked=”true”/>





For updating existing server communities you can use the following section
in the managed-community-configs.xml file.

<?xml version=”1.0″ encoding=”utf-8″?>


<managed-community id=”” host=”” port=”80″/>
<managed-community-action type=”update” managed-community-id=””/>



A complete list of configurable options can be found here

The settings should work for the stand-alone Sametime Connect client
and the embedded version within IBM Notes.

Shutdown your Sametime Connect client and start it again.
The server community port should now be listed as 80.

55-CR1-homepage-db2.sql – 705 vs. 704

If you were one of the early birds deploying Connections 5.5 and you used the
Connections SQL files from the initial supplied Wizard tools then applying CR1 will fail.

The 55-CR1-homepage-db2 SQL script checks on DBSCHEMAVER 705. This is the version used within the Connections SQL files from the Day1Fix Wizard tools.
The “old” scripts use version 704 for the DBSCHEMAVER column.


Change the 55-CR1-homepage-db2 SQL script upfront befor applying or make the change after in the HOMEPAGE.HOMEPAGE_SCHEMA table.


VALUES ('HOMEPAGE', 704, '')@


VALUES ('HOMEPAGE', 705, '')@



Customize the new Hikari theme in IBM Connections 5.5

With IBM Connections version 5.5 a new default theme was introduced, the
Hikari theme. In order to customize this new theme new directory paths are
required. You can find the source sprite files ( images ) and the CSS files of this
theme in the following location.


Now open the following JAR file. ( Running IC55 CR1 )

Under \resources\sprite you can find the images used within this theme.\resources\sprite


Place customized versions of these images under the CONNECTION_CUSTOMIZATION_PATH. Find the current customization path in the WAS console under Environment -> WebSphere variables.


Additions and customization’s for the Hikari theme style-sheet needs to be placed under
the following path in a file with the name custom.css.


Custom sprites used by the Hikari theme need to be placed in the below mentioned directory. You can just create a copy of an existing sprite file and make adjustments to it, use other colors or create complete new icons.


This way you can easily re-style the images used for the Apps menu or the Mail & Calendar icons as used by Connections Mail.


IC55 Hikari theme custom mail icons


IC55 Hikari theme custom Apps icons




The caching mechanism of Connections can be very persistent. When activating new
theme changes for Connections I always go for removing all the temp files of the
WAS IC nodes. So stopping all JVM’s, removing everything under AppSrv01/temp and
starting all JVM’s again. Then in the browser go for a CTRL + F5 to see the theme changes.

A strange phenomenon in the combination of Connections 5.5, Connections Mail 1.7 and Windows servers is that temp files are created in directory paths which are longer than the supported length of Windows. ( running Windows 2012R2 )

Whenever you try to remove the Common temp folder you will get this prompt.






Whenever you try to browse to certain directories you will notice that the path
gets so long that you will not be able to open the underlying directories anymore.

For example:


In order to delete these temp files you will need to make the full path length smaller.
So in case of the path as mentioned  above rename some of the directories to a
single character.




Working with IBM Connections Communities under a different URL

During side-by-side migrations or for backup/restore projects it sometimes is necessary
to access your Connections data under a different URL than the original one.

For side-by-side migration projects you may want to run a test migration and let
a subset of test users reach the new environment at a temporary URL. This way you don’t have explain anything about changing hosts files etc and testing access for mobile devices gives you no other challenges than using an alternative Connections URL.

Also testing purposes may demand you to have a set of data that resembles the production system. A thing that will help in troubleshooting data related production issues and gives you a try how to deal with a Connections data backup/restore routine.

The challenge with these projects is that there are components inside Connections which hold absolute URLs inside their configuration. The Community widget configuration is one of them. But you will also see this for Blog items which have images in them which are saved inside the Blogs component.

Also some issues could arise with embedded images inside Wiki pages. ( Okay so the Wikis embedded images thing is related to Connections 5.5. The following tech note was already released to address this issue. “Following migration to IBM Connections 5.5, images within wiki pages have disappeared and replaced with a small box.” )

As you notice it all is a bit trial and error which is mainly because no good
all-one backup / restore procedure exists yet. A lot of progress has been made to introduce trash cans in order to be able to restore deleted Files, Activities etc.
But doing a complete restore to a different environment, for example, get a presentably production like environment is a real challenge.

For now this Blog entry lists a way to fix the widget configurations of Communities so at least all functions within a Community are available and usable.

On creating, Communities don’t have absolute URLs in those widget configurations if
you stay to using “stock” Connections widgets. Add-on widgets like the Library and the “Featured Survey” widget always include an absolute URL inside their configuration.

The “Featured Survey” widget with a wrong URL configuration caused some Communities to get stuck in an infinite reloading loop.

Some other thing I saw going bork when accessing the Connections environment under a different URL was the Files widget. Saving settings for the Files widget will have the effect that absolute URLs  are included.

Below the error you will see when the the Files widget configuration uses absolute URLs.Files-widget-error

All Communities have a widget configuration saved as XML inside a BLOB column in the SNCOMM.LC_EXTENSIONS table. The name of the column is EXT_VALUE_EXTENDED.

widget-config-featuredsurvey widget-config-library






Once you access the Connections environment at the correct URL the thing to fix is to replace all old URLs with the new one within all XML configurations. A good database tool which you can use to open/edit and save BLOB fields is DbVisualizer. Running it in evaluation mode will give a way to edit BLOB fields. If you have a lot of these wrong widget configurations you be better off coding something with Java or SQL else you will be clicking yourselves senseless.


IBM Connections Plug-in for IBM Notes & Connections Cloud

Support for the Connections Cloud in the IBM Connections Plug-in for IBM Notes  seems on its way.




Re the “The Files sidebar plugin does not support IBM Connections Cloud” technote.



Profiles not marked as inactive with two TDI configurations

When you work with two TDI configurations, which is a very common scenario
in a setup where you also have external users, it could occur that profiles
aren’t marked as inactive anymore. Even if the account of the user
is deleted from the LDAP directory.

This could be caused by the facts that:

1. you work with two TDI configurations which requires a specific setup for
both TDI configs. This prevents that the one TDI sync process marks all the
profiles provided by the other TDI solution as inactive and visa versa.

These are the settings for

2, in the situation that the LDAP filter or the LDAP host is changed
after the user profiles where populated.


In order to prevent this you should come up with a LDAP filter to rule theme all
and stick to it or update the PROF_SOURCE_URL column for all profiles to
keep it “synced” with the current LDAP host and LDAP filter in use by the TDI

The PROF_SOURCE_URL is built as follows from the following values.

source_ldap_url + ‘/’ + source_ldap_search_base + ‘?’ source_ldap_search_filter








To make difference between the Profiles that are internal and external you can
use the PROF_MODE column. If it is set to 1 it indicates an external user profile
and 0 is for an internal user profile.

set PROF_SOURCE_URL='ldap://lcalhost:389/dc=base,dc=com?(objectClass=person)'

Credits for this fix go to my colleague Remco.




DB2 backup/restore for IC5.5 – diff. diff. diff. diff.

A different instance owner, a different instance name, different db2levels and different paths. This is a setup you could bump into when you want to migrate your DB2 databases for your IBM Connections 4.5 or 5.0 environment to version five dot five.

When going with the side-by-side migration path you can use the DBT tool as provided by IBM but you can also accomplish this by using DB2 backup restore mechanism as long as your operating system remains the same.

Backup and restore operations between different operating systems and hardware platforms

This is one of the setups I had to work with.

Source DB2 system
– Windows 2008 R2 64bit
– DB2 10.1 FP2 64-bit
– Tablespaces located on D:
– Instance owner: DB2ADMIN
– Instance name: DB2

Target DB2 system
– Windows 2012 64-bit
– DB2 10.5 FP7 64-bit
– Tablespaces located on Z:
– Instance owner: DB2IIC
– Instance name: DB2IIC

First create offline backups on the source DB2 system. ( You can’t use online backups
to restore to a higher DB2 version on the target system. ) Restoring to a higher DB2 version will automatically upgrade the database to the new version.

Get the offline backups to the target DB2 system.

Logged in as the new instance owner on the DB2 target system make sure to set the following DB2 variable so the DBADM role is giving to the user that is performing the restore.


Make sure to stop and start the DB2 instance.


See the following technote about this command. “Grant the new instance owner rights on all new restored databases”. ->

Navigate to the path where you placed the backups from the source system.
As an example we use the Activities OPNACT database. Use the following command
to start the restore of the OPNACT database. By using the “redirect generate script” parameter you get the option to change the paths where to redirect to.

db2 "restore db OPNACT from . ON "z:" into OPNACT redirect generate script dbrestore_OPNACT.txt"

After running this commando open the dbrestore_OPNACT.txt file. For the OPNACT
database I had to make the following changes. It depends per Connections database as some have more tablespace containers than the others.

Enable ( remove the leading — ) and change the used path values.
Find here the original and the modified one. The new paths to choose are up to yourself ( as far as I can tell ).


ON ‘Z:’


FILE   ‘Z:\DB2IIC\NODE0000\SQL00001\OAREGTABSPACE’              4480


If the database already exist on the target system and you want restore into that database/replace make sure the NEWLOGPATH directory is empty else first
remove all log files inside that directory.

del /s /q /F Z:\DB2IIC\NODE0000\OPNACT\NODE0000\*.*

Now run the modified SQL statement to complete the restore.

db2 -tvf dbrestore_OPNACT.txt

Check if you can connect to the restored database.




If you have restored all the databases use the 5.5 day1 upgrade scripts to upgrade
to the IBM Connections 5.5 level.