NOVELL TECHNICAL INFORMATION DOCUMENT TITLE: DSREPAIR.NLM DOCUMENT ID: TID015613 DOCUMENT REVISION: A DATE: 15APR94 ALERT STATUS: Yellow INFORMATION TYPE: Symptom Solution README FOR: DSREPR.EXE NOVELL PRODUCT and VERSION: NetWare 4.01 ABSTRACT: This file includes the DSREPAIR.NLM 1.92 for NetWare 4.01. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 DISCLAIMER THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO NOVELL. NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS INFORMATION. HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT IS FOR YOUR INFORMATION ONLY. NOVELL MAKES NO EXPLICIT OR IMPLIED CLAIMS TO THE VALIDITY OF THIS INFORMATION. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 SYMPTOM Using the "Designate New Master Replica" function (option 4 under set options) always changed replica state to on. SYMPTOM No way exists for users to quickly see replica ring information of the local DIB. SOLUTION Use version 1.92 of DSREPAIR.NLM. Self-Extracting File Name: DSREPR.EXE Revision: A Files Included Size Date Time \ DSREPR.TXT (This File) DSREPAIR.DOC 21703 04-15-94 1:11p DSREPAIR.NLM 55536 04-07-94 2:38p Installation Instructions: 1. Copy DSREPAIR.NLM to the SYS:SYSTEM subdirectory of the server on which it will be run. 2. At the console prompt of the file server, type the following command: LOAD DSREPAIR Solution Specifics: RELEASE NOTES This version of DSREPAIR has been enhanced to allow the editing of replica rings and the print out of the replica ring information on the local DIB. This README describes the error conditions that can require this editing and gives examples of how to use DSREPAIR to correct the errors. It contains the following five sections: I. Caveat II. Description of Error Conditions III. Example of Use IV. Print Out Local Replica Information V. DSREPAIR Is a Local Database Repair Tool I. CAVEAT Attempting to use older version of DSREPAIR to designate a new master replica when the master replica has been lost, and the replica is in a split or join state, creates other errors. *** WARNING *** YOU MUST BE SURE YOU ARE USING THE CORRECT VERSION OF DSREPAIR! Version 1.92 or later can be identified by the following message on the top of the main screen when the NLM is loaded at the server console: MESSAGE NetWare 4.01 Directory Services Repair Utility BETA RELEASE, NOT FOR GENERAL DISTRIBUTION THIS VERSION CONTAINS REPLICA RING EDITING FEATURES ** PLEASE ** read accompanying READ.ME before using this feature! Item 4 in the options menu has been enhanced to resolve a problem that occurs in replica rings for partitions. To invoke the option, select item 4 under the options menu. The message following message will appear when the option is selected: MESSAGE ** BETA RELEASE ** NEW REPLICA RING EDIT FEATURE II. DESCRIPTION OF ERROR CONDITIONS Start the repair in the normal way by selecting "2" in the main menu. When the DIB (local database on this server) repair has completed, the ring repair menu will appear. It will list all replica root objects stored on this server. This includes types of MASTER, SECONDARY, READ-ONLY, and SUBORDINATE. You do not see the SUBORDINATE type from client utilities, such as PARTMGR. Each replica is assigned a unique number on the left side of the screen. If there are more replicas than can be displayed on the first screen, you will be prompted to press a key to see the next screen, and this continues until all the replicas have been displayed. You are prompted to select a replica by keying in the number of the replica that has been displayed. If the replica you want to use is on a previous screen, you must remember the number it was assigned. You can key in the replica number of the replica that you want to work on, or "0" (zero) to exit the replica ring edit procedure and continue with the repair. When you select a replica, you are prompted for one of two following operations: 1) Change the replica type on this server to a MASTER replica. 2) Edit the servers in the replica ring for this replica. ********** Option 1: Change replica type to MASTER This option is used to select a new master replica for a partition that has somehow lost the master replica. The master replica could have been lost because the server that contained it has been uninstalled from the Directory Services Tree with INSTALL.NLM or the server may have been damaged or destroyed. Without a MASTER replica, partition operations such as split and join cannot be performed, because the client utilities first contact the MASTER replica of the partition to schedule these operations. In this case, selecting the option to change the replica type to MASTER will set this server (the one running the NLM) as the MASTER replica in the replica ring (the list of all the servers that contain replicas of the partition). If you want to set some other server that has a replica of the partition as the master, then you will need to run DSREPAIR on that server and perform the operation there. You should only be changing SECONDARY or READ-ONLY replicas to be a master replica. There will be confirmation on the screen that THIS server was found in the replica ring and that it has been changed to type MASTER. If another server is found in the replica ring that had been the MASTER, it is changed to a SECONDARY. If the server that originally had the master comes back on line, the new replica ring with the new master replica information will over-write the old one and the server with the old master will find out that he has been changed to a secondary. ******** Another possible MASTER failure is that all the servers containing a replica of the partition have been lost. This includes the case where there was only one replica of the partition and that server has been lost. When this happens, there may still be SUBORDINATE replicas stored on servers in the Directory Services Tree. You will see the partition with the client utilities; however, when you try a partition operation it will fail, and when you try to view the servers that contain replicas of the partition, none will be displayed, because the client utilities do not show servers with SUBORDINATE type partition roots. When this type of failure occurs there is a replica ring of SUBORDINATE reference partition roots for the partition; however, no real replicas of the partition exist. Because no replicas exist, there are no copies of the objects, their properties, or their data left in the Directory Services tree. There may however be external reference objects subordinate to the SUBORDINATE reference partition roots that contain the names of the objects. These external reference objects were created on these servers because they needed object IDs to grant rights to the file system for these objects. In this case, and ONLY this case, you need to change a SUBORDINATE reference to a MASTER replica. When you select this option you are alerted on the screen that you will have to run DSREPAIR again on this server. This is because the subordinate reference objects that were contained by the SUBORDINATE replica are now subordinate to a MASTER replica. This is an illegal condition in the Directory Services database. When DSREPAIR runs again, it will change the external reference objects to real objects with a base class of "unknown." Be aware that DSREPAIR will generate a lot of errors on the objects in this replica when this takes place. At this point, you have a MASTER replica of the partition, and it contains some but probably not all of the objects that were in the original replica. However, these objects all have the object class of UNKNOWN, and they have no properties or data. You can restore the replica from a tape drive with SMS, which will restore all the properties and data for these objects, or to clean up the tree, delete all the objects in the replica. Then join the partition root object with the parent partition, which changes the object from a partition root to just a container, and then delete the container object. ********* Option 2: Editing The Replica Ring Option 2 allows editing the replica ring (the list of all servers that contain a replica of the partition) of the selected replica. This is necessary if a server that contained a replica of any kind, including a SUBORDINATE, has been lost. There are several ways this can happen. 1) The server was properly removed from the Directory Services tree with INSTALL.NLM. The server object was deleted; however, all references to the object were not deleted on all servers because they had external references of the object that were not back-linked or there were synchronization failures due to other damage in the Directory Tree. 2) A server was destroyed or otherwise removed from the tree without being uninstalled. In this case, you would normally delete the server object from the tree and all would be well. However, the previous conditions could occur; or you may find that there was only one replica that contained the server object, and it was on the server that has failed. In this case, you cannot delete the server object because you cannot find it with the client utilities. Either way, you end up with a server in the replica ring that no longer exists in the Directory Tree. You may see an error -625 on the DS.NLM trace screen when the synchronization process is synchronizing a replica and it tries to contact the server that no longer exists. This trace screen is enabled by typing "SET DSTRACE = ON" on the server console and using + to switch screens. This error will prevent synchronization from completing properly, because it indicates that a server in the ring has not been updated with the latest information. This also prevents objects marked for deletion from being purged, because that cannot happen until all replicas are informed of the deletion. The solution is to edit the replica ring and delete the server that no longer exists. You have already selected the replica to edit. Now the list of all servers that contain a replica are displayed, along with a unique number to identify the server, the type of replica on that server, the state of the record in the DIB (local database), and the servers Directory Name. The state is "Present" or "Deleted." You can set a server to "Deleted" by keying in the number of that server. After a server is deleted from the ring, it cannot be added again. Also, if an existing server is deleted from the ring, that server will no longer synchronize with this server and no strategy is presented to correct this problem. *** WARNING *** BE CAREFUL AND UNDERSTAND WHAT YOU ARE DOING OR YOU MAY CREATE A PROBLEM AS SERIOUS AS THE ONE YOU ARE TRYING TO CORRECT. If you make a mistake and delete the wrong server, exit the ring editor by selecting "0" (zero) to each prompt, and return to the main repair screen. When you are prompted to save the DIB, select "N" for NO and run the repair again to access the ring editor and make the correct selection. You may want to check the ring of each replica on this server. This is the only way to be sure that the failed server has been removed from all replica rings. ********* When you are done with either procedure previously listed, you are returned to the list of replicas stored in the DIB. You can select another replica and perform the operation again. Selecting "0" (zero) returns you to the main repair screen. If mistakes were made when editing the replica, select "N" when asked to save the DIB, then rerun the repair and make the correct selections. The 4.01 DSREPAIR cannot contact other servers to verify that the operations you select are correct, you must make that decision. III. EXAMPLE OF USE The following is an example of server that was not properly removed from the partition ring and was giving a -625 error: SYNC: Start sync of partition OU=DETROIT. 2D52D8D6:967 SYNC: Start outbound sync with server 2D52D8D6:239 SYNC: Start outbound sync with server 2D52D8D7:052 SYNC: Start outbound sync with server 2D52D90F:402 (16:23:59) SYNC: failed to communicate with server ERROR: -625 2D52D90F:442 SYNC: Start outbound sync with server 2D52D910:204 SYNC: Start outbound sync with server 2D52D911:724 SYNC: Start outbound sync with server 2D52D914:962 SYNC: End sync of partition OU=DETROIT. All processed = NO. The server SERV3-MASTER was deleted from the tree for several months but still appeared in the DETROIT partition ring on server SERV4-MASTER. To remove SERV3-MASTER from the ring, the user ran DSREPAIR.NLM on SERV4-MASTER and choose option 4, "Repair replica ring with manual editor." After running the initial scan through DSREPAIR, the following screen was presented that allowed the user to choose the DETROIT partition ring. Select a replica to edit: Replica Type Name 19 SECONDARY "OU=UGH" 20 MASTER "OU=DETROIT" 21 MASTER "OU=FOO" 22 SUBORDINATE "OU=DOSFISH" 23 SUBORDINATE "OU=SERVES" 24 SECONDARY "OU=NYU_Testing" 25 SECONDARY "OU=WHY" 26 SECONDARY "OU=PIL" 27 SECONDARY "OU=Planning" 28 MASTER "OU=HC" 29 SUBORDINATE "OU=SLP" 30 MASTER "OU=TRAINING" 31 MASTER "OU=NBC" 32 SECONDARY "OU=SAL" 33 MASTER "OU=MAGS" Press a key for the next page, or ESC to Quit After choosing the DETROIT partition, the user was presented with the options to change the partition to a MASTER or modify the partition ring. The user chose to modify the replica ring, which then presented the following screen: NetWare 4.01 Directory Services Repair Utility You selected replica: OU=DETROIT Press "1" to set this server as MASTER in the replica ring. Press "2" to manually edit the replica ring. Enter selection, or "0" to quit: 2 This screen displays the current servers that are associated with the DETROIT partition ring. As you can see, the server SERV3-MASTER is still present. NetWare 4.01 Directory Services Repair Utility Select a server in the ring of partition: OU=DETROIT Number State Type Server 1 Present MASTER CN=SERV4-MASTER 2 Deleted SUBORDINATE CN=WARLOCKS 3 Present SUBORDINATE CN=SERV2-CEN3 4 Present SECONDARY CN=DETROIT_4 5 Present SECONDARY CN=DETROIT-PORT1 6 Present SUBORDINATE CN=SERV3-MASTER 7 Present SUBORDINATE CN=SERV2-MASTER 8 Present SUBORDINATE CN=SERV1-MASTER 9 Deleted SUBORDINATE CN=RHIDE Enter the number of the server to delete, or '0' to quit: 6 Then the user selected to delete SERV3-MASTER (number 6) from the ring, then saved the changes and exited DSREPAIR. NetWare 4.01 Directory Services Repair Utility Select a server in the ring of partition: OU=DETROIT Number State Type Server 1 Present MASTER CN=SERV4-MASTER 2 Deleted SUBORDINATE CN=WARLOCKS 3 Present SUBORDINATE CN=SERV2-CEN3 4 Present SECONDARY CN=DETROIT_4 5 Present SECONDARY CN=DETROIT-PORT1 6 Deleted SUBORDINATE CN=SERV3-MASTER 7 Present SUBORDINATE CN=SERV2-MASTER 8 Present SUBORDINATE CN=SERV1-MASTER 9 Deleted SUBORDINATE CN=RHIDE Enter the number of the server to delete, or '0' to quit: 0 Then the user selected '0' (zero) to exit the edit function. IV. PRINT OUT LOCAL REPLICA INFORMATION This option will display or print out to a log file the local replica ring information. To choose this option, select option 3 from the main menu. At this point you can page down through all the ring information or save it to a log file. If no name is specified, then DSREPAIR.LOG in SYS:\SYSTEM is the default name and location of the file. To run in unattended mode, type the following command: dsrepair -u [for unattended] -r [for replica information] -l a:log.fil [for log file name and path] Example 1: load dsrepair -u -r This will load dsrepair and output replica information to the screen and the default log file SYS:SYSTEM\DSREPAIR.LOG. If the file already exists, then the new information will be appended. Because the unattended mode is specified with -u, DSREPAIR will perform the repair without user intervention, then automatically unload upon completion. Also, because -r is specified, it will output replica information instead of performing a local database repair. Example 2: load dsrepair -u -r -la:myring.log This will run DSREPAIR in unattended mode and output replica information as above; however, output will go to a diskette in the a drive called "myring.log". Example 3: load dsrepair -u -r -lc:myring.log As previously shown; however, the log file is on the DOS C: drive. Example 4: load dsrepair -u This will perform a local database repair in unattended mode with output being sent to the default log file. No replica information is output. V. DSREPAIR IS A LOCAL DATABASE REPAIR TOOL You should always log the output of dsrepair to a log file, and check the log file after the repair to see if objects in replicas have been damaged. If so, the objects have been repaired or deleted in the LOCAL DATABASE ONLY. Further operations, such as removing the damaged replica from the server and reinstalling it again to replace the damaged objects with a good copy may be necessary. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 