Troubleshooting

Del Mar College
CIS 306 - Managing NOVELL® Networks
Instructor: Michael P. Harris

IntranetWare 4.11

IntranetWare Adminstration Guide

Troubleshooting

Troubleshooting Hardware and Network Problems

The following sections provide hardware and network troubleshooting information for resolving equipment-related errors on a server running the IntranetWare^TM for Small Business networking software.
Identifying Problems After Installation

If the problem occurred after installation, it may indicate that the network was installed incorrectly.
Check all network boards for possible conflicting address and I/O settings.
Each component should be able to work as a standalone system. Remove all network boards in the server and boot DOS. Add each board one at a time and make sure that DOS still boots after each addition.

Make sure that all cables are fastened securely to all network boards and network connectors, and that terminating resistors are installed correctly.

Resolving Hard Disk Access Problems

To diagnose hard disk access problems, you should identify if the following conditions exist:
The disk driver has not been loaded.

A hard disk is not installed or cabled correctly.

The communication channel between the controller interface board, the disk coprocessor board, and the hard disk is not functioning.

The hard disk controller board is not terminated or addressed correctly.

To resolve hard disk access problems, you should perform the following actions:
Make sure the disk driver is loaded. At the console, type MODULES to view the loaded disk drivers.

Check the cables between the hard disks and the controller boards. Be sure Pin 1 of each cable is attached to Pin 1 of each connector.

Check the power cables and make sure they are seated correctly in the power sockets on the hard disks.

Check the jumper settings on the disk coprocessor board (DCB), the controller board, and the hard disk. Refer to the hardware documentation for correct jumper settings.

If you are using a DCB, run DISKSET to make sure the hardware configurations contained on the EEPROM chip on the disk coprocessor board match those for the hard disks in your server.

Load INSTALL to check the IntranetWare Small Enterprise disk partition and volume information on the hard disk. For details, see "Maintaining Volumes" in Supervising the Network of the NetWare 4.11 online documentation.

Make sure that each controller interface board connected to the same disk coprocessor board has its own valid address.

Making Computer Memory Available for Network Drivers

To increase the amount of workstation memory available for network drivers:
Add more memory.

Unload unneeded TSR (terminate-and-stay-resident) programs (DOS clients only).

Modify the NET.CFG file to load only necessary drivers.

Modify the CONFIG.SYS file to load only necessary drivers.

For more information about freeing up memory on a workstation, see "Resolving Workstation Memory Problems" in Supervising the Network of the NetWare 4.11 online documentation.
For information about freeing up memory on a server, see "Resolving Server Memory Problems" in Supervising the Network of the NetWare 4.11 online documentation.
Resolving Cabling Problems

Use the proper cabling for your network topology as specified by IEEE. Make sure cable segments do not exceed the recommended lengths.

Make sure cable segments are properly terminated for the type of cabling being used.

Make sure terminators and in-line cable connectors are working properly.
If you are not sure whether a terminator or connector is working properly, replace it. If the new components work properly, discard the old ones.

Make sure there are no breaks in the cable or shield. Use a time delay reflectometer (TDR), a LANalyzer, or a volt ohm meter (VOM) to test cabling for breaks in the cable conductor or shield.

Make sure cabling is routed away from devices that produce high electric or magnetic fields, such as fluorescent lights, microwaves, radar, X-rays, copy machines, etc.

Power Supply Errors

An inconsistent power source is the most common cause of hardware problems. It also produces the most devastating results.
Power outages cause workstations, network servers, print servers, and backup devices to reboot. When this happens, all information stored in RAM is lost, and sometimes hardware is damaged.
Power spikes and "brownouts" can also cause a variety of hardware errors.
You can have reliable network performance only if you plan for power outages and fluctuations and protect against them. The following tips can help you do this:

Add a dedicated power feed and ground line from your breaker box to critical equipment. Make sure the ground line connects to earth ground.

Install an uninterruptible power supply (UPS) or a standby power system (SPS) to provide power to critical equipment for 15 minutes after a power outage.
The capacity of such power supplies is limited, so you may not want to plug nonvital hardware (such as monitors or printers) into the UPS or SPS line.

Train users to save data and log out of the network when the lights go out. Then you can bring down the NetWare server in an orderly fashion without forcing users off the system while the server is running on UPS or SPS power.

Install a surge suppressor or power conditioner on all power lines that are used by computers. Many UPS and SPS devices already have this feature.

Do not allow anyone to plug fans, printers, copy machines, vacuum cleaners, or other motor-driven appliances into the dedicated line or into any power line with computers.
Insert dummy plugs into open outlets to prevent people from plugging such appliances into computer power sources.

Troubleshooting the NetWare Server

This section provides troubleshooting suggestions for typical NetWare server problems such as abends, disk I/O errors, insufficient disk space, and insufficient memory.
Resolving Abends

The IntranetWare Small Enterprise operating system is very resilient, but errors can and will arise. Serious problems are usually accompanied by abend (abnormal end) messages.
Abend messages are usually caused by consistency check errors or CPU-detected software errors.
Consistency check errors are internal tests placed in the operating system to ensure the stability and integrity of internal operating system data.
Consistency check errors might be caused by a corrupted operating system file, by corrupted or outdated drivers and NetWare Loadable Module^TM (NLM^TM ) programs, or by hardware failure.
What Happens When You Get an Abend

When the server abends, it displays an abend message similar to the following:
Abend: SERVER-4.10-message_number
 message_string
