Setting Your WINS Strategy

Determine your goals with WINS

Many network administrators wrestle with how to employ effective WindowsInternet Name Service (WINS) server strategies. Administrators typically askquestions about running WINS in small and large environments, determining aneffective number of servers, using WINS with Novell NetWare clients, andsecuring WINS against unauthorized access. Before I get into the questions I seemost frequently, let's review the history of name resolution and how we arrivedat 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 performname resolution on Microsoft-based, TCP/IP networks. The first hoop was DomainName System (DNS)--not a big deal for UNIX savvy administrators familiar withHOSTS files and DNS namespace on the server. But maintaining static addressesand names for hundreds of nodes on many DNS servers causes networkadministrators to think twice. As a de facto standard for Internet naming, allnetworks used DNS. Properly configured, DNS lets TCP/IP-based applicationscommunicate 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. InNetBIOS networks, computers broadcast their local, unique NetBIOS name on thenetwork--a fundamentally different approach compared to the connection-orientednature of TCP/IP. In small, bridged environments, NetBIOS's performance wasgreat 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, youcan't route it. So Microsoft gave us the LMHOSTS file, the NetBIOS equivalent ofa TCP/IP local HOSTS file.

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

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

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

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

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

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

When deploying NT networks in small locations or locations with minimalonsite support, consider employing WINS on the site's high-performance domaincontrollers. These machines offload overhead from dedicated high-user fileservers.

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

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

For this reason, configuring WINS on at least two servers for each locationis 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 andIP address of the secondary or backup WINS server. This configuration adds thebackup server as a replication partner and lets both WINS servers exchangeupdates 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 overthe WAN. But as your environment grows and WINS traffic increases, you mustmonitor name resolution requests across the network and plan to consolidate WINSservers 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. Isthis WINS strategy a solid approach?"

Sites with thousands of nodes in multiple, connected locations often havetoo many WINS servers. Effective WINS planning means maximizing the availabilityof WINS servers to clients, not maximizing the number of WINS servers. Inaddition, you need to be aware of the replication demands between each WINSreplication partner. Based on an average of three database changes per hour oneach WINS server, replication traffic can create a significant amount of networkchatter, possibly up to 8 percent in an eight-hour day, according to apresentation 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. Runningmore than two WINS servers for each 100 to 200 nodes probably overloads thesystem. This fact is especially true when all workstations connect in a singleLAN. Keep in mind that several factors affect the capability of a single WINSserver. These factors include server hardware, network link speed, andvolatility of WINS database changes.

To determine whether you have the appropriate number of servers, use the NTPerformance Monitor (Perfmon.exe) to track CPU utilization, bytes persecond for the network interface, and queries per second for the WINS server. Ifany counter consistently reports high utilization, your environment may requireadditional WINS servers. However, if these counters indicate little to noactivity, consider eliminating or relocating these underutilized WINS servers.

2.Determine geographical placement of the servers. Havingmultiple WINS servers on a single segment does not result in a huge boost toname resolution performance. WINS really shines in its ability to better servicerequests across routed segments, especially in a WAN environment. To minimizeyour dependency on slow WAN links for name resolution traffic, you can locateWINS servers in strategic geographical locations. For example, in a multitierednetwork, your servers may reside on routed segments for the Northeast.Localizing WINS servers on the Northeast segments aids name resolution andreduces the need for WINS servers defined for other regions to resolve names.Also, to increase performance, you will want to place WINS servers on segmentswith high broadcast traffic. This strategy facilitates regional name resolutionwithout WINS traffic traversing an excessive number of network segments.

3.Control replication intervals. Three settings manageWINS replication traffic: Update Count, Replication Interval, and Start Time.The Update Count determines the number of record updates that must occur in theWINS database before the WINS server notifies its partners that replicationupdates exist. Depending on the volatility of name changes in your environment,increasing the Update Count reduces the number of replication notifications thatthe server sends. (However, name resolution failures may occur because WINS namechanges will take longer to reach partner WINS servers.)

Here's how to increase the Update Count: In WINS Manager, click theOptions/Preferences menu and then click Partners. When you see the Preferencesscreen shown in Screen 2, click Update Count.

Instead of increasing the Update Count, you can simply increase theReplication Interval. WINS sets the default Replication Interval to every 30minutes. This means that once WINS notifies replication partners that updatedrecords exist, partners pull replication records in 30 minutes. You need toadjust this value consistently across all WINS replication partners, and youneed to control the time of day when replication events occur.

