The Doctor Is In

Performing an NDS Health Check

Jeffrey F. Hughes and Blair W. Thomas

Getting frequent checkups from your family doctor helps you maintain good health, prevent disease, and catch potential problems before they occur. Likewise, performing a Novell Directory Services (NDS) health check on a regular basis helps keep your company's NDS tree stable and efficient. A stable and efficient NDS tree, in turn, helps keep your company's IntranetWare or NetWare 4 network running smoothly.

The more preventative maintenance you do now, the less time you will have to spend troubleshooting problems later. This article provides guidelines for how often you should perform an NDS health check and then explains how to perform a basic NDS health check and a complete NDS health check.

HOW OFTEN SHOULD YOU CHECK YOUR COMPANY'S NDS TREE?

The faster an NDS tree grows, the more often you should perform an NDS health check. For example, if you are developing your company's NDS tree or if you are making frequent changes to this tree to reflect your company's growth, you should perform an NDS health check as often as once a week. If your company has an established NDS tree that requires few changes, however, you can perform an NDS health check less frequently, such as once a month.

To help you assess your company's NDS tree and decide how often you should perform an NDS health check, Novell Technical Services has defined two categories of NDS trees:

Your company has a dynamic NDS tree if you create a partition or add a server at least two or three times each week. Most companies with a dynamic NDS tree are in the process of developing this tree. For example, if you were upgrading a NetWare 3 network to an IntranetWare network, your company would have a dynamic NDS tree during the upgrade process.

In addition, some companies have a dynamic NDS tree because they are undergoing a period of change. For example, if your company were reorganizing, selling off parts of its business, or merging with another company, you would have to modify the NDS tree. During this period of change, your company's NDS tree would be dynamic.

If your company has a dynamic NDS tree, you should perform an NDS health check once a week. As the pace of change decreases and the NDS tree becomes static, however, you can begin to perform an NDS health check less frequently.

Your company has a static NDS tree if you create a partition or add a server every couple of months. If your company has a static NDS tree, you usually make only simple changes, such as adding or deleting User objects. Because you make fewer changes to a static NDS tree than to a dynamic NDS tree, you need to perform an NDS health check only once a month.

IT'S ALL IN THE DESIGN

The first time you perform an NDS health check, you should ensure that your company's NDS tree is properly designed. Creating an efficient design is essential in maintaining a healthy NDS tree. Unless your company's NDS tree undergoes considerable change, you must verify the design only once.

As a basic guideline, you should design your company's NDS tree in the shape of an upside-down tree, with a trunk at the top and branches extending below the trunk. You should then base the upper portion of the NDS tree on your company's WAN and the lower portion of this tree on your company's LAN.

For detailed information about designing an NDS tree, you can refer to the following articles:

You can also use Novell's SCANTREE utility to determine whether your company's NDS tree is properly designed. The SCANTREE utility can analyze an NDS tree and provide various statistics, such as how many levels the tree consists of and what type of leaf objects this tree contains. (See "Getting to Know the SCANTREE Utility.")

PERFORMING A BASIC NDS HEALTH CHECK

Whether your company has a dynamic NDS tree or a static NDS tree, you should perform a basic NDS health check before you begin any partition operation, such as adding or deleting a partition. To perform a basic NDS health check, you check the following:

Check NDS Version

Before you begin a partition operation, you should verify that the IntranetWare and NetWare 4 servers in your company's network are running the latest version of the DS NetWare Loadable Module (NLM). Novell recommends that, if possible, you run the latest version of the DS NLM on all IntranetWare and NetWare 4 servers. Running different versions of this NLM on the same network may cause synchronization problems and corrupt the NDS tree.

As we go to press, the latest version of the DS NLM for IntranetWare and NetWare 4.11 is DS.NLM 5.81, which is included with IntranetWare Support Pack 4.0. The latest version for NetWare 4.1 is DS.NLM 5.06, which is included with the DS410A.EXE file. Of course, if your company's network has both a NetWare 4.11 server and a NetWare 4.1 server, you can run DS.NLM 5.81 and DS.NLM 5.06 on the same network. (You can download IntranetWare Support Pack 4.0 and the DS410A.EXE file from http://support.novell.com/misc/patlst.htm.)

