Leadership By Numbers

The Adminp only works on NSFs on which it has been told to change. Every ACL has an advanced setting for adding an Administration Server (also used for document locking) to the database. Go to the ACL settings, select the Advanced tab and you will see the entry for Administration Server. Only one server can be an Adminp server, otherwise it's possible that replication conflicts would occur. Guess what happens to databases on which the entry is empty? Adminp will honor the blank choice and do nothing for the database. So, the first explanation for Adminp's failure is that it is doing what it was asked to do—ignore the database.

There is a second reason for Adminp failures—the wrong Adminp server has been selected. When a database is first created on a server, the Adminp server choice will default to the name of first host server. What happens if the database is moved or replicated to another server and the original database is deleted from the original host server (or the original server is retired)? In this instance, no Adminp services will run on the database because there is no actual server to do the work. If no instance of the database exists on the server for which it has identified as its Adminp server, then, again, nothing will happen.  

The last reason that causes the Adminp to behave poorly comes by identifying the distribution of the key databases. Depending on what Adminp is accomplishing it may be working from the Domino Directory (on its own Adminp server), the Certification Log, the application database, and, of course, its own Administration Log. If everything is on a single server, then the updates can be relatively quick. What happens when all these databases are on multiple servers? Adminp updates can be slow. It may be necessary to increase the replication schedule for the Domino Directory, Administration Log and Certification Log to bring larger enterprises up to speed.

The fix: quickly identify any database with the incorrect Administration server. You might be tempted to write an agent to scour through the server directory and generate a report. Of course, the agent would have to run on every single server in the enterprise. A better solution is to work with what we already have—the catalog.

The Domino Catalog is a great administration resource. It contains a record for each database and gives out the replica ID, the complete ACL and numerous database properties (replication settings and database usage statistics). Yes, it also gives the name of the Administration server for each database. We can easily modify the catalog with a view that adds the Adminp server information. But before I explain how to modify the catalog, you should know that the catalog's capabilities require (1) that the catalog task has been recently run and (2) that every database allows an entry in the catalog. There is a database property which permits or denies creating a catalog entry (some databases are intentionally kept out of a public listing). Relying on the catalog is not a 100% solution, because it is possible that some databases are not included, but I expect 99% to be included and that's good enough reason to use it (cf. "A Final Note," below).

How to find Adminp problems:

1. Add a view to the Catalog. I'm choosing to copy from the existing"Databases\by Replica ID." From within the Designer client of the view, I can simply copy and paste the existing view to create a new view (see Caveat Emptor below).

  2. Don't open the new view, yet, but select it in the list of other views and open the properties dialog. Make sure that there is no entry for inheritance and make sure that you have selected the option to"Prohibit design refresh."

3. Open the new view and open the view property dialog to change the name to something you like (“Replica ID & Admin") and the alias (“ByReplicaIDAdmin"). And, do everyone else a favor and fill in the comment entry (something like,"Custom View to identify Admin Servers").

4. Last item, change a view column formula so that it can display the Administration Server information. I use the"File" column and alter the formula so that it includes the DbAdminServer field: @Name([CN];DbAdminServer) + " " + Pathname

You're done!

This works fine to do the job, but if you can add a little bit more to it to make it easier to read: @If(DbAdminServer ="";"NO ADMIN SVR";@UpperCase(@Name([CN];DbAdminServer))) + " " + Pathname

Finally, we can add a collation to the column. Collations are sub-indexes to the main view collection. The view already has one collation (the initial column which categorizes all the databases by the Title field). Usually, I'm cautious about adding too many sub-indexes to a view because it increases the size of the view and adds CPU processing overhead. But, the Catalog NSF is not used actively and is only updated when the CATALOG task is scheduled, so it's a reasonable addition.

Double-click on the column heading to see the appropriate column property dialog. Select the"Sorting" tab and mark the checkbox for"Click on column header to sort." This makes it possible to collapse all the documents in the view into groups of"NO ADMIN SVR" or the Administration Server.

---

A Final Note Nate Freeman (of OpenNTF.org fame) has reminded me that every database does have an entry in the Catalog.NSF, but the database property marks the catalog document so that all the views exclude any flagged databases. If you look at the selection formula for any of the views, you'll recognize that !DBListInCatalog = "0" must be the filter to conceal documents associated with databases marked to be hidden. Simply removing the statement in the selection formula will allow every database to have an entry in the Catalog.NSF. Thanks, Nate.

Caveat Emptor: My instructions work fine because I already know what to expect in the new view. If I was customizing the Catalog with a new view that I'd never before designed, I'd want to test it first. I don't want to set a bad example, so let me explain one way that I use to create a custom view in a production database.

The Designer Client builds a temporary view index for testing purposes. Obviously, if the database held thousands and thousands of documents, then previewing my work in the Designer Client would be a tedious exercise. Make a change, rebuild the test index, make another change, the index is again rebuilt—that's one reason to use a template. But, I shy away from modifying system templates (every new upgrade overwrites them).

However, you have a third choice: create a folder first and put a few sample documents in it. Now, you can modify the new folder to look the way you need. When you have completed the design of the folder, create a new view and inherit the folder design (and then delete the folder).