Novell Network Management: NetWare 6

Chapter 1: Use a Systematic Troubleshooting Process

 

Objectives:

The objectives important to Chapter 1 are on page 1-1:

  1. Use the 6-Step Network Troubleshooting Model to Solve Problems
  2. Prepare for Network Problem Recurrence
  3. Document Your Network

Concepts:
Use the 6-Step Network Troubleshooting Model to Solve Problems

In the same sense that some programmers have never used a systematic, disciplined approach to creating software, some technicians have never learned or used a systematic, disciplined approach to troubleshooting problems. Like the programmer who writes without a plan, the technician troubleshooting without a plan runs the risk of getting lost, overlooking details, or simply doing a bad job due to poor procedure. Without a plan, you can still fix problems, but it is not efficient, it is not recommended, and it will not help you pass the test for this class.

Even with a plan, you need something that a previous version of the book referred to as "part science and part art". You can't have a feeling for troubleshooting a system you do not understand. That is why this is the last class in your rotation. If you have not understood the other Novell classes, review the books for them and come back to this one. (My notes are still on this site. Click for a while and come back...)

So, assume a user has called you with a problem. The book gives you a six step model for troubleshooting.

  • Try a Quick Fix
  • Gather Basic Information
  • Develop a Plan
  • Execute the Plan
  • Ensure User Satisfaction
  • Document the Solution

You need to know the steps of this model, including their sub-steps.
Step 1: Trying a Quick Fix:

  1. Eliminate user error. This is broken down into three possibilities:
    1. The user did something wrong. (Don't laugh, it happens a lot, especially before the users are trained.)
    2. The user did nothing wrong, but does not understand the system, so he/she expects something other than what happened. (This happens after the users are trained, but before they are experienced.)
    3. There is actually a problem. (After your users are experienced, this happens more often.)
  2. Check the hardware components.
    1. Are parts missing? ("What's a drop cable?")
    2. Are all parts correct? ("But that cable works for my phone...")
    3. Are all parts correctly connected? ("What's a network jack?")
  3. Simplify the problem. Remove programs and hardware that are not necessary. Replace programs and hardware items, one at a time, to test the point of failure. This is less practical than it seems. It works best if the user is using some unapproved software from home that can be uninstalled and sent back home. If troubleshooting a server, remove NLMs one at a time.
  4. Suspect a rights problem. If a user can run some applications and not others, they may not have rights to the applications or the data directories.
  5. Verify that the most recent Novell patches and versions are being used. (Novell will ask you to do this if you call for support.)

Step 2: Gather Basic Information

    1. What are the symptoms, and who is affected?
    2. Is the network usage high at the time?
    3. How is this different from baseline or normal performance? What changes have been made?
    4. Check online resources for suggestions about the problem. Examples are user groups and online forums.

Step 3: Develop a Plan

    1. Decide where the problem is likely to be and focus on one area at a time: user, application, operating system, equipment. Develop a hypothesis for each likely cause.
    2. Use Novell's Prioritization rules.
      • First prioritize your hypotheses by their probability of being the actual cause of the problem.
      • If each will take an equal amount of time to test, test the most probable cause first, then the second most probable, and so on.
      • However, they will never take an equal amount of time to test in the real world. In reality, some causes can be tested very quickly. Test quick fixes first, out of probability order.

Step 4: Execute the Plan

    1. Break the hypothesis into small testable parts.
    2. Test one part at a time. Make one change, test, and repeat.
      • Use either forward chaining (moving from source to target),
      • backward chaining (moving from target to source), or
      • binary chaining (starting halfway between the target and the source, determining which side the problem is on, moving to a halfway point on that side, and continuing by half the distance each time).
    3. Use reliable test equipment, software and procedures.
    4. Consult people you know to check your ideas. Another set of eyes may see something you missed.
    5. Test each hypothesis in turn, until you find an answer.
    6. Use the Novell Support Connection web site at http://support.novell.com as noted in Chapter 2, for more ideas.

Step 5: Ensure User Satisfaction

Most respected processes do not consider a problem resolved until the user is satisfied. This may require educating the user about the problem and the solution. Practice customer service skills.

Step 6: Document the Solution

    1. Record the problem and the solution for next time, for other staff, for posterity, etc.
    2. Take steps to avoid the problem or make the solution easier next time.
Prepare for Network Problem Recurrence

The text offers five areas of advice.

  1. Be Proactive - This means to look for problems that will happen again, and prevent them or prepare for them. If you know a printer runs out of toner often, keep more on hand. If a device runs hot, install better cooling for it. Don't wait for the next problem to do something about it.
  2. Check Network Health - Measure the network performance with diagnostic tools. This includes running virus scans, and keeping your antivirus products updated.
  3. Test the Network - Introduce new equipment, turn off equipment, disconnect devices, and produce other controlled errors to see how the network will react. Record what you do, and what the results are. Be careful not to cause down time for your users.
  4. Map your Network - Networks can grow rapidly or bit by bit. Maintain a map of your wiring, your users, your printers, and other network resources.
  5. Keep Vendor Documentation - Administrator manuals, downloaded technical information, security advisories, and other documents should be kept for reference.
Document Your Network

Documenting your network is broken into three types of documentation:

  • Components of the Network - this includes five sorts of information
    1. a map of users and equipment
    2. a list of all parts and software used
    3. diagrams of the cables used
    4. records of changes made to the network
    5. accurate descriptions of workstations, including configuration and roles on the network
  • History - four types of information
    1. How does the company use the LAN?
    2. Who are the users, what are their needs and how have they been trained?
    3. Log of past problems and solutions. This is the most critical part for troubleshooting.
    4. Baseline. What is normal for this network?
  • Resources - who can you turn to?
    1. Documentation on hand
    2. Technical support people, vendors, web sites