Resolving NetBIOS Names Using WINS

Resolving NetBIOS Names Using WINS

The venerable Windows Internet Name Service (WINS) is an alternative to statically mapping names and IP addresses in Lmhosts. WINS maintains a database of NetBIOS names and IP address mappings that WINS clients use to register their own NetBIOS services and to find the IP addresses of the services running on other WINS clients.

WINS is based on protocols and services defined in RFC 1001, "Protocol Standard For A NetBIOS Service On A TCP/UDP Transport: Concepts And Methods," and RFC 1002, "Protocol Standard For A NetBIOS Service On A TCP/UDP Transport: Detailed Specifications." These are public standards but, in practice, Microsoft WINS is the only commercial NetBIOS name service.

Resolving Names over Dial-Up Connections

The Routing and Remote Access Services (RRAS) service in Windows Server 2003 can be configured to permit broadcast-based name resolution across a dial-in connection. This eliminates the need for Lmhosts files and special mapping procedures on dial-in clients, at least in small networks. For routed networks where the target host lies on the other side of a router, you may still need an Lmhosts file.

WINS is, without a doubt, the single most pernicious cause of weird, inexplicable behavior in a classic NT network. Managing WINS in a large network is one of the most complex duties of a classic NT administrator. Thankfully, the need for WINS is diminishing thanks to Dynamic DNS.

This section provides an overview of installing, configuring, and troubleshooting WINS on Windows Server 2003.

WINS Functional Overview

WINS works like a bridal registry, where happy couples go to Nordstrom's or Wal-Mart and register their wedding plans so their friends can go to the store and resolve their gift-buying decisions. With WINS, clients go to a WINS server to register their NetBIOS names and services so that other WINS clients can query WINS to resolve NetBIOS names and services into IP addresses. Let's look at registration first.

Name Registration Using WINS

Here is a typical sequence of events when a client registers itself with its WINS server:

  1. When the WINS client comes up on the network, it sends a name registration request to its WINS server. The client sends a separate registration request for each of its SMB-based services. For example, if the client is running the Server, Workstation, and Messenger services, it would submit three registration requests to WINS.

    If the client has multiple network adapters (also known as a multihomed WINS client), it submits registration requests for each service on each adapter.

  2. If the WINS database at the server contains no other records that use the name or IP address that the client is requesting, the WINS server returns a positive name registration response and adds the records to its database along with a renewal interval after which the registration expires. The client must renew the registration within this period. By default, the renewal interval is six days.

  3. If the WINS database at the server contains a record with the same name but different IP address, the WINS server tells the client to wait for a short time (five minutes) while it sends a name query request to the client that already has the registration. If the existing client responds, the WINS server sends a negative name registration response to the requesting client.

    If an existing client does not respond to the name query request, the WINS server returns a positive response to the requesting client and modifies the records in the database. It also starts a new renewal interval.

  4. At the halfway point of the renewal interval, the client sends a renewal request to the WINS server for each registered service. The server responds and the renewal interval clock is reset.

  5. If the WINS client goes off the network using a standard shutdown process, it sends a name release to its WINS server.

  6. The server marks the associated records as released and assigns an extinction interval to the record. During the extinction interval, the released record is not replicated. The owner server is free to reassign the name or address to another client, but replication partners are not. This interval simplifies reregistration when the client comes back online.

In short, the name registration cycle for a WINS client consists of the following:

  • A registration request followed by a registration response informing the client that it owns the name

  • A period of active status during which the client periodically renews its registration

  • A release request followed by a release response telling the client that it no longer owns the name

  • A period of released status during which the client can be reregistered quickly

Selective Domain Responses

It sometimes happens that you want to decommission a particular NetBIOS domain. This can happen during domain consolidation or migration from an NT domain to a Windows Server 2003 domain. When the domain is removed from the system, it leaves lingering records in WINS. You can elect to filter out a domain from the list of records that will be returned by a WINS server. The server returns a No-ACK rather than a useless resource record.

Name Registration Failure Handling

