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
- 01/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.
About the Author
Mark England, MCSE, MCT, MCNE, is a principal technology consultant with HP Services, Microsoft Infrastructure Practice, where he specializes in Windows and Exchange. He is a regular contributing author for Microsoft Certified Magazine, a presenter at MEC, as well as an evening instructor in Sacramento.