IBM Lotus Domino is a great product but it has persistent flaws that make you eventually lose patience with it. Here are a few examples. I cannot see why IBM have allowed these flaws to persist, but I can see a common trait – a refusal to accept Microsoft-led standards.
This is not a review of Exchange against Domino. Another review would be entirely superfluous. Instead I am looking at a few things that make Domino unnecessarily difficult to use, and may eventually lead people to give up on it.
Exchange is an ugly product to administer. Its architecture is derived from assembling different components – Windows NT SAM, now Active Directory; MS SQL Server; IIS; Exchange; and MS Office Outlook. So Domino should be in a good position.
Lotus Domino is in many ways a great product. It was one of the first to have a full set of internet protocols so if you preferred you could just connect it to a standard mail client and use LDAP, IMAP and SMTP. We did this for an international rollout where some of the small offices had no need for Outlook, shared calendars etc. It is also internally secure. You can put a Domino server in the DMZ and connect to it over the web or from the LAN. In a remote office you just need to set up one server with Domino, not Exchange, IIS, Active Directory and SQL.
However to use the Groupware features (like shared calendars) you need to use a Lotus Notes client. You could use the web client but it’s not the same. A web client does not stay open on the desk and ping you when you have a meeting coming up. The client is where the problems arise.
First, it’s ugly. Nothing is where you expect it to be. I have used it for years and still can’t find the Change Password routine. When I do find it, I need to go though several steps before it is changed. I am sure there are answers to all of these problems, but they depend on people being trained and skilled in the Notes client. It is not intuitive. The Help is hopeless. I could just use an Outlook or Thunderbird client with the internet protocols, but then no groupware.
The Notes client depends on an ini file to control the user settings. You need first to select the multi-user install option, then you can save an ini file for each user in their Windows profile. That’s handy, as with a roaming profile the user settings can be the same across different machines. But there is a problem. The ini file contains the path to the user’s ID file, the file that contains the certificate that identifies the user when unlocked by a password. The ID file is supposed to be stored locally. You can not store the ID file in each user’s My Documents folder, because Lotus Notes does not recognize the path, which is a logical not physical path. Therefore you can’t actually roam, because you can’t get your ID file. You could keep one central copy on the network, and copy it down to each machine, but when you change password it is changed in the ID file and you would have ID files scattered around with different passwords. You could just store the ID file on the network, although you would have to have a mapped drive, but this is not supported by Lotus. At least, it used not to be supported, with the explanation that the Notes client is not network-aware, but you would have a hard time researching this on the Lotus website. Just try a search and see what I mean.
You may decide that you would like instead to use Outlook as the client for Domino. Lotus make a plug in for this purpose, the Domino Access for Microsoft Outlook (DAMO) client. That’s handy. We could just roll out the DAMO client and have people use their familiar Outlook to connect to Domino. But there’s a problem. You can’t automate the rollout as it is not really a multi-user product. This takes a bit of explaining, but the basic conclusion is that IBM either don’t know or don’t care how to make software run effectively on the Window platform.
The DAMO client comes as an exe that installs DAMO and sets up the user mail profile. You can’t use this directly as it requires admin rights and would not set up a mail profile for each user when they log on. IBM do not document or publish a Windows Installer msi. However the product clearly is an msi, so you can disassemble it to obtain: the msi; and the separate profile setup routine. In the msi you can select a multi-user option. However this one is not multi-user in the normal sense. It is multi-user in a special IBM-only sense, multiple users sharing the same logon. It is not even the same sense as the Notes client multi-user install. All it does is to put each user’s data directory in a different path. By digging around we find that LAUNCHDFOSETUP=0 will disable setting up the user profile, so if we run the msi with this switch, we could install the product for all users, and then let them set up their profile when they first run it. A few other minor details:
- For some reason we also need to run ONLYCURRENT=1
- You can add single sign-on by setting the install level of this feature to 101. It is the opposite way to any other msi, as normally features install if the level is below a figure (say 100). In this case it is above, but now nothing surprises us about IBM.
So we are all set. The user runs the profile setup part after the install and Outlook is set up for them. But it turns out not to work unless they have local administrator rights. That’s odd, as by definition we are carrying out only the user portion of the setup. It turns out that the per-user install writes files to the Program Files directory. That’s OK, we can work around that by changing the rights on that directory only. But it still does not work. We watch it carefully and find that the per-user portion of the setup installs files in the System directory, where we can not give users rights, and makes numerous registry per-machine entries. So starting with the best intentions and applying a great deal of expertise to an undocumented product, we finally admit defeat. It turns out that running Outlook before you set up the DAMO profile breaks it anyway, so we would have had to send an engineer to the desk for each installation. Basically, IBM have deeply engineered it in such a way that it can not work in a standard corporate environment. How did they come to do that?