ADDITIONAL INFORMATION: message
The "Additional Information" section states the probable cause of the abend. It indicates where the problem occurred and gives the name of any NLM program associated with the abend. This information helps you determine how to resolve the abend.
You can respond to the abend manually or have the server respond automatically.
When you respond manual ly, the server determines the nature of the abend and displays the appropriate response option on the screen, along with additional options for bringing down the server or executing a core dump. You must execute an option to respond to the abend.
When the server responds automatically, it executes the appropriate response without intervention.
IMPORTANT: Sometimes an abend (or a faulty NLM program) can cause the server console to "hang" (stop functioning). In this case, the abend message is not displayed and you cannot enter commands at the console prompt.
If this happens, press <Ctrl><Alt><Esc> . A message asks if you want to down the server. Enter Y to down the server and exit to DOS, or N to return to the console prompt.

Responding to the Abend Manually

The default method of responding to an abend is "automatic." For more information about automatic response to abends, see "Responding to the Abend Automatically" in Supervising the Network of the NetWare 4.11 online documentation.
To respond manually to abends, change either of the following SET parameters to the values shown:
AUTO RESTART AFTER ABEND = 0
DEVELOPER OPTION = ON
When an abend occurs, the server displays a short list of options appropriate to the nature of the abend. To respond to the abend, you must execute one of the options by typing the first letter of the option.
The following options may be displayed. Note that several of the options have the same first letter (such as R, S, or X). In a given abend situation, the option list will include only one option for any given first letter.
S=Suspend the running process, update ABEND.LOG, and attempt to down the server.
This option appears if the abend was "software-detected," that is, detected by IntranetWare Small Enterprise. It is important to save files, shut down the server, and try to solve the problem that caused the abend. Review the ABEND.LOG file to help determine the source of the problem.
When you execute this option, the server sends a message every two minutes to users advising them to save their files and log out. The server then stops the running process, updates the ABEND.LOG file, and attempts to shut down and restart the computer.
The amount of time before the server shuts down and restarts is determined by the SET parameter AUTO RESTART AFTER ABEND DELAY TIME. You can set this value from 2 to 60 minutes.

R=Resume the running process, update ABEND.LOG, and attempt to down the server
This option appears if the abend was an NMI (nonmaskable interrupt), indicating a parity error or a machine check processor exception. It is important to save files, shut down the server, and solve the problem causing the abend. Review the ABEND.LOG file to help determine the source of the problem.
When you execute this option, the server sends a message every two minutes to users advising them to save their files and log out. The server then resumes the running process, updates the ABEND.LOG file, and attempts to shut down and restart the computer.
The amount of time before the server shuts down and restarts is determined by the SET parameter AUTO RESTART AFTER ABEND DELAY TIME. You can set this value from 2 to 60 minutes.

S=Suspend the running process and update ABEND.LOG
This option appears if the abend was "hardware-detected," that is, detected by the processor. All hardware-detected abends have the words "processor exception" in the abend message.
These abends include page faults, protection faults, and invalid op codes. When this option is available, the server has determined that it cannot return the process to a safe state, but that it does not need to shut down the computer immediately to resolve the problem. You may still need to shut down the computer and restart it at a later time.
When you execute this option, the server suspends the currently running process, updates the ABEND.LOG file, but does not shut down the computer. Server performance may be poor, because a loaded NLM is probably malfunction ing.
Read the "Additional Information" part of the abend message to learn which NLM might be causing the problem. Wait until a convenient time, then
S=Return the running process to a safe state and update the ABEND. LOG file
Like the previous option, this option appears if the abend was "hardware-detected," that is, detected by the processor. All hardware- detected abends have the words "processor exception" in the abend message.
These abends include page faults, protection faults, and invalid op codes. When this option is listed, the server has determined that it can return the process to a safe state.
When you execute this option, the server returns the running process to a safe state and updates the ABEND.LOG file, but it does not shut down the computer. In most cases, the machine completely recovers and no further action is necessary. This option resolves most page fault abends.

Y=Copy diagnostic image to disk
Execute this option to perform a core dump that can be examined to determine the cause of an abend.

X=Restart
This option appears only if DOS has been removed. Execute this option if you want to restart the server.
NOTE: If DOS has been removed, the server will not create or update an ABEND.LOG file.

X=Update ABEND.LOG and then exit
Execute this option if you want to bring down the server and exit to DOS. If you power off the server without first executing one of the S or R options to resolve the abend, the server will not update the ABEND.LOG file.

Otherwise, power off and back on to restart
If the console has been secured, you must power off and then back on to restart the server. If you power off the server without first executing one of the S or R options to resolve the abend, the server will not update the ABEND.LOG file.

NOTE: When the server restarts, it moves the ABEND.LOG file from the DOS partition to SYS:SYSTEM.

Responding to the Abend Automatically

You can require the server to respond automatically to abends. Two automatic responses are possible.
When both of the following parameters are set to the values shown, the server responds to the abend automatically by evaluating the source of the abend and executing the appropriate S or R option described in the previous section.
AUTO RESTART AFTER ABEND = 1
DEVELOPER OPTION = OFF
Because these are the default values of the parameters, the default mode is to respond to abends automatically.
When both of the following parameters are set to the value shown, the server responds to the abend by downing the server and attempting to restart it.
AUTO RESTART AFTER ABEND = 2
DEVELOPER OPTION = OFF
Use the following parameter to specify how long the server waits after an abend before attempting to shut down and restart the computer:
AUTO RESTART AFTER ABEND DELAY TIME = minutes
Use the SET command or the SERVMAN or MONITOR utilities to set the parameter values. See "SET," "SERVMAN," or "MONITOR" in Utilities Reference.
The DEVELOPER OPTION parameter is found in the "Miscellaneous" category of parameters.
The AUTO RESTART AFTER ABEND and AUTO RESTART AFTER ABEND DELAY TIME parameters are found in the "Error Handling" category.
All parameters can be set in the STARTUP.NCF file.
IMPORTANT: Because the server responds to the abend automatically, you may not know when an abend has occurred. Therefore, you should periodically check the ABEND.LOG file or the "Server Up Time" statistic on the "Connection Information" screen of MONITOR.

