This chapter lists all the sundry tasks a server administrator must perform that aren't covered in Chapter 15, "Administering Replication," and Chapter 14, "Administering Notes Mail." The server console and the Name and Address book,
two critical administrative tools with which you must be familiar before reading this chapter, are covered in Chapters 12 and 13. In this chapter you will learn about
Server administrators are the focal point of a Notes support team. Server administrators are responsible for coordinating the activities of the various database administrators and application developers who, in turn, are responsible for databases
residing on Notes servers. In addition, the server administrator is responsible for the overall reliability and performance of the Notes network.
The server administrator should have a clear understanding of all of the tasks that are running on the servers under his care. In addition to the server tasks that run as part of the Notes server, the administrator should know how to start and stop any
add-in programs developed by in-house developers, and how to administer any third-party products running on the server, and should be aware of any agents that are run on one of his servers.
With the advent of R4, tracking agents becomes more difficult. You can limit agents on a database-by-database basis; if you dont, knowing what's running and when is more difficult. Close cooperation between application developers and administrators is essential; monitoring can't be easily automated.
The server administrator must monitor all aspects of a Notes server on a regular basis to ensure reliable operation of the Notes network. Table 16.1 lists the tasks to be monitored.
Task | Daily | Weekly | Monthly |
Mail routing | x | ||
Replication | x | ||
Modems | x | ||
Memory usage | x | ||
Free disk space | x | x | x |
Swap file size (OS/2 only) | x | ||
Server capacity | x | ||
Backup server | x | x (offsite) | x (offsite) |
In addition to the tasks outlined above, the server administrator should run the database Fixup task to correct corrupted databases as needed. If Fixup fails to correct the problems with a database, you will need to restore from a backup.
Chapter 17, "Administering Notes Databases," and Chapter 13, "Administrative Tools," detail the tools available to the server administrator to accomplish these tasks. In summary, the databases that are central to a server
administrator's job include
In addition to these databases, the server administrator should be comfortable using the Server Administration panel, server console, remote console, and administrative agents.
Other chapters cover some of these tasks in detail. See Chapter 15, "Administering Replication," for details on configuring and maintaining Notes replication. See Chapter 14, "Administering Notes Mail," for details on configuring and
maintaining Notes mail.
A database library is a specialized form of a database catalog. The database library is meant to include references to databases that have some common features. For example, you may create one database library for marketing databases and a different
database library for research databases. Each reference to a database contains a brief abstract about the database, database title and replica ID, and buttons that enable a user to access the database and add it to her workspace. Users need only reader
access to use a library.
You use the DBLIB4.NTF template to create database libraries. The person who creates a library is automatically entered as a librarian and given manager access to the database. Figure 16.1 shows a small library database.
Figure 16.1.
A library of Notes databases.
If you choose to use libraries, specify at least one librarian to maintain each library. The librarian may or may not be the server administrator. Only librarians can add database references to a library; users can't add a database to a library. When a
user attempts to add a database to a library, the librarian receives an e-mail message with a reference to the database to be added, enabling the librarian to publish the database for the user.
The librarian for a database should be someone with an interest in or knowledge of the topic areas covered by the library.
To create a database library, follow these steps:
If you are going to create libraries on your server, create a special subdirectory where users can find the libraries. The person who creates the library is given the status of librarian. To add more librarians, follow these steps:
You add entries to a database library in two ways: select and add a database of your own volition, or add a database as a result of a user request. To add a database entry, follow these steps:
You can create a new database entry in a library as the result of a request from a user. You, the librarian, will receive a message in your In Box requesting that you create the new database entry. This allows librarians to control the entries in their
library without being responsible for generating all the ideas for the databases to be referenced. Of course, if you choose to deny a user's request, you should respond to the mail message explaining the reasons for the rejection. To add a database entry
based on a user request, follow these steps:
If the name of the library doesn't appear in the selection list, you need to add the icon for the library database to your workspace.
As a librarian, you always have the option of deleting a database entry from a library. To delete a library, perform the following steps:
As a server administrator, you may not expect to be involved in maintaining full-text indexes. Full-text indexes are primarily the job of a database administrator, who is responsible for creating and deleting full-text indexes for individual databases.
Database managers can also update full-text indexes for their databases. The server administrator can update the indexes of all databases in one batch operation by using the UPDALL server task. It's the server administrator's responsibility to update
full-text indexes on a regular basis.
You can run the UPDALL task in three ways: from the server console, from a program document, and from the NOTES.INI file. From the console, you run UPDALL by typing the following command (you can run UPDALL from a program document by entering this same
information in a program document):
Load UPDALL parameters
These are the parameters:
The default behavior for UPDALL when no parameters are specified is to update all views and full-text indexes on the server. The parameters -v, -r, and -c also can be used with UPDALL to update views on specific databases. See Chapter 17,
"Administering Notes Databases," for details.
Full-text indexes aren't updated automatically as the content in a database changes. Updating a full-text index is a significant drain on system resources, and should be done during off-peak hours. You can control the update frequency for each full-text
index on your server, but you should coordinate the updates with the database managers in control of the databases on your server. You should require database managers to justify specifying an update frequency other than daily or scheduled. This policy
prevent database managers from wasting the server CPU by updating full-text indexes during peak periods. You can select from the following update frequencies:
For details on each of these settings, see Chapter 17, "Administering Notes Databases."
For details on creating a program document to run UPDALL, see Chapter 13, "Administrative Tools."
The third way that you can run UPDALL is by adding an entry to the NOTES.INI file. When you use the NOTES.INI file, you run the UPDALL task on a daily basis. You can control the time of day at which UPDALL runs by editing the ServerTaskAt line. The
default setting is 2:00 a.m.
You also can control whether UPDALL updates views and full-text indexes or just views. To have UPDALL update only views, add this line to NOTES.INI:
Update_Full_Text=1
Compacting databases is primarily a responsibility of database managers. Chapter 17, "Administering Notes Databases," describes in detail the process of compacting databases. As a server administrator, you need to do the following:
You can run Compact from the server console, from a program document, or from the NOTES.INI file. Using the console, you can compact all databases or just databases with wasted (free) space. To run Compact from the console, type
Load Compact >parameter
where parameter is -s percent.
You can specify a minimum percent of free space that will trigger a database compact. Databases with less internal free space than the specified minimum won't be compacted. You should compact all databases with more than ten percent free space. The
default behavior when you specify no parameters is to compact all databases on the server.
You can use either the Database Properties dialog box (click the I tab) or the Server Administration panel to compact a single database. Follow these steps to use the Server Administration panel:
Figure 16.2 shows the steps Notes follows when compacting a database.
Figure 16.2.
The database compaction process.
Because Compact creates a copy of a database before reclaiming free space, you will need enough free disk space on your server to hold a duplicate copy of the largest database on your server.
You can also use the Compact routine to change a database from Release 4.0 to Release 3.x format. At the server console, enter this command:
load compact databasename -r
For details on using Compact to revert databases, see Chapter 17, "Administering Notes Databases."
Historically, modems have been one of the most trouble-prone areas of Notes. A significant amount of setup is required to run a modem successfully, including modem files and scripts. The server administrator needs to ensure on a daily basis that modems
are functioning properly. You can monitor modems as described in the following sections.
The Miscellaneous Events view of the Notes log contains records that can indicate modem problems. By default, only successful modem connections are recorded. To monitor additional information that can help you correct modem problems, follow these steps:
Figure 16.3.
Configuring ports in the User Preferences dialog box.
Figure 16.4.
Set COM port options by using the Additional Setup dialog box.
You should check the Notes log for modem problems everyday. In addition to the miscellaneous events view, you can use the Phone Calls View to see details by individual phone calls.
The Reporter server task generates a number of useful modem statistics. To view statistics generated by the Reporter task, follow these steps:
You can review the current statistics from the console by typing this command:
Show Portportname
To view modem statistics from the workstation program on the server, follow these steps:
You can configure the Event server task to generate alarms that indicate possible modem problems. For complete details on setting up and configuring event monitoring, see Chapter 13, "Administrative Tools." For details on alarms and statistics
specific to modem ports, see Chapter 19, "Supporting Dial-Up Users."
You can collect information that will help you troubleshoot connection problems by tracing a server's attempts to connect to another Notes server. The trace connection feature allows you to see the steps taken to connect to a specific server using a
specific port. You can choose to display the trace information and/or record the information in the Notes log.
To enable the trace connection feature, follow these steps:
Figure 16.5.
Setting the information to be collected by the trace collection feature.
Try tracing connections to various types of servers (LAN connected, different Notes named networks, different domains) to get an understanding of how Notes uses connection and server documents in the Public Address Book.
You also can use the CONSOLE_LOGLEVEL command in the NOTES.INI file to control the amount of information displayed on the status bar when you trace a connection. See Appendix B, "NOTES.INI Parameters," for complete information on the
CONSOLE_LOGLEVEL command.
As a server administrator, you must guarantee that your server has enough memory and disk space to provide reliable and predictable service to your end users. These are the key statistics you should monitor:
Chapter 7, "Determining Hardware and Software Needs," shows the recommended amount of memory for each platform. Memory is critical to the stability and performance of a Notes server; you should monitor the amount of memory being used by a
server at least daily and evaluate your need for additional memory on a weekly basis.
To check the amount of memory being used by a Notes server under OS/2, use the Show Memory command at the server console. If your Notes server doesn't have adequate memory installed, you should see a large swap file. The OS/2 swap file
(c:\os2\system\swapfile.dat) serves as a temporary storage area for programs and data that can't be held in memory. If your server swap file is greater than 2 megabytes in size (the default initial size), your Notes server is memory constrained. You can
probably live with a swap file up to 20 megabytes in size, although any swapping is detrimental to server performance. An OS/2 application server, such as a Notes server, should never need to swap memory to disk. This recommendation is in direct contrast
to recommendations for OS/2 workstations, where some swapping is quite acceptable. If your swap file grows beyond 20 megabytes and you feel that you have enough memory in the server, check with IBM to ensure that there are no current problems with OS/2
causing large swap files.
You can view the size of the swap file by using the dir command at an OS/2 command prompt or by using the Notes Statistics and Reporting database. If you are using the Reporter task, you can look up the size of the swap file
in the Statistics and Reporting database.
You can also check the size of the swap file from the console by typing this command:
show stats
The show stats command displays the amount of free memory in the Mem.Availability statistic. The Mem.Availability statistic has three possible values: painful, normal, and plenty. The value of Mem.Availability determines the amount of disk caching that
Notes automatically configures. The amount of memory that Notes sets aside for disk caching is controlled by the NSF_BUFFER POOL SIZE setting in the NOTES.INI file. Under low-memory conditions, Notes automatically shrinks the amount of memory set aside as
a cache. The size of the cache can range from 192K under painful memory conditions to 6MB under plentiful memory conditions.
You can't increase performance in low-memory conditions by increasing the size of the disk cache. If you attempt to reserve memory for disk caching in low-memory situations, you will, in fact, slow the server. If your disk cache is being swapped to
disk, as would happen under low-memory conditions, you are forcing Notes to write data to disk twice instead of once. Notes writes data to the cache, causing a disk write, and then transfers the data from the cache to the actual database, causing a second
disk write.
Use the Microsoft Windows NT Diagnostics program to view the amount of memory available on a Windows NT machine.
For each server that you administer, you should maintain a schedule of anticipated disk space needs. You should be able to anticipate the number of users who will be added to mail files, and the amount of disk space you would need to set aside for those
additions. Work with application developers and database managers to track the anticipated needs of their databases on a monthly basis. Monitor the Notes server's available disk space on a weekly basis to ensure that you have enough disk space to meet
future requirements. You can monitor free disk space using the console or the Reporter task. From the console, type this command:
show disk space
The Reporter task (covered in Chapter 13, "Administrative Tools") collects information on free disk space in the Disk Statistics section of the System Statistics report in the Statistics and Reporting database.
For rough formulas that you can use to calculate disk space requirements, see Chapter 7, "Determining Hardware and Software Needs."
If you need additional disk space on a server, you can add disk space or delete items from the server. To free disk space, you can delete or move databases or possibly run the Compact program. System administration databases are primary disk hogs, as
they collect historical information. You should consider archiving or deleting sections of the Notes log, database catalog, and Statistics and Reporting database.
To reduce the size of the Notes log, you can disable modem logging if you aren't experiencing modem problems. You also can limit the size of the Statistics and Reporting database by limiting the number of servers and statistics that are tracked.
Limiting the size of the Notes log and the Statistics and Reporting database should be considered temporary solutions at best. Even though you can turn off modem logging, eventually you will need to log modem activity again. If you haven't taken the steps
necessary to acquire additional disk space, you will spend a considerable amount of administrative effort to solve problems because you can't track modem activity.
Instead of attempting to limit the size of Notes databases, consider moving non-administrator databases to servers with available free space. Chapter 17, "Administering Notes Databases," details the steps you should follow when moving a
database.
You also should carefully review the disk space being used by non-Notes resources on the server. It may be possible to slim down the installation of your operating system and supporting utilities.
In addition to monitoring the amount of memory and disk space being used by Notes, you should monitor the number of users and transactions a Notes server is servicing. You can monitor these statistics with the Statistics and Reporting database, or from
the console by typing this command:
show stats
The statistics you should monitor are
Monitor the performance of your server by attempting to use different applications on the server as well as monitoring specific server statistics. You can monitor these statistics from the console command by typing
show stats
or from the Statistics and Reporting database (if you are running the Reporter task). The statistics that can indicate performance problems are
Many organizations that use OS/2 as a Notes platform may be considering switching to Windows NT, as Windows NT gains more acceptance and more products are written for that platform. Regardless of the operating system you are currently using, or the one
you want to use, you can perform the following steps to change the operating system of a server:
If you don't have two server machines available at a single point in time, completely back up the old server before installing the new operating system. After installing the new operating system, make any custom changes based on your backed-up files.
If you suspect that hardware problems are causing your Notes system to be unreliable, set up a new server machine to replace the current machine. Follow the steps in this section, but just use the same operating system!
The most common reason for changing a server name is to upgrade a server from flat naming to hierarchical naming. You also may want to rename a server when you dedicate the server to a different task or relocate the server to a new geographical region.
In any case, whenever you change the name of a server, you must recertify that server ID. See Chapter 18, "Administering Notes Security," for details on renaming and recertifying the server IDs. Before changing a server's name, be sure that you
understand all the implications of a name change. When a server's name is changed, every reference to the server must be changed throughout your entire network. All ACLs, connection documents, database formulas, and LotusScript programs must be checked and
updated (the Administration Process can help with some of these tasks; see Chapter 18 for details). Users have to update their database icons for databases on the server.
The primary reason to change the domain name of a server is to consolidate multiple domains into a single domain. Domains are simply a logical collection of servers. There are no limitations on which Notes servers may or may not be in a single domain.
Servers may be on the same network and be in separate domains; servers on different networks can be in the same domain.
Make sure that you have a copy of the Name and Address Book from the new domain available before changing the domain of a server. To change the domain of a server, follow these steps:
SET CONFIG "DOMAIN=domain name"
Administration is easier when fewer servers exist to monitor. When larger, more robust, more scaleable servers (like SMP machines) become available and more affordable, you should have opportunities to consolidate several servers into a single server.
When consolidating servers, remove all references to servers that are being removed from the network. As with changing a server's name, make sure that you understand all the implications of removing a server before proceeding. When you remove a server from
the network, you must delete every reference to the server throughout your entire network. Check and update all ACLs, connection documents, database formulas, and LotusScript programs (the Administration Process can help with some of these tasks; see
Chapter 18 for details). Users must update their database icons for databases on the server.
To remove a server, follow these steps:
Let the server continue to operate for a short period of time, to allow all users a chance to migrate their references to any databases on the new server.
You may need to change a server's administrator when someone changes jobs or leaves the company. By planning ahead, and having at least two administrators for every Name and Address Book, you can ease the transition. You should attempt to replace the
administrator as soon as possible. To change a server's administrator, follow these steps:
If you are changing the server's administrator because the administrator left the company, you should follow the guidelines in Chapter 18, "Administering Notes Security." If the administrator has simply changed positions, you may need to
assign a new home mail file. Follow the guidelines in Chapter 14, "Administering Notes Mail" for guidelines on changing a person's home mail server.
Administrators control access to a server by editing the server access lists contained in a server document for that server. Chapter 18, "Administering Notes Security," contains complete information on server access lists. In summary, there
are four primary server access lists:
Following are the valid entries for a server access list:
If you make a change to a server access list, you should restart the server to put these changes into effect. If you change groups or wild-card entries, however, those changes are recognized without restarting the server.
Only those people listed as administrators in the server document can use the remote server console for the server.
The use of server access lists can hurt performance on your server. If you are using server access lists, every access by every user must be checked against each list. If you want to use server access lists while minimizing the performance impact, create a group for each server, containing frequent users for that server. List this group first in all access lists to speed access for users that frequently use a server.
Administration costs are eased when you locate all of your servers in a single office, but this setup isn't possible for all organizations. Chapter 5, "Building a Deployment Plan," provides guidelines for placing remote servers.
The primary tool for a server administrator to administer a remote server is the remote server console. To use the remote server console, an administrator's name must appear in the Administrators field or in a group in the Administrators field for that
server. Chapter 13, "Administrative Tools," covers the remote server console in detail.
Although the remote server console is your primary tool for managing remote servers, sometimes you may want to reboot a remote computer or access the file system on that computer. The tools you should consider, in addition to the remote console, are
For many operating systems, you can build your own reboot utility. For example, under OS/2, the SETBOOT command (which can be entered at any command line) reboots the server. You could place the SETBOOT command in a batch file and launch the batch file
from a program document. The following code line is an example of a batch file that you could use for this purpose. This batch file reboots an OS/2 server from drive C:.
SETBOOT /IBD:c
Commercially available reboot utilities are available, such as the Notes Shutdown and Reboot Utility from CleverSoft (http://WWW.Cleversoft.COM/Cleversoft). The Cleversoft reboot utility is also
available through CompuServe (Go LOTUSC).
Telnet and FTP are TCP/IP utilities that can give you access to an operating system command line and transfer files. If you install Telnet and FTP servers on a Notes server, make sure that they are password-protected and that these servers can't be
accessed by external companies. There are several known ways to gain access to a server that is running Telnet or FTP server programs. Notes security can be compromised if non-administrators have access to the operating system and file system.
You should back up your Notes servers on a daily basis. The goal of your backup plan should be to minimize the amount of data lost in a system crash, and the effort required to restore the Notes network to working order.
Unlike most major relational database products (such as IBM's DB2 or Oracle), with Notes you can't guarantee that no data will be lost when a database is corrupted. The best defense you have against losing up-to-the-minute data is keeping at least one
replica copy of each database. You can keep replica copies of key databases updated on an hourly basis, minimizing the number of changes that would be lost in a system crash. The replica would have all changes except those that happened since the last
replication. But you can't rely solely on replication for your backups, because a damaged database can sometimes replicate its damaged parts to other databases. Part of your backup plan must include backing up to tape.
In many circumstances, corrupted databases can replicate their corrupted portions to other replicas. Like a virus, a problem with one database can quickly spread to other replicas. The only solution to this problem is to monitor your databases frequently, and keep a non-corrupted backup.
The recommended method for creating backups depends on your network topology and uptime requirements. If you have a hub-and-spoke topology, the hub is a natural place to keep a replica of every database in your network. While this strategy might seem
like a natural solution, proceed carefully before blindly replicating all databases to the hub. The hub is often the first server to become overloaded. To maximize your chances of having a non-corrupt database you can use to restore, decide which databases
are truly mission-critical, and back up these databases as infrequently as possible (to avoid replicating corrupted documents) to an off-site, secure server.
In any case, you may not be able to back up databases directly from the hub server if you have a requirement to provide service 24 hours a day, 7 days a week, because Notes keeps several key files open while the server is running. Even though there are
several tape backup products that can back up open files, if you want to guarantee absolutely that your backup isn't corrupted, you must shut down the Notes server before backing it up. Many organizations have backed up Notes servers for years without
shutting them down, with no problems. Though there are no guarantees, you can decide whether the risk is great enough to warrant the expense of either shutting down the server or buying a dedicated backup server.
The following list details the basic elements of a backup strategy:
Don't forget to test your restore procedures using an actual backup of a Notes database. You should test by restoring a database, a whole directory, and a whole drive from your taped backups.
Organizations serious about minimizing downtime of their Notes servers should maintain a hot backup server that can be called into duty when a Notes server's hardware fails. A hot backup server is very much like a hub server, except that the hot
backup server is available to be a substitute for any other server that fails.
A hot backup server should contain replica copies of all the databases on the network. This setup enables you to substitute the hot backup for any database on your network. A server's identity is determined by the local NOTES.INI file and the local ID
file. To substitute the hot backup for another server, shut down the hot backup, replace its NOTES.INI and ID files with a backup copy from the failed server, and reboot the hot backup server. Remember to keep a copy of personal mailboxes on the hot backup
server, or you can't substitute the hub backup server for a home server. This problem is especially crucial considering the fact that a home server, a server that stores users' mailboxes, is often the most critical server in a network.
The Notes server is actually a collection of tasks that run under the control of the main server program. You can configure the server program to run any of these tasks at server startup, at a specific time, or on command. If you want to run a task at a
specific time, you can use the ServerTaskAt setting in the NOTES.INI file or create a program document in the Public Address Book. You also can run your own custom command programs from program documents in the Public Address Book. The types of programs
that you can run include:
Table 16.2 contains a summary of each server task, its program name, and its purpose.
Server Task | Program Name | Description |
Administration Process | AdminP | Propagates name changes for users and servers. Used for maintaining ACLs and migrating from flat to hierarchical naming. |
Agent Manager | AgMgr | Responsible for running database agents for databases on a server. |
Chronos | Chronos | Maintains full-text indexes that have update frequencies of hourly, daily, or weekly. |
Database Cataloger | Catalog | Updates the database catalog. |
Database Compactor | Compact | Reclaims disk space by eliminating unused space in databases. |
Database Fixup | Fixup | Fixes corrupted databases. |
Designer | Design | Copies changes from database templates to all databases that inherit changes from that template. |
Event | Event | Generates server events reports. |
Indexer | UPDALL | Updates all views and/or full-text indexes for all databases on a server. |
Object Store Manager | Object | Maintains mail-in databases and mail files that use shared mail. |
Replicator | Replica | Propagates changes to databases to other Notes servers. |
Reporter | Reporter | Generates statistic reports to the Statistics and Reporting database. |
Router | Router | Routes mail. |
Statistics | Stalog | Generates database statistics to the Notes log. |
Stats | Stats | Used at the console with the Show Stats command to view current server statistics. |
Chapter 13, "Administrative Tools," gives complete details on how to run these tasks from program documents, the NOTES.INI file, and the server console.
The Notes workstation program defaults to the server ID when used on a Notes server. An administrator may wish to switch to his administrative ID to read or send mail, as a requirement for using some applications, or to maintain a correct audit trail.
You could switch IDs for a single session or permanently.
To use your own ID, choose File | Tools | Switch ID and select your personal ID file. When you have completed your task, remember to switch back to the server ID.
You can permanently change the default ID for the workstation program on a server by editing the NOTES.INI file. You may want to do this if the administrator is using a server as his workstation (not recommended) or if a particular administrator often
needs to switch IDs at a server. To specify a different default ID for the workstation program, add the following lines to the NOTES.INI file.
ServerKeyFileName=Server.ID KeyFileName=User.ID
Where Server.ID is the server ID file and User.ID is the administrator's ID file.
On a Macintosh, specify the path. For example,
KeyFileName=NOTES:ADAHL.ID.
On UNIX, specify the full path and name for the ID name. For example,
KeyFileName=\HOME\NOTES\SERVER.ID
On NetWare, specify the mapped network drive corresponding to the directory containing the ID file. For example,
KeyFileName=G:\NOTES1.ID
On Windows, specify the full path and file name, including the drive letter. For example,
KeyFileName=C:\NOTES\USER.ID
On OS/2, specify the path, file name, and drive letter. For example,
KeyFileName=C:\NOTES\DATA\USER.ID
See Chapter 13, "Administrative Tools," for ways to edit the NOTES.INI file.
You can use the catalog server process in conjunction with the database catalog (CATALOG.NSF) to build a list of all databases in a domain. The catalog server task runs, by default, at 1:00 a.m. every day. The catalog server task scans all databases on
the server, deletes entries from the database catalog for any databases that have been deleted from the server, and adds entries to the database catalog for new databases. Database managers and designers can prevent a database from being listed in a
catalog by using the Design Property dialog box. Follow these steps:
Figure 16.6.
The Design tab of the Database Properties dialog box.
As a server administrator, you should coordinate the contents of the database catalog with the individual database managers in your organization. If a database catalog grows to an unusable size, screen out databases that don't need to be in a catalog.
To create a catalog of databases in an entire domain, create replicas of the database catalog on every server in the domain.
Don't use the database catalog as your sole notice to users that a database is going to be moved or deleted. See Chapter 17, "Administering Notes Databases," for details on moving Notes databases.
The server administrator is the coordinator of all activities for your Notes servers. Other administrators, database managers, and certifiers should coordinate their activities through the server administrator. The server administrator is responsible
for maintaining a reliable Notes network.
The server administrator needs to back up the server regularly, monitor access to the server, and update the design of databases, with input from application developers.
The next two chapters detail the responsibilities of database administrators and certifiers. A Notes server administrator should have an understanding of every task that a database administrator or certifier performs.