 | Level: Intermediate Timothy Speed (tim_speed@us.ibm.com), Infrastructure and Security Architect, IBM Paul Raymond, Development Relations Manager, Lotus
01 Jul 2003 Part 2 of 2: Advanced administration of the AdminP server task include 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.
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 sentto the Lotus domain.
Figure 1. 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):
Figure 2. 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:
Figure 3. 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:
Figure 4. 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:
Figure 5. 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.
Figure 6. 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 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.
Resources
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 1555 582982. 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. |
Rate this page
|  |