Checking the Network

Before assuming that the server is the cause of all network problems, it is worthwhile to perform checks to verify the sanity of the network. This is particularly important when all or a very large portion of server users are reporting a problem at the same time.

Use the following steps to verify the sanity of the network.

Step 1: Verify the Status of the Physical Network

The first item to check is the physical network. The majority of today's networking hardware provides status indicators that you can use to assess the state of the various network links (for example, 10-BASE-T Hubs use LEDs). Always check these links for any signs of problems with the physical network such as excessive re-transmissions, link Integrity mismatches, and jabber conditions.

Even in cases in which only a single client is affected, never assume that is it not a bad cable connection. For a single client it is easy to check to determine whether the problem occurs regardless of which server the client tries to use.

If a client cannot "see" anything on a network that is otherwise functioning without incident, then it is safe to assume that the problem is related to that client's network configuration. If however, that same client can see other nodes on the network but cannot connect to a particular server, then the network path to that server, the server itself, or the account being used by that client are likely candidates for trouble.

There are several third-party products available that you can use to monitor the health of the physical network. It is worthwhile to check network traffic periodically with one of these devices to see whether there are problems occurring with the physical network.

Step 2: Verify the Transport Protocol Status

If the physical network appears to be functioning properly, the next step is to determine whether the various computers on the network can "see" each other from the perspective of a transport protocol. Most transport protocol applications include a connectivity test tool that can be used to verify connectivity at the transport level between a client and the server over the network.

If you cannot reach a server machine from a particular client with the ping command, then neither will that client computer be able to connect to the server. If you cannot ping a server from several client computers, then one of the following conditions may be present: the server is not running, the transport protocol is not running, or there is a configuration problem that is disrupting network connectivity.

Review the recommendations in your transport protocol software documentation. If appropriate, continue with the procedures described later in this section on assessing the status of the NetBIOS protocol and SunLink Server software.

Step 3: Verify the NetBIOS Protocol Status

Check the NetBIOS protocol layer. Most NetBIOS modules provide test tools that test the connectivity between NetBIOS names over the network.

Connectivity between nodes using TCP/IP may be available, but if connectivity between NetBIOS names is not working then SunLink Server software will not work. All SunLink Server communications are based on NetBIOS name sessions. Use the test tools provided with your protocol software to verify NetBIOS level connectivity. If you find a problem, isolate it according to the information provided with the NetBIOS protocol documentation.

Step 4: Verify Solaris System Functionality

If all of the network connectivity modules check out properly, the next item to verify is the Solaris operating environment on the computer hosting the SunLink Server program. The operating system provides a variety of log files and system checks that can be performed to verify proper operation. For information on these checks, see your Solaris system administrator documentation.

SunLink Server software is particularly sensitive to the following system problems:

• Insufficient disk space in critical file systems such as root ( / ) or /var

• Insufficient system memory causing excessive swapping

• CPU bound conditions

• Unbalanced disk loads

• Improperly tuned kernel parameters such as maximum number of open files

Operating system problems usually will affect all or most client computers connected to the server. Do not spend much time on this step if you are troubleshooting an individual client problem.

Step 5: Isolating Problems on the SunLink Server System

If you determine that all of the underlying software is functioning properly, then you should check the SunLink Server system for problems. Problem isolation on the server often is dependent on the type of problem reported by the user community.

If only a single user is experiencing a problem, then you can narrow your focus quickly to the operations that this user is attempting to perform.

If a group of users is experiencing problems but many other users are not, then you should look for a common thread among the users with problems. For example:

• Are they on the same hub?

• Are they using the same applications or printers?

• Are they on the same lmx.srv process?

• Are they members of the same SunLink Server group?

If all users of a server are experiencing a problem, then you should start with more basic assessments of the state of the server. These are described in the following sections.

Is the Server Running?

It is worthwhile to verify that the server is actually running. You can do this easily by entering the following command at the system command prompt:

ps -ef | grep lmx

The system display should include the following (at a minimum):

root 3554 3452 Feb28 19:39 lmx.srv -s 1

root 3452 1 0 Feb28 5:03 lmx.ctrl

root 3568 1 0 Feb28 2:16 lmx.dmn

This display indicates that the three required server processes are in fact running, the daemon (lmx.dmn), the control process (lmx.ctrl) and at least one worker process (lmx.srv). You also may see other processes, such as lmx.browser and lmx.alerter.

Additional multiple worker processes, each with a unique number displayed at the end of the line, may be displayed. The server spawns new worker processes based on the number of clients supported by the server. As more client sessions are started, more lmx.srv processes may be started, each with a unique process ID and number. This is normal.

