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.