• Choose a category
• All
• Classic-Fiction

PC points by default to a printer other than the one that the user thinks should print.

That’s about it. Maybe the parallel port configuration is wrong in CMOS or the USB drivers aren’t correct, but still.… Now do the same thing with a networked situation where a user can’t print. Here are the obvious extra issues, because all of the local machine issues apply as well:

Print server is down.

Printer is locked by another user.

The client PC doesn’t have network connectivity.

The NIC driver is bad or incorrect.

The client PC doesn’t have the proper printer drivers installed for the networked printer.

The cable between the client PC’s NIC and the nearest switch is bad.

The port to which the cable connects is bad.

The switch failed.

Somebody in an office down the hall spilled coffee on the printer, inside the mechanism, and then didn’t fess up to the accident.

That’s a lot of variables, and they just scratch the surface of possibilities. You live in a networked world—it’s time to elevate your troubleshooting skills and methodologies to the next level. This section offers a series of steps you can use when performing any type of PC or network troubleshooting. You’ll look at ways to apply your tech skills and general communication skills to get to the bottom of a problem and get that problem fixed.

Verify the Symptom

The one thing that all PC problems have in common is a symptom. If something odd wasn’t happening (or not happening) to users as they tried to do whatever they need to do on their computers, you wouldn’t have a problem at all, would you? Unfortunately, the vast majority of users out there aren’t CompTIA A+ certified technicians. As a tech, you need to overcome a rather nasty communication gap before you can begin to consider a fix. Let’s bridge that gap right now.

* * *

EXAM TIP Look for lots of questions on communication with users on the Essentials exam.

It usually starts with a phone call:

You: “Tech Support, this is Mike. How can I help you?”

User: “Uh, hi, Mike. This is Tom over in Accounting. I can’t get into the network. Can you help me?”

Tom just started over in the Accounting department this week and has been a pain in the rear end so far. Ah, the things you might want to say to this person: “No. I only help non-pain-in-the-rear accountants.” Or how about this? “Let me check my appointment schedule.… Ah, yes. I can check on your problem in two weeks. Monday at 4:00 P.M. okay for you?”

But, of course, you had the audacity to choose the beloved profession of IT tech support, so you don’t get to ask the questions you want to ask. Rather, you need to take a position of leadership and get to the bottom of the problem, and that means understanding the symptom. Take a deep breath, smile, and get to work. You have two issues to deal with at this point. First, if you’re working with a user, you must try to get the user to describe the symptom. Second, whether you’re working on a system alone or you’re talking to a user on the telephone, you must verify that the symptom is legitimate.

Getting a user to describe a symptom is often a challenge. Users are not techs and as a result their perception of the PC is very different than yours. But on the same token, most users know a bit about PCs and you want to take advantage of a user’s skill and experience whenever you can. A personal example of verifying the symptom: Once I got a call from a user telling me that his “screen was blank.” I told him to restart his system. To which he responded, “Shouldn’t I shut down the PC first?” I said: “I thought you just told me the screen was blank!” He replied: “That’s right. There’s nothing on the screen but my desktop.”

When Did It Happen?

Once you know the symptom, you need to try to inspect the problem yourself. This doesn’t mean you need to go to the system; many real problems are easily fixed by the user, under your supervision. But you must understand when the problem occurs so that you can zero in on where to look for the solution. Does it happen at boot?