Single-copy template and shared mail

With disk costs being as dirt cheap as they are, does anyone feel the need to use the single-copy template or shared mail features these days? I can see where they made sense years ago when drives were smaller and more expensive, but having single points of failure is a very risky proposition and doesn't seem to be justifiable today. If you are very concerned about disk space, quotas and archiving policies are the way to go. I'd like to hear about some current success stories to balance my thinking on this. Right now I just can't think of a scenario where I'd recommend their implementation.

Occam's razor and administration

"Entities should not be multiplied unnecessarily."

This most famous of logical principles is often paraphrased as "all things being equal, the simplest solution is the best one," and it is sage advice in all aspects of life, including Domino administration.

An issue was brought to my attention this week of a customer who wanted advice on how to configure a three-server environment consisting of one organization and three domains. While this is certainly feasible and may make sense for this particular customer, it seems to me that the majority of organizations would not benefit from such a configuration. Instead of a single directory that could house all users, groups, and configuration documents, this strategy requires an administrator to maintain three separate primary directories and use Directory Assistance to interconnect them.

There's nothing inherently wrong with this scenario, but it is unlikely to provide enough benefit to the average three-server organization to outweigh the additional complexity and maintenance overhead. Keep it simple.

Removing notes.ini parameters from the console

When troubleshooting a Domino problem, you will often enable one or more debugging parameters in the notes.ini file. When the issue is resolved, you could disable the parameter using the "set config" command to set it equal to zero, but what if you like to keep a tidy configuration file and want to remove it entirely? To do this without leaving the comfort of the remote console, simply use "set config" without specifying a value. For example, the command "set config debug_threadid=" will both disable the debug_threadid variable and remove it from notes.ini.

Controlling the size of admin4.nsf

I frequently receive copies of customers' admin4.nsf databases in the course of diagnosing various AdminP issues. One thing that really stands out is the number of documents in an admin4.nsf from a large environment. Some of this data is necessary for AdminP to function. However, a large chunk of it is not. Documents that have already been processed successfully by AdminP become little more than a log entry. Some documents are not even required by all servers. Here are some basic steps that can trim the document count significantly:

1. Use a sensible document retention period. This is configured by the "Remove documents not modified in the last N days" replication setting. By default this is enabled for admin4.nsf and is set to 7 days. I recommend keeping the default unless you have an overriding need to maintain documents for longer periods of time. If you do increase this, keep it reasonable. AdminP generates many documents, and you will end up with some serious bloat if this option is set inappropriately.

2. Do not store no-change log entries. This is the "Store Admin Process log entries when status of no change is recorded" field on the server document's Server Tasks -> Administration Process tab. If enabled, this option will cause AdminP to store log entries for all servers involved with a request--whether or not that server actually has databases to process. Unless you can't resist being notified that a server had no work to perform, it's best to leave this set to No to prevent such documents from being stored.

The two options above are best practices in any Domino environment and should go a long way toward cutting down on the document count in admin4.nsf. However, if you are still fighting the battle of the bulge, a third option exists. This is more risky and should be done with great care and ample testing.

3. Implement a selective replication formula for admin4.nsf. Strictly speaking, a server really only needs the documents that it is supposed to process. However, you need to take the replication topology into account as well. A spoke server can only receive a document if the hub receives it as well. Thus a spoke server would have a replication formula that limits its replica to two types of documents: those intended for that spoke server alone and those intended for all servers in the domain. A hub server would use a modified version of that same formula that also includes documents intended for any spoke server it services. The administration server should have no formula enabled. In case it was not clear above, test such a strategy thoroughly before implementation.

By using the techniques presented here, you should be able to cut down dramatically on the size of your admin4.nsf databases without sacrificing any AdminP functionality.

Introduction

My name is Chad Scott, and I am a software engineer with IBM's Lotus brand. My primary role is providing technical support for the core features of the Domino server product. The purpose of this blog is to discuss techniques for improving the performance and reliability of Domino environments. While the ideas conveyed here are based on real-world customer scenarios, they are my own and should not be confused with an official IBM opinion.