Tag Archives: connections

Social File Sharing: IBM Connections vs. MS SharePoint

A collegue brought the following great comparison of Social File Sharing in IBM Connections and MS SharePoint to my attention.  While it is done cleary from IBMs point of view I still can’t believe that SharePoint could be that “unsocial” when it comes to it’s greatest strength: files and documents.  If you are using MS SharePoint feel free to comment and show me what the colleague is overseeing. 😉

Here the video in English:

Here the video in German:

 

 

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: com.ibm.websphere.asynchbeans.SerialDeserialException: 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

execfile(“connectionsConfig.py”)

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:

Communities:

DB: SNCOMM – COMMUNITIESSCHEDULERTASK

Activities:

DB: OPNACT – OA_SCHEDULERTASK

Forum:

DB: FORUM – DF_SCHEDULERTASK

Profiles:

DB: PEOPLEDB – PROFILES_SCHEDULERTASK

Files:

DB: FILES – SCHEDULERTASK

Wikis:

DB: WIKIS – SCHEDULERTASK

News:

DB: HOMEPAGE – NR_SCHEDULER_TASK

Search:

DB: HOMEPAGE – LOTUSCONNECTIONSTASK

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.

NodeRestartState

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.

Speichern