Implementing Enterprisewide WINS

Understanding NT's name resolution service

If you've implemented a Windows NT environment using TCP/IP as your primary protocol, you're probably using Windows Internet Name Service (WINS) to resolveNetBIOS names to IP address. If you're in a routed LAN and WAN networkenvironment, you don't have much choice but to use WINS. And, if yourenvironment contains multiple WINS servers replicating with each other, youprobably wish Microsoft had never developed WINS.

In this article, I'll dig deep into WINS--looking at how it works, how todesign a large-scale WINS implementation, and how to troubleshoot WINS when itbreaks. I will review some of the key features of WINS, but, I assume thatyou're familiar with the basic functions of WINS and the WINS Administratortool. For an overview of WINS, see Mark Minasi, "Name Resolvers: WINS vs.DNS," November 1996.

WINS Under the Covers
WINS is NT's name resolution service. You can think of WINS as a way toprovide Domain Name System (DNS) functionality in a NetBIOS world. (For moreinformation about WINS and DNS, see the sidebar, "Can You Use DNS Insteadof WINS?" page 158.) That is, WINS gives NT (and Windows 95 or Windows forWorkgroups) devices that use TCP/IP as a way to resolve simple machine names toIP addresses. But WINS also provides the NetBIOS functions associated with thatmachine name. WINS accomplishes this resolution through the use of the 16th-bytevalue. The 16^th-byte value is, as its name implies, a byte ofinformation that WINS tacks on to the end of every NetBIOS machine name in yourNT environment. This placement means that NT machine names cannot exceed 15bytes, and the 16^th byte is reserved for this special value. Youdon't ordinarily see the 16^th-byte value when you refer to Windowsmachines by name. However, you can see evidence of the 16^th byte ifyou open up a command shell in NT, and type the command

This command shows you the NetBIOS names registered locally for thismachine. In Screen 1, page 152, my machine name, W1NT, has registered with the16^th-byte value of . You'll notice that the username I amcurrently logged on as, DMARELIA, has also registered with the value.Some NetBIOS services need to know who is logged on to which machine. Forexample, when you issue a Net Send command to a username, NT Messenger Serviceuses the 16^th-byte value, which the service represents inhexadecimal notation. The Net Send command directs the messenger service on thesource machine to query WINS for the username registered with . WINSreturns the IP address for that username, and the source machine then knowswhere to send the message.(For more information about NetBIOS, see Mark Minasi,"Knowing the Angles of NetBIOS Suffixes," February 1997.)

