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.
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:
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
Once configured as noted here, your UPS can communicate with your NetWare 6.5 server through the server's serial port.
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."
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.
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.
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.
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:
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.
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:
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.
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.
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:
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:
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:
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:
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
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.
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
Modifying Server Startup Activities
When you start up or reboot the NetWare server, its boot files execute in the following order:
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.
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
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:
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:
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:
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
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.