Different WAS node Versions in a single cell

In the course of Connections CR Updates I also tend to update all WebSphere Components to the latest supported version. Currently for Connections 5 CR2 & CR3 the latest supported Application Server is WebSphere 8.5.5.4.

Quite recently we needed to update a Connections environment from 5 CR1 to 5 CR2. This Environment consists of four nodes, on two of them we have Connections applications running in a cluster, the other two are used for IBM Docs applications, also clustered. One of the nodes where Connections Software is running is also a Deployment Manager.

The initial plan was to update WebSphere Nodes, to 8.5.5.4, only on which Connections is running. We wanted to update remaining nodes later on, in the course of IBM Docs Update. This was a very bad idea, after the Update, the two IBM Docs nodes, running the older version of WebSphere, started getting out of sync, causing Docs applications to stop working.

Manual Synchronization, using “syncNode.bat” file, seemed to resolve the problem for a short period, but only after we updated the IBM Docs Nodes to the 8.5.5.4 version we managed to solve the synchronization issue.

So beware of running different node versions of WAS in a single cell.

TDI Job “sync_all_dns.bat” fails to run

Recently I noticed that some employee records in PeopleDB were not in Sync with the records on our LDAP Server.

Looking at the Job History in “Task Scheduler” on our Backend Server, Windows Server 2008 R2,  were TDI Job “sync_all_dns.bat” runs I could see that the Job was being triggered at regular intervals as configured without any problems. After looking at the TDI Wizard Log Files, “ibmdi.log”, it was clear to me that the “sync_all_dns.bat” batch file was not run for a while, the value of “Date modified” Field was about two days old.

The “sync_all_dns.lck” File had the same value in “Date modified” Field, so the job “froze” for some reason.

2015-08-19 21_19_49-mRemoteNG - C__Users_wbtmam_AppData_Roaming_mRemoteNG_confCons.xml

After manually deleting the “sync_all_dns.lck” file the “sync_all_dns.bat” Batch file could be run and the PeopleDB synchronized with our LDAP Server without any problems.

Deleting Port numbers from LotusConnections-config.xml File

Short after installing Connections I always delete the port numbers or change the URL completely in the “LotusConnections-config.xml” file so that Connections Applications could be accessed without typing the port numbers as a part of an URL.

Doing this manually can consume lot of time.

You can automate this process by using the replace function in “Notepad ++” or “UltraEdit” editors as described in following.

Notepad ++

notepad++

UltraEdit

ultraEdit

I hope this helps. 🙂

Files “An unknown error has occurred.”

Recently I encountered an error in IBM Connections which caused me a lot of headaches.

A Customer informed me that he cannot see the files of a community. After opening a community and clicking on files tab the following error pops out “An unknown error has occurred”, at the same time Firebug Plugin was showing “Network Error: 403 Forbidden”. As shown in a screenshot below:

Files Error4 Blur

The customer has not made any changes in the environment. At first I could not reproduce this issue in the Connections environment of our customer or in any other environment. After a lot of troubleshooting we opened a PMR regarding this problem.

A few weeks later, yes we were troubled by this issue for weeks, tickets started to pop-out in our helpdesk showing that this error started to occur in basically all other Connections environments we are managing.

At first I thought this error was occurring only in Firefox, later on we got the info that this issue could be reproduced in Chrome and IE, regardless of the Version. I could also verify that this problem occurred in Connections 5.0 CR1, CR2 and CR3.

At this point I started to get desperate, thankfully the IBM Support provided us with the Interim Fix for Communities Application, which is applicable for Connections 5 CR1, CR2 & CR3.  Until now I tested it on CR3 Version, the iFix worked perfectly, resolving our issue.

The number of the Interim Fix we got is “IFLO86000”.

I hope this saves you some hair… 🙂