Managing a NetWare Server

In the preceding sections, you saw how NoRM permits you to manage most any aspect of a NetWare 6.5 server from any workstation with browser access to the network, even over the Internet! The following sections review several of the other types of day-to-day server-management tasks you need to perform on a NetWare 6.5 network.

Protecting the Server

Protecting the server is a very important safeguard that cannot be overlooked. Damage to the server can affect the entire network. The activities covered in the following sections can help you protect your server.

Physical Damage

If the server is in an exposed public area where anyone can have access to it, accidents can, and will, happen. For example, someone might unplug the power cord or turn off the server, thinking it had been left on accidentally . For this reason, all file servers should be stored in a locked room. NetWare 6.5 makes this much easier with its comprehensive remote-management tools. Because of this, you should strongly consider removing keyboards and monitors from the servers. This eliminates a major access point for mischief and mistakes.

Today, it is fairly common to purchase customized rack-mountable hardware for your server. This way, many servers can be located in a fairly limited area, with isolated and protected power sources and climate control to keep everything cool. When possible, this type of configuration further limits physical problems that might affect your network.

Electrical Power Problems

If you have been around computers for any period of time, you know the chaos that can be caused by a sudden loss of electrical power. A Uninterruptible Power Supply (UPS) helps mitigate this risk by providing a battery-based power backup for your server. When power is lost, the UPS seamlessly takes over and provides power for a time sufficient to allow you to close things down gracefully.

Several UPS manufacturers provide NetWare-compatible software for their products. However, if your UPS does not come with NetWare software, you can try UPS_AIO.NLM, which allows NetWare to communicate with a UPS attached to a serial port on the server. Complete the following steps to use UPS_AIO.NLM to link your UPS to your NetWare 6.5 server using a serial port:

1. Attach the UPS to the server using the manufacturer's instructions.

2. Load the UPS hardware driver on the server.

3. Load an AIO device driver on the server. AIOCOMX.NLM is the default driver that comes with NetWare.

4. Load UPS_AIO.NLM on the server, specifying the correct options in the UPS_AIO options format (see Table 4.2).

TIP

If you want the UPS to be configured the same way every time the server is rebooted, put the LOAD UPS_AIO. NLM in the server's AUTOEXEC.NCF file. Be sure to include the appropriate options (see Table 4.2).

Table 4.2. UPS_AIO Options

OPTION	DESCRIPTION
Downtime = value	The time, in seconds, that the server will run on battery power before shutting down. Default: 300. Value: Minimum 30 seconds (no maximum).
MSGDelay = value	The time, in seconds, before the system sends a message to users about the approaching shutdown. Default: 5. Value: Minimum 0 (no maximum).
MSGInterval = value	The time, in seconds, between broadcasts. Default: 30. Value: Minimum 20 (no maximum).
DriverType = value	The AIO device driver type. See the manufacturer's documentation for the type. Default: 1 (AIOCOMX). Value: 1, 2, or 3.
Board = value	The AIO board number. If you use AIOCOMX, the board number is displayed when you load AIOCOMX. If you use another driver, see the manufacturer's documentation for the number. Default: 0.
Port = value	AIO port number. If you use AIOCOMX, the port number is displayed when you load AIOCOMX. If you use another driver, see the manufacturer's documentation for the number. Default: 0.
Signal_High	Sets normal RS232 signaling state to High. Use the High setting only if your system uses high values instead of low values to determine whether the power is low. See the manufacturer's documentation for more information. Default: none.

Once configured as noted here, your UPS can communicate with your NetWare 6.5 server through the server's serial port.

Disk Failures

To help isolate your users from the effects of hard disk problems, the NetWare 6.5 offers several powerful storage options, including disk mirroring and duplexing , software RAID support, Storage Area Network (SAN) support with NetWare Cluster Services, and iSCSI. NetWare storage options are discussed in more detail in Chapter 8, "File Storage and Management."

Viruses

