Previous Page TOC Next Page



— 13 —


Administrative Tools


Notes administrators must be familiar with the various specialized tools for monitoring and configuring a Notes network. The two biggest challenges a Notes administrator faces are maintaining remote servers and monitoring activity on all Notes databases. Administering local servers and users, while extremely important, has been vastly simplified in Notes 4.0.

This chapter serves as a general introduction to the tasks that an administrator must accomplish. Notes is shipped with a collection of programs and tools to simplify the administrator's job. The primary tools of a Notes administrator are

In addition to these tools, Notes includes a number of databases that an administrator can use to monitor system activity. The most important of these databases are

You will quickly notice that the Public Address Book is listed as both an administrative tool and an administrative database. The Public Address Book is the most important database in a Notes network. All Notes administrators should be completely familiar with the Public Address Book.

Notes configuration information is stored the NOTES.INI file. The NOTES.INI file is a text file stored on each server in the network. Each server has its own copy of NOTES.INI. Notes provides several ways you can manage remote NOTES.INI files. In addition to the Public Address Book, Notes administrators should be familiar with each entry in the NOTES.INI file.

Administrative Databases


Notes administrative databases enable you to monitor activity within the Notes network. These databases are:


Using the Notes Log


The Notes log (LOG.NSF) records information about events and activity on your Notes network, such as replications, database activity, port activity, and mail routing. Check the Notes log on a daily basis to ensure that you are identifying all replications, mail routing, and modem errors.

The Notes log is useful for both server administrators and database managers. Server administrators can track general server statistics, while database managers track detailed activity on their databases.

Because the Notes log serves as a repository for general information about your Notes network, it can grow quite large. To help minimize the size of the log file, you can configure the exact information to be collected in the Notes log. In general, you should collect as much information as possible, so that you can analyze problems when they arise, rather than having to reconfigure logging and collect information before being able to solve a problem. The disadvantage of recording all activity on a network is that the Notes log can become unmanageable. In particular, you should consider when to monitor activity on ports. Part of the server administrator's job is to specify what information needs to be monitored on each server in the Notes network.

Even if you carefully tailor the information recorded in Notes log, visually scanning the Notes log for specific problems is difficult. Instead, you can use the Log Analysis tool to search for key words in the Notes log. The Log Analysis tool pulls documents matching your search criteria into another database that you can browse visually.

Monitoring the Notes Log

At least one administrator should check the Notes log for each server once a day. The views available in the Notes log are:

These views are self-explanatory except for the Sample Billing view. You can use the Sample Billing view to charge individual departments or users for their usage of the Notes server. Figure 13.1 shows an example of a Sample Billing view.

Figure 13.1.
The Sample Billing view of the Notes log.

Server administrators and database managers should both be monitoring the Notes log to verify that

The Notes log records the following information about Notes server activity:

The Notes log records the following information about a Notes workstation:


Creating the Notes Log

The Notes server creates the Notes log the first time the server is run. This default setting gives you one Notes log on each server. Some organizations may want one Notes log for the entire Notes network. You should only share a Notes log across a network if you have a very small network (fewer than five servers). The recommended approach is to create a single Notes log for each server and use the Log Analysis tool to copy data to a common database, rather than creating a common Notes log for all servers.

When the Notes log is created, the local server is defined as the manager of the database. The server administrator should immediately add the server administrator group to the access control list of the Notes log, giving the group manager access. If you want to define a different set of managers for different Notes logs, create multiple administrator groups rather than entering administrator names directly into an access control list. For details on adding names and groups to access control lists, see Chapter 18, "Administering Notes Security."

If Notes Setup is run from a remote workstation, the ID that was active during Notes setup will be defined as the manager of the Notes log. The server administrator should immediately add the server administrator group, giving manager access, and remove the person's ID from the access control list.

If you have a number of new administrators in your organization, consider editing the About documents for the Notes log. You should add the following information to the About document:


Using the Log Analysis Tool

The Log Analysis tool searches the Notes log for documents matching your search criteria and copies matching documents to the Analysis results database. An Analysis database will be created if one doesn't already exist. The Analysis database makes it easier for an administrator to monitor specific Notes resources.

To use the Log Analysis tool, follow these steps:

  1. Choose File | Tools | Server Administration.
  2. Select the server containing the Notes log you want to analyze.
  3. Select the server's icon.
  4. Select Log Analysis.
    The Server Log Analysis dialog box appears (see Figure 13.2).

    Figure 13.2.
    The Server Log Analysis dialog box.

  5. Click the Results Database button to display the Results Database dialog box (see Figure 13.3).
  6. Select a server to store the results database.
    You should select a server on which you have rights to create a database.

    Figure 13.3.
    Use the Results Database dialog box to specify an results database.

  7. Enter a title for the results database. The default title is Log Analysis.
  8. Enter a path and file name for the results database. The default setting is LOGA4.NSF.
  9. Indicate whether you want to overwrite all entries in this database or add new entries. Because the purpose of the Log Analysis tool is to reduce the amount of clutter that an administrator needs to work through, the default setting is overwrite this database.
  10. Choose OK.
  11. Enter the number of days back in time that the Log Analysis tool should search.
  12. Enter the keywords for your search, separated by commas. If you are searching for potential errors, some good keywords are cannot, error, and fatal.
  13. Click the Start button or the Start and Open button. The Start and Open button opens the Log Analysis results database for immediate browsing. Figure 13.4 shows an example of the Log Analysis output.

Figure 13.4.
A sample Log Analysis output.

The Log Analysis view shows all the information in each document. The administrator doesn't have to open each document in the Log Analysis database to find possible problems or errors. The complete text of the message is contained in the view.

You can sort the output in the Log Analysis view by server, date, or message, in ascending or descending order. Simply select the proper arrow in the Server, Date, or Message column heading.

