How To Troubleshoot A Slow Network

If you are experiencing slow response times over your network, here is a checklist to help you find the source of your sluggish operating system.

1. Basic Server and Workstation housekeeping

Basic Server and Workstation housekeeping - the most important point!

• Scandisk
• Defrag
• Hard drive Cleanup
• HDD capacity (consider use of Compression)

The basics of periodic computer maintenance - we all forget them sometimes, but they can cause major headaches for Collect! and Collect! users. Please check these items regularly to avoid system issues due to an overloaded server. We have seen cases where the server hard drive was full!

2. Name resolution issues

Ways of resolving NetBIOS names and IP addresses are crucial to any network. If name resolution is handled slowly, (i.e. by broadcast), network response will be slow and database errors will occur in Collect!. These database errors will cause further network slowdowns, and the situation will spiral down, down and down.

The best way to handle this is to configure NetBIOS name resolution either through a WINS server, via DHCP or LMHOSTS.

Check name resolution from a command prompt:

Type nbtstat -r

"Names resolved by broadcast" should be 0. If it isn't, you have a name resolution issue. WINS and DHCP are network services which relate to this type of issue, as does the Lmhosts file. It is worth noting that NetBIOS name resolution is not configured by default on Windows2000 class servers, as the standard name resolution for this generation of server is DNS. Collect! needs NetBIOS name resolution.

Lmhosts is an easy way to set up name resolution when using WinNT/2000 operating systems. If you are using WinNT/2000, please see Lmhosts File Setup at the end of this document.

3. Any antivirus or other ram-resident programs or unneeded services installed and/or recently added?

What are they doing and when? How compatible are their settings with other processes on the system? Some TSR monitoring features can cause problems with other programs, and scheduled scans and updates can seriously slow down network performance. Scheduling scans for low traffic times (e.g. 3:00 am) can be helpful. Also, downloading virus definition file updates to a central network share and distributing them from there can reduce the network and Internet connection load dramatically. Picture the effect of half your staff deciding to run Norton Live Update simultaneously one morning because there has been a virus scare on the news that day!

4. Network browser issues

What computers does your network browser show?

You should see:

All computers physically connected to the network that are not powered down.

You should not see:

-- Only your own computer. This indicates a lack of connection
to the network.

-- Nothing, not even your own computer. This indicates a problem
with the network card and/or protocol. A system showing this symptom will fail the "ping localhost" test (see above).

5. Operating system licensing limit

Some server operating systems enforce licensing regulations more aggressively than others. Check your client access licensing status. The "magic numbers" for licensing problems are 5 and 10.

• 5 is the standard number of CALs shipping with an OEM server operating system
• 10 is the inbound connection limit for a workstation operating system (NT or 2000 Pro) being used as a server

6. Bad workstation test

• Get all users to sign out of Collect!
• Sign into the Collect! server from each workstation in turn, and test the speed of the connection with some demanding routines.

7. Network hardware - network cards, wiring, and hubs

NIC cards - card may fail ping localhost test, lights on back of NIC card may not be responsive, NIC may show error condition in device manager, or may not plug and play correctly after a reinstall. Or the card may look like it is working, and actually work once in a while, and still be unreliable. Network cards aren't worth fighting with - replace them.

Wiring - Category 5 cable can pass a cable test and still be bad. The only real test is if you can do your work correctly.

Here is something thing to try:

1. Choose a computer you suspect of being bad, shut it down and disconnect it from the network.

2. Move it to a different location, hook it up, log on to the network and test it.

3. Take another computer to the location of the original system - one
that seems reliable.

4. Hook it up, log on to the network and test it.

If the problem follows the computer, you have a problem with that machine. (i.e.. network card, etc.) If the problem stays with the location, you have a wiring or hub problem.

Hubs and switches - bad ports are not uncommon, and the smarter switches can have configuration issues of their own (e.g. DHCP server functionality).

8. Check the speed of a range of different network operations - not just Collect!

Specifically, what is slow? Collect! login, Collect! operating speed or all network operations? Batch processes and report generation/printing can cause network timeout issues with other users of Collect! This is particularly true if the printer or printer drivers are not handling the job in a speedy way. What looks like a slow network problem can turn out to be a batch-processing problem, a report design problem or even a printer problem.

9. New computers on network

New computer systems may have factory-installed operating systems, which may or may not be what you want for your network. Many systems now ship with WindowsME or XP Home Edition, pre-installed. WindowsME has been known to cause problems for some networked Collect! applications, and XP Home Edition is unable to join a domain, and is thus only useful for peer-to-peer networks. Even if the Operating System is not ME or XP, many factory installs tend to "over install" - load the system up with services, applications and peripherals not really needed in a business environment. Moving to a more stable and proven operating system would be a good decision. Collect! is quite happy on WindowsXP Professional, and doesn't require server services to run, unless you require more than 10 inbound connections to your Collect! application server.

10. New cards/peripherals added to computers

Even if the new equipment and its drivers are working perfectly, it is possible that they have been installed into an already-stressed system and have pushed it over the limit. Performance Monitoring should be frequent, especially on critical and highly stressed computers.

11. Any additional protocols on the network?

NetBEUI+TCP/IP will cause issues on some networks. It is possible for both NetBEUI and TCP/IP to attempt to pass NetBIOS commands at the same time, and this can be a major headache. We suggest you pick one, preferably TCP/IP, and then ensure that the other protocol is gone (REALLY gone, not just mostly gone!)

12. TCP/IP configuration check?

In addition to checking the local area connection properties and "Control Panel - System - Network Identification Dialogs," the command line utilities are a good way to get a snapshot of how network communications are functioning. (ipconfig /all, netstat -r, nbtstat -r, ping ip address/ping computer name)

13. Local and domain permission/membership issues?

This is a somewhat technical area, about which you should certainly consult your network technician, but it can be a plentiful source of access problems. If you have recently moved your network from Windows98 workstations, which couldn't join a domain, to WindowsXP workstations, which can't function properly without joining a domain, you should check this out.

14. Stressed server

If network and performance monitoring utilities indicate the server is at, or near, its limit, unexpected results can be seen. This can be true even if the stresses are occasional and temporary. Server resources which can cause operational problems include hard drives at or near capacity, paging file size, RAM, processor performance, CPU/power supply fans.

Lmhosts File Setup

On Windows 2000 operating systems, a sample Lmhosts file can be found in \WINNT\system32\drivers\etc. It is called lmhosts.sam and contains full instructions and examples of how to set one up. Normal practice is to create a copy of the lmhosts.sam, omitting the file extension and removing any file extension your text editor may try to put on. Then copy and edit an example line in your new file, adding a line for each computer on your network. Delete the comments and text at the head of the file. You will need an Lmhosts file for each computer. It is best to use the #include command to point the other Lmhosts file to a master Lmhosts file on a server. This will reduce administration, as otherwise you will need to change every Lmhosts file on every computer, every time you add, remove, rename, or change an IP address on any computer on your network - labor intensive! You will also need to enable "lmhosts lookup" on the local area network properties tab for WINS for each computer. These files also need to be updated whenever new computers are added, or old ones removed from the network. Lmhosts also doesn't work well if you use DHCP. If you have DHCP, it better to run DNS and WINS as well.

The www.microsoft.com system of web sites have a great deal of information on DHCP, WINS and DNS configuration and issue resolution. A good starting point is www.microsoft.com/technet.

See Also

- Introduction To Multi User Network Setup
- Basic Networking For Using Collect!