10 Tips for Troubleshooting NDS
Articles and Tips: article
01 Nov 1999
If you are like most network administrators, you dread something going wrong with your company's network. Troubleshooting is undoubtedly one of the most frustrating and time-consuming responsibilities you face. In many cases, relatively minor problems, such as not being able to add or modify passwords, are more difficult to isolate than major problems, such as a server going down.
10 EASY TIPS
Many problems that occur in the Novell Directory Services (NDS) database start out as minor problems. If you don't resolve these minor problems, however, they can become major problems over time. This article provides 10 tips for troubleshooting NDS problems. You can use these tips to ensure that the NDS database functions normally and to prevent problems from affecting your company's network.
1. Ensure that NetWare's time service is running on each server and that time is synchronized across the network.
One of the most common causes of NDS problems is that time is not synchronized between network servers. Time synchronization is extremely important because NDS keeps track of all changes made to the NDS database by time stamping them. If time is not synchronized, the NDS database cannot replicate changes across the network, causing significant NDS problems.
For example, if time is not synchronized between network servers and you add a User object, you may discover later that the User object does not appear in the NDS tree. In addition, you may not be able to access information about NDS objects, and users may not be able to print to PSERVER-based printers.
If you are experiencing these types of problems, you may want to take a look at time synchronization. Time synchronization problems can occur for several reasons:
NetWare's time service is not configured properly. For example, the network may have multiple reference servers or no reference server.
An equipment failure may prevent some servers from communicating with each other.
A server was shut down, and the CMOS clock did not match the actual date and time when the server was restarted.
A server was configured with an incorrect time zone or with no time zone.
Someone reset the date and time on a server in an active NDS tree.
Time synchronization problems are relatively easy to isolate. At each server console, you enter the following command:
TIME
The server then displays the current date and time, as well as basic time service information. For example, a particular server might display the following information:
Time zone string: "MST7MDT" DST status: ON DST start: Sunday, April 2, 2000 2:00:00 am MST DST end: Sunday, October 31, 1999 2:00:00 am MDT Time synchronization is active. Time is synchronized to the network. Monday, September 6, 1999 5:57:45 pm UTC Monday, September 6, 1999 11:57:45 am MDT
The first line is the time zone string, which defines the time zone in which the server resides. You should ensure that the time zone string accurately reflects the server's geographic location. (To find out what time zone your company resides in, refer to the U.S. Naval Observatory's corrected time zone map at http://aa.usno.navy.mil/AA/faq/docs/world_ tzones.html.)
In the example above, MST stands for mountain standard time, and MDT stands for mountain daylight time. The number 7 indicates that the company is located seven hours west of coordinated universal time (UTC), which is the meteorological equivalent of Greenwich mean time (GMT).
The number of hours west of UTC is typically represented as a negative number, and the number of hours east of UTC is typically represented as a positive number. However, NetWare assumes that your company is located west of UTC. To simplify the configuration process, a negative value is built into NetWare, thus enabling you to enter a positive number for time zones that are west of UTC. NetWare automatically reads the positive number as a negative number.
Although this solution works well if your company is located west of UTC, it complicates the configuration process if your company is located east of UTC. For example, suppose that your company is located in the Western Australia time zone--eight hours east of UTC. Normally, this number is represented as a positive number. But if you enter WAST8WADT as the time zone string, NetWare reads that number as a negative number and assumes that your company is located in the Pacific time zone--eight hours west of UTC.
To get around this problem, you need to enter WAST-8WADT as the time zone string. Inserting a negative number negates the negative value built into NetWare, which then reads it as a positive number. (For more information about how NetWare handles time zone strings, see Novell's technical information document about time zone codes and offsets. To view this document, visit Novell's Support Connection web site at http://support.novell.com, and use the Knowledgebase feature to search for document number 2908587.)
After the time zone string, the next three lines displayed on the server console define the daylight-savings time configuration. The fifth and sixth lines indicate whether or not time synchronization is active on this server and whether or not the server's time is synchronized with the reference servers in your company's network.
Finally, the seventh and eighth lines display the current date and time both in UTC and in the server's time zone. If the eighth line displays the incorrect date and time for the server's time zone--especially if the reported date and time are in the past--this server may be using synthetic time to protect information about NDS objects.
Synthetic time allows NDS to continue providing time stamps to NDS and the server even if the date and time have been set into the future. For example, if you add a User object to a server whose time has been set into the future, the User object can be replicated because of synthetic time. Synthetic time allows a valid time stamp to be created for an object. The time stamp created is not based on the future date and time but instead on the last time stamp known on the server. Without synthetic time, the object cannot be replicated across the network because NDS does not recognize time stamps in the future.
According to Novell, synthetic time will not damage the NDS tree or its objects if time synchronization on the server with the future date and time is reset. (For more information about synthetic time, see document number 10012705 on Novell's Support Connection web site.)
2. Ensure that you have configured each NetWare server as the appropriate type of time server.
Another common cause of NDS problems is not properly configuring the time servers on your company's network. If you have not configured the time servers correctly, the servers do not know which server to contact for time synchronization. As a result, time may not be synchronized between your company's servers.
There are four types of time servers: single, reference, primary, and secondary. Single time servers respond to time requests from primary and secondary time servers, without allowing primary time servers to affect the single time servers' local time. Reference time servers also respond to time requests from either primary or secondary time servers. However, reference time servers allow primary time servers to affect the reference servers' local time. Primary time servers respond to time requests from reference time servers, other primary time servers, and secondary time servers. Primary time servers can also negotiate minor time differences between themselves to establish a common time. Secondary time servers typically only receive their time from the other time servers.
To determine what types of time servers are necessary for your company's network, you should follow some basic rules of thumb:
All networks must have either a single time server or a group of time servers containing a reference time server and two primary time servers. Either configuration provides a definitive source for all other servers to get the correct time. You will need to choose between having a single time server or the group of servers. You cannot have both. (If your company's network has a direct connection to the Internet, such as a T-1 connection, you can use RDATE from MurkWorks Inc. to synchronize time to an outside source. You may want to synchronize a single time server or a reference time server with an atomic clock or other reference time source. You can download RDATE free from MurkWorks's web site at http://www.murkworks.com. Similar utilities are available from other companies.)
If your company's network includes only one NetWare 4 or NetWare 5 server, you should define this server as a single time server. (NetWare 3 servers do not use time services.)
If your company's network includes multiple NetWare 4 or NetWare 5 servers that reside in a single location in a single NDS tree, you should define one server as a single time server. You should then define all other servers as secondary time servers.
If your company's network includes multiple NetWare 4 or NetWare 5 servers that reside in multiple locations within a single NDS tree, you should define one server in a central location as a reference time server. You should then define one server at each location as a primary time server, and you should define all other servers as secondary time servers.
If your company's network includes multiple NetWare 4 or NetWare 5 servers that reside in multiple locations within separate NDS trees, you should define one server for each location or NDS tree as a single time server. You should then define all other servers as secondary time servers.
You can use Novell's MONITOR utility to configure a time server. You select the Server Parameters option from the main menu, and you then select the Time option. Next, you define the default time server type and the timesync type. (For more information about configuring time servers, see document number 2930686 on Novell's Support Connection web site.)
If your company's network includes only one NetWare 4 or NetWare 5 server, you should define this server as a single time server.
3. Look for orphaned NDS objects.
When you make a change to an NDS object, that change must be completely replicated across the network. Each ser ver keeps old information until all other servers in a replica ring are updated and acknowledge a change. If you move an object from one container object to another, the object that is moved is tagged to prevent this object from being moved again before the first move is completed. If communication is lost to a server that must update its NDS information to reflect the move, that server may contain an orphaned object, and a move-in-progress error may occur because the move cannot be replicated completely. This problem is the most serious problem that can affect the NDS database without bringing it down.
To determine whether or not the NDS database includes orphaned NDS objects, you can manually start the replication process by entering the following commands at the server console:
SET DSTRACE=+SYNC SET DSTRACE=*H
You then toggle to the Directory Services screen. If a -637 error appears during the replication process, a move-in-progress problem may exist. To troubleshoot and correct this error, follow the instructions outlined in document numbers 2942837 and 2923724 on Novell's Support Connection web site.
4. Look for communications problems between servers on the network.
If minor communications problems occur during the replication process, servers may spend hours trying to replicate with each other. As with orphaned NDS objects, you can isolate communications problems by entering the following commands at the server console:
SET DSTRACE=+SYNC SET DSTRACE=*H
In this case, you toggle to the Directory Services screen to watch for a -625 error, which indicates that a communications problem exists. If a -625 error appears during the replication process, you should test your company's communications links. For example, you should ensure that your company's WAN links are not saturated, and you should check the cabling on the LAN segment. You should also ensure that no changes have been made to each server's identification information, such as the server name and the internal IPX address.
5. Look for duplicate network addresses assigned to each server.
If you change a server's internal network address, this address is replicated across the network. If another server already has the same internal network address, a conflict occurs.
In most cases, a server's internal network address is changed inadvertently. For example, in the course of performing a maintenance task, you might restart a server with the -na (No AUTOEXEC) switch. When the server prompts you to enter the internal network address, you could accidentally enter the wrong one.
To ensure that all servers have a unique internal network address, enter the following command at the server console:
LOAD DSREPAIR
The DSREPAIR utility's main menu appears, and you select Advanced Options from this menu. You then select the Servers Known to This Database option. Next, you select a server from the list of servers that appears, and you select the Repair All Network Addresses option. You repeat this process for each server in the list.
6. Look for duplicate SAP device names on the network.
Just as each server must have a unique internal network address, each device must have a unique Service Advertising Protocol (SAP) name. Otherwise, SAP cannot properly advertise each device's presence across the network. For example, suppose an NDS server and a print server have the same name, which SAP broadcasts across the network. Other servers may not be able to distinguish between the server running NDS and the print server. This confusion can lead to both replication and time synchronization problems.
7. Ensure that there is no software locking the NDS database.
Sometimes software loaded on a server may lock the NDS database. For example, if you load the DSREPAIR utility on a server that maintains a master replica or a read-write replica and you leave this utility running on the server, the NDS database may become locked because the replicas on this server cannot participate in the replication process. Another potential cause of a locked NDS database is backup software that crashes during the backup process. You should make sure that you exit the DSREPAIR utility and ensure that the backup software closes after completing the backup process.
8. Ensure that each server is running the same version of the DS NLM.
Some versions of the DS NetWare Loadable Module (NLM) cannot communicate with other versions of this NLM. In addition, different versions of the DS NLM that can communicate with each other may not be able to handle the same schema extensions. As a result, you should install the same version of the DS NLM on each server. If your company's network runs multiple versions of NetWare, you should ensure that each server is running the latest version of the DS NLM for that version of NetWare and that these versions of the DS NLM are compatible with one another. (Novell includes a compatibility list with each DS NLM update.) You should also ensure that each master replica resides on a server that is running the latest version of the DS NLM.
9. Ensure that you have installed the latest patches and updates.
You can prevent potential problems by ensuring that servers are running the latest patches and updates. To help you keep up with the available patches and updates, Novell offers a minimum patch list, which you can access through Novell's Support Connection web site (http://support.novell.com/misc/patlst.htm or ftp://ftp.novell.com/pub/updates). In addition, you can download free upgrades, client software, and evaluation copies of Novell products from http://www.novell.com/download. And you can download beta products, including patches and updates that are currently in beta testing, from http://support.novell.com/beta/public.
10. Follow Novell's guidelines for preventive maintenance.
Of course, the best way to tackle NDS problems is to prevent them from occurring in the first place. Novell recommends that you use the DSREPAIR utility to perform preventive maintenance for the NDS database. (To view Novell's guidelines for preventive maintenance, see "Using DSREPAIR to Maintain the Novell Directory Services Database,"Novell AppNotes, May 1998. You can download this article from http://support.novell.com/techcenter/articles/ana19980503.html.)
CONCLUSION
Just seeing an NDS problem may cause you stress. However, most NDS problems are minor inconveniences that you can easily isolate and fix. When you encounter an NDS problem, you should always investigate the simplest remedies first.
Mickey Applebaum provides technical support for The Forums (http://theforums.com) and operates Proactive Team Solutions, a consulting firm located in Salt Lake City.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.