
              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 <Alt>+<Esc> 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
                         <CN=SERV1-MASTER>
          2D52D8D6:239   SYNC: Start outbound sync with server
                         <CN=SERV2-MASTER>
          2D52D8D7:052   SYNC: Start outbound sync with server
                         <CN=SERV3-MASTER>
          2D52D90F:402   (16:23:59) SYNC: failed to communicate with server
                         <CN=SERV3-MASTER> ERROR: -625
          2D52D90F:442   SYNC: Start outbound sync with server
                         <CN=DETROIT-PORT1>
          2D52D910:204   SYNC: Start outbound sync with server <CN=DETROIT_4>
          2D52D911:724   SYNC: Start outbound sync with server <CN=SERV2-CEN3>
          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.





