Category Archives: Tech-Bits

Lotus Notes displays wrong calendar week

Under certain circumstances it is possible, that Lotus Notes will display the wrong calendar week.  This is due to different counting of calendar weeks in e.g. Europe and U.S. (in Europe weeks starting on Monday in the US on sundays).  In my case this happened, when I set my Mac OS Lion to English and thus to an American Environment.  For example the last week of this year is displayed as calendar week 53 as can be seen in the following screenshot:


To fix this and have the correct week shown we must set the calendar week counting to ISO standard.  To do so go to the preference pane and open Calendar and To Do followed by Regional Settings.  Now you can switch the radio button on the bottom from “Use my operating system regional setting” to “always use ISO standard“.


After clicking OK switching back to the calendar show that the week number has changed to week 52:



Manually delete the Search- / Index- /CleanUp-Taks for Connections directly in the DB2

After I had to reinstall an IBM Connections 3.0.1 system (a HDD crash destroyed the installation and of course Murphy made sure the customer did not have a working backup) I realized, that certain tasks did not run correctly anymore.  The SystemOut.log from the WebSphere Application Server showed the following error message:


ASYN9999E: Unexpected Exception Occurred: Exception while deserializing a saved service. Service=security. Unable to deserialize the Subjects in this Context, cause: Validation of LTPA token failed due to invalid keys or token type.


According to this support document this means that either not all fixes are installed correctly or that the search tasks in the databases are either broken or saved with wrong or non-valid LTPA tokens.  The correct way to solve this ist deleting the tasks, which can usually be done easily using the wsadmin-console (here the description in the IBM Connections Wiki).  After a restart of the applications the tasks are then recreated automatically. This is how it’s done:


\DMGR01\bin\wsadmin -lang jython -user wasadmin – password password


In a cluster select “1

Scheduler.listAllTasks() – this shows all available tasks

Scheduler.clearAllTasks() – this deletes all tasks

restart Cluster to recreate all tasks


Unfortunately in my case the wsadmin-console kept telling me, that the corresponding application is not running and therefore the task cannot be deleted (of course the newly reinstalled applications were running).  The only way out was deleting the tasks directly in the database. Using DB2 you need to start the DB2-Control Center and access the Connections database.  The above mentioned  Scheduler.listAllTasks() shows in which component / database which task resides: Communities, Activities, Forums, Profiles, Files, Wikis, News and Search (both in the Homepage DB).  So you need to open each database and click on the left on Tables. Now you can open the needed table by double clicking it. In the now opened windows you can select the task and then click on Delete Row followed by hitting the Commit button. This deletes the tasks.


Entries to delete in the db2


The tables with the entries to delete are:

















Once you’re done: Restart IBM Connections and all tasks are recreated and should be running fine.

The reason in my case for this problem was that the tasks were created using the old installation of Connections.  After I had to reinstall Connections including the WebSphere Application Server the LTPA tokens were newly created and not the same as the ones saved in the DB. Therefore the tasks complained about the LTPA validity.


TDI User Import – tampering with the collect.dns can be dangerous

Sometimes in a testinstallation of IBM Connections you may only want to import a few specific user.  This can be done by editing the collect.dns by hand, because only the users present in this file will be added to the Profiles database in the next step when running the populate_from_dn_file.

Unfortunately there is a little trap you can step in.  The collect.dns *MUST* be saved in the UTF8-format, otherwise you will encountered massive problems with names containing Umlaute or other special letter as in Sören Müller.  If you use Notepad for editing the file will be automatically saved in ANSI format, unfortunately. If the list than contains a special character the populate_from_dn_file will start though, but once it hits the user with it it hang and the log files will grow rapidly (easily a few 100 MB in 10, 20 seconds). If you notice that: CTRL-C the comandline running the populate_from_dn_file and reopen the collect.dns and this time when saving select UTF-8 in the “Save as type” field:


Beim Speichern UTF8 statt ANSI auswählen


Right after that you can restart the importing of userdata and it should run fine for all Müllers of this planet..

Backup / Restore of an IBM Connections environment on file basis

In todays time of virtual machines the easiest and simplest way of getting a backup is doing a snapshot. I usually recommend it everytime bigger changes such as upgrades are done.  But not always there is the option to get a timely snapshot and therefore other means of backups are necessary.  One “quick and dirty” way is copying all necessary files to a backup folder.

In a standard Connections environment (all Components in a /IBM directory) this usally means backing up two directories:

  • the database directory (/DB2) if DB2 is installed locally
  • the complete aforemeantioned /IBM directory (at least the /WebSphere and /LotusConnections directories under it)

Since IBM Connections 3 the IBM Installation Manager is used for installing the solution and its upgrades.  Now I ran into a problem during an upgrade to 3.0.1 (always check the the remote desktop is started using the /console setting 😉 ) and hat copy back the recovered folders.  Unfortunately the Installation Manager copies files some files in a separate directory no matter what you said when installing. And these files contain the information which upgrades have already been installed.  So the IBM Installation Manager was still believing 3.0.1 was installed even though it did not and I copied back the “old” 3.0.0 environment. Having not enough time to play around I went the way of deinstalling Connections completely and reinstalling it.

So when you do a backup, make sure to add the following folder, too:

  • C:\ProgamData\IBM\Installation Manager


Synchronizing changes done in the WebSphere WebSphere Integrated Solution Console automatically

Whenever WebSphere Application Server settings are changed in the Deployment Manager, these changes are not pushed down to all nodes automatically by default.  Therefore a manual synchronization must be triggered to get these changes pushed to all cluster members.  This can be automated by doing the following steps:

In the Integrated Solution Console (ICS) open System administration on the left hand menu and the click on  Console Preferences.

Console Preferences auswählen

Now you can set the checkmark on the right side at Synchronize changes with Nodes.

Synchronize changes with Nodes

Once you click on “Apply” all changes in the ICS will be pushed down to all available cluster members whenever “save” is clicked.

Monitor IBM WebSphere applications and start them automatically

IBM Connections is being installed in a WebSphere Cluster.  After rebooting a server there are different ways of restarting each application server and application.  One way is starting each feature as its own service task or, and this is what this blog entry is about, you just start the node and the node itself will check the application status and detect that the applications are not running and will start them on its own.

To configure this you need to log into the WAS Integrated Solutions Console with the WebSphere Application Server admin user and select  Servers => Server Types => WebSphere application servers:


WebSphere Application Server Auswahl


Now you select the first server and click on Configuration and then click on Monitoring policy.

Monitoring Policy

Now we need to change the Node restart state to RUNNING.


Finally we save the changes and repeat these steps for each server. After doing a Sync to all notes if necessary we can restart the node agent and all changes are active.  Now the applications are monitored and started automatically if they are not running after an reboot / restart.