Weblog
17/2: Setting up Domino to work with IIS
For companies that use Windows and IE, IIS simplifies the authentication of web users with integrated Windows authentication. When integrated with Domino, this means that web users do not need a separate web password. This clearly has big administration advantages.Unfortunately, the instructions in the help have been plagued with mistakes both at version 5 and version 6.x. I wanted to post some instructions here that correct those mistakes and make it easier for others. If there are any mistakes here then please let me know!
When upgrading a domino server from version 5 to version 6 (or 7), there is a big change in the way the integration works. At version 5, IIS served the web pages and you didn't require the HTTP process to be loaded within Domino. At version 6, both IIS and Domino serve web pages and there is a plugin required for IIS so that it knows which URLs to send across to Domino and which to serve itself. For example, you would want any URLs containing ".NSF" to be passed to Domino but any containing ".ASP" would need to be served by the IIS server.
If the two servers are running on the same box, the two HTTP processes must be configured to use different port numbers. Usually the default port 80 would be assigned to the IIS server and another port chosen for the Domino HTTP task. If IIS and Domino are on different servers then you can choose to keep the ports the same if you wish.
Here is the official Lotus help with errors fixed.
[Update 6th May 2006: Another useful document here describes how HTTP threads are queued by the HTTP task in Domino (changed between versions 5 and 6) and the new NOTES.INI setting at version 6.5.5 that enables you to change it.]
Author: Rob Wills Categories: Domino
1. Rob Wills wrote:
This is a reminder to myself in case I need the information again in a hurry. One of my clients recently upgraded their Domino Web Server from 6.03 to 6.5.5. The main driver for this was in order to go back to the R5 style HTTP thread queueing system i.e. (for those in the UK at any rate) queueing like in the post office instead of Tescos.
This is described here.
They have been having problems with an agent that uses the UniObjects libraries to access IBM's UniVerse product. The agents work great the first time but never the second. Although the agent is very careful to Disconnect and set the objects used to Nothing, it seems there may still be a memory leak or something which is sufficient to prevent that HTTP thread being usable next time round. So if you happen to be queued up behind that agent, it is akin to the Tescos check out girl finishing her shift without anyone to take over.
Make sure that any NOTES.INI settings don't get lost. Our Administrator started with a new NOTES.INI which lost our HTTPEnableConnectorHeaders=1 setting. This has now been added into the Configuration document in the Directory database and I have added the HTTPQueueMethod=2 setting in there too.
Whilst I was busy trawling the Forum to figure out what had gone wrong, I stumbled on this page here which shows the latest WAS plugin releases and the associated fix list. It appears that a few people have been having problems with spaces and other characters in the URLs that have been fixed.