Resolving Server I/O Errors

To resolve a general disk I/O error on the server, try one or more of the following remedies:
Check the disk subsystems to make sure the power is on and the cables are correctly connected between the controller and the subsystems.

Make sure the subsystem cables are terminated correctly.

Make sure the disks are installed correctly.

Make sure you have current NetWare 4^TM -certified disk driver loaded. Many drivers can be found on the NetWare CD-ROM or on the master diskettes. Updated drivers may also be available from third-party disk driver manufacturers.

Make sure the interrupt parameters, I/O port settings, slot settings, etc. for the driver match those for the hardware. Also, make sure custom parameters have been set correctly for your hardware.
At the server console, type the following command:
SCAN FOR NEW DEVICES <Enter>
This causes the operating system to request controller information about all devices.
Load INSTALL, select "Disk Options," and then "Modify Disk Partitions and Hot Fix." Make sure the device is visible and has a valid partition.

Increase the Hot Fix^{^TM} Redirection Area, using INSTALL.NLM.
To change the Hot Fix Redirection Area on an existing drive, back up all the data on the partition, delete the volumes on the partition, and delete the partition; then re-create it.
Assign the partition a different percentage for the Hot Fix Redirection Area; then re-create the volumes and restore the data.
If you have tried all the preceding suggestions without success, contact your Novell� Authorized ResellerSM representative or drive manufacturer.
Resolving Server Disk Space Problems

To resolve an insufficient disk space error, you should do one or more of the following:
Delete unnecessary files and directories from the volume.

Change the Minimum File Delete Wait Time SET parameter in your server's AUTOEXEC.NCF file equal to 0 so that files can be removed immediately rather than being retained in a salvageable state on the volume.

Use the FILER or NetWare Administrator^TM utility to purge deleted files if they cannot be purged automatically. (The deleted files are using up directory table space.)

Increase the volume size and/or add more disks to the volume.

Increase the percentage of disk space that can be used by a directory.

If the disk or volume has space available, check the disk drives and disk channel to see if a failure has occurred.

Use SET to increase the percentage of disk space that can be used by a directory.

Delete NLM programs that you no longer use.

Check and adjust or remove any volume restrictions placed upon users.

If the disk or volume has space available, check the disk drives and disk channel to see if a failure has occurred.

For information on SET parameters, see "Managing Server Hard Disks" in Supervising the Network and " SET" in Utilities Reference of the NetWare 4.11 online documentation.
Resolving Server Memory Problems

To free up server memory temporarily (until you can add more memory to the server), do one or more of the following:
Use the FILER or NetWare Administrator utility to purge deleted files on the specified directory that cannot be purged automatically. (Deleted files are using up directory table space.)

Unload NLM programs, such as INSTALL or MONITOR, that are not currently needed.

Dismount volumes that are not being used.

Reduce the size or number of volumes that the server supports.

Delete unused files and directories on the specified volume.

Change the Minimum File Delete Wait Time SET parameter in the AUTOEXEC. NCF file so that files can be purged immediately rather than being retained in a salvageable state on the volume.

As a last resort, back up all files in your volume, bring down your server, and use INSTALL to reinitialize the volume. Specify block size of 64 KB and turn the "Block Suballocation" option to "Off."
(This setting uses a lot of disk space but increases the amount of memory available.)
For more information, see "SET" in Utilities Reference of the NetWare 4.11 online documentation.

Resolving Locked Device Errors

To resolve a locked device error, try one or more of the following:
Wait for a while; the task in process may complete and free the device.

Retry the action that resulted in the error.

Load MONITOR.NLM, delete all user connections, and disable logins.

For a disk device error, unload NLM programs (other than the device driver) that may be using the disk. Dismount all volumes on the disk.

If you have tried all of the above without success, contact your Novell Authorized Reseller representative or the drive manufacturer.
Resolving File I/O Errors

To resolve a file I/O error, try one or more of the following:
Check to see that the volume (especially volume SYS:) is mounted. To check volumes, type VOLUME at the server console prompt.

If the volume is out of disk space, error messages will appear on the console screen indicating that the volume is almost out of disk space. Check the console screen.

Type DIR at a DOS workstation to see how much space remains.

To increase the amount of free space, do one or more of the following:
Delete extraneous files (if you can log in from a workstation).

Type SET IMMEDIATE PURGE OF DELETED FILES = ON at the console prompt, and retry the action.

If you have an additional disk, increase the size of the volume by creating an additional segment of the volume on the disk.

See also "Resolving Volume I/O Errors" in Supervising the Network of the NetWare 4.11 online documentation.
Resolving Volume I/O Errors

To resolve a volume I/O error, try one or more of the following:
Make sure all devices that contain the volume are online. (Volumes may span multiple devices.) See" Resolving Server I/O Errors" in Supervising the Network of the NetWare 4.11 online documentation.

Load and execute VREPAIR.

