Network Support Encyclopedia 96-1

home *** CD-ROM | disk | FTP | other *** search

/ Network Support Encyclopedia 96-1 / novell-nsepro-1996-1-cd2.iso / download / netware / dsenh.exe / README.TXT < prev next >

Wrap

Text File | 1995-09-13 | 46KB | 1,073 lines

DS Enhancement Pak September 1995 The DS Enhancement Pak is provided as a compressed file named DSENH.EXE and will expand into the following files: README.TXT - This text file DS.NLM - Version 4.89a of the Directory Services for NetWare 4.10 DSREPAIR.NLM - Version 4.26b of the Repair utility for NetWare 4.10 DSMAINT.NLM - Version 4.89 This is a new DS maintenance utility which provides for more simple hardware maintenance. UPGRADE.TXT - a text file describing the recommended process for upgrading NetWare 4.0x to NetWare 4.10 REPAIR.NLM - Version 2.23 of the Repair utility for NetWare 4 versions before version 4.10. This file should be renamed to DSRPEAIR.NLM when copied to the file server. REPAIR.DOC - a text file with instructions for the use of the DSREPAIR.NLM version 2.23 NOTES: The REPAIR.NLM is for all NetWare versions before 4.10. Rename REPAIR.NLM to DSREPAIR.NLM when you place it on the old server. The DS in prior NetWare 4.0x is contained within the Operating System and cannot be replaced. The DS.NLM will therefore only work with NetWare 4.10. The UPGRADE.TXT includes instructions for upgrade from previous versions of NetWare 4.0x to 4.10 and may be disregarded in new installations. CONTENTS I. NEW DS VERSION II. HOW TO INSTALL III. DSREPAIR IV. DSMAINT V. NDS PROTOCOL ISSUES VI. HOW TO RESOLVE DS ERRORS VII. SOME FREQUENTLY ASKED NDS QUESTIONS. I. NEW DS VERSION The DS Enhancement Pak contains DS.NLM version 4.89 for NetWare 4.10 file servers. This file replaces the previous Directory Services and provides increased performance, additional functionality, and addresses any known issues. All NetWare 4.10 servers should be updated to this new version to obtain the new functionality. Performance: This DS.NLM significantly increases the performance of NetWare Directory Services. Some of the improvements will be noticeable to the users, while others will improve the background processes and are not immediately apparent. Changes in the login and authentication process will reduce the time it takes to accomplish tasks when large numbers of users attempt concurrent access. Improvements in the resolve name routines will also allow DS to more quickly locate objects and complete the required actions. Background processes involving revision attributes and backlinks have been altered to improve synchronization and replication, especially when operations were not "normal" because of server or communications faults. The introduction of a "tuned resolve name" ability in background consistency checking of external references insures greater reliability and improved performance. Bindery Services: Code changes in how the bindery handles names have been improved, and in general performance will be improved and server utilization will be reduced. A name can now exist in more than three of the bindery contexts set on a server and show up during a list operation. Previously, this was not the case. Management: The addition of the "Partition Status" attribute makes it easy to determine the health of background synchronization. This attribute keeps a record of the last successful time a complete synchronization cycle was accomplished. If synchronization errors were encountered, a record of those errors is recorded in this attribute. Included in the error record is the object on which the failure occurred, the server to which synchronization was being attempted and whether it was a local or remote error. This status is displayed by the new DSREPAIR.NLM, the enclosed sample utilities, and will be used in future management tools. This functionality reduces the time required to administer the Directory Services. Internal DS commands were added to assist in making future utilities more useful. These will promote self-healing and global repair strategies. Status flags may be used in future utilities to alert an operator that a partition operation may be placed on hold because a server in the ring is down. Backward Compatibility Additional work has been done to ensure interoperability with previous versions of NetWare 4.0x. In the event that data inconsistencies are encountered in the old directory database the new DS will attempt to correct them. The DS.NLM version 4.89 is appropriate for ALL NetWare 4.1 servers. Although all versions of NetWare 4.10 Directory Services interoperate, you are strongly encouraged to upgrade all NetWare 4.10 servers to the same version to insure consistency and easier future maintenance. II. HOW TO INSTALL THE DS.NLM If you are upgrading from NetWare 4 versions prior to 4.10 Please read the attached UPGRADE.TXT file first. DS.NLM is normally installed as part of a server upgrade or new install. It also may be loaded and activated on existing NetWare 4.10 servers without the need to restart the server. Note: If you have installed the NetWire patch DSPRCSFX.NLM version dated 4-28-95 it MUST be replaced with the version dated 5-10-95 and the server rebooted before the new DS is installed. A. EXISTING 4.10 SERVERS MANUAL METHOD To install the new DS.NLM on an existing NetWare 4.10 server you should: 1. Log into the network as ADMIN or a user with rights to the SYS:\SYSTEM directory of a current NetWare 4.10 file server. Locate the file SYS:\SYSTEM\DS.NLM 2. Copy the new DS.NLM file to the SYS:\SYSTEM directory of the NetWare 4.10 file server to be upgraded and overwrite the existing file. You should also copy the DSREPAIR.NLM and overwrite the old file on SYS:\SYSTEM. 3. At the file server console of the server being upgraded (or using RCONSOLE) toggle to the system console screen. 4. Enter the command "SET DSTRACE = *." and press <Enter> to reload the Directory Services without downing the server. 5. Repeat the process for each 4.10 server in the network which may be running the older version. 6. Although you do not have to upgrade all servers at once, the DSREPAIR status commands will not report the status of servers running the older version. NOTE: Reloading the DS will not affect currently connected users. Users who request new connections while the file server reloads will, however, receive an error because the data base is still closed. You may wish to perform the upgrade during a period of minimal user activity. B. NEW INSTALLS OF NETWARE 4.1 Because it is not possible to copy the DS.NLM file to the read-only CDROM one of the following processes must be used: 1. Staging Server (Preferred) Many people copy the contents of the CDROM to another server's magnetic disk drive and perform the install across the network. Generally this provides high performance and the ability to alter the files to be installed. If you use this method you should copy the new DS.NLM to the NW410\SYSTEM\PREINST directory. Run the installation and the correct DS will be loaded and activated. 2. Install or Upgrade from CDROM The CDROM may be connected directly to the file server being installed or upgraded or it may be attached to another file server and accessed across the network. BEFORE you begin the upgrade of the NetWare 4.0x server you must first copy the new DS.NLM onto the file server in the SYS:\system directory. Prior to NetWare 4.10 the DS was embedded in the Operating System, so this will have no effect on the operation of the server and may be done at any time before the upgrade. Begin the installation in the normal fashion. During the "Preliminary file copy" the older DS.NLM would normally be copied to the file server. When the install program detects a newer version is already present it will display the file name and ask "over write newer version?" Answer "NO" and continue with the installation. III. DSREPAIR v 4.26 In addition to enhancement of the Directory Services Novell continues to enhance the diagnostic and repair utilities. At your convenience you should copy the DSREPAIR.NLM to the SYS:\SYSTEM directory of each file server. The DSREPAIR.NLM version 4.26b contains new functionality and will more completely identify and correct data inconsistencies. The older DSREPAIR.NLM version 4.23 may still be used with the new version of the DS, but will not provide these improvements. Although the DSREPAIR version 4.26 will identify and correct data inconsistencies for any version of the DS you cannot obtain status information from servers which are not running the new DS version 4.89. Once the new DS NLM is loaded and synchronization has occurred the status information about DS replication and synchronization will be available. The option on the first menu "Report Synchronization Status" will display and log the status of ALL copies of ALL replicas of ALL partitions contained on this server. It will contact each server which contains a replica copy and verify the status. If this involves multiple partitions and many copies the screen display will scroll rapidly and the logfile will be required to check the results. By careful selection of servers you should be able to obtain data on the status of your entire tree without checking all servers. A sub-set of the above information may also be obtained. From the "Advanced Options" sub-menu you may select "Replica and Partition Operations" and then select a partition. Selecting the new option "Report Synchronization Status" will contact all servers with a replica of that partition and then display and log the status. You may also select the option "View Replica Ring", select a server, and display the status of the replica on that server. See the "How to resolve DS errors" section below for more details on the DS error messages. IV. DSMAINT The DSMAINT.NLM provides control of NetWare Directory Services (NDS) when certain hardware maintenance operations are necessary. Because it deals with the Directory information on a specific server, it is run from that server's console. You may wish to copy it to the SYS:\SYSTEM directory so it is available if needed. The DSMAINT utility provides functionality to address two specific scenarios that NetWare administrators may experience. Each specific situation is addressed by a pair of features in the utility that work together. One command begins a process; another completes it. Scenario One: NDS and Upgrading Server Hardware There are times when a server requires an upgrade that does not affect the server as a Directory object. For example, the SYS: volume may be physically located on an old hard disk drive that needs to be upgraded. In these situations, you no longer need to uninstall NDS from the server. You can use DSMAINT to prepare Directory information on the server for the upgrade. Then, after the upgrade, you can restore Directory information to the server with DSMAINT. The "Prepare NDS for a hardware upgrade" option prepares the Directory information on this server for a planned hardware upgrade of this server. DSMAINT creates a file (SYS:\SYSTEM\BACKUP.DS) that stores all the Directory information on this server, including replica information. This file should be included in backup procedures before bringing the server down. The "Prepare NDS for a hardware upgrade" option locks and disables the Directory on this server, preventing any data change. To other servers that normally communicate with this server, the server appears to be down. Any Directory information that normally is sent to the locked server is stored by other servers in the Directory; the "stored" information is used to synchronize the server when it comes back online. Because the global Directory is 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 Directory information on the server as soon as possible. The "Restore NDS after a hardware upgrade" option uses the file created by the "Prepare..." option (SYS:\SYSTEM\BACKUP.DS) to restore Directory information on this server. Before the Directory is restored, DSMAINT ensures that the server is in the same relative state as before the upgrade. DSMAINT ensures 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. Procedure: IMPORTANT: If you use backup software that needs to be logged in to the Directory, log it in before you use this option. Because the option closes the Directory on this server, you cannot authenticate to this server after performing the option. 1. Log in your backup software or if you have a current backup login as Admin. The object of this step is to ensure that there is an authenticated connection with Admin rights to SYS:SYSTEM. 2. Load DSMAINT and use the "Prepare NDS for a hardware upgrade" option; then, back up the server. If a backup was already performed the BACKUP.DS file will need to be copied to the client's harddrive. The object of this step is to not only backup the data, but to also get a backup of the BACKUP.DS file in the SYS:SYSTEM subdirectory which was created by DSMAINT. 3. Bring down the server and perform the upgrade. 4. Use the INSTALL utility to reinstall NetWare and place a "temporary" Directory on the server. Install the server to its OWN temporary Directory tree, not your normal Directory tree. The temporary Directory tree will be replaced in step 7. 5. Copy the DSMAINT.NLM and restore BACKUP.DS to the SYS:\SYSTEM directory. 6. Use the INSTALL utility to remove NDS from this server. This option is under INSTALL's "Directory options" menu. 7. Load DSMAINT.NLM at the server console and use the "Restore NDS after a hardware upgrade" option to restore the correct Directory information to the server. 8. Restore Data from backup performed in Step 2. 9. Run DSREPAIR 10. Load INSTALL and upgrade mounted volumes. IMPORTANT: This procedure may create trustee assignments that did not exist before the upgrade. By default, the container object into which the server is installed receives Read and File Scan rights to the server's SYS:\PUBLIC directory. If these rights were previously removed you will need to remove them again. Scenario Two: Maintaining Server References during a Brief Shutdown At times, it is necessary to remove a NetWare Server object from the Directory for a brief period of time. For example, in the case of a corrupt authentication key, it is necessary to reinstall NDS on the server. During the uninstall process, the NetWare Server object is removed from the Directory. When the NetWare Server object is removed from the Directory, objects that reference it in their required attributes can become Unknown objects. A similar type of problem can occur with services like printing that are associated with a physical server. With DSMAINT, you can avoid losing objects and ease reinstallation by replacing references to the server with references to another object that you create for this purpose. After installing NDS on the server again, you can use DSMAINT to replace these references to the server in other objects' Host Server, Host Device, or Message (Default) Server attributes. The "Replace server references" option searches the Directory and replaces references to this server's NetWare Server object in other objects' Host Server, Host Device, or Message (Default) Server attributes with a reference to another Directory object. The "Restore server references" option restores references to this server in other objects' Host Server, Host Device, or Message (Default) Server attributes. This option reverses the replacements made by the "Replace server references" option. Procedure: 1. Begin by selecting an object for "holding" the references. This can be an existing User object, but must not be a NetWare Server object. The user object you have logged in as would be appropriate. 2. Now select the "Replace server references" option. You are required to enter the full name of the container where you want to begin searching for objects that reference this server's NetWare Server object. You also need to enter the full name of the object you want DSMAINT to use as a replacement value (such as a TEMP User object). 3. At this point, you can uninstall and reinstall NetWare Directory Services. 4. Once NDS is properly operating, you can select the "Restore server references" option to reverse the replacements made by the "Replace server references" option. You will again be required to provide the full name of the temporary object that is holding the references. Note: DSMAINT automatically removes volume IDs from the physical volumes on the server so Volume objects are not removed during an uninstall. V. NDS PROTOCOL ISSUES RIP and SAP FILTERING An administrator might consider installing RIP filtering in order to reduce traffic on a heavily used segment of his network. This however, is not a healthy approach in the distributed world of NDS since it is possible that at anytime it may be necessary for any given server in the tree to contact any other server in the tree. The logical approach currently taken by administrators is to examine the replica sets of the NDS tree and based on replica placement assume that server X has no need to talk to server Y and therefore it is okay to install a RIP filter between them. This is bad. It can cause other parts of background synchronization to fail thereby endangering consistency of objects in the tree. For example, an external reference on one server may be unable to contact another server with the real object (because of a filter) and place a backlink value on the object. Backlinks are used to inform external references of renames, moves, deletions, and so forth, that happen to real objects. It is Novell's recommendation that RIP filtering not be used. When reviewing SAP filtering be aware that SAP type 278 is used by clients to discover directory services on initial boot up. The clients will revert to SAP type 4 if 278 is not discovered. SAP type 278 also is used by install when selecting which directory services tree will contain the server. Some NDS partition operations use SAP type 278, while others use SAP type 4 such as tree-walking when an intermediate partition is unavailable. Servers that have child/parent replicas must be able to see each other's SAP type 4. Novell does not recommend filtering these SAP types. If you desire to do additional SAP filtering you may want use configured Time Sources. This will allow you to eliminate SAP type 26B. In the future it will be possible to filter out all SAPs as this information will be in the DS. IPX SOCKET LIMITS NetWare servers have a default maximum of 1200 IPX sockets when first installed. Every time an outgoing connection is established, three IPX sockets are employed, one socket conducts primary NCP packet exchanges, another is used by a watchdog timer, and the last is used to retrieve messages from the server. This effectively limits NLMS needing an outgoing IPX connection to a combined maximum of 400 unless the default is changed. Experience would indicate that at about 350 servers in a tree this problem could begin to occur. It is most likely in the case where a server contains a replica of every partition in the tree. In this case that single server would be the only one on which the socket limit would need to be increased. In most cases it is only necessary to change the default on selected servers that have high sockets requirements. The symptom exhibited when the connections limit is exceeded is an error -119 on the DSTRACE screen and a significant number of -625 errors. The solution is to run the SPXCONFG.NLM and increase the maximum open IPX sockets from 1200 to a higher value. Unfortunately, the default will be re-established when the server is rebooted. To make the IPX configuration permanent, add the following line in the AUTOEXEC.NCF LOAD SPXCONFG Q=1 I=<n> where n is the maximum open IPX sockets between 120-65520 You should begin by changing the value to 2040 and monitoring for possible errors. VI. HOW TO RESOLVE DS ERRORS It is important to remember than NDS is designed to be loosely consistent, which means that at any given instant not all replicas will be synchronized. This will be especially true if significant administrative changes have recently been made, if partitioning operations were recently done, or if servers or communications links have been down. This is normal operation, and replicas will converge. There is cause for concern, however, when replicas are out of sync for extended periods for no apparent reason. Care should be taken to properly interpret the information the error messages provide. The suggestions contained below are general and may need to be modified to apply to your specific situation. DSREPAIR DEFINITIONS Source Server: The server where the error is displayed (local). Target Server: The server whose name is listed in with the error message (remote). Send All Objects: An option available in the 4.1 DSREPAIR under "Advanced Options", "Replica and partition operations", <select partition>, "Send all objects to every replica in the ring." A better option is generally "Receive all objects from the master to this replica" (available from the same menu as Send all Objects) because receiving from the master involves only two servers in the synchronization. See below. Send All Objects will send all information from the source server to every other server in the replica list including the Master replica) and update missing or old information. For instance, user SAM may have a phone number on replica one with no E-mail address, but replica two may think that SAM has an E-mail address but no phone number. If you were to do a Send All Objects from replica one on SAM's partition, replica two would then get the phone number in addition to keeping the E-mail address. This is similar to a Repair Time stamps or Receive All Objects except that 1) Repair Time stamps and Receive All Objects always take information from the Master replica and Send All Objects allows you to choose the replica from which to send information; and 2) Repair Time stamps and Receive All Objects will overwrite data on the target replicas while Send All Objects merely sends information from the source server while not writing over anything the target may have in addition to what the source is sending. Send All Objects generates quite a bit of traffic since the source server resends all data in the partition to all servers in the replica list. It is also easy to do a Send/Receive All Objects from a bad replica and therefore corrupt all the other replicas, so please be careful about performing any of these options and make sure you check the validity of the replica you use as the source before executing any of these commands. If a Send All Objects is executed but a server in the replica list is down, the Send will continue to try to update each server in the replica list with all the objects until it can get an ALL PROCESSED=YES on the operation. Do not perform a Send/Receive All Objects if a server in the replica list is down! Receive All Objects: An option available in the 4.1 DSREPAIR under "Advanced Options", "Replica and partition operations", <select partition>, "Receive all objects from the master to this replica." This is generally a better option because receiving from the master involves only two servers in the synchronization. The disadvantage of Receive All Objects is that the Master replica then completely replaces the information on the source server's replica. This option generates less traffic, but cannot be used unless the Master replica has the good copy and the server with the problem copy is 4.10. If you cannot use a Receive All Objects, you will need to do a Send All Objects. It can be dangerous to do ANY of these options in a mixed environment (a tree containing both 4.0x and 4.10 servers) if there are any rename problems (objects which have been renamed to #_#, i.e. 3_2, due to name collisions). Therefore, check for renames before issuing a Send All Objects or a Receive All Objects. CODES DISPLAYED The errors listed here can be encountered when running the report replica synchronization status option available from the main menu of DSREPAIR.NLM 4.26b. Note: Any servers which have not been upgraded to DS version 4.89 will display the name of the server followed by :??? Some errors may be transient in nature and will correct themselves. Other errors, such as communications failures, over which you may not have control, may require correction by communications technicians. In each case check the date and time of last synchronization to determine the scope of the problem. Within each error message a code of either LE (local error) or RE (remote error will be displayed). RE indicates that the error is not on the named server, but is "remote" to that server. The LE indicates that the error exists on the named server. Generally running DSREPAIR on that named server will be the first step to repairing the problem. For each error identified refer to the recommendation below. -603 0xFFFFFDA5 FDA5 NO_SUCH_ATTRIBUTE Explanation: The requested property could not be found. In the Directory, if a property does not contain a value then the property does not exist for the specific object. Action: This is probably a problem with either the public key or the remote ID. Run DSREPAIR to verify remote server IDs. If errors appear there, run this same option once more to verify remote server IDs. If you get a -602 or -603 in DSREPAIR when verifying remote server IDs, call your Novell Authorized Service Center for support. Be aware, however, that a public key cannot be repaired unless there is at least one server in the tree authenticating without problems to the target server. The server authenticating OK to the target server must also have a real copy of the target server object, so it must have a replica (other than a subordinate reference) of the partition holding the target server object. If this is only a two server tree, the target server will need to be removed from the tree and reinstalled. -608 0xFFFFFDA0 FDA0 ILLEGAL_ATTRIBUTE Explanation: An attempt was made to add a property that is illegal to an object. The Directory Services schema determines what properties can be inherited by an object class. (Refer to the Directory Services Schema documentation if available.) This error can also occur in mixed trees (4.0x and 4.10 servers in the same tree) or in upgraded trees (when 4.0x servers have been upgraded to 4.1) when a server does not have the correct schema. Action: Run DSRepair on the server reporting the error, if the error persists, contact your Authorized Novell Reseller. -609 0xFFFFFD9F FD9F MISSING_MANDATORY Explanation: This error indicates that one or more of the mandatory properties for the object being created is missing. Each object Class in the Directory has a set of mandatory properties (properties that must contain a value before the object can be created). For example, a USER object in the Directory is required to have a Common Name (CN) and a Surname. Without these properties the object will not be created. A property exists only if there is a value supplied for the given property. This error can also occur in mixed trees (4.0x and 4.10 servers in the same tree) when a server does not have the correct schema. Action: Do a SET DSTRACE=+SYNC at the file server console and then SET DSTRACE=*H to see the object causing the error. If the object is not a server object, try deleting it. In the case of a schema problem, run Global Schema Update from a 4.10 server. If Global Schema Update does not correct the problem, down the server with the master replica of the partition showing errors and then bring it back up. Upon startup, the server will force a schema update which usually corrects these schema problems. -610 0xFFFFFD9E FD9E ILLEGAL_DS_NAME Explanation: Illegal Directory Names are those which are too long (more than 255 characters) or ones which contain illegal character combinations. The '\' character may be followed only by a '.' or '=' or '+' or '\'. -611 0xFFFFFD9D FD9D ILLEGAL_CONTAINMENT Explanation: The containment rules of the Directory specify where an object class may appear in relation to other objects in the Directory tree. For example, the object Class Country can only be created at the top of the Directory, the object Class User can only be created under Organizations and Organizational Units. The Schema enforces the containment rules for Directory Services. -616 0xFFFFFD98 FD98 MAXIMUM_ENTRIES_EXIST Explanation: This error indicates that the maximum entries (objects) for a single file server exist in the Directory tree. The maximum number of objects that can be created and maintained on a single file server is FFFFFF (3 bits of FF) which equals 16,777,220 decimal. Some of these entries are used by the Directory itself. Action: For the current version of the Directory, you have reached the maximum number of objects that can be stored on that file server. To continue you will need to delete objects that are no longer needed or partition the database. -618 0xFFFFFD96 FD96 INCONSISTENT_DATABASE Explanation: This error indicates that an error has been encountered in the database itself. Usually this error means that the number of entries in a container does not match the number stored in the container's entry. When this error occurs during synchronization, the target server has a corrupted database. Action: Run DSREPAIR ONLY ONCE. If this error persists after running DSREPAIR the first time, consult your Novell Authorized Service Center. By running DSREPAIR a second time, the original OLD database files will be overwritten and it may not be possible to restore the information. -621 0xFFFFFD93 FD93 TRANSACTIONS_DISABLED Explanation: This error indicates that Transaction Tracking (TTS) has been disabled for the server on which the Directory operation is taking place. When TTS is disabled, Directory Service operations which require modifying the database on that server are disabled as well. Action: At the console prompt of the file server type "ENABLE TTS." If TTS was disabled because the SYS volume is full, login to the file server, delete unnecessary files from the SYS volume, and type "ENABLE TTS" at the file server. If you are unable to login to the file server, try running VREPAIR on volume SYS and selecting "purge deleted files" from the VREPAIR menu. If there still is not enough space you will need to increase the size of the SYS volume hardware. -625 0xFFFFFD8F FD8F TRANSPORT_FAILURE Explanation: This error indicates the inability to communicate across the network either between a client and a server or between two servers. This is a common error and generally indicates a failure of the LAN or WAN connections. This error will also be seen when trying to communicate with servers having locked databases (i.e. DSREPAIR in operation). Action: This error is almost ALWAYS a LAN issue. Assuming that the rest of the network is operating properly check cabling, the LAN card, and the LAN driver of the server in question. Type DISPLAY SERVERS on the source server to see if the target server is visible. Attempt to RCONSOLE to the target server. Verify that other servers also showing a -625 error to the same target server. Determine if workstations can attach and login to the target server from the same segment as the source server? Type RESET ROUTERS and then type SET DSTRACE=*U at the source server to flag all servers as UP and retry communicating. Occasionally a change of the server's name, a move of the server object, or a change to the internal IPX number can also cause this error. Run DSREPAIR with the option to repair network addresses on the source server to check the internal IPX number of the target server--the change may not have completed successfully. Check for SAP filtering of the DS SAP types of 26B and 278. -628 0xFFFFFD8C FD8C OBJECT_CLASS_VIOLATION Explanation: An object class violation has occurred. This can happen when the source server's objects are unknown, but the objects are fine on the target server. Action:. Lock the databases to isolate the bad replica, then delete the bad replica and add it back again through Partition Manager (verifying first that the master is a good copy). -632 0xFFFFFD88 FD88 SYSTEM_FAILURE Explanation: This error indicates that unexpected results have occurred. For example, the client requested that the Directory return a network address attribute and the Directory actually returned a public key attribute. This condition may be temporary. While the client usually returns errors in the -301 to -399 range, the client as well as the server return this error during the authentication process. When a server returns a -632 during synchronization, this may be because authentication could not complete due to an error in the public key--the key is the right key, but it is corrupt (not the right format). Because -632 is just a general error which means that the process being attempted failed it may be because the server(s) being contacted was busy, down, or that the source server could not authenticate to it. Action: Run DSREPAIR with the option to verify remote server IDs on every server in the replica list. Repeat the same repair option. If the remote server id check returns a -632 after running it the second time, call your Novell Authorized Service Center. Otherwise, try to resolve the process which failed. -634 0xFFFFFD86 FD86 NO_REFERRALS Explanation: This means that the target server does not have a copy of what the source server is requesting. In other words, the source server has no objects which match the request and has no referrals on which to search for the object. Action: This is not actually an error, but just a response. It will usually resolve itself when synchronization is complete. -635 0xFFFFFD85 FD85 REMOTE_FAILURE Explanation: In order to complete some operations, a server will need to contact another server. If this is not possible (due to a link being down, for example), this error will be returned. Action: If the required links are operational the target server does not have the correct information about the source server. This is often caused by a problem with local to remote IDs or the server object. Run DSREPAIR with the option to verify remote server IDs on every server in the replica list. Repeat the same repair option. Resolve any errors found after the second run of DSREPAIR. -637 0XFFFFFD83 FD83 PREVIOUS_MOVE_IN_PROGRESS Explanation: Once an object has been moved from one context in the Directory to another, the Directory will not allow that object to be moved again until all replicas of that object have been updated. The length of time for a move to complete will vary--depending on the size of the replica, the number of replicas, and condition of the communication links between all the servers holding the replicas. This error can also be caused by a moved object which lost the original object (the primary obituary) or by a broken partition. Action: Leave the object in its current context until it can be moved again. This may require that the object be left in its new context for several minutes. You might also check to see if all replicas have been synchronized. If the object still cannot be moved, load the 4.10 DSREPAIR with -m (LOAD DSREPAIR -M) and then run Repair Local Database. View the DSREPAIR.LOG file which will display objects which have move obituaries. Verify that the problem objects and all their attributes have successfully moved to the new location (by running NWAdmin or Netadmin and viewing the objects). If so, contract your Novell Authorized Service Center. -649 0xFFFFFD77 FD77 INSUFFICIENT_BUFFER Explanation: The server ran out of memory. The operating system will self-correct this error. Action: Be patient. See "Resolving Server Memory Problems" in Supervising the Network. -654 0xFFFFFD72 FD72 PARTITION_BUSY Explanation: Another partition operation is currently taking place. For example, if a request has previously been issued to split a partition, a second request for a split (even at another point in the same partition) will result in this error. Action: This is a normal error immediately after a partition operation has been initiated. If this error does not go away call your Novell Authorized Service Center. -659 0xFFFFFD6D FD6D TIME_NOT_SYNCHRONIZED Explanation: Directory Services uses time stamps to determine the order of events that take place in the Directory. Time Synchronization services has been implemented to maintain a consistent time across the network. Modification operations require the issuance of a time stamp. If a replica on a server has issued a time stamp and the time on that server is set back, in 4.0x no further modification operations may take place until the time on the server moves past the last modification time on the partition. This applies only to operations that modify, not those that just read information. In other words, users will be able to login to the directory fine, but no objects can be edited through the utilities. In 4.1, the directory will issue synthetic time stamps on objects in order to allow them to be modified yet still not allow illegal time stamps. The server console will display a synthetic time error when the server time is behind the DS time. Action: Check for other errors first and resolve any you find. Then Repair Time stamps (found in the 4.10 DSREPAIR) which will reset the time stamps to the current server time. The 4.0x equivalent of Repair Time stamps is Rebuild Replicas and is performed from Partition Manager. This action will delete the objects from all replicas except the Master and then recopy all objects from the Master copy to all other replicas. CAUTION! If the Master copy was corrupt in any way, that corruption will be propagated out to the other replicas when a Repair Time stamps or Rebuild Replicas action is performed. Repair Time stamps or Rebuild Replicas can also cause considerable traffic on the network. You may have to do this on a partition by partition basis. -663 0xFFFFFD69 FD69 DS_LOCKED Explanation: The Directory database is locked on the server. The server with the problem will often get an error trying to open the directory when mounting the SYS volume. This error will occur when DSREPAIR is loaded on the server and repairing the database, when the hard drive on the server is going bad, and when a new 4.02 server install does not complete properly. Action: Try running DSREPAIR on the server ONCE. If DSREPAIR is run more than once, the .old database files are overwritten). If DSREPAIR doesn't fix the problem, try downing the server and bringing it back up again. If DSREPAIR and downing the server do not fix this error, the server may need to be removed from the tree and reinstalled. See the section on DSMAINT before performing this process. -669 0xFFFFFD63 FD63 FAILED_AUTHENTICATION Explanation: An invalid password was sent. Authentication failed. The most likely problems are either in the remote ID or the public key. Action: Try running DSREPAIR with the option to verify remote server IDs on the source server and all other servers in the replica list. If there are errors in the DSREPAIR.LOG file, run DSREPAIR with the option to verify remote server IDs once more on every server in the replica list. This should correct a problem with the remote ID being incorrect. If the source server is either using or looking at the wrong public key (the key is the right format, but is for the wrong object) the problem is the public key: a) If the source server has a REAL copy of the target server object (so if the source server has a Master, R/W, or R/O replica of the partition containing the target server object) then check to see if the other servers in that replica list (for the partition containing the target server object) are able to authenticate to the target server. If another server CAN authenticate successfully, then do a Send All Objects (see note on Send All Objects above) from the good server, or Receive All Objects on the target server (but only if the server with the "good" copy has the Master). Remember that Send All Objects generate a lot of traffic. If no servers can authenticate to the target server, remove DS from the target server and reinstall it back into the tree or call your Novell Authorized Service Center for support. b) If the source server has a subordinate reference replica or no replica of the partition containing the target server object, then the external reference to that object will need to be re-backlinked. Call your Novell Authorized Service Center for support. -672 0xFFFFFD60 FD60 NO_ACCESS Explanation: The client does not have sufficient results to complete the requested operation. Also, this error can indicate that the target server's replica list doesn't match the source server's replica list. Action: Compare the replica ring information for all the servers in the replica list (available though Display Replica Information). If you confirm that the target server doesn't have the source server in it's replica list, then either remove DS from the target server or call your Novell Authorized Service Center for support. -673 0xFFFFFD5F FD5F REPLICA_NOT_ON Explanation: The replica is in the process of being created on a server. Until all the object information has been received on that server, the replica is "off" (not available for use by Directory clients). Action: This error will resolve itself when the process is complete. If it does not appear to resolve itself, look for an error that is preventing the replica from turning "on" and address that problem. -699 0xFFFFFD45 FD45 FATAL Explanation: An unrecoverable error has occurred and the operation cannot be completed. Action: Because this error can be caused by different problems it is not possible to provide a simple solution. Call your Novell Authorized Service Center for support. ERRORS NOT LISTED If an error is not referenced here, please consult the complete Error Codes document available from NetWire, on CompuServe. The file is located in NovLib 14, the file name changes periodically to reflect updates to documents contained within the archive. The basic filename is TNDS#.EXE where # is a number from 2 to 9, then A through Z. (For example: TNDS1.EXE was replaced by TNDS2.EXE due to updates made to documents within the file.) TNDS2.EXE was publicly available at the time this document was prepared. VII. SOME FREQUENTLY ASKED NDS QUESTIONS. 1. What is error -631 when trying to SET BINDERY CONTEXT on server? Be sure that a partition replica containing the context to be bindery emulated exists on this server. 2. What is the message "Synthetic time is being issued on partition..."? In NetWare 4.10 synthetic time will be issued at a server with the error "DS- 4.63-12" if the server time is set backwards. The synthetic time will be cycled every 2 minutes until the server time is after the last modified timestamp. You may fix the problem from DSREPAIR by selecting Advanced Options, Replica and Partition Operations. Next select the partition you want to update and then select Repair Time stamps and declare a new epoch. 3. Users are being logged out at wrong times and/or time restrictions are being shown incorrectly. Be sure that the workstation TZ variable is set. You may do this in the workstation AUTOEXEC.BAT file by adding the line SET TZ=timezone or perform the task in the login script by adding the line DOS SET TZ="timezone" 4. Where can I find a complete list of NDS error codes? These can be obtained from the file TNDSx.EXE in library 14 of the NOVLIB forum on NetWire. (Where x is the version number - see above).