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 resolve NetBIOS names to IP address. If you're in a routed LAN and WAN network environment, you don't have much choice but to use WINS. And, if your environment contains multiple WINS servers replicating with each other, you probably wish Microsoft had never developed WINS.

In this article, I'll dig deep into WINS--looking at how it works, how to design a large-scale WINS implementation, and how to troubleshoot WINS when it breaks. I will review some of the key features of WINS, but, I assume that you're familiar with the basic functions of WINS and the WINS Administrator tool. 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 to provide Domain Name System (DNS) functionality in a NetBIOS world. (For more information about WINS and DNS, see the sidebar, "Can You Use DNS Instead of WINS?" page 158.) That is, WINS gives NT (and Windows 95 or Windows for Workgroups) devices that use TCP/IP as a way to resolve simple machine names to IP addresses. But WINS also provides the NetBIOS functions associated with that machine name. WINS accomplishes this resolution through the use of the 16th-byte value. The 16^th-byte value is, as its name implies, a byte of information that WINS tacks on to the end of every NetBIOS machine name in your NT environment. This placement means that NT machine names cannot exceed 15 bytes, and the 16^th byte is reserved for this special value. You don't ordinarily see the 16^th-byte value when you refer to Windows machines by name. However, you can see evidence of the 16^th byte if you open up a command shell in NT, and type the command

nbtstat -n

This command shows you the NetBIOS names registered locally for this machine. In Screen 1, page 152, my machine name, W1NT, has registered with the 16^th-byte value of <03>. You'll notice that the username I am currently logged on as, DMARELIA, has also registered with the <03> value. Some NetBIOS services need to know who is logged on to which machine. For example, when you issue a Net Send command to a username, NT Messenger Service uses the <03> 16^th-byte value, which the service represents in hexadecimal notation. The Net Send command directs the messenger service on the source machine to query WINS for the username registered with <03>. WINS returns the IP address for that username, and the source machine then knows where 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 information specific to domains and workgroups. Associated with each of these different types of names is a specific set of 16^th-byte values that provide NetBIOS services. For a list of the 16^th-byte values most commonly found in WINS, check out Knowledge Base article Q119495, "List of Names Registered 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 is not complete, and in your WINS you may see other 16^th-byte values that you don't recognize. Some third-party applications that run as services on your NT devices will register custom 16^th-byte types, usually associated with the machine name they're running on.

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

<03>: for the Messenger Service

<00>: for the Workstation Service

<20>: for the Server Service

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

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

With the introduction of NT 4.0, Microsoft reorganized these types of entries. NT 3.51 and earlier versions had only four types of entries--the Domain Name type was called the Internet Group. In NT 4.0, Microsoft moved the functionality of what was the Internet Group to the Domain Name, and the Internet Group type took on a new function. Specifically, the Internet Group lets you define custom 16^th-byte values. This method gives application developers a way to identify a service running on an NT system by having it register a unique 16^th-byte value with WINS. Machines that register workgroup or domain entries use the Group type. The Browser service, <1E> 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 register themselves as available to handle logon requests (<1C>). The Domain Name type will hold up to 25 IP addresses for a given domain.

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

The WINS Database
WINS provides a centralized, dynamic mechanism for keeping track of all these 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, because information about names and IP addresses can change often. A user might log on to multiple workstations, or remote users on laptops might dial in from multiple IP addresses, depending on where they are. WINS lets these clients dynamically register and reregister themselves as information changes. WINS is an ever-changing database of names and IP addresses. Microsoft based WINS on its Jet database engine, which is the same technology its Dynamic Host Configuration Protocol (DHCP) server and Microsoft Exchange use. On an NT Server, if you look where WINS is installed--in the %systemroot%\ system32\wins directory--you'll see the file wins.mdb. It is the main WINS database file for this system, with the familiar Microsoft Access extension. Don't try opening the file with Access. WINS uses a special Jet database engine version that is different from Access.

WINS Replication
If you have a small NT network (i.e., fewer than 200 nodes), you may need only one WINS server for name resolution services. However, if you're deploying WINS to multiple locations across both LAN and WAN locations worldwide, you will likely deploy multiple WINS. Even in a small network, you might want two WINS servers for redundancy. In both cases, you will need to consider replicating records 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 and pull (for more on this topic, see Mark Minasi, "Advanced WINS Features," September 1997). When you set up a push trigger between a pair of WINS servers--for example, Server A and Server B--you are telling Server A that after a set number of changes occur in its database, Server A needs to send a 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 trigger is responsible for all replication between partners. You can also configure pull intervals that say, "Every so many minutes, pull any new records that exist on my partners." As I'll explain next, WINS uses version IDs to determine what constitutes new records.