You can collect information from several server logs into a common Log Analysis database. This strategy is better than creating a single log for all servers on a network. Administrators have only one database to scan (the analysis database) instead of many logs, and server performance isn't degraded by the need to replicate the Notes log.

Using the Certification Log


Immediately after installing the first Notes server in your organization, you should create a certification log (CERTLOG.NSF). The certification log is required for the use of the Administration Process. The certification log maintains a list of all registered and certified users and servers within your domain.

The certification log stores the following information from each user and server:

You can open the certification log directly from the workspace or through the Server Administration panel (see Figure 13.5). Figure 13.6 shows a sample entry from the certification log.

Figure 13.5.
The certification log, By Certifier Name view.

Figure 13.6.
A sample document from the certification log.

In addition to information on registered and certified users and servers, the certification log contains information on recertification requests in-process. In-process recertification requests are ones that the Administration Process has not yet completed. You can view in-process recertification requests using the Update Status view.

The administrator must create the certification log manually. Notes doesn't create the certification log automatically. To create the certification log, follow these steps:

  1. Choose File | Database | New.
  2. Select the administration server on your network. Create database rights on this server to proceed.
  3. Enter Certification Log for the title.
  4. Enter CERTLOG.NSF for the name of the file. The certification log must use the file name CERTLOG.NSF (see Figure 13.7).

    Figure 13.7.
    Specifying the certification log's file name.

  5. Select Show Advanced Templates.
  6. Select Certification Log from the list of templates.
  7. Choose OK.
  8. Add the certifier's group to the access control list, giving the group editor access. This setting enables certifiers to register new users and servers. You should remove the names of any administrators that appear directly in the certification log.

After you have created a certification log for a domain, you should create a replica of this file on all servers that will run the Administration Process.

Understanding the Administration Process


The Administration Process automates the tasks of renaming users and servers. The Administration Process automatically updates the following databases whenever a name is changed in the Public Address Book:

You can use the Administration Process to

The Administration Process works by scanning the Administration Request database and responds to new requests. Requests are generated most often from the Name and Address Book.

You can create the Administration Requests database manually, or let the Administration Process create the database automatically. The Administration Request database (ADMIN4.NSF) is based on the Administration Request template. You should maintain replica copies of the Administration Request database on all servers in your domain, and shouldn't have non-replica copies of Administration Request databases on your network.

You don't need to run the Administration Process on every server that contains a copy of the Administration Request database. This setup enables you to generate requests from any server, have those requests replicate to the server running the Administration Process, and have your requests automatically handled by the Administration Process. Minimize the number of servers in your domain running the Administration Process to simplify configuring the Administration Server property for the databases on your domain. Notes automatically adds Administration Process server task (ADMINP) to the ServerTasks = setting in the NOTES.INI file. You should edit the NOTES.INI file and remove the ADMINP ServerTasks entry on all servers that will not be functioning as administration servers.

Configuring the Administration Process


The Administration Process can only run on a Notes Release 4 server. To take full advantage of the Administration Process features, such as upgrading ID files from flat to hierarchical naming, the administration server should be hierarchically certified. To set up the Administration Process, follow these steps:

  1. If you haven't done so, create the certification log database. See the earlier section "Using the Certification Log" for details on creating a certification log database.
  2. Ensure that the ADMINP server program is set on the ServerTasks = line in the NOTES.INI file.
  3. Start the Notes server and workstation program.
  4. Modify the ACL in the Public Address Book. For each group of administrators that need to change user or server names or recertify users or servers, add the group name to the access control list, specifying at least author access with the ability to delete documents. Specify any or all of the following roles as appropriate for each administrative group:
    The ability to delete documents is required for all administrators who will have to remove users and servers from the network.
  5. Modify the access control list of the Administration Request database. Give author access to all administrators and administrator groups that will be requesting changes to user names and certificates.

After you have configured a server to be the administration server, you must specify for each database on the network which administration server has the right to update the access control list for that database. All replicas of the database should share a common administration server setting, to prevent replication conflicts when more than one administration server is updating a database's access control list. Each database must have a replica on one or more servers running the Administration Process. This strongly implies that you should configure your hub servers to be your administration servers also. If you aren't using a hub-and-spoke replication architecture, the easiest way to make sure that every database can be serviced by an administration server is to configure all servers to run the Administration Process.

You can specify an administration server for a single database or for a group of databases. To specify an administration server for a single database, follow these steps:

  1. Select the database icon from your workspace.
  2. Choose File | Database | Access Control.
    The Access Control List dialog box opens (see Figure 13.8).
  3. Select the Advanced icon.

    Figure 13.8.
    Options for setting the ACL for the administration server.

  4. Select the administration server for this database from the drop-down list. The list contains servers for the databases on your desktop. Click the Other selection in the drop-down list box to display servers that are available based on your current location.
  5. Choose OK.

The following section includes a diagram that shows how the Administration Process updates database ACLs and server and user ID files. Administrators and certifiers submit requests for name changes and recertifications, using the Public Address Book. The Public Address Book automatically creates the appropriate requests in the local Administration Requests database. These requests are replicated to the administration server, where the Administration Process updates the Public Address Book. The Administration Process also updates the access control list for all the local databases that specify that server as their administration server.

You can set the administration server for a group of databases by using the Server Administration panel. Follow these steps:

  1. Choose File | Tools | Server Administration.
    The Server Administration Panel opens.
  2. Select the database's icon.
  3. Select Database Administration Server.
    The Set the Database Administration Server dialog box appears (see Figure 13.9).

    Figure 13.9.
    You can set the administration server for a group of databases, using multiple databases at one time.

  4. Select one or more databases from the list. You can select multiple databases by holding down the Shift key as you select databases.
  5. Type the name of the administration server for these databases. Double-check your typing to avoid typos. Enter the full name of the server.
  6. Click Set.
    Notes posts a confirmation box when the databases have been updated.
  7. Choose OK.
  8. Choose Done.

