Symetrik Domino Consulting

A couple of days ago, I had a regional administrator in the Americas notify me that he had some users in his region that could not login to webmail. He was concerned that when the users changed their Notes client password, their HTTP password was not set (synced) in their person document.

As part of our desktop policy we have Domino setup so that every user has to change their password every 90 days, every password has to be at least 8 characters, and the Domino HTTP (Internet) password is automatically synced with the Notes password.

We also have adminp properly setup on all servers which constitutes of all servers running the adminp task, and all servers having a replica copy of admin4.nsf which replicates from the hubs to all servers. We even have a dedicated administration server that processes all administration tasks. Incidentally, this is where all of our administrators register users and make modifications to the name and address book. It also houses the Recovery Database, which is a mail-in database that all clients automatically send backups of their ID files to. Lastly, it also serves as our primary LDAP server for external systems to interact with the Domino directory.

Here is a screen shot of the password management tab of the security settings policy document to enforce the password settings.

This enforces password checking as well. You must enable password checking on all of your servers on the security tab in the server document for this to be effective. This prevents a user with an obsolete ID file with an old password from accessing your server. This compares the ID file password with the password digest that is stored in the person document.

We haven’t had any complaints or problems with the HTTP password sync or webmail access so I was a bit concerned.

I looked through all of the activity in admin4.nsf which shows when password information (password digest) was processed and when the http password was stored.

After a few hours of research, the regional administrator came back to me and said that he realized that the problem was that the users were using their shortname to login to webmail. A few months ago, we had changed the security to force them to user their full name to login. This is set in the Internet Authentication field on the security tab of the server document. It should be set as “More name variations with lower security.”

This explained why the users in question were not able to login to webmail, but my research into admin4.nsf showed alot of inconsistencies between users changing their password and that information being stored in their person document and some users http password being stored in their person document and some user not having their http password stored in their person document.

I began to wonder if there was really a problem, or if the http sync sometimes just took a little while (even a few days) to process. I would have thought that if it was really a problem that we would be hearing more complaints from users not being able to login to webmail.

I began to dig a little further and a colleague by the name of Jean-Yves Riverin and I were discussing the issue and he suggested that I check the administration server of the mailboxes of each user.

Previously, all users in our international locations had their mailboxes stored in a central cluster server and were setup to replicate their mailboxes locally.

Since that time, we have setup regional clustered mail servers and moved their mailboxes off of the centralized cluster. In doing so, their administration server was never changed. So many of the mailboxes on the international mail clusters had their administration server set to a server where the mailbox did not exist.

I went around and changed this yesterday on all mailboxes in our domain. This can be done pretty easily using the administration client. Select Multiple databases, right click ACL\Manage, and then choose the Advanced tab.

I’m not 100% sure that this will fix the problem or if there really is a problem, but it could fix a few other anomalies, such as local archiving working in some instances and not in others, or some users not being able to disable the out of office agent when they return from holiday.

When you move a database from one server to another, this should be taken care of automatically, but in our case, we created new replicas of the databases on the new servers and then later deleted them from the centralized server. It will certainly fix any modifications to the ACL of the database or other task on the database that adminp takes care of.

The moral of the story that this small configuration item could be important, especially if you move databases from time to time.

One Response to “What can go wrong when the administration server is not correct on your mailboxes.”