Load INSTALL and select "Volume Options." Make sure the volume is visible.

If you have tried all of the above without success, contact your Novel l Authorized Reseller representative or disk drive manufacturer.
Resolving Event Control Block Allocation Errors

Event control block allocation system messages can occur when you first bring up the server or after the server has been running for some time.
These messages indicate that the server was unable to acquire sufficient packet receive buffers, usually called event control blocks (ECBs). Running out of ECBs is not a fatal condition.
Servers that run for several days where high loads occur in peaks might exceed the set maximum number of ECBs, causing the system to generate ECB system messages.
If these situations are caused by occasional peaks in the memory demand, you should probably maintain your current maximum ECB allocation and allow the message to be generated at those times.
On the other hand, if your server memory load is very high and you receive frequent ECB allocation errors, you should probably set your maximum ECB allocation higher. Use the following SET command in the STARTUP.NCF file:
SET MAXIMUM PACKET 
RECEIVE BUFFERS=number
NOTE: Memory allocated for ECBs cannot be used for other purposes.

The minimum number of buffers available for the server can also be set in the STARTUP.NCF file with the following command:
SET MINIMUM
PACKET RECEIVE BUFFERS=number
Resolving Server Console Command Problems

To diagnose server console command problems, you should identify whether the following conditions exist:
Some SET parameters can only be set in the STARTUP.NCF file.

You are not at the system console.

The server has been brought down.

The server has failed ("hung").

The SERVER.EXE file is corrupted.

The IntranetWare for Small Business operating system has been configured incorrectly.

To resolve server console command problems, you should perform the following actions:
Type the SET parameter in the STARTUP. NCF file and then bring the server down and back up.

Make sure all cables are fastened securely to all network boards and network connectors. Check that terminating resistors are installed correctly.

From a backup, or from the IntranetWare Small Enterprise CD-ROM, copy a new version of SERVER.EXE to the server boot directory. Have all users close their files and log out.
Bring down the server, if possible. If not, wait a few minutes after all users have logged out; then reboot the server.

Check the hardware configuration on each network board in the server to make sure it is correct.

If you recorded network board configurations and they do not agree with the actual hardware configurations, reload the LAN driver with the correct parameters or change the hardware settings to match the LAN driver parameters.

Check all network board settings for possible interrupt and I/O port conflicts. The server can boot up initially even if the interrupt on a network board is set incorrectly.
The most common conflict occurs when a network board is set to interrupt 4 and a printer is connected to the server's serial port, which also uses interrupt 4.

Resolving Keyboard Locking Problems When Copying Files from CD-ROM

To diagnose keyboard locking problems when copying files from CD-ROM, you should identify if the following conditions exist:
If you have a CD-ROM device that shares a SCSI bus with a disk subsystem containing volumes to which IntranetWare Small Enterprise installation files are copied (typically volume SYS:), your keyboard may lock up while loading drivers or copying file s to the volume.
Figure A-1 shows possible configuration conflicts.
Figure Appendix-A-1. Figure A-1

Remove the CD-ROM device drivers that you used to set up the CD-ROM drive as a DOS device from your CONFIG.SYS file. This will avoid possible conflicts when the IntranetWare Small Enterprise CD-ROM is mounted as a NetWare volume.
To resolve keyboard locking problems when copying files from CD-ROM, you should use the following procedure.
Procedure
Press <Alt> <Esc> until you are at the console prompt (:).
Type
DOWN <Enter>
Then type
EXIT <Enter>
Using a text editor, remove the CD-ROM device drivers from your CONFIG.SYS file.

Save the updated CONFIG.SYS file.

Using a text editor, remove any references to the CD-ROM driver s from your AUTOEXEC.BAT file.

Save the updated AUTOEXEC.BAT file.

Reboot the server by pressing <Ctrl> <Alt> <Del> .
(Conditional) If the server doesn't boot automatically from the AUTOEXEC.BAT file, change to the subdirectory to the SERVER.EXE file (the default directory is C:\NWSERVER) and other boot files, and type
CD\NWSERVER <Enter>
SERVER <Enter>
(Conditional) If you are using ASPI device drivers (for example , for an Adaptec controller), you need to perform one of the following commands:
LOAD AHA1540 <Enter>
or
LOAD ASPICD <Enter>
or
LOAD CDNASPI <Enter>
At the console, type
LOAD NWPA <Enter>
At the console, type the following
LOAD CDROM
 <Enter>
CD MOUNT NW410 <Enter>
At the console, type
LOAD INSTALL <Enter>
Resolving Problems When Server "Hangs" after Mounting Last Volume

To diagnose problems when the server hangs after mounting the last volume, you should identify whether the following conditions exist:

The server network board is not initializing when the server is brought up because the board is not installed or seated correctly.

The server network board is not configured correctly.

To resolve problems when the server hangs after mounting the last volume, you should perform the following actions or ensure that the following conditions exist:
Run CONFIG at the server console to see what settings appear on the screen. Check the network board configurations of the boards in the server. Make sure the settings match.

Make sure that all server and workstation network boards are seated proper ly and that cabling and connections are attached securely.

Make sure that the terminators on cables have the right ohm rating and are installed correctly. The IBM* PC Cluster sends a broadcast message during initialization and hangs if the network is not cabled or terminated properly.

Check the network boards in all workstations for correct node address settings.

Resolving Problem When No Volumes Mount

