by Michael Urspringer
Allen Lesern meiner Seiten wünsche ich ein frohes und geruhsames Weihnachtsfest.
Dieses Jahr wird’s bei uns ganz sicher etwas ruhiger, da mich rechtzeitig zu den freien Tagen eine starke Erkältung erwischt hat und ich seit 3 Tagen schon im Bett stecke. Heute musste ich dann doch den ärztlichen Notdienst bemühen und mir eine Dosis Antibiotika abholen, da es eher schlimmer als besser wird.
Melde mich dann wieder, wenn ich einigermaßen auf dem Damm bin.
This time I just modify my last post from yesterday evening …. instead of Hotfix 6 it now reads simply Hotfix 7 🙂
This time I am a little bit late…. Hotfix 6 Hotfix 7 for Lotus Quickr (Domino Services) is out since yesterday. BTW: There was no public Hotfix 5 as far as I know …
In the hotfix documentation you now will also find some instructions what to do after applying the fix.
I am not sure if the comamnds are in the correct order as they write:
• Upgrade all the places and Placetypes:
load qptool upgrade -f –a
• Upgrade all the databases on the server:
load qptool upgrade -f –server
I am quite sure that you should do it the other way round (as it was decsribed in the past) but I am still trying to verify this.
They now have corrected the order in the readme of Hotfix 7.
In addition to the commands you have to run in the past you now should also unregister and register all places again afterwards:
load qptool unregister -a -placecatalog
load qptool register -a -placecatalog
If you want to use SSL for Lotus Quickr (Domino Services) you have to do three four different things:
1. Configure the Domino HTTP task correctly for HTTPS
2. Activate SSL for the Domain catalog server and set the correct port numberi n QPCONFIG.XML:
| <search_places …..”> | |
| <domain_catalog_server ssl=”true”> | |
| <port>443</port> | |
| <domino_server_name>………<domino_server_name> | |
| <hostname>………..</hostname> | |
| </domain_catalog_server> | |
| </search_places> |
3. Activate SSL for cluster
| <cluster> | |
| <master ….. ssl=”true”> | |
| <port>443</port> | |
| <hostname>……….</hostname> | |
| <path_prefix></path_prefix> | |
| </master> | |
| </cluster> |
Important: It is not quite obvious that you have to do step 3 also in a non-clustered environment. But if you do not add this configuration option you end up with connector links which do no longer work. Instead of links like “https://servername.domain/……” you get links like “https://servername.domain:80/……” which will not work because of the wrong port number.
Update:
There is another thing to do:
4. Unregister and register the server again:
On the Domino server console run the following commands:
load qptool unregister -server
load qptool register -server
Otherwise the links in MyPlaces will still point to “http://” instead of “https://”.
While upgrading Lotus Quickr 8.0 to 8.0.0.2 (HF4) at a customer site we experienced two problems:
The first thing was that the command “l qptool upgrade -f -a”, which you have to do in order to get all places upgraded to the new version, promotes all place managers to super users. So you should check your places afterwards and correct them if necessary. A PMR is opened and currently under investigation. You can see a corresponding message also in the Domino server logs (“Upgrade: Upgrading Place ‘Main.nsf’, promoting ‘CN=xxx yyy’ to SuperUser.”) if you set a higher log level for the upgrade process (set the variable “QuickPlaceUpgradeLogging=4” in the NOES.INI before running the upgrade command; attention: you will get many messages if you do have many places to upgrade, so be careful by using this parameter).
The other issue was that after upgrading all places the users did not see any documents in the Quickr connectors. The reasons seems to be that “l qptool upgrade -f -a” did not upgrade the places correctly. What worked for us was to issue the command “l qptool upgrade -f -a” again. after the second run all places worked correctly with the connector again. Another PMR was opened for that as well.
Hotfix 4 for Quickr 8.0.0.2 (Domino Services) is out.
It seems that this problem is fixed now (according to the documentation; it still needs to be verified).
Hotfix 3 for Lotus Quickr 8.0.0.2 (Services for Domino) has just been released on FixCentral.
[Thanks to Oliver who noticed me earlier than my internal resources :-)]
With version 8.0.0.2 of Lotus Quickr (Domino Services) there are several new parameters which can be configured in the QPCONFIG.XML. It is worth a look into the QPCONFIG_SAMPLE.XML after upgrading the server.
Some of the new parameters control …
… if clicking on a place link opens a new browser window or not
… if public places should be listed in “MyPlaces” for anonymous users
If you have special characters (e.g. German umlaut) as part of the Lotus Notes user name and are using Lotus Quickr (Domino Services) you might experience problems with the Quickr connectors.
As soon as you add a user who has a special character in his name as a Superuser of to place, all users who have access to this place will no longer see any places in their connector list.
The problem is already reported to developement.
The only currently available workaround is to give a maximum of Manager access to such users.
This again shows that it is a good recommendation not to use special characters for user names ….
If you want to be able to login into Lotus Quickr when using a Domino LDAP directory you have to add the Internet address as an additional line in the user name field of the person documents in the Domino directory. It is not sufficient to have the Internet address in the Internet address field.
If you experience a Java execption in Lotus Connections stating that you do not have enough rights when deleting an activity, adding a person to an activity or changing an activity to public or back to privat then this might be your solution:
When you log-on to Activities, it creates a JSESSIONID after successful authentication. From Activities, it calls the Profiles servlet when you deal with users (for example, when you click to view Profile, search for users when adding members), sometimes, it happens that Profiles application’s JESESSIONID overwrites the JSESSIONID of the Activities. When this happens, the logon user tied to JSESSIONID of Activities is un-identified and lost the access rights.
Please use these steps to setup JVM parameters to re-use the JSESSIONID’s between applications (these steps are documented in V1.0.2 information center)….
If you are installing Profiles with either Activities or Blogs or both, and you installed Profiles into a separate WebSphere Application Server profile from Activities and Blogs, but you plan to use the same host name for these features, you must configure the Java Virtual Machine (JVM) for Activities and Blogs on each server to reuse the session ID.
To do so, complete the following steps:
From the Integrated Solutions Console for the WebSphere Application Server hosting the features, expand Servers, and then select Application Servers.
Select the Application server hosting the Activities or Blogs feature, and then select Server Infrastructure > Java and Process Management > Process Definition > Java Virtual Machine > Custom Properties > New.
Add a new Custom Property for the JVM to reuse the session ID by entering the following values in the fields:
System Property Name: HttpSessionIdReuse
System Property Value: trueSave your changes.
Repeat these steps for the Application Server of the other feature, either Activities or Blogs, if you are installing both.
Restart WebSphere Application Server.