In-Depth

An Ounce of Prevention

When setting up a network, forgetting the concepts of scalability and centralized management can have costly consequences down the road.

• By Mark England
• January 01, 2002

You may manage a small network with just a few servers and a few dozen users. But what happens if (and, hopefully, when) that network expands, jellyfish-like, throwing out new tentacles here, there and everywhere? You could kluge together a solution, watching your administrative and scalability problems expand as the network does, or you could prepare to have a big network even while your network is small, minimizing potential hassles down the road. Even with a small network, you should start with engineering drawings that document the design and provide for scalability.

Growth Spurt
Implementation of Windows Internet Name Service (WINS) and Dynamic Host Configuration Protocol (DHCP) is a perfect example of how thinking small can lead to big headaches. Last year, one of my clients grew from six workstations and one server to 19 workstations, not even counting the dozen or so remote laptop remote access service (RAS) users. At the time, I suggested that both WINS and DHCP be implemented. The powers that be decided against it, for two reasons: First, they felt the company was “too small” and, secondly, that both WINS and DHCP take up too much bandwidth (which is a popular myth). WINS and DHCP can be installed on most any server (member server preferred) and takes up very little server resources and network bandwidth. Switching to WINS eliminates workstations from broadcasting on the segment for network resources. The client felt that, with such a small number of users and only two network segments, why install more services when it could do the same job with a simple batch file and Excel worksheet?

After a few months, the client called and wanted to talk about several things, including some name-resolution problems and a growing infrastructure. The name-resolution problem was called the “ghost problem,” because it was extremely hard to reproduce and, of course, only happened when there were deadlines to meet.

At the same time, the company expanded significantly. The number of BackOffice servers for development and testing shot up to 32, along with three more NT domains, six segments between new buildings and 100 or so users, plus the remote laptop RAS users. The client’s solution to replace WINS was the standard LMHOST batch-file routine most of us have used at one time or another. It did a good job of automating the LMHOST file for the most part. The master LMHOST file was stored locally on one of the administrator’s workstations, instead of a server. At 2 a.m. each day, an AT command would run a batch file that copied the LMHOST file to all servers, including the import directory of the PDC. Each time a user logged on, the login script would copy the LMHOST file down to the user’s local workstation or laptop (if connected to the network). This worked as long as the workstation with the master LMHOST file was turned on. Many times, however, the master workstation would be off and the update for that night wouldn’t be distributed. This caused many problems the next day when users were unable to connect to network resources. Because the company wasn’t running DHCP, it maintained a spreadsheet and manually updated it each time an IP address was used, changed or deleted—or at least it was supposed to. Many times, one of the administrators wouldn’t update the spreadsheet, causing duplicate IP addresses later on.

A Failure to Communicate
The ghost problem turned out to be a simple resolution problem: NetBIOS names weren’t being resolved to IP addresses, and PREDOM statements in the LMHOST file were incorrect. The problem was intermittent because multiple administrators were updating the master file, sometimes at the same time. To save time, an administrator would map a drive to the master workstation and update the master LMHOST file while another administrator simultaneously had the file displayed on their workstation. Thus, the last person to click “save” would overwrite any updates from the other administrator. This was causing BackOffice applications to have problems, especially during the nightly maintenance procedures. The client felt the best way to fix this was to modify all the batch files and other procedures to use hard-coded IP addresses, rather than NetBIOS names. The other workaround was to publish the IP spreadsheet via the NetLogon share. Users were told to use IP addresses to map drives rather than using simple NetBIOS names. Asking users to use IP addresses instead of friendly names is begging for trouble; after all, users want their lives to be easy and the computer should aid in that. When you walk around and notice lists of IP addresses taped on monitors, it’s a warning signal that something isn’t right. You can start to see how much work was being done to avoid using DHCP and WINS.

The Pound of Cure
Using the company’s current design and IP-management techniques to expand into another building and adding more segments and more routers was going to be a lot harder than necessary, as the company had persisted in its “small network” mindset.

It was time to start thinking big. Given the problems the client was facing now (and would face later doing things the old way), it wasn’t hard to sell the benefits of WINS and DHCP. The point was driven home after I demonstrated on a white board how much time and energy the client would spend trying to not roll out WINS and DHCP.

The time had come to re-engineer the network infrastructure and how the client managed not only its NetBIOS devices, but also its Unix systems. We updated the current network engineering drawings by adding a WINS and DHCP server. One of the inside DNS servers was a new PIII server with 256MB RAM, so we decided to install the WINS and DHCP services on that server. A secondary WINS server would also be installed on the secondary inside DNS server for fault tolerance.

With updated engineering drawings and a detailed plan in hand, we scheduled the changes for the next weekend. The WINS and DHCP installs went perfectly. Servers were onfigured as WINS clients. The DHCP scopes were created to handle the assignment of IP addresses for each segment. Routers were configured to pass DHCP requests to the DHCP server. The next task was to delete the AT command and batch file that was copying the LMHOST file around the network. This was done by updating the login script to not only remove the copy of the LMHOST file down to each workstation, but also delete the LMHOST file on each workstation. The final step was to reconfigure the workstations and laptops to pull an IP address from DHCP. The conversion to WINS and DHCP went off without any problems.

Failing to Plan…
Although this story had a happy ending, it’s amazing how much work, time, money and troubleshooting could have been saved by considering future expansion from the beginning. If my client had installed WINS and DHCP as part of its network infrastructure from the start, hundreds of hours could have been saved. It’s vital to create a solid infrastructure when designing a network—be it NT 4.0 or Windows 2000. Keep the concepts of scalability and centralized management in mind when designing a network, and you’ll have a smoother transition when that network goes from little to big.