Unfortunately, software viruses are a fact of life. Fortunately, the specialized nature of the NetWare architecture has made it resistant to virus infection at the operating system level. However, that doesn't mean that a NetWare server can't host a virus and play a part in its propagation around your network.

The best way to fight the continually shifting assault of viruses is to use a third-party virus-scanning solution to detect and clean network files if they become infected. This solution should also support automatic scanning of Web-based files and email to create a more robust protective barrier .

Because of the rate at which new viruses are being created, keep your virus solution current with both software updates and virus pattern files. Virus scanning won't do much good if it is incapable of detecting the virus that hits your system.

NetWare does offer some protection against viruses infecting executable files through the use of the Execute Only file attribute. You can also remove the Modify right from the directory that contains the executable files and make executable files Read-Only. This will prevent viruses from modifying a file in order to attach themselves to it. For more information on NetWare file system rights, see Chapter 8.

CD-ROMs

With NetWare, a server-mounted CD-ROM can appear as any other NetWare NSS volume. Users on the network can access the CD-ROM just like any other volume, except that it is read-only. For more information on NSS, see Chapter 8.

NetWare uses CDROM.NLM to mount CD-ROMs as NetWare volumes . It supports High Sierra, ISO 9660, and HFS (Apple) extensions for Macintosh clients that might be out there, and the appropriate support module will be auto-loaded with CDROM.NLM (for example, CD9660.NSS). CDROM.NLM is loaded automatically when the server starts. When you insert a CD-ROM into the CD-ROM drive, NetWare will automatically detect and load the drive as a new NetWare volume.

Once loaded, you can use the Volumes page in NoRM to view the CD-ROM volume; it's listed as an active volume on the server. You can dismount and mount the CD-ROM just like any other volume on the server.

NOTE

All the manual CDROM load commands that you might remember from previous versions of NetWare, particularly NetWare 5.1 and prior, are no longer available, or necessary, in NetWare 6.5.

Controlling NLMs

Because NLMs load as part of the operating system, it is possible for a misbehaving NLM to cause problems in a server's memory. It could corrupt its own memory space or overwrite memory being used by another process, causing a server ABEND , or Abnormal END. An ABEND is a serious error from which the server cannot always recover without your help.

NLMs from Novell should not require that you load them in protected address spaces, but NLMs that execute external applications, including the NetWare JVM, load in protected memory automatically to protect the server from those external applications. If you have an NLM that you don't trust, it is possible to test it in NetWare's protected address space .

You can load an NLM into a protected address space from NoRM by doing the following:

1. Select the Protected Memory link under Manage Applications in NoRM. This screen also gives you a view of applications operating in protected memory and settings for memory protection SET parameters.

2. Select one of the following options:

   • Load NCF file protected: Many third-party applications will create an NCF script to load the necessary modules. Use this option to make sure all modules loaded from the specified NCF file are loaded into protected memory.

   • Load module protected: Use this option to load a single NLM into protected memory.

3. Enter the full name , including path , of the module or NCF file that you want to load in the appropriate field, and then select the corresponding button.

Once loaded in this fashion, the NetWare kernel will be protected from any misbehavior of the module loaded into protected memory space.

Monitoring and Optimizing Server Performance

When you monitor the server's performance, you look for key indicators that the server is functioning at an optimal level. Some of the things you should monitor include the utilization percentage of the server's processor, the number of cache buffers and packet receive buffers being regularly used, and the server's memory allocation.

Every network has different needs and usage patterns. By default, server parameters are set so that the server will perform well on most networks. In addition, the server is self-tuning , meaning that it will gradually adjust itself over time to accommodate changing usage patterns. However, you should be aware of what constitutes "normal" for your server(s). That way, you can effectively plan for future network and server needs as well as notice any unusual changes that might indicate a potential problem.

The best way to do this is to regularly review NoRM's Health Monitor (see Figure 4.5). Health Monitor is broken down into major groupings of server health. Selecting a link in Health Monitor takes you to more specific information about the current state of the server with regard to that category.

Figure 4.5. Health Monitor in NoRM.

Health Monitor also allows you to set thresholds for server performance that can generate automated alerts to the administrative staff when these thresholds are passed.

