Previous | Table of Contents | Next |
Lets go over the basic call-handling techniques that are applicable when youre not presented with a clear picture of whats going on. Assuming that that user is having unspecified application problems, how do you probe for more information? Dont forget to apply the SOAP theorygetting as many objective facts as possible about any type of trouble can only help you. Ask the user as many factual questions as you can. Here are some examples:
Asking about previous instances of the current problem is really important. Sometimes the history behind the problem will make the problem come into focus for you. For example, someone might tell you that the problem happens repeatedly at the same time every weeka major clue. Sometimes, the user might go so far as to tell you how the problem was fixed last time. A doctor friend of mine says that history is nine-tenths of diagnosis; hes not too far off.
This whole processparticularly if youre not at the workstation involvedcan be like groping in the dark. If you dont have a basis for your questioning, its hard to know which questions to ask. Sometimes, you simply have to go see it for yourself (particularly when the problem being reported is a local problem). Before you do, however, you might want to try to reproduce the problem from your desk.
For example, to rule out operator error, you can have the user at the other end of the line reboot the problem workstationsoup to nuts. Have the user power down and ask him or her to describe to you whats happening at each stage of the boot process. When its time to run the application, bring up the same application on your workstation, and have the user talk you through what he or she is doing to get the error; at the same time, you do the same thing on your end. This process can be tedious, and it takes a bit of practice, particularly if youre familiar with the application but the user is not (or vice versa).
A better option, particularly if its problematic for you to get across town to a users workstation, can be to invest in one of the many network remote control packages out there, such as one of the following:
These packages will allow you to watch exactly what the person at the other end is doing, which is really, really helpful. Sometimes you can simply correct what the user is doing. If you cant, though, at least youll realize whether he or she is reporting the problem correctly.
Of course, a network remote control program does you zero good if a workstation is not talking to the network, so you might want to brush up on your over-the-phone troubleshooting skills anyway.
If you think that the application is installed correctly and on a functional workstation but might possibly be the victim of a bad bit of network glue, you should perform some basic protocol troubleshooting steps to gather more data. I basically perform these measures as second nature, just so I dont assume I have the entire picture before I get this objective data.
This discussion is going to be in the context of a Windows PC, but these steps can be taken on any workstationyoull just use slightly different commands.
If youre using TCP/IP, youll follow steps that are similar to the ones in Hour 12, UNIX Networking Basics.
Step 1: Ping the Loopback Address
First, youll definitely need to identify your users PC as well as the resource he or she is trying to get to on your network map. Youll want to get to the users workstation and see if you can ping the loopback address (127.0.0.1).
As youve probably figured out by now, the loopback address isnt just a UNIX feature. Every station that has TCP/IP on it has a loopback address of 127.0.0.1. It serves the same function as the loopback plug I discussed in Hour 8, Hard Basics: Guide to Being a Hardware Geek. It allows the IP protocol program to talk to itself without involving any outside influence, such as the network card.Huh? Without the network card? How can you talk to anything without a network card? Trust me, you can. This is because the TCP/IP protocol (the stack) is its own program, and while it can and should talk to the network card, it can also talk to itself, as illustrated in Figure 17.1. This allows you to rule out the stack or the PC environment as the source of the trouble.
Figure 17.1 The TCP/IP stack of your computer can talk to itself, allowing you to rule out the PC environment as a source of trouble.
Step 2: Ping the Workstations IP Address
Next, ping the workstations IP address. If you dont know what it is, look at the output of the winipcfg command. (This command might tell you something else as well: Are you running out of leases on your DHCP scope? Is the DHCP server down?)
You might get a hardware error during either of these local pings, which means youve got a hardware problem. Youll need to run the network card diagnostics that came with your network card.
If you cant ping the workstations own IP address, perhaps the user ignored an error message when Windows started up, stating that a conflict existed with the IP address and Windows was going to disable the protocolmeaning no TCP/IP for you! Try rebooting and seeing if you get such a message. (See Hour 21, Tell Me About Your Network: Network Analyzers for tips on hunting down a duplicate IP address with a network analyzer.)
Previous | Table of Contents | Next |