New Administrative Features and Enhancements in Lotus Notes Release 4



By Louise Young

''Would you like to spend less time running your Lotus Notes servers and keeping your end users happy and content? Lotus Notes Release 4 can help you do just that! It has many powerful tools to ease the deployment of Notes and help you manage administrative tasks quickly and easily through automation. This article introduces some of the many new features and enhancements in Lotus Notes Release 4 that make Notes administration easier.''

''This article is based on early beta builds of Lotus Notes Release 4. The conclusions in this article are drawn from hands-on tests and early beta documentation. It is possible that actual product functions described here may change, or may not be included in the final product. Screen captures may also vary from the screens you will see in Lotus Notes Release 4.''

Let's take a look at several capabilities of Lotus Notes Release 4:
 * The Name and Address Book
 * Administrative Control Panel
 * Multiple passwords on Certifier IDs
 * Single Copy Object Store
 * Database size limits and database security

The Name and Address Book
The Lotus Notes Name and Address Book (NAB), one of the most important databases in a Notes domain, plays many roles. It is a directory service for mail routing and provides the names of users, groups, servers, and certifiers. As a server management tool, it provides information about scheduling replication and mail routing, runs programs automatically, and provides instructions for initiating statistics and alarm reporting performed on a server. Keeping the NAB running smoothly is critical to maintaining a well managed, well run Notes domain.