Server parameters, also called SET parameters, control the NetWare 6.5 server environment. They allow you to set Maximum, Minimum, and Threshold levels for many aspects of the server's internal operations. Appendix C contains a comprehensive list of NetWare 6.5 SET parameters, and more information on configuring thresholds and alerts.

You can use NoRM to adjust SET parameters by selecting the Set Parameters link, as shown in Figure 4.6. This can also be done from the server console with MONITOR.NLM. SET parameters come in two types: persistent and non-persistent. Persistent SET parameters maintain their state even if the server is shut down. Non-persistent SET parameters reset to their default value when the server restarts. You place non-persistent SET parameters in your AUTOEXEC.NCF and/or STARTUP.NCF, so they are set automatically to the desired value whenever the server starts.

Figure 4.6. NetWare 6.5 SET parameters in NoRM.

After NetWare 6.5 is first installed, it will optimize itself over a period of time by leveling adjustments for low-usage times with peak-usage bursts.

Over a week or two, the server will settle on an optimal setting for each SET parameter. However, if you already know where the server should be set, or if you are not satisfied with the server's self- tuned settings, you can configure any SET parameter manually.

The following sections describe some of the ways to monitor and optimize your server's performance.

Cache Memory

Running out of cache memory is one of the biggest causes of poor server performance in a NetWare environment. Prior to NetWare 6.5 there were a number of cache parameters related to directory, open files applications, and the like. One of the major changes between NetWare 5 and NetWare 6.5 is the use of the NSS file system as the default file system for NetWare 6.5 and the SYS volume. With NSS, you get a completely redesigned caching system that eliminates most of the cache monitoring with which you may be familiar.

NSS introduces a much simplified caching system with only two cache pools to worry about: the OS pool and the NSS pool. The OS pool, as its name implies, is used to supply the memory needs of all OS-related processes, including packet receive buffers. The NSS pool is used for everything else, including directory, files, server applications, and so on.

When NetWare 6.5 is installed, the total available cache memory is balanced between the OS and NSS cache pools. The default balance is 60% NSS pool and 40% OS pool. You can change this setting from NoRM by selecting Set Parameters >> Novell Storage Services >> NSS Cache Balance Percent. The NSS system will automatically re-allocate memory between the two pools to keep them functioning at an optimal level.

You can review the current server statistics related to cache memory through the following links in NoRM's Health Monitor. If you are familiar with it, you can also set these values using MONITOR.NLM from the server console:

• Cache performance: Provides both a textual and graphic overview of memory allocation on the server to which you are attached through NoRM. Also provides links to specific memory allocations within the general pools. The Available Memory link brings you to this same page.

• Available ECBs: Event Control Blocks (ECBs) are another name for packet receive buffers. You can get an overview of ECB allocation from this page. It also lists all modules currently assigned ECBs. The Packet Receive Buffers link brings you to this same page.

If the server seems to be slowing down or losing workstation connections, see how many ECBs are allocated and how many are being used. You might need to increase the minimum and/or maximum numbers of packet receive buffers. To do this from NoRM, select Set Parameters >> Communications and scroll down to the Minimum and Maximum Packet Receive Buffers settings. You can also decrease the New Packet Receive Buffer wait time.

After a couple of days of average network usage, check to see how many packet receive buffers are being allocated, and compare that with the maximum number. If the two numbers are the same, increase the maximum value by 50 buffers. Continue to monitor the buffers periodically and increase the maximum value until the allocated number no longer reaches the maximum.

Virtual Memory

NetWare 6.5 includes support for virtual memory to help utilize memory more efficiently. Any modules that are loaded in protected memory will utilize virtual memory. With virtual memory, data that hasn't been accessed recently can be moved back to disk, where it is temporarily stored in a swap file. When the data is requested again, it is restored back into memory. Data in the swap file can still be accessed more quickly than from its permanent location on the disk, while at the same time allowing existing RAM to be used more efficiently . This helps reduce the possibility of encountering low memory conditions on the server.

