NetWare Directory Services:

NetWare 4.02 NDS Guidelines

NetWare 4.02

October 12, 1994

Version 1.01

Disclaimer

Novell, Inc. makes no representations or warranties with respect to the contents or use of this manual, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.

© 1994 by Novell, Inc. All rights reserved.

This document may be freely copied and distributed as long as it is reproduced in its entirety and for the benefit of the network product developers. Portions of this document may be included with other material as long as authorship is attributed to Novell, Inc. and appropriate copyright notices are included.

Novell, Inc.

122 East 1700 South

Provo, Utah 84606

Trademarks

Novell has made every effort to supply trademark information about company names, products, and services mentioned in this document. Trademarks indicated below were derived from various sources.

Novell and NetWare are registered trademarks of Novell, Inc.

NDS and NetWare Directory Services are trademarks of Novell, Inc.

Contents

Introduction	4

Designing NDS Trees	4

The Fourth Replica Type	4

Design Considerations	6

Maintaining NDS Trees	7

Determining the Synchronization State of a Server	7

Taking a Server or WAN Link Down	8

Renaming a Server or Changing the IPX Address	9

Partition Operations	10

Problems and Solutions	10

Data Failure	10

Hard Disk Failure Not Involving Volume SYS	11

Procedure	11

Hard Disk Failure Involving Volume SYS:	11

Procedure.	11

Communication Failure	13

LAN or WAN Link Failure	14

CPU Failure	16

Long-Term Communication and CPU Failure	16

Procedure.	17

Reinstalling a Server	18

Procedure	18

Introduction

This document gives network administrators some guidelines on how to design, maintain, and troubleshoot an NDS™ (NetWare Directory Services™) tree. These guidelines include instructions for:

Designing a tree that performs well and is easy to maintain and troubleshoot.

Preserving NDS tree integrity when you perform a planned shutdown of a server or WAN link.

Changing server names and IPX addresses safely.

Performing partition operations safely and efficiently.

Responding to NDS error conditions.

This document is written for use by network administrators who understand NDS configuration and administration concepts.

Designing NDS Trees

You can minimize maintenance of Directory Services by setting up your partitions and replicas as efficiently as possible. To do this, you need to understand how NDS works behind the scenes.

This document does not discuss NDS planning issues in detail but provides general background information and recommendations to help you determine where to place partitions and replicas.

The Fourth Replica Type

NDS uses three types of replicas that almost every NetWare 4 administrator or installer is aware of: master, read/write, and read only. The fourth replica type is seldom referred to but is an important part of NDS communication. This replica type is called a subordinate reference.

Before you learn what a subordinate reference is, you must understand the relationship between a parent partition and a child partition. A child partition is one that is subordinate in the tree to another partition called the parent. For example, in the illustration on page 4, the Marketing, Eng., and Sales partitions are child partitions of the parent partition [Root].

A subordinate reference links a parent partition and a child partition. It contains a list of the servers where replicas of the child partition are stored, their addresses, and replica types, as well as other NDS partition information.

Currently, the Partition Manager utility does not list subordinate references because it considers them replicas of the child partition; however, subordinate references do not contain any of the Directory Services data stored in the partition itself. Each file server that contains a replica of the parent partition also contains a subordinate reference of every child partition that is not located physically on that server.

Consider the following illustration:

This tree contains four partitions ([Root], Mktg, Eng, and Sales) and three file servers (FS1, FS2, and FS3). Each file server holds the only copy of the partition in which it is contained; the [Root] partition is stored on FS1. The replica table for this tree will look like this :

Table 1: Original Replica Table of Sample NDS Tree

[Root]

Mktg

Eng

Sales

FS1

Master

Master

Sub_Ref

Sub_Ref

FS2

Master

FS3

Master

Notice that this tree contains a total of six replicas: a master replica for each partition and two subordinate references. FS1 contains subordinate references for Eng. and Sales because their parent, [Root], physically resides on the server but they do not. Neither FS2 or FS3 needs a subordinate reference because Eng. and Sales have no child partitions.

