Windows networks rely heavily on services such as WINS and DHCP, as you’ve no doubt discovered if you’ve ever had one of these services go down. Administrators often don’t devote enough energy to making sure critical services such as these have high availability measures in place. That’s unfortunate, especially since it’s easy and inexpensive to provide high availability for these services using the Windows Cluster Service.

When you have the clustering hardware in place, it makes sense to use it for both WINS and DHCP networking services. Both of these services are now “cluster-aware” in Windows 2000, which means they can successfully fail over to another server without loss of data.

Unfortunately, Microsoft didn’t extend the DNS service to be cluster-aware in Win2K, presumably because it assumed everybody would be running Active Directory. AD provides fault tolerance with integrated zones. You may be able to successfully cluster the DNS service using the generic Cluster Service resource—that’s up to you.


This article assumes a basic familiarity with the Windows 2000 Cluster Service. If you are new to the Cluster Service, take a look at these articles:

Clustering WINS
Most people seriously underestimate the importance of running a reliable WINS service on their Windows networks. I’ve lost count of the times I’ve been told, “We’re not using NetBIOS in our NT4 domain because we’re running DNS.” Within an Active Directory domain, it is possible to reduce the reliance on WINS or possibly even eliminate it. However, if you have any NT4 domains or any applications that rely on NetBIOS, WINS remains crucial because Windows computers use it to locate networking services.

For example, it is used to locate domain controllers, domain membership, browser services, and users—all by adding a suffix (a hex character) to the user-defined NetBIOS name. Thus, if your WINS service is not reliable, your networking services will also be unreliable.

Many networks include a number of WINS servers for fault tolerance as well as for reducing traffic and increasing lookup response times. But WINS wasn’t really optimally designed for a distributed database (unlike DNS) and despite carefully configuring replication to keep the database consistent, out of date information and corruption often occur.

Since a single WINS server can successfully cope with up to 10,000 clients (especially by using Burst Mode for peak times), you could reduce that risk by running as few WINS servers as possible. By all means, still use additional WINS servers for remote sites over low bandwidth. But for fault tolerance, consider clustering WINS rather than using a bunch of servers to provide high availability.

When clustering WINS, two servers are assigned to run WINS (although only one at a time) so that if one server dies, the other will take over. Because they share disk storage, only one database is being used, so there is no need to replicate this information. Consequently, data integrity is far less at risk. As with any clustered resource, however, clustering WINS doesn’t protect data storage. (Remember that the Cluster Service always assumes the data is good.) So you must also factor in hardware RAID and UPS for the shared external storage.

Configuring WINS for clustering
Configuring a clustered WINS service is pretty straightforward if you already know how to configure file shares and printers for clustering. The WINS service resource requires the following dependencies: Physical disk, IP Address, Network Name. You’ll need to specify two parameters: the location of the WINS database path and the location of the backup path. As with any clustered resource, you should specify an external disk, and both directories will be created for you. (The backup directory will be called wins_bak.) Note that these fields should end in a backslash, as shown in Figure A.

Figure A
Configuring a clustered WINS service

Clustering DHCP
DHCP is very important on most networks today, especially when used in conjunction with Win2K DNS. However, unlike either WINS or DNS, it doesn’t have the inherent ability to share or replicate its database. Each DHCP server acts in isolation, unaware of active leases, reservations, or address pools on other DHCP servers. As a result, running multiple DHCP servers entails the risk of overlapping addresses. And when a DHCP server is down or not responsive, a backup DHCP server can result in two IP addresses being leased to a single computer (with an unexpired lease on the original DHCP server).

Administrators use multiple DHCP servers for the same reason that they deploy multiple WINS servers—for fault tolerance and a fast response. But just as running multiple WINS servers increases risks and administrative overhead, so does using multiple DHCP servers.

The traditional advice for running two DHCP servers for fault tolerance is to use the 80/20 split scope. That is, split the available addresses between the two servers and, on each, configure a scope with 80 percent of the addresses you expect the server to offer. Then, create another scope with 20 percent of the available addresses you expect the other server to offer, so there is some overlap if the first server fails to respond.

Clustering the DHCP database is a more elegant way of offering fault tolerance than using this 80/20 split scope between two servers. With clustering, all available addresses can be configured in one database, and then one server can fail over to the other server if necessary. Of course, you can still use the 80/20 scope with another DHCP server (which could even have its own separate cluster) to increase fault tolerance and to incorporate network failures on remote subnets.

Configuring DHCP for clustering
The process of configuring DHCP for clustering is similar to the process of configuring the WINS service. The DHCP service resource requires the following dependencies: Physical Disk, IP Address, and Network Name.

As when configuring the WINS service resource, you’re prompted to supply the database location and backup location. You’re also asked for the DHCP audit file location. That may come as a surprise to some administrators who are not aware of this default log, which is normally configured on the Advanced tab of the DHCP service. It produces a CSV format file to record key events, such as when an IP address is leased, a rogue DHCP server is detected, a scope is depleted, and so on. Figure B shows these DHCP service parameter options.

Figure B
Configuring a clustered DHCP service

This article has covered the basics of clustering two key Windows networking services—WINS and DHCP. Although there are other ways to provide fault tolerance and high availability for these services, in most cases, the best and easiest way is to utilize the Win2K Cluster Service.