The fix and installation instructions can be found at IBM Fix Central.

Bookmark:

Not everyone seems to be affected by this bug, but if you are, all week numbers in Notes are one week ahead. It’s easy to check: just go to January 1st on your calendar in Notes. It should say “week 53 – 0 weeks left in year” at the botom. If it doesn’t, you are probably affected.

IBM supplies the following workaround: in the Notes client, go to File -> Preferences. In there, go to Calendar and To Do -> Regional Settings and look for the “Week Numbers” section. Set this to “Always use the ISO standard” and the week numbers should be fine. You can also do this via a notes.ini setting:

FooterWeekNo=2

It’s not a showstopper bug, but it can be irritating.

Bookmark:

After this, the Domino service just stopped. A technote from IBM explained that this problem was caused by two files: Domino8.lic and nodelock. I checked the data directory and those files were present. The technote suggested to reinstall the Domino server, but I wanted to avoid that.
I started looking around in the Windows registry and discovered that there are two references to the data directory in there. Of course, these were still pointing to the old location. After changing these registry keys to the new location, I could start the server again without any problems.

The keys can be found in:
HKEY_LOCAL_MACHINE\SOFTWARE\Lotus\Domino\
and
HKEY_LOCAL_MACHINE\SOFTWARE\Lotus\Domino\1

The name of the key is:
DataPath

Just edit the values and fill in the new path of the Domino directory.

PS: If, for some reason, you don’t want to change the registry, you can also recreate the data directory at it’s old location. Then copy the two files (Domino8.lic and nodelock) to that directory and you will be able to start the server. All other data can stay at the new location. But I prefer to just change the registry.

Bookmark:

Some of the users on the Foundations server had to be upgraded to roaming users (Notes roaming). It took me quite a while before this actually worked. When I upgraded an existing user on the Enterprise server to roaming, it worked within ten minutes. But when I did the same for a user on the Foundations server, it always ended up in tears (aka: not working).

After some searching and digging on the web, I finally found a solution. For some reason, roaming just wouldn’t work if the files were  on the Foundations server itself. When I put them on the Enterprise server, everything seemed to work. Putting the roaming files on the Enterprise server will ofcourse cause a longer startup time if the user logs on for the first time, as the Enterprise server is probably off-site.

So in short:
You have to upgrade the user to roaming on the Enterprise server, select the Enterprise server as the roaming server, and then replicate this to the Foundations server (that, in combination with a few “tell adminp process new” commands).
By default, if you upgrade a user to roaming, it selects the mailserver of that user as the roaming server. So be sure to change this for a user on Foundations to the Enterprise server!

Bookmark:

Setting up an Subversion server is fairly easy. On most Linux distributions, you can install it via the packet manager that comes equipped with it. At our company, we run Subversion on CentOS with Apache.

For added security, we require users to authenticate if they want to access the repositories. You can add these users manually with htaccess files, but why do that if you already have all the users listed in the Domino directory? Having multiple user accounts for the same user, scattered over different server, only makes things more complex. So I decided to extract them from our Domino server via LDAP.

To add authentication, I added the following paramters in the configuration of Apache.
First, specify that you want to use LDAP for authentication:

AuthBasicProvider ldap
AuthType Basic
AuthzLDAPAuthoritative off
AuthName “SVN”
require valid-user

AuthBasicProvider ldap and AuthType Basic will tell Apache/Subversion to use LDAP for authentication. With AuthzLDAPAuthoritative off, you tell Apache that LDAP does not decide who has access and who doesn’t. In our case, LDAP just has to pass user information. AuthName is just a title for the login popup. require valid-user speaks for itself I think.

Next, we come to the actual connection. This has to be built up like this:

AuthLDAPUrl “ldap://hostname:port/basedn?attribute?scope?filter” NONE

basedn defines where you want to search in LDAP. attribute is what will match the username  to what the user types in the login popup. scope tells LDAP how deep it has to search in the directory. Put this on “sub” so it will search the entire tree. Finally,  filter defines what objects should be returned. Put this on “(objectClass=*)” to return all objects.

On our server the URL looks like this:

AuthLDAPUrl “ldap://ldap.groupwave.be:389/O=GroupWave?CN?sub?(objectClass=*)” NONE

To find the correct URL for your server, I suggest you use an LDAP browser tool like Softerra LDAP Browser. Getting the URL right by trial and error in Apache, can be a very tiresome job.

These extra parameters should be enough to add Domino LDAP authentication to your Subversion server.

Bookmark:

We access our iNotes webmail through a reverse proxy. This reverse proxy is an Apache webserver. To add to this security, all http traffic is redirected to https for obvious reasons. This means that there has to be an SSL certificate on the reverse proxy for that website. But Lotus Domino stores its certificates in keyring files (.kyr extension), which cannot be read by Apache. I had to export the keyring file to a certificate file (.cert) and key file (.key) for Apache.

After searching around a bit, I quickly realised that this wouldn’t be as easy as I initially hoped. There is no built-in feature in Domino to export keyring files to any other format. Even opening the file turned out to be quite a challenge.
After some more searching, I came across a handy little tool from IBM called “iKeyman” (link). This tool is part of IBM HTTP Server and WebSphere. With it, you can open and export keyring files created by Domino. If you don’t have IBM HTTP Server or WebSphere, you can download this utility here.

If you start the tool, you can open the keyring file (you will have to know the password), and then select “Export/import” on the right side.

After that, I stumbled upon the next problem: you can only export to PKCS12 or CMS. These aren’t usable for Apache either, but it’s a start. I exported the file to the PKCS12 format, wich gave me a .p12-file. This file, I could then export to the format I needed with OpenSSL (link). OpenSSL is available for Windows and Linux. I used the following commands on a Linux machine:

openssl pkcs12 -in host.domain.p12 -clcerts -nokeys -out host.domain.cert
openssl pkcs12 -in host.domain.p12 -nocerts -nodes -out host.domain.key

This finally gave me the right files I could load in the Apache configuration.

Bookmark: