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
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
Just a quick note to everyone who is going to set-up Lotus Notes Traveler 8.5.1 on the Nokia E63. We have had one issue where Traveler did not start synchronising after the successful set-up on the mobile device. Instead the Traveler home screen got stuck and the whole S60 operating system reacted very slowly.
IBM technical support is referring to this as the “home screen issue” andÂ is working with Nokia on a solution. In the meantime you can request a test fix from IBM that will disable the Traveler home screen. Feel free to quote PMR 36532.120.796 if you are experiencing similar issues.
This morning I was stumbling upon a very interesting issueÂ in Lotus Notes/Domino that involved truncated documents on a server replica. ThisÂ is an issue as the database on the server is the only one, besides a number of local replicas on laptops.
A bit of research on the web unveiled that Almar DielÂ has encountered a similar problem, which pointed me towards the right solution.
In order to get theÂ full documents backÂ onto the server replica IÂ had to find the laptop that was holding the replica with the corrupt replication formula as this had to beÂ cleared out as described in workaround option 2 of this IBMÂ technote.
This will ensure that all documents replicated from now on would not be appearing as truncated documents anymore on the server. In order to fix the existingÂ truncated documents though, IÂ had toÂ remove the documents from the serverÂ replica without leaving deletion stubs. This can easily be achieved in utilising Julian Robichaux’ stub-less delete function documented here. Clearing out the replication history of the local database and issuing a new replicationÂ did make the documents re-appearing on the server replica in there entirety.
Thanks to Almar and Julian for documenting your solutions!
One of my previous posts describes that there are two different ways policies are applied to traveler users.
When Traveler policies are applied, the content of theÂ settings documentÂ is beingÂ copied over into a profile document of the user’s mail file.
The Traveler server is using the Traveler’s Cluster Cache database (ntsclcache.nsf) toÂ look-upÂ the location of the user’s mail file.
The following error could be raised when policies can not be applied:
Notes Traveler: SEVERE [SYSADMIN] Internal Error: Debug Data: Error on UpdateProfileFromPolicyError: Database ‘mail/mdemo2.nsf’ on ‘CN=MAIL/O=Organisation’. Error(227 )=Invalid or nonexistent document
There might be an issue with the ntsclcache.nsf. Just open the database, remove the entries for the affected user. Restart the Traveler task and try applying the policies again manually.
In my case the mail file was located on a 7.0.3 server in a different domain, hence I had to issue ‘Tell Traveler Policy Update MDemo2‘