After my previous post I am now back with a more appealing issue. Not a show stopper but still annoying, considering the possibilities if the automated client update is truly going to work.

The issue I am facing is an error message on our Nokia mobile phones on checking for new updates using the update installer:

“The response indicates that the server does not support Lotus Installer”

Strangely enough I have been able to upgrade one phone using this method without any issues, all subsequent attempts from there onwards failed and I am a bit stuck due to the lack of detail of information on this feature on the web. Did anyone else run into this issue today or during the beta phase? I have also opened a PMR with IBM. I will update this post as I am receiving updates.

Update 26/08/10:
Just figured out the main cause of the issue. The domlog.nsf records the URL request of the Update Installer application from the mobile phone, which looks similar to that:

server.domain.com/servlet/traveler?action=checkForUpdate&deviceType=NokiaS60-5.0&version=0&appName=Lotus%20Installer

You can open this url in the browser of your PC and will receive a response similar to this:

DownloadLink=/traveler/LotusInstaller/LotusInstaller.sisx
Version=8.5.2.0 201007201801

As always, the devil lies is in the detail. Before getting to the response I had to enter my username and password in the browser, which made me think that this could be the actual issue.
Again, checking the domlog.nsf, I realised that the request from the Update Installer is an unauthenticated one, hence making it impossible for the application to receive the response.

The possible workaround is also explaining why I had been able to run the update once. The phone still had an open connection to the server in the browser session, which made the Lotus Installer request an authenticated one as well. Guess that’s the workaround for now until IBM comes back with a permanent fix on this as I don’t fancy allowing anonymous access to the Traveler servlet itself.

Just updating our environment to Lotus Domino and Traveler 8.5.2.

The only item catching my eye so far is the altered directory for traveler problem reports. In the past they were located in a folder named traveler\logs\tprs in the Domino data directory. This has now changed and the files can be found in the IBM_TECHNICAL_SUPPORT\traveler\logs\tprs directory.

This is important for organisations that have employed some kind of process to get the problem reports picked up and processed automatically from this directory.

Some details on TPRS can be found here.

WASServiceCMD.exe – Nice command line tool to register Websphere servers as a Windows service

Adam Brown – Starting up Lotus Connections automatically

Thanks for sharing!

While the Lotus Connections 2.5 installation guide is quite comprehensive there are a couple of flaws a non full fleshed Websphere application server administrator (like me) won’t spot immediately, hence falling into the trap.

I was banging my head the past few weeks, not being able to determine why on earth I wasn’t able to set-up a network deployment of Lotus Connections. The error message was pretty trivial and documented in the Lotus Connections wiki.

CLFRP0258E: The installation of feature {0} failed while creating WebSphere® Application Server Variables.

Hunting through the detailed error messages in the log though didn’t make me any wiser. Until I got the tip (thanks Justin) that the application server profile has to be unmanaged prior to the installation of Lotus Connections as it will be federated as part of the installation.

This is clearly documented on page 36 of the installation guide (“The node must be unmanaged before you install”), however, other paragraphs further out indicated that the application server is being managed by the deployment manager. Core examples are on page 37 explaining that security should only be enabled on the deployment manager in order to not having to repeat the steps for each node, which indicated to me that the node must be managed at this point in time.

I am sure this procedure can be found all over the World Wide Web. However, I need to document it for myself here so I don’t have to search for it again.

Stop the Websphere application server.

Open the command prompt (in Windows) and browse to the Websphere home\bin\ directory. Issue ‘wsadmin.bat -conntype NONE’

This will come up with a message “WASX7357I: By request, this scripting client is not connected to any server process. Certain configuration and application operations will be available in local mode.”, which is pretty much confirming that the wsadmin is not connected to any server process.

Once launched issue ‘securityoff’ to the wsadmin console.

Restart the Websphere application server.