As the number of servers that contain replicas of the [Root] partition increases, the number of subordinate references will most likely increase. Let's assume that we decide to store a copy of the [Root] partition on every file server in the tree. The replica table will look like this :

Table 2: Replica Table of Sample NDS Tree with Additional Servers

[Root]

Mktg

Eng

Sales

FS1

Master

Master

Sub_Ref

Sub_Ref

FS2

Read/Write

Sub_Ref

Master

Sub_Ref

FS3

Read/Write

Sub_Ref

Sub_Ref

Master

Although you might think you added only two additional replicas to your tree (copies of [Root] on FS2 and FS3), the number of replicas has actually doubled from six to twelve. While replicas are necessary for fault tolerance, creating unnecessary replicas can needlessly increase the number of subordinate references in your tree.

Design Considerations

Having subordinate references is not necessarily incorrect or wrong but does have some important ramifications. Any partition operations, such as creates, merges, or deletes, affect subordinate references the same way they affect read/write and read-only replicas. In other words, you need to consider subordinate references in your partition and replica design as you would read/write and read-only replicas.

For example, you would not want to have subordinate references link partitions across unreliable communication links. If you wanted to make a partition change such as a merge and the link was not available, you would not be able to complete the merge until the subordinate references across that link became available. In the meantime, the directory tree would not be synchronized.

The most effective way to reduce the number of subordinate references is to reduce the number of file servers that contain a copy of the [Root] partition. Having fewer subordinate references will reduce the number of replicas you need to update when you make partition changes, reducing the chance that synchronization will not occur because file servers or communication links are not available.

We recommend the following steps for reducing the number of subordinate references:

•	Create few partitions at the top levels of the tree, with more partitions at the lower levels.

Workgroup boundaries generally determine the number of partitions required in any tree. You should partition your tree according to how network resources are used and where they are located in the directory tree. Be careful not to create unnecessary partitions.

Design your tree like a triangle with a small number of partitions at the top of the tree and more partitions as you move toward the bottom. Such a design will create fewer subordinate references than a top-heavy tree that has more partitions at the top than at the bottom.

•	Minimize the number of replicas of the [Root] partition and other parent partitions.

As mentioned above, fewer replicas of the [Root] partition mean fewer subordinate references. This holds true for other parent partitions as well. Remember that every server that contains a replica of a parent partition will receive subordinate references of that parent's child partitions.

Keep in mind that the main reasons for replicating are fault tolerance (in which two to three copies of a replica should be sufficient) and placing directory services data close to the users who need it. If you design your tree with the users in mind, you should not need too many replicas.

Maintaining NDS Trees

This section contains guidelines for maintaining NDS trees. NDS provides global resources throughout the network, resulting in greater dependency between servers. The global nature of NDS requires that you understand how to:

Determine the synchronization state of a server.

Take a server or WAN link down.

Rename a server or changing IPX address.

Perform partition operations.

Determining the Synchronization State of a Server

Because of the global nature of NDS, you must always check a server's partition state before you perform certain NDS operations. To determine a server's synchronization state, follow these steps at the console:

.	Type Set dstrace=on.

.	Type Set dstrace=*h.

.	Toggle to the directory services screen.

.	Check the Directory Services screen for the message All processed= YES for each partition on the server. You can perform NDS operations safely when you receive this message for all the partitions on that server.

Note

If any error messages appear, please refer to the "Problems and Solutions" section of this document.

Taking a Server or WAN Link Down

Before you take a server or WAN link down, make sure you check the servers' synchronization states. In addition, consider the following issues:

If you are going to remove NDS from a server and want to preserve trustee rights, we recommend that you do an NDS- aware SMS backup. An NDS-aware backup stores the trustee information by object name and not by object ID.

Note

When you remove Directory Services, the uninstall process creates a file that maps NDS names to object IDs. This file restores the trustee rights when you reinstall Directory Services.

You should always have at least three copies of each partition in the NDS tree to provide fault tolerance.

If you remove replicas from a server, you will lose access to the server through bindery services.

Table 3 shows other required actions for each planned event.

