The Domino directory, (a.k.a. NAB, a.k.a names.nsf) contains
configuration documents for servers and people. They store details on these
resources registered within the Lotus Domino environment. A large part of the
content of the Domino Directory can be made available via the Domino LDAP task
which makes that data available to clients over the LDAP protocol.
people contain information such as the user’s name, her email address and
telephone numbers (if set), as well as the distinguished name (DN) of the
user’s primary server and the name of the user’s mail file. A shortened LDIF
output for user jdoe could produce the following:
Note how the name of the mail server is in the mailserver attribute type.
Similarly, the path to the user’s mail file in the mailfile attribute type.
The Domino directory also makes information about servers available via LDAP.
If we query the same directory for the server’s DN, we can glean some more
I’ve shortened this server entry very much; there is half a ton of other
interesting data to be read for your servers, if you do an authenticated LDAP
search on your Domino directory.
By combining the hostname contained in the
smtpfullhostdomain attribute type with the mailfile attribute type, we get
a path to the user’s mailfile. This path can easily be used to construct an
HTTP URL to the user’s mail file, if I ensure that the filename ends in
By now you’ll be thinking: “so? Big deal”. It isn’t a big deal really,
but it is quite interesting, because this shows that an authenticated query or
two to the Domino directory can devulge information that we’ll use to access
the user’s mail file.
But what about the replicas? In a clustered Lotus Domino
environment, the administrator will have created at least another replica of
the user’s mail file so that the Lotus Notes clients can fail over to these
replicas in the event the primary home server goes South. If that does happen,
there is no easy way to determine the hostname of the user’s replica host.
Unfortunately, the name(s) of the replica servers are not published via the
Domino Directory. Enter cldbdir.nsf.
The cldbdir.nsf database on Lotus
Domino is the Lotus Domino Cluster Database Directory, which is managed and
maintained by the Cluster Database Directory Manager. Its use is well
documented, but in escense it contains documents describing which
databases in a Domino cluster have replicas on which servers. So, if a
user named joe has a mail file on server domin and its replica on
jp510m, and both those servers are in a cluster, the cldbdir.nsf will
contain two documents with the common names of those servers and the pathnames
of the databases.
This information is normally only used by
the cluster manager for failover of a mail file from one server to another,
but I want access to that data in order to determine the names of the replica
IMHO, the fastest wat to get a dump of the cluster manager database
directory is with a Lotus Notes C API program, which I’m presenting here,
although a LotusScript agent or a Java agent might be alternatives. The
program as it stands will have to be run on one server per cluster because it
accesses the cluster-specific cldbdir.nsf.
The processing is as follows:
opens the Domino Directory names.nsf and the Cluster Database Directory
cldbdir.nsf. It starts off by preloading a list of all servers defined in
the Domino directory (servername) with their DNS names (smtpfullhostname)
into a map. This list is later used as a fast cache, utilizing my
wrapper for MapKit.
The program then searches for all people in the
Domino Directory with the specified selection formula (Form = "Person"). For
each found person in the directory, the enumpeople() function is invoked to
process the person document.
enumpeople() opens the person document and
extracts the user’s mailfile (mail/jdoe.nsf) and mailserver (i.e. home
server). With the information of the mailfile and home server, a lookup is
performed in the cldbdir.nsf to find the server names of the replica
servers. If this information cannot be determined (probably because this
person has no replica on this server), the person is ignored, and the next
document from the NAB is processed, until there are no further documents to
Do note once again, that cldbdir.nsf contains replicas in the
current cluster; that is the reason for which the program must be run on one
partner of each cluster, in order to determine the information for all users
of the domain.
If a user read from the Domino directory has mailfile replicas
on this cluster (as determined by the current cldbdir.nsf, an entry for
this user is created in the output file. This entry consists of a comma-
separated list of shortname(s), the path to the user’s mail file, and a list
of the DNS domain names for the user’s mail server replicas. These three
entities are semicolon-separated.
User jdoe has three short names in the Domino Directory. His mail file is
named mail/jdoe.nsf (the backslashes typical on Windows have been
normalized) and there is a replica on both servers domin and jp510m. User
john has a single shortname and also has a replica on two servers, the
second one is marked as na (not available) because the server document holds
no smtpfullhostdomain field.
At this point it is important to realize that
the information might not be complete. If a user has a replica of her mail
file on a server distant to this cluster, the information will not be
contained in the output. Furthermore, the “formula” depends on the paths to
the user’s mail files being identical on each and every server in the cluster
(IMHO there is no valid reason not to adhere to that convention).
The resulting output contains information about the users on the cluster the
program is run on. I’ll be storing this information in a relational database
(RDBMS) for easy and fast access and later copying the data into custom made
LDAP attribute types of an LDAP directory. This trivial task is left as an
excercise to the reader (hint: use Perl).
In a subsequent article, I will
be discussing how I use the data gathered by replinfo to build a resilient
jump to database.