Administering
This documentation provides information about the administration tools for managing and monitoring servers and databases.
- Administration tools
  Topics in this section describe the tools you can use to administer a Domino® server.
- Managing users
  The Administration Process helps you manage users by automating many of the associated administrative tasks. For example, if you rename a user, the Administration Process automates changing the name throughout databases in the Notes® domain by generating and carrying out a series of requests, which are posted in the Administration Requests database.
- Monitoring servers
  This section describes how to use the tools and features that help you monitor a Domino® system.
- Managing servers
  Manage Domino® servers by performing any of these tasks.
  - Changing the server administrator
    If the name of the former administrator is explicitly listed in the access control list (ACL) for the Domino® Directory, delete the name of the former administrator from the ACL. Add the name of the new administrator and assign the administrator Manager access.
  - Setting and managing passwords for the server console
    Set server console passwords to protect against unauthorized use of the server console.
  - Decommissioning a Domain Search server
    If you want the server that creates full-text indexes of the Domino® domain to resume duty as a regular Domino server, remove it from the appropriate group in the Domino Directory, edit its Server document, and then delete some files from its directory structure.
  - Decommissioning a server
    You use the Decommission Server Analysis tool when you are consolidating existing servers and/or permanently removing a server from service. Whether you are combining two servers into one server or renaming a server, the result is the same -- the old server name is replaced with the new server name.
  - Deleting a server name
    You can use the Administration Process to delete references to a server from the Domino® Directory, and from database ACLs and Extended ACLs. The Administration Process automatically deletes mail-in database documents and cross-certificate documents as necessary during the Delete Server process.
  - Dropping user sessions on a server
    Dropping user sessions from a server may be useful when you need to make a database or server temporarily unavailable to correct a problem; users can reconnect after you are ready. You can drop one user session or all user sessions for the current database, or selected user sessions, from the server.
  - Finding a server name in the domain with the Domino® Administrator
    You can search for a server name in the domain and then view a log that includes document links and directory links to each occurrence of the server name.
  - Recertifying a server ID
    Use the original certifier to recertify a server ID that has a certificate that is about to expire.
  - Uninstalling a Domino® partitioned server
    You can remove all server partitions from a computer or you can remove just one server partition.
  - Reinstalling or moving a Domino® server from one computer to another
    Use this procedure to reinstall a server if an error occurs and the installer does not complete during the install of an incremental installer, or if the Domino® server is crashing and troubleshooting does not reveal the root cause.
  - Transaction logging
    Domino® transaction logging captures changes made to a database and writes them to a transaction log. The logged transactions are then written to disk in a batch, either when resources are available or when scheduled.
  - Installing and running NSD as a Microsoft™ Windows™ service
    Installing and running NSD as a Microsoft Windows service is no longer available as of Domino 10.
  - Setting up a Fault Reports database
    The Notes/Domino Fault Reports database stores data that is collected at the time of a server crash. Data is collected from both the client and the server and can then be used to measure client reliability and determine the areas where problems exist.
  - Client and server diagnostics
    Use these tasks to perform client and server diagnostics to collect diagnostic information after a server or client crash.
  - Collecting diagnostic information after a server or client crash
    The automatic diagnostic collection tool collects diagnostic data after server and client crashes and sends the collected data to a mail-in database when the server or client restarts. You can then use the collected data to determine the cause of the crash.
  - Using the IBM_TECHNICAL_SUPPORT directory
    The IBM_TECHNICAL_SUPPORT database contains data that has been collected using the Domino® Configuration Collector and the Automatic Diagnostic Data Collection tool. It also includes system information files and documents that have been exported from the Domino Directory and saved as .dxl documents using the Save command entered at the Domino server console.
  - The Domino® server log file (LOG.NSF)
    Every Domino® server has a log file (LOG.NSF) that reports all server activity and provides detailed information about databases and users on the server. The log file is created automatically when you start a server for the first time.
  - Controlling the size of the log file
    By default, the log file (LOG.NSF) records information about the Domino® system.
  - The Domino® Web server log (DOMLOG.NSF)
    You can log your server activity and Web server requests to the Domino® Web server log (DOMLOG.NSF) database. This option may be preferable if you want to create views and view data in different ways.
  - Using console log mirroring
    Console log mirroring causes a new server thread to be created which monitors all messages written to the Console Log file and duplicates these messages into another file. When this new file is filled, the thread closes the mirrored file and creates a new file into which subsequent messages are written. You can delete the closed mirrored files at your discretion.
  - Using the Domino® Configuration Tuner to evaluate server settings
    The Domino® Configuration Tuner (DCT) evaluates server settings according to a growing catalog of best practices. All servers in a single domain can be evaluated together. DCT generates reports that explain the issues DCT uncovers, suggests mitigations, and provides references to supporting publications.
  - Activity Logging
    You use activity logging to collect information about the activity in your enterprise. You can use this information to charge users for the amount they use your system, monitor usage, conduct resource planning, and determine if clustering would improve the efficiency of your system.
  - Managing a cluster
    After you have set up a cluster, you can perform tasks to manage it.
    - Balancing the workload in a cluster
      After monitoring your cluster and determining that you want to make an adjustment, you can perform the following tasks to better balance the workload across the servers in a cluster.
    - Improving server availability in a cluster
      Clusters are designed to improve server availability.
    - Managing failover in a cluster
      When you set up a cluster, you create replicas of databases so that users fail over automatically to a different replica if the database or server they try to access is unavailable.
    - Streaming cluster replication
      Streaming cluster replication (SCR) takes advantage of the fully-connected nature of clusters and data streaming to produce a low-overhead cluster replicator.
    - Managing replication in a cluster
      You should use both cluster replication and standard replication in a cluster and run them both at the same time. Cluster replication is the primary means of replication in a cluster, while standard replication updates any databases that the Cluster Replicator couldn't update.
    - Configuring and controlling cluster replication
      When you add a server to a cluster, Domino® starts the Cluster Replicator automatically. Each time you start the server, the Cluster Replicator starts. You can also control cluster replication in various ways, such as disabling, pausing, and resuming it.
    - Creating configuration settings for all servers in a cluster
      If there are configuration settings that you want to apply to some or all servers in a cluster, you can create a Configuration Settings document that applies to the servers you want.
    - Managing database availability in a cluster
      There are three database attributes that let you specify whether a database is available for user access.
    - Adding a server to a cluster
      Use the administration server when adding a server to a cluster. The administration server does not have to be part of the cluster.
    - Removing a server from a cluster
      Use the administration server when removing a server from a cluster. The administration server does not have to be part of the cluster.
    - Moving a server from one cluster to another
      To move a server from one cluster to another, you simply add the server to the new cluster. Domino® automatically removes the server from the old cluster.
    - Viewing information in the Cluster Database Directory
      The Cluster Database Directory contains one document for each database in the cluster. The document tells you such information as the server, path, and replica ID of the database; whether cluster replication is enabled for the database; and whether the database is out of service or pending delete. The Cluster Manager and the Cluster Replicator use this information to determine if the database is available and how to access it during failover and cluster replication, respectively.
