Setting Your WINS Strategy

Many network administrators wrestle with how to employ effective Windows Internet Name Service (WINS) server strategies. Administrators typically ask questions about running WINS in small and large environments, determining an effective number of servers, using WINS with Novell NetWare clients, and securing WINS against unauthorized access. Before I get into the questions I see most frequently, let's review the history of name resolution and how we arrived at WINS. (If you can't wait to learn the answers, see "To WINS, or Not to WINS," for a few hints.)

A Brief History
Once upon a time, network administrators jumped through two hoops to perform name resolution on Microsoft-based, TCP/IP networks. The first hoop was Domain Name System (DNS)--not a big deal for UNIX savvy administrators familiar with HOSTS files and DNS namespace on the server. But maintaining static addresses and names for hundreds of nodes on many DNS servers causes network administrators to think twice. As a de facto standard for Internet naming, all networks used DNS. Properly configured, DNS lets TCP/IP-based applications communicate on the network.

The next hoop was to let Microsoft-based clients share files and printers. Beginning with LAN Manager, Microsoft built name resolution on NetBIOS. In NetBIOS networks, computers broadcast their local, unique NetBIOS name on the network--a fundamentally different approach compared to the connection-oriented nature of TCP/IP. In small, bridged environments, NetBIOS's performance was great in terms of network throughput (albeit with high bandwidth utilization).

However, as networks grew and TCP/IP forged ahead into large, segmented, routed networks, NetBIOS had to adapt. Because it is a broadcast protocol, you can't route it. So Microsoft gave us the LMHOSTS file, the NetBIOS equivalent of a TCP/IP local HOSTS file.

LMHOSTS maps NetBIOS names to IP addresses so that clients can share files and printers in routed networks. However, as with the HOSTS file, local administration on each workstation was a nightmare, if not impossible. Although LMHOSTS supported references to centralized files, it simply wasn't enough.

Jump ahead to Windows NT 3.5 and the introduction of WINS. It provides two important functions. It performs dynamic resolution of NetBIOS names to TCP/IP addresses, and it reduces name resolution broadcasts by setting up computers as H-nodes, which lets the computers directly reference the WINS server for name lookup. If WINS is unavailable or the name isn't in the database, WINS resorts to a broadcast. WINS and DNS effectively serve the same purpose. (For details on the difference between WINS and DNS, see Mark Minasi, "Name Resolvers: WINS vs. DNS," November 1996.)

Now you know what WINS does. Let's address administrators' concerns about how to employ WINS in today's environments.

Slim Environments
"I support a small 20-node network running NT and Windows 95. Do I need WINS?"

Organizations with small networks or branch offices previously avoided the complexity of TCP/IP administration. They selected easier-to-support protocols on local networks, such as NWLink and IPX/SPX. Now that Internet connectivity has become the norm, priorities have changed.

Yet, many administrators still mistakenly believe that only large TCP/IP networks need WINS. If your organization supports numerous small sites with minimal administrative or technical support, WINS makes sense. (Even from an administrative standpoint alone, WINS makes sense.)

When deploying NT networks in small locations or locations with minimal onsite support, consider employing WINS on the site's high-performance domain controllers. These machines offload overhead from dedicated high-user file servers.

However, sites using a single server for domain control and file and print sharing obviously need WINS on the primary file server. In these situations, WINS won't add much overhead because you have fewer workstations, and changes to IP addresses and name changes are probably minimal.

In addition to identifying the best WINS distribution on your site's servers, you must also decide the importance of WINS name resolution to that site. If the primary WINS server goes down or becomes unavailable, TCP/IP network communication can become difficult. Even machine browsing with the Network Neighborhood is difficult without WINS functioning in a pure, multisegmented TCP/IP network. You could simply define LMHOSTS files on each workstation to work around the downed WINS server, but that brings you back to onsite support issues.

For this reason, configuring WINS on at least two servers for each location is a good idea. Here's how to designate one server as the primary WINS server: In WINS Manager, click on the Server menu and then click Replication Partners. On the Replication Partners screen shown in Screen 1, enter the machine name and IP address of the secondary or backup WINS server. This configuration adds the backup server as a replication partner and lets both WINS servers exchange updates of their WINS databases.

In environments with numerous small sites connected by slow WAN links, placing a WINS server in each location minimizes name resolution traffic over the WAN. But as your environment grows and WINS traffic increases, you must monitor name resolution requests across the network and plan to consolidate WINS servers to locations that warrant increased name resolution services.

Too Much of a Good Thing
"My environment has two WINS servers for each group of 10 clients. Is this WINS strategy a solid approach?"

Sites with thousands of nodes in multiple, connected locations often have too many WINS servers. Effective WINS planning means maximizing the availability of WINS servers to clients, not maximizing the number of WINS servers. In addition, you need to be aware of the replication demands between each WINS replication partner. Based on an average of three database changes per hour on each WINS server, replication traffic can create a significant amount of network chatter, possibly up to 8 percent in an eight-hour day, according to a presentation by Microsoft's Wally Mead at Microsoft Tech-Ed 1997.

Effectively managing WINS in large environments entails three major steps:

1. Determine the effective number of required servers. Running more than two WINS servers for each 100 to 200 nodes probably overloads the system. This fact is especially true when all workstations connect in a single LAN. Keep in mind that several factors affect the capability of a single WINS server. These factors include server hardware, network link speed, and volatility of WINS database changes.

To determine whether you have the appropriate number of servers, use the NT Performance Monitor (Perfmon.exe) to track CPU utilization, bytes per second for the network interface, and queries per second for the WINS server. If any counter consistently reports high utilization, your environment may require additional WINS servers. However, if these counters indicate little to no activity, consider eliminating or relocating these underutilized WINS servers.