'; zhtm += '

' + pPage + ''; zhtm += ''; window.popUpWin.document.write(zhtm); window.popUpWin.document.close(); // Johnny Jackson 4/28/98 } //-->

Migrating to Netware 4.1

- 13 -

Managing NDS

Setting Context at the Workstation
Using the Command Line for NDS Queries
- The CX Utility
- The NLIST Command
Using NetWare Administrator NDS Queries
Using the NetWare Administrator Tool to Move Container Objects
Time Synchronization Techniques
- Methods of Time Synchronization
- Implementing Time Synchronization
- Avoiding Time Synchronization Problems
- Building a Reference Time Server
Detecting NDS Problems
- Inconsistencies in the NDS Database
- Unsynchronized Replicas
- Problems with Synchronization When Servers Are Down
Troubleshooting NDS Problems
- Determining Synchronization Status of a Partition
- Restoring System Software after NDS or SYS: Volume Failure
- Updating Corrupted Replicas

Chapter 2 described NDS and showed you how to design an NDS tree. This chapter discusses some of the tools and techniques you'll need to manage your NDS tree once it's in place, including the following topics:

Setting NDS context at the workstation.
Using the command line for NDS queries.
Using NetWare Administrator for NDS queries.
Using NetWare Administrator to move container objects.
Implementing time synchronization.
Detecting and troubleshooting NDS problems.

Setting Context at the Workstation

NetWare 4.x client software provides the capability to set the current context before a user logs into the workstation. The Name Context configuration setting in the NET.CFG file provides this capability. The NET.CFG file is processed at the time the NetWare client software drivers and the network requester software are started.

The format of the name context configuration setting is as follows:

NAME CONTEXT = NDS Complete Path of Context

The NET.CFG statements are not case sensitive.

Suppose you want to set the current context at the time of LOGIN for user Bob to the following:

OU=CORP.O=SCS

You would simply include the following statement in the NET.CFG file:

Name Context = OU=CORP.O=SCS

TIP: You cannot enter a leading period (.) in the name context parameter. For example, the following is illegal in the NET.CFG file:

NAME CONTEXT=.OU=CORP.0=SCS

You can change the name context before logging in to the network using the CX (Change Context) command. Placing the name context statement in the NET.CFG file is a convenience to the user, because it can simplify access to the network resources the user most frequently uses. For this reason, it is best to set the name context to the container that contains the resources a user is most likely to use. If the name context of a user is set to the container that contains the user object, the user can log in to the network using the command

LOGIN UserLoginName

For user BOB, this would be as simple as logging in as follows:

LOGIN BOB

If the name context is set to a context different from the context of the user object, the user would have to use the NDS path to the user object.

LOGIN NDSPathToUserObject

For user BOB, whose user object is defined in OU=CORP.O=SCS, this would be

LOGIN .CN=BOB.OU=CORP.O=SCS

LOGIN .BOB.CORP.SCS

The second form demonstrates the use of the typeless complete name, whereas the first form shows the User object by its complete name with attribute designators (also called typeful name or typed name).

Using the Command Line for NDS Queries

The two primary command-line utilities for browsing the NDS tree are

1. CX (Change Context)

2. NLIST (Network List)

Used together, the CX and NLIST utilities provide a flexible and powerful mechanism for browsing and searching NDS object names and properties.

The CX Utility

The CX utility is used to change the current context. When used by itself, without any parameters and options, you can employ it to determine the current context. Thus, the command CX from the DOS prompt, as shown in the following example, indicates that the current context is set to O=ESL.

F> CX ESL F> CD F:\SYSTEM

The command in bold is the command a user types in, and the other text is the system's response. In the preceding commands, F> is the system (DOS) prompt; ESL and F:\SYSTEM are the results that appear after the respective executions of the CX and CD commands.

The CX command is very similar to the CD command, which enables the user to display or change the current directory for a file system. Keep in mind that the CX operates on the NDS directory, not on the file system directory. Changing the NDS directory context does not change the current file system directory. Therefore, in the previous example, the CX command reveals that the current context is O=ESL, and the CD command reveals that the current directory is F:\SYSTEM. Changing the current context does not affect the current directory setting, and changing the current directory does not affect the current context setting.

The commands that follow refer to the NDS tree in figure 13.1.

Figure 13.1 An NDS tree example for CX commands.

To change the current context to OU=CORP.O=ESL, you can issue the following command:

F> CX .OU=CORP.O=ESL CORP.ESL

Notice that the CX command always returns the current context; it acts as a quick check to see if the CX command works correctly.

In the preceding command, the complete name .OU=CORP.O=ESL was used. You also can use typeless names, because no Country object exists in the NDS tree. For instance, the command that follows has the same effect as the preceding command:

F> CX .CORP.ESL CORP.ESL

To go back one container level above, you can issue the following command:

F> CX . ESL

The period (.) following the CX command means that you want to change your context to the parent container. You can combine periods to go up several container levels, illustrated by the following example:

F> CX CORP.ESL F> CX .. [Root]

In the preceding example, the current container is OU=CORP.O=ESL. Using the command CX .., go two container levels up, which in this case is to the [Root] container.

What would happen if your current context is OU=CORP.O=ESL and you try to go three container levels up?

F> CX CORP.ESL F> CX ... CX-4.20-260: An internal system error occurred during CX's attempt to canonicalize the context: (...)

If an attempt is made to change the context to a location that does not exist in the NDS tree, an error message appears.

To change the context to the [Root], you can use the /R option:

F> CX /R [Root]

To view all container objects (tree structure) below your current context or specified context, you can use the /T option:

F> CX [Root] F> CX /T

Figure 13.2 shows the output of the CX /T command issued from the [Root].

You can combine the /R with other options such as /T. If /R is combined with /T, the CX /T command is issued from the root of the tree, but the context is not changed. You can type the following commands:

F> CX .CORP.ESL CORP.ESL F> CX /T /R F> CX CORP.ESL

The command CX /T /R produces the same output as in figure 13.2, but the context before and after executing the command remains the same (OU=CORP.O=ESL).

The /A (or /ALL) option enables you to view all objects at or below the current context. The /A option is meant to be used in conjunction with options like the /T option.

F> CX CORP.ESL F> CX /T /A

The command CX /T /A produces an output that is shown in figure 13.3.

You can combine the CX /T /A command with the /R option. For instance:

F> CX CORP.ESL F> CX /T /A /R F> CX CORP.ESL

CX /T /A /R shows all objects beginning from the [Root], but the context remains the same (OU=CORP.O=ESL) before and after executing the commands.

To view only container objects at a specified level, you can use the /CONT option, as follows:

F> CX CORP.ESL F> CX /CONT

Figure 13.2 The CX /T command from the [Root].

Figure 13.3 The CX /T /A command from the OU=CORP.O=ESL context.

You can combine the /CONT command with /A to see all objects within the container only:

F> CX CORP.ESL F> CX /CONT /A

Figure 13.4 shows the output of using the CX /CONT /A command in the current context OU=CORP.O=ESL.

Figure 13.4 The CX /CONT /A command from the OU=CORP.O=ESL context.

What is the difference between CX /CONT /A and CX /T /A ? Compare figure 13.6 with figure 13.5. CX /CONT /A displays all objects in the current context only, whereas CX /T /A displays all objects in the current context and in the containers below the current context.

Figure 13.5 NLIST /? P: Property Help screen for NLIST.

Figure 13.6 NLIST /? D: Display Options help screen for NLIST.

If CX /CONT /A is combined with the /R option, what output appears?

F> CX CORP.ESL F> CX /CONT /A /R F> CX CORP.ESL

Figure 13.7 shows the output produced by the CX /CONT /A /R command in the current context OU=CORP.O=ESL. Notice that the current context before and after executing this command does not change, even though the /R option displays the tree starting from the [Root] object.

Figure 13.7 The CX /CONT /A /R command issued from the OU=CORP.O=ESL context.

You can use the CX command with typeless and partial names. If the current context in figure 13.1 is O=ESL, for instance, the partial typeless name to change the context to OU=CORP.O=ESL is as follows:

F> CX ESL F> CX CORP CORP.ESL

If the current context is O=ESL, the partial typeless name to change the context to OU=SALES.OU=CORP.O=ESL is as follows:

F> CX ESL F> CX SALES.CORP SALES.CORP.ESL

If the current context is [Root], the partial typeless name to change context to O=SCS is as follows:

F> CX [Root] F> CX SCS SCS

If the current context is O=SCS, the partial typeless name to change context to O=ESL is as follows:

F> CX SCS F> CX ESL. ESL

The preceding example uses the trailing period rule to go one container above the current context.

If the current context is OU=CORP.O=SCS, the partial typeless name to change context to OU=SALES.OU=CORP.O=ESL is:

F> CX CORP.SCS F> CX SALES.CORP.ESL.. ESL