Table 3: Managing NDS

During the Planned

Shutdown of a Server

or WAN link

Planned Event

Required Action

Downing a server or WAN link permanently.

Remove Directory Services from the server.1

Downing a server or WAN link temporarily if you are replacing the SYS: hard drive.

Remove Directory Services from the server.1

Downing a server or WAN link temporarily if any of the following are required:

Partition operations

Large numbers of changes, adds, or deletes of replicas.

Relocation of the server to another site.

Remove the replicas from the server before downing the server or WAN link.2

1 Make sure to backup your data properly before performing this operation if you plan on bringing the server back up. If you fail to do a backup you may lose trustee assignments.

2 Bindery emulation will be lost on the servers from which partitions are removed.

Renaming a Server or Changing the IPX Address

Before you rename a server or change the IPX address, make sure you check the servers' synchronization states. Also be sure that the server contains a replica of the partition in which the server object is contained.

Follow these steps to change the server name or IPX address:

.	Edit the AUTOEXEC.NCF file to change the name or address.

.	Down the server.

.	Restart the server.

.	Type Set dstrace=on.

.	Type Set dstrace=+limber.

.	Type Set dstrace=*l.

.	Toggle to the Directory Services screen.

.	Check the Directory Services screen for the messages Limber: start connectivity check and Limber: end connectivity check. These messages mean that you have changed the server name or IPX address safely.

Note

If any error messages appear, please refer to the "Problems and Solutions" section of this document.

To change a server's context in the tree, follow these steps:

.	Use NWAdmin or NetAdmin to move the server object in the tree.

.	Go to a server console.

.	Type Set dstrace=on.

.	Type Set dstrace=+limber.

.	Type Set dstrace=*l.

.	Toggle to the directory services screen.

.	Check the Directory Services screen for the messages Limber: start connectivity check and Limber: end connectivity check. These messages mean that you have changed the server name or IPX address safely.

Note

If any error messages appear, please refer to Appendix A of the NetWare 4.0 manual System Messages II.

Table 4: Managing the

Network for Changing

of Server Name or

Internal IPX Address
Planned Event

Required Action

Renaming a server or changing the IPX address.

Edit the autoexec.ncf file.

Check the DSTrace screen.

Changing the server context.

Move the server object.

Check the DSTrace screen.

Partition Operations

Before you perform any partition operations, make sure you check the synchronization states of all servers that contain copies of the affected partitions. Please refer to the table below to determine which partitions are affected.

Table 5: Managing the

Network for Partition

Maintenance*

Partition Operation

Partitions affected

Create, add, or delete a partition.

Check the target partition(s).

Change the replica type.

Check the target partition(s).

Rebuild the replica(s).

Check the target partition(s).

Merge partitions.

Check the parent and child partition(s).

Problems and Solutions

Hardware problems that affect Directory Services fall into two categories: data failure and communication failure. This section provides strategies for you to recover from hardware problems as quickly as possible with minimal disruption to Directory Services.

Data Failure

Data failure is usually caused by a defective hard drive or support device, such as a controller, host adapter, paddle board, cable, terminator, or power supply. If the faulty device is something other than the hard drive, normally you need only to replace the device to recover fully. The following sections outline the steps you must take if the data failure is caused by a defective hard drive.

Hard Disk Failure Not Involving Volume SYS

If the hard drive failure does not involve volume SYS:, you do not need to modify or reinstall NDS. As soon as the volume is mounted again, the NDS volume object will function as before.

Procedure. To restore a volume after a hard disk failure not involving Volume SYS:, follow these steps:

1.	Replace the bad hard drive.

2.	Create a NetWare partition, and define volumes using Install.

3.	Mount the volumes.

4.	Restore data, file ownership, and trustees using your backup system. If the backup system is unable to restore file ownership and trustee information, you will have to do this manually.

The restoration of the volume is complete.

Hard Disk Failure Involving Volume SYS:

Because the NDS database is located on volume SYS:, a hard drive crash involving volume SYS is equivalent to removing NetWare 4.x from the file server. You will need to reinstall NetWare 4.x and NDS before you restore your data. To remove and reinstall the server into the tree, complete the following steps:

