Creating an LTPA Token – Without WAS Network Deployment Server

Recently I was installing an HCL Sametime 11 environment from scratch. I always tend to implement a single LTPA Token across the Domino, Sametime and/or Connections environment. It is also a very good idea to use only the LTPA Token version 2, as it is more secure, but this also means that the LTPA Token has to be created by a WebSphere server.

Usually this is not a problem, because most of my customers have HCL Connections or an older version of Sametime already deployed, which means that they are also using WebSphere Application Server Network Deployment.

But this customer only had Domino, and a new installation of the WAS Network Deployment Server, solely to create a new LTPA Token and scrap it afterwards would take me too much time.

My friend Herwig W. Schauer gave me tip that the same could be done with WebSphere Liberty server, which is a lot faster.

Just download the latest version of WebSphere Application Liberty Server, which is free, from the IBM Website, I used the ZIP Install Package for Windows OS.

Just extract the downloaded package to the directory of your choice and open the “server.xml” file, which can be found under “<was_liberty_package>\wlp\usr\servers\defaultServer”, in text editor. At the line number 17, inside the “<ltpa>” tag, edit the “keyFileName” and “keysPassword” parameter, as shown in the screenshot below:

Afterwards, just start the WAS Liberty by executing the “server.bat” script.

<was_liberty_package>\wlp\bin>server.bat start

Just as in the screenshot below:

As soon as you get the server fired up, a new LTPA token will be generated in “<was_liberty_package>\wlp\usr\servers\defaultServer” directory, with the name and password you specified in the “server.xml” file.

That’s it, you can take the newly generated LTPA token and import it to Domino.

We Have Lost The “wasadmin” Account Password!

If you have lost the “wasadmin” account password or any other local WebSphere account, there is a rather simple way to recover it.

Just connect to the server where WebSphere Deployment Manager is running, via RDP or SSH, depending on the OS of the server, and open the “security.xml” file located under “<WebSphere_Installation_Directory>/AppServer/profiles/<Deployment_Manager_Profile>/config/cells/<Cell_Name>” for example “/opt/IBM/WebSphere/AppServer/profiles/ic-dmgr01/config/cells/ic-cell01”.

After that just search for the account name, for which you would like get the password, in the same line you should find the attribute “password”:

Then just copy the value of the “password” attribute, now we need to decode the xor encoded password. For that I am usually using the following Website:

Just paste the encoded text and click the “decode” button, after that you should have the password.

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

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, 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 version we managed to solve the synchronization issue.

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