Previous Page TOC Next Page



— 16 —


Administering Notes Servers


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


Responsibilities of Server Administrators


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.



NOTEWith the advent of R4, tracking agents becomes more difficult. You can limit agents on a database-by-database basis; if you don’t, 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.

Table 16.1.Administrative tasks schedule.

TaskDailyWeeklyMonthly
Mail routingx
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.

Using Database Libraries


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:

  1. Choose File | Database | New.
  2. Select Database Library as a template.
  3. Enter a server, a database title, and the file name for the new library.
  4. Choose OK.

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:

  1. Select the library database icon.
  2. Choose View | Librarians.
  3. Open the librarians document.
  4. Enter the name of the new librarian.
  5. Close and save the librarians document.

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:

  1. Add the database icon to your workspace.
  2. Select the icon of the database for which you are going to create a new entry.
  3. Choose File | Database | Publish.
  4. Select the library to contain the new entry.
  5. Choose OK.
  6. Enter a description of the database in the Abstract field of the new database entry.

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:

  1. From the mail message, select the database link for the database to be added to the library.
  2. Choose File | Database | Publish.
  3. Select the library to receive the new database entry.
  4. Choose OK.


    NOTEIf 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.


  5. Enter a description of the database in the Abstract field of the new database entry.
  6. Notify the user that you have created the database entry.

As a librarian, you always have the option of deleting a database entry from a library. To delete a library, perform the following steps:

  1. Open the library database.
  2. Select the database entries you want to delete.
  3. Press the Delete key.

Managing Full-Text Indexes


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


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:

  1. Choose File | Tools | Server Administration.
  2. Select the server containing the database to be compacted.
  3. Select the database icon.
  4. Choose Database | Compact.
  5. Select the database from the list presented.
  6. If a database contains a corrupted view, choose Discard View Indexes.
  7. Choose Compact.

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."

Monitoring Modem Communications


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.

Monitoring Modem Activity with the Notes Log


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:

  1. Choose File | Tools | User Preferences from the workstation program running on the server or client to be configured.
  2. Select the Ports icon.
  3. Highlight the COM port corresponding to the modem that you want to monitor. Your screen should resemble Figure 16.3.

    Figure 16.3.
    Configuring ports in the User Preferences dialog box.

  4. Select the COMx Options button.
    The Additional Setup dialog box opens (see Figure 16.4).

    Figure 16.4.
    Set COM port options by using the Additional Setup dialog box.

  5. Select the options Log Modem I/O and Log Script I/O.
  6. Choose OK.

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.

Viewing Modem Statistics with the Reporter Task


The Reporter server task generates a number of useful modem statistics. To view statistics generated by the Reporter task, follow these steps:

  1. Open the Statistics Reporting database (STATREP.NSF).
  2. Choose View | Communications.

Viewing Modem Statistics from the Server


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:

  1. Choose File | Tools | User Preferences.
  2. Select the Ports icon.
  3. Choose Show Status.

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."

Tracing Server Connections


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:

  1. Choose File | Tools | User Preferences from the server (using the Notes workstation program running on the server) or workstation you want to trace.
  2. Select the Ports icon.
  3. Select the port you want to trace.
  4. Click the Trace Connection button.
  5. Select the server to which you want to connect.
  6. The Trace Connection dialog box appears (see Figure 16.5).

    Figure 16.5.
    Setting the information to be collected by the trace collection feature.

  7. Specify the information you want to record in the Notes log. You can select any of the following settings:
  8. Click the Trace button.
    The Trace dialog box displays the steps Notes is taking to make the connection. If the connection attempt is unsuccessful, the Remaining Path box will contain all servers in the connection path.


TIP 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.

Monitoring Key Server Statistics


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.

Checking Memory on OS/2


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.

Checking Memory on Windows NT


Use the Microsoft Windows NT Diagnostics program to view the amount of memory available on a Windows NT machine.

Checking/Freeing Disk Space on the Server


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.



NOTEFor 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.

Monitoring the Number of Users and Transactions


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


Converting the Operating System of a Server


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:

  1. Backup the server's ID file, DESKTOP.DSK, and NOTES.INI.
  2. Install the new operating system and run the notes INSTALL process to place the new server program files on the new server.
  3. Replace the new server's files with the three you backed up in step 1.
  4. Install any add-in tasks that will run in the new server.
  5. Start the new 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.



TIP 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!


Changing the Name or Domain of a Server


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:

  1. Edit the server's NOTES.INI file. Change the DOMAIN= setting to the name of the new domain.
    You also can edit the NOTES.INI file by using the console, with this command:
    
    
    
    SET CONFIG "DOMAIN=domain name"
    
    
    
    
  2. Copy the server document from the original Name and Address Book to the new domain's Name and Address Book.
  3. Change the domain name for the server in the server document.
  4. Edit all connection and network documents that reference this server to reflect the change in domain name.
  5. Move all mail-in database documents for mail-in databases on this server.
  6. Move all person documents for all users who have this server as their home server to the new domain's Name and Address Book. Update each person document and enter the new domain name.
  7. Servers in domains other than this server's new domain should update any remote connection documents that mention this server. Replicate all changes to the Name and Address Books for both domains.
  8. Check all your applications to see whether they assume any particular domain names.
  9. Restart the server.

Removing a Server


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:

  1. Move all databases to a new server. Follow the guidelines in Chapter 17, "Administering Notes Databases," when moving a database.
  2. Make backups of all critical files from this server in case you decide you need to rebuild the server in the near future.
  3. From a different server, edit the Name and Address Book for the domain. Delete the server document, delete the server from all groups, delete any connection documents that mention this server, and erase the server's ID file.
  4. Edit the Name and Address Books from other domains that communicated with this server's domain. Delete the server from any groups, and delete any connection documents mentioning this server.
  5. Replicate any changes to the Name and Address Book.

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.

Changing a Server's Administrator


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:

  1. Edit the server document in the Name and Address book. Enter the name of the new administrator and remove the name of the previous administator.
  2. Remove the previous administrator from any administration groups.
  3. If the administrator's name appears explicitly in the Name and Address Book ACL, remove it.
  4. Remove the administrator's name from any server access lists in which it appears.
  5. Replicate any changes to the Name and Address Book.

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.

Controlling Access to a 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.



TIP 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.


Maintaining Remote Servers


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


Rebooting with a Reboot Utility


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).

Rebooting with Telnet or FTP


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.

Backing Up Servers


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.



TIP 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.

Understanding Server Tasks


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.

Table 16.2. A Summary of Server Tasks.

Server TaskProgram NameDescription
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.

Switching Server IDs


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


NOTESee Chapter 13, "Administrative Tools," for ways to edit the NOTES.INI file.


Cataloging Databases in a Domain


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:

  1. Open the database from your workspace.
  2. Choose Design | Design Properties.
    The Design Properties dialog box opens.
  3. Select Database from the drop-down list.
  4. Select the Design tab. You should see the dialog box in Figure 16.6.

    Figure 16.6.
    The Design tab of the Database Properties dialog box.

  5. Deselect the List in Database Catalog check 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.

Summary


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.

Previous Page Page Top TOC Next Page