A swap file is created automatically for the SYS volume. You can create additional swap files for each volume if you want. The swap files don't necessarily need to reside on the volume for which they're designated, but it's a good idea to have one swap file per volume.

View, create, and delete swap files from NoRM's Health Monitor by clicking Virtual Memory Performance >> To Swap File Information. This will open the Swap File Configuration utility (see Figure 4.7).

Figure 4.7. Swap file configuration as it appears in NoRM.

To create a new swap file, select the No link in the Swapping Enabled column next to the volume for which you want to create a swap file. If you don't specify any parameters, this will create a swap file with a minimum size of 2MB, a maximum size of the entire volume size, and will leave a minimum of 5MB of free space on the volume. However, you can set any of these parameters as you see fit by typing the desired value into the appropriate field.

To delete a swap file from a volume, select the Yes link in the Swapping Enabled column next to the volume for which you want to delete the swap file and select Disable.

Error Logs

You can monitor several error log files to determine whether your network has generated any error messages. They are a valuable source of information and clues when troubleshooting a network or server problem.

You can view the principal log files with NoRM by selecting Reports /Log Files (see Figure 4.8).

Figure 4.8. Report and log file options in NoRM.

You have access to the following information from this screen:

• View Config Report: Lets you generate and view a NetWare Server Configuration report. This report can help you diagnose problems with your server that might be caused by improper NLM versions. You can print this report from your browser, if desired. Clicking Send Config Report will generate a Config report and email it to the specified email address. The Config report contains the following:

  • Basic server configuration information

  • A listing of all modules currently loaded on the server

  • LAN driver configurations

  • Storage device configuration

  • Statistics for all mounted volumes

  • A listing of all primary server configuration files

  • A listing of current SET parameter settings

  • A listing of the contents of SYS:SYSTEM

  • A listing of the boot directory ( C:\ )

• View Security Report: Lets you generate and view a Server Security report. This report can help you monitor potential security risks to a server. To see all the available information, you must be logged as an Admin user . Clicking Send Security Report will generate a Security report and email it to the specified email address. The Security report contains the following:

  • General security-related information

  • Trustee assignments for all mounted volumes

  • Trustee assignments to the common folders on volume Sys

  • Information for all protocols loaded on the server

• View Inventory Report: Lets you generate and view a NetWare Server Inventory report. Clicking Send Inventory Report will generate an Inventory report and email it to the specified email address. This report can take a while to create, so it is automatically saved on the server where you can view it at a later time. This report contains the following information:

  • Links to volume-specific reports

  • Storage resource management information about the files on the server volumes

  • A list of key statistics

  • Various profiles of the files

  • A list of all the trustee assignments for each volume

• Log File Management: The links in this table let you view and clear several of the log files available on the server. Simply click the log's filename to view the log. Restart the logging by clicking Clear next to the log you want to clear. The following logs are available:

  • Server Personal Log Book: Stored at SYS:SYSTEM\NRMUSERS.LOG , this log functions as a journal to let you keep track of changes made to the server, or any other information you might want to keep around.

  • System Error Log: Stored at SYS:SYSTEM\SYS$LOG.ERR , this log file stores all messages sent to the System Console and Logger screens.

  • Abend Log: Stored at SYS:SYSTEM\ABEND.LOG , this log file tracks any ABENDs that occurred on the server. Because of the robust recovery features in NetWare 6.5, you might not be aware that the server has had a problem unless you view this file.

  • Server Health Log: Stored at SYS:SYSTEM\HEALTH.LOG , this log file tracks the change in health status as they are reported by the semaphore (traffic light) in NoRM (Green, Yellow, Red).

There are a few other log files of which you should be aware. You can view these logs in NoRM by selecting the Volumes link, selecting the volume on which the log is storedtypically SYS: or C:\ and then browsing to the file you want to view. The error log files you should keep in mind include the following:

• BOOT$LOG.ERR: Logs all the errors that occur during server startup. This file is stored in the SYS:SYSTEM directory.

