June 1, 2011, 1:02 p.m.
posted by vdv
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.
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.
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
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:
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:
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.
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.
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.