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. Prerequisites
This article assumes a basic familiarity with the Windows 2000 Cluster Service. 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