• LOGGER.TXT: Many of the console messages that were formerly sent to the server console are now sent to a new Logger screen available in NetWare 6.5. All Logger screen messages are maintained in a buffer, so you can scroll up and down the logger screen as needed. You can dump the Logger buffer file to C:\NWSERVER\LOGGER.TXT by pressing <F2> while in the Logger screen. Other Logger options can be seen by pressing <F1> in the Logger screen.

• VOL$LOG.ERR: Logs error messages for a volume. This log file is used only with traditional NetWare volumes. Each volume has its own log file, which is stored at the root of the volume. Any errors or messages that pertain to the volume are stored in this file.

• TTS$LOG.ERR: Logs all data that is backed out by the NetWare Transaction Tracking System (TTS). This log file is used only with traditional NetWare volumes. This file is stored in the SYS volume. To allow this file to be created, use MONITOR.NLM to turn the TTS Abort Dump Flag parameter to On.

NOTE

Remember, you can also run NoRM from the server GUI by clicking the red N icon.

To limit the size of SYS$LOG.ERR and BOOT$LOG.ERR, select Set Parameters >> Error Handling from NoRM and change the appropriate log file parameters. You can also set these parameters from the server console with MONITOR.NLM:

• Server log file state: This parameter defines what should happen if the server log reaches its size limit. Valid options are 02. Default is 2.

  • 0: Takes no action (logging will effectively stop)

  • 1: Clears the log file (all previously saved data is lost)

  • 2: Renames the log file and starts a new one

• Server log file overflow size: Sets the maximum size for SYS$LOG.ERR in bytes.

• Boot error log file state: This parameter defines what should happen if the boot error log reaches its size limit. Valid options are 03. Default is 3.

  • 0: Takes no action (logging will effectively stop)

  • 1: Clears the log file (all previously saved data is lost)

  • 2: Renames the log file and starts a new one

  • 3: Causes a new log file to be created every time the server is rebooted

• Boot error log file overflow size: Sets the maximum size for BOOT$LOG.ERR in bytes.

To limit the size of VOL$LOG.ERR and TTS$LOG.ERR on traditional NetWare volumes, select Set Parameters >> Traditional File System from NoRM and change the appropriate log file parameters. You can also set these parameters from the server console with MONITOR.NLM:

• Volume log file state: This parameter defines what should happen if the server log reaches its size limit. Valid options are 02. Default is 2.

  • 0: Takes no action (logging will effectively stop)

  • 1: Clears the log file (all previously saved data is lost)

  • 2: Renames the log file and starts a new one

• Volume TTS log file state: This parameter defines what should happen if the TTS log reaches its size limit. Valid options are 02. Default is 2.

  • 0: Takes no action (logging will effectively stop)

  • 1: Clears the log file (all previously saved data is lost)

  • 2: Renames the log file and starts a new one

• Volume log file overflow size: Sets the maximum size for VOL$LOG.ERR in bytes.

• Volume TTS log file overflow size: Sets the maximum size for TTS$LOG.ERR in bytes.

Using these log files, you can keep a pretty close eye on events related to your NetWare storage environment.

Performing Regular Server Maintenance

From time to time, you might find you need to perform some type of maintenance on your server. For example, you might need to add a new hard disk, load the latest patches (bug fixes or enhancements) on the server, or clear a workstation connection. The following sections explain how to do some of these common maintenance tasks.

Displaying Information About the Server

Just about all the server information you will ever need is available in NoRM. Utilities with identical functionality are also available from the server console. Table 4.3 lists the types of information about the server you can see and the console utilities you can use to display that information.

Table 4.3. How to Display Server Information

TYPE OF INFORMATION	NORM PAGE	CONSOLE UTILITIES
Server name	Header Frame	NAME, CONFIG
Tree name	Access Tree Walker	CONFIG
Network board info	Disk/LAN Adapters	CONFIG
Storage devices	Disk/LAN Adapters	LIST STORAGE ADAPTERS
Loaded NLMs	List Modules	MODULES
Processor speed	Processors	SPEED, CPUCHECK
Processor status	Processors	DISPLAY PROCESSORS
Version number	Reports/Log Files >> View Config Report	VERSION
Current SET parameters	Set Parameters	DISPLAY ENVIRONMENT
SET parameters not at default	Set Parameters	DISPLAY MODIFIED ENVIRONMENT
Mounted volumes	Volumes	VOLUMES

Installing Patches and Updates

No software product is going to be perfect, no matter how thoroughly it has been tested. And because of today's tight development schedules and competitive marketplace , the reality is that there is already a list of known defects before the product even ships. NetWare 6.5 is the most thoroughly tested and most stable product ever to be released by Novell, but that doesn't mean that unforeseen flaws or unexpected behaviors won't crop up.

To fix these problems, Novell releases software patches and updated modules that can be installed on your NetWare server. Once tested, NetWare 6.5 patches will be rolled into a support pack. Not all individual patches or updates are needed for every customer, but support packs usually contain enough fixes that they are a good idea for the majority of NetWare 6.5 users.

All NetWare patches come with installation instructions and an automated installation routine to make sure all the files get to the right places.

Novell releases support packs, patches, and updates in a variety of ways. The best way to keep track of the recommended updates is through Novell's minimum patch List. Individual patches are available from Novell's Support Web site, and all patches and updates are also included on the Support Connection Librarya collection of CDs regularly produced by Novell Technical Services and sent to subscribers.

NOTE

Novell's minimum patch list is located at http://support.novell.com/produpdate/patchlist.html. Individual patches are available from Novell's Support Web site at http://support.novell.com.

Monitoring Workstation Connections

Some types of server maintenance require that you break a workstation's connection to the server or that you prevent users from logging in while you're completing the maintenance task. Use the utilities listed in Table 4.4 to perform these tasks.

Table 4.4. Ways to Monitor Workstation Connections

TASK	NORM PAGE	CONSOLE UTILITY
See connected workstations	Connections	MONITOR
See open files	Connections (select a connection)	MONITOR (select a connection)
Clear connections	Connections	MONITOR (press Del)
Prevent user login	None (use iManagerUser Management)	DISABLE LOGIN
Re-enable login	None (use iManagerUser Management)	ENABLE LOGIN

Modifying Server Startup Activities

When you start up or reboot the NetWare server, its boot files execute in the following order:

1. The DOS system files load, including CONFIG.SYS and AUTOEXEC.BAT, which sets up a basic environment and can be set to automatically execute SERVER.EXE.

2. SERVER.EXE runs the NetWare operating system on the computer, which turns the computer into the NetWare server. NWSERVER.EXE is located in the \NWSERVER directory.

3. STARTUP.NCF, which is stored in the Boot partition with SERVER.EXE, automates the initialization of the NetWare operating system. It loads disk drivers, name space modules to support different file formats, and may execute some SET parameters that modify default initialization values.

4. AUTOEXEC.NCF, which is stored in SYS:SYSTEM , loads the server's LAN drivers, sets time parameters, specifies the server name and ID (formerly the IPX internal net number), mounts volumes, and then performs optional activitiessuch as loading application or utility NLMs you specified to load automatically, and executing additional SET parameters.

5. Additional .NCF files, if they've been created, can be called from the AUTOEXEC.NCF file or executed from the server's console. They are normally stored in SYS:SYSTEM .

The STARTUP.NCF and AUTOEXEC.NCF files are created automatically during the installation process. They contain commands that reflect the selections you made during installation. Several other .NCF files are created during the NetWare 6.5 installation or when other services are installed.

You can edit these .NCF files after installation to add new commands or modify existing ones. Table 4.5 describes the utilities you can use to edit the STARTUP.NCF and AUTOEXEC.NCF files.

WARNING

When using a text editor, make sure you save the NCF file as a plain text document to prevent any formatting characters from being inserted, and be sure the .NCF extension is preserved.

There are several ways to modify .NCF files, both from the server console and from a client workstation. Furthermore, any server-based method can be accessed remotely through RConsoleJ in ConsoleOne.