If your environment must increase its Replication Interval, time theupdates to occur during off-hours--especially with WINS servers across WANlinks. To set the Replication Interval, click Replication Interval on thePreferences screen and enter an interval in the HH:MM:SS format.

In large environments, administrators often configure WINS servers in amultitier hierarchy. You may need to configure Replication Intervals so thatchanges cascade to partner WINS servers appropriately. In other words, you wantto ensure that WINS replicates record updates from server A to server B and thenfrom server B to server C, etc.

Mixed Environments
"Our network consists of NT application servers with mostly NetWareclients. How can I set up WINS?"

Mixed networking environments are today's norm. Yet many such environmentsdon't necessarily warrant the use of WINS. For example, one of my customers onlyrecently began to upgrade 400 workstations from Windows 3.11/NetWare 3.xto Win95. In this environment, the company deployed NT servers for SQL databaseapplications, but NetWare 3.x and 4.x. systems were the primary file-and-printnetworks. Except for a handful of NT clients, all the client workstations ranWindows 3.11 with a 16-bit Novell client stack, so WINS servers did not benefitthis 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 environmentsinclude IBM LAN Manager or Digital Equipment Pathworks. Client workstations thatcan't recognize WINS servers directly can still take advantage of WINS dynamicname resolution, using WINS proxy agents. A proxy agent can be any NT or Win95client workstation configured to access a given WINS server.

Proxy agents accept broadcasts from non-Microsoft clients and forward therequests to the WINS server. Rather than maintain a WINS database, you can use aproxy agent that essentially gives the B-node client access to its local namecache for a given period. If you want to use proxy agents, clients must complywith Request for Comments (RFC) 1001 and RFC 1002 and conduct B-node (broadcast)resolution.

WINS proxy agents are also helpful in large organizations where severalMicrosoft clients run TCP/IP but do not access a WINS server. These agents usebroadcasts rather than directed resolution requests to a WINS server. Employinga proxy agent on subnets can help reduce the need to implement additional WINSservers.

Static mappings are another method to improve name resolution in mixedenvironments. Static mappings are permanent entries in the WINS database forspecific machines. This solution incorporates non-Microsoft hosts into the WINSdatabase, which improves name resolution performance.

Here's how to add a static mapping: In WINS Manager, click the Mappingsmenu and then click Mappings. When you see the Static Mappings menu shown inScreen 3, enter the name and IP address for the given server.

Static mappings also help in small, mixed environments; however, you mustdocument your network configurations. This documentation helps in the case ofchanged IP addresses.

Secure Environments
"I maintain classroom networks that require isolation from myproduction network. Could WINS compromise security?"

In organizations that require a high security level on various localnetworks, administrators may not want to configure clients for WINS access. Whenyou need to isolate workstations in classrooms, for example, you may want toprevent users from accessing corporate network resources. Yet, instructormachines might require full network access. In this situation, not defining WINSservers on the classroom clients ensures that you protect resources.

You need to make sure that you do not select the option to enable DNS forNetBIOS name resolution. This option lets NetBIOS clients resolve hosts definedin the DNS server that is specified in the client's network settings. Theinstructor, in contrast, can configure a local LMHOSTS file with the requiredserver names for NetBIOS resolution.

Keep in mind that denying WINS only makes it more difficult to getfile-and-print access to NT resources. You still need to monitor access throughTCP/IP services, such as FTP and HTTP. Technically savvy users can issue the NETSEND command and specify the IP address for the resource to connect to resourcesfrom an NT command prompt.

The End of WINS?
WINS does a great job of minimizing the administrative complexities ofNetBIOS naming while providing improved performance for NetBIOS clients. That'swhy Microsoft originally designed WINS. Obviously the value of these benefitsincreases in direct relation to the size and complexity of the networkenvironment.

Because the upcoming release of NT 5.0 replaces NetBIOS with DNS nameresolution lookup, WINS will provide only legacy support for NT 3.51 and 4.0networks. Without WINS's NetBIOS dependencies, administrators will not need WINSexcept for interoperating with NT 4.0-based networks.

Instead of designing new tools to supplement NT's strengths, Microsoft ismoving toward industry-standard methods for common services such as logonauthentication and name resolution. For this reason, NT is sure to become astronger Internet and enterprise network player. In the meantime, understandingwhen and how to implement WINS not only improves the reliability of your NTnetworks, but also provides stability as you prepare for the eventualintegration with and upgrade to NT's next release.