The previous example uses the trailing period rule to go two containers above the current context.

To view additional help on using the CX command, type the following command

CX /?

The screens in figure 13.8 show the two help screens that appear after you type the CX /? command. Table 13.1 also summarizes many common CX options.

Figure 13.8 The CX /? Help screens.

TABLE 13.1 Common CX Options

Command	Description
CX .	Change context to one container above current context
CX	Display current context
CX /R	Change context to root of NDS tree
CX /T	View all container objects below current or specified context
CX /T /A	View all objects in current context and below
CX /CONT	View container objects at current or specified context only
CX /CONT /A	View all objects at current context or specified context only
CX new_context	Changes context to specified context
CX /?	Obtain CX help screens

The NLIST Command

By using the NLIST command, you can view information on different object classes. The information appears in a convenient tabular form. NLIST is the fundamental command-line utility for extracting information on NDS objects. You can use NLIST to set up general purpose queries that search NDS objects based on a number of search criteria, including the following:

Property value
Existence of properties
Membership in a specific branch of the NDS tree

If you want to search for all the active users connected to the network, use the /A option, as in the following command:

F> NLIST USER /A Object Class: User Current context: ESL Conn = The server connection number * = The asterisk means this is your connection User Name = The login name of the user Address = The network address Node = The network node Login time = The time when the user logged in User Name Address Node *Admin [ E8022][ C024282D] One user object was found in this context. One user object was found.

The output of all NLIST commands produces a legend that describes the columns for the tabular information that is displayed.

An asterisk next to a connection means that the connection is your connection to the server. The output of NLIST * is equivalent to the USERLIST /A command in NetWare 3.x.

To see all user objects defined in the current context and subcontainers, use the /S option:

F> CX OU=CORP.O=ESL F> NLIST USER /S Object Class: User Current context: CORP.ESL User name= The name of the user Dis = Login disabled Log exp = The login expiration date, 0 if no expiration date Pwd = Yes if passwords are required Pwd exp = The password expiration date, 0 if no expiration date Uni = Yes if unique passwords are required Min = The minimum password length, 0 if no minimum User Name Dis Log Exp Pwd Pwd Exp Uni Min Dei No 0-00-00 No 0-00-00 No 0 Admin1 Yes 0-00-00 Yes 0-00-00 No 8 Admin2 No 9-01-99 No 0-00-00 No 5 A total of 3 USER objects was found in this context. Object Class: User Current context: SPOOL.CORP.ESL User Name Dis Log Exp Pwd Pwd Exp Uni Min USER_TEMPLATE No 0-00-00 No 0-00-00 No 0 One USER object was found in this context. Object Class: User Current context: SALES.CORP.ESL User Name Dis Log Exp Pwd Pwd Exp Uni Min USER_TEMPLATE No 0-00-00 No 0-00-00 No 0 One USER object was found in this context. Object Class: User Current context: OPS.CORP.ESL User Name Dis Log Exp Pwd Pwd Exp Uni Min USER_TEMPLATE No 0-00-00 No 0-00-00 No 0 One USER object was found in this context. A total of 6 USER objects was found.

As you can see from the last two NLIST commands, the output always begins with the Object Class specified in the NLIST command. The Current Context is listed next, followed by the information returned by NLIST for the current context.

The NLIST USER /S command was issued from the context OU=CORP.O=ESL. It lists all the users found in the context OU=CORP.O=ESL and all users defined in subcontainers below this context. A total of three user objects are defined in the context OU=CORP.O=ESL. User DEI is not disabled and has no login expiration dates. User Dei also does not have unique password or minimum password length restrictions. User Admin1, on the other hand, is disabled and has required password, unique password, and eight-character minimum password length restrictions. User Admin2 is not disabled, but the login account expires on 9-1-99, and although a unique password is not enforced for this user, the minimum password length is five characters. The subcontainers OU=SPOOL.OU=CORP.O=ESL, OU=SALES.OU=CORP.O=ESL and OU=OPS.OU=CORP.O=ESL are searched next. Each search reveals a user object with the name USER_TEMPLATE, which--like user DEI in the container above--has no restrictions. You can use the user USER_TEMPLATE in a container as a model for other users created within that container.

To see property details for a specific user, such as user DEI, use the following command:

F> NLIST USER=DEI /D Object Class: User Current context: CORP.ESL User: Dei Name: Dei Object Trustees (ACL):   Subject:      Dei  Property: [All Properties Rights] Property Rights: [ R ] Object Trustees (ACL):   Subject:      Dei  Property: Login Script Property Rights: [ RW ] Object Trustees (ACL):   Subject:      [Public]  Property: Default Server  Property Rights: [ R ] Object Trustees (ACL):   Subject:      [Root]  Property: Group Membership  Property Rights: [ R ] Object Trustees (ACL):   Subject:      Dei  Property: Print Job Configuration Property Rights: [ RW ] Object Trustees (ACL):   Subject:      [Root] Property: Network Address Property Rights: [ R ] Full Name: Dei Siyan Given Name: Dei Group Membership: Manager.SCS.. Home Directory:  Volume Name: NW4CS_SYS Path: USERS\Dei Name Space Type: DOS Middle Initial: G Language:  English Default Server: NW4CS Object Class: User Object Class: Organizational Person Object Class: Person Object Class: Top  Revision: 5 Security Equal To: Manager.SCS.. Last Name: Siyan Title: Finance Controller ------------------------------------------------------------------------------ One User object was found in this context. One User object was found.

The output of the NLIST USER=Dei /D command gives detailed information on the properties for that object. Some of the properties that are listed for the user are All Properties Rights, Login Script, Default Server, Group Membership, Printer Job Configuration, Network Address, Home Directory, Language, Full Name, Given Name, Middle Initial, Group Membership, Language, Title, and Last Name.

NOTE: Notice that in the NLIST USER=Dei /D command, the following lines appear at the end:
Object Class: User Object Class: Organizational Person Object Class: Person Object Class: Top
The preceding lines indicate the derivation hierarchy for user object Dei. The base class for user object Dei is User class. This is derived from the Organizational Person superclass, which is derived from the superclass Person, which is, in turn, derived from superclass Top.

The derivation principles used in NDS were discussed in Chapter 2.

To search for user KSS in the current container and all subcontainers:

F> CX SCS F> NLIST USER=KSS /S Object Class: User Current context: SCS User name= The name of the user Dis = Login disabled Log exp = The login expiration date, 0 if no expiration date Pwd = Yes if passwords are required Pwd exp = The password expiration date, 0 if no expiration date Uni = Yes if unique passwords are required Min = The minimum password length, 0 if no minimum User Name Dis Log Exp Pwd Pwd Exp Uni Min KSS No 0-00-00 No 0-00-00 No 0 One USER object was found in this context.

Object Class: User Current context: CORP.SCS User Name Dis Log Exp Pwd Pwd Exp Uni Min KSS No 0-00-00 No 0-00-00 No 0 One USER object was found in this context. Object Class: User Current context: ENG.SCS User Name Dis Log Exp Pwd Pwd Exp Uni Min KSS No 0-00-00 No 0-00-00 No 0 One USER object was found in this context.

The NLIST USER=KSS /S command finds all occurrences of user object KSS in current context and all subcontainers.

To see all printer objects within the current context and all subcontainers, use the following command:

F>CX SCS F> NLIST PRINTER /S Current context: SCS Partial Name Object Class

NP_0 Printer  One PRINTER object was found in this context. Current context: CORP.SCS Partial Name Object Class NP_0 Printer  One PRINTER object was found in this context. A total of 2 PRINTER objects was found.

To search for a specific property value for an object class such as the user object class, in the current context and all subcontainers:

F> CX SCS F> NLIST USER SHOW Telephone Number /S Object Class: User Current context: scs User: Manager1 Telephone: 310-434-3344 User: Manager2 Telephone: 310-444-4435 User: KSS Telephone: 415-333-4655 A total of 3 User objects was found in this context. Object Class: User Current context: ENG.scs User: AMY Telephone: 310-444-4354 One User object was found in this context. Object Class: User Current context: CORP.scs User: Linda Telephone: 510-233-3432 One User object was found in this context. A total of 5 User objects was found.

If the /S option is left out in the preceding command (NLIST USER SHOW "Telephone Number"), only the phone numbers for users in the current context of OU=CORP.O=SCS would be displayed.

To see a specific value for a specific object, use the following command:

F> CX CORP.ESL F> NLIST SERVER=NW4CS SHOW Network Address Object Class: Server Current context: CORP.ESL Server: NW4CS IPX/SPX Network Address Network: F0000055 Node: 1 Socket: 451 One SERVER object was found in this context. One SERVER object was found. F> CX .O=SCS SCS F> NLIST PRINTER=NP_0 SHOW Location /S Current context: SCS Printer: NP_0 Location: Building 6, Room 404 One PRINTER object was found in this context. Current context: CORP.SCS Printer: NP_0 Location: Engineering Lab Bldg, Printer Room 5 One PRINTER object was found in this context. A total of 2 PRINTER objects was found.