Volume SYS: is the backout volume for TTS^{^TM} (Transaction Tracking System^{^TM} ). Volume SYS: also contains the IntranetWare Small Enterprise system files and the NLM programs.
If volume SYS: does not mount when the server is booted, then the AUTOEXEC.NCF file does not execute, LAN drivers do not load, TTS can't be enabled, and the volume does not become part of the Directory tree.
To diagnose problems when no volumes mount, you should identify if the following conditions exist:
Volume SYS: is corrupted.

The hard disk containing volume SYS: has failed.

The cable or power to the external hard disks has malfunctioned.

To resolve problems when no volumes mount, you should perform the following actions:
Run VREPAIR on volume SYS: (VREPAIR autoloads from the DOS partition).

Check the cabling and power to the external hard disks. Replace any faulty components.

Replace the hard disk containing volume SYS:.
Load INSTALL to create the partitions and volume SYS:.

Restore the data from a backup copy.

Resolving Problems When Only Some Volumes Mount

To diagnose problems when only some volumes mount, you should identify whether the following conditions exist:
The server does not have enough RAM.

The disk driver for external drives may not be loaded.

To resolve problems when only some volumes mount, you should perform the following actions:
Add more RAM.

At the server console, type MODULES to see which drivers are loaded.

Resolving Disk Error Problems When a Volume Is Mounting

To diagnose problems when disk errors occur while a volume is mounting, you should identify whether the following conditions exist:

The server does not have enough memory to mount the volume.

The operating system is experiencing directory sector mismatching. This mismatching can be caused if the media is defective or if the server is turned off without the DOWN command.

To resolve problems when disk errors while a volume is mounting, you should perform the following actions:
Load MONITOR and check the status of the available cache buffers. If the cache buffers are fewer than 20%, add more memory to your server.

Minor errors usually correct themselves through normal network use. For example, if a FAT entry is wrong, the entry is updated and corrected the next time it is written to. If errors do not correct themselves, run VREPAIR.

Some problems may be corrected automatically by TTS.

Resolving Memory Errors When a Volume Is Mounting

To diagnose problems when memory errors while a volume is mounting, you should identify whether the following conditions exist:

Volumes take more memory to mount than they require after being mounted because the mounting process performs consistency checks (for example, the duplicate copies of all the tables are checked).

Volumes and directory entries grow dynamically. Thus, if your server is using most of the RAM (file cache buffers are close to 20% of the memory) and you dismount a volume, you may not be able to remount the volume unless additional memory is available.

Each additional name space support that you add to a volume increases the size of the FATs and DETs. Adding name space support can cause the tables to grow so large that the server does not have enough RAM to mount the volume.

To resolve problems when memory errors while a volume is mounting, you should perform the following actions or ensure that the following conditions exist:
Load MONITOR and check the status of the available cache buffers. If the cache buffers are fewer than 20%, add more RAM to your server.

Free up memory by unloading resources.

Streamline the directory structure. Every subdirectory takes at least one directory block (by default, a 4KB block of memory). Thus, subdirectories with only one file require as much memory as directories with 32 files.
If you combine directories so that most directories have about 32 files, and then purge the deleted subdirectories and files, you will free up memory.

Calculate how much memory you need and add memory to the server. View the current volume size with INSTALL. (See "Modifying the Size of a Volume" in Supervising the Network of the NetWare 4.11 online documentation.)
See Appendix A, "Calculate RAM Requirements," in Installation of the NetWare 4.11 online documentation for a formula for estimating the total amount of server memory needed.

For a more accurate assessment of available RAM, load MONITOR, select "Resource Utilization" from the "Available Options" menu, and view the "Cache Buffers" setting in the "Server Memory Statistics" screen.
If the percentage is below 20%, you should add more memory.

Remove the recently added name space support.
WARNING: This is a destructive step that destroys all the extended file information. Before taking this step, try to free up enough memory so that the volume mounts and you can back up the data.

Have all users log out, and then unload all modules except the volume's disk drivers. Dismount any mounted volumes.
To remove the name space, load VREPAIR and choose the "Remove Name Space Support From The Volume" and "Write All Directory and FAT Entries Out to Disk" options. Then run VREPAIR on the volume that would not mount.

Resolving Volume Mounting Problems Because of Corrupted Directory Entry Tables or File Allocation Tables

To diagnose problems when mismatches exist in the duplicate copies of the File Allocation Table (FAT) and Directory Entry Table (DET), you should identify whether the following conditions exist:
A power failure has occurred and the server has not been brought down with the DOWN command.

A hard disk fails.

A disk channel error occurs.

A volume is not dismounted with the DISMOUNT command.

Directory information in cache is not completely written to disk.

To resolve problems when mismatches in the duplicate copies of the FAT and DET exist, you should perform the following actions:

Run VREPAIR.

Add a UPS system so that the server is brought down automatically when a power failure occurs.

Replace faulty disks or controllers.

Resolving Volume Mounting Problems Because of Name Space Module

Once a volume has been configured to support more than the DOS naming convention, the name space loadable module must be loaded before the volume can be mounted.
To diagnose problems when a volume cannot mount because the name space module is not loaded, you should identify whether the following conditions exist:
The command to load the name space module is not in the STARTUP.NCF file.

The module to load the name space has not been copied to the boot director y of the server.

To resolve problems when a volume cannot mount because of the name space module is not loaded, you should perform the following actions:
Load the name space module; then mount the volume. Copy the name space module to the server boot directory and add the load command to the STARTUP.NCF file. The module then loads automatically whenever the server is booted.

Delete the name space configuration from the volume.
WARNING: This is a destructive step that destroys all of the extended file information.