To check the version of the DS NLM, you can launch Novell's NDS Manager utility from a Windows NT or Windows 95 workstation. (If you want to use the NDS Manager utility, you should download IntranetWare Support Pack 4.0, which contains the latest version of this utility.) You can also load Novell's DSREPAIR utility at the server console. (If you want to use the DSREPAIR utility, you should download the DS410A.EXE file, which contains the latest version of this utility.)

To use the NDS Manager utility to check the version of the DS NLM, you complete the following steps:

1. Launch the NDS Manager utility from your workstation, and select the Tree option from the View pull-down menu. The NDS Manager utility's browser view appears.

2. Select the container object in which the servers you want to check reside.

3. From the Object pull-down menu, select the NDS Version option, and then select the View option. The View NDS Version dialog box appears, showing the current NDS context, the servers in this context, and the version of the DS NLM that is running on these servers. (See Figure 1.)

You can also use the NDS Manager utility to update the DS NLM. (For more information about updating the DS NLM, see "The NDS Manager Utility," NetWare Connection, April 1997, pp. 20­29.)

Check NDS Time Synchronization

You should also verify that the servers running NDS on your company's network are maintaining accurate time and that these servers are synchronized to the same time. Checking NDS time synchronization is important because the replica synchronization process uses timestamps to keep track of the order in which particular NDS events occur. (An NDS event occurs when you create or modify an NDS object or property.)

Each NDS object is automatically assigned two timestamps: one that indicates when the object was created and one that indicates when the object was last modified. In addition, each property of an NDS object is assigned one timestamp, which indicates when the property was last modified.

Timestamps ensure that the replica synchronization process performs updates in the correct order for each NDS object and property in a partition. NDS uses timestamps to find out when objects and properties in the partition's replicas were last updated. NDS can then determine which replicas need to be synchronized.

To check NDS time synchronization, you use the DSREPAIR utility to complete the following steps:

1. Load the DSREPAIR NLM at the server console.

2. From the Available Options menu, select the Time Synchronization option.

3. The Time Synchronization screen appears, displaying a list of every server running NDS on your company's network. (See Figure 1.) If a server is maintaining the same time as the other servers in this list, the word Yes appears in the Time Is in Sync column. If a server is maintaining a time that differs from the other servers in this list, however, the word No appears in the Time Is in Sync column.

If a server's time is not synchronized, you should not perform any partition operations until you correct the problem. (For more information about time synchronization, see "NetWare 4 Time Sync: Synchronize Your Network Servers," NetWare Connection, Oct. 1996, pp. 36­39.)

PERFORMING A COMPLETE NDS HEALTH CHECK

In addition to performing a basic NDS health check before you begin any partition operation, you should perform a complete NDS health check on a regular basis. To perform a complete NDS health check, you check the NDS version and NDS time synchronization. Then you check the following:

Check NDS Partition Continuity

You should randomly select several partitions on which to check NDS partition continuity. NDS partition continuity ensures that all servers holding a replica of the same partition are available to participate in a partition operation. If one or more of these servers are not available, synchronization errors may occur. For example, if a server went down, it could not synchronize with the other servers in the replica ring. (A replica ring includes every server that holds a replica of a particular partition. Each server in the replica ring maintains a list of all other servers in this replica ring.)

To check NDS partition continuity for a partition, you use the NDS Manager utility to complete the following steps:

1. Launch the NDS Manager utility from your workstation, and select the Partitions and Servers option from the View pull-down menu.

2. The partitions and servers view appears. Select the partition whose synchronization status you want to view, and then select the Partition Continuity option from the Object pull-down menu.