In the NLIST SERVER command, the network address of server NW4CS is queried. The network address that is reported is the internal software address of the server. The internal software address consists of the internal network number, the socket number, and the node number, which is always set to 1. The internal network number is selected during installation, and the socket number identifies the file service process that handles incoming requests. The NLIST PRINTER command shows the location of the printer object NP_0. The /S option helps find this printer object in the current context of O=SCS and all subcontainers. Without the /S option, only the printer object located at Building 6, Room 404 would be found. The printer object at location Engineering Lab Bldg, Printer Room 5 would not show up.

To search for all objects with a specific property value, use the WHERE option with the NLIST command.

F> CX SCS F> NLIST USER WHERE Title EQ ENGINEER Object Class: User Current context: SCS User name= The name of the user Dis = Login disabled Log exp = The login expiration date, 0 if no expiration date Pwd = Yes if passwords are required Pwd exp = The password expiration date, 0 if no expiration date Uni = Yes if unique passwords are required Min = The minimum password length, 0 if no minimum User Name Dis Log Exp Pwd Pwd Exp Uni Min

KSS No 0-00-00 No 0-00-00 No 0 One USER object was found in this context. One USER object was found.

F> NLIST USER=KSS SHOW TITLE Object Class: User Current context: SCS User: KSS Title: Engineer One USER object was found in this context. One USER object was found.

