Implementing Enterprisewide WINS

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 . You'll notice that the username I am currently logged on as, DMARELIA, has also registered with the 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 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 . 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:

: for the Messenger Service

: for the Workstation Service

: 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 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 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, 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 (). 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.