If the server is not running, use the net start server command at the command prompt.

Are All of the Server Services Running?

If one of the required server processes is not running, determine whether all of the server services started properly. A situation can occur when several server processes are running but you still cannot use the server because a particular service did not start. This is especially true for the Net Logon service. To check which services are running, enter the following command at the command prompt:

net start

The system displays a list of the services that currently are active on the server.

It is critical that the Net Logon and Server services are displayed. If they are not shown, then the server has a problem. Often the Net Logon service will not start because of a problem with the server name, domain name, or domain configuration.

Check the error logs for problems as described in the next section.

Are There Messages in the Error Logs?

Always check the error logs used by the server. You can view the system, security, and application logs from a client computer using Event Viewer, from the SunLink Server system using SunLink Server Manager, or at the system console using the elfread command. You also can view the logs in the PRINTLOG share area if there is a printing-related problem. For problems related to server startup, you can check the lmxstart.log located in the /var/opt/lanman/logs directory.

If there are entries in any of these logs, save them for future reference. Never discard or overwrite error messages since they may indicate the cause of the problem. These logs may have to be supplied to support personnel at a later date.

The following message is particularly indicative of a server problem:

A server process has unexpectedly terminated

This message indicates that a server process has encountered an unexpected error. Depending on how your server is configured, there may be a core file located on your system.

If the value of the CoreOk keyword is set to 1 (yes) in the SunLink Server Registry, then a core file is located somewhere on the system. The CoreOk value is in the following key:

SYSTEM\CurrentControlSet\Services\ AdvancedServer\ProcessParameters

Go to the root directory, and execute the following command to search the file system for core files:

find . -name "core*" -print

Save any files that you may find. If the coreok parameter is set to no, then core files will not be created. You may want to set the CoreOk keyword to yes in order to capture core files, which are useful for debugging purposes.

Are All of the Server Resources Properly Shared?

Some server resources are shared automatically every time the server is started. These resources are used in the background by clients while performing other server activities.

The list of resources shared by default includes:

ADMIN$

C$

D$

IPC$

LIB

NETLOGON

PRINTLOG

PRINT$

USERS

The resources followed by a dollar sign ($) are special resources required for server administration and communication. (An additional special resource -- REPL$ -- is available when the Directory Replicator service is running.)

Never attempt to delete or re-share these resources. If any of these resources are absent, the server will not function properly. If you detect that one of these resources is missing, stop and restart the server to determine whether they are shared at server startup. If they are not displayed, contact your service representative.

The remaining resources are default resources typically used by clients during logon (NETLOGON), to connect to home directories (USERS), and to access utilities or error logs (DOSUTIL, OS2UTIL, PRINTLOG). These items may be deliberately absent from your server. However, if you did not unshare them, then a problem with the server caused them to be removed.

Can the Server Be Contacted From the Console?

You can conduct a simple test to determine whether the server is communicating over the network. Issue the following command at the system console.

net view

The system displays the name of the server and other servers operating in the same domain. If your server name is displayed, execute the same command, adding the server name:

net view \\asutrial

The system displays a list of shared resources similar to the following:

Shared resources at \\asutrial

SunLink Server Systems

Sharename Type Used as Comment

----------------------------------------------------------------

DOSUTIL Disk DOS Utilities

LIB Disk Programming Aids

NETLOGON Disk Logon Scripts Directory

OS2UTIL Disk OS/2 Utilities

PRINTLOG Disk LP Printer Messages

USERS Disk User Directory

Other entries may be displayed if you added shared resources to your server.

If either of these commands fails consistently, then there is a problem with broadcast communications over the network. If these commands succeed, you can use the tests in the next section.

Is the Server Supporting a Maximum Number of Users?

When a connectivity problem occurs, ensure that your server has not exceeded the maximum number of clients that it is configured to support. This number is indicated by the maxclients parameter in the server lanman.ini file. It can be displayed using the srvconfig - g maxclients command.

Has the SunLink Server Registry Been Corrupted?

Execute the regcheck -C command to determine whether the internal format of the Registry file has been corrupted. If this command detects corruption, execute the regcheck -R command to repair the Registry file.

If invalid values have been entered in the SunLink Server Registry, then you can use the regload command to reinitialize all Registry values to their defaults.

Can the Server Be Contacted From a Client?

Attempt to log on to the server from a client computer. If the logon is successful, link a virtual drive ID to a shared resource. Then, view the contents of the linked drive.

If you have problems with these steps, isolate each problem using the following procedure.