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 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 16th-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 16th byte is reserved for this special value. You
don't ordinarily see the 16th-byte value when you refer to Windows
machines by name. However, you can see evidence of the 16th 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
16th-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> 16th-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 16th-byte values that provide
NetBIOS services. For a list of the 16th-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 16th-byte values
that you don't recognize. Some third-party applications that run as services on
your NT devices will register custom 16th-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 16th-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 16th-byte values. This method gives
application developers a way to identify a service running on an NT system by
having it register a unique 16th-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 16th-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.
Previous
Register
