Today’s fun with ILDDM

April 9 2007

Today I got to go back in and deal with issues with a customer application that utilizes ILDDM, or Domino.Doc to you old school Notes folks. I did some big time integration between our enTouch.workflow and enTouch.project products with ILDDM last year. Everything is working great from the Notes client and from the Document Manager Enabler. On the web, editing a document stopped working. So I had to figure out what was wrong.

Since I had done major customizations in the Library and File Cabinet templates, I decided to roll back the customizations and start from a clean base. I created a new Library with the default templates that ship with base product. Still, no editing of documents on the web. I turned to the Domino server, and did things such as turned of Session Authentication and other stuff that I thought could complicate the issue. Today, since I was not making progress on my own, I called IBM Support. Harold @ IBM helped me walk thru the issues. We turned on verbose logging in the Desktop Enabler ... doing just one action on the web generated 180 pages of text!

We found the issues and fixed it, and here is what I can share with you ...

  1. ILDDM REQUIRES that the "Domino.Doc Site Administrators" group, with the id that signed the ILDDM templates, be listed specifically in the Unrestricted Agents and Restricted Agents fields on the Security tab on the Domino Server document. You could also have the id that signed the templates specifically in those fields. You can not use */domain or some other shortcut in those fields. It turns out that the ILDDM web process has the agent check the server document to see if the agent signer has the correct rights. That check is doing some kind of @user comparison with the agent signer and that field.
  2. You have to be careful with Session Authentication. It seems when I switched the value back to disabled, something was set incorrectly with the Domino Server and ILDDM. It was doing Single-Sign On verification even thought the field value was set to not do that. Once I set it back to Multiserver SSO, selected the right token, and restarted HTTP, that started working correctly
  3. It seems that ILDDM stores the HTTP Host Name internally. If you rename the host name of the Domino Server, you have to reset that value in ILDDM. The bad news is there is no easy way to do that. Performing the documented ILDDM Server move resets this value, but there is no way to do that if you keep the Domino server the same. Watch out for that.

So, it seems all is well. The customer is testing to confirm this solved the problem completely and I get to focus on other things. Nice way to start out the week :-)