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
This may not be an issue for organisations that do have the Domino data directory in the default location (e.g. <Domino Program Directory>\data).
If however you want to run the stnamechange task on a server with an alternative data directory, you must add the following parameter to the [Config] section of the sametime.ini
I recently upgraded our Sametime environment to version 8.5.1 from version 7.5.1. Since we also wanted to transfer to new server hardware I figured it would be easiest to do a new installation and just migrate the vpuserinfo.nsf and stconf.nsf. Since no configuration settings are being migrated this was a good opportunity to startÂ afresh.
This here is a quick note (from own experience) that the design of the vpuserinfo.nsf is important for the successful run of Sametime.
Since the vpuserinfo.nsf got copied to the new server after the set-up it didn’t receive any design updates. This causes the Sametime community server to not accept any new client connections. Obviously since neither the user’s contact list nor privacy settings can be found. Thanks to IBM support for hinting into that direction. I spend about two hours on the phone with the support checking all sorts of logs and config settings. Until we were left with none but one possibility: ‘a corrupt vpuserinfo’.
When compact, fixup and updall didn’t yield any success I got suspicious and took a closer look at the design of the database.Â While I refreshed the design of the databases from the stuserinfo.nsf template I did not realise that LocalDomainAdmins do not have access to the template itself. This effectively removes all design elements from the vpuserinfo.nsf, resulting in the issue as described above: no users are able to connect to the Sametime Community server. Once I refreshed the design of the database on the server console instead of the admin client my users where happily connecting to their new Sametime server.
If you have followed IBM’s instructions on replacing the Domino Directory with an LDAP directory you might notice the user notification below after running the stnamechange command against the vpuserinfo.nsf:
I can not think of any valid reason why a user should be bothered that his ‘contact list has been updated to reflect recent administration changes to contact names’. In my experience it would just puzzle people, especially since there is no true information relayed or any action required.
Fortunately we have given the possibility to to suppress the prompt for the user either using a managed setting in the plugin_customization.ini or a desktop policy.