Last week, a friend of mine encountered a little problem with his company’s DHCP server. Someone was apparently running a DHCP server on his company’s network, and it was conflicting with its DHCP server. The IT department was looking for a culprit, and my friend was the prime suspect.
Because the IT department believed that my friend could be causing the problem with the DHCP server, they had gone into his office and unplugged his Cobalt Qube and RaQ units. Unfortunately, they did this without asking my friend first. If they had, he could have told them that he didn’t have any DHCP servers activated in his office.
My friend caught up with the IT guy who had unplugged the units, who explained that the IT department had been trying to figure out what was wrong with the DHCP server for the past few days. They came to the conclusion that the problem had to be outside the server room. The IT guy asked my friend if he was running any servers in his office. My friend explained that he had been, but nothing had a DHCP server running.
In an effort to prove his innocence, my friend took the IT guy back to his office, plugged in the Qube and RaQ units once again, and booted up all three units. He explained to the IT guy that out of the two RaQ units and the Qube, only the Qube had the ability to actually run a DHCP server. The RaQ units were just Web servers. The only software that ran on these systems was essential for Web site hosting, which DHCP services have no part in at all.
The Cobalt Qube culprit
Once the RaQs were found innocent of any wrongdoing, attention was turned to the services running on the Qube. As it turned out, the DHCP service was running on the Qube, but it was not actually operating because no one had ever set it up before.
The IT guy still thought that the Qube might be the problem, so in order to prove once and for all that the Qube was not the troublemaker, my friend turned off the services. He also told the IT guy that the Qube had been running on the network since the first day he had received it—roughly two months earlier—and that if there were a problem with the Qube, it surely would have happened before now.
The IT guy countered by explaining that it was actually possible the problems were stemming from the Qube because the IT department had recently made a few modifications in the network. As a result, the Qube, which had been running on the network without problems for two months, could have started the DHCP problems after these recent changes to the network.
My friend agreed that this could have happened, and decided to take the Qube completely offline. After all, if it was the Qube that was causing problems, then by turning it off, the DHCP server should have been able to pick up where it needed to and assign IP addresses to the computers that were requesting them. However, this proved not to be the case.
The Qube wasn’t the problem on the network after all. After some careful research, the IT department discovered that my friend was not the only person running a server within the company offices. At first, they thought the problem could have occurred because my friend and another employee were each running their own servers on the network, but IT soon discovered that there were many servers in the building that were running DHCP.
The temporary solution
As a temporary fix until the IT department could get the DHCP server up and running once again, the Support technicians had to go to every computer at my friend’s company and assign each a static IP address.
Needless to say, with the few members of the Support department being pulled every which way to get IP addresses on machines, they became very stressed. Not only did they have to assign static IP addresses on this particular day, but sometime in the near future, they will have to go back to each machine and set them up to use the new DHCP server once it is up and running.
The question at hand
This problem brings up an interesting question that Support personnel must ask themselves: Is it worth the trouble to let your users run servers on your network? While it is true that some of these users know what they’re doing, what if these users caused a problem on the network and simply were not aware of it? We want to know what you think. Do you have a solution to problems such as these? Tell us about it! Feel free to leave a post below or send us a note with your thoughts.
Ed Engelking is a Web editor for the Support and NetAdmin Republics. In his spare time, he designs Web sites for small businesses and helps operate UCANweb.com, a company that he co-owns.