WINS consists of the following two components:
The WINS server, which handles name queries and registrations
Client software, which queries for computer name resolution
Windows networking clients (WINS-enabled Windows NT, Windows 98, Windows 95, or Windows for Workgroups 3.11 computers) can use WINS directly. Non-WINS computers on the internetwork that are b-node compatible (as described in RFCs 1001 and 1002) can access WINS through proxies (WINS-enabled computers that listen to name-query broadcasts and then respond for names that are not on the local subnet).
To allow browsing without WINS, the network administrator must ensure that the users' primary domain has SunLink Server, Windows NT Server, or Windows NT Workstation computers on both sides of the router to act as master browsers. These computers need correctly configured LMHOSTS files with entries for the domain controllers across the subnet.
With WINS, such strategies are not necessary because the WINS servers and proxies transparently provide the support necessary for browsing across routers where domains span the routers.
If a client computer running Windows NT also is DHCP-enabled, and if the administrator specifies WINS server information as part of the DHCP options, the computer automatically will be configured with WINS server information.
In a WINS and broadcast name resolution environment, a WINS-enabled client computer will behave in a different manner than a non-WINS-enabled client computer. These differences will be apparent in the way these clients handle resolution, registration, release, and renewal, described in the next sections.
With WINS servers in place on the internetwork, NetBIOS computer names are resolved using two basic methods depending on whether WINS resolution is available and enabled on the client computer. Regardless of which name resolution method is used, the process is not visible to the user after the system is configured.
If WINS is not enabled on the client - The computer registers its name by sending name registration request packets (as broadcast messages) to the local subnet. To find a particular computer, the non-WINS computer sends name query request packets (as broadcast messages) on the local subnet. (This broadcast message cannot be passed on through IP routers.) If local name resolution fails, the local LMHOSTS file is consulted. These processes are followed whether the computer is a network server, a workstation, or another device.
If WINS is enabled on the client - The computer first queries the WINS server. If this fails, it sends name registration and query requests (as broadcast messages) in the following series of steps:
A client's name query request is sent first to the WINS server. If the name is found in the WINS database, then the client can establish a session based on the address mapping received from the WINS server.
If the WINS server query is unsuccessful and if the client computer is configured as an h-node, the client computer sends name query request packets (as broadcast messages) in the same manner as a non-WINS-enabled computer.
Finally, if other methods fail, the local LMHOSTS file is checked. (Included in the search are any centralized LMHOSTS files referred to in #INCLUDE statements in the local file.)
WINS servers accept and respond to User Datagram Protocol (UDP) name queries. Any name-to-IP address mapping registered with a WINS server can be provided reliably as a response to a name query. However, a mapping in the database does not ensure that the related device is currently running, only that a computer claimed the particular IP address and that it currently is a valid mapping.
Name registration ensures that the NetBIOS computer name and IP address are unique for each device.
If WINS is enabled on the client - The name registration request is sent directly to the WINS server to be added to the database. A WINS server accepts or rejects a computer name registration depending on the current contents of its database, as follows:
If the database contains a different address for that name, WINS challenges the current entry to determine whether that device still claims the name.
If another device is using that name, WINS rejects the new name registration request.
Otherwise, WINS accepts the entry and adds it to its local database together with a time stamp, an incremental unique version number, and other information.
If WINS is not enabled on the client - For a non-WINS computer to register its name, a name registration request packet is broadcast to the local network stating its NetBIOS computer name and IP address. Any device on the network that previously claimed that name challenges the name registration (with a negative name registration response), resulting in an error for the computer attempting to register the duplicate name. If the name registration request remains unchallenged for a specific time period, the requesting computer adopts that name and address.
After a non-WINS computer claims a name, it must challenge duplicate name registration attempts (with a negative name registration response) and respond positively to name queries issued on its registered name (with a positive name query response). The positive name query response contains the IP address of the computer so that the two systems can establish a session.
When a computer finishes using a particular name, it no longer challenges other registration requests for the name. This is referred to as releasing a name.
If WINS is enabled on the client - Whenever a computer is shut down properly, it releases its name to the WINS server, which marks the related database entry as released. If the entry remains released for a certain period of time, the WINS server marks it as extinct, updates the version number, and notifies other WINS servers of the change.
If a name is marked released at a WINS server, and a new registration arrives using that name but a different address, the WINS server immediately can give that name to the requesting client because it knows that the old client no longer is using that name. This might happen, for example, when a DHCP-enabled laptop changes subnets.
If the computer released its name during an orderly shutdown, the WINS server does not challenge the name when the computer is reconnected. If an orderly shutdown did not occur, the name registration with a new address causes the WINS server to challenge the registration. The challenge fails and the registration succeeds, because the computer no longer has the old address.
If WINS is not enabled on the client - When a non-WINS computer releases a name, a broadcast is made to allow any systems on the network that might have cached the name to remove it. Upon receiving name query packets specifying the deleted name, computers simply ignore the request, allowing other computers on the network to acquire the released name.
For non-WINS computers to be accessible from other subnets, their names must be added as static entries to the WINS database or in the LMHOSTS file(s) on the remote system(s) because they will respond only to name queries that originate on their local subnet.
Client computers periodically are required to renew their NetBIOS name registrations with the WINS server. When a client computer first registers with a WINS server, the WINS server returns a message that indicates when the client will need to renew its registration, as follows:
Default renewal interval for entries in the WINS database is six days.
WINS clients register and refresh every three days.
Primary and backup WINS servers should have the same renewal interval.
An entry defined as static never expires.
If the entry is owned by the local WINS server, the name is released at the specified time unless the client has renewed it. If the entry is owned by another WINS server, the entry is revalidated at the specified time. If the entry does not exist in the database of the WINS server that owns the entry, it is removed from the local WINS database. A name renewal request is treated as a new name registration.
Incorrectly adjusting the renewal interval might adversely affect system and network performance.