Introduction to WINS

If you are at all familiar with Windows NT 4.0 networks, you are undoubtedly familiar with the
intricacies of a WINS infrastructure. You may also be wondering why Microsoft didn't get rid of
WINS in Windows Server 2003. Well, the good news is that with Windows Server 2003, WINS
is used for backward compatibility only. Windows Server 2003 Active Directory networks do
not need WINS at all.

So that means we don't need to talk about WINS, right? Sorry, but you don't get off that easily.
Until your network is 100% Windows 2000 or later, you still need WINS to provide backward
compatibility for legacy Windows operating systems, particularly with your NT domains. With
that in mind, let's talk about what WINS is and how it works.

In the Internet-centric environment that most companies are designing and maintaining,
Transmission Control Protocol/Internet Protocol (TCP/IP) has become the ubiquitous networking
protocol. For old-time Unix users, using TCP/IP is a good thing. TCP/IP came out of the Unix
arena and has been the native protocol for Unix systems since the late 1980s.

Microsoft, on the other hand, started with a different protocol as its LAN Manager operating
system's native protocol—NetBIOS Extended User Interface (NetBEUI). NetBEUI was a pretty
good protocol for small networks; it required no configuration and didn't require complex
addressing like TCP/IP does. However, NetBEUI cannot handle routing and does not perform
well in large environments. Microsoft needed to add TCP/IP support.

When Microsoft began to add TCP/IP support to its LAN server products, the company ran into
a little problem. The naming system used on Microsoft networks at that time would not function
on routed TCP/IP networks. Microsoft LAN Manager computers used the computer's NetBIOS
names for identification. Although this makes maintaining the network very simple for an
administrator—because servers are automatically advertised on the network by name—this
naming system was a problem with TCP/IP.

NetBIOS has a design limitation that shows up in routed networks because NetBIOS relies
heavily on broadcast messages to advertise servers and their shared resources. Broadcast
messages are messages that are received by every computer on a network segment, rather than by
a specific computer. This paradigm is useable on smaller networks but can add overwhelming
amounts of broadcast traffic on an enterprise network. If you have ever suffered from a broadcast
storm on your network, you are familiar with the issue. To confine the impact of broadcast
messages on a TCP/IP network, IP routers do not forward broadcast messages. Unlike the
Microsoft NWLink protocol for IPX compatibility, which was written by Microsoft to support
broadcasts, TCP/IP conforms to very strict standards. To function in a TCP/IP environment,
Microsoft's TCP/IP implementation had to conform to the standard. Therefore, Microsoft had to
find a way to make NetBIOS naming work in a standard TCP/IP network.

Microsoft's first solution, introduced in its older LAN Manager server, was to use a LAN
Manager HOSTS (LMHOSTS) file on each computer on the network. Similar to the HOSTS file
used before DNS was available, LMHOSTS consists of records matching NetBIOS names to IP
addresses. When a computer couldn't find a particular NetBIOS computer on the local network, it
would consult its LMHOSTS file to see whether the computer could be found elsewhere.

An LMHOSTS file is a text file that must be edited manually. After creating a master LMHOSTS
file, an administrator must copy the file to every computer on the network. Every time a
computer was installed or removed, the master LMHOSTS file had to be updated and
redistributed. The architects of TCP/IP faced a similar issue with HOSTS files before the DNS
specification was written.

WINS and DNS Integration

Although it would be nice if you no longer had to support WINS clients, this is not always the
case—thus the reason that Microsoft still provides a very robust and powerful WINS server in
Windows Server 2003. What's more, DNS and WINS can be integrated to provide a more
complete name resolution solution for all clients on your network.

You can configure a DNS server to query a WINS server by configuring a DNS zone setting.
This is helpful when some of the clients you support require NetBIOS name resolution, such as
legacy Windows 9x clients, or cannot register themselves with DNS. In effect, you are providing
a means for DNS clients to look up WINS client names and IP addresses without needing to
contact the WINS server directly. This is accomplished by adding a WINS lookup record to the
authoritative zone. After it is configured, the DNS server will query a WINS server for every
request made to it for which it does not have a valid record. If the requested name is located on
the WINS server, the information is returned to the requesting client via the DNS server. The
process is invisible to all clients. Note that you can configure this for both forward and reverse
lookup zones.