Procedure. To restore the replicas to the server that experienced the hard disk crash, follow these steps:

1.	Document the replicas located on the server. To do this, use Partition Manager to select the server object and record the replicas listed.

2.	If any of the replicas displayed in step 1 is a master replica, you will have to designate a new master on a different server in the tree. To do this, you will need to run DSRepair on a server that has an up-to-date read/write replica of the partition you need to change. To change the replica type, follow these steps:

a.	Load DSRepair.

b.	Choose option 1 (Select Options).

c.	Select option 4 (Repair replica ring with no master), and deselect options 5, 6, and 7.

d.	Return to the selection menu by choosing option 8.

e.	Choose option 2 (Begin Repair). If a log file is present, you will have the option of overwriting, appending, or not logging the errors.

f.	After DSRepair has completed its routine, the computer asks which partition should be changed to the master. Select the number of the partition you want to change.

g.	Type Y (for yes) when the prompt asks if you want to save repairs to the DIB.

h.	Exit DSRepair (NDS will remain locked until you exit DSRepair).

3.	Using Partition Manager, delete the server object of the server on which the hard drive crashed. Using NetAdmin or NWAdmin, delete the volume objects associated with the server.

4.	At the server console, type SET DSTRACE=ON on all the servers that contain copies of the partition in which the deleted server object was located. Resolve all errors before proceeding further. If any 625 errors occur while NDS is trying to connect to the server deleted in Partition Manager, wait to see if the error clears up. If the error remains, follow the steps outlined in step 5; otherwise, skip to step 6.

5.	Remove replica pointers to the deleted server using DSRepair. Normally, you need only to perform the following steps on the master replica. NDS should synchronize the deletion. If following the steps does not clear up the 625 errors, you will have to perform the same steps on all of the servers containing replicas of the partition in question. To remove the deleted server out of the replica pointer, list follow these steps:

a.	Load DSRepair.

b.	Choose option 1 (Select Options).

c.	Select option 4 (Repair replica ring with no master), and deselect options 5, 6, and 7.

d.	Return to the selection menu by choosing option 8.

e.	Choose option 2 (Begin Repair). If a log file is present, you will have the option of overwriting, appending, or not logging the errors.

f.	After DSRepair has completed its routine, select the replica you want to edit.

g.	Choose option 2 (Manually edit the replica ring).

h.	Enter the number of the server from which the replica is going to be deleted (this is the name of the server where the hard drive has crashed and that has been deleted in Partition Manager).

i.	Press 1 to verify that the server has been deleted in the replica ring.

j.	Press 0 to exit replica ring editing.

k.	Type Y when the prompt asks if you want to save repairs to the DIB.

l.	Exit DSRepair (NDS will remain locked until you exit DSRepair).

Caution
Use the procedures listed in step 5 only to remove a deleted server object. Using this procedure to try to delete a live server from a replica pointer list will corrupt the list.

6.	Install the new hard drive. Using procedures recommended by the manufacturer, verify that the hard drive is working properly. We recommend that the new hard drive have the same or larger storage capacity as the drive it replaces.

7.	Reinstall NetWare the same way you previously installed it. After you have defined the configuration and copied the NetWare 4.x files, the NDS portion of install appears on the screen. At this point you can install the server to the previous context or to a context of your choice. If you choose a different context, NDS-style drive mappings to the old context will become invalid. Bindery drive mappings are not affected.

8.	Use Partition Manager and the list you generated in step 1 to place replicas on the server. The completion time needed to restore replicas depends on the speed of your LAN or WAN environment.

9.	Use the backup system to restore the server's data. The backup system restores not only data but file ownership and user trustee information. If the backup system is unable to restore file ownership and trustees, you will have to create them manually.

10.	Set the bindery context if needed.

The restoration of the server and volume is complete.

Communication Failure

Communication failure can be divided into three general categories:

WAN link failure

LAN failure

CPU box failure