In the preceding commands, the quotes (") are placed around property names and values that have spaces around them; otherwise, the quotes are optional. Also, the EQ operator for comparison can be replaced by the equal symbol (=). This means that each of the following commands are equivalent and produce the same results.

NLIST USER WHERE "Title" EQ ENGINEER NLIST USER WHERE "Title" = ENGINEER NLIST USER WHERE "Title" = "ENGINEER" NLIST USER WHERE Title = "ENGINEER" NLIST USER WHERE Title = ENGINEER

The common NLIST options are summarized in table 13.2.

TABLE 13.2 Common NDS Options

Command	Description
NLIST USER /A	Display active users logged on to the network
NLIST VOLUME /S	Display all volumes in the current context and subcontainers
NLIST USER=Dei /D	Show detail property values for a user
NLIST USER=KSS /S	Search for a specific object in current context and all subcontainers
NLIST SERVER=FS1	Show a specific property for a SHOW "Network Address" specific user object
NLIST PRINTER WHERE	Search for objects that have a "LOCATION"=LABspecific property value
NLIST /?	Displays top-level help screen for NLIST

The help screens obtained from using the NLIST /? command are displayed in figures 13.9 through 13.11. Figure 13.9 is the top-level help, and the other figures are the specific help screens described in the top-level help. These help screens are shown here for your reference.

Figure 13.9 NLIST /?: Top-level help screen for NLIST.

Figure 13.10 NLIST /? B: Basic Options help screen for NLIST.

Figure 13.11 NLIST /? R: Property Search help screen for NLIST.

Using NetWare Administrator NDS Queries

You can generate NDS queries using a graphical user interface tool such as the NetWare Administrator Tool.

Start the Search option by performing the following steps:

1. Start the NetWare Administrator tool.

2. Highlight the container object from which the search is to be carried out. If you want to search the entire NDS tree, highlight the [Root] object.

3. Select the Object menu.

4. Select the Search... option from the Object menu.

After the previous steps, you will see a screen like that shown in figure 13.12. The Start From text box indicates the starting point of the search, and can be set to any container object in the NDS tree. The Browse icon, next to this value, can be used to browse for an appropriate container, as you can see in figure 13.13. The default is to search the entire subtree as indicated by the default check mark on the Search Entire Subtree check box.

Figure 13.12 The Search option in the NetWare Administrator tool.

Figure 13.13 The Select Object panel used for browsing to set the value of Start From in the Search option.

Several other object classes are listed in the Search For file. In addition to the standard object classes, you can use additional classifications to aid in finding the objects. These additional classifications are listed in table 13.3.

TABLE 13.3 Additional Object Classifications for Search Option

Object Classification	Description
Device	Includes all computer and printer objects
Locality	This classification is not used by NDS currently, but can be used by third-party products and tools
Organizational person	Lists all users
Partition	Used by the Partition Manager Tool to indicate containers that are on top of a separate partition
Person	Includes all users
Resource	Includes printer queue and volume objects
Server	Includes NetWare server, print server, and AFP server
Top	Includes every object in the container that is being searched

The Properties list box enables you to select from the different properties that you want to search for. The comparison operators include Equal, Not Equal To, Not Present, Present. You have a field for entering the actual property value you want to search for.

Figure 13.14 shows the results of searching all organizational unit objects in the container O=SCS and its subcontainers. This figure shows that three organizational unit objects are found:

OU=CORP.O=SCS OU=ENG.O=SCS OU=RESEARCH.OU=ENG.O=SCS

Figure 13.14 The Search results for all organizational unit objects in the O=SCS NDS database.

Using the NetWare Administrator Tool to Move Container Objects

The Partition Manager tool can be started from the Tools pull-down menu of NetWare Administrator. To move a container, you must first make it the root of a partition, otherwise Partition Manager displays a warning message.

When moving containers, be aware that the complete names (distinguished names) of the NDS objects in the container being moved do change. Therefore, you must perform the following actions:

Users logged in as user objects in the container being moved must log out and log back in again with the changed NDS distinguished names.
Change the "NAME CONTEXT=" statement in the NET.CFG file for the user's workstation to the changed context of the user object.

Time Synchronization Techniques

In the previous section, you learned that to provide fault tolerance and increase performance over slow wide area links, the NDS tree is partitioned and replicated. To keep the replicas properly updated, directory synchronization is used. This is done by a process called the skulk process that synchronizes the replicas with the updated information.

Any kind of global synchronization mechanism needs an accurate time reference that should be the same throughout the network. This ensures that the NDS operations are timestamped accurately, regardless of where performed on the network.

Accurate timestamps on NDS operations are essential to ensure that the NDS database is updated and synchronized correctly. A change made to a replica of a partition is propagated to all servers that are part of the replica ring. The timestamps are used for ordering the directory events. For instance, the changes to NDS operations are performed in the order in which their NDS modification requests are timestamped. If the timestamps on the modification requests do not have a common time reference, no guarantee can be made that the changes are made in the correct order. This could lead to all kinds of inconsistencies in the NDS database. The following is a partial list of server functions that need a consistent time standard across the network:

Messaging applications need to timestamp messages.
Operations performed on file systems need to apply a timestamp for changes that are made. Timestamps are recorded in the file system directory.
NDS needs timestamps to properly collate changes to the NDS database.

All servers need to have the same time, ideally matching the Universal Time Coordinated (UTC) time, but not essential for reliable NDS operations. To maintain the UTC time, an external time source is needed. The NetWare 4.x time synchronization mechanism enables the use of external time sources. UTC corrects local time and accounts for daylight savings time to give the equivalent GMT (Greenwich Mean Time). The following formula is used for calculating UTC: UTC = local time ± time zone offset - daylight savings offset The time zone offset parameters are set during NetWare 4 server installation (see Chapter 3).

The type of time synchronization that is used on the network is identified during NetWare 4.x server installation. Because servers could reside in different time zones, the time zone must be selected accurately, and the local Daylight Savings Time convention must be set correctly. For example, within the continental United States, certain areas do not use the Daylight Savings Time. The NetWare 4.x server is flexible enough to use whatever method is used locally. If necessary, even the Daylight Savings Time rules can be changed by programming them via SET commands on the NetWare 4.x server. All of the time synchronization parameters can be set using the server SET command, including the rate at which the time servers synchronize.

The time synchronization choices during installation are as follows:

1. Single reference time servers (SRTS)

2. Reference time servers (RTS)

3. Primary time servers (PTS)

4. Secondary time servers (STS)

The Single reference time server (SRTS) is the default choice during a first time installation. You can designate the first installed NetWare 4.x server as the SRTS. The single reference time server is the authoritative time source on the network. All other servers synchronize their time to match the SRTS. Although the SRTS can be made to work for all kinds of networks, it is primarily recommended for small networks. For larger networks, the SRTS acts as a single point of failure, and other mechanisms should be used. When SRTS is used, other types of time servers such as the primary time server (PTS) or the reference time server (RTS) cannot be used.

TIP: All servers on the network must be able to contact the SRTS because it is the only source of time.

Reference time servers (RTS) are used to provide an external time source. They are designed to be accurate and usually synchronize their time from a radio clock that is slaved to the Naval Observatory or some other equally accurate time source. Another way of designing the RTS is to use a time synchronization NLM that contacts an accurate time source via modem at regular intervals. An RTS can synchronize itself with an external time source, but it never adjusts its time from any other source on the network. For reliability, additional RTSs can be used. The additional RTSs should be strategically located at other points on the network. Because there could be differences in the time provided by the RTS, a voting method is used to decide the reference time for the network. All Reference Time servers participate in this vote. If any Primary Time servers exist, they too participate in the vote. The Primary Time servers adjust their time to match the consensus reached as a result of the vote.

TIP: Use an RTS when there is a need to have a central point to control accuracy of network time with respect to an external source.

TIP: For large networks where synchronization with an accurate external clock is needed, a backup RTS is recommended.

Primary time servers (PTS) synchronize their time by voting with at least one other PTS or RTS. In other words, a PTS must have another PTS or another RTS in order to synchronize its time. The network could have more than one PTS and RTS, in which case all the PTSs and RTSs participate in the vote. Unlike an RTS, a PTS adjusts its time to match the common network time (a result of the vote). The RTSs and PTSs poll each other to determine each other's time before casting their votes. While the PTSs are adjusting their clocks, the network time might drift slightly during the synchronization process. The other clients and servers take their time from the PTS. Having several PTSs on the network provides a measure of fault tolerance because, as one PTS goes down, another PTS can be used to provide an alternate time source.

TIP: Use one PTS for every 125 to 150 secondary time servers.

Secondary time servers (STS) synchronize their time from a PTS, RTS, or SRTS. Secondary time servers do not participate in the vote to obtain a common network time. If an SRTS is used, all other servers must be secondary time servers and must have a path to the SRTS. If an SRTS is not used, the STS can obtain its time via PTS or RTS. To minimize network traffic and time synchronization delays, the STS should contact the nearest PTS or RTS, with a minimum of router hops and network segments between an STS and its time source.

NOTE: Secondary time servers do not provide time. Single reference, primary and reference time servers provide time and are called time providers.

The different time server types and their chief characteristics are summarized here.

Server Type: SRTS
Time source: Yes

Gets time from hardware clock or external source

Adjusts clock: No

Gives time to STS and clients

Description: This is the default configuration. It cannot coexist with PTS and RTS. This is similar to the RTS with the difference that the SRTS claims to be always synchronized with the network time because it is the sole provider of the network time.

Server Type: PTS
Time source: Yes

Gets time from RTS. If there is no RTS, you must have at least one other PTS.

Adjusts clock: Yes. Implements 50 percent correction per polling.

Gives time to STS and clients.

Description: PTS polls other time sources and votes to determine correct network time, and compensates for clock errors. The synchronization status is set based on its deviation from the calculated network time and is independent of the status of other time sources that are polled. Server Type: RTS
Time source: Yes

Gets time from hardware clock or external source

Adjusts clock: No

Gives time to PTS, STS, and clients.

Description: Similar to PTS with the difference that it does not adjust its internal clock. It provides a central point of time for the entire network. RTS is assumed to be more reliable than PTS, and is therefore given a higher weight in computing common network time. You must have at least one PTS if you are using an RTS. Reliabilty of RTS time can be implemented using commerical products such as radio clocks and modems that communicate with external time sources such as atomic clocks. Server Type: STS
Time source: No

Gets time from SRTS, PTS, or RTS.

Adjusts clock: Yes. Implements 100 percent correction per polling interval.

Gives time to Clients only

Description: This is the default configuration if there exists an SRTS. STS does not participate in the voting process, and attempts to remain synchronized with only one time source.

Methods of Time Synchronization

In NetWare 4 networks, you can use two methods for communication time synchronization information:

Default configuration that uses SAP (Service Advertising Protocol) to transmit and receive time
Custom configuration

Default Method for Time Synchronization

During NetWare 4 server installation, the installation program assumes that there are only two types of time servers: STS and SRTS. This method is simple and does not require time synchronization when new servers are added to the network.

The default method for time synchronization uses SAP to advertise time sources (PTS, RTS, SRTS). PTS and RTS use SAP to communicate time synchronization information used for voting. Secondary time servers automatically learn where to get the network time from and require no additional configuration.

The default method is adequate for a small network with a small number of servers. Because SAP is used, the overhead introduced by time service is not significant for small networks. As the network grows in size and sites are connected through relatively low speed WAN links, however, the SAP overhead can become a substantial portion of the network traffic. If multiple sites separated by WAN links have a PTS or RTS at each site, SAP traffic carrying time synchronization information must go over the WAN links. If the WAN links are already closed to the maximum capacity, the additional burden placed by time synchronization traffic could affect other network services.

The advantages of the default method for time synchronization are as following:

Easy to configure. In fact there is no configuration file or configuration procedure. Use of SAP makes configuration automatic.
Easy to understand.
No additional planning is necessary.
Possibility of an error in synchronizing is reduced. There is no configuration error because manual configuration is not done. The time receiver, such as the STS, can only talk to other time sources such as the RTS, PTS and SRTS. An STS will not talk to another STS.

The disadvantages of the default method for time synchronization are as follows:

If SRTS is used, it represents a single point of failure. You can recover by manually making an STS an SRTS by changing the TIME SERVER TYPE parameter on the server using the SET command or the SERVMAN.NLM.
If manual errors are made in misconfiguring a time server type, for example, accidentally creating another SRTS--then the STS can synchronize incorrectly to the wrong SRTS.
Use of SAP can add additional network traffic.

Custom Configuration Method for Time Synchronization

Custom configuration involves determining which servers are time sources and deciding which servers will receive time from which time source, which means that custom configuration, unlike the default configuration, is not automatic and requires some planning.

Each time server maintains a configuration file (TIMESYNC.CFG) that contains a list of authorized time sources for the server and other time-related parameters. For the most part, you can copy the same configuration file to other servers and edit it to change the order in which time sources are to be contacted. The time source list should be ordered so that the closest time source appears first on the list; the least-cost (WAN speeds, communication costs) time sources should appear next in the order of increasing cost. Because the time sources that need to be contacted are listed explicitly, the custom configuration method cuts down on the amount of network traffic.

The following guidelines can be used for custom configuration:

STS can synchronize to the nearest PTS, RTS, or SRTS.
Keep the number of time sources as small as possible to reduce time synchronization traffic. Novell suggests using no more than five PTSs and RTSs.
Use time sources to provide local access throughout the network.
The time source list should be ordered so that the closest time source appears first on the list; the least-cost (WAN speeds, communication costs) time sources should appear next in the order of increasing cost.
If the STSs are known to be good timekeepers, increase their polling interval to an hour or more. This can be done by using the SET TIMESYNC POLLING INTERVAL command. The default value of this parameter is 600 seconds (10 minutes).

The advantages of the custom method for time synchronization are as follows:

You have control over the time synchronization hierarchy.
You can reduce network traffic by judiciously distributing time sources on the network.
You can provide alternate time sources, in case of network failure.

The disadvantages of the custom method for time synchronization are as follows:

Custom configuration requires a higher level of understanding and planning, especially for larger networks.
As new time sources are added, the configuration files on the servers need to be changed to be aware of the new time sources.

Implementing Time Synchronization

Time synchronization is implemented by the TIMESYNC NLM. It can be configured using a number of console SET parameters or by placing configuration parameters in the TIMESYNC.CFG file that is kept in the SYS:SYSTEM directory. The TIMESYNC.CFG file is a text file and can be edited using any text editor. Alternatively, SERVMAN can be used to make changes in the SET parameters and save these changes in the TIMESYNC.CFG file.

Making time synchronization changes in the TIMESYNC.CFG file rather than in the AUTOEXEC.NCF file or by using the SET commands at the server console is generally better. The TIMESYNC.CFG file is specially designed for time synchronization, whereas the AUTOEXEC.NCF file is used for general purpose server configuration. Also, TIMESYNC.CFG is processed earlier than AUTOEXEC.NCF. TIMESYNC.CFG is processed when the server boots up and TIMESYNC.NLM loads. TIMESYNC.NLM loads before the SYS: volume is mounted, after which AUTOEXEC.NCF is processed.

The following is a guideline for using SERVMAN to configure time synchronization parameters:

1. Load SERVMAN from the server console.

2. Select Server Parameters from Available Options.

You will see the "Set a parameter category" menu.

3. Select Time.

You will see the Time Parameters form, showing the parameters that affect time synchronization.

4. After making changes in the SET parameters, press Esc until you are shown the Update option menu. Select Update TIMESYNC.CFG now to save parameters in TIMESYNC.CFG file. Unless explicitly mentioned, the SET parameters in table 13.4 can be placed in the TIMESYNC.CFG file without the TIMESYNC keyword prefix. To save parameter settings to a selected file (called flushing to a file), select Copy all set parameters to a file.

TABLE 13.4 SET Time Synchronization Parameters

TIMESYNC Parameter	Description
TIMESYNC Directory Tree Mode = [On\|Off]	When set to ON, the time servers throughout the directory tree will only listen and vote with time servers in their own directory tree.
TIMESYNC Add Time Source = ts	This is used to specify the time source, ts, to be contacted for obtaining the time. The time source name, ts, can be up to 48 characters long. You can use this to build a list of time servers that your server will contact to obtain its time. Normally, SAP is used to obtain the common network time. If this parameter is set, your server will contact the time servers in the order specified until it obtains the time. Only if none of the specified time servers are available will the SAP method be used (unless disabled by TIMESYNC Configured Sources Default parameter). By default, this parameter is not set.
TIMESYNC Configuration File =pathname\filename	This parameter is used to specify the default path for the configuration file. The defaul value is SYS:SYSTEM\TIMESYNC.CFG. You can use an alternate path name. You cannot specify this parameter in the TIMESYNC.CFG or this parameter in the STARTUP.NCF file.
TIMESYNC Configured Sources = [ON \| OFF]	This parameter is used to control whether your server will use SAP to obtain the time source or a preconfigured list of time servers (set by TIMESYNC ADD Time Source parameter). The default value is OFF, which means SAP will be used. To use a preconfigured list of time servers, set the value to ON. If you set the value to ON, you must use the TIMESYNC ADD Time Source parameter to specify a list of time servers.
TIMESYNC Hardware Clock Default = [ON \| OFF]	This parameter is used to determine whether the NetWare server uses an external time source or reads its internal time clock. If this parameter is set to OFF, your server will contact an external time source (such as an atomic clock or radio clock) to obtain its time. The default is ON, which means that your server will read its internal clock. If this parameter is set to ON for Single or Reference time servers, these servers will read their clock. If this parameter is set to ON for Primary or Secondary time servers, these servers will set their clock base on the common network time.
TIMESYNC Polling Count = n	This parameter sets the number of time synchronization packets that will be exchanged during a polling cycle. The polling cycle is used for time synchronization. The default value is 3. Values can range from 1 to 1000. If you increase the value, the amount of synchronization traffic will increase. Novell recommends that you do not increase this setting (unless you have a very good reason).
TIMESYNC Polling Interval = t	This parameter sets the amount of time, in seconds, that will elapse between polling cycles. The default is 600 seconds (10 minutes) and the value can range from 10 to 2,678,400 seconds (31 days). If you decrease this time parameter, your servers will be more closely synchronized, but the network time will increase. If you want to decrease the network traffic due to polling cycles, increase this value. For slower WAN links, you might want to increase the polling interval.
TIMESYNC Remove Time Source = ts	This parameter is used to remove the specified time source from a list of configured time sources. It is primarily meant to be issued from the server console to make deletions in the list. This command is usually not added in the TIMESYNC.CFG or AUTOEXEC.NCF file.
TIMESYNC Reset = [ON \| OFF]	This parameter is used to reset the values changed by the TIMESYNC.CFG or SET TIMESYNC commands to their default values and remove the list of time sources. It does not alter the contents of the TIMESYNC.CFG or AUTOEXEC.NCF file. It only resets the current values of the parameters for the server. After the value is changed to ON, it executes the actions described, and resets to OFF. The default value is OFF.
TIMESYNC Restart Flag = [ON \| OFF]	This parameter is used to restart TIMESYNC.NLM with a new set of values from the TIMESYNC.CFG file without rebooting the server. After the value is changed to ON, it executes the actions described and resets to OFF. The default value is OFF.
TIMESYNC Service Advertising = [ON \| OFF]	This is used by time providers only and not time consumers (secondary time servers) to determine the method by which the time source should advertise. This parameter has no effect on secondary time servers.The default value is ON, which means that time providers use SAP broadcasts for advertising time. If you have set the TIMESYNC Configured Sources to ON, set the value of this parameter to OFF.
TIMESYNC Synchronization Radius = t	This parameter determines the error bounds for time synchronization. It determines how far apart the times on the servers can be before adjustment is necessary. If you set this parameter to a high value, you allow for a larger difference between times on servers. If the error margin is too large, it could reduce the integrity of NDS transactions being done in the correct sequence. If the radius is small, the servers will be more closely synchronized, but will generate greater synchronization traffic. If the radius is made too small, time synchronization will become difficult, if not impossible, to achieve. The value is measured in milliseconds and has a default of 2000 milliseconds. It can range from 0 to 2,147,483,647 milliseconds.
TIMESYNC Time Adjustment = [+ \| -] hh:mm:ss [[AT mm/dd/yy]]	This parameter can be used to manually adjust time on a Single Reference hh:mm:ss [AM \| PM]] \| [CANCEL]] or Primary time server. Use this command sparingly to correct network-wide time errors. Frequent use of this command can corrupt time synchronization on the network, and this will cause inconsistencies in the order of events performed on the network. The AT option can be used to schedule a time adjustment on the specified day mm/dd/yy and time hh:mm:ss. To cancel a previously scheduled time adjustment, use CANCEL instead of AT. The maximum length of the value is 99 characters. The default date and time is six polling intervals or one hour from now, which-ever is larger.
TIMESYNC Time Source = ts	This adds the name of the time source, ts, to the configured list of servers. When used without specifying a value, it displays a list of current time servers.
TIMESYNC Type = type	This is used to set the type of time server that is active on the file server. The type can have any of the following values: SINGLE, REFERENCE, PRIMARY, or SECONDARY. SINGLE refers to Single Reference Time Servers; REFERENCE refers to Reference Time Servers; PRIMARY refers to Primary Time Servers; SECONDARY refers to Secondary Time Servers. The default value is SECONDARY, except in the very first save in the tree; then the default is single.
TIMESYNC Write Parameters = [ON \| OFF]	When set to ON, this causes certain parameters (controlled by TIMESYNC Write Value parameter) to be written to the TIMESYNC.CFG file. The default is OFF.
TIMESYNC Write Value = n	The value of n controls the type of parameters that are written to the TIMESYNC.CFG file, if TIMESYNC Write Parameters is ON. If n is set to 1, only internal parameters from this file server are written to TIMESYNC.CFG.If n is set to 2, only external parameters from servers on the TIMESYNC TIME SOURCE list are written to TIMESYNC.CFG. If n is set to 3, both internal and external parameters from servers on the TIMESYNC TIME SOURCE list are written to TIMESYNC.CFG. The default value is 3.
Time Zone = sssNddd	This parameter determines the offset from UTC (Universal Coordinated Time). sss refers to the standard time zone. Examples are PST, MST, CST, and EST. These are three letter abbreviations for U.S. Pacific Standard Time, U.S. Mountain Standard Time, U.S. Central Standard Time, and U.S. Eastern Standard Time, respectively. N refers to the number of hours offset from UTC. U.S. Pacific Coast is 8 hours from UTC, and U.S. East Coast is 5 hours from UTC. The ddd indicates if daylight savings time is in effect. PDT = U.S. Pacific Daylight saving Time. MDT = U.S. Mountain Daylight saving Time. CDT = U.S. Central Daylight saving Time. EDT = U.S. Eastern Daylight saving Time.