Back up all non-DOS files. Then load VREPAIR and choose the "Remove All Name Space Entries" and "Write Changes Immediately to Disk" options. Then run VREPAIR on the volume.

Troubleshooting Communication Problems

Communication problems are related to network boards, LAN drivers, network performance, and server/workstation communications, as well as to internetwork communications.
General Communication Problems

To diagnose general network communication problems, you should identify whether the following conditions exist:
The server network board is not seated or configured correctly.

The network board cable from the server is faulty.

Cabling on the network is faulty.

The connector closest to the server is faulty.

The RX-Net^{^TM} active hub is off.

The correct Ethernet frame type has not been specified. NetWare 4.11 defaults to frame type 802.2.

The repeater is off or is nonfunctional.

The cabling is not terminated properly.

Volume SYS: is not mounted.

ISA disk controller boards installed in EISA machines have not been configured.

To resolve general network communication problems, you should perform the following actions:
Check all hubs and repeaters to make sure they are on.

Check the cables for proper termination.

Make sure the server network board is seated properly.

Replace the server network board with a board that works correctly. Make sure the new board has the same jumper settings.

Run VOLUMES at the server console. If volume SYS: is not mounted, mount it. The server does not broadcast to the network until volume SYS: is mounted.

Run CONFIG at the server console to check the configuration of the network boards. Then bring down the server, turn off the power, and check the actual network board settings:
Make sure all settings agree with the settings used to load the driver. If you load the driver with an interrupt that conflicts with the board's setting, the network board cannot broadcast on the network.

Make sure the node address on the board is a legal address. (Addresses 0 and FFFFFFFFFFFF are reserved; do not use them.)

Run CONFIG at the server console to make sure each network board has a LAN protocol bound to it. Network boards cannot broadcast without a protocol.

Run NLIST at a workstation, if possible, to check node addresses. Each node address on the network should be unique. Sometimes you can find the problem by turning off all workstations and turning them on one at a time.

Have a user log in to the network from a workstation. Load MONITOR and choose "Connection Information" from the "Available Options" menu.
If the "Active Connections" list shows the user's login name, the server is receiving and responding to the workstation's request.
If the workstation receives a "Server cannot be found" error, make sure the server and workstation are using the same frame type.

Replace segments of cable and cabling connections until communication is restored.

Resolving Server Boot Problems After a Network Board Is Installed

To diagnose server boot problems after a network board is installed, you should identify whether the following conditions exist:
The network board is not attached properly to the cable.

The hardware conflicts with other boards, the monitor board, or ports in the server.

The network board is faulty.

To resolve server boot problems after a network board is installed, you should perform the following actions.
Cable the network board to at least one workstation and check the termination.

Make a list of all I/O ports, interrupts, and memory addresses used by the equipment.
Also do the following to identify potential conflicts:
Check the documentation that came with the computer and all installed hardware components.

Make sure no two pieces of hardware are using the same I/O port, interrupt, or memory address.

Make sure that the memory range for the I/O ports and memory addresses do not overlap. If there are conflicts, reconfigure the equipment so that no conflicts exist.

Resolving Problems When Workstations Can't Communicate with a Server

To diagnose problems when workstations cannot communicate with a server, you should identify whether the following conditions exist:

The server's network board is not initializing when the server is brought up because the board is not configured correctly or it has failed.

The server is anticipating the wrong frame type. NetWare 4.1x uses Ethernet 802.2 as the default frame type for Ethernet LAN drivers that were loaded at the system console. Workstations running earlier versions of NetWare may be using Ethernet 802.3.

Address or interrupt conflicts exist between two boards inside the server or between a board and the computer's hardware.

The server does not have enough packet receive buffers.

A protocol (such as IPX^{^TM} ) is not bound to the network board.

The cabling is too close to sources of interference.

Volume SYS: is not mounted.

To resolve problems when workstations cannot communicate with a server, you should perform the following actions.
Make sure all network connectors (including transceivers and repeaters) are installed and the cable is attached securely.

Make sure all network boards are seated firmly and the cabling connections are in place.

Make sure the network cable is terminated properly. Many network boards send a broadcast message during initialization and will hang if the network is not cabled or terminated properly.

Check cabling for interference from fluorescent lights, microwaves, radar, X rays, and copy machines. Either move the cable or shield it from the source of interference.

Run VOLUMES at the server console to ensure that volume SYS: is mounted. Volume SYS: must be mounted before the server can advertise its name to the network.

Run CONFIG at the server console to see what settings appear on the screen. Then check network board configurations in the server. Be sure the network board configurations match the settings that appear when you run CONFIG.

Check the workstation frame types to see that they match those of the server.

Check node address settings on all server and workstation network boards. Each address should be unique.

Check all IPX internal and external network numbers. Each server and cabling system should have a unique IPX external network number.

Make sure no two boards in the server are using the same I/O port, memory address, or interrupt.

Bind the LAN driver (TRXNET, NE1000^{^TM} , TOKEN, etc.) to IPX (or another communication protocol).

If you have a lot of network traffic, increase the maximum number of packet receive buffers. (See "SET" in Utilities Reference of the NetWare 4.11 online documentation.)

Resolving Communication Problems Between Servers

To diagnose communication problems between servers, you should identify whether the following conditions exist:
The hardware settings in the server are incorrect.

The IPX internal/external network numbers conflict.

The NetWare Directory database is corrupted.

Frame types are different.

The router is filtering out the IPX external network number.