Microsoft bases WINS replication on a multiple-master model. Each WINS server in your environment owns the records for devices registered with it, and replicates these records to configured partners. When you set up replication among multiple WINS servers--for example, between WINS Server A and Server B--you are telling WINS Server A to copy the records that it owns to WINS Server B's database, and vice versa. You can see this replication when you start the WINS 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've selected the WINS server at 192.168.10.71, which is replicating with 192.168.10.70 and 192.168.11.129. From the Show Database dialog box, you'll see interesting information about this WINS server's database. For example, the Select Owner window lets you show that portion of the database owned by the WINS server you're currently managing, or one of its replication partners. Select a different owner, and the contents of the database window change to display that owner's records. Click the Show All Mappings radio button, and you can view all records within the database on the managed WINS server.

Remember, you're viewing records replicated from other WINS servers, but these records physically exist in the database of the WINS server you're currently managing. This point is important, and I can best illustrate it with the 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 file server called Appserver. Server B replicates Appserver's registration information to Server A. You configure an NT workstation called WS1 to register itself with Server A and to use Server A for NetBIOS name resolution. If WS1 wants to connect to Appserver, it need only contact Server A, which owns records from 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 uses the version ID and an expiration date to keep track of the records that need to be replicated. Every record in the database has a unique, sequential version ID. A low-order and high-order set of bytes (represented hexadecimally) compose the version 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 set to 0. For example, if you have a registration with a version ID of (FA09), it is actually (0 FA09). Two partners that are set to replicate each other, whether they are push or pull, use version IDs to determine how many records are more recent, and which records to replicate. For example, WINS Server A is set to pull every two hours with WINS Server B. The last time Server A pulled from Server B, the highest version ID of records owned by Server B was 123AA. Two hours later, Server B has handled a few registrations and some reregistrations and currently owns records up to version ID 123BF. Server A now will pull all records between 123AB and 123BF.

Expiration Dates
The expiration date associated with a WINS record tells WINS how long to keep a given record active. Referring again to Screen 3, you'll notice two columns in the database display window--column A and column S. Column A shows that the record is active, and column S shows that the record was statically mapped. Active means that the record is still valid in the database, that it has been renewed, and that it is a live record. Static records are those that have been manually added to the WINS database. Normal records are dynamically registered with WINS. If a record has been dynamically registered, column S will be blank. Column A can have three different indicators--a check mark to indicate active, 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 server is 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 configuration options (as shown in Screen 4). The basic portion of the screen includes four time intervals you need to configure on a WINS server--the Renewal Interval, Extinction Interval, Extinction Timeout, and Verification Interval. These values control how often your WINS clients need to reregister with the WINS server and how long a given registration is good. Also, they control how long a record remains active in the database.

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

These intervals are important in replication, because a partner of a WINS server will not pull records if those records will become extinct as a function of replication. Suppose that a set of records on WINS Server A are due to expire in one day, and you're replicating those records to WINS Server B. WINS Server B's system clock thinks it is already one day later. Server B fails to replicate the records because it believes the records are extinct. You need to time synchronize WINS servers in your environment as closely as possible to avoid such problems.

Designing a Replication Scheme
Before you design a replication pattern for all WINS servers in your environment, you need to consider a couple of things. First, the goal in any enterprise WINS configuration is to have as few WINS servers as possible. In a large network, WINS can be a very problematic service, and you will thank yourself 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 four WINS servers for 20,000 devices. The prime driver behind your design should be to balance availability of name resolution services related to your network topology 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 each other if you want every machine in your environment to be able to resolve every other machine. Even if you don't want this resolution, you're probably asking for trouble if you try to segment WINS servers for purposes of securing certain machine names. There are better ways to provide security.