Avoiding Time Synchronization Problems

If you use the server hardware clock for time synchronization, you must make sure that the hardware clock is reliable. Novell discourages the use of the hardware clock for applications that require synchronized timestamps.

If the time server's clock is set back (as it sometimes happens with bad hardware clocks and failing batteries for CMOS settings), other servers do not set their clocks back. The other servers advance their clocks at a slower pace, and the slower server advances its clock at a faster pace until the times converge.

If you accidentally reset server time to a future time, you risk serious corruption of the NDS database with incorrect timestamps. Try running DSREPAIR to repair the timestamps.

If the server is an SRTS or RTS, it assumes that its time is the correct time. If this time is incorrect, it can change the network time to its incorrect time value. If the server is not an SRTS or RTS, when it is started, it assumes that the network time is the correct time and adjusts its clock to the network time.

When the server is brought online, take the following steps to minimize time synchronization problems:

1. Before running SERVER.EXE, set the hardware clock (via DOS DATE and TIME commands) to correct local time. This might mean putting the time or date commands in the AUTOEXEC.NCF file that starts the SERVER.EXE. This has the unfortunate consequence of requiring manual intervention before the SERVER.EXE can be run.

2. When the server starts, check the server's time synchronization information using the console command TIME to ensure that the time zone and daylight savings time settings are correct. You can put the TIME command as the last command in the AUTOEXEC.NCF file.

3. Observe server time for a few minutes to see if there is any radical change in time. If the time changes by more than an hour, you might have incorrectly set the time parameters in the AUTOEXEC.NCF file. Take corrective actions immediately. Avoid having the server online for more than 20 minutes without fixing the server time or time synchronization parameters.

4. If you have had a history of time synchronization problems for objects in a container, avoid having network administrators for the same container in different time zones.

Building a Reference Time Server

You might consider building an inexpensive Reference Time Server using any of the following products. This list does not endorse any of these products, but rather, lets you investigate if it suits your needs and budget. Software: Cadence (NLM)

