Issue:
An Apple iPhone was unable to synchronise with the Traveler server. The only error message we got was 403 FORBIDDEN (Access not allowed even with authorization) in the Domlog.nsf.

Investigation:
Issue tell traveler security status username on the domino console. This will result with a listing of all devices registered to a user and their security status. In this particular case the security approval was pending for the iPhone but the device was not listed in the LotusTraveler.nsf.

Solution:
Issue tell traveler security approval approve deviceID username. This will approve the pending device approval and re-add the device to the LotusTraveler.nsf.

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

NC_DB_PATH=G:\Datadir

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.

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.

Plug-in: com.ibm.collaboration.realtime.imhub
Preference: showExternalModificationDialog
Value: false

There are good and not so good reasons for either option:

• To get the discussion started there seems to be the obvious choice to keep on using the Domino Directory when switching to LDAP. This way users can work in their familiar directory structure without the need to impose the rather technical structure of (our) AD.
• On the other hand it appears to be quite reasonable to also implement SPNEGO.  This however requires the use of Active Directory as a LDAP source.
• On the flip-side there is the obvious issue of the non-hierarchic structure of the Domino groups. Combine this with the requirement to have a base entry for LDAP defined as mentioned by Gabriella Davis and you are left with yet another point for consideration. Especially if you are reluctant to make existing groups in the Domino Directory hierarchic – who is doing that anyhow?

I am wondering how other environments have designed their solution. Did you really append an organisation to the name of groups just to make them available in an LDAP tree?
How did you maintain group entries in the vpuserinfo.nsf when moving between directories? Person entries are easily managed utilising the name change task but groups are rarely replicated between directories, hence the benefit of previously added public groups to the contact list is just gone.
Is there any way to use Domino as a LDAP source but still provide SSO in a Windows environment? I am wondering whether there is the possibility to have the Websphere server connecting to two directories, one for authentication, the other one for online awareness. Similar to the portal configuration described here. Or maybe utilising a Domino server for authentication with shared LTPA keys between Websphere and Domino?

I am sorry for everyone who expected any answers to their own questions in here. Do not hesitate though to leave a comment if you are having a suggestion for any of the questions raised in here or below.