All about AdminP Part 2

by Timothy Speed
with Paul Raymond

Level: Intermediate
Works with: Notes/Domino
Updated: 01-Jul-2003

In last month's issue of LDD Today, we ran Part 1 of our detailed tour of the Domino Administration Process (known universally as AdminP). In that article, we introduced AdminP, discussing its components and explaining proxy actions and the Administration Requests database. Our early feedback indicates a number of readers have already found this information very useful.

In Part 2 of this article series, we conclude our examination of AdminP. This includes cross domain administration requests and how to control AdminP functions through Server document settings, server console commands, the Notes.ini file, and database purge intervals. This article assumes that you're an experienced Domino administrator and have read Part 1 of this series.

Cross domain administration requests
You can use AdminP to initiate and run an administration request from one Domino domain and then to send that request to another Domino domain. In the following diagram, you see that a request has been generated in the Notes domain and then sent to the Lotus domain.

Cross domain administration requests

To set up AdminP to handle cross domain requests:

Create an email connection document between domains.
Issue cross certificates (as needed).
Verify that you have a mail-in database named Administration Requests.
Create the Cross Domain Request Configuration documents in the Administration Requests database, containing the required outbound and inbound cross domain settings.

After you've set up AdminP to process cross domain requests, you can send the following requests from one domain to another:

Delete a person or server in the Domino Directory
Rename a server in the Domino Directory (that is, upgrade the server name from flat to hierarchical)
Rename a person in the Domino Directory
Create a replica
Get replica information for deletion (this request is generated when you delete a database and its replicas)

After this process has been set up, it runs automatically and over email. But first you must create the Cross Domain Request Configuration documents.

Cross Domain Request Configuration documents
The Cross Domain Request Configuration documents control how a domain exchanges and processes administration requests. Cross Domain Request Configuration documents are stored in the Administration Requests database (Admin4.nsf):

Cross Domain Request Configuration document - Configuration Type tab

You must create documents containing configuration information for both inbound and outbound requests, as described in the following sections.

Outbound request configuration
If you select Outbound in the Configuration Type tab, the Outbound Request Configuration tab appears:

Cross Domain Request Configuration document - Outbound Request Configuration tab

Cross Domain Request Configuration document - Outbound Request Configuration tab

To create an outbound request, complete the following fields:

Field name	Enter the following
Domains to submit AdminP requests to	Enter the names of the domains you want to send the requests to.
List of AdminP requests to submit	Select the requests that this server will send to the target domains: Create replica Delete person in Address Book Delete server in Address Book Get replica information for deletion Rename person in Address Book Rename server in Address Book
Only submit Create Replica requests to the domains listed above if the destination server is one of the following	Enter the server names that this outbound domain will send Create replica requests to. Also be sure to enter the target domain name.
List of approved signers	Enter a list of approved signers who will act as trusted signers for each request.

Inbound request configuration
Next, set inbound configuration information on the server that will receive the cross domain AdminP requests. Start by selecting Inbound in the Configuration Type tab. This displays the Inbound Request Configuration tab:

Cross Domain Request Configuration document - Inbound Request Configuration tab

Cross Domain Request Configuration document - Inbound Request Configuration tab

The Inbound Request Configuration tab consists of the following:

Field name	Enter the following
Receive AdminP requests from domains	Enter the names of the domains from which this server will receive requests.
List of AdminP requests allowed from other domains	Select the requests that this server will accept from other domains: Create replica Delete person in Address Book Delete server in Address Book Get replica information for deletion Rename person in Address Book Rename server in Address Book
Only allow Create Replica requests if intended for one of the following servers	Enter the server names in your current domain that will accept Create replica requests from other domains.
List of approved signers	Enter the names of each approved signer. This is a very important setting because inbound requests are rejected if they are not signed by a trusted signer.

Managing AdminP
There are several methods you can use to manage AdminP. These include:

Server document settings
Database purge intervals
Notes.ini variables
Server console commands

We discuss each of these methods in the following sections.

Server document settings
The Server document in the Domino Directory stores most AdminP settings for each server. You must update this information for every server in your domain. To display this information, open the Server document and select the Administration Process tab:

Server document - Administration Process tab

Server document - Administration Process tab

The following table lists each Administration Process setting.

Field name	Enter the following
Maximum number of threads	Enter the number of threads (tasks) that will execute on any one server. You can type show tasks at the server console to see the number of tasks loaded.
Interval	Enter the number of minutes that pass between the processing of name change requests. The default is 60 minutes.
Execute once a day requests at	Specify a time when an update to a Person document is executed by AdminP. Also this impacts when a "Rename person in unread lists" action executes. The default is 12 AM.
Interval between purging mail file and deleting when using object store	Enter the number of days to delay deletion of a mail file that uses shared mail. The delay you specify gives the Object Collect task time to purge any obsolete messages associated with the mail file from the shared mail database. The default is 14 days.
Start executing on	Specify the day of the week on which updates to Authors and Readers fields in a database and discovery of shared and private design elements for a deleted person occur. The default is Sunday.
Start executing at	Specify the time of day when updates to Authors and Readers fields in a database and discovery of shared and private design elements for a deleted person occur. The default is 12 AM.
Mail file moves expire after	Enter the number of days during which the Notes client will update mail-related changes. Valid values are 7 through 60; the default is 21 days.
Store Admin Process log entries when status of no change is recorded	Determines whether or not "no change" entries are logged. This is a very interesting setting. When you first use AdminP, you should leave this value set to Yes. This will generate a set of logs that can provide some status information about various AdminP activities that you are executing. The downside is this can create a large number of documents. So after you have experience with AdminP, we recommend setting this value to No. This will save disk space and replication time. Also if you are performing a large rename, this can help avoid replication conflicts.
Suspend Admin Process at Restart Admin Process at	Specify the daily start and end times for time interval during which AdminP is suspended. Suppose you have a very busy server from the hours of 9 AM to 3 PM every day. You can use these settings to suspend the AdminP during this period. This may save system resources. By default, these fields are empty, meaning AdminP is not suspended.

Notes.ini variables
When AdminP was first introduced into Notes/Domino, the primary method of controlling it was through Notes.ini settings. In Domino 6, the Server document contains most of this configuration information formerly controlled through Notes.ini. However, for those of you whose environments still include earlier releases of Domino, we'll briefly mention some of these Notes.ini settings. (Keep in mind Professor INI's warning that you should always exercise great caution when modifying Notes.ini variables, especially undocumented ones that could change from one Notes/Domino release to the next.)

AdminPInterval
This variable is no longer used in Domino 6. The Interval field in the Server document controls this function.
AdminpModifyPersonDocumentsAt
This is another variable no longer used in Domino 6. The Server document controls this function via the "Execute once a day requests at" field.
AdminP_Disable_Move_Mail_Connectivity
This variable is included in Domino R5.0.10 and later. By default, the Notes client tries to connect to the Administration server of the Domino Directory for a Move Mail File function. If it cannot, it posts a warning, but continues. To prevent the client from attempting to connect, add AdminP_Disable_Move_Mail_Connectivity=1 to the server's Notes.ini file.
Debug_AdminP and Debug_Outfile
Set Debug_AdminP=1 to instruct AdminP to record its schedule information every time the schedule is updated. This information is then stored in the file specified by the Debug_Outfile variable. (Note these are undocumented variables intended primarily for troubleshooting and should only be used when advised to do so by Lotus Support.)
Name_Change_Expiration_Days
As of R5.0.2, this variable is no longer used. When the name change is initiated, the Person document is updated to include the new name and is marked Change request: pending on the Administration tab. The period of time that the Person document remains with the pending status is determined at the time the change is made and cannot be changed later. In R5.0.2 and later, a dialog box is provided that allows you to add this line or to modify its value with each name change. In other words, once changed, it will "remember" the last value that client used.

Database purge intervals
As with other Domino databases, the Administration Requests database lets you set the purge interval to limit the number of documents it contains. The purge interval has a double role. It purges documents based on the value set (if the checkbox is selected). This value also controls the purge interval for the purging of deletion stubs. Deletion stubs are markers that remain from deleted documents so that Domino knows to delete documents in other replicas of the Administration Requests database. Deletion stubs consume disk space; Domino removes deletion stubs regularly based upon the purge interval. The interval for removing deletion stubs is set to one-third the purge interval. For example, if the purge interval is set to 90, then the deletion stubs are removed every 30 days. This process is managed by the Updall task, which runs by default at 2:00 AM.

To run a lean environment, you may be tempted to set the purge interval on the Administration Requests database to a short interval such as five days. This may work in your environment, but let's look at some of the potential impact from this change. First, look at the replication schedule for your environment. Make sure that the Administration Requests database has a replication schedule to and from every server in the domain. A hub and tree spoke model works fine—documents are created in both the primary Administration server as well as the spokes. So make sure you can replicate back up the tree. Also, some AdminP proxy actions may not execute immediately, for example, Update to Reader fields (proxy action 20). By default, these actions execute on Sunday at 12:00 AM. So if you set the purge interval too small, the server may delete the requested action before it has an opportunity to execute.

Replication Settings for Administration Requests dialog box

Replication Settings for Administration Requests dialog box

AdminP console commands
There are a number of powerful AdminP commands that can be executed at the Domino server console. Here are a few:

Command	Command timing or request type	Result
Tell Adminp Process All	Internal, daily, and delayed requests	This is the "do it all and do it now" command. This command processes all new and modified requests. Be careful with this command—you may execute commands when you don't want them to execute, for example, delayed requests.
Tell Adminp Process Daily	Daily requests	Processes all new and modified daily requests that are queued to update the Person documents in the Domino Directory. This command will also process any outstanding Rename Person in Unread List requests.
Tell Adminp Show Databases	N/A	Displays information about the AdminP process and the databases that will be processed. Including: Databases that an assigned server will update Databases that don't have an AdminP server assigned
Tell Adminp Process Interval	Interval requests	Processes all requests normally processed via the Interval setting in the Server document.
Tell Adminp Process New	New requests	Processes all new requests.
Tell Adminp Process People	New and modified requests	Processes all new and modified requests to update Person documents in the Domino Directory.
Tell Adminp Process Delayed	Delayed requests	Processes all new and modified delayed requests. The Server document normally controls when delayed requests are executed. Look at the Start executing on and Start executing at settings in the Server document.
Tell Adminp Quit	N/A	Shuts down AdminP on a server.

For more information on these and all other Domino server commands, see the Domino Administrator Help.

Moving a user from one hierarchy to another
This is the most complex task that AdminP executes. In this case, the user is moved from one O (or OU) level certifier to another certifier. AdminP executes no less than seven different proxy actions as part of this process. This procedure includes the following basic steps:

Start the process by requesting a new name from the server console or in the Domino Directory.
Approve the action in the Administration Requests database.
AdminP executes the request.
The user receives a prompt (optional with a Notes 6 client) to accept a new name. This updates the user.id file.
AdminP updates the name in the Domino Directory (all entries, including group names).
AdminP updates the name in various database ACLs, mail profile, and Reader and Author fields.
AdminP may also update the name in the free time database and update calendar entries.

Updates to private design elements
One of the most powerful AdminP features found in R5.0.5 and later is the ability to update private design elements (agents, views, and folders). In earlier releases, when a user name expired due to a name change, that user lost access to any private design elements he created because these still contained the user's old name. In R5.0.5, AdminP replaces the old name with the new, allowing users to access those design elements.

The process required to update user names depends on whether all Notes clients in your environment are running R5.0.5 or later or some users are running earlier releases of Notes.

All clients running Domino R5.0.5 or later
AdminP can send the user an email containing database links for the databases in which the user has private design elements. Opening the databases via the database links updates the fields with the user's new name. No other action is required. The agent that generates these automatic emails is called the AdminP Mail Notification agent. To enable the AdminP Mail Notification agent:

From the Domino Administrator R5.0.5, open the Administration Request database.
Open Rename user request. The Administrator Process Log for the request appears.
Choose Actions - Enable/Disable User Notification. The following message appears: "Notification is now enabled. Users will receive email notification about Notes databases in which they created or modified design elements such as folders or views."
Click OK.

Note that if you are using a Domino R5.0.5 server and have at least one R5.0.5 Notes client, you can still use the agent by having users open their databases via the R5.0.5 client as described previously. If they open and close their databases with an R5.0.5 client, you do not have to perform the following procedure for users who do not have R5.0.5 clients.

All clients not running Domino R5.0.5
Do the following:

From the Domino Administrator R5.0.5, open the Administration Request database.
Open Rename user request. The Administration Process Log for the request displays. Take note of the information in these fields:
- Old name
- New name
- Private Agents belonging to this user
- Shared Agents belonging to this user
- Private Views belonging to this user
- Private Folders belonging to this user
Send an email to each user listing each database (with the server name) that contains a private design element and that needs updating due to a user rename. The user must open the Domino Designer, open the item, and then save and close the item. This updates the private design elements.

Conclusion
This concludes our detailed look at the features of AdminP. We've introduced you to all its major components, how they function, and how you can use them. We hope you find this article series useful for taking full advantage of AdminP's powerful functionality to make your job easier and your users (and boss) happier.

ABOUT THE AUTHORS
Timothy Speed is an infrastructure and security architect for IBM Software Services for Lotus (ISSL). Tim has been involved in Internet and messaging security since 1992. He also participated with the Domino infrastructure at the Nagano Olympics and assisted with the Lotus Notes systems for the Sydney Olympics. His certifications include MCSE©, VCA (VeriSign Certified Administrator), Lotus Domino CLP Principal Administrator, and Lotus Domino CLP Principal Developer. Tim has also co-authored four books: The Internet Security Guidebook, ISBN: 0122374711, February, 2001; The Personal Internet Security Guidebook, ISBN: 0126565619, October, 2001; Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization, ISBN:0121604527; and Internet Security: A Jumpstart for Systems Administrators and IT Managers, ISBN 1555582982. You can reach Tim at Tim_Speed@us.ibm.com.

Paul Raymond is a Development Relations Manager with the Lotus Product Introduction organization. He was involved with the early deployment Design Partner Beta program for Notes/Domino 6.0 and continues to be the lead for the Notes/Domino 6.5 Beta programs. Paul joined Lotus in 1992 and worked in various parts of the organization ranging from Desktop Support and Field Support Services before joining the newly formed Development Relations team.