In all three cases, the DSTrace screen will show a 625 error. If you repair the failure quickly, you need only resolve the problem causing the 625 error.

If you want to perform a partition or replica operation before you eliminate the 625 errors, you must first remove the server that is not communicating. Please refer to the section "Long-Term Communication and CPU Failure" for instructions on removing the server. Making partition changes while a server holding a replica involved in the change is not communicating will impede NDS's performance.

To make sure that the 625 error condition still exists type SET DSTRACE=ON at the console prompt on the server. Then type SET DSTRACE=*U. This will cause NDS to try to communicate with the server. If the error still exists, the system has a communication problem.

LAN or WAN Link Failure

LAN or WAN communication failures can have many causes.

The following list shows the most common causes of DIRECTORY SERVICES's 625 errors.

The link is completely down. You should be able to isolate this problem easily because none of the resources on the other side of the link will be available.

The link is sporadic. In other words the link is providing consistent enough performance for SPX to function but not enough for NDS information to synchronize. This can be a difficult problem to isolate because often the other SPX applications work fine, but NDS still returns 625 errors when it tries to access a server on the other side of the link. In this specific case you may be able to work around this problem using a couple of DSTrace commands to increase the listening time. Listening time is the time after which IPX will time out if it gets no response from a device on the network. To use these commands you need to understand the following formula.

Listening Time = Tick Count x Scale Factor + Shift Factor

!Y	!Z

Tick Count:	This value is provided by IPX (or the transport protocol that is being used) and is calculated by the server based on routing information it has received.

Scale Factor:	This value is multiplied. For this reason you need to be careful not to change the value too far from default (default value is 16, range is 1-80).

Shift Factor:	This value is used to granulate the scale factor (the default value is 10, range is 1-500).

Here is an example of how to set the X, Y, and Z parameters:

SET DSTRACE=ON

SET DSTRACE=!X4

SET DSTRACE=!Y20

SET DSTRACE=!Z40

The !X parameter changes the number of IPX retries that occur before a 625 message is sent to the console. The default value is 3, and we recommend that you set the value no higher than 5. The range is from 1 to 500.

Caution
Do not change the X, Y, and Z parameters unless absolutely necessary. If you increase these values, in some processes NDS performance will drop significantly. We suggest that instead of raising these values you improve the link used increase the capacity. If you increase the Y parameter, we recommend that you create local copies of all of the objects referenced by the users so that the link is not used. This way the link will be used primarily for synchronization and not to access NDS objects. If you do not follow these recommendations, 4.x users may see a significant performance degradation.

The RAM buffering in the router is not large enough to provide consistent flow of packets. In many cases, NDS will perform best if you increase RAM buffering significantly.

Dropped packets may indicate a need for increased buffering. Different routers have different methods for checking for dropped packets. Some routers allow you to check statistics using SNMP services; other routers can connect to a terminal. Check with the manufacturer if you have questions about the router in question.

The router is performing some type of SAP filtering. The two SAP numbers that cannot be filtered are 26Bx (Time Synchronization) and 27Ax (Directory Services). If you are unsure how to check for SAP filtering refer to the router's manual or with the manufacturer.

After you have checked obvious causes, check to see if a marginal LAN card is the source of the problem. NDS will show a communication problem as 625 on the Directory Services Trace Screen. Look for bad packets or dropped packets that may be a sign that a LAN card is malfunctioning. Sometimes, installing a higher performance card will solve the problem.

CPU Failure

CPU failure occurs when the server abends, hangs, or will not run NetWare. While the server is not up and running, other servers in the tree will send a 625 error to the Directory Services Trace Screen. If you can resolve the cause of the failure quickly, you do not need to modify or reinstall NDS. If you want to perform a partition or replica operation before you resolve the CPU problem, you must remove that server before you attempt those operations. Please refer to the section below on "Long-Term Communication and CPU Failure" for instructions on removing the server. Performing partition changes while a server containing a replica involved in the change will impede NDS's performance.

Long-Term Communication and CPU Failure

