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.
2. Determine geographical placement of the servers. Having multiple WINS servers on a single segment does not result in a huge boost to name resolution performance. WINS really shines in its ability to better service requests across routed segments, especially in a WAN environment. To minimize your dependency on slow WAN links for name resolution traffic, you can locate WINS servers in strategic geographical locations. For example, in a multitiered network, your servers may reside on routed segments for the Northeast. Localizing WINS servers on the Northeast segments aids name resolution and reduces the need for WINS servers defined for other regions to resolve names. Also, to increase performance, you will want to place WINS servers on segments with high broadcast traffic. This strategy facilitates regional name resolution without WINS traffic traversing an excessive number of network segments.
3. Control replication intervals. Three settings manage WINS replication traffic: Update Count, Replication Interval, and Start Time. The Update Count determines the number of record updates that must occur in the WINS database before the WINS server notifies its partners that replication updates exist. Depending on the volatility of name changes in your environment, increasing the Update Count reduces the number of replication notifications that the server sends. (However, name resolution failures may occur because WINS name changes will take longer to reach partner WINS servers.)
Here's how to increase the Update Count: In WINS Manager, click the Options/Preferences menu and then click Partners. When you see the Preferences screen shown in Screen 2, click Update Count.
Instead of increasing the Update Count, you can simply increase the Replication Interval. WINS sets the default Replication Interval to every 30 minutes. This means that once WINS notifies replication partners that updated records exist, partners pull replication records in 30 minutes. You need to adjust this value consistently across all WINS replication partners, and you need to control the time of day when replication events occur.
If your environment must increase its Replication Interval, time the updates to occur during off-hours--especially with WINS servers across WAN links. To set the Replication Interval, click Replication Interval on the Preferences screen and enter an interval in the HH:MM:SS format.
In large environments, administrators often configure WINS servers in a multitier hierarchy. You may need to configure Replication Intervals so that changes cascade to partner WINS servers appropriately. In other words, you want to ensure that WINS replicates record updates from server A to server B and then from server B to server C, etc.
Mixed Environments
"Our network consists of NT application servers with mostly NetWare
clients. How can I set up WINS?"
Mixed networking environments are today's norm. Yet many such environments don't necessarily warrant the use of WINS. For example, one of my customers only recently began to upgrade 400 workstations from Windows 3.11/NetWare 3.x to Win95. In this environment, the company deployed NT servers for SQL database applications, but NetWare 3.x and 4.x. systems were the primary file-and-print networks. Except for a handful of NT clients, all the client workstations ran Windows 3.11 with a 16-bit Novell client stack, so WINS servers did not benefit this company. The Novell client implemented both a 16-bit IPX and TCP/IP stack, so NetBIOS name resolution wasn't a factor or requirement.
Other environments also use NetBIOS-dependent transports. Such environments include IBM LAN Manager or Digital Equipment Pathworks. Client workstations that can't recognize WINS servers directly can still take advantage of WINS dynamic name resolution, using WINS proxy agents. A proxy agent can be any NT or Win95 client workstation configured to access a given WINS server.
Proxy agents accept broadcasts from non-Microsoft clients and forward the requests to the WINS server. Rather than maintain a WINS database, you can use a proxy agent that essentially gives the B-node client access to its local name cache for a given period. If you want to use proxy agents, clients must comply with Request for Comments (RFC) 1001 and RFC 1002 and conduct B-node (broadcast) resolution.
WINS proxy agents are also helpful in large organizations where several Microsoft clients run TCP/IP but do not access a WINS server. These agents use broadcasts rather than directed resolution requests to a WINS server. Employing a proxy agent on subnets can help reduce the need to implement additional WINS servers.
Static mappings are another method to improve name resolution in mixed environments. Static mappings are permanent entries in the WINS database for specific machines. This solution incorporates non-Microsoft hosts into the WINS database, which improves name resolution performance.
Here's how to add a static mapping: In WINS Manager, click the Mappings menu and then click Mappings. When you see the Static Mappings menu shown in Screen 3, enter the name and IP address for the given server.
Static mappings also help in small, mixed environments; however, you must document your network configurations. This documentation helps in the case of changed IP addresses.
Secure Environments
"I maintain classroom networks that require isolation from my
production network. Could WINS compromise security?"
In organizations that require a high security level on various local networks, administrators may not want to configure clients for WINS access. When you need to isolate workstations in classrooms, for example, you may want to prevent users from accessing corporate network resources. Yet, instructor machines might require full network access. In this situation, not defining WINS servers on the classroom clients ensures that you protect resources.
You need to make sure that you do not select the option to enable DNS for NetBIOS name resolution. This option lets NetBIOS clients resolve hosts defined in the DNS server that is specified in the client's network settings. The instructor, in contrast, can configure a local LMHOSTS file with the required server names for NetBIOS resolution.
Keep in mind that denying WINS only makes it more difficult to get file-and-print access to NT resources. You still need to monitor access through TCP/IP services, such as FTP and HTTP. Technically savvy users can issue the NET SEND command and specify the IP address for the resource to connect to resources from an NT command prompt.
The End of WINS?
WINS does a great job of minimizing the administrative complexities of
NetBIOS naming while providing improved performance for NetBIOS clients. That's
why Microsoft originally designed WINS. Obviously the value of these benefits
increases in direct relation to the size and complexity of the network
environment.
Because the upcoming release of NT 5.0 replaces NetBIOS with DNS name resolution lookup, WINS will provide only legacy support for NT 3.51 and 4.0 networks. Without WINS's NetBIOS dependencies, administrators will not need WINS except for interoperating with NT 4.0-based networks.
Instead of designing new tools to supplement NT's strengths, Microsoft is moving toward industry-standard methods for common services such as logon authentication and name resolution. For this reason, NT is sure to become a stronger Internet and enterprise network player. In the meantime, understanding when and how to implement WINS not only improves the reliability of your NT networks, but also provides stability as you prepare for the eventual integration with and upgrade to NT's next release.