Using the Administration Process to Convert Names


The Administration Process automatically updates the Public Address Book, user and server ID files, and database ACLs in response to requests to change a user or server name or a certificate. The process is similar in all cases. (Note that the numbers in the following steps match those in Figure 13.10.)

Figure 13.10.
The steps carried out by Administration Process when changing a name or certification.

These are the steps:

  1. A certifier uses the Public Address Book to request a change to a user's or server's name or certification.
    To change the name or certification for a user, you open the People view in the Public Address Book, select the name(s) to be changed, and choose Actions | Rename Person to open the Certify Selected Entries dialog box (see Figure 13.11).


    NOTEThe server used by the certifier in this step must have a copy of the Administration Request database.


    Figure 13.11.
    Changing the certification for selected entries.

    In this dialog box, you can upgrade to hierarchical certification, change the common name, or change the certifier by using the Administration Process. You can only change the common name of a single user at a time. You can upgrade certification or change the certifier of groups of users at one time. Choose the button appropriate for this situation to display a file selection dialog box. Next, open the Certifier ID file that will be used to issue the new certificate for the users, type the password for the certifier file in the Enter Password dialog box, and choose OK. What happens next depends on the type of change you're making:

  2. Notes automatically creates requests in the Administration Requests database.
  3. The name change or certification requests replicate in the Administration Requests database on the administration server.
  4. The Administration Process scans the Administration Requests database.
  5. The Administration Process updates the entries in the Public Address Book for each user or server changed. The certificates are copied from the requests into the Public Address Book.
  6. Changes to the Public Address Book replicate to all servers in the domain.
  7. The ID file for the user or server is updated:
  8. Notes creates a Rename Server in Address Book document or a Rename User in Address Book document in the local Administration Requests database.
  9. The Rename request replicates back to the administration server for the Public Address Book.
  10. The Administration Process scans the Administration Request database.
  11. All other entries in the Public Address Book are changed to reflect the new name or certification.
  12. The Administration Process creates a Rename in Access Control List request in the Administration Requests database.
  13. The Rename in Access Control List requests replicate to the Administration Requests database on administration servers throughout the domain.
  14. The Administration Process scans the Administration Requests database.
  15. The access control lists for all databases are changed to reflect the new name or certification.

All changes to the Public Address Book and database ACLs are replicated throughout the domain.

The user's ID is updated in step 7, but database access control lists are not updated until step 15. In the time between a user's ID being updated and database access control lists being updated, the user's name will be different from his name stored in a database ACL. If you are simply upgrading a user from flat certification to hierarchical certification, he will be able to access all databases, even before their access control lists are updated, if

If you are changing the common name of a user or server, or switching from one hierarchical certifier to another, the user will not be able to access databases that explicitly mention this user in their ACLs. This problem is yet another reason for not explicitly including individuals' names directly in the ACL. If a user's name appears only in groups, which are in turn included in the ACL, he needs to wait only until the Public Address Book is updated in step 11 to gain access to all databases.

You can view the status of in-process requests in the certification log. Every time the Administration Process takes an action, it updates the certification log. For more details on the certification log, see the earlier section "Using the Certification Log."

This example is meant to illustrate the workings of the Administration Process, not to document all the steps required to convert a Notes network from flat naming to hierarchical naming. For complete details on converting from flat naming to hierarchical naming, see Chapter 12, "Migrating from Notes 3.x."

The Administration Process follows the same steps when recertifying hierarchical IDs. Steps 8 through 16 are skipped when there is no name change due to the recertification.

Scheduling the Administration Process


A significant amount of time can pass before the entire Notes network is updated in response to a request for a name or certification change. In particular, there may be a period of time during which users can't access databases on the network. The length of time required to update the Notes network depends on the replication schedule and the Administration Process schedule. To reduce the amount of time required, replicate the Administration Requests database and the Public Address Book more frequently and reduce the ADMINP Interval and ADMINPModifyPersonDocumentsAt settings in the NOTES.INI file.

The ADMINP Interval setting is the number of minutes between scans of the Administration Requests database. The ADMINPModifyPersonDocumentsAt setting is the hour of each day when person documents will be updated in the Public Address Book. You should schedule person document changes during off-peak hours. The default is midnight. Keep in mind that the ADMINPModifyPersonDocumentsAt setting uses a 24-hour clock, where 0 (zero) is midnight and 23 is 11:00 p.m.

The Public Address Book


The Public Address Book is far more than a directory of users and servers. The Public Address Book stores the topology of your Notes network, your Notes replication architecture, and controls the way Notes mail is routed. The Public Address Book is also a powerful tool administrators can use to accomplish such tasks as these:

The Public Address Book is the most important database in the Notes network. It's extremely important that you keep a backup copy of the Notes Name and Address Book available at all times to replace any that might become corrupted.

There is one Public Address Book for each Notes domain. In addition, each user can set up one or more Personal Address Books on their own machines. Each server needs a copy of the Public Address Book. Users (other than mobile users) don't need a replica of the Public Address Book on their client machines. Mobile users may need to have a copy of the Public Address Book on their machines to properly route mail. See Chapter 19, "Supporting Dial-Up Users," for a full discussion of the options available to mobile users.

Controlling Access to the Public Address Book


The Public Address Book is designed to be managed by many different administrators, possibly working at different locations. You can have your administrators specialize geographically or by tasks. Users also have an important role to play in maintaining their own person documents.

In addition to the normal database ACL access levels, the Public Address Book is shipped with eight roles that you can use to finely tune the authority given to each administrator or user. As discussed in Chapter 3, "Understanding Security," roles don't protect the data in a database. Roles are a user interface convention intended to prevent accidents or errors. These are the eight roles for the Public Address Book:

