Home / Windows 7

Maintaining WINS

Windows Internet Naming Service (WINS) enables computers to register and resolve Network Basic Input/Output System (NetBIOS) names on Internet Protocol version 4 (IPv4) networks. WINS is not used with IPv6 networks. WINS is maintained primarily for backward support and compatibility with legacy applications and early versions of Microsoft Windows that used WINS for computer name resolution; or for networks running pre-Windows Server 2008 versions of Windows Server that don't have Active Directory deployed and thus don't require Domain Name System (DNS). On most large networks, WINS is needed to support legacy applications and legacy hooks into Active Directory from upgrades that proceeded from early versions of Windows Server to current versions.

If you are setting up a new network and there are no legacy operating systems, you probably don't need WINS. Here, only DNS is needed because these computers rely exclusively on DNS for name resolution if Active Directory is deployed. Because WINS is not required, WINS support could be removed from the network. Doing so, however, means that legacy applications and services that rely on NetBIOS, such as the computer Browser service, would no longer function.

WINS Essentials

Like DNS, WINS is a client/server protocol. All Windows servers have a WINS service that can be installed to provide WINS services on the network. All Windows computers have a WINS client that is installed automatically. The Workstation and Server services on computers are used to specify resources that are available, such as file shares. These resources have NetBIOS names as well.

NetBIOS namespace and scope

WINS architecture is very different from DNS. Unlike DNS, WINS has a flat namespace and doesn't use a hierarchy or tree. Each computer or resource on a Windows network has a NetBIOS name, which can be up to 15 characters long. This name must be unique on the network-no other computer or resource can have the same name. Although there are no extensions to this name per se that indicate a domain, a NetBIOS scope can be set in Dynamic Host Configuration Protocol (DHCP).

The NetBIOS scope is a hidden 16th character (suffix) for the NetBIOS name. It is used to limit the scope of communications for WINS clients. Only WINS clients with the same NetBIOS scope can communicate with each other.

Decommissioning WINS
WINS is needed to support legacy applications written to the NetBIOS over TCP/IP interface and to support network browsing for users in pre-Windows Server 2008 environments. If you don't have NetBIOS applications on the network or pre-Windows Server 2008 infrastructure, you don't need to use WINS. That said, before you decommission existing WINS infrastructure, you should ensure that your Active Directory domains and forests don't have legacy hooks that use the NetBIOS over TCP/IP interface. Your network might have legacy hooks that use NetBIOS if trusts were established in your domains and forests under early Windows Server releases and you subsequently upgraded to later releases of Windows Server. If so, you might need WINS to get the trusts verified and re-established. The only way to be certain that you don't need WINS in this situation where legacy hooks might exist is to perform a fresh install of the network environment with Windows Server 2003 or later and Active Directory operations in Windows Server 2003 Native Mode or higher.

If WINS is no longer needed on your network, you can look to decommission WINS. The best approach to decommissioning WINS is a methodical one that includes clear communication of your plan to decommission WINS throughout the organization as appropriate for IT guidelines. Start by examining the applications and server products in use throughout the organization that use or rely on network connections, such as Exchange Server, Systems Management Server, and Microsoft BackOffice Server. If the product version was developed and released prior to the release of Windows Vista and Windows Server 2008, the product might require NetBIOS naming. After you upgrade or replace applications and server products as appropriate, you can then enter the next phase of the transition where you stop and then disable the WINS service on your organization's WINS servers. This stops NetBIOS name resolution, without uninstalling your WINS servers. During this phase, you might find that some applications require WINS for name resolution. If so, you can enable WINS and then make plans to phase out those applications. Once you are certain there is no need for WINS, you can completely decommission WINS by removing the WINS Server feature from your servers.

NetBIOS node types

The way WINS works on a network is determined by the node type set for a client. The node type defines how name services work. WINS clients can be one of four node types:

B-Node (Broadcast Node):
Broadcast messages are used to register and resolve names. Computers that need to resolve a name broadcast a message to every host on the local network, requesting the IP address for a computer name. This node type is best for small networks.
P-Node (Peer-to-Peer Node):
WINS servers are used to register and resolve computer names to Internet Protocol (IP) addresses. Computers that need to resolve a name send a query message to the server and the server responds. This node type is best if you want to eliminate broadcasts. In some cases, however, resources might not be seen as available if the WINS server isn't updated by the computer providing the resources.
M-Node (Mixed Node):
A combination of B-Node and P-Node. WINS clients first try to use broadcasts for name resolution. If this fails, the clients then try using a WINS server. Using this node type still results in a lot of broadcast traffic.
H-Node (Hybrid Node):
A combination of B-Node and P-Node. WINS clients first try to use a WINS server for name resolution. If this fails, the clients then try broadcasts for name resolution. This node type is best for most networks that use WINS servers because it reduces broadcast traffic.

Small networks might not need a WINS server

WINS resolves NetBIOS computer names to IP addresses. Using WINS, the computer name DESKTOP12, for example, could be resolved to an IP address that enables computers on a Microsoft network to find one another and transfer information. On a small network without subnets and a limited number of computers, WINS clients can rely on broadcasts for name resolution. In this case, it isn't necessary to set up a WINS server.

WINS name registration and cache

WINS maintains a database of name-to-IP-address mappings automatically. Whenever a computer or resource becomes available, it registers itself with the WINS server to tell the server the name and IP address it is using. As long as no other computer or resource on the network is using that name, the WINS server accepts the request and registers the computer or resource in its database.

Name registration isn't permanent. Each name that is registered has a lease period associated with it, which is called its Time to Live (TTL). A WINS client must reregister its name before the lease expires, and it attempts to do so when 50 percent of the lease period has elapsed or when it is restarted. If a WINS client doesn't reregister its name, the lease expires and is marked for deletion from the WINS database. During normal shutdown, a WINS client sends a message to the WINS server requesting the release of the registration. The WINS server then marks the record for deletion. Whenever records are marked for deletion, they are said to be tombstoned.

As with DNS clients, WINS clients maintain a cache of NetBIOS names that have been looked up. The WINS cache, however, is designed to hold only names looked up recently. By default, names are cached for up to 10 minutes and the cache is limited to 16 names. You can view entries in the NetBIOS cache by typing nbtstat -c at the command prompt.

WINS implementation details

On most networks that use WINS, you'll want to configure at least two WINS servers for name resolution. When there are multiple WINS servers, you can configure replication of database entries between the servers. Replication allows for fault tolerance and load balancing by ensuring that entries in one server's database are replicated to its replication partners. These replication partners can then handle renewal and release requests from clients as if they held the primary registration in the first place.

WINS supports the following: