Some lessons learnt from installs this week:
- Before starting a Lotus installer on Windows, particularly Quickr/Domino and Connections, check your %TEMP% and %TMP% variables within Control Panel/System/Advance/Environment Variables. Ensure they are short as possible, e.g. c:temp rather than c:Documents and SettingsuserLocal SettingsTemp. Why? The directory structures that Lotus uses for the installers are pretty long and very descriptive, and if your %TEMP% and %TMP% are not short you will run into the limits that Windows places on paths. In my experience, you’ll get a pretty odd error, certainly there is no error trap built into the installer.
- Don’t let your Windows OS Admins build environments with tiny C: drives and all applications on other partitions. In one case this week, the C: drive had been built as just a 4GB partition, with Program Files etc on the D: drive. This can cause huge problems with well behaved apps, let alone those that have hard coded (or assumed) direct paths. One example of this is the TDI upgrade installer shipped with the TDI component of Lotus Connections, which has hard-coded ‘C:Program Files’ paths. Secondly, you always run the risk of production servers taking a dive just because an application installs additional drivers/DLLs etc. into c:Windows. Don’t do it!
- Be careful using non-standard ports. Whilst it can be a good idea to change ports from their standards for security reasons, particularly on Internet-facing servers, it does cause issues when debugging difficult problems. In particular, it can lead to (reasonable) requests from IBM Support to test the issue against the standard port in order to reproduce the problem. This can add several hours or even days to the problem determination process. If the application is solely on an internal network then I would argue that this risk is greater than the security benefit to be seen from the port change.
- Even when it seems a crazy restriction, stick to the stated supported versions of 3rd party products. I had a very odd issue with Lotus Connections 2.0 connected to an MS SQL backend, where the installer would quit with a rather bizarre error message:
After extensive debugging and some assistance from the IBM Support team, it turned out to be down to the version of the SQL Server JDBC driver. We had installed 1.2 (the latest version for SQL Server 2005 – shipped February 2008) which was recommended by Microsoft for performance and security reasons, whereas after searching in the Infocenter IBM seems to recommend 1.1 (shipped September 2007). After rolling back to the 1.1 version, the issue disappeared and Connections installed fine. Lessons learnt are to stick to the versions that IBM (and other vendors) state as being supported even for small modules such as JDBC drivers. Secondly (and this goes for the issue above with %TEMP% paths as well), we could do with the Installer doing more in the way of error-checking and trapping…
It has been an interesting week!