Although it's certainly possible to distribute responsibility for the Public Address Book across multiple regions and multiple administrators, your organization may choose to centrally administer the Public Address Book. Roles are more important for large organizations that administer the Public Address Book centrally. In this case, you have several administrators at one site, allowing the administrators to specialize. If your organization has administrators at multiple sites, or is medium-to-small in size, you may not have the opportunity to have your administrators specialize. There simply aren't enough administrators at any one site to divide up the tasks. In this case, you should consider relying more on the access control list's access levels, such as manager, editor, and so on, and not worry about assigning roles.

If your organization is going to use roles to control access to the Public Address Book, create a matching group for each role. For example, create a group called UserModifier for all users and administrators who have the ability to edit person documents.

The Creator roles must be assigned to all administrators who need to create documents, regardless of the administrator's access level to the Public Address Book (except for managers). The Modifier roles are useful only for tuning the ability of administrators or users with author access to the Public Address Book. Anyone with manager, designer, or editor access to the Public Address Book already has the ability to modify all documents. For each access level allowed in an access control list, you need to determine which users will have those rights to the Public Address Book:

Chapter 3, "Understanding Security," describes these access levels in detail.

The Public Address Book is a good example of how to use access levels, author fields, and roles to fine-tune access for a wide variety of users.

Every document in the Public Address Book contains an Administrators field that is used to delegate specific responsibilities to individual documents. Administrators is an author type field. Author type fields give the ability to edit a specific document in which the field appears. You can use the Administrators field to give users the ability to edit their own person documents without giving them the ability to edit any other person document.

You use the Administrators field to control access to a specific document. Use the modifier roles to give to a user the ability to edit a whole class of documents. The modifier roles are useful only for modifying the access level of users or administrators with author access.

The Administrators field, as with all author type fields, is useful only for modifying the access given to users with author access to the database. Users with reader access to a database cannot edit a document even if their names appears in an author type field. This means that all users must be given author access if you want them to edit their own person documents. You cannot give users reader access, list their names in the Administrator's field, and expect them to edit their own person documents.

When planning your administrator groups, you should consider these issues:

Groups that you set up for use in the Public Address Book should be created for use in access control lists only. These groups will not be used for mail routing or server access. Chapter 9, "Designing Your Notes Network," covers setting up groups and default access control lists in more detail.

Public Address Book Document Types


The Public Address Book contains eleven different types of documents that enable administrators to configure and manage the Notes network. The following list describes the documents in the Public Address Book.

The following sections describe each of these document types and their uses in more detail.

Certifier Documents

Certifiers are responsible for issuing certificates that bond together user and server public keys and names. Certifiers and certificates are described in more detail in Chapter 3, "Understanding Security," and Chapter 18, "Administering Notes Security."

Certifier documents in the Public Address Book contain information about an individual certifier. The certifier's name, ancestor, contact information, and certified public key is contained in the certifier document (see Figure 13.12).

The public key contained in a certifier document is not displayed in Read mode. You must put a certifier document in Edit mode (by pressing Ctrl+E) to view the public key. You may need to read the public key to another certifier over the phone when you are setting up cross certificates with another organization.

Figure 13.12.
You must open a certifier document in Edit mode to view the public key.

Connection Documents

Connection documents are used to configure replication and mail routing between two specific servers (see Figure 13.13). The servers don't need to be in the same domain or on the same Notes network. Using a connection document, you can specify the times, days, and intervals between scheduled connections for two servers. When two servers connect, by default Notes replicates all databases in common and routes all pending mail. You can cause Notes to connect to another server at an unscheduled time if the amount of pending mail exceeds a specified threshold.

Figure 13.13.
A typical server connection document.

You can create multiple connection documents for a specific pair of servers. This system is useful if you want to schedule replication and mail routing separately. To create a connection document for replication only, deselect mail routing in the Tasks field. Similarly, to schedule mail routing without causing replication, delete the replication entry in the Tasks field.

Chapter 14, "Administering Notes Mail," and Chapter 15, "Administering Replication," contain more information on configuring replication and mail routing.

Domain Documents

Notes offers a variety of different types of domains. Each domain is a logical set of servers. Any collection of servers can be included in a domain, whether they are on the same network, connected by modems, or not connected in any manner.

Foreign domains are typically used to route mail to non-Notes mail users. Each type of mail system that must connect to Notes needs its own foreign domain document. Lotus has created foreign domain documents for the most typical types of mail interconnections, including X.400, SMTP, and cc:Mail. For each foreign domain, you must specify a particular server that connects to the other mail domain. Typically, this is a gateway server running both mail systems, as well as a program that converts mail from one system to another. Figure 13.14 shows a typical foreign domain document.

Figure 13.14.
A typical foreign domain document.

Non-adjacent and adjacent domain documents route mail between Notes domains. Non-adjacent domains are all domains that don't directly connect to a server in your organization's domain. Adjacent domains have at least one server that can connect directly to a server in your domain. For non-adjacent domains, you need to specify an adjacent domain that, in turn, knows how to route mail to the non-adjacent domain. Figure 13.15 shows a typical non-adjacent domain document.

Figure 13.15.
A typical non-adjacent domain document.

You need only specify the name of an adjacent domain. Notes automatically scans the Public Address Book for a server in the adjacent domain when it needs to route mail.

Global domain documents configure mail address conventions used in a worldwide domain. Global domains are useful when you are sending mail to Internet domains or X.400 mail systems.

Group Documents

Groups are collections of users, servers, and other groups. Groups are useful for reducing the amount of administrative effort needed to maintain a Notes network. You should use groups instead of explicitly listing individual user or server names.