Hardware:	COM1:/COM2: Serial Port
Source:	NIST, NBS
Supplier:	C-Note Software, Inc / Polygon Software St Louis, MO USA
Telephone:	+1 314 432 4142
Fax:	+1 314 997 9696
Internet:	info@polygon.com

Provides NLM which can synchronize NetWare 3.x and 4.x servers to NIST and NBS time sources via dial-up modem. Software: Novelset (DOS)

Hardware:	TCR-200 AT Plug-in Card
Source:	SMPTE, EBU(25fps), IRIG-B(1)
Supplier:	Clark & Associates, Ltd. 318 E Calhoun Macomb, IL 61455 USA
Telephone:	+1 309 837 2244
Fax:	+1 309 833 5175
CompuServe:	75570,3030
Internet:	MUCDS@UXA.ECN.BGU.EDU

Provides hardware and software to synchronize Server time to external SMPTE (30fps), EBU(25fps) and IRIG-B(1) longitudinal time codes. Reads SMPTE drop frame. Software developed and tested on NetWare 3.11. Software: Atomic Network Time (DOS)

Hardware:	COM1:/COM2: Serial Port
Source:	NIST
Supplier:	CompuServe NOVUSER forum library (NTIME.ZIP)
Uploaded by 100141,2110

Workstation utility to synchronize multiple servers to the NIST time source via modem. Software: NET-TIME (DOS)

Hardware:	N/A
Source:	File server
Supplier:	CompuServe NOVUSER forum library (NETIME.ZIP)
Uploaded by 72300,503

DOS TSR programs to maintain time synchronization at all workstations in a NetWare LAN. Software: NetTime (Windows)

Hardware:	COM1:/COM2: serial port
Source:	?
Supplier:	CompuServe NOVUSER forum library (NETTIM.ZIP)

Windows program to dial atomic clock then set the time on every NetWare file server. Software: NovSync (DOS)

Hardware:	N/A
Source:	File server
Supplier:	CompuServe NOVUSER forum library (NVSYNC.ZIP)
Uploaded by 71333,427

DOS device driver that keeps the workstation clock in sync with the server. Software: Server to Station (DOS)

Hardware:	N/A
Source:	Workstation
Supplier:	CompuServe NOVUSER forum library (S2S100.ZIP)
Uploaded by 76516,1113

Utility that enables the user to synchronize any Netware 2.x or 3.x file server to the date/time of the workstation. Software: SYNC (NLM)

Hardware:	N/A
Source:	File server
Supplier:	CompuServe NOVUSER forum library (SYNC.ZIP)
Uploaded by 75730,1051

SYNC.NLM will check a time source server every minute and update the time of the local server. SYNC runs on NetWare 3.1x or 4.0x. Software: SYNCTIME (DOS)

Hardware:	N/A
Source:	Current default server
Supplier:	CompuServe NOVUSER forum library (SYNCTI.LZH)
Uploaded by 72302,3171

Workstation utility to synchronize all servers to the time of the current default server. Software: ServSet (DOS)

Hardware:	N/A
Source:	Workstation
Supplier:	CompuServe NOVUSER forum library (SERVST.ZIP)
Uploaded by 100117,213

Utility to set a NetWare file server's software clock to that of a PC workstation. Software: SERVTIME (DOS)

Hardware:	N/A
Source:	Workstation
Supplier:	CompuServe NOVUSER forum library (SERVET.ZIP)
Uploaded by 72007,1055

Utility to set a NetWare file server's software clock to that of a PC workstation. Software: DOS Device Driver (DOS)

Hardware:	DCF77 Clock
Source:	DCF77
Supplier:	Conrod Electronics PO Box 12, 7500 AA Enschede Netherlands
Telephone:	+31 53 282000
Fax:	+31 53 283075

Provides software and hardware in kit or ready-built form for DOS PCs to allow synchronization to the DCF77 Mainflingen clock. Software: Worldwide Time Server (DOS) TSERVE.ZIP in CompuServe NOVUSER forum library

Hardware: COM1:/COM2:
Source:	NRC (Canada)
Supplier:	Jiri Severa 101 Renfrew #3 Ottawa ON K1S1Z6 Canada
Internet:	jiri@ott.mmcl.ca
CompuServe:	70534,3457

Workstation-based software connects with the Ottawa NRC atomic clock via modem--then synchronizes time on Netware servers (up to 8 per installation). Software: Office-Logic Clerk (DOS/NLM)

Hardware:	None
Source:	NIST
Supplier:	LAN-ACES Inc.
Telephone:	+1 713 890 9787 (From US : 1 800 LANACES)
BBS:	+1 713 890 9790
EMail MHS:	SUPPORT @ LAN-ACES (via NHUB)

Provides time synchronization via dial up modem to NIST Time Server. Can synchronize current server time to all other local servers. Designed to run with Novell MHS/GMHS Email networks. Also, includes NSETTIME.EXE. Can be used together with others time synchronization packages to set the time on one or more file servers. Software: WanTimes (DOS)

WANTIM.ZIP in CompuServe NOVUSER forum library

Hardware:	COM1/2/3/4 Serial Port
Source:	NIST
Supplier:	Legal File Software USA
CompuServe:	71224,161 (Tom Ruby)

NetWare client software which dials NIST then sets the clocks of all File Servers to the time received. This software can be downloaded from the CompuServe NOVUSER forum as the file WANTIM.ZIP. Software: DOS Device Driver (DOS)

Hardware:	Rugby Clock Receiver Kit
Source:	MSF Rugby (UK)
Supplier:	Maplin Electronics PO Box 3, Rayleigh, Essex SS6 8LR UK
Telephone:	+44 1702 552911

Provides software and hardware in kit form for DOS PCs to allow synchronization to the MSF Rugby clock. Can be used with NSETTIME.EXE to allow setting of the server time. Software: Time Master and Time Master Plus (NLM, DOS, OS/2)

Hardware:	Contact MDI
Sources:	WWVB, DCF77, NIST, NRC, US Naval Observatory
Supplier:	MDI, 311 B Avenue, Suite A Lake Oswego Oregon 97034 USA
Telephone:	+1 503 635 6370
Fax:	+1 503 636 9501

Provides a Time Master (TM.NLM) and Time Slave (TS.NLM) which can be used to synchronize time on 2.x, 3.x and 4.x servers as well as device drivers for DOS and OS/2 workstations. Demo (TM.ZIP) in CompuServe NOVUSER forum library. Software: MK-NetClock (NLM,VAP)

Hardware:	External devices via COM1/COM2 and internal boards ISA/EISA/MCA
Source:	DCF77 Mainflingen, Germany
Supplier:	Mueller-Knoche GmbH Schleswiger Str. 1-5 D-90425 Nuernberg Germany
Telephone:	+49 (0)911 93488-0
FAX:	+49 (0)911 93488-35
MHS:	MK@MUEKNO (via CSERVE)

Provides NLM which can synchronize NetWare 2.15 (VAP),2.2, 3.x, and 4.x servers to DCF77 time source. Software: MK-TimeSync (NLM,VAP)

Hardware:	N/A
Source:	Server with MK-NETCLOCK or MK-NetClock-II
Supplier:	Mueller-Knoche GmbH Schleswiger Str. 1-5 D-90425 Nuernberg Germany
Telephone:	+49 (0)911 93488-0
FAX:	+49 (0)911 93488-35
MHS:	MK@MUEKNO (via CSERVE)

Provides NLM which can synchronize NetWare 2.15 (VAP), 3.x, and 4.x servers to time reference server running MK-NETCLOCK. Provides 4.x time synchronization mechanism to 3.x and 2.15 servers. Software: MK-NetClock-II (NLM)

Hardware:	Internal ISA board, external antenna
Source:	Global Positioning System GPS (Worldwide)
Supplier:	Mueller-Knoche GmbH Schleswiger Str. 1-5 D-90425 Nuernberg Germany
Telephone:	+49 (0)911 93488-0
FAX:	+49 (0)911 93488-35
MHS:	MK@MUEKNO (via CSERVE)

Provides NLM which can synchronize NetWare 3.x and 4.x servers to the GPS system as time source. Software: MK-DOSSync (DOS)

Hardware:	N/A
Source:	Server MK-NetClock or MK-NetClock-II
Supplier:	Mueller-Knoche GmbH Schleswiger Str. 1-5 D-90425 Nuernberg Germany
Telephone:	+49 (0)911 93488-0
FAX:	+49 (0)911 93488-35
MHS:	MK@MUEKNO (via CSERVE)

DOS device driver which keeps DOS and WINDOWS workstations in sync with servers with MK-NetClock or MK-NetClock-II. Announcement: (OS/2 workstation in beta, Windows NT in development). Software: RDATE.NLM (NLM) RDATE.ZIP in CompuServe NOVUSER forum library