- Managing databases
  Topics in this section describe how to set up and manage Domino® databases.

Improving server availability in a cluster

Clusters are designed to improve server availability.

To configure a Domino® server for clustering, specify a default port in the server's NOTES.INI file by using the following setting:

Server_Cluster_Default_Port=portname

.

When you specify a port, you limit cluster replication to that specific port even if the port has failed. If the setting Server_Cluster_Default_Port= is not defined, the standard server search algorithm is used and all ports are tried. If the designated port fails, that is, the port specified in the Server_Cluster_Default_Port= setting, the server may be accessible from another port.

You can allow the use of other ports by entering this setting in the server's NOTES.INI file:

Server_Cluster_Auxiliary_Ports=portname

Note: If you do not specify a default port in the setting Server_Cluster_Default_Port=, all ports are tried.

The Server_Cluster_Auxiliary_Ports= setting can be set to any one of these values:

Blank -- Do not specify an auxiliary port. The user sees no change in the existing behavior.
* (asterisk) -- Specify * in the Server_Cluster_Auxiliary_Ports= setting. All ports are checked if the server specified in the setting Server_Cluster_Auxiliary_Ports= cannot be reached.
List of port names separated by a comma -- Specify a comma delimited list of port names in the Server_Cluster_Auxiliary_Ports= setting. The ports in the list are checked for the desired server.