The WINS name registration process includes the following several features for handling common failure modes:

  • Failure to reregister. If a client releases a registration and does not subsequently reregister, the server waits until the end of the extinction interval and then assigns a status of tombstoned to the record. Tombstoned records are replicated so that other WINS servers know that the name and IP address are available should another client attempt to register using them. An extinction timeout interval is assigned to the tombstoned record. The default interval is six days. After this interval, the record is removed from the database during scavenging.

  • Failure to renew. If a client does not renew a registration within the renewal period, the record is assigned a status of released. The server assigns an extinction interval to the record after which it is tombstoned.

  • Failure to release. If a client does not release a registration within the renewal period, the record is released automatically. The server assigns an extinction interval to the record, after which it is tombstoned.

  • Unable to contact primary WINS server. If the primary WINS server is unavailable when the client attempts to renew a registration, the client can renew with its secondary WINS server, if one has been configured. This can lead to an awkward situation where the primary server has an active record and the secondary server has a released record. To prevent this, if the client releases a registration to a WINS server that is not the owner, the record is immediately tombstoned.

  • Client crash. The WINS server has no way of knowing whether a client goes offline abnormally until the end of the renewal interval. The client record stays active and the server continues to hand out the client's IP address in response to query requests. If a client gets the address for a crashed client and attempts to use it, the connection attempt will fail. The client reports this failure to the WINS server, which checks the status of the client using a name query request. If the WINS server gets no reply, it releases the record with an extinction interval.

In a small network with one WINS server, this relatively simple sequence of events is sufficient to maintain database integrity, ensure name uniqueness, and give rapid response to lookup queries. In a big network with several WINS servers configured to replicate with each other, the situation becomes much more complex. Details are in "Functional Description of WINS Replication" later in the chapter. First, let's see how name resolution works.

Name Resolution Using WINS

When a WINS client needs to resolve a NetBIOS name associated with a service, the Netbt.sys driver sends a name lookup query to the WINS server. If the name contains a dot or is longer than 16 characters, Tcpip.sys considers it a DNS host name and uses the DNS resolver, not Netbt, to resolve the name.

When a WINS server receives a lookup query, it locates the record in the Jet database that contains the name registrations. If the record exists and if it is marked active, the WINS server returns a name lookup response with the IP address.

If a client is configured to use two WINS servers, a primary and a secondary, the client will query the secondary server if the primary server is unavailable.

Client Name Resolution Options

A Windows client can be configured to register and resolve NetBIOS names in one of two ways, broadcast or WINS. There are several combinations of these two methods. The combination used by a client is determined by its NetBIOS node type. There are four node types:

  • b-node (broadcast). The Netbt driver uses IP multicasts to register and resolve names. If there is a router, L3 switch, or intelligent bridge between the client and server, the name registration is only heard on the local subnet. This results in user complaints such as, "I'm looking in My Network Places and I can see the servers in my building but I can't see the servers in Building 303." b-node is the default node type if WINS is not enabled.

  • p-node (point-to-point). This method uses WINS exclusively. If a p-node client cannot find its WINS server, all registrations and resolutions fail.

  • m-node (mixed). This method avoids the complete reliance on WINS by first using broadcasts to resolve a name on a local subnet and contacting the WINS server if the broadcast fails.

  • h-node (hybrid). This method is not defined in RFC 1001 or 1002. Microsoft introduced it to reduce the broadcast traffic produced by m-node clients. An h-node client contacts WINS first and then falls back on local broadcasts only if the WINS query fails. This is the default node type if WINS is enabled.

Choosing a node type is a matter of balancing convenience, fault tolerance, and operational stability. b-node is generally a poor choice in all but the smallest networks. If you have a Windows server, you should configure it as a WINS server.

m-node is inadvisable for pretty much the same reason. Why broadcast if you have a WINS server? You may find situations, though, where an organization has slow WAN links and a single remote WINS server. If the majority of resources used by clients are local to their subnet, you can change the node type from h-node to m-node to increase the speed of local resource access.

The real choice for node type, in most cases, is between p-node and h-node. Here you have to weigh your alternatives. h-node seems like the rational alternative; in practice, however, h-node clients frequently generate broadcasts even when a WINS server is available. Also, h-node clients exhibit a tendency to hang a long time at logoff because they insist on deregistering both with WINS and by broadcast.