The most difficult problem you will face with groups is the proliferation of group names in the Public Address Book. If you distribute management of the Public Address Book such that many people have the ability to create groups, consider creating a policy for naming groups. Your goal should be to have a group's name clearly define the group's reason for being. For example, if you want to create a group of administrators who can edit server documents in the Public Address Book, you might call the group PABServerModifiers. By prepending the initials PAB to the group name, you are indicating that this group is to be used specifically with the Public Address Book. You can come up a set of prefixes and suffixes for groups that will clearly identify whether the group is for use by a particular department, database, access control list, mail addressing, or is a multipurpose group.

Creating a group document is extremely easy. You simply need to specify the group name, type, and members. A useful option is to enter a detailed description of the group in the group document. Figure 13.16 shows an example of a completely filled in group document.

Figure 13.16.
A group document in the access control list.

Pay particular attention to group types. Using group types helps clarify the purpose of the group, as well as reducing clutter on the Notes interface. The types that Notes provides are

Groups with the type Mail only appear only in views and lists for addressing mail. This setting increases view performance, as well as reduces the number of groups that a user needs to sift through when addressing mail. All the other types function in a similar manner. The Access Control List Only groups appear only in dialog boxes and views pertaining to access control lists. The Deny List Only type appears only in the server access list views.

Location Documents

Location documents are used by mobile users to instruct Notes on how to reach their Notes network. Each location to which a mobile users travels must have its own location document. Figure 13.17 shows a typical location document.

Figure 13.17.
A typical location document.

Each location document specifies the mail file to be used at that location, a replication schedule (if applicable), and a set of servers accessible from that location. Chapter 19, "Supporting Dial-Up Users," provides detailed information on configuring location documents.

Mail-In Database Documents

The Notes mail router can place mail in any Notes database, not just mailboxes. Any Notes database can be a recipient of Notes mail. Before a database can receive mail, you must create a mail-in database document in the Public Address Book for that database. Figure 13.18 shows a typical mail-in database document.

Figure 13.18.
A typical mail-in database document.

You address mail to a mail-in database as you would any other mail recipient. You can include mail-in database addresses in groups or explicitly in any To field. Mail-in databases can respond automatically to mail by using macros.

Person Documents

Person documents contain information for mail routing, as well as generic address and phone number information. Figure 13.19 shows a typical person document.

Figure 13.19.
A typical person document.

Most of the fields in a person document are self-explanatory. If you need to view the public key for a person, you should place a person document in Edit mode by pressing Ctrl+E.

Person documents are created automatically when you register a new user. By listing the user's name in the Administrators field at the bottom of a person document, you can have your users enter their own address and phone number information. When you first register a new user, that person's ID file is stored as an attachment to his person record (if you have elected to store ID files in the Public Address Book). The first time a Notes user accesses his home server, the ID file is detached from his person document and stored on his local hard drive.

Program Documents

You can use the Notes Public Address Book to schedule tasks and programs on any Notes server. Common uses for program documents are to schedule backups and software updates. For each program, you need to provide a complete path and file name for the program, including any extensions, such as .EXE. You can specify the time of day and day of week for each program. Figure 13.20 shows a typical program document.

Figure 13.20.
A typical program document for backing up a server.

Using the Enable/Disable field, you can cause a program to be run according to the schedule, on system startup only, or to not run at all. If you select STARTUP ONLY, the program will run each time the Notes server is shut down and restarted.

Server Documents

The server document is the most complex document in the Public Address Book. Server documents contain information on the server's location, network configuration, access control, agent manager, mail routing, and administrator contact information. Server documents are created automatically when you register a server. Figure 13.21 shows a typical server document.

Figure 13.21.
A typical server document in the Public Address Book.

For information on filling in server location and network configuration sections, see Chapter 10, "Installing and Configuring Notes Servers." For details on the security and restrictions information, see Chapter 18, "Administering Notes Security." For information on the passthru fields in the Restrictions section, see Chapter 19, "Supporting Dial-Up Users." Information on configuring the agent manager is contained in the section "Using the Agent Manager," later in this chapter.

The administration section of a server document contains four fields: Owners, Administrators, Certified Public Key, and Change Request. The Change Request field is set by the Administration Process (described earlier in this chapter) when a server's name or certification changes. A server scans its own server document periodically, checking the Change Request field. If the Change Request flag is set, the Notes server will verify the information in the server document and then update the server ID file.

Server Configuration Documents

Server configuration documents are one way you can edit parameters stored in the NOTES.INI file. You can use a server configuration document to change a parameter in every server's NOTES.INI file or to change a parameter for a single server. A single server configuration document can be used to set any number of NOTES.INI parameters. Figure 13.22 shows a typical server configuration document.

Figure 13.22.
A typical server configuration document.

To create a server configuration document, follow these steps:

  1. Open the Public Address Book.
  2. Choose Server | Configurations | View.
  3. Choose Add Configuration.
    Notes creates a server configuration document with a default server name of *.
  4. Enter the server name for this server configuration document. The default setting (*) causes this server configuration document to apply to all servers in the domain.
  5. Click the Set/Modify Parameters button.
    The server configuration parameters dialog box opens (see Figure 13.23).

    Figure 13.23.
    The Server Configuration Parameters dialog box.

  6. Click the little down-arrow button by the Next button.
    The Select a Standard Parameter dialog box appears.
  7. Select the parameter you want to configure.
  8. Choose OK.
    Notes fills in the Item field with the parameter name and displays Help text in the bottom of the Server Configuration Parameters dialog box.


    You can use the Server Configuration Parameters dialog box to help you understand specific NOTES.INI parameters. Detailed Help text is available in this dialog box for all NOTES.INI parameters.

  9. You can repeat these steps to configure multiple parameters in a single server configuration document.
  10. Choose OK.
    The Current Parameters field in the server configuration document is updated with one line for each parameter you have specified.
  11. Choose Save.
  12. Choose Close.

