Recently, I ran into an interesting network problem. As with most network problems, logic prevailed when it came to finding a solution. However, the problem was one that the designer of the network never anticipated.
The network that was experiencing the problem started out as three separate networks. Each of these networks was a closed LAN with no Internet or other wide-area connections. Each network consisted of one domain. These networks each contained about 50 workstations and were located on different floors of the same building. All three networks had been in place for quite some time and had worked flawlessly for several years.
One day, the network administrator received a request to tie the networks together. This seemed easy enough at first glance. He simply connected some of the hubs together via a CAT 5 cable and then established trust relationships between the various domains. That’s when the trouble began.
For the most part, the network seemed to be functioning correctly. Users could log into their home domain. Once logged in, they had no problems accessing resources from the other two domains. The problem was that every now and then, the user would receive a message stating that no domain controller could be located for the domain that the user tried to log into. The strange part was that the problem seemed completely random. It wasn’t limited to any particular group of PCs or user accounts.
The network administrator called me and asked if I could take a look at the problem. It didn’t take us long to find a PC that was having the problem. The first thing that I wanted to check was communications. I began by pressing [Esc] to bypass the login screen. I then went to the Network applet under the Control Panel. The machine had a very simple configuration. It was using Client for Microsoft Networks over TCP/IP. A closer inspection revealed that TCP/IP was set up to use DHCP (Dynamic Host Configuration Protocol). After seeing that, I ran the Winipcfg program to test DHCP functionality. Apparently DHCP was functioning, because the PC had an IP address.
Puzzled, I tried pinging the primary domain controller by IP address. The ping came back good. Next, I tried pinging the primary domain controller by computer name. This time the ping failed. A closer look at the Winipcfg utility revealed that the DHCP server was assigning the PC a WINS (Windows Internet Naming Service) server to use for name resolution.
Just as I was about to test to see whether WINS was working, it hit me. The network was made up of three separate networks at one time. Each of these networks had its own DHCP server. The DHCP server assigned the IP address to each PC but also assigned a WINS server to use for name resolution. The problem was occurring because three separate DHCP servers were assigning IP addresses and referencing three separate WINS servers. None of these WINS servers had any knowledge of the others. If a PC received its IP configuration from any DHCP server other than the one it was originally intended to use, the DHCP server would assign the PC to use a WINS server that wasn’t aware of the existence of any domain controllers on the network that the user was trying to log into.
The solution was simple. All the administrator had to do was make each WINS server aware of the other two WINS servers. Once the WINS servers could exchange information, the problem went away.
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.