Table 4.5. Tools for Editing .NCF files

TOOL	DESCRIPTION
Text editor	Any text editor can be used to modify an .NCF file from a Windows workstation. Simply browse to the desired file and open it with your editor. You might have to use the Open With option to specify the editor for the .NCF file extension.
EDIT.NLM	A text editor on the server that lets you manually edit the files. Type EDIT at the server console, and then enter the full name, including path, of the desired file.
NWCONFIG.NLM	Lets you modify the same options you set during installation. Automatically updates the appropriate file with the new information you've specified. Also lets you manually edit the files by choosing NCF files options.
MONITOR.NLM	Lets you add, delete, or modify SET parameters by selecting them from menus . Automatically updates the appropriate file with the new information you've specified.

TIP

You can also open EDIT. NLM from console screens in NoRM and edit an NCF file from there.

NetWare Time Synchronization

Although time synchronization is vital to the proper function of Novell eDirectory, it does not implement time synchronization. Rather, eDirectory requires the underlying Network Operating System (NOS) platform to provide a fully time-synchronized environment in which eDirectory can operate .

Novell implemented a proprietary time sync model for NetWare with the release of NetWare 4. However, because eDirectory is now used across multiple NOS platforms, it must be able to synchronize time with non-NetWare servers and/or networks. To do this, Novell has extended the NetWare time sync modules to support an industry standard time synchronization protocol known as Network Time Protocol (NTP).

There are four types of timeservers supported in a NetWare 6.5 environment:

• Single Reference: Uses its own internal clock, or an external time source, to determine network time. This eDirectory time is then communicated to secondary timeservers and network clients. The Single Reference timeserver is the master source for network time.

• Reference: Uses its own hardware clock, or an external time source, to determine network time. Reference servers replace the Single Reference timeserver in more complex network environments. The Reference server participates with other timeservers in a voting process to determine a consensus time. When a reference server is used, NetWare uses a hybrid time sync strategy. However, as you'll see, other participants in the time synchronization process will converge toward the Reference server time.

• Primary: Name notwithstanding, a Primary timeserver does not generate network time. Primary timeservers participate in a polling process with other primary servers and the Reference server. During the polling process, each Primary timeserver votes on the correct network time. From this process, a consensus network time emerges. Each primary timeserver synchronizes its internal clock to the consensus network time and helps distribute that time to all interested parties.

• Secondary: Secondary timeservers receive network time from Single Reference, Reference, Primary, or other secondary timeservers. Secondary timeservers are slaves that do not participate in the time polling process, but simply receive and pass on the consensus network time.

The choice of a time synchronization strategy is largely dependent on the size and complexity of your network. You have your choice of a default strategy, appropriate for smaller networks, or a more complex Time Provider Group strategy, which is more efficient in a large network environment. Configuring either of these environments is done with the TIMESYNC.CFG file, as shown in Figure 4.9. TIMESYNC.CFG is stored in SYS:SYSTEM .

Figure 4.9. Sample TIMESYNC.CFG file.

Default Time Synchronization

The default time synchronization strategy is suitable for smaller networks with fewer than 30 servers in the network and no WAN connections. The default time synchronization strategy utilizes SAP in an IPX environment and SLP in an IP environment to locate and query the Single Reference server. Figure 4.10 shows a default time sync configuration.

Figure 4.10. Logical time sync architecture (sample).

Under the default strategy, the first server installed into an eDirectory tree is designated as a Single Reference timeserver. All subsequent servers installed into the tree are designated as Secondary timeservers. In this scenario, the Single Reference server defines the network time and responds to all queries regarding network time. Obviously, as the network grows and/or WAN links are added, this single source for network time will become a bottleneck. If this Single Reference server has to be contacted across a WAN link, this time synchronization method will also add unnecessary traffic to expensive WAN links.

Time Provider Group

More complex environments should implement a Time Provider Group (TPG) or groups. A TPG consists of a centrally located reference server, and between two and seven primary servers that will distribute the network time to all servers in the network, as shown in Figure 4.11. This strategy spreads the task of distributing network time out across multiple servers. It also makes it possible to limit the amount of time synchronization traffic that needs to traverse costly WAN links.