The server configuration document replicates to all copies of the Public Address Book and causes the NOTES.INI files to be updated. NOTES.INI parameters set using the server configuration document take precedence over settings in the current NOTES.INI file. These settings will typically take effect within one minute of the time the server configuration document is placed in the Public Address Book on a server. You don't need to reboot the server for these new parameters to take effect.

A single parameter for a server can be set in more than one server configuration document. This can happen when you use one server configuration document to specify parameters for a group of servers and another server configuration document specifically for a single server. The parameter value from the server configuration for a single specific server takes precedence over a server configuration setting for multiple servers.

One way to efficiently configure multiple servers is to create a server configuration document for each type of dedicated server in your organization. For example, you may have a specific set of parameters for mail servers and another set for hub servers. Create a group document for each class of servers and place that group name in the Server field in the server configuration document.

Every time a server reboots, it scans the Public Address Book for server configuration documents that apply. Any new parameters are read into memory and the NOTES.INI file is updated. The server scans the Public Address Book for configuration settings every five minutes. Every time a server finds a new or modified configuration setting, it reads that setting into memory and updates the NOTES.INI file. Remote servers experience more of a delay, due to the time needed for the document to be replicated, the Public Address Book view to be updated, and the Public Address Book to be scanned. In all, you can expect a delay of an additional twenty minutes on top of the replication time before parameter changes take effect on remote servers.

You cannot edit every parameter in NOTES.INI file using a server configuration document. You must enter some configuration changes using the server document. This system is necessary to maintain proper Notes security. The parameters that cannot be updated using a server configuration document are in the following list:

If these fields aren't specified in the server document, a Notes server will use them.

Consider the following example, which shows how a Notes server uses different configuration documents to arrive at the actual parameter values used. In this example, there are three server configuration documents. One specifies parameters for all servers, using *, the second specifies parameters for a group of servers, and the third specifies parameters for a specific server.


All Servers Configuration Document

    Server Name = *

        LOG_MAIL_ROUTING = 10

        Update_No_Full Text = 1

Mail Servers Configuration Document

    Server Name = MailServers    (Group containing all mail servers)

        LOG_MAIL_ROUTING = 30

        Replicators = 2

Single Server Configuration Document

    Server Name = Mail1/L3COMM

        ADMINP_Interval = 30

        Replicators = 4

Notes will first read in the parameters from the All Servers configuration document. Notes then reads the server group configuration document and overwrites any parameter values from the All Servers document. Finally, Notes reads the Single Server configuration document and overwrites any existing parameter values. The final set of parameters used by mail 1/L3COMM are as follows:


LOG_MAIL_ROUTING = 30

    ADMINP_Interval = 30

    Replicators = 4

    Update_No_Full Text = 1

User Setup Profile Documents

Users setup profiles are used during user registration to automatically create connection documents for the servers listed in the profile. User Profiles simplify the registration of multiple users by eliminating the need to provide common information repeatedly. Although you can create as many profiles as you want, each user can be associated only with a single profile.

When creating a new user setup profile, you specify the name and phone numbers of passthru and remote dial-up servers and the name of the Internet server for the class of users. You also can specify a mail domain for that set of users. All fields are optional except the name of the profile.

Notes creates all the location and connection documents needed by users to access the servers listed in the profile. These documents are stored in the Personal Address Books for the users.

Gathering Statistics and Events


The Notes Events Monitor enables you to configure automatic notification for large numbers of errors and conditions. You also can use the Event Monitor to record statistics about activities on the Notes network, including replication events, changes to access control lists, and database usage. The Event Monitor works with two databases: Statistics Events (EVENTS4.NSF), and Statistics Reporting (STATREP.NSF). The Reporter server task is responsible for generating statistics and events. When Notes is installed, no statistics or events are being monitored. You must configure the exact statistics and events that you want to track. Consider these issues when deciding what statistics and events to monitor:

Events are broken into categories. Each category has specific events broken into severity levels. The following list details the types of events:

You create an Event Monitor document in the Statistics and Events database (EVENTS4.NSF) for each type of event you want to track. You can have more than one Event Monitor document for each type of event, if you want to monitor different severity levels on different servers.

The Statistics and Events Database


The Statistics and Events database can contain:

You can view all events and their associated message text by using the Names and Messages views in the Statistics and Events database. You can edit individual documents in these views to create your own message text or to add new messages specifically for your installation. Figure 13.24 shows typical names and messages—messages by text view—in the Statistics and Events database. As the figure shows, each message has an associated type and severity.

Figure 13.24.
Viewing message text in the Statistics and Events database.

Configuring Events and Statistics Reporting


The Event Monitor and Reporter server tasks don't run automatically. An administrator must edit the ServerTasks setting in the NOTES.INI file. Add the entries Event and Reporter to the ServerTasks parameter to run the Event Monitor and Statistics Generator on a server. The first time the Event server task runs, it will automatically migrate Release 3 monitor documents from the Public Address Book and configure all the necessary databases and entries in the new Public Address Book. Specifically, the first time the Event task runs, it will take these steps:

  1. Creating the Statistics and Events database (EVENTS4.NSF) if none exists.
  2. Creating a Server to Monitor document for every server in the Public Address Book.
  3. Migrating all Notes Release 3 monitor documents from the Public Address Book to the Statistics and Events database.
  4. (Event Monitor) Adding an address for mailed-in events in the Server to Monitor document for the server running the Event server task.
  5. For the database listed in the address on the Server to Monitor document, a creating a mail-in database document in the Public Address Book.
  6. Creating a mail-in database corresponding to the mail-in database document, if none exists.

The Reporter server task automatically configures a Notes server the first time the task is run. The Reporter is responsible for tracking statistics on its server. A Reporter must have a mail-in database to receive statistics information. The mail-in database can be a local database, or one on a remote server that is used to collect information from multiple servers. The recommended configuration is to use a centralized Statistics Reporting database that receives messages from the Reporter tasks running on multiple servers in the network.