Hardware:	None
Source:	Unix Time Server
Supplier:	MurkWorks PO Box 631 Potsdam, NY USA
Telephone:	+1 315 265 4717
Fax:	+1 315 268 9812
Internet:	info@MurkWorks.com
FTP:	ftp.msen.com:pub/vendor/murkworks

Provides NLM which synchronizes with a Unix time source using Unix rdate protocol over TCP/IP. Software: TimeBase/NLM (DOS/Windows/NLM)

Hardware:	TimeBase
Source:	MSF Rugby (UK)
Supplier:	NetConnect Limited Cambridge UK
Telephone:	+44 1223 423523 (International)
Telephone:	01223 423523 (UK)
EMail MHS:	SBACON@NETCON (via NHUB)

Provides external hardware clock plus DOS, Windows, and NLM driver to allow synchronization of all servers from the MSF Rugby source. Software: RTCTOOLS.NLM (NLM)

Hardware:	CTS-10 Card
Source:	WWV (10MHz)
Supplier:	Odetics, Inc via Personal Computer Tools 90 Industrial Park RD Hingham, MA 02043 USA
Telephone:	+1 800 767 6728
Fax:	+1 617 740 2728

Provides hardware card, antenna, and RTCTOOLS.NLM software for receiving WWV broadcast. Software: ProTime (NLM)

Hardware:	Contact Protocom
Source:	Telecom Australia
Supplier:	Protocom Development Systems Pty Ltd
Telephone:	+61 15 335190
Fax:	+61 35 780144

Provides NLM for NetWare 3.x and 4.x servers to synchronize to Telecom Australia digital time source. Software: RDATE2 (NLM)

Hardware:	N/A
Source:	Unix Time Server
Supplier:	Richard Letts University of Salford UK
FTP:	ftp.salford.ac.uk:network/nlms/rdate.zip

Provides NLM to synchronize with Unix Time Server using the Unix rdate protocol. Includes source code. Software: Time:LAN! (DOS/NLM)

Hardware:	External clock receiver
Source:	DCF77
Supplier:	Tobit Software Gmbh D-48664 Ahaus Germany
Telephone:	+49 2561 913190 (From US : 1 800 GOTOBIT)
Fax:	+49 2561 913191 (From US : 1 800 FAXWARE)
EMail MHS:	HELLO@TOBIT (via CSERVE)
Internet:	HELLO@TOBIT.mhs.compuserve.com

Provides hardware and software to allow synchronization of client and/or server to DCF77 time source. Software: WMODEM.NLM (NLM)

Hardware:	COM1: or External receiver
Source:	Westerstrand's time base, DCF77, MSF Rugby (UK)
Supplier:	Westerstrand Urfabrik AB Box 133 S-545 23 Toereboda Sweden
Telephone:	+46 506 71600
Fax:	+46 506 16169
CompuServe:	73671,772 (Mats Sunesson)

Provides time synchronization via dial up modem to Westerstrand's time base or from master clock connected to serial port on server.

Detecting NDS Problems

NDS is a global distributed database. If a portion of the database (replica) is corrupted, you should be able to detect this problem and correct it. As with any distributed database, a number of problems can arise in connection with NDS. These problems and their solutions are discussed in this section.

The following types of problems can arise with NDS:

Inconsistencies in the NDS database
Unsynchronized replicas
Problems with synchronization when servers are down

Inconsistencies in the NDS Database

NDS is a distributed, global, replicated database that is "loosely consistent." The loose consistency property of the NDS database implies that it is possible for the replicas to be out of synchronization for short periods of time because synchronization might take a few seconds. NDS operations can tolerate a few seconds of inconsistency while the replicas are being synchronized. This does not imply that the NDS database has a problem because it is inconsistent during the synchronization process.

Understanding Time to Synchronize

Knowing the amount of time required for a change in a replica to be propagated to other servers in the replica ring is useful. Remember that the replica ring is the set of servers that have replicas of the partition. The synchronization time depends on the nature of the change being performed, the partition size, and the number of servers in the replica ring.

The nature of the change to the NDS database can be simple or complex. Simple changes are those that affect only a single NDS object, such as changing the Fax number property of a user object. Simple changes are performed relatively quickly on the replica, and then the replica changes are synchronized to only those servers that contain the replicas of that partition (that is, the replica ring). Another example of a simple change is creating a partition, which takes very little time. The NDS adds partition attributes describing the subtree that is now a new partition.

Complex changes take more time, and require more careful planning. Merging and splitting partitions are examples of more complex changes. If partitions are to be merged, the following tasks are performed by the NDS:

1. NDS locates the servers that contain the replicas of the partition.

2. NDS forces the servers that have a replica of a partition to be joined to have a copy of the replica of both partitions that are to be merged.

3. After the partition merger is completed, the servers have the combined information of both partitions.

NDS Fault Tolerance

In case of serious inconsistency problems with the NDS database, having replicas of the partitions is useful. For redundancy purposes, you might want to have two to three replicas of a partition. Novell documentation recommends three replicas per partition. As the number of replicas increases, however, so does the amount of synchronization time. Make sure that the replicas are both on-site (local to your network) and off-site (on a remote network) as part of your NDS design, to ensure that at least one replica is preserved in case of major catastrophes (floods, earth quakes, and so on).

Treat backing up of the NDS database the same way as backing up other critical resources, such as files and directories. Implement a schedule for backing up the NDS database on a daily, weekly, or monthly basis. You can restore the Directory from the backup, if other means of restoring the NDS database fail. For example, if a merge or split operation fails because of a power failure or other interruption, the master replica could become corrupted and propagate errors to other replicas. The first recovery option would be to see if there is an unaffected read/write replica of the partition, and make it the master partition. If such a replica does not exist, the second recovery option would be to restore the Directory from the latest backup.

During partition operations such as a merge, split, or move, the affected partitions are locked. This prevents simultaneous partitions on these operations from being performed. Novell recommends that you perform partition operations from only one station at a time to enable you to help track the partition operations.

NDS database and the SYS: volume

The NDS database is stored on the SYS: volume, and to maintain the consistency of this database, NetWare uses the Transaction Tracking System (TTS) feature, which is automatically enabled for a volume when the volume is mounted. TTS is used in NetWare to ensure that critical system files are restored to a consistent state on failure within the server. If the TTS is disabled or shutdown, interrupted changes to the NDS database could lead to a corrupted NDS database. The TTS is disabled if the volume becomes full, so you should monitor the storage space on the SYS: volume and prevent this volume from becoming full. The following are guidelines for preventing the volume from becoming full:

Set minimum space requirements so that you receive a warning if the SYS: volume is running out of space.
Store print queues on other volumes besides the SYS: volume.
Store applications and data that are likely to grow in size on other volumes besides the SYS: volume.
Do not add replicas to servers that are low on space in the SYS: volume.
Do not use extended schemas if the space on the SYS: volume is low. Extended schemas allow the creation of new types of NDS objects and additional properties for existing objects.
Use the following statement in the STARTUP.NCF file to back out any incomplete transactions in the database:
SET AUTO TTS BACKOUT FLAG=ON

By default, this parameter value is ON.

NOTE: The NDS database is kept in a hidden directory called SYS:_NETWARE. This directory cannot be viewed using NCP requests, so you cannot see it using workstation commands. However, you can view this directory using the "Directory Scan" option from the Available Options of an RCONSOLE session to the server. You can see the RCONSOLE Available Options by pressing the ALT+F1 key during an RCONSOLE session. You can use the listing of files that are displayed (see fig. 13.15) to find out how much space is being used by the NDS database by adding up the bytes of the files that are displayed.

NOTE: If TTS is disabled on a server that contains active replicas, the replicas can become corrupted. TTS can become disabled if the SYS: volume becomes full.

Figure 13.15 NDS database hidden files in SYS:_PARTITION.

Unsynchronized Replicas

Because the NDS databases have loose consistency, the replicas might not be synchronized during synchronization--that's normal. If problems in NDS operations persist, however, you can conclude that you have synchronization problems. The symptoms of nonsynchronization can appear at the client or the server.

At the client, any of the following symptoms could indicate problems with replica synchronization:

NDS object modifications made to the directory seem to disappear unexpectedly.
Changes made to NDS rights seem to disappear unexpectedly.
Errors at clients cannot be duplicated.
Client performance is inconsistent.
Clients prompt for passwords when none have been assigned.

At the server, you can detect synchronization occurrences by turning the DS trace screen ON using the following server console command:

SET DSTRACE = ON

The DS trace screen shows the replica synchronization operations (see fig. 13.16). The messages are of the following type:

SYNC: Start sync of partition name state: xx type: yy  SYNC: End sync of partition name. All processed = Yes/No

Figure 13.16 DS trace screen.

In the previous message, name is the name of the partition, and YesNo can be either YES or NO. If you see NO for more than 20 minutes, this indicates a synchronization problem, and you should take corrective action.