Once you have decided how many WINS servers you will need to support, keep in mind two important goals when creating a WINS replication plan. First, keep a replication path no more than two "hops" deep. That is, if WINS Server A replicates with WINS Server B, and WINS Server B replicates with WINS Server C, then WINS Server D needs to replicate with WINS Server B. The second design goal is to create a replication scheme that meets the minimum convergence required to keep your environment consistent. Convergence is the time necessary for changes to the database of one WINS server to propagate to all other WINS servers.

In addition to these design goals, several best practices have come about since WINS has been around. First, when you establish replication between two partners, the partners must be both push and pull partners with each other. I haven't found a configuration that yields a consistent result if it isn't using two-way push-pull. Second, make sure that between a given pair, the push-pull configurations are the same. For example, if the pull interval on Server A is every 3 hours starting at midnight, the interval must be the same on its partner.

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

So, what does a replication design look like that takes into consideration no more than two hops and quick convergence? Figure 1 shows an example of a replication 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 WINS server. All the other WINS servers--Server B through Server E--will act as primary servers. In this hub-and-spoke design, each WINS server replicates the records that it owns to Server A, which in turn, replicates them to its partners. When replication is complete, each WINS server will have the entire database of WINS registrations for the enterprise.

In this design, convergence becomes a function of the push-pull parameters you define on each partner. For example, if you set the Push count to be 20 (the minimum) 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 can adjust 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 registered on Server D. You can set the pull interval between Server C and Server A and Server D and Server A to be small, such as every 30 minutes. This adjustment means that the maximum time for a new registration to get from Server D to Server C is 1.5 hours.

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

Maintenance of WINS
Establishing replication between your WINS servers is the easy part. Keeping them up and running with a consistent database is tricky. If you're maintaining NT 3.51 (or NT 3.50) WINS servers, you probably know you must jetpack the WINS database periodically. Jetpacking is the process by which you compact and rewrite the WINS database. The jetpacking process in NT 3.5x requires you to manually stop the WINS service, run jetpack.exe, then restart the service. This process needs to occur frequently (once a week on an active WINS server), to keep the database consistent. The easiest way to jetpack in NT 3.5x is to create an 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 database automatically. This automation is a boon, because it means that the database is always consistent. However, if you need to jetpack an NT 4.0 WINS server, you can 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 server environment, after you replicate static mappings, getting rid of them can be very difficult. This problem occurs because static mappings effectively have no expiration date--most expire in the year 2038. They don't expire out of the database on replicas, even if you remove them from the server that created them.

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

Use static mappings only as a last resort when you can't get a device or service to register dynamically. Some people use static mappings to register clients 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%\system32\drivers\etc rather than keeping the static mappings in WINS.

Troubleshooting WINS
Several problems manifest themselves if your WINS databases are corrupt or in need of jetpacking. Examples include devices that cannot register with the database, or records that aren't replicating properly. You may also see evidence of corruption from the WINS Administrator tool if you view the database. Records that contain garbage characters or invalid expiration dates are good indications of problems with the database. To deal with these problems, you may have to explicitly 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 date is 2038, and is OK.) You may also need to perform a Delete Owner operation on the offending records to remove them from the database. Delete Owner can be a tricky operation in a replicated WINS environment. Before you perform this operation on a WINS server, turn off replication between the server and all of its replication partners. Then perform the operation, and reestablish replication. Finally, you will need to perform this operation on all servers that contain the offending owner. If you don't, you'll find the bad records replicating again. After you perform a Delete Owner, stop WINS and jetpack the database to ensure the records were removed.

You can use the WINSCL tool to remove individual corrupt records or groups of them from a WINS database. You can use the resource kit utility WINS CHK to test your WINS server's health on an ongoing basis. WINSCHK can take two text files 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 of WINS servers in servers.txt. It can also perform periodic communications checks against WINS servers, or verify version number consistency.

Microsoft recommends that a WINS server reference itself only in its WINS client configuration. Failure to do so can actually cause database corruption problems. For example, if you have a WINS server whose IP address is 192.168.100.10, the Primary and Secondary WINS server reference that you configure in that 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, you can do several things. First, look at the system event logs on the servers involved to check for any useful messages. You can turn on Log Detailed Events in the WINS Administrator configuration screen while you're troubleshooting problems. 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 CPU drain. Second, you can force replication manually from the Replication Partners menu item in the WINS Administrator tool. As a final test, make sure that the WINS servers involved can resolve their partners by name. I have seen a situation where replication fails because the partners were not resolvable by name.

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