You should run the Event Monitor and Reporter server tasks one time from the console to automatically configure a server for Statistics and Events monitoring. After the server has been configured, you can tune the installation by editing the Server to Monitor documents in the Statistics and Events database. To edit a Server to Monitor document, follow these steps:

  1. Open the Statistics and Events database.
    You can open the Statistics and Events database directly from your workspace or by using the Server Administration panel (for details, see the later section " Using the Server Administration Panel"). To use the Server Administration panel, select the database's icon and choose Configure Statistics Reporting.
  2. Open the Server to Monitor view.
  3. Open the Server to Monitor document for the server you want to configure.
  4. Enter the address of the mail-in database that will receive statistics.
    Enter the address exactly as it appears in the Mail-In Name field in the mail-in database document in the Public Address Book for the Statistics Reporting database.
  5. Enter a collection interval for the server.
    The collection interval is the interval between Reporter tasks. The collection interval controls how many documents will be created in the Statistics Reporting database. One document is created for each running of the Reporter task. Running the Reporter task more often creates more documents and causes the analysis to take longer to perform. The minimum interval you can specify is 15 minutes. The recommended interval is 4 hours for heavily loaded servers and once a day for infrequently used servers.


    If you are experiencing problems on a specific server, increase the reporting frequency to 30 minutes.


  6. Enter an analysis interval.
    Analysis reports summarize the individual statistics documents in the Statistics Reporting database. At each interval specified, the Reporter server task creates a report containing information such as averages and peak usages. The analysis reports are useful for planning server and network upgrades and for assigning users to lightly loaded servers. The analysis report also reports on database and templates.
  7. (Optional) Enter a description for the server.
  8. Select Save Server to Monitor.

Using the Server Administration Panel


You can access the Server Administration panel can be accessed from any workstation. The Server Administration panel centralizes the most common tasks that administrators need to perform. All types of administrators, including certifiers, server administrators, and database managers, can use the Server Administration panel. The following list details some of the tasks you can accomplished from the Server Administration panel:

To access the Server Administration panel, choose File | Tools | Server Administration. In the list of servers, highlight the server you want to manage, and select the desired task from one of the drop-down menus accessed from the buttons to the right. Each of the tasks that you can accomplish by using the Server Administration panel is covered in detail in other chapters. Using the Server Administration Panel to manage certificates and ID files is covered in Chapter 18, "Administering Notes Security." The Notes console, administration databases, and Public Address Book are covered in this chapter. Using the Server Administration panel to manage databases is covered in Chapter 17, "Administering Notes Databases." Analyzing mail problems with the Server Administration panel is covered in Chapter 14, "Administering Notes Mail."

Using the Server Console


At the server console, you can enter commands for immediate execution by the server. You can access the server console directly on the server or through the Administration Server panel. Figure 13.25 shows a typical server console listing.

Figure 13.25.
A typical server console.

The only difference between a server console and a remote console? Only those listed as administrators for a server can access that server by using a remote console.

The remote server console is shown in Figure 13.26. You access the remote server console from the Server Administration panel by selecting the Console button.

Figure 13.26.
The remote server console.

To enter a command using the remote server console, follow these steps:

  1. Select the correct server from the drop-down list.
  2. Enter the command in the Server Console Command field. You can retrieve commands you have already typed by selecting them from the drop-down list.
  3. Choose Send.
    The response from the remote server, if any, appears in the Server Response field. You can scroll the Server Response field to view lengthy messages.
  4. You can copy the Server Response into another document or to the Clipboard by using the Copy Response button.


    You can send results of a server command to an output file by typing the server command and then entering > file name on the same line before selecting Send.


  5. When you have completed your session on the remote console, click Done.

When entering commands at the server console, keep the following points in mind:

Table 13.1 summarizes the server commands you can use at either the console or the remote console.

Table 13.1. Server commands.

..
AbbreviationExampleDescription
Broadcast Broadcast Message UserName(s) Sends a message to all users specified. The default is to send a message to all users currently attached to a server.
Drop Drop UserName Closes out a user's connection to a server. If you have entered LogSessions = 1 in the NOTES.INI file, Notes reports confirmation when a session is dropped.
Exit Exit Shuts down the server.
Help Help Generates a complete list of server commands with brief descriptions.
Load Load ProgramName Executes a specific server task or launches any program that can be run from the current operating system's command line. When using Load to run Notes server tasks, you need to know the executable name for the server task. Chapter 16, "Administering Notes Servers," contains a complete list of the server tasks and their executable names.
Pull Pull ServerName Replicates database updates from the destination server to the current server. No updates are sent from the current server to the specified server
Push Push ServerName Replicates database updates from the current server to the specified server. No updates are replicated from the specified server to the current server
Quit Quit Shuts down the server.
Replicate Replicate ServerName Begins a replication session between the current server and the specified server. The current server pulls changes from the other server and then gives the other server an opportunity to pull changes. If the minimum interval between replications for these two servers has elapsed (see the replication schedule in the connection document), the other server pulls changes from the current server. Otherwise, the other server waits until the next scheduled replication. If the server is replicating when the Replicate command is entered, the command is queued until the current replication ends.
Route Route ServerName Immediately routes all pending mail to the specified server. The other server must be on another Notes network because Notes always immediately routes mail within a network. Use the Route command when you are attempting to troubleshoot mail problems.
Set Configuration Set Configuration Setting Updates settings in a server's NOTES.INIfile and server configuration documents. The Set Configuration Server command immediately updates the specified parameters for the server at which the command was entered. The Set Configuration command updates the server's configuration document in the Public Address Book or creates a server configuration document if none exists. You will need to reboot the server when using the Set Configuration command to change the following parameters:
  • ServerTasks
  • ServerTasks At
  • NSFBufferPoolSize
  • Domain
  • ModemFileDirectory
  • ServerKeyFileName
  • Ports
  • Names
