41NDS6.EXE contains the following files:

README.TXT   - This text file

DS.NLM - Version 4.89c of the Directory Services for NetWare 4.10

DSREPAIR.NLM - Version 4.35 of the Repair utility for NetWare 4.10

DSMAINT.NLM - Version 4.92   This is a new DS maintenance 
utility which provides for more simple hardware maintenance.

DSMAINT.TXT - a text file describing steps for using DSMAINT.

UPGRADE.TXT - a text file describing the recommended process for
upgrading NetWare 4.0x to NetWare 4.10

DSREPAIR.NLM - Version 2.23 of the Repair utility for NetWare 4 
versions before version 4.10.  This file should be renamed to
DSREPAIR.NLM when copied to the file server. (NOTE: This version is 
contained in the 4.0x subdirectory).

REPAIR.DOC - a text file with instructions for the use of the
DSREPAIR.NLM version 2.23 (NOTE:  This file is contained in the 4.0x 
subdirectory).

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 41NDS6.EXE file contains DS.NLM version v4.89c 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.89c 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.35

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.35 contains new functionality and  will more
completely identify and correct data inconsistencies.  

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.35.  

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).