If you have a mixture of Windows and third-party DNS servers in your organization, you will
run into problems if you attempt to replicate WINS lookup records to these third-party DNS
servers. Only Microsoft DNS servers support WINS lookup records; thus, zone transfers to third-
party DNS servers will fail. In this situation, you should use WINS referral to create and delegate
a special "WINS zone" that refers queries to WINS when needed. This zone does not perform
any registrations or updates. Clients need to be configured to append this additional WINS
referral zone to their queries for unqualified names, thus allowing clients to query both WINS
and DNS as required. You also need to ensure that this WINS referral zone is not configured to
transfer to any third-party DNS servers.

Microsoft also needed a dynamic name service that would keep itself current on computers on
the network—a name service that could work in routed TCP/IP environments. Microsoft's
answer was the WINS. Four elements can be found in a WINS network:

 WINS servers—When WINS client computers enter the network, they contact a WINS
server using a directed message. The client computer registers its name with the WINS
server and uses the WINS server to resolve NetBIOS names to IP addresses.
 WINS client computers—WINS client computers use directed (P-node) messages to
communicate with WINS servers and are typically configured to use H-node
 communication. Windows 2000, Windows NT, Windows 95 and 98, and Windows for
Workgroups computers can be WINS client computers.
 Non-WINS client computers—Older Microsoft network client computers that can't use
P-node can still benefit from WINS. Their broadcast messages are intercepted by WINS
proxy computers that act as intermediaries between the B-node client computers and
WINS servers. MS-DOS and Windows 3.1 client computers function as non-WINS
clients.
 WINS proxies—Windows NT, Windows 95 and 98, and Windows for Workgroups
client computers can function as WINS proxies. They intercept B-node broadcasts on
their local subnet and communicate with a WINS server on behalf of the B-node client
computer.

As we discuss in the "Implementing WINS Replication" section of this chapter, WINS servers
can replicate their databases so that each WINS server can provide name resolution for the entire
network. Whenever possible, it is desirable to have at least two WINS servers. This way, name
resolution can take place when one name server is down. Also, administrators can distribute
WINS activity across multiple servers to balance the processing loads. WINS server addresses
are one of the configuration settings that can be issued with DHCP.

What's New in Windows Server 2003 WINS

If you're moving from a Windows NT 4.0–based WINS implementation, some great changes are
in store for you in Windows Server 2003. The following improvements have been made to
WINS since Windows 2000 Server:

 Record filtering—Using improved filtering and search functions, you can quickly locate
records by showing only the records that fit the specified criteria. This capability can be
useful when you are managing larger WINS databases. You can now specify multiple
criteria to perform advanced searches. Also, you can combine filters for customized
results. The available filters include record owner, record type, NetBIOS name, and IP
address (with or without the subnet mask). Lastly, because the results of the query are
stored in the local NetBIOS cache on your computer, the performance of subsequent
queries and name lookups is improved.
 Specified replication partners—You can define a list of WINS servers that are allowed
to be the source of incoming WINS records during pull replication events. You can opt to
block specific WINS servers from being able to replicate with your WINS servers.
Alternatively, you can opt to allow a specific list of WINS servers to perform replication,
blocking all other WINS servers from replicating with your WINS servers.

The following improvements were also made to WINS in Windows 2000 Server and are carried
over into the WINS implementation in Windows Server 2003:

 Command-line management—You can use the netsh command with the WINS
context to manage WINS servers from the command line and to use batch files.
 Persistent connections—Each WINS server can be configured to maintain a persistent
connection with one or more of its replication partners. This configuration increases
 replication speed and eliminates network overhead associated with building and tearing
down connections for replication.
 Manual tombstoning—Records can be marked for deletion (tombstoning). This
tombstoned state is replicated to all WINS servers preventing an active copy of the record
on a different WINS server from being propagated.
 Improved management—The WINS console is Microsoft Management Console based
and can be added to customized MMCs, resulting in a user-friendly, powerful, and
customized management interface.
 Dynamic record deletion and multiselect—Using the WINS console, you can you
easily manage the WINS database. You can point, click, and delete one or more WINS
static or dynamic entries.
 Record verification—Record verification performs a comparison of the IP address
returned by a NetBIOS query of different WINS servers. This feature helps to check the
consistency of names stored and replicated on your WINS servers.
 Version number validation—Version number validation examines the owner address–
to–version number mapping tables. This feature helps to check the consistency of names
stored and replicated on your WINS servers.
 Export function—The WINS database can be exported to a comma-delimited text file