3. After you select the Partition Continuity option, the NDS Manager utility checks all of the servers that hold a replica of the partition to see if these servers are maintaining the same replica ring. The NDS Manager utility also checks to see if the servers are unable to participate in the replica synchronization process.

4. The Partition Continuity screen appears, displaying a list of every server that holds a replica of the partition. If a particular server's replica ring differs from the replica ring maintained by the other servers in this list or if the server is unable to participate in the replica synchronization process, an exclamation point (!) appears next to this server's icon, indicating a synchronization error.

5. If an exclamation point appears next to a server's icon, double-click the icon to view a context-sensitive help screen that provides information about the synchronization error. If no exclamation point appears next to any of the icons, all servers that hold a replica of the partition are properly synchronized and do not contain synchronization errors.

With the Partition Continuity option, you can perform operations that were previously available only in the DSREPAIR utility. When you perform the following NDS Manager operations, the DSREPAIR utility is automatically launched on a server to perform these operations: Synchronize Immediately, Receive Updates, and Send Updates. The NDS Manager utility then displays the status of each operation so you can determine whether a particular operation was successfully completed. (The NDS Manager utility displays a log file for some operations performed by the DSREPAIR utility.)

You can also use the NDS Trace feature, which is part of Novell's SET utility, to check NDS partition continuity. With NDS Trace, you can force the replica synchronization process to begin, and you can then monitor this process to determine whether any ser-vers are unavailable.

To use NDS Trace to check NDS partition continuity, you complete the following steps:

1. At the server console, enter the SET DSTRACE = ON command, which enables NDS Trace.

2. Enter the SET DSTRACE = +S command, which displays debug error messages for any errors that occur during the replica synchronization process.

3. Enter the SET DSTRACE = *H command, which prompts NDS to transmit a signal, or heartbeat. This heartbeat, which NDS transmits every 30 minutes by default, prompts each server that holds a replica to begin the replica synchronization process.

