Chapter 20: Nixing Network Problems

Even with the best planning and equipment, the networks of even the best network administrators crash from time to time. Spotting trouble before it happens is best, but knowing how to quickly remedy trouble after it happens can be a lifesaver. Because of today's heterogeneous networking environments, many things can go wrong. In this chapter, we discuss some common network problems and tell you how to solve them.

When Good Networks Go Bad

Believe us when we say that you'll know when something goes wrong on your network! Your pager beeps (or vibrates), your phones ring, and people stand in your doorway tapping their feet. To help you lessen the chance of network problems, you should learn the warning signs associated with network problems and add preventative measures to your network.

Because networks consist of so many resources, when the network goes down, so too could the Internet connection as well as the e-mail, fax, and printing service. Whoops, that sounds like the business could come to a crashing halt! That's right, a broken network can cause lots of problems for an organization.

What's healthy ? Creating a baseline

One way to monitor your network for trouble is to create a baseline report of what your network looks like on a day when it's healthy (that is, working properly). When you think the network is functioning poorly, you can compare snapshots of the network on a good day and a bad day. Some administrators like to take a baseline snapshot and then weekly snapshots.

You should monitor the network's memory, processor, logins, and utilization because these areas usually contain the warning signs that show up when something goes wrong. You can monitor these functions using the System Monitor tool that comes with Windows Server 2003. Choose Start Administrative Tools Performance, and the Performance window appears. You'll notice that it has two functions: one is System Monitor and the other is Performance Logs and Alerts.

In System Monitor, you can view real-time information or load information from a previous capture of data that you made.

In Performance Logs and Alerts, you can look at the various logs in textual format to examine each individual alert. It's not really plain-old ASCII format; it's still a graphical user interface (GUI), but the alerts are listed as line items that you can view or filter.

To add counters and objects, right-click the Counters button at the bottom of the System Monitor and choose Add Counters. (You can also click the Add button, which is the plus sign in the right pane.) The Add Counters dialog box appears, as shown in Figure 20-1. Your computer is selected by default as the one to be monitored , but you can monitor any computer in your domain. Next , you need to select the performance object that you want to measure, such as Processor (which is selected by default), Print Queue, or Paging File. When you select the performance object, the performance counters for that object are displayed. After you select the counter, you may need to select an instance when you have more than one object on your system. For example, if you have more than one hard drive on your computer, you can choose which one you want to monitor.

Figure 20-1: The Add Counters dialog box.

You can check the server, processor, and memory for issues such as the total number of logons, how many logons your system is experiencing per second, how much memory is being used, and how much of the available sever bandwidth is being used. If you don't understand a particular object or counter, you can click Explain for more information.

While you have the Add Counters dialog box on your screen, you can add as many performance counters as you want. As you add each counter, it takes on a color that appears on the graph and in the legend at the bottom of the chart. Continue to click Add and choose the counters for the object until you're finished, and then click Close. Figure 20-2 shows System Monitor in action after we added several counters and began monitoring. Notice the real-time lines (one-second intervals) on the graph.

Figure 20-2: A graph of System Monitor doing its thing.

You should establish a baseline when you first begin using Windows 2003. Then, set your alerts and counters to monitor performance during certain intervals of peak usage and other time frames . This allows you to analyze your network and server load after it's been used for a while. Make adjustments to your server and then look at the logs again to see whether the adjustments helped. For example, if you determined that more memory was needed in the server, add memory and then go back and view the logs again to make sure that this change improves performance. You may need to tweak some other setting besides the memory.

Tip 

Because you want to monitor your server on a regular basis, save the configuration settings (File Save As) and type a filename such as Perfset.msc. Then, each time you monitor the server, you can pull up your configured settings. If you save the settings to your desktop, Windows 2003 creates an icon for you that you can double-click the next time you want to monitor the server with these settings.

Documenting problems

We recommend that you grab a notebook and begin to document all network problems as they occur or immediately thereafter. You should record the symptoms, the items you changed to correct the problem, and the date and time. Documenting what you changed can give you a leg up if something else breaks that's related to a change you made. For example, you may need to give User A the permission to get to a spreadsheet application. Then, a week later, you notice that the master template file has been altered by that user and everyone on your network is complaining that their spreadsheet application has new defaults. You may have given that user too many rights.

You should include a drawing of your network (called a network map ) in this documentation. Seeing your network at-a-glance helps with troubleshooting efforts because you can look at the various segments and their information. See Chapter 5 for more information on network maps.

Tip 

If you have a computer room, you should lock the door and require visitors to sign a visitor log notebook even the person who comes to change the light bulb in the ceiling should sign in, because the ladder could bump into some wires in your computer room and bring a segment of your network down.

What we've seen in organizations that have several network administrators is that while one administrator works on one problem, another lets the maintenance person into the computer room. When something on the network goes down, network administrators start looking for the problem, but don't know that there was someone in the computer room. If you keep access to all your equipment as restricted as possible, know exactly who goes near that equipment, and log all changes, you stand a better chance of troubleshooting problems quickly.

If you have more than one network administrator and a problem occurs, gather everyone and ask these questions:

• Has anyone made any changes to the network today that don't appear on the log?

• Has anyone outside our group been inside the computer room?

Then, check your network change log to see whether any changes to the network over the past week could be related to the current problem.

30,000- foot view

When your network breaks, try to step back and look at it from a distance. Ignore the panic that sets in because it won't help you keep your wits about you. Divide your network into segments so you can analyze which parts of the network are broken. Is it just one workstation, one segment, one server, one application, or one service? After you begin to isolate the problem, you can start to correct it.

If this network is connected to a wide area network (WAN), you have more work to do. Someone could have made changes on the WAN that affect your network. If you're connected to a WAN, be sure to use unique naming and addressing schemes. If everyone names their Windows 2003 servers and domains the same (for example, Server1, Server2, Server3, and so on), things stop working well. For example, you can install a Windows Server 2003 in an isolated manner (not connected to any network) and then later connect it to a WAN. If no naming scheme is in place, other servers on the WAN may have the same names and addresses, which can really foul up the network.

In addition to using unique naming and addressing schemes, you need to build redundant paths or links in your WAN in case links go down. If you don't, you may find that remote offices are not available until the link is restored. Links can go down because of carrier problems or faulty equipment on your end. In some cases, you may want to disconnect your WAN connection to see whether the immediate problem goes away.

If you're using Active Directory Services and the directory isn't being administered properly, you may have some other LAN connected to yours via the WAN that's interfering with your network. Again, disconnect your WAN connection to see whether the problem goes away.

Tip 

Flowcharts can help diagnose problems because they force you to think in a logical pattern (if the flowchart is logical). Draw a flowchart of your troubleshooting technique and have it handy. Then, when trouble arises, you can look at your flowchart and make a quick determination.