for importation into Excel or another application for offline analysis.
 Increased fault tolerance—Windows 98 and later clients can specify up to 12 WINS
servers per interface, up from the previous limit of 2. These extra WINS servers can be
queried should the primary and secondary WINS servers not respond.
 Dynamic renewal—WINS clients are no longer required to restart after renewing their
NetBIOS name registration.
 Nbtstat -RR option—The Nbtstat -RR option provides the ability to release and
renew the NetBIOS name registration.
 WINS Users group—A special local group, WINS Users, is created when WINS is
installed; this group provides read-only use of the WINS console. Members of this group
can view but not change information and properties of the WINS servers.

www.informit.com/

Introduction to WINS

Windows Internet Name Service (WINS) is the Windows implementation of a NetBIOS name
server
(NBNS), which provides a distributed database for registering and querying dynamic mappings
of
NetBIOS names to IPv4 addresses used on your network. WINS is designed to provide
NetBIOS name
resolution in routed TCP/IP networks with multiple subnets. Without WINS, you must
maintain Lmhosts

files.
Before two hosts that use NetBIOS over TCP/IP (NetBT) can communicate, the destination
NetBIOS name must be resolved to an IPv4 address. TCP/IP cannot establish communication
using a NetBIOS computer name. The basic procedure for WINS-based NetBIOS name
resolution is the following:

1. Each time a WINS client starts, it registers its NetBIOS name-to-IPv4 address mappings
with a
configured WINS server.
2. When a NetBIOS application running on a WINS client initiates communication with
another host,
NetBT sends a NetBIOS Name Query Request message with the destination NetBIOS name
directly
to the WINS server, instead of broadcasting it on the local network.
3. If the WINS server finds a NetBIOS name-to-IPv4 address mapping for the queried name in
its
database, it returns the corresponding IPv4 address to the WINS client.
Using WINS provides the following advantages:
•

Client requests for name resolution are sent directly to a WINS server. If the WINS server can
resolve
the name, it sends the IPv4 address directly to the client. As a result, a broadcast is not needed
and
broadcast traffic is reduced. However, if the WINS server is unavailable or does not have the
appropriate mapping, the WINS client can still use a broadcast in an attempt to resolve the
name.

•
The WINS database is updated dynamically so that it is always current. This process allows
NetBIOS
name resolution on networks using DHCP and eliminates the need for local or centralized
Lmhosts
files.
•

WINS provides computer browsing capabilities across subnets and domains. Computer
browsing
provides the list of computers in My Network Places. For more information, see Appendix C,
"Computer
Browser Service."

ow WINS Works
The WINS Server service in Windows Server 2003 is an implementation of an NBNS as
described in
Requests for Comments (RFCs) 1001 and 1002. WINS clients use a combination of the
following
processes:
•
Name registration

Each WINS client is configured with the IPv4 address of a WINS server. When a WINS client
starts,
it registers its NetBIOS names and their corresponding IPv4 addresses with its WINS server.
The
WINS server stores the client’s NetBIOS name-to-IPv4 address mappings in its database.

•
Name renewal

All NetBIOS names are registered on a temporary basis so that if the original owner stops
using a name, a different host can use it later. At defined intervals, the WINS client renews the
registration for its NetBIOS names with the WINS server.

•
Name resolution
A WINS client can obtain the IPv4 addresses for NetBIOS names by querying the WINS
server.
•
Name release
When a NetBIOS application no longer needs a NetBIOS name, such as when a NetBIOS-
based

service is shut down, the WINS client sends a message to the WINS server to release the

name.

These processes are described in greater detail in the following sections.

All WINS communications between WINS clients and WINS servers use unicast NetBIOS

name

management messages over User Datagram Protocol (UDP) port 137, the reserved port for the
NetBIOS Name Service.
Name Registration
When a WINS client initializes, it registers its NetBIOS names by sending a NetBIOS Name
Registration Request message directly to its configured WINS server. NetBIOS names are
registered
when NetBIOS services or applications start, such as the Workstation, Server, and Messenger

services.

If the NetBIOS name is unique and another WINS client has not already registered the name, the
WINS
server sends a positive Name Registration Response message to the WINS client. This message
contains the amount of time, known as the Time to Live (TTL), that the NetBIOS name is
registered to
the WINS client. The TTL is configured on the WINS server.