Figure 4.11. Sample TPG configuration.

In a well-designed network environment, it is easy to determine the optimal locations for the various timeservers. The Reference server should exist at the hub of the network, perhaps at a corporate headquarters to which all satellite or branch offices are connected. The Reference server will normally receive its time from a highly accurate external time source such as an atomic clock, radio clock, or Internet time source. These time sources can be contacted through dial-up connections or across the Internet.

Primary servers should be strategically placed at the largest branches and distribute time information to Secondary servers at their own site as well as any small satellite sites in their area.

Time Sync Advertisement

In addition to these synchronization strategies, you will have to decide on automatic or manual advertisement of time synchronization. The following describes the advantages and disadvantages of each method:

• Automatic advertisement: By default, NetWare 6.5 advertises its configuration automatically using SLP in TCP/IP networks or SAP in IPX networks. The advantage of automatic advertisement is ease of implementation. Timeservers will communicate without any intervention from the administrator. However, this background communication consumes network bandwidth, which can be a big issue on WAN links and other slow network connections.

• Manual advertisement: Also known as configured lists , the administrator manually defines the source of network time for each server in its TIMESYNC.CFG file. Reference and single timeservers can get their time from either their internal clocks or from an authoritative time source such as an atomic clock, radio clock, or Internet time source.

Your choice of advertisement method depends on how much you want the network to do automatically, at the expense of some network bandwidth.

Configuring Your Time Sync Environment

TIMESYNC.NLM is responsible for all time sync operations that take place in the NetWare environment. It loads automatically when the server starts. At that time, TIMESYNC.NLM reads the TIMESYNC.CFG file to determine how it should act. You can modify TIMESYNC.CFG settings through NoRM by selecting SET Parameters and clicking Time. Eight of the parameters are set when the server is installed and will seldom have to be modified:

• TIMESYNC configuration file

• Start of daylight saving time

• End of daylight saving time

• Daylight saving time offset

• Daylight saving time status

• New time with daylight saving time status

• Time zone

• Default timeserver type

The remaining parameters are used to configure and reset the time sync environment. They are outlined in Table 4.6.

Table 4.6. TIMESYNC.CFG Parameters

PARAMETER	DEFAULT	VALUES DESCRIPTION
Configured sources	OFF	Set ON if a list of time sources is used.
Polling count	3	Defines how many time packets to exchange during time polling cycle. Increasing this number will add network traffic needlessly.
Polling interval	600 sec	Defines the time to wait between time polling cycles. This value should be the same for every server in the tree.
RESET	OFF	Resets internal time sync variables and clears the configured server list.
Restart flag	OFF	Restarts the time sync service. Similar to unloading and reloading TIMESYNC.NLM.
Service advertising	ON	Determines whether SAP/SLP advertisement will be used. Turn this off when using configured lists.
Synchronization radius	2000 msec	Defines how close a server's time has to be to network time in order to be considered in sync.
Time adjustment	[+ -]hh:mm:ss [AT date and time]	Schedules a time adjustment on a single, reference or primary timeserver.
Time sources	Timeserver to query	Configured list of timeservers that this server will query for network time. Multiple time sources can be configured so that if one does not respond, the server will query the next on the list.
Type	Single, Reference, Primary, Secondary	Defines the type of timeserver.

Using NTP with NetWare 6.5

The first decision you need to make when integrating TIMESYNC and NTP environments is the direction of the time flow. Do you want NTP to receive time from TIMESYNC or vice versa? Both options are equally valid, but some environments lend themselves more to one method over another. The random mixing of NetWare and NTP servers is not recommended.

Novell time sync experts recommend using NTP over WAN links and then letting the NetWare TIMESYNC environments at each site receive their time by NTP. To configure TIMESYNC to receive time from NTP, edit the TIMESYNC.CFG file on the reference or single server and change the time source to point to an NTP server.