p-node clients, on the other hand, generate no broadcast traffic and break off the wire cleanly after they deregister at the WINS server, which takes a negligible amount of time. The problem with p-node is that you lose all NetBIOS name resolution if the WINS server goes down or is otherwise unavailable.

If you have a secondary WINS server and you can respond quickly if a server goes unavailable, you should choose p-node. If you have only one WINS server and want to maintain service continuity if the server goes down, opt for h-node.

Functional Description of WINS Replication

It is theoretically possible to handle NetBIOS name resolution for an entire global enterprise with a single WINS server equipped with only moderately powerful hardware (Pentium 400, 64MB RAM, 10MB NIC). Such a server can handle thousands of registrations a minute, enough to support a client community of 30,000 or so nodes.

Issues of fault tolerance and WAN traffic must also be considered. Generally, you should distribute WINS servers to each major office or LAN installation. If you have hundreds of small networks, such as a retail business, however, you do not need a WINS server in each location. Set up regional WINS servers and use the WAN for name registration/resolution.

Each WINS server maintains a database of the registration records requested by its clients. The server is said to be the owner of those records. A WINS server can replicate its database entries to other WINS servers that are configured as its replication partners. The servers each maintain a single database with records identified by owner. When a new replication partner is added, its database records are merged with the existing entries.

WINS uses two replication modes, somewhat reminiscent of Dr. Doolittle—a Push mode and a Pull mode:

  • Push mode. When accumulated changes reach a preset level, the WINS server contacts its replication partners and sends them the updates. Push replication is event driven.

  • Pull mode. A particular WINS server's replication partners periodically poll for updates. Pull replication is time driven.

Name registrations in the WINS databases of both partners are replicated to each other as they accumulate and at intervals throughout the day. WINS clients can use either these servers or both of them with one configured as a primary and the other as a secondary.

Registry Tip: Configuring the Netbt Node Type

You can set the Netbt node type in one of two ways. If you use DHCP, set scope option 44, WINS/NBNS Servers, to point at one or more WINS servers and then set scope option 46, WINS/NBT Node Type, for the desired node type. See Chapter 5 for details on configuring DHCP.

For non-DHCP clients, configure the node type locally in the Registry as follows:


HKLM | System | CurrentControlSet | NETBT | Parameters




1=b-node, 2=p-node, 4=m-node, 8=h-node

The default is b-node if the client does not have a WINS server configured for an interface and h-node if it does.

Registry Tip: WINS Database Parameters

The WINS database is named Wins.mdb. It is a Jet database, similar to that used by Access but with a different and incompatible format. The database and its support files are located in \Windows\System32\Wins.

The WINS database location and other WINS parameters are controlled by Registry keys under HKLM | System | CurrentControlSet | Services | WINS. The Partners key under WINS contains the IP address and control parameters for replication partners, if any.

WINS uses TCP/UDP port 42 for replication. This port was originally designated for Home Name Server (a kind of super Hosts file) that was abandoned in favor of DNS.

Only updated records are replicated between replication partners. This minimizes network traffic. Each record has a version ID that increments when the record is updated. In push replication, the server sends records with a version ID higher than the last batch that was sent to that particular partner. In pull replication, the pull partner sends a replication request containing the highest version ID it has received from that partner. The partner then sends updates with a higher version ID.

If you have a slow or expensive WAN link, you can use pull replication and set the replication interval relatively long. There are other possible combination of pushes and pulls, but for the most part they exist only for certification exam scenarios.

When you set up replication between multiple WINS servers, try to create a defined replication topology. You can use a ring, similar to Active Directory replication, where each WINS server replicates to the server on either side. Or, you can use a hub-and-spoke, where all WINS servers replicate to a central master, which then distributes the updates to the other servers. Most large organizations opt for hub-and-spoke because it is easier to manage and limits the number of hops required to replicate a change to the other WINS servers. Or, you can set up a meshed topology where all servers replicate to each other. This last option gives you the fastest convergence, but is the most prone to database anomalies. Regardless of the topology, be careful not to set yourself up for replication loops.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows