Not long ago, a man at one of the medical facilities that I manage decided to “clean up” the network wiring. He turned off all of the computers and disconnected every network cable from the hub. Then, he got rid of the slack in the cables, bundled them together, and plugged them back into the hub. Although this man wasn’t a technician, he had the foresight to mark the ends of each cable with the locations from which they came. After performing this chore, he turned on the server and a PC. Unfortunately, the PC was unable to connect to the server. That’s when he called me. Since this facility was 75 miles away, I tried to troubleshoot the problem over the phone. Using a step-by-step process, I was able to get the network up and running fairly quickly. Today, I’m going to outline the procedure that I used—in case you ever run into a similar problem.

The first thing that I needed to determine was whether or not the problem was isolated to a single PC. I had this person boot a couple of PCs and attempt to log in. If the other PCs could log in, then I would know that the problem was limited to the first PC that he had tried. On the other hand, if the other PCs couldn’t log in, then the problem would be the server’s connection to the hub. After booting the other PCs, we determined that none of them could log in.

One lesson that I’ve learned from my job is that, nine times out of ten, users will tell you what they think will keep them out of trouble rather than what’s actually going on. Therefore, even though this person claimed that he had everything plugged in correctly, I decided to check. After all, he had set out to clean up some cabling and probably hadn’t made any changes to the software.

First, however, I had him check the server console for error messages—just in case something unusual had happened. There were no errors, so I had him check for the presence of a green light on the network card. The green light was illuminated but not flashing, which led me to believe that there was an invalid or an incomplete connection.

Next, I had him write down which ports on the hub had illuminated connection lights. Then, I had him unplug the patch cable from the back of the server and recheck the hub to see if any lights had gone out. If he had accidentally plugged the server into another PC instead of the hub, then the green light would be illuminated, but no data would be flowing. This wasn’t the case, however. When he disconnected the server, one of the lights went out.

Then, I had him plug the server into a different port on the hub—just in case the port had gone bad. Suddenly, data began to flow, and the PCs were able to log in. This problem could have been due to a bad port, or it could have been caused by something as simple as a loose wire. Just to be safe, I talked him through the process of creating a new patch cable (which isn’t an easy feat over the phone). He plugged the new patch cable into the server and the hub, and the network started to work correctly.

Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it’s impossible for him to respond to every message. However, he does read them all.)

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.