Not at all would I have expected this cause when an user complaint today that SSO (Single Sign-on) with the Windows XP operating system ceased working after changing the password.

Investigating the matter it turns out that the user used the colon ‘:’ as part of the password. This and two other special characters (tilde ‘~’ or asterisk ‘*’ on the number pad) are obviously not supported when using SSO between Lotus Notes and the operating system. The issue appears to be well known and documented by IBM. Unfortunately there are currently no plans to address this issue.

Fair enough. At least I know what to tell my users the next time they are running into similar issues.

You should have seen my surprised face today. I was playing around with SSO (Single-Sign-On) for the integrated Sametime client and the security setting that enforces the change of the notes ID password to be replicated to the internet password field in the Domino Directory.

Until recent I did this with Lotus Notes and Domino in version 6.5. As the administration server was different to the user’s mail server there was always a delay when the user has changed his/her ID password. This happens because the request to change the internet password is submitted to the user’s mail server admin4.nsf and processed after the request gets replicated to the administration server.

IBM made a big announcement that this process will be streamlined with Notes/Domino release 8 where these kind of requests are delivered directly to the administration request databases (admin4.nsf) on the target server, which in case is the server that is going to process this message.

While testing the same today with Lotus Notes/Domino 7.0.3 (FP1) I discovered that this feature was already implemented with this release. I am wondering what maintenance release or fix pack this enhancement included. Or was it already part of the 7.0 package but no one ever bothered emphasising this?

Guess no one asked me this before and I didn’t run into this question yet. However, today I got approached with the question how line breaks can be entered in a mailto: command.
The answer can be found in RFC 2368 whereas line breaks in the body of a message must be encoded using the %0D%0A sequence, which in case is nothing else then hexadecimal for 10 (line feed) and 13 (carriage return).
A full mailto: command using this feature could look like this:

mailto:name@domain.e_t?subject=Header&body=This is the first line%0D%0AThis is the second

Strictly speaking should the white spaces also be replaced with the appropriate ASCII code which is %20 and makes the complete command to look like this:

mailto:name@domain.e_t?subject=Header&body=This%20is...
%20the%20first%20line%0D%0AThis%20is%20the%20second

Some weeks ago I tried to enable my Lotus Sametime/Domino environment to allow scheduling of Sametime online meetings from within the Lotus Notes calendar. Sounds straightforward. Doesn’t it? So thought I.

While everything was working fine until the processing of the meeting invitation on the Sametime server I started following IBM’s step-by-step guide while double and triple checking that all the settings made had been all right.

After debugging the configuration, again following IBM instructions, it appeared that the Java service manager is having issues parsing the time format of the meeting invitation as shown below.

exception msg:Unparseable date: "01/08/2008 08:30:00 p.m."
01/09/08 9:22:56.117 [Trace ] [ CalendarServiceHandler ] [ com.lotus.sametime.meetingmanagement.meetingservices
.notes.NotesDateTime

Funnily this seems to be caused by the a.m./p.m. time format being used in some English spoken countries as New Zealand, where I currently live and work. Changing the time format to either military time (24 hours) or AM/PM (capital letters) extension let this problem disappear. Some instructions on how to change the time format for the systems account in MS Windows are documented here.

When I submitted this issue as PMR to IBM it appeared that no one else in this world has had this issue before. I can only see two reasons: Either anyone else has proper time formatting and, being German, I consider a 24 hour clock as a proper format or they are not using Sametime at all. Let’s see if I missed anything.

Nowadays it seems to be public known, that the existence of a $KeepPrivate field prevents documents from being copied, forwarded or printed in Lotus Notes. Until recent I was aware of about three possibilities on how this field will be added to a document. Via design specifications, manually via smart icon code or while using the ‘Prevent copying’ delivery option in the Notes client.

While testing an application for compatibility against Notes/Domino 7.0.3 recently an user complaint that she would not be able to copy documents from one field to another using the clipboard. This was caused by the existence of the $KeepPrivate field for each newly created document.  According to the IBM Support this appears to be a feature even I wouldn’t totally consider it as such. If an user has the access rights to create new documents within a database as author or above but did not the replicate or copy documents option granted, each document created from this (group of) user(s) will have a $KeepPrivate field set to 1.

Looks like I need to log a new PMR to find out whether or not there are plans to address this in any future release to split up the replication and the copy right.