Service and Support

Introduction to Service and Support , and Chapter 1: Using a Systematic Troubleshooting Process

 

Objectives:

These notes will cover concepts in the Introduction chapter, and in Chapter 1. The objectives important to Chapter 1 are on page 1-1:

  1. Use the 6-Step Network Troubleshooting Model to Solve Problems
  2. Use System Diagnostic Software to Troubleshoot Problems
  3. Document Your Network to Avoid or Prepare for Recurrence

 

Concepts:

The circular diagram on page Intro-5 presents seven tasks that give you an overview of this course. An administrator of a network will need to be able to do these things (and more):

  • Configure hardware (like NICs, hard drives and controllers) and software (on servers and workstations)
  • Install any component of a network
  • Investigate problems, and determine if they are hardware or software related
  • Diagnose problems, once they are reported and investigated
  • Fix problems
  • Document problems, for the next occurrence
  • Upgrade hardware and software, to improve and support the network

ESD, or Electrostatic Discharge, can be a serious cause of problems. Some numbers are given on page Intro-6 about problems with static electricity:

  • A human can't feel a static discharge until it is 3,000 volts or more.
  • Normal motion like moving a chair or a foot can generate 1,000 volts.
  • Simply walking across a carpeted area can generate 1,500 to 35,000 volts.
  • Handling a plastic envelope can generate 600 to 7,000 volts.
  • Picking up a plastic bag can generate 1,200 to 20,000 volts.
  • Damage can be done to computer parts with 20 to 30 volts. The damage may not cause immediate failure.

A program to minimize ESD has the following benefits:

  • Less need for spare parts
  • Less downtime
  • Fewer intermittent problems
  • Fewer service calls
  • Fewer unhappy users

My first recommendation: get the computers off the floor!

Rules of Static Prevention

  1. Ground yourself when working on computers. Use a wrist strap, EXCEPT when working on monitors or power supplies. Test your grounds. Unplug computers, as some modern models pass current through the system when plugged in, even if they are turned off. (This tech I know tried to change sound cards while the new Dell was plugged in...)
  2. Do not touch electrical leads.
  3. Do not touch ungrounded people while working on components.
  4. Use static-shielding bags (gray or silver) not antistatic bags (pink or blue).
  5. Keep nonconductors, like styrofoam, away from components. They generate static. Silk ties are preferable to synthetic.
  6. Don't place components on metal surfaces.
  7. Increase humidity to 70 to 90 percent, to minimize static. This is a problem in air-conditioned areas. This is also a problem in that humans do not like this much humidity, and it could cause undesired condensation on the equipment. (Boss, it's raining in the server room...)

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.
Pages 1-3 and 1-4 explain the sub-steps to 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 inventory.
    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. Make a backup of data before changing anything. (It would be nice if you had one already.)
  4. Classic: shut everything off and reboot. This actually works quite often.
  5. 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.
  6. 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.
  7. Verify that the most recent Novell patches and versions are being used. (Novell will ask you to do this if you call for support.)

On page 1-5, the book continues steps of the model for troubleshooting:

  1. Gather Basic Information
    • What are the symptoms, and who is affected?
    • Is the network usage high at the time?
    • How is this different from baseline or normal performance? What changes have been made?
    • Check online resources for suggestions about the problem.
  2. Develop a Plan
    • 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.
    • 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.
  3. Execute the Plan
    • Break the hypothesis into small testable parts.
    • 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).
    • Use reliable test equipment, software and procedures.
    • Use the Novell Support Connection web site at http://support.novell.com as noted in Chapter 2.
  4. Ensure User Satisfaction Most systems do not consider a problem resolved until the user is satisfied. This may require educating the user about the problem and the solution.
  5. 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.

Several software applications are provided with your textbook. These are to help you become familiar with the concepts they use, and the book warns you of several things on page 1-10:

  • The text does not discuss the use of the software in detail. You will be expected to know the principles used.
  • The software provided with the text is probably not the latest version (and some are demos). You will be expected to know how to use NetWare, DOS, and Support Connection (Novell) software for certification.
  • Several other software packages are recommended that are not included with the book.

The use of Diagnostic Software is discussed on pages 1-11 and 1-12. Various products are available to diagnose servers, workstations and LANs. Some of the tasks you should be able to carry out with this kind of software are listed on page 1-12:

  • Determine facts about your hardware and OS.
  • Inventory the hardware in a computer.
  • Measure the performance of hardware.
  • Check for incompatibilities, like IRQs, I/O addresses and memory addresses already in use.
  • View and edit CMOS settings.
  • Determine what drivers are in use.
  • Diagnose failing components.

Documenting your network is broken into three types of documentation on pages 1-13 through 1-15:

  • The LAN - 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. accurate descriptions of workstations, including configuration and roles on the LAN
    5. records of changes made to the LAN
  • 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