In addition to username and computer name, WINS registers informationspecific to domains and workgroups. Associated with each of these differenttypes of names is a specific set of 16^th-byte values that provideNetBIOS services. For a list of the 16^th-byte values most commonlyfound in WINS, check out Knowledge Base article Q119495, "List of NamesRegistered with WINS Service," (go to Microsoft's Web site, http://www.microsoft.com/kb/ articles/q119/4/95.htm). Be aware, however, that this list isnot complete, and in your WINS you may see other 16^th-byte valuesthat you don't recognize. Some third-party applications that run as services onyour NT devices will register custom 16^th-byte types, usuallyassociated with the machine name they're running on.

When you fire up the WINS Administrator tool and look in the database, yousee multiple entries for a given machine. Most NT workstations register threedifferent 16^th-byte values:

Additionally, if you configure an NT server as a Primary Domain Controller(PDC), that server registers these three services and places registration valuesrelated to the domain in WINS, as shown in Screen 2. For example, the announces the machine at this IP address as the Domain Master Browser. The record signals that this machine is available to handle logon requests for thedomain.

Types of Registration
When you use the WINS Manager tool to view the WINS database, you'll noticedifferent icons associated with machine entries. These icons represent whetherthe entry is unique or multihomed. Devices that have a single NIC will registeras unique. Any machine with multiple NICs will register as a multihomed entry.Any machine with Remote Access Service (RAS) installed will also register asmultihomed, because RAS installs the logical network driver interfacespecification (NDIS)-WAN adapter as part of its install. In addition to uniqueand multihomed entries, the three other possible types of entries are InternetGroup, Group, and Domain Name.

With the introduction of NT 4.0, Microsoft reorganized these types ofentries. NT 3.51 and earlier versions had only four types of entries--the DomainName type was called the Internet Group. In NT 4.0, Microsoft moved thefunctionality of what was the Internet Group to the Domain Name, and theInternet Group type took on a new function. Specifically, the Internet Grouplets you define custom 16^th-byte values. This method givesapplication developers a way to identify a service running on an NT system byhaving it register a unique 16^th-byte value with WINS. Machines thatregister workgroup or domain entries use the Group type. The Browser service, registered for a domain or workgroup, is an example of a Group type. Finally,the domain controllers within a domain use Domain Name type to registerthemselves as available to handle logon requests (). The Domain Nametype will hold up to 25 IP addresses for a given domain.

Usually, you won't have to deal with these different types of entriesdirectly. When a machine registers dynamically, it automatically takes one ormore of these types. However, if you start working with static mappings, which Idiscuss later in this article, knowing what these types of entries do will comein handy.

The WINS Database
WINS provides a centralized, dynamic mechanism for keeping track of allthese special names and the 16^th-byte values associated with them,and resolving them to an IP address. The dynamic nature of WINS is key, becauseinformation about names and IP addresses can change often. A user might log onto multiple workstations, or remote users on laptops might dial in from multipleIP addresses, depending on where they are. WINS lets these clients dynamicallyregister and reregister themselves as information changes. WINS is anever-changing database of names and IP addresses. Microsoft based WINS on itsJet database engine, which is the same technology its Dynamic Host ConfigurationProtocol (DHCP) server and Microsoft Exchange use. On an NT Server, if you lookwhere WINS is installed--in the %systemroot% system32winsdirectory--you'll see the file wins.mdb. It is the main WINS database file forthis system, with the familiar Microsoft Access extension. Don't try opening thefile with Access. WINS uses a special Jet database engine version that isdifferent from Access.

WINS Replication
If you have a small NT network (i.e., fewer than 200 nodes), you may needonly one WINS server for name resolution services. However, if you're deployingWINS to multiple locations across both LAN and WAN locations worldwide, you willlikely deploy multiple WINS. Even in a small network, you might want two WINSservers for redundancy. In both cases, you will need to consider replicatingrecords registered on each WINS database to the other WINS servers.Understanding replication will help with troubleshooting WINS problems.

WINS replication is a two-way process-- that is, both push andpull (for more on this topic, see Mark Minasi, "Advanced WINSFeatures," September 1997). When you set up a push trigger between a pairof WINS servers--for example, Server A and Server B--you are telling Server Athat after a set number of changes occur in its database, Server A needs to senda trigger to Server B saying that new records are ready for Server B to pull.You set up a pull trigger to pull records from a partner, and the pull triggeris responsible for all replication between partners. You can also configure pullintervals that say, "Every so many minutes, pull any new records that existon my partners." As I'll explain next, WINS uses version IDs to determinewhat constitutes new records.

Microsoft bases WINS replication on a multiple-master model. Each WINSserver in your environment owns the records for devices registered with it, andreplicates these records to configured partners. When you set up replicationamong multiple WINS servers--for example, between WINS Server A and ServerB--you are telling WINS Server A to copy the records that it owns to WINS ServerB's database, and vice versa. You can see this replication when you start theWINS Administrator tool, select a WINS server that is replicating with others,and choose Mappings, Show Database from the menu. In Screen 3 (page 154), I'veselected the WINS server at 192.168.10.71, which is replicating with192.168.10.70 and 192.168.11.129. From the Show Database dialog box, you'll seeinteresting information about this WINS server's database. For example, theSelect Owner window lets you show that portion of the database owned by the WINSserver you're currently managing, or one of its replication partners. Select adifferent owner, and the contents of the database window change to display thatowner's records. Click the Show All Mappings radio button, and you can view allrecords within the database on the managed WINS server.

Remember, you're viewing records replicated from other WINS servers, butthese records physically exist in the database of the WINS server you'recurrently managing. This point is important, and I can best illustrate it withthe following example: Suppose you have two WINS servers (Server A and Server B)that replicate with each other. Server B owns records registered by a fileserver called Appserver. Server B replicates Appserver's registrationinformation to Server A. You configure an NT workstation called WS1 to registeritself with Server A and to use Server A for NetBIOS name resolution. If WS1wants to connect to Appserver, it need only contact Server A, which owns recordsfrom Server B, which provides the IP address for Appserver.

Version IDs
If you look again at Screen 3, you'll see the column Version IDs. WINS usesthe version ID and an expiration date to keep track of the records that need tobe replicated. Every record in the database has a unique, sequential version ID.A low-order and high-order set of bytes (represented hexadecimally) compose theversion ID. Unless you have a very large number of devices in your NT network,you will see only the low-order bytes represented. The high-order bytes are setto 0. For example, if you have a registration with a version ID of (FA09), it isactually (0 FA09). Two partners that are set to replicate each other, whetherthey are push or pull, use version IDs to determine how many records are morerecent, and which records to replicate. For example, WINS Server A is set topull every two hours with WINS Server B. The last time Server A pulled fromServer B, the highest version ID of records owned by Server B was 123AA. Twohours later, Server B has handled a few registrations and some reregistrationsand currently owns records up to version ID 123BF. Server A now will pull allrecords between 123AB and 123BF.

Expiration Dates
The expiration date associated with a WINS record tells WINS how long tokeep a given record active. Referring again to Screen 3, you'll notice twocolumns in the database display window--column A and column S. Column A showsthat the record is active, and column S shows that the record was staticallymapped. Active means that the record is still valid in the database, that it hasbeen renewed, and that it is a live record. Static records are those that havebeen manually added to the WINS database. Normal records are dynamicallyregistered with WINS. If a record has been dynamically registered, column S willbe blank. Column A can have three different indicators--a check mark to indicateactive, a dash to indicate released, or a cross to indicate the record was tombstoned,or extinct. The expiration date for records registered with a given WINS serveris derived from the WINS configuration parameters for that server.

To configure the WINS server, go to the WINS Administrator tool main menu,select Server, Configuration, to view the basic and advanced configurationoptions (as shown in Screen 4). The basic portion of the screen includes fourtime intervals you need to configure on a WINS server--the Renewal Interval,Extinction Interval, Extinction Timeout, and Verification Interval. These valuescontrol how often your WINS clients need to reregister with the WINS server andhow long a given registration is good. Also, they control how long a recordremains active in the database.

A dynamic WINS record will go through three phases of life before it isscavenged, or removed, from the database. When a machine firstregisters, the records associated with it are marked active. A machine will thenreregister with WINS at half the time set for the Renewal Interval. If themachine fails to reregister by the end of the Renewal Interval or if you shutdown the machine, the records associated with it will be marked released (thesecond phase). After a record has been marked released, the Extinction Intervalspecifies how long that record is to remain in released mode before being markedtombstoned. Finally, the Extinction Timeout specifies how long tombstonedrecords are to remain in the database before they are scavenged. The delaybetween releasing a record and marking it tombstoned is useful, because often amachine may simply be powered down for a short period, and when the machinecomes back up, it can reregister using the existing, released records.

These intervals are important in replication, because a partner of a WINSserver will not pull records if those records will become extinct as a functionof replication. Suppose that a set of records on WINS Server A are due to expirein one day, and you're replicating those records to WINS Server B. WINS ServerB's system clock thinks it is already one day later. Server B fails to replicatethe records because it believes the records are extinct. You need to timesynchronize WINS servers in your environment as closely as possible to avoidsuch problems.

Designing a Replication Scheme
Before you design a replication pattern for all WINS servers in yourenvironment, you need to consider a couple of things. First, the goal in anyenterprise WINS configuration is to have as few WINS servers as possible. In alarge network, WINS can be a very problematic service, and you will thankyourself later if you simplify your design. How many servers are too many?Depending on your network topology, you wouldn't be out of line to have fourWINS servers for 20,000 devices. The prime driver behind your design should beto balance availability of name resolution services related to your networktopology vs. the need to minimize the number of WINS servers in the environment.You also need to know that all of your WINS servers must replicate with eachother if you want every machine in your environment to be able to resolve everyother machine. Even if you don't want this resolution, you're probably askingfor trouble if you try to segment WINS servers for purposes of securing certainmachine names. There are better ways to provide security.

Once you have decided how many WINS servers you will need to support, keepin mind two important goals when creating a WINS replication plan. First, keep areplication path no more than two "hops" deep. That is, if WINS ServerA replicates with WINS Server B, and WINS Server B replicates with WINS ServerC, then WINS Server D needs to replicate with WINS Server B. The second designgoal is to create a replication scheme that meets the minimum convergencerequired to keep your environment consistent. Convergence is the time necessaryfor changes to the database of one WINS server to propagate to all other WINSservers.

In addition to these design goals, several best practices have come aboutsince WINS has been around. First, when you establish replication between twopartners, the partners must be both push and pull partners with each other. Ihaven't found a configuration that yields a consistent result if it isn't usingtwo-way push-pull. Second, make sure that between a given pair, the push-pullconfigurations are the same. For example, if the pull interval on Server A isevery 3 hours starting at midnight, the interval must be the same on itspartner.

Finally, forget about installing WINS on a multihomed server. You can dothis installation, but you're asking for trouble. WINS wasn't designed to workwell with multihomed configurations, and it can cause some weird problems withreplication, such as failing to replicate.

So, what does a replication design look like that takes into considerationno more than two hops and quick convergence? Figure 1 shows an example of areplication design for five WINS servers. WINS Server A acts as the hub server.All WINS client machines will point to this server as their secondary WINSserver. All the other WINS servers--Server B through Server E--will act asprimary servers. In this hub-and-spoke design, each WINS server replicates therecords that it owns to Server A, which in turn, replicates them to itspartners. When replication is complete, each WINS server will have the entiredatabase of WINS registrations for the enterprise.

In this design, convergence becomes a function of the push-pull parametersyou define on each partner. For example, if you set the Push count to be 20 (theminimum) between Server A and Server B, but 40 between Server A and Server C,then Server C will take longer to replicate changes with Server A. You canadjust the pull interval to reduce or increase convergence time. For example,WINS Server C needs to know as soon as possible when new records are registeredon Server D. You can set the pull interval between Server C and Server A andServer D and Server A to be small, such as every 30 minutes. This adjustmentmeans that the maximum time for a new registration to get from Server D toServer C is 1.5 hours.

Of course, you need to balance replication intervals with the networkbandwidth consumed and the amount of changes your WINS servers are experiencing.By monitoring your WINS servers and network with a tool such as PerformanceMonitor, you can establish a baseline from which to adjust replication asneeded.

Maintenance of WINS
Establishing replication between your WINS servers is the easy part. Keepingthem up and running with a consistent database is tricky. If you're maintainingNT 3.51 (or NT 3.50) WINS servers, you probably know you must jetpackthe WINS database periodically. Jetpacking is the process by which you compactand rewrite the WINS database. The jetpacking process in NT 3.5x requires you tomanually stop the WINS service, run jetpack.exe, then restart the service. Thisprocess needs to occur frequently (once a week on an active WINS server), tokeep the database consistent. The easiest way to jetpack in NT 3.5x is to createan AT scheduler job to perform the activity after hours. However, with NT 4.0,Microsoft added online jetpacking to WINS. Now NT jetpacks the WINS databaseautomatically. This automation is a boon, because it means that the database isalways consistent. However, if you need to jetpack an NT 4.0 WINS server, youcan still do it manually.

If you're considering static mappings, think carefully about this decision.Do everything you can to avoid using them. In a multiple WINS serverenvironment, after you replicate static mappings, getting rid of them can bevery difficult. This problem occurs because static mappings effectively have noexpiration date--most expire in the year 2038. They don't expire out of thedatabase on replicas, even if you remove them from the server that created them.

Because NT bases replication on version ID and NT never increments astatically mapped record's versions, the best way to remove the staticallymapped records from replicas is with the Delete Owner function in the ShowDatabase view of the WINS Administrator tool (or manually delete the staticallymapped records individually, using the WINSCL tool in the Microsoft WindowsNT Server Resource Kit). Delete Owner tells a WINS server to delete all therecords of a selected owner. For example, suppose Server A push-pull replicateswith Server B, and you've statically mapped several records on Server B. Youdecide you want to remove the static mappings on Server B. To remove them fromServer A, you need to perform a Delete Owner operation on Server A for ServerB's records. This operation has the effect of removing all the records owned byServer B, which means that these records won't be available on Server A untilthey have been repulled from Server B.

Use static mappings only as a last resort when you can't get a device orservice to register dynamically. Some people use static mappings to registerclients that are incapable of being WINS aware, such as UNIX-based systems.However, you're probably better off using DNS or even the hosts file in%systemroot%system32driversetc rather than keeping the static mappings in WINS.

Troubleshooting WINS
Several problems manifest themselves if your WINS databases are corrupt orin need of jetpacking. Examples include devices that cannot register with thedatabase, or records that aren't replicating properly. You may also see evidenceof corruption from the WINS Administrator tool if you view the database. Recordsthat contain garbage characters or invalid expiration dates are good indicationsof problems with the database. To deal with these problems, you may have toexplicitly stop WINS and jetpack the database. (Be aware that static mappings,by default, appear in the database with an expiration date of 1-18-38--this dateis 2038, and is OK.) You may also need to perform a Delete Owner operation onthe offending records to remove them from the database. Delete Owner can be atricky operation in a replicated WINS environment. Before you performthis operation on a WINS server, turn off replication between the server and allof its replication partners. Then perform the operation, and reestablishreplication. Finally, you will need to perform this operation on all serversthat contain the offending owner. If you don't, you'll find the bad recordsreplicating again. After you perform a Delete Owner, stop WINS and jetpack thedatabase to ensure the records were removed.

You can use the WINSCL tool to remove individual corrupt records or groupsof them from a WINS database. You can use the resource kit utility WINS CHKto test your WINS server's health on an ongoing basis. WINSCHK can take two textfiles as input (servers.txt and names.txt) and check the contents of names.txt(a set of names that you want to verify is in the database) against a list ofWINS servers in servers.txt. It can also perform periodic communications checksagainst WINS servers, or verify version number consistency.

Microsoft recommends that a WINS server reference itself only in its WINSclient configuration. Failure to do so can actually cause database corruptionproblems. For example, if you have a WINS server whose IP address is192.168.100.10, the Primary and Secondary WINS server reference that you configure inthat server's TCP/IP properties must each point to itself--192.168.100.10.

Replication Problems
If you find that records simply aren't replicating between WINS servers, youcan do several things. First, look at the system event logs on the serversinvolved to check for any useful messages. You can turn on Log Detailed Eventsin the WINS Administrator configuration screen while you're troubleshootingproblems. This step will let you get more detail in the event logs for problems.Make sure you turn off this event log after testing--it can be quite a CPUdrain. Second, you can force replication manually from the Replication Partnersmenu item in the WINS Administrator tool. As a final test, make sure that theWINS servers involved can resolve their partners by name. I have seen asituation where replication fails because the partners were not resolvable byname.

If you search Microsoft's Knowledge Base with the keyword WINS, the numberof problems that Microsoft documents with this service will amaze you. The bestadvice I can give for designing an enterprisewide WINS implementation is to keepit as simple as possible, with as few WINS servers as possible. Keep allreplication parameters between pairs consistent, and monitor the WINS servers closely using both event logs and Performance Monitor.