Five tips for faster remote network troubleshooting

Network troubleshooting can be a nightmare, since so many things can go wrong. Do you start at the client end or the server end? Is the problem a cable, connection, switch, router, or bad password? The possibilities seem limitless. Every network administrator knows a few tricks, but having a short list of tips to start from can make the tasks of network troubleshooting far easier.

Here are some ways network troubleshooting can be made faster and more standardized. I’ll focus on smaller clients, which make up the bulk of support customers. Since every network is different, not every trick will work every time. But taking a systematic approach should help you zero in on the problem.

1: Start with the client machine

When someone reports a network issue, the logical place to start is with his or her machine. I know this sounds like common sense, but I’m always surprised at how many administrators I know who immediately jump to the server when a problem is reported. The process can be made much easier if the first point of contact is the client machine. The first thing I always ask clients is whether they can access the outside world and/or the internal network. If they are unsure what I mean, I tell them to open up a Web browser and try to view Google.com. If they can see that, I ask them if the mapped drives they have on their machine can be accessed. The answers to these questions tell me exactly where I need to go first.

2: Narrow down the client problem

If the client’s machine can’t see the network, I try another client machine. If that second client machine can see the network, the problem is the first client machine. The next step is to make sure that machine is physically plugged into the network. If it is, I will try the wireless network (to rule out hardware issues) and/or reboot into Safe Mode (With Networking) to rule out infection. If nothing seems to be amiss on the client machine, I will bring in a laptop and plug it into their network drop to make sure it isn’t a jack or cabling issue. If the problem is isolated to a single client, and the problem is wireless, I’ll make sure the client’s machine has wireless turned on. Most laptops can turn off wireless to conserve battery power. I can’t tell you how many times this alone has been the issue.

3: Reboot switches and modems

The next step in chasing down the issue — while still avoiding the server — is to assume the problem could be a switch. If the client machine is in working condition, and a new machine can’t access the network from the client’s network drop, the issue is somewhere beyond the jack. So I check the switches, routers, and modems. This tends to work well for smaller clients on cable or DSL. This step is also handy when troubleshooting network issues over the phone. Instruct your client to reboot (or power cycle) the modem, router, and switch. Then, check connectivity again. If it still doesn’t work, have the client do it again but include a reboot of the computer (in case the issue is with DHCP). If that doesn’t work (after all else has failed), the problem is most likely with their provider. Either call the provider yourself or have the client call. If the provider reports all is fine, it’s time to dig a bit deeper.

4: Turn to the server

If no one in the company can access the LAN (as well as the WAN), the server will have to take focus. This is especially true if the server handles DHCP and/or DNS. Now the big issue is that you’re not on site, and your clients most likely don’t know their way around a server - so your task (as insurmountable as it might seem) is to have them be your eyes and fingers. First, have them log into the server, open up a browser, and try to hit Google.com. If they can’t, it’s time to dig into the server. If your clients are adept enough at following instructions, you can walk them through disabling and enabling a network interface (which will probably have to be done twice — once for the internal and once for the external network interfaces). After the network interfaces have been re-enabled, have them try to see the network from a desktop machine. If that doesn’t work, it’s time to get serious.

5: Reboot the server

This is the last ditch effort to get the network up and running before you have to arrange to be on site. Start by asking the client to make sure nobody is connected to the server. I would even go so far as to have all clients shut down their machines (if the company is small). Once you are sure everything is okay, remind the client the server will take anywhere from 15 to 30 minutes to reboot (unless the server is an Apple or Linux server). After the server has finally rebooted, have the client restart a single desktop machine and try again. At this point, if the client still can’t see the network, it’s time for you to fuel up the car and head over there.

Other suggestions?

No, it’s not a perfect outline that will get your client’s network back up and running in a matter of minutes. But these steps have helped make my remote network troubleshooting much easier. Do you have a favorite remote network troubleshooting tip? If so, share it with your fellow TechRepublic members.

Thanks & regards,

"Remember Me When You Raise Your Hand For Dua"
Raheel Ahmed Khan
System Engineer
send2raheel@engineer.com
sirraheel@gmail.com

http://raheel-mydreamz.blogspot.com/
http://raheeldreamz.wordpress.com/
http://www.facebook.com/pages/My-Dreamz-Rebiuld-our-nation/176215539101271   
http://www.facebook.com/pages/Beauty-of-islam/223983470988333?sk=wall              
http://www.facebook.com/pages/Health-is-wealth/289486761065829?sk=wall