Set Secure Set Secure Current Password Prevents unauthorized access to a server console by requiring a password. A password-protected server console prevents users from using the Exit, Load, Quit, Set Configuration, and Tell commands. In addition, any command that launches a Notes server task cannot be launched from a password-protected console. The console remains protected until a second Set Secure command is entered, using the same password.
Set Statistics Set Statistics Statistics Resets the running total for statistics. You can use a wild card (*) to reset all statistics at once.
Show Configuration Show Configuration Setting Displays the current value for the specified parameter. Any setting for the NOTES.INI file can be used. For a complete listing of parameters in the NOTES.INI file, see Appendix B.
Show Directory Show Directory Displays a list of all databases and templates in the data directory. This command only works with the Notes data directory.
Show Disk Space Show Disk Space location Displays the number of bytes available on a specified hard drive, file system, or volume. Location is an identifier applicable to a specific operating system. Under Windows NT and OS/2, use a hard drive letter. Under NetWare, enter a volume label. Under UNIX, enter a file system name. The default setting displays information about the disk containing the Notes program directory.
Show Memory Show Memory The Show Memory command displays the total amount of virtual memory available to the Notes program. Under OS/2 and Windows NT, this is the total system memory installed plus swap space available. Under NetWare, this command displays the total amount of memory configured. The Show Memory command is not available under UNIX.
Show Port Show Port PortName Displays information about a specific communications port. A port name can be any configured port, including LAN and COM ports.
Show Schedule Show Schedule ServerName/ Use Show Schedule Program Name/Location to display information about programs related to a specific server, program, or location. Show Schedule shows the next program of the specified type to be run.
Show Sessions Show Sessions Server Command Displays system information about the specified server command. The default is to show information about all current Notes sessions. Use the Show Sessions command when debugging a Notes installation.
Show Stat Show Stat Statistic Name Displays information about disk space, memory utilization, and network activity. Statistic name can be any statistic available in the Statistics and Events database's Names and Messages—Statistic Names view. The default is to display information about all statistics.
Show Tasks Show Tasks Displays the status of all active server tasks.
Show Transactions Show Transactions Displays the current transaction statistics for a server.
Show Users Show Users Displays the list of all users currently connected to a server, along with the databases they have accessed and the elapsed time since the last database access.
Tell Tell Server Program Parameter Use Tell to shut down specific server tasks without shutting down the entire server. You also can use Tell to issue any command that will be accepted by a server task.

Using the Agent Manager


Agents are like personalized butlers that Notes users use to carry out specific tasks. Agents can be a significant drain on server resources. For this reason, it's important for a server administrator to restrict the amount of server resources that agents can use. You can restrict a user's ability to create agents, the times of day that agents can run, and the number of agents that can be running simultaneously.

The Agent Manager is responsible for launching all agents on a server. Before executing an agent, the Agent Manager verifies the authority of the person who created the agent. If the user has insufficient authority to run an agent, the Agent Manager rejects the request to run an agent. The Agent Manager then checks to see that all other restrictions, such as time of day and number of simultaneous agents, are not violated. If all these criteria are met, the Agent Manager launches the specific agent. All Agent Manager activity is recorded in the Notes log on the server where the individual agents are run.

To restrict the agents that can run on a particular server, follow these steps:

  1. Open the Public Address Book.
  2. Open the Server-Server view.
  3. Open the desired server document in Edit mode (press Ctrl+E).
  4. In the Agent Manager field, enter the users who are allowed to run private agents. The default setting allows all users to run private agents. Users listed in this field can create personal agents using either the Agent Builder or formulas. Users must have reader access to a database to create personal agents.
  5. Enter the names of any users who are allowed to run restricted LotusScript agents. Any user not specifically listed in the Run Restricted LotusScript Agents field can't use restricted agents. Restricted LotusScript Agents can execute only a limited set of calls. Restricted agents cannot access security features or the operating system.
  6. Fill in the users who will be allowed to run unrestricted LotusScript agents. Any user not specifically listed in the Run Unrestricted LotusScript Agents field can't run unrestricted agents. Unrestricted LotusScript agents can execute any LotusScript call.
  7. In the Refresh Agent Cash field, enter a time of day when you want to have the list of agents updated. The Agent Manager scans all databases and the Public Address Book at the specified time for new or deleted agents.
  8. Specify a start and end time for your daytime operations. Users who can't run agents during the daytime also can't run agents between the start and end time specified.
  9. The maximum number of concurrent agents allowed is 10. Up to 10 agents can run on a server at a single time. A database can execute only a single agent at a time, but multiple databases can have agents executing concurrently. Enter the maximum number of concurrent agents for your server in the Max Concurrent Agents field.
  10. Enter the maximum number of minutes a single agent is allowed to run. Use this field to limit absolutely the amount of resources that are consumed by an agent. When an agent has been executing for the maximum number of minutes allowed, the Agent Manager terminates the agent without allowing it to complete.
  11. Enter the maximum percentage of time an agent is allowed to poll before being delayed. This field specifies the maximum percentage of the CPU that can be used by a single agent. If an agent exceeds this threshold, the Agent Manager delays the further execution of the agent.
  12. Repeat steps 9 through 12 for the nighttime parameters.
  13. Choose Save.
  14. Choose Close.

Summary


Notes provides a variety of tools for administering the Notes network. Several key databases track statistics, events, and other information about the Notes network. The key databases with which all administrators should be familiar are the Public Address Book and Notes log. Other administrative databases, such as the Administration Requests database and the Statistic and Events database, are associated with specific server tasks that administrators must also know how to use.

With proper planning and a little bit of training, administering a Notes network need not be an onerous chore. The following chapters provide specifics on administering the various parts of the Notes network, including mail routing, replication, serving the databases, and security.

Previous Page Page Top TOC Next Page