Previous Table of Contents Next Socializing a Solution: Basic Call-Handling Techniques Let's go over the basic call-handling techniques that are applicable when you're not presented with a clear picture of what's going on. Assuming that that user is having unspecified application problems, how do you probe for more information? Don't forget to apply the SOAP theory-getting 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: o What happened? o When? o During what? With what applications loaded? o What were you doing right before the problem? o Was idle time involved? o Has this happened before? How was it resolved? ______________________________________________________________ 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 week-a 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; he's not too far off. ______________________________________________________________ This whole process-particularly if you're not at the workstation involved-can be like groping in the dark. If you don't have a basis for your questioning, it's 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 workstation-soup to nuts. Have the user power down and ask him or her to describe to you what's happening at each stage of the boot process. When it's 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 you're familiar with the application but the user is not (or vice versa). A better option, particularly if it's problematic for you to get across town to a user's workstation, can be to invest in one of the many network remote control packages out there, such as one of the following: o PCAnywhere o ReachOut o RemotelyPossible o Novell Z.E.N. Works Remote Control o Microsoft SMS Remote Control 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 can't, though, at least you'll 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. ______________________________________________________________ Protocol Problems 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 don't 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 workstation-you'll just use slightly different commands. ______________________________________________________________ TCP/IP If you're using TCP/IP, you'll follow steps that are similar to the ones in Hour 12, "UNIX Networking Basics." Step 1: Ping the Loopback Address First, you'll definitely need to identify your user's PC as well as the resource he or she is trying to get to on your network map. You'll want to get to the user's workstation and see if you can ping the loopback address (127.0.0.1). ______________________________________________________________ As you've probably figured out by now, the loopback address isn't 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. ______________________________________________________________ [17-01t.jpg] 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 Workstation's IP Address Next, ping the workstation's IP address. If you don't 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 you've got a hardware problem. You'll need to run the network card diagnostics that came with your network card. ______________________________________________________________ If you can't ping the workstation's 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 protocol-meaning 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