Managing User Names in the NAB
A user document identifies a Notes user in a domain, as well as defines the home server for each user. (The home server is where the user's mail file is stored.)

User name and group management is easier in Release 4. Now you can accomplish tedious tasks such as deleting a name from the NAB and all instances of that name in additional groups in the NAB by simply deleting the user document.

Once selected, the action to delete the user document from the NAB takes place immediately, affecting all references to this person in all groups in the NAB. What does this mean to server administrators? You are no longer forced to manually look through multiple group documents to find and delete user names.

Admin Proxy Agents, a new feature in Release 4, updates a domain's NAB and Access Control Lists (ACLs). In other words, administrative agents clean up and reconcile all the Name and Address Book documents and ACLs after a user or server is renamed, recertified, or deleted.

Administrative agents relieve you from having to change the Name and Address Book and database ACLs manually. You no longer must seek out each occurrence of a user or server, because the agent conducts the search and makes the change.

Examples of Admin Proxy Agents activities are:
 * Delete user
 * Rename in ACL
 * Copy server's public key
 * Rename user in the NAB
 * Rename server in the NAB
 * Move user in hierarchy

Managing Group Documents in the NAB
Group documents (also called groups) list users, groups, servers, and combinations thereof. They are useful for mailing lists, ACLs in databases, deny access lists, and server access lists.

You'll find it easier to create and manage groups by creating specific group types by category using the following keyword list choices: Use the multi-purpose type for the majority of groups. When you know that you will use a group for a specific purpose, use one of the other choices.
 * Multi-Purpose--Can be used as a distribution list for mail, in an ACL, or in appropriate locations in a server document (Groups migrated from Release 3 will be multi-purpose.)
 * Access Control List Only--ACL only; can't be used as a distribution list for mail
 * Mail Only--For mail only; can't be used to manage an ACL
 * Deny List Only--Used in the restrictions portion of a server document

In Release 4, you can easily add users to a new or existing group by highlighting and selecting names from the NAB's Names view. Figure 1 shows an example of the new interface for working with group documents in the Name and Address Book.

If a name is not listed in the Names view, you can manually type the name. You can delete individual names one at a time by selecting the Remove button, or remove the entire list via the Remove All button.

Server Documents
Server documents define information about an individual server in the Notes domain. A server document is required for each server in a domain.

Because server documents are quite large, Release 4 divides them into collapsible sections for easier viewing and browsing. Document sections and short descriptions are listed below:
 * Basics - Contains server name, domain name, cluster name, administrators, and routing type
 * Server Location Information--Used in setup of remote user documents, e.g., hotel, home, office
 * Network Configuration - Defines enabled port names and addresses
 * Security - Defines public key comparisons during authentication; allows anonymous access
 * Restrictions - Defines who can and can't access the server, who can create databases, who can make replicas, and who can use a server as a passthru server
 * Agent Manager - Defines who can run private agents, restricted and unrestricted LotusScript agents, and daytime and nighttime parameters
 * Contact - Optional fields for server location, department, and description

Connection Documents
Connection documents provide server, domain, and task information for connecting servers to each other for mail routing and replication. Release 4 allows you to create dynamic connection documents based on connection requirement types. Options are: If you select the connection type as dialup modem, the document displays fields that are pertinent to a dial connection - e.g., destination phone number, login script file name, and login script arguments. If you select the connection type as local area network, the information that is unique to a dial connection is replaced by fields for a LAN connection (for example, an optional network address such as 9.19.140.89).
 * Dialup modem
 * Local area network
 * Passthru server
 * X.400
 * Remote LAN service
 * Simple Mail Transfer Protocol (SMTP)
 * X.25
 * cc:Mail

There are instances when you may want to connect two servers that are running different network protocols. In these instances, you can't use network connection documents to directly connect the two servers. Instead, you must use an intermediate server that has both protocols configured on it as a passthru server. A passthru server becomes the intermediate server, routing information between the two servers running different protocols. Passthru servers are defined in a connection document.

Several new fields have been added in the routing and replication section of a connection document. You can specify four different replication types: pull-pull, pull-push, pull only, and push only.

You can include a list of files to replicate in a specific order. All databases with the same replica ID will replicate if nothing is specified in the Files to Replicate field.

There is also a field to set the maximum allowable time for a replication cycle. When the replicator reaches the limit, replication ends, even if all databases have not been replicated and the replication cycle isn't complete. This option helps keep servers on their correct replication schedules.

Server Configuration Documents
Server configuration documents, new in Release 4, are used to set NOTES.INI variables without editing the physical file. Changes made to a server configuration document are written to the NOTES.INI file.

The server periodically reads the server configuration documents and updates NOTES.INI settings. Settings in the NOTES.INI file are overwritten by settings configured in the server configuration documents, and server configuration documents take precedence over settings configured with SET CONFIG commands issued at the server console or remote server console.

You can set the scope of NOTES.INI settings for all servers in a domain, a group of servers, or a single server. You can use an asterisk (*) in the server name field to indicate all servers in a domain, or you can specify a group or individual server. A parameter indicates the last person who made a change and the time the change was made, making it a useful audit-trail tool.

A server configuration document displays only settings previously entered in the server configuration document. It cannot display settings added to the NOTES.INI file during server installation and setup.

Figure 2 below lists a few of the NOTES.INI variables you can set in server configuration documents. (If your browser doesn't support tables, click here to [view the text].) '''Figure 2. Server Configuration Document Variables'''

Access Control List Management
Managing ACLs can be the bane of a server administrator, because you spend countless hours trying to maintain, manage, and control them, only to find that one seemingly innocent change made to an ACL can have disastrous effects throughout entire domains.

Release 4 includes several utilities to ease ACL management. Figure 3 illustrates one of these utilities, the Access Control List interface.



In the ACL control panel, you can:
 * List names in the ACL by access level
 * Classify names in the ACL by type for additional security (unspecified, person, group, group of servers, group of users)
 * See a history of ACL changes - who made the changes and the date and time when changes were made
 * Authorize names listed in the ACL to create personal agents, personal folders/views, and LotusScript agents.

Administrative Control Panel
Administration tasks become much easier with a new feature in Release 4 called the Administrative Control Panel. This panel (shown in Figure 4) provides "one-stop shopping" for virtually all server administrator tasks, including pushbutton access to maintaining users, groups, and servers in the NAB.



In addition, from the Administrative Control Panel, you can access other functions and utilities, including:
 * Working with certifiers (creating, cross-certifying ID files, viewing the certification log, and registering certifiers)
 * Monitoring MAIL.BOX and sending a mail trace to locate and debug mail routing problems
 * Using the remote server console
 * Monitoring administrative databases such as the Notes Log, Catalog, and Statistics; doing statistics and database analysis; compacting databases; creating and maintaining full-text indexing; setting database quotas

Multiple Passwords on Certifier IDs
You can add multiple passwords to hierarchical certifier IDs to protect them from fraudulent use by requiring more than one person to enter a password. This feature enables you to create a list of authorized users who can use the certifier, as well as choose the number of passwords required to access the ID. Each user in the authorized list creates a password on the certifier ID that is not known to the other users in the list.

For example, if there are four names in the authorized list and the number of passwords required is two, then any two in the authorized list must be available to create or recertify IDs. If a user in the authorized list leaves the company or changes jobs and should no longer have certifier access, you can remove that name from the authorized list and add another name. This feature helps maintain certifier security.

Also, in Release 4, if someone fraudulently accesses a certifier and enters an incorrect password, the time delay experienced in the return of the "wrong password" dialog box increases each time the wrong password is entered. This time delay is meant to discourage hackers from trying to guess at passwords associated with the certifier.

Single Copy Object Store
Single Copy Object Store (SCOS) is a space-saving facility allowing storage of a single copy of a mail message sent to multiple users in a special-purpose object store database called MAILOBJ.NSF.

You can configure and enable SCOS in a server configuration document in the NAB. Individual mail databases are manually linked, one at a time, to MAILOBJ.NSF from the server console. Once SCOS is enabled on a server, and mail is sent to two or more people whose mail files are linked to MAILOBJ.NSF, the router separates the message header text from the body of the mail message, sends the header text to the individual mail file, and sends the content to MAILOBJ.NSF. The body text is stored only once, in MAILOBJ.NSF, thus lessening the system burden and saving disk space.

End users are unaware of the fact that there are links between the message content and the header text. They read their mail as if it were stored in their individual mail file.

What happens if a user edits and saves a mail message? The body content is moved to the user's individual mail file, and the pointer to MAILOBJ.NSF is deleted. If a user deletes a mail message, only the pointer is deleted from his or her mail file; the body content still resides in MAILOBJ.NSF. Mail that has been encrypted is not stored in MAILOBJ.NSF, but instead in individual mail files.

To keep the size of object store databases to a minimum, the server program Collect deletes obsolete documents that no longer have pointers associated to the body content because all users have deleted the mail message (the pointer). The Collect server program, by default, runs at 2:00 a.m. on all object store databases on a server.

Database Limit
Database limit represents the maximum size that a database can occupy on a hard disk. Database size in Release 3 is limited to 1 GB. The limit in Release 4 has been increased to 4 GB. When you create a new database, you can choose an option to set the database size up to 4 GB. Once the database size is created, the size cannot be changed.

Being able to establish a maximum database size allows server administrators or database managers to plan for server space and to manage and control database size. In addition, tools are available to help you monitor database size and to set database quotas and warning thresholds.

Local Database Security
You can add local database security, sometimes referred to as local database encryption, to a database to prevent unauthorized local access. When local security is added, Notes encrypts the database using the ID file of the server or user that stores the database, thus preventing someone with another ID from accessing the database from the workstation or from a copy of the database made through the operating system.

Notes encrypts a database by generating a random encryption key, encrypting this key with a public key associated with a selected ID, and appending the resulting key to the database. When a user attempts to access the database locally, Notes provides access only if the private key of the person attempting to gain access can decrypt the appended key.

Much More to Explore
There is so much to explore in Release 4; this article covers only the "tip of the iceberg." The list of new features goes on and on. Here are just a few more to whet your appetite:
 * Field replication instead of document replication
 * Faster algorithm replication and support for multiple replicators
 * Passthru server for remote access - the user connects to multiple servers with a single phone call
 * Less time to start a Notes server - the consistency check on databases is performed at the same time as server initialization
 * Improved message tracing tools to manage message routing
 * New views in the Notes Log (LOG.NSF) for mail routing events and phone calls by date and by user
 * Tools for hierarchical ID conversion and ID recertification
 * Redesigned Notes mail template
 * Retrieve key on the server console
 * Stacked replicas on the work page
 * Additional tabs dynamically added to the work page