4. To view NDS Trace messages, press <Alt> <Esc> until the Directory Services screen appears. The message All Processed = Yes indicates that the replica synchronization process was successfully completed. The message All Processed = No indicates that a synchronization error occurred. (For information about error messages and suggested solutions, refer to Novell's Systems Messages manual.)

5. Press <Alt> <Esc> to return to the server console prompt. Enter the SET DSTRACE = OFF command to disable NDS Trace.

Check NDS Background Processes

Next, you should check NDS background processes. As the name implies, these processes run in the background, performing various tasks that are necessary to keep the NDS tree functioning properly. If an NDS background process fails, the NDS tree may experience synchronization or performance problems.

To ensure that NDS background processes are running smoothly, you should check the following:

Check External References. You should randomly select several servers on which to check external references. When a server refers to an NDS object that does not reside in any of the replicas on this server, NDS creates an external reference that points to the object.

By checking external references, you can determine whether the NDS objects to which the external references point still exist in your company's NDS tree. If some of these NDS objects no longer exist, the network may experience performance problems. You can minimize the number of external references by following the guidelines for NDS tree design.

To check external references on a server, you use the DSREPAIR utility to complete the following steps:

1. Load the DSREPAIR NLM at the server console.

2. From the Available Options menu, select the Advanced Options Menu option, and then select the Check External References option. This option prompts the DSREPAIR utility to check all external references contained in the server's external reference partition. (An external reference partition is a list of every external reference on this server.)

To check external references, the DSREPAIR utility locates the backlink of each NDS object to which an external reference points. (NDS uses a backlink to track all references to an NDS object. For example, a User object contains a backlink to each Group object to which the User object belongs.) Using the information listed in this backlink, the DSREPAIR utility performs the backlink process by locating the actual NDS object.

3. After the DSREPAIR utility verifies all external references contained in the server's external reference partition, a log file appears. This log file displays the number of external references on the server and the number of errors that occurred when the DSREPAIR utility checked external references.

If the DSREPAIR utility finds external reference errors on this server, you can use NDS Trace to monitor the backlink process and determine why these errors occurred. To use NDS Trace to monitor this process and view information about errors on a particular server, you complete the following steps:

1. At the server console, enter the SET TTF = ON command, which creates the DSTRACE.DBG log file in the server's SYS:\SYSTEM directory.

2. Enter the SET DSTRACE = ON command, which enables NDS Trace.

3. If a DSTRACE.DBG log file already exists, enter the SET DSTRACE = *R command, which prompts NDS Trace to clear the log file. This log file will then contain only new NDS activity.

4. Enter the SET DSTRACE = +BLINK command, which enables NDS Trace to display debug error messages for any errors that occur during the backlink process.

5. Enter the SET DSTRACE = *B command, which prompts the backlink process to begin.

6. To view NDS Trace messages, press <Alt> <Esc> until the Directory Services screen appears.

7. Press <Alt> <Esc> to return to the server console prompt, and enter the SET TTF = OFF command to save the DSTRACE.DBG log file to the server's SYS:\SYSTEM directory.

8. Enter the SET DSTRACE = OFF command to disable NDS Trace.

You can open the DSTRACE.DBG log file to view any errors that occurred during the backlink process. For example, an error would occur if an external reference pointed to a particular NDS object but the server on which this object resides did not respond to the NDS Trace query. In this case, the following error message would appear in the DSTRACE.DBG log file:

-626 all referrals failed

Check Obituaries. You should randomly select several servers running NDS on your company's network and verify that obituaries are being purged on these servers. (An obituary is an attribute created for an NDS object that has been moved, renamed, or deleted.) Because all servers do not receive updates simultaneously, these changes take some time to be replicated throughout the network. An obituary ensures that NDS retains outdated information for a particular NDS object until the updated information for this object has been replicated throughout the network. As soon as the update is replicated throughout the network and the replica synchronization process is completed, the obituary is purged.

An obituary can have the following values, or states:

For example, suppose that you deleted a User object from your company's NDS tree. NDS would create an obituary for the User object and assign this object a value of 0.

The replica synchronization process would notify all of the servers holding a replica of the partition in which the User object resides that this object had been deleted. NDS would then change the obituary's value to 1.

After every server had deleted the User object, NDS would change the obituary's value to 2. Finally, after all updates were replicated throughout the network, NDS would change the obituary's value to 4, and the janitor process would purge this obituary.

If obituaries are not being purged on a particular server, the server may be experiencing communication problems. For example, if you were filtering Service Advertising Protocol (SAP) type 278, the servers running NDS on your company's network could not exchange NDS information, and obituaries would not be purged.

To check obituaries on a server, you use the DSREPAIR utility to complete the following steps:

1. Load the DSREPAIR NLM at the server console.

2. From the Available Options menu, select the Advanced Options Menu option, and then select the Check External References option. This option prompts the DSREPAIR utility to display a list of external references and obituaries that have not been purged on the server.

If this server contains obituaries that have not been purged, you can use NDS Trace to purge these obituaries. To force NDS to purge the obituaries on a server, you use NDS Trace to complete the following steps:

1. At the server console, enter the SET TTF = ON command, which creates the DSTRACE.DBG log file in the server's SYS:\SYSTEM directory.

2. Enter the SET DSTRACE = ON command, which enables NDS Trace.

3. If a DSTRACE.DBG log file already exists, enter the SET DSTRACE = *R command, which prompts NDS Trace to clear the log file. This log file will then contain only new NDS activity.

4. Enter the SET DSTRACE = +J command, which enables NDS Trace to display debug error messages for any errors that occur during the janitor process.

5. Enter the SET DSTRACE = *J command, which prompts the janitor process to begin.

6. To view NDS Trace messages, press <Alt> <Esc> until the Directory Services screen appears. (See Figure 2.)

7. Press <Alt> <Esc> to return to the server console prompt, and enter the SET TTF = OFF command, which saves the DSTRACE.DBG log file to the server's SYS:\SYSTEM directory.

8. Enter the SET DSTRACE = OFF command to disable NDS Trace.

Check Remote Server IDs. If your company's network includes more than one server, you should check the remote server IDs on several servers running NDS on your company's network. Checking remote server IDs verifies that all servers on the network can communicate with one another. (A remote server ID is the network address of any server to which another server is authenticated.)

To check remote server IDs on a server, you use the DSREPAIR utility to complete the following steps:

1. Load the DSREPAIR NLM at the server console.

2. From the Available Options menu, select the Advanced Options Menu option, and then select the View Remote Server ID List option.

3. When the Local ID to Remote ID List screen appears, press the Enter key.

4. The Remote Server ID Options menu appears. Select the Verify All Remote Server IDs option. This option prompts the server to refer to its remote server ID table, which stores the remote server IDs of all other servers in the network. Using these remote server IDs, the server tries to authenticate to each server listed in its remote server ID table to verify that the remote server IDs are correct. If a remote server ID is incorrect, the DSREPAIR utility tries to repair it.

Check Unknown NDS Objects. You should check your company's NDS tree to determine how many unknown NDS objects it contains. If an NDS object is missing one of its mandatory attributes, NDS does not know how to classify the object and cannot perform any updates for this object. The NDS object then becomes an unknown NDS object.

Unknown NDS objects may appear in your company's NDS tree after you have upgraded from NetWare 3 to NetWare 4 or IntranetWare. Unknown NDS objects may also appear if you have deleted an NDS object's mandatory property or if the NDS database has been corrupted.

Because NDS eventually resolves many unknown NDS objects by finding the missing mandatory attribute, these objects do not usually cause critical problems. However, the number of unknown NDS objects may indicate the overall health of your company's NDS tree. For example, suppose that you recently upgraded from NetWare 3 to IntranetWare. If more than 25 percent of the NDS objects in the NDS tree are unknown, the upgrade process may not have gone smoothly, and other, more serious problems may exist.

To check unknown NDS objects in the NDS tree, you use Novell's NetWare Administrator (NWADMIN) utility to complete the following steps:

1. Launch the NWADMIN utility from your workstation.

2. From the Object pull-down menu, select the Search option.

3. The Search screen appears. Type [Root] in the Start From field, or browse for the NDS tree's [Root] object by clicking the browser icon. Then click the Search Entire Subtree box.

4. In the Search For field, scroll down the list of NDS object types, and select the Unknown option. Click the OK button. A message appears, indicating that searching the entire NDS tree could take a long time.

5. Click Yes if you want to perform the search. After the search is completed, a list of unknown NDS objects in the NDS tree appears.

If the NWADMIN utility finds any unknown NDS objects, check the NDS object type before deleting these objects. If the NWADMIN utility finds an unknown container object, such as a Server object, do not delete the object because you could cause a serious problem. For example, if you deleted an unknown Server object for a server that holds partitions or replicas, that server would not be able to participate in the replica synchronization process and might maintain outdated information. Before you delete any unknown container object, you should call Novell Technical Services for help.

If the NWADMIN utility finds an unknown leaf object, such as a User object, you can simply delete the object. If this object reappears, a replica ring mismatch may exist. (A replica ring mismatch occurs when one of a partition's replicas contains a particular NDS object, while another replica of the same partition does not contain the object.) If you cannot resolve this synchronization problem, you should call Novell Technical Services for help.

To delete an unknown leaf object, you should use the NWADMIN utility rather than the DSREPAIR utility. If you select the DSREPAIR utility's Delete Unknown Class Leaf Objects option, this utility deletes every unknown NDS object that does not hold other objects. To determine which NDS objects are unknown, the DSREPAIR utility uses only the information from the server on which you run this utility.

For example, suppose that you ran the DSREPAIR utility on a particular server and selected the Delete Unknown Class Leaf Objects option. If the server held a replica that contains an unknown Server object, the DSREPAIR utility would delete this object. However, the Server object might be marked as Unknown only in this replica, remaining valid on all other servers that hold a replica of the same partition. When the DSREPAIR utility deleted this Server object, NDS would create an obituary to ensure that all other servers would also delete the object. Because the Server object might be valid on these servers, deleting this object could damage your company's NDS tree.

Check the NDS Schema. You should check the NDS schema on several servers running NDS in your company's network to verify that all servers are running the same NDS schema. If these servers are not running the same NDS schema, the replica synchronization process may be unable to perform a particular update.

For example, suppose that you modified the NDS schema by adding a Job Title property to the User object type and that you then entered a job title for User object John. If a replica containing User object John resided on a server that was running an NDS schema without the Job Title property, the job title you entered would not be replicated to the server.

A server may be running a different NDS schema if an error occurred during the schema synchronization process. When you modify the NDS schema, NDS updates this schema on every server running NDS on your company's network. As with the replica synchronization process, however, the schema synchronization process cannot replicate updates throughout the network if certain errors occur, such as a server going down.

To check the NDS schema, you use NDS Trace to complete the following steps:

1. At the server console, enter the SET TTF = ON command, which creates the DSTRACE.DBG log file in the server's SYS:\SYSTEM directory.

2. Enter the SET DSTRACE = ON command, which enables NDS Trace.

3. If a DSTRACE.DBG file already exists, enter the SET DSTRACE = *R command, which prompts NDS Trace to clear the log file. This log file will then contain only new NDS activity.

4. Enter the SET DSTRACE = +SCHEMA command, which enables NDS Trace to display a schema message whenever an update to the NDS schema is synchronized.

5. Enter the SET DSTRACE = *SS command, which prompts NDS to begin the schema synchronization process for the entire NDS schema.

6. To view NDS Trace messages, press <Alt> <Esc> until the Directory Services screen appears. The message All Processed = Yes indicates that the schema synchronization process was successfully completed. The message All Processed = No indicates that a synchronization error occurred.

7. Press <Alt> <Esc> to return to the server console prompt, and enter the SET TTF = OFF command to save the DSTRACE.DBG log file to the server's SYS:\SYSTEM directory.

8. Enter the SET DSTRACE = OFF command to disable NDS Trace.

Check All NDS Background Processes. You should randomly select several partitions in your company's NDS tree and verify that NDS is properly performing each of its background processes. By checking all NDS background processes, you can view the "normal" NDS errors that occur. Rather than causing problems, normal NDS errors help ensure that all NDS background processes, such as the login process and the replica synchronization process, are successfully completed.

For example, a DSA common request error would occur if you tried to log in to the network using the wrong context. (See Figure 3.) A collision error, on the other hand, would occur if NDS tried to replicate an update to a particular server when the WAN link was down. In this case, a second server would take over, replicating the update to the first server via a different link. When the WAN link became available, NDS would again try to replicate the update, causing a collision error. (See Figure 4.) This error would prompt the first server to ignore the duplicate replication request.

To check all NDS background processes for a partition, you use NDS Trace to complete the following steps on each server that holds a replica of the partition:

1. At the server console, enter the SET TTF = ON command, which creates the DSTRACE.DBG log file in the server's SYS:\SYSTEM directory.

2. Enter the SET DSTRACE = ON command, which enables NDS Trace.

3. If a DSTRACE.DBG log file already exists, enter the SET DSTRACE = *R command, which prompts NDS Trace to clear the log file. This log file will then contain only new NDS activity.

4. Enter the SET DSTRACE = +IN command, which enables NDS Trace to display debug error messages for synchronization information that is being received by the server. This synchronization information is indicated by an asterisk (*).

5. Enter the SET DSTRACE = +S command, which enables NDS Trace to display debug error messages for NDS objects that are being synchronized between servers.

6. Enter the SET DSTRACE = +SCHEMA command, which enables NDS Trace to display a schema message whenever an update to the NDS schema is synchronized.

7. Enter the SET DSTRACE = +LIMBER command, which enables NDS Trace to display debug error messages for the limber process. This process verifies the server's name, its internal IPX address, and its connectivity with all other servers holding a replica of any partition that resides on this server.

8. Enter the SET DSTRACE = +MISC command, which enables NDS Trace to display debug error messages for all other NDS background processes, such as the bagging process. This process flags NDS information that is ready to be overwritten. For example, suppose that you changed a subordinate reference replica to a read-write replica. Unlike master replicas and read-write replicas, subordinate reference replicas do not contain actual NDS objects. Rather, subordinate reference replicas contain pointers that point to these NDS objects.

If you changed a subordinate reference replica to a read-write replica, the bagging process would flag the pointers contained in the subordinate reference replica so NDS could overwrite these pointers, replacing them with actual NDS objects. NDS would also overwrite any external references to reflect this change.

9. Enter the SET DSTRACE = +AGENT command, which enables NDS Trace to display a debug trace screen. This command also sets the BACKLINK, DSAGENT, JANITOR, RESNAME, and VCLIENT debug trace message flags. You can then view debug error messages for various NDS background processes while NDS performs the replica synchronization process.

10. Enter the SET DSTRACE = *H command, which prompts NDS to transmit a heartbeat that triggers the replica synchronization process.

11. To view NDS Trace messages, press <Alt> <Esc> until the Directory Services screen appears. The message All Processed = Yes indicates that the replica synchronization process was successfully completed. The message All Processed = No indicates that a synchronization error occurred.

12. Press <Alt <Esc> to return to the server console prompt, and enter the SET TTF = OFF command to save the DSTRACE.DBG file to the server's SYS:\SYSTEM directory.

13. Enter the SET DSTRACE = OFF command to disable NDS Trace.

CHECK NDS SET PARAMETERS

Finally, you should check NDS SET parameters, which define how the DS NLM behaves. Because many NDS SET parameters are tuneable, you can change their value to meet the needs of your company's network. However, the default value of NDS SET parameters should be adequate for most networks.

To check tuneable NDS SET parameters, you use NDS Trace to complete the following steps:

1. At the server console, enter the SET TTF = ON command, which creates the DSTRACE.DBG log file in the server's SYS:\SYSTEM directory.

2. Enter the SET DSTRACE = ON command, which enables NDS Trace.

3. If a DSTRACE.DBG log file already exists, enter the SET DSTRACE = *R command, which prompts NDS Trace to clear the log file. This log file will then contain only new NDS activity.

4. Enter the SET DSTRACE = *P command, which prompts NDS Trace to display the current value of each tuneable NDS SET parameter.

5. To view NDS Trace messages, press <Alt> <Esc> until the Directory Services screen appears.

6. Press <Alt> <Esc> to return to the server console prompt, and enter the SET TTF = OFF command to save the DSTRACE.DBG log file to the server's SYS:\SYSTEM directory.

7. Enter the SET DSTRACE = OFF command to disable NDS Trace.

If you want to change the value of a particular NDS SET parameter, you can use the SET utility at the server console to enter a new value. You can also use Novell's SERVMAN utility to modify an NDS SET parameter. (To find out how to use the SERVMAN utility, see "SERVMAN: The Anonymous, But Vital, NetWare 4 Utility," NetWare Connection, Nov./Dec. 1995, pp. 40­43.)

CONCLUSION

Although you may think that the steps outlined in this article sound time consuming, you can actually perform these steps quickly and easily. Not only does an NDS health check take just a few minutes, but it also saves you time in the long run by keeping your NDS tree functioning properly.

By performing an NDS health check on a regular basis, you can avoid potential problems and identify existing problems before they cause serious errors. Because the NDS tree is the backbone of your company's network, you simply cannot afford to postpone performing an NDS health check.

Jeffrey F. Hughes and Blair W. Thomas are senior consultants for Novell Consulting. They are the authors of the upcoming book Novell's Guide to Tuning and Optimizing IntranetWare by Novell Press.

NetWare Connection, December 1997/January 1998, pp. 33-41