Workshop

• PCAnywhere
• ReachOut
• RemotelyPossible
• Novell Z.E.N. Works Remote Control
• 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.
TCP/IP
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.
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.