To resolve communication problems between servers, you should perform the following actions:
Run CONFIG at the server console to see what settings appear on the screen. Then check network board configurations in the server. Be sure the network board configurations match the settings that appear when you run CONFIG.

Check the IPX internal network number for the server and the IPX external network number for the cabling.
When multiple servers share the same cabling system (called a multiserver network), all servers must have the same IPX external network number. However , the servers must have unique IPX internal network numbers and unique node numbers.
When network cabling systems are connected through routers (internal or external), each cabling system must have a unique IPX external network number. NetWare 4 servers must also have a unique IPX internal network number apart from the cabling.
The unique IPX external network number is the first item read in a packet sending/receiving interaction.

Reset the router with the RESET ROUTER console command.

Check the cabling system for faulty termination.

Bring down all servers except one. Reset its router with RESET ROUTER. Bring up each server, one at a time, establishing communications with it before bringing up the next one. Run DISPLAY NETWORKS to check for duplicate IPX external network numbers as each server is booted.

Run DSREPAIR.

Load FILTCFG.NLM at each server and verify that SAP traffic is being routed.

Resolving Slow Server Response

To diagnose slow server response problems, you should identify whether the following conditions exist:
The workstation network board is slow or faulty.

Network cabling is faulty.

The server network board is slow or faulty.

Too many users are using the network.

The server speed is not set to the highest speed.

The server hard disk is slow or faulty.

The server is low on memory.

The volume has too many deleted files that have not been purged.

Network traffic is extremely high.

The cabling system is experiencing too much interference.

A hard disk has failed or is failing.

Insufficient directory buffers, cache buffers, or packet receive buffers have been allocated.

An EISA controller board needs to be configured to use interrupts.

To resolve slow server response problems, you should perform the following actions.
Check the computer's documentation for switch information. Set the CPU speed to its highest setting. Use SPEED to verify that the CPU is running at the appropriate speed.

If a workstation or the server seems slow, insert a new network board into the slow computer to check performance. If the speed is still below normal, reinstall the original network board and replace the cable attaching the workstation or server to the network.

Load MONITOR to check the status of packet receive buffers and service processes. Compare their values to the maximum allowable value.
Use SET to increase the values for the following parameters if your system is at the maximum value: Maximum Service Processes and Maximum Packet Receive Buffers.
(For additional ideas, see "Assessing Server RAM" in Supervising the Network of the NetWare 4.11 online documentation.)

Load MONITOR and check the Hot Fix status of all hard disks. Verify that all mirrored disks are still mirrored.

Run the FILER text utility or the NetWare Administrator graphical utility to purge deleted files. Or set the "Purge" attribute on files you want to be purged immediately after being deleted.
For more information, see "Managing Directories, Files, and Applications" in Supervising the Network of the NetWare 4.11 online documentation.

Load MONITOR and check the LAN driver statistics. If you have more than one network board, compare the boards' "Total Packets Sent" statistics. If one board is receiving most of the traffic, recable the network so that the boards have equal loads.

If you are on a multiserver network or an internetwork, recable the system with a backbone to reduce network traffic. See "Network backbone" in Concepts of the NetWare 4.11 online documentation for a description of a backbone.

Check the cabling for interference from fluorescent lights, microwaves, radar, X rays, and copy machines. Either move the cable or shield it from the source of interference.

Resolving Periodic Loss of Connection

To diagnose periodic loss of connection problems, you should identify whether the following conditions exist:
A network board in either the server or a workstation is faulty.

A user on the network is using an old NetWare shell file (for example, NETX.COM).

Two workstations have the same node number.

The cabling system is not terminated properly.

To resolve periodic loss of connection problems, you should perform the following actions.
Run NLIST to make sure all node numbers are unique. At a DOS workstation, type
NLIST USER /A <Enter>
Check all boot files. Make sure all users are using the latest version of the workstation software.

Check the cabling for improper termination, loose connections, and faulty components.

Use a LAN analyzer product to check the network boards, cables, and packets. (NetWare Care^{^TM} and LANalyzer� products are available from your Novell Authorized Reseller representative.) Replace faulty boards and cables.

Refer to your network hardware's documentation to review the cabling specifications for your cabling system. Make sure your system is in compliance with all the specifications.

Set the console to display all workstation connections cleared by the watchdog. (See "SET" in Utilities Reference of the NetWare 4.11 online documentation.)
If workstations are being cleared by the watchdog, check all network boards and the entire cabling system between the workstations and the server. Check for faulty cables, improper termination, and faulty hubs.
Resolving ARCnet- Specific Software Problems

To diagnose ARCnet-specific software problems, you should identify whether the following conditions exist:
The LAN driver being used is not specifically designed for the ARCnet* network board.

The LAN driver is outdated.

Receive buffer sizes conflict.

Node numbers are illegal or conflicting.

The monitor board settings conflict with the network board settings.

To resolve ARCnet-specific software problems, you should perform the following actions.
Load the LAN driver that matches the network board installed.

Contact the vendor for an updated version of the LAN driver.
Run NLIST. Make sure that all client workstation addresses are unique and that no station uses address 0. At a DOS workstation, type
NLIST USER /A <Enter>
If the monitor is blank when the network board is in the workstation, the monitor could be using interrupt 2. Try setting the network board to an option that does not use interrupt 2; then edit the NET.CFG file to reconfigure the workstation's IPXODI.COM file.
(See the hardware documentation for a list of supported options for your board.)
Resolving ARCnet-Specific Hardware Problems

To diagnose ARCnet-specific hardware problems, you should identify whether the following conditions exist:
The passive or active hubs are faulty.

