NetWare 4.1 Server Maintenance Using DSMAINT.NLM This document explains how to use the DSMAINT.NLM utility when shutting down a server temporarily, when upgrading the server hardware, and when recovering a failed server. It also explains DSMAINT's log file options. DSMAINT.NLM provides control of Novell Directory Services (NDS) when you need to bring down a NetWare 4.1 server for maintenance operations. DSMAINT includes two pairs of options that address two cases of planned server outages: shutting down a server temporarily, and upgrading server hardware. A third option allows you to use DSMAINT to recover a server from an unplanned outage. For this to work, you need a current backup of the server-specific information files. These server-specific information files are provided as a major resource when you use the new version of the file system Target Service Agent (TSA) for NetWare 4.1 servers (TSA410.NLM). With this TSA loaded, SMS-based backup programs display "Server Specific Info" in the list of available resources. Selecting "Server Specific Info" packages critical server information into five files that can be backed up and subsequently used for recovery purposes: SERVDATA.NDS contains server-specific NDS information. The file is used by the INSTALL.NLM utility to recover from an unplanned server failure. This is the file that allows trustee assignments and other NetWare information to be preserved. The server recovery procedure given later in this document show how to use this file to recover from a server failure in a multiple-server environment where replicas exist on other servers. DSMISC.LOG is a text file containing a list of replicas, including replica types, which the backed up server held at the time of backup. It also provides a list of the other servers that were in the failed server's replica ring. DSMISC.LOG is used in the restore procedures to provide helpful information needed to prepare NDS for recovery of the failed server. VOLSINFO.TXT is a text file containing needed information about the server's volumes, including name space, compression, and data migration information, at the time of backup. This file can be used during restore procedures to provide helpful information in preparing volumes correctly for a restore. STARTUP.NCF is the NetWare server boot file that loads the NetWare server's disk driver and name spaces and some SET parameters. AUTOEXEC.NCF is the NetWare server executable batch file, located in the NetWare partition of the server's disk, used to load modules and set the NetWare operating system configuration. Note: For NetWare 4.1 servers, you need TSA410.NLM version 4.14, DSMAINT.NLM version 4.9? (dated 10-2-96) and DSBACKER.NLM version 4.96 (dated 6-26-96). In NetWare 4.11 ("Green River"), the DSMAINT functions are incorporated into the INSTALL.NLM utility. Because DSMAINT deals with the NDS information on a specific server, it is run from hat server's console. You might want to copy DSMAINT.NLM and DSBACKER.NLM into the server's SYS:SYSTEM directory so the utility is available. (DSMAINT.NLM autoloads DSBACKER.NLM when needed.) Maintaining Server Object References During a Brief Shutdown At times, it is necessary to remove a NetWare Server object from the NDS tree for a brief period of time. For example, if an authentication key is corrupted, it is necessary to reinstall NDS on the server. During the uninstall process, the Server object is removed from the tree and other NDS objects that reference the Server object in their mandatory attributes can become Unknown objects. A similar type of problem can occur with services such as printing that are associated with a physical server. With DSMAINT, you can avoid losing objects and ease reinstallation by substituting references to the server with references to another object that you create for this purpose. After reinstalling NDS on the server, you can use DSMAINT to replace these references to the server in other objects' Host Server, Host Device, or Message (Default) Server attributes. Procedure. Following are the steps to use DSMAINT.NLM to restore server references so that a corrupted NDS database can be removed and then cleanly re-installed without losing important references. 1. Check for replicas on the server and make a note of what they are so you can re-establish the replicas later. Remove all replicas from the server. If the server holds any master replicas, switch them to another server in the replica ring. 2. Load DSMAINT.NLM and select the "Replace Server References" option. For Replacement Object, specify another object for "holding" the server references. The object you use must not be a NetWare Server object. It can be an existing User object, such as the one you have logged in as. Enter the full distinguished name of the object; for example, .CN=Admin.O=ABC. For Container Name, enter the distinguished name of the container where you want to begin searching for objects that reference this server's NetWare Server object. In most cases, this would be [Root] to avoid missing any references that may be located separate from the server. 3. Load INSTALL.NLM and remove NDS from the server. From the Installation Options menu, select "Directory options (install NetWare Directory Services)". Then select "Remove Directory Services from this server". Do not perform any partition operations until the replica rings this server was involved in have finished resynchronizing. 4. In INSTALL.NLM, re-install NDS on the server. From the Installation Options menu, select "Directory options (install NetWare Directory Services)" and then select "Install Directory Services onto this server." Place the server in the same location in the tree that it was in previously. Note: DSMAINT automatically removes volume IDs from the physical volumes on the server so that Volume objects are not removed during an uninstall. When NDS is re-installed on the server, the volume ID link between the physical volume and the Volume object is re-established. If problems still exist with the volume ID, the latest DSREPAIR should resolve this issue. 5. Load DSMAINT.NLM and select the "Restore Server References" option to reverse the substitutions made previously in Step 2. Enter the same Replacement Object and Container Name as in Step 2. 6. Check the server for proper functionality and re-establish replicas. Verify that the server is fully functional by printing print jobs, checking default server attributes, and so on. Use Partition Manager to re-establish the replicas previously held on the server. Upgrading Server Hardware There are times when a server requires an upgrade that does not affect the server as an NDS object. For example, the SYS volume may be physically located on an old hard disk drive that needs to be replaced, or the entire server hardware may need to be upgraded from one machine to another. In these situations, you no longer need to uninstall NDS from the server. You can use DSMAINT to save NDS information in preparation for the planned hardware upgrade of the server. After the upgrade, you can restore this NDS information to the server with DSMAINT. Before you run DSMAINT, you should have a current backup of the entire server. The "Prepare NDS for a hardware upgrade" option prepares the NDS information on this server prior to the upgrade. When you select this option, DSMAINT creates a file called BACKUP.DS in the server's SYS:SYSTEM directory. This file stores all the NDS information for this server, including replica information, the .NDS files, streams files, and so on. The BACKUP.DS file should be included in file system backup procedures before bringing the server down. Using this option also locks and disables NDS on this server to prevent any data changes from taking place. To other servers that normally communicate with this server, the server appears to be down. Any NDS information that is normally sent to the locked server is stored by other servers in the tree; when the server comes back online, this "stored" information is used to resynchronize the server. Because other servers in the tree are expecting the server to come back online quickly, you should not plan to take several days to upgrade the server. Complete the upgrade promptly and restore NDS information on the server as soon as possible. The "Restore NDS after a hardware upgrade" option uses the BACKUP.DS file created by the "Prepare NDS..." option to restore NDS information on this server. Before the NDS information is restored, DSMAINT verifies that the server is in the same relative state as before the upgrade. DSMAINT verifies that the server's object and authentication keys still exist and that the server still exists in all the replica rings for copies that were on this server before the upgrade. It is important that NDS partition and replica information remain consistent during the entire upgrade process. No replicas should be added or removed, nor should any replica/partition types be changed during this time. Likewise, no existing servers should be uninstalled and reinstalled, nor should any new server be installed until the Prepare and Restore procedure is complete. If consistency of the tree (including partitions, replicas and placement of replicas, and servers) is not maintained, the DSMAINT verification process will return a -601 error during the Restore phase and the process cannot be completed. Procedure. Following are the steps to use DSMAINT.NLM to maintain NDS information during a server hardware upgrade. 1. Note the server's name and internal IPX number. You will need to re-enter the same server name and internal IPX number after the hardware is upgraded. 2. From a client workstation, log in to the server as Admin or equivalent. Because the "Prepare NDS for a hardware upgrade" option disables NDS on the server, any user or service attempting to access the server after you select this option will be unable to do so. Be sure to log in before you run DSMAINT. 3. Disable user logins and clear all connections except the Admin user. 4. At the server console, load DSMAINT.NLM and select the "Prepare NDS for a hardware upgrade" option. The BACKUP.DS file is created in the server's SYS:SYSTEM directory. Exit DSMAINT when this process is completed. At this point, the server still exists in the NDS tree. However, other servers that share in partition and replica operations with this server report a -625 error attempting to communicate with this server. This server's NDS object should not be deleted from the NDS tree. 5. Use an SMS-compatible backup program to do a full file system backup of the server's volume(s). A complete backup of all data is strongly suggested even if the server's hard drives are not being replaced. 6. Copy the BACKUP.DS, DSMAINT.NLM, and DSBACKER.NLM files to another server on the network. Use the MAP command to map a drive to a directory on a server other than the one you are going to upgrade. Enter a username and password as prompted to complete the mapping. For example, if you are copying the files from SRV1 to SRV2, the command would be: MAP G:=SRV2/SYS:SYSTEM/SRV1 Then copy the three files listed above to drive G using the COPY command. 7. Bring down the server and perform the hardware upgrade. 8. Load INSTALL.NLM and install the server by itself into a temporary NDS tree. When prompted in INSTALL, enter the same server name and internal IPX number that the server had previously. After INSTALL copies the preliminary files, the prompt to "Select a directory tree" is displayed. Press to create a new tree to temporarily hold the server. This will allow you to log in and copy files to this server. The temporary tree will be removed in Step 10. When prompted, insert the NetWare License diskette for the server. Exit INSTALL when the installation is complete. 9. Copy BACKUP.DS, DSMAINT.NLM, and DSBACKER.NLM into the server's SYS:SYSTEM directory. Again, map a drive to the newly-installed server. Since the server is in a separate NDS tree, this will be a bindery-based mapping. Then copy the files back from the server you copied them to in Step 6. 10. Load INSTALL.NLM and remove NDS from the server. From the Installation Options menu, select "Directory options (install NetWare Directory Services)". Then select "Remove Directory Services from this server". This takes the server out of the temporary NDS tree and eliminates the tree. While in INSTALL, view the AUTOEXEC.NCF file and verify that it contains the correct server name, internal IPX address, and default time server type. These settings should be the same as they were before you ran DSMAINT on the server. 11. Load DSMAINT.NLM and select the "Restore NDS following a "hardware upgrade" option to restore the correct NDS information to the server. This restores the correct NDS information from the BACKUP.DS file to the server. 12. Bring down and restart the server. 13. Load the file system TSA by typing LOAD TSA410.NLM. Using an SMS-compatible backup program, restore the file system data for each volume affected by the hardware upgrade. When setting up the restore session, go into Custom Restore and, under "How to scan the session to be restored", set the "Delete existing trustees before restoring" option to YES. This will purge existing trustees before restoring the backed-up trustee assignments from the backup. (Third-party backup programs might not have this option. If this is the case, type LOAD DSREPAIR at the server console and choose the "Unattended full repair" option. This includes the option to purge invalid trustee information on the server's volumes.) Note: If you don't use the "Delete existing trustees before restoring" option, you may have to manually remove trustee assignments that are made by default during the server reinstallation. For instance, by default the container object into which a server is installed receives Read and File Scan rights to the server's SYS:PUBLIC directory. If these rights had been previously removed, you will need to remove them again after the server upgrade. 14. Run DSREPAIR.NLM to check volumes and trustees. From DSREPAIR's Advanced Options menu, select "Check volume objects and trustees". If new hard drives were installed, the Volume IDs no longer reside in the root entry of the Directory Entry Table. DSREPAIR will re-establish this link. 15. Check the server for proper functionality. Verify that the server is fully functional by printing print jobs, checking default server attributes, and so on. Recovering a Failed Server with DSMAINT In a multiple-server environment, it is possible for one server to go down but for the rest of the servers in its replica list to remain intact. The same situation exists if the hard disk(s) containing the SYS volume on one server becomes damaged, since a hard disk failure involving volume SYS affects the entire server and halts all NetWare operating system activities. Because the NDS files are stored on volume SYS, loss of the SYS volume is equivalent to removing NetWare 4 and NDS from the file server. You must reinstall NetWare 4 and NDS before you restore your data. Procedure. Following are the steps to use DSMAINT.NLM to restore a failed NetWare 4.1 server/SYS volume in a multiple-server network where replication is present. These steps assume you have a current backup of the server-specific information for the failed server. Note: Do not delete the Server or Volume objects for the failed server in the NDS tree. Leaving these objects intact preserves references that other objects (such as Directory Maps and Queues) may have to these objects. If the Server or Volume objects are deleted and you had objects that depended on them, you will need to re-establish the relationships through a selective NDS restore. 1. From your backup host server, run your backup program and restore the "Server Specific Info" files from a tape backup. You can restore these files to any target server using an SMS-based backup program. If you are using SBACKUP, the steps are as follows: 1a. From SBACKUP's main menu, select the "Restore" option. Select a server that will receive a copy of the server-specific information files and enter the administrative username and password as prompted. 1b. If the backup session files are not available, select "Restore Without Session Files". Otherwise, select "Choose a Session to Restore" and specify the path to the session log file of the session you want to restore. 1c. Select "Perform Custom Restore". In the Restore Options screen, highlight "Subsets of the Session to Be Restored" and press . 1d. Highlight "Include major TSA resources" and press . Then press and select "Server Specific Info" from the Resource list. Press until you see the prompt "Proceed with the Restore?" Answer Yes to continue. The server-specific information files (SERVDATA.NDS, DSMISC.LOG, VOLSINFO.TXT, STARTUP.NCF, and AUTOEXEC.NCF) will be restored to a subdirectory under SYS:SYSTEM on the server you have selected. The subdirectory name will be a DOS 8.3 name derived from the source server name. These files will be used throughout the restore procedure. 2. If necessary, restore DSMAINT.NLM and DSBACKER.NLM to the target server. Otherwise, you should have a copy of these two NLMs on a diskette or on a client workstation's local hard drive. 3. If the failed server held a master replica of any partition, use DSREPAIR to designate a new master replica on a different server in the replica list. (Use the information contained in the DSMISC.LOG file to determine what replicas were stored on the failed server.) If there is not another server that contains the same replicas as the failed server, Step 3 might need to be repeated on another server that contains the missing replicas. (Again, you can use the replica lists in DSMISC.LOG to determine which servers to load DSREPAIR on to complete this step.) To change the replica type, run DSREPAIR on another server in the replica list that has an active read/write replica of the partition. The steps are: 3a. Load DSREPAIR. 3b. Choose "Advanced options menu." 3c. Select "Replica and partition operations." Note: Normally you should use PARTMGR or the Partition Manager tool in NWAdmin to perform partition operations. This option in DSREPAIR is to be used only when the master replica of a partition is lost because of server or hardware failure. 3d. Select the partition you want to edit. 3e. Select "View replica ring" to see a list of servers that have replicas of the partition. 3f. Choose the server you want to hold the master replica and select "Designate this server as the new master replica." 4. If the failed server contained any non-master replicas, you need to remove all replica pointers to the failed server. If there is not another server that contains the same replicas as the failed server, Step 4 might need to be repeated on another server that contains the missing replicas. (Use DSMISC.LOG to determine what other replica types the failed server contained, and to determine which servers to load DSREPAIR on to complete this step.) To remove the failed server from the replica ring, the steps are: 4a. From the DSREPAIR Available Options menu, select "View replica ring." 4b. Select the name of the failed server. 4c. Select "Remove this server from the replica ring." You will see a warning message. Choose "Yes" to continue. 4d. Exit DSREPAIR. 5. Install the new hard disk or server hardware. Follow any instructions provided by the manufacturer to verify that the server's hard disks are working. The new hard disk should have the same (or larger) storage capacity as the drive it replaces. Use the server-specific information files to verify configuration information. 6. Reinstall the NetWare 4.1 server and place it by itself into a temporary NDS tree. When prompted in INSTALL, enter the same server name and internal IPX number that the server had prior to the failure. Use the STARTUP.NCF and AUTOEXEC.NCF files included with the server-specific information for needed information. After INSTALL copies the preliminary files, the prompt to "Select a directory tree" is displayed. Press to create a new tree to temporarily hold the server. This will allow you to log in and copy files to this server. When prompted, insert the NetWare License diskette for the server. 7. Edit the STARTUP.NCF and AUTOEXEC.NCF configuration files. The STARTUP.NCF and AUTOEXEC.NCF files are displayed so you can make edits as necessary. If changes were made to these configuration files since they were backed up as part of the server-specific information, make the proper changes online. Or you can use the .NCF files that were restored to the source server in Step 1. When the server installation is complete, exit the INSTALL utility. 8. From a client workstation, log in to the source server (the one the server-specific information files were restored to in Step 1). Then use the MAP command to map a drive to the destination server (the server you just installed). Since the newly-installed server is in a separate NDS tree, this will be a bindery-based mapping. For example: MAP G:=SRV1/SYS:SYSTEM 9. Copy the server-specific information files from the source server to the destination server. For example, if drive F is mapped to SYS:SYSTEM/SRV1 and drive G is mapped to SRV1/SYS:SYSTEM, the command would be: F:\> COPY *.* G: 10. Copy the DSMAINT.NLM and DSBACKER.NLM files to the destination server's SYS:SYSTEM directory. 11. Run INSTALL.NLM and remove NDS from this server. From the Installation Options menu, select "Directory options (install NetWare Directory Services)". Then select "Remove Directory Services from this server". This takes the server out of the temporary NDS tree and eliminates the tree. 12. Load DSMAINT.NLM on the server and select the "Restore local server information after hardware failure" option. This restores the correct NDS information from the SERVDATA.NDS file to the server. 13. Load the file system TSA by typing LOAD TSA410.NLM. Using an SMS-compatible backup program, restore the file system data for each volume affected by the failure. Note: If the server that failed was the host server for the backup program, first take the steps necessary to reinstall the backup software and storage device drivers. When setting up the restore session, go into Custom Restore and, under "How to scan the session to be restored", set the "Delete existing trustees before restoring" option to YES. This will purge existing trustees before restoring the backed-up trustee assignments from the backup. (Third-party backup programs might not have this option. If this is the case, type LOAD DSREPAIR at the server console and choose the "Unattended full repair" option. This includes the option to purge invalid trustee information on the server's volumes.) If the server had volumes other than SYS that were unaffected by the failure, no further action is needed because the SERVDATA.NDS file preserves the trustee assignments on these other volumes. 14. Bring down and restart the server. 15. Using Partition Manager, re-establish replicas on the recovered server. Use DSMISC.LOG to aid in this process. It contains a copy of the replica list that resided on the server at time of backup. From the server console, you can type LOAD EDIT DSMISC.LOG to view the log file contents. DSMAINT's Log File Options Following is a brief description of the Log File Options in DSMAINT. Current file size Displays the current size of the DSMAINT.LOG file located in the SYS:SYSTEM directory. View Activates a screen to view the log file. Enable log file Determines whether the log file will be enabled. Default is No. Delete current log file Determines whether the existing log file is deleted whenever the utility is started. Default is No. Maximum size of log file (bytes) When the log file reaches this maximum size, DSMAINT.OLD is created. Default is 524288 (500 KB); range is from 10 KB to 10 MB.