Novell recommends the following actions when server synchronization problems are detected:

1. Let the systems run for a few hours. The replicas might resynchronize and correct the problem. Bringing the servers down could prevent this self- correction.

2. Run DSREPAIR.

If you see several Unknown NDS objects in the NDS tree, it can indicate synchronization or other NDS problems. Unknown objects also can appear during partition operations (merge, split, create, move) when the system is in a state of flux.

Problems with Synchronization When Servers Are Down

If servers that are part of a replica ring are down, they cannot receive replica synchronization information and consequently are out of synchronization. Servers can be down because of planned maintenance or due to failure.

The NDS database was designed to take into account periods when the servers that hold replicas are not available. When the servers are brought online, the replicas on them automatically resynchronize and become available.

During the period of time a server is unavailable, the servers that send updates to the unavailable server use a backoff algorithm that tells them not to send changes to the unavailable server. The disconnected server periodically requests updates when no changes have been received for a period of time. The downed server uses the last time it received an update and other information to detect that it is out of synchronization when it comes back online, and requests an update.

Planned Shutdown of Server

If you plan to bring down a server that contains the only replica of a partition, move that partition to another server or create a replica of the partition.

Table 13.5 provides guidelines on how to manage a planned shutdown of servers.

TABLE 13.5 Planned Server Shutdown

Server Shutdown Event	Planned Action
Make the server inaccessible permanently.	Back up NDS and remove NDS from the server.
Replacement of the hard disk that contains the SYS: partition.	Back up NDS and remove NDS from the server. Restore replicas on the server when the server is online again.
Bring down a server temporarily for partition changes, relocation of server to another site, large number of changes/additions/deletions of replicas.	Remove replicas from the server before bringing down the servers.

Unplanned Shutdown of Server--Server Failure

If a server that contains replicas fails unexpectedly, it could result in directory loss unless the replicas on the server exist on other servers that are still accessible.

If a server fails, use the Partition Manager tools to remove the server from the directory tree. The explicit deletion of the server informs other servers in the replica ring that the failed server is no longer part of the replica ring and that they should not attempt to update the failed server's replicas. When a server fails, the backoff algorithm causes the server to send updates less frequently. However, the servers in the replica still continue to contact the failed server unless the server is deleted or comes back online. The failure to contact manifests as server console messages of the type Unable to contact server XXXXX.

Troubleshooting NDS Problems

This section discusses procedures for the following tasks:

Determining synchronization status of a partition
Restoring system software after NDS or SYS: volume failure
Removing the NetWare server object from the NDS tree
Updating corrupted replicas

Determining Synchronization Status of a Partition

Before attempting any NDS operation, check the synchronization status of a partition to avoid potential problems and misunderstandings in your troubleshooting endeavors. You can use the DSREPAIR NLM to determine the synchronization status of a partition. The following list outlines the procedure:

1. Run the DSREPAIR NLM:

LOAD DSREPAIR

2. Select "Replica Synchronization."

3. Authenticate yourself by entering the complete name of the Admin user and the password.

4. Check the DSREPAIR log file for the status of the server (see fig. 13.17).

Restoring System Software after NDS or SYS: Volume Failure

If the SYS: volume, which contains the hidden files that implement the NDS database, fails because of a disk crash or other problems, you must reinstall NDS. Because the disk file contains other system-critical files, you might need to reinstall the server software.

Figure 13.17 DSREPAIR log file.

If the SYS: volume also contains the master replica of a partition, you have to take additional steps to recover the master replica. For example, you can upgrade another replica of the partition to a master replica using DSREPAIR or the Partition Manager. The master replica is needed for making partition changes. You can still perform other administration functions using read/write replicas.

Novell recommends the following general outline to restore replicas after recovering the SYS: volume.

1. Record the status of the replicas in each replica ring for a given partition. Note which server, if any, has the master replica.

2. Delete the failed server and its associated volume objects.

3. Resolve NDS errors and remove replica pointers to non-existent replicas.

4. Reinstall the hard drive on the server.

5. Place replicas back on the server.

6. Restore the file system data from backup.

7. Set the correct bindery context.

Recording the Replica Status

You can use the following steps for recording the status of replicas:

1. Use the Partition Manager and select server objects. Note the replicas on each server.

2. If a replica on the failed server shows a master status, you must designate a new master replica that is on an up-and-running server, and has a properly synchronized read/write replica.

You can do this using DSREPAIR, as outlined in the following steps:

3. Run DSREPAIR
LOAD DSREPAIR

4. Select "Advanced options menu." You will see the screen in figure 13.18.

Figure 13.18 DSREPAIR Advanced Options menu.

5. Select "Replica and partition operations." You see a list of replicas.

6. Highlight a read/write partition and press Enter.

7. Select "Designate this server as the new master replica" (see fig. 13.19).

Figure 13.19 Replica Options menu.

8. Exit DSREPAIR.

Deleting the NetWare Server and Volume Objects

Servers need to be deleted using the Partition Manager, because the servers contain replica and other partition information. Make partition changes when all servers in the replica ring that are expected to be up are reachable.

You can use the following steps for deleting the NetWare server and volumes:

1. Run NetWare Administrator on a NetWare workstation.

2. From the Tools menu, select Partition Manager.

3. Navigate the directory tree to find the server object you want to delete.

4. Select the server to be deleted, and select "Delete Server." After a server object is deleted, this change is synchronized to the other replicas.

5. Use NetWare Administrator or NETADMIN to delete the volume objects for the deleted server.

Resolving NDS Errors

Use the following as a guideline for resolving NDS errors and removing replica pointers.

1. Run DSREPAIR at the server console:
LOAD DSREPAIR

2. Select "Replica Synchronization" to see all partitions that existed on the deleted server.

You see the "Collecting replica synchronization status" screen (see fig. 13.20) and then the DSREPAIR log.

3. If you see error messages with code 625 (also called 625 errors), perform the following steps on all servers containing the replica in question until the errors disappear.

a. From the DSREPAIR Available Options menu, select the Advanced Options menu (see fig. 13.18).

b. Select "Replica and partition operations." You see a list of replicas.

c. Highlight the partition that has the errors and press Enter.

Figure 13.20 Collecting replica synchronization status screen.

d. Select "View replica ring." You see a list of servers that have a replica of the partition.

e. From the list of servers in the replica ring, highlight the server that has been deleted, and press enter. You see the Replica Ring Options menu (see fig. 13.21).

Figure 13.21 Replica Ring Options menu.

f. Select "Remove this server from the replica ring," and answer Yes to verify operation.

g. Exit DSREPAIR.

Reinstalling the Hard Drive on the Server

To install the hard drive on the server, use the procedures recommended by the hardware vendor and appropriate for the hard disk. This might be a good time to replace your old drive with a "higher capacity" drive you have been planning for some time.

Use the INSTALL NLM to reinstall the system software. Chapter 3 covered the installation procedure. Install the NetWare server object in the original context.

Place Replicas Back on the Server

You can use the Partition Manager and the replicas you documented for the server to place the replicas back on the restored server.

The amount of time it takes to perform this operation depends on the size of the network and the speed of the LAN and WAN links.

Restore File System Data from Backup

Restore any other applications on the SYS: volume from backup media. This restore operation backs up both data and ownership and trustee information for files and directories. Check to see if ownership and trustee information is restored properly. In the worst case, you must establish ownership and trustee information manually.

Set the Correct Bindery Context

The bindery context is important for bindery-based clients. The default value of the bindery context is the same as the server context. If the bindery-based clients require other containers to be part of the bindery context, add these additional containers to the SET BINDERY CONTEXT command in the AUTOEXEC.NCF file.

Updating Corrupted Replicas

You can send updates from a master replica to update other replicas. This procedure updates all other replicas regardless of the accuracy of timestamps. You must, therefore, ensure that the master replica has the correct timestamps. Depending on the size of the replica and your network topology, this procedure can cause excessive network traffic.

You can use the following procedure with the Partition Manager to send updates:

1. Run Partition Manager from the Tools menu of NetWare Administrator.

2. Highlight the partition, and select the Replicas button (see fig. 13.22).

Figure 13.22 Viewing a specific partition using Partition Manager.

3. Select the master replica (see fig. 13.23).

Figure 13.23 Using a master replica to send updates using Partition Manager.

4. Select the Send Updates button and confirm the operation.

This chapter described some of the tools and techniques you'll need to manage your NDS tree. You learned about the following topics:

Setting NDS context at the workstation
Using the command line for NDS queries
Using NetWare Administrator for NDS queries
Using NetWare Administrator to move container objects
Implementing time synchronization
Detecting and troubleshooting NDS problems

In the following chapters, you'll learn more about network administration under NetWare 4. The next chapter discusses server management.

Migrating to Netware 4.1 -- Ch 13 -- Managing NDS