Generally speaking, you should not leave unsynchronized servers in the tree for long periods of time, which may be defined by how often certain changes are made in the tree. If you must delete objects or make partition structure changes, then an unsynchronized server has been out of sync too long.

When you delete an object, the system does not purge it from the database until all the servers holding a copy of that object are informed of that deletion. If large numbers of additions and non- purged deletions are occurring in the tree, the NDS database will increase in size. This may pose a concern if any server in the tree has limited disk space on volume SYS:. In this case you may need to remove an unsynchronized server from the tree.

A partition structure change occurs when a partition is merged or created, or when a replica is added or deleted. None of these changes will be completed if a server holding a copy of a replica cannot be synchronized. If you need to make partition changes, you should remove from the tree any unsynchronized server.

Procedure. To recover from a long-term communication or CPU failure, follow these steps:

1.	If you need to restore the exact replicas on the server being removed, use Partition Manager to document the replicas. To do this, select the server object and record the replicas shown.

2.	If any of the replicas displayed in step 1 is a master replica, you must designate a new master on a different server in the tree. To do this, you will need to run DSRepair on a server that has an up-to-date read/write replica of the partition you need to change. To change the replica type, follow these steps:

a.	Load DSRepair.

b.	Choose option 1 (Select Options).

c.	Select option 4 (Repair replica ring with no	master), and deselect options 5, 6, and 7.

d.	Return to the selection menu by choosing option 8.

e.	Choose option 2 (Begin Repair). If a log file is present, you will have the option of overwriting, appending, or not logging the errors.

f.	After DSRepair has completed its routine, the system asks which partition you want to change to the master. Select the number of the partition you want to change.

g.	Type Y when the prompt asks if you want to save repairs to the DIB.

h.	Exit DSRepair (the NDS will remain locked until you exit DSRepair).

3.	Using Partition Manager delete the server object of the server you are removing. Using NetAdmin or NWAdmin, delete the volume objects associated with the server.

4.	At the server console type SET DSTRACE=ON on all the servers that have copies of the partition in which the deleted server object was located. If any 625 errors are trying to connect to the server you deleted in Partition Manager, wait to see if the error clears up. If the error remains, follow the steps outlined in step 5; otherwise, skip to step 6.

5.	Remove replica pointers to the deleted server using DSRepair. Normally, if you perform the following steps on the master replica, NDS should synchronize the deletion. If doing so does not clear up the 625 errors, you will have to perform the same steps on all of the servers holding replicas of the partition in question. To remove the deleted server out of the replica pointer list, follow these steps:

a.	Load DSRepair.

b.	Choose option 1 (Select Options).

c.	Select option 4 (Repair replica ring with no master), and deselect options 5, 6, and 7.

d.	Return to the selection menu by choosing option 8.

e.	Choose option 2 (Begin Repair). If a log file is present, you will have the option of overwriting, appending, or not logging the errors.

f.	After DSRepair has completed its routine, select the replica that you want to edit.

g.	Choose option 2 (Manually edit the replica ring).

h.	Enter the number of the server from which you want to delete the replica (this is the name of the server whose hard drive has crashed and has been deleted in Partition Manager).

i.	Press 1 to verify that the server has been deleted from the replica ring.

j.	Press 0 to exit replica ring in editing.

k.	Type Y when the prompt asks if you want to save repairs to the DIB.

l.	Exit DSRepair (the NDS will remain locked until you exit DSRepair).

Caution
Use the procedures listed in step 5 only to remove of a deleted server object. Using this procedure to try to delete a live server out of a replica pointer list will result in a corrupt list.

The removal of the server is complete.

Reinstalling a Server

After the communication failure has been resolved or the server hardware is in good working order, the server is ready to be reinstalled into the tree.

Procedure

1.	Load Install, and choose Directory install. Move through the install screens the same way you did when you first installed the server. You can install the server to the previous context or to a context of your choice. If you choose a different context, NDS-style drive mappings to the old context will become invalid.

2.	Use Partition Manager to place replicas on the server. The time it takes to restore replicas depends on the speed of your LAN/WAN environment.

3.	Set the bindery context if needed.