This week I was challenged with a completely deceptive error message during the installation of the Sametime Meeting Server. The error message claimed that
System Clocks are not synchronized within 5 minutes of one another, Please synchronize for federation.
Since I was working in a somewhat unreliable test environment I obviously believed in the message and dutifully compared the system times between the Sametime Systems Console server and the Sametime Meeting server. Without a lot of surprise the times were synchronised and the time zone settings didn’t cause any trouble either. This obviously didn’t help me in any shape or form hence I started to investigate the various log files created by the system.
Looking at the Deployment Manager’s System log I discovered an error, which was logged every time I tried to confirm the deployment plan for the Sametime Meeting Server:
[20/04/12 16:21:13:150 NZST] 00000065 exceptionÂ Â Â Â W com.ibm.ws.wim.adapter.file.was.FileAdapter login CWWIM4512E The password match failed.
[20/04/12 16:21:13:151 NZST] 00000065 exceptionÂ Â Â Â W com.ibm.ws.wim.adapter.file.was.FileAdapter login
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4512E The password match failed.
[20/04/12 16:21:13:153 NZST] 00000065 LTPAServerObj EÂ Â SECJ0369E: Authentication failed when using LTPA. The exception is <null>.
This triggered my memory. We recently had to change the password for the local Websphere administrative user. Researching above error message I learned from Dave (Thanks!) that the local file registry could still hold the wrong password. The link in Dave’s post pointed me to the instructions on how to How to reset the administrator’s password in the file registry. While those instructions obviously aim for Websphere Portal they still helped me solve my issues with the Sametime Systems Console deployment manager.
After synchronising all the nodes and restarting the application servers, node agents and the deployment manager I managed to successfully deploy the Sametime Meeting Server.
How to reset the administrator’s password in the file registry
While I was working on the upgrade of our existing Sametime environment to Sametime 8.5.1 (soon 8.5.2) I have run acrossÂ an interestingÂ question that I considered worth sharing: Will I use Domino LDAP or connect to Active Directory.
There are good and not so good reasons for either option: Continue reading
Just a quick note interesting for DB2 installations on Windows 2008 Server or Windows 7 workstations.
If you are receiving an error “SQL5005C System Error” immediately after the launch of the operating system you have most likely missed to add your current user ID to the DB2Admin group on the local machine.
SQL5005C System Error
This post is in response to a question asked on my previous post by Gili Nachum.
When re-installing the Sametime Gateway to convert it from a Single Server to a Network Deployment you are obviously faced with the task to re-configure the system, which definitely includes the SSL configuration. There might possibly be a way to transfer most of the configuration using Websphere scripts. In absence of any experience in this area I am going to describe the manual steps here.
Very important: create a backup of your Websphere directory before removing the old installation of the Gateway. I am assuming here thatÂ you have followedÂ IBM’s instructionsfor theÂ SSL setup of the single server and didn’tÂ create a custom keystore.Â In this case you’ll find a key.p12 file within the profile config, which is the NodeDefaultKeyStore and a trust.p12 file, reflecting the NodeDefaultTrustStore.
On setting up the new Sametime Gateway server using network deployment you will be creating a new key store. Instead of creating a certificate request though you are going to import the existing certificate.
- Select Personal Certificates under Additional properties and choose Import.
- Choose Key store file and type the path to you key.p12 file.
- Leave Type set to PKCS12.
- Enter the Key file password. The default key store password, if you haven’t changed it, is WebAS .
- Hit the ‘Get Key File Aliases’Â button and select the alias to import in the drop down below.
- Define the alias name for the import and hit okay.
Repeat above steps for all trust certificates using the trust.p12 file of the old installation and the CellDefaultTrustStore of the new installation. You can now continue with the SSL configuration for the cluster, the SIP andÂ XMPP proxy.
As a side note to above: it is strongly recommended to change the password for your DefaultKeyStores. Otherwise an attacker might possibly be able to steal and misuse your identity.
WASServiceCMD.exe – Nice command line tool to register Websphere servers as a Windows service
Adam Brown – Starting up Lotus Connections automatically
Thanks for sharing!