The network boards are faulty.

Improper cable lengths are connected to passive or active hubs.

Two passive hubs are connected together.

A passive hub is terminated improperly.

To resolve ARCnet-specific hardware problems, you should perform the following actions.
Check the fuses in all active hubs. Replace faulty fuses.

If active hub lights blink, bad packets are being sent on the network. Check for conflicting node addresses, bad network boards, and improperly terminated passive hubs.

Check all passive hubs for proper termination.

Check the lengths of the cables connecting active and passive hubs to make sure they are within specifications. (See the hardware documentation to review the cabling specifications for your network board.)

Check the cabling system for loopbacks, such as a cable from an active hub that attaches back to the active hub rather than to a workstation. Make sure that two passive hubs are not cabled to each other.

Resolving Ethernet- Specific Software Problems

To diagnose Ethernet-specific software problems, you should identify whether the following conditions exist:
The workstation and the server are using two different Ethernet frame types.

The monitor board settings conflict with the network board settings.

To resolve Ethernet-specific software problems, you should perform the following actions.
Make sure that the server LAN drivers and the workstation LAN drivers have been configured for the same Ethernet frame type. (See "Frame" in Concepts of the NetWare 4.11 online documentation for information on frame types.) Configure the workstations for the appropriate frame type.
For instructions on configuring workstation LAN drivers, see "Basic Essentials" NetWare Client for DOS and Windows User Guide (NetWare 4.11 online documentation).

See " LOAD" in Utilities Reference of the NetWare 4.11 online documentation for the parameter you need to configure the Ethernet LAN driver in the IntranetWare Small Enterprise server.

Some VGA boards use interrupt 2. If the monitor is blank when the network board is installed, set the network board to an option that does not use interrupt 2; then edit the NET.CFG file to reconfigure the workstation software.
(See the appropriate hardware documentation for a list of supported options for your network board.)
For workstation LAN drivers or specialized software that set the node address for the client workstation's network board, run NLIST to make sure that each network board has a unique node number. At a DOS workstation, type
NLIST USER /A <Enter>
Resolving Ethernet-Specific Hardware Problems

To diagnose Ethernet-specific hardware problems, you should identify whether the following conditions exist:
T-connectors are not terminated properly.

The network board is set up for one type of cabling, but it is connected to a different type (such as thick Ethernet instead of thin Ethernet).

Hardware conflicts exist between the workstation and the network board.

To resolve Ethernet-specific hardware problems, you should perform the following actions.
Check for faulty termination. Each T-connector that has only one cable attached to it must be terminated. Each trunk must be terminated with a grounded terminator.

Check the network boards. Make sure that the board is set for the type of cabling (thick or thin Ethernet) you are using.

Check terminators with an ohmmeter for a resistance of 48 to 52 ohms. Replace any terminators that do not fall within the specified range.

Resolving Token Ring-Specific Software Problems

To diagnose token ring-specific software problems, you should identify whether the following conditions exist:
IBM LAN support has not been loaded at the workstations.

The LAN driver software is not loaded.

To resolve token ring-specific software problems, you should perform the following actions.
Check for duplicate client workstation addresses if you have used DOS ODI^{^TM} drivers or specialized software to set the node addresses.

Run DXMAID at each workstation, and set LAN Support to load automatically when the workstation is booted. The DXMAID program is on the IBM LAN Support Program diskette.

Resolving Token Ring-Specific Hardware Problems

To diagnose token ring-specific hardware problems, you should identify whether the following conditions exist:
A MAU (Multistation Access Unit) is faulty or has been set improperly.

A faulty token ring adapter has been installed in a workstation or server.

To resolve token ring-specific hardware problems, you should perform the following actions.
Reset the MAU.

Check the MAU for faulty fuses, power problems, and bad ports.

Check for faulty token ring adapters by running the DXMAID program found on the IBM LAN Support Program diskette.

Check for breaks in the daisy-chained MAUs.

Troubleshooting Workstations

This section provides troubleshooting suggestions for typical client (workstation) problems, including ways to resolve workstation memory problems. This section also lists common workstation error messages (the 900 series of messages).
Resolving Workstation Memory Problems

DOS Workstations

To free up DOS workstation memory temporarily (until you can add more memory to the workstation), do one or more of the following.
Unload any unneeded TSR (terminate-and-stay-resident) programs.

Optimize memory usage by loading DOS and other programs into high memory.
Modify the CONFIG.SYS file to reduce the number of files that can be open at the same time, the number of buffers allocated for disk drives, and the memory size allocated by the shell for the DOS environment (the /E option).
The following settings are sufficient for normal workstation operation, but the values can be reduced further until problems occur:
FILES=20
BUFFERS=20
SHELL=C:\COMMAND.COM /E:640 /P
Be sure to reboot the machine after modifying the CONFIG.SYS file.
OS/2 Workstations

Check the CONFIG.SYS file to see if there are any devices that can be unloaded; then try to load the driver again.
(For more information about the CONFIG.SYS file, see "Introduction in NetWare Client for OS/2 User Guide ( NetWare 4.11 online documentation).
Resolving Workstation Disk Space Problems

To resolve an insufficient disk space error, do one or both of the following:
Delete unnecessary files and directories from the volume.

Unload TSR (terminate-and-stay-resident) programs that have swap files on the hard disk.

Prior Index Next

This page is maintained by: Michael P. Harris

viking.delmar.edu
Last Updated: Sep 20 mpharris@surf.delmar.edu
Copyright © 1998