Posted by arlene

After you’ve got a well-documented network, all you have to do is sit back and wait for problems to occur. Spurious as that may seem, it’s true. Sometime, some day, when you least expect it, something out of the blue will knock a server offline, disable a printer, and so on. If you have good documentation, you can tackle the problem and do so from a structured point of view.

The troubleshooting method known as the problem resolution cycle builds on accurate documentation for the network and uses a simple question/answer technique to determine what has changed to bring about the problem.

The Problem Resolution Cycle

The problem resolution cycle is a method designed to meet two needs: to solve the immediate problem that prevents the network (or a component of the network) from working, and to provide insights as to the cause of the problem so that it can be avoided or quickly solved in the future. The elements of a structured problem resolution cycle approach are as listed here:

• Accurate and complete descriptions of the symptoms. Determine whether a problem really exists, or whether the user is using the computer or application improperly.
• Understanding how the network functions from a logical and physical point of view.
• Solving the problem instead of creating a makeshift fix.
• Providing a follow-up mechanism for recording and distributing solutions to others who may have a need to know, such as staff at a help desk or a departmental supervisor.
• Development of a solution-tracking system to keep you from having to solve the same problem over and over again.

In most cases, the more data you can collect about a problem, the easier the problem will be to solve. When selecting employees who will serve as help-desk personnel, for example, try to get someone with both good verbal and good listening skills, not just someone with technical know-how. Although the initial problem report might be something like “I can’t print this document,” a good help-desk technician can usually walk the user through a series of questions to determine whether other symptoms are present. In the example just given, it would be prudent to ask whether the user can print other documents, or whether the problem is with just the one document. What about different types of documents?

If the user can print a spreadsheet but not a word processor document, the problem may be with the application. If the user can print a text document with a laser printer but not a document containing a lot of graphics, the printer might not have enough memory to hold the document. Another good question would be to ask whether any other users of the printer are having a problem. As you gather more data, you can focus your troubleshooting efforts on the local user PC or the printer. If the user can’t print anything but no one else is having a problem, you can begin to troubleshoot the printer configuration (has the user made changes you are unaware of?). Or perhaps the user has lost network connectivity and it’s a simple matter to try to ping the computer. You can use utilities such as ping or tracert to determine whether connectivity exists between the user and the printer or print server. After that, you could start investigating to be sure that the correct print driver is installed, and so on.

This brings up the network maps. You can quickly locate what hub, switch, or other network device the user’s computer is attached to by using a physical map of the network. Using a logical map, you can find other users or computers that make use of the same information flow through the network.

Sometimes things just fix themselves. For example, it may be that the user could not print because a router standing between the user and the printer was overloaded temporarily and was not able to route packets from the user’s network segment to the printer. In these situations, don’t let sleeping dogs lie. Instead, keep investigating (using your network maps) and try to determine what caused the problem. You can use performance and capacity reporting techniques for servers and network devices.

Find out what caused a problem so that you can anticipate when it might happen again, and try to take measures to prevent it.

Keep track of all incidents in an orderly fashion, and make the information known to others who might encounter the same problem. A help desk should have a log of some sort so that every problem called into the help desk is tracked from the time the call is placed until the problem is solved and the call is closed. Provide feedback to the user about how the problem was solved. This is especially important when you have problems that are self-induced, such as when users try to change the configuration of their computer although they know only enough to be dangerous to themselves!

Don’t repeat past mistakes. By tracking problems and recording the troubleshooting effort and the solution to the problem, you make it easier to solve the same, or similar, problems in the future. Your help desk should have a database of some sort (such as a spreadsheet, or perhaps a Web site with documentation linked via HTML code) that can be used to see whether a problem with similar symptoms has been called in before.

Is There Really a Problem?

Sometimes, as noted in the preceding section, problems just fix themselves. There are times when you can’t ever find the reason for a particular problem. In many cases, you’ll find that sporadic problems are caused not by equipment or software failure, but by users who are not using the system correctly. When any new application is deployed on a network, you need to be sure that the end users receive adequate training for using the application or else you may find that user errors begin to account for many of your help-desk calls. For example, a user may have corrupted files on a hard disk. Should you replace the disk? Should you search for a virus or another harmful program? These sound like logical things to do.

Or you could simply ask whether the user is properly shutting down the computer or just “power cycling” it when he gets stuck in an application and can’t find a way out. Some people find that just turning a computer off and back on again is a fine way to start anew, without realizing the problems they may encounter down the line. So, when troubleshooting, try to find out what has led up to the problem. It may be a simple case of user training that needs to be addressed.

I can’t stress enough the importance of training new users in the workings of the environment in which they will be placed. If you have configured a desktop in a certain manner, you can’t assume that a new employee will be able to make proper use of it. Although it’s easy to check someone’s résumé to determine what applications they are skilled at using, it’s difficult to be sure what the configuration of the application was at their previous place of employment. The same goes for training classes offered by temp agencies and other similar organizations. Although they may have used a standard installation for training purposes, any customizations or configuration changes you make need to be explained to the new user. So, as a general rule, no matter how qualified a new employee may appear to be, it’s just an appearance. You should have in place a structured training program and require each new employee to attend, or at least initiate a mentoring system so that one user can teach another.

Possibly related posts: (automatically generated)
Network Problem-Solving Techniques

• Network Problem-Solving Techniques continue…
• GUI principle: not to distract users
• Website Hosting Sever, some Pitfalls you need to avoid part 1
• Keeping Multiple Database Applications in Sync with Replication
• Anatomy of the Online Store
• Website Hosting Sever, some Pitfalls you need to avoid part 3
• Ten Scamps of a Data Warehousing Failure continue...
• Integrating "Shelf" Merchandising Techniques
• The Active Directory Schema
• Network and Servers Technical Compare continue...