Do you understand WINS architecture? Well, you should! In this article, we’ll look at why it’s important to understand the WINS architecture for any network running Windows NT 4.0 or earlier, as well as for any network on which Windows 2000 will run in a mixed environment.

First, an introduction to WINS
The Windows Internet Name Service, a.k.a. WINS, functions as the domain and machine locator service for Windows NT networks. WINS locates network resources in a TCP/IP-based Microsoft network by automatically configuring and maintaining the computer name and IP-address mapping tables. It also serves basic functions, such as preventing duplicate network names. While Windows 2000 does not require WINS in a pure Win2K environment, WINS will always be required in a mixed environment, where Windows 2000 computers interoperate with other systems such as Windows NT 4.0, Windows 95, and Windows for Workgroups.

Optimizing your WINS can be fun!
Requests to WINS servers are directed datagrams, which means the requests are routed. Therefore, one WINS server is adequate in a network, although at least two are recommended to provide fault tolerance. One WINS server can service up to about 10,000 client registrations.

Generally, the fewer WINS servers, the better. An organization should consider adding WINS servers only in the following situations:

  • Inadequate bandwidth prevents the WINS server from promptly fulfilling client requests.
  • The links between clients and the WINS server are unreliable, and the organization can’t tolerate any loss of WINS service.
  • Network traffic is expected to be very high, and the organization wants to localize the WAN traffic. NetBIOS name resolution traffic is reduced, but WINS replication traffic is increased.

WINS static mappings for fun and profit
Certain nodes on a network, such as a server running UNIX, are incapable of registering a name with a WINS server. A WINS client can resolve these names if the client has a name-to-IP address entry in an LMHOSTS or HOSTS file or by querying a DNS server. However, a better solution is to enter the name-to-IP address mapping statically in the WINS server using the WINS Manager.

Static entries allow for faster name resolution because they let WINS clients resolve name-to-IP-address mapping by querying the WINS server. Secondary resolution methods, such as broadcast resolution, become unnecessary. Static entries also prevent the WINS server from allowing another WINS client to dynamically register the name. You can use the WINS Manager to enter static mappings either interactively or by importing an LMHOSTS file. Static mappings are never released and are never replaced by dynamic entries. You should use static mappings only for clients that are not WINS-aware.

Don’t you just love traffic?
WINS reduces the amount of broadcast traffic on the network. Except for broadcast traffic associated with logon requests and DHCP requests, network broadcast traffic can be reduced to nil if WINS is fully implemented.

WINS and WINS clients generate four types of traffic:

  • NetBIOS name registrations
  • Re-registrations and de-registrations
  • NetBIOS name requests
  • WINS database replications

Table 1 includes the WINS traffic summary.

Table 1
Service Traffic Frequency
WINS client to server Registration—two frames and
214 bytes


Renewal—two frames and
214 bytes


Resolution—two frames and
196 bytes

Once per service or
application at startup


Once per service or
application every one-half


Varying frequencies

WINS replication Database verification—12
frames and approximately
900 bytes


Database update—about 14
frames and about 2,100 bytes
(varies with # of updates)

Once per update request to
each replication partner


Once per update request to
each replication partner

WINS traffic summary

Based on the given information, you can draw the following conclusions regarding WINS’ impact on the network traffic and resource accessibility:

  • WINS generates little network traffic for name registrations and queries.
  • If the link to the primary and secondary WINS servers goes down, workstations can still access resources on server and workstations on the local subnet by issuing a local NetBIOS broadcast.
  • WINS replication traffic requires a TCP connection, so it generates more network traffic and server usage than name registration and query processes.

As the NetBIOS resolves
In many organizations, WINS clients requesting NetBIOS name-to-IP address mappings of various network devices will generate the largest amount of WINS-related traffic. Each request requires two frames to complete. The WINS client sends the name request directory to the WINS server using a UDP frame, which does not involve session establishment overhead. The size of the request message is 92 bytes. The response, which contains the IP address of the requested NetBIOS name, may range from 104 to 480 bytes.

By comparison, the broadcast method of NetBIOS name resolution requires sending three broadcast messages of 92 bytes each. Each device that has the requested NetBIOS name registered responds with a single frame of 104 bytes.

A client that needs to connect to a server will first check its name cache to see if it contains the server’s IP address; if it doesn’t, the client will send out a request.

If you have more than one home, you’re multihomed!
The term multihomed refers to a workstation or server that is configured with more than one TCP/IP address. NetBIOS over TCP/IP supports only one IP address per NIC, even if you’ve configured TCP/IP to have multiple IP addresses on a single NIC. A computer configured in that manner still registers only a single NetBIOS name and IP address with the WINS server.

A computer that needs to register multiple IP addresses must use multiple network adapter cards. Each card has its own unique IP address so the computer can register with WINS as multihomed. In this situation, the NetBIOS name references each of the IP addresses, and when a client queries that NetBIOS name, the WINS server returns all of the registered addresses in response.

It’s up to the WINS client to choose the “best” IP address to connect with a multihomed computer. Currently, the WINS client uses the following algorithm:

  • If one of the IP addresses in the name query list is on the same logical subnet as the calling binding of the NetBT on the local computer, the WINS client selects that address. If more than one of the addresses meets the criterion, the WINS client picks one at random from those that match.
  • If one of the IP addresses in the list resides on the same logical subnet as any binding of NetBT on the local computer, the WINS client selects that address. If more than one of the addresses meets this criterion, the WINS client picks one at random for those that match.
  • If none of the IP addresses in the list is on the same subnet as any binding of NetBT on the local machine, the WINS client selects an address at random.

WINS server can also be configured as multihomed systems, but for most enterprises this is not advisable, due to the name resolution and browsing problems.

Register your common NetBIOS names today!
Every service or application that supports NetBIOS must register NetBIOS names. Examples include workstation and server services, the Network Monitor application, and special names that indicate roles on the network, such as primary domain controller or backup domain controller . The actual number of names depends on the specific network services and applications the client computer initializes—typically, three or four names. Each name can be up to 15 characters long, with a sixteenth character that designates the service or application that owns the name.

Using default values, a client will refresh its name at half the renewal interval value. Under Windows NT 4.0, the NetBIOS name registration renewal process will occur every 72 hours for each client. If the administrator shortens the interval, network traffic increases as a result. By contrast, increasing the interval will reduce client-to-WINS traffic but will diminish database accuracy. The administrator must always ensure that the renewal interval is the same for primary and secondary WINS servers so the secondary server remains unused until necessary.

Every two days, each WINS-enabled client must re-register all of its NetBIOS names. Further, every time a server or workstation on the network is started, it registers each of its NetBIOS names with the WINS servers. When the computer shuts down, the names are de-registered. For this reason, it’s important to train users to log off and properly shut down their workstations so that the NetBIOS names can be properly cleared from the WINS database.

Interoperability fun for every network administrator
Earlier, we discussed WINS static mapping for nodes on a network that can’t register names with a WINS server. The WINS client can resolve those names via a number of methods, including by querying a DNS server. The DNS server provides hostname-to-IP address name resolution for non-NetBIOS network clients.

Although DNS is similar to WINS in certain respects, major differences do exist:

  • DNS is a static database for name-to-address mapping and must be manually updated by an administrator. By contrast, WINS allows computers to dynamically register their name-to-address mappings—a method that requires less administration than static mapping.
  • The DNS hierarchy allows database administration and replication to be segmented into zones. WINS, however, is a flat name space, without the concept of hierarchy; thus, each WINS server must maintain a complete database of entries—a feat accomplished through replication.

The DNS server works with the WINS server through a new (proprietary) record, which is defined as part of the zone database files. The WINS record instructs the domain name server to use WINS to look up any requests for hosts in the zone root that do not have static addresses in the IP database.

You want to be my WINS replication partner?
As we’ve mentioned, the WINS database is a flat, non-hierarchical namespace. Replication of database entries between servers ensures that any WINS-aware computer in the company can locate and connect to any other WINS-aware computer.

WINS servers maintain the database by means of replication partners. Each WINS server is a push partner or a pull partner, with at least one other WINS-based server. Push replication occurs based on the number of changes made to the WINS database. The push partner initiates replication by informing its partner that it has reached an update count for registrations and changes. Replicating on this basis helps keep WAN traffic to a minimum and ensures that the WINS changes are replicated expediently.

WINS also offers a Push With Propagation option that forces immediate WINS updates to all replications. Although this option increases database accuracy, it does so at the cost of increased network traffic; thus, use of this option is not advised on a sizable network.

Pull replication happens on a time interval. The pull partner replicates the database by asking its partner for all records with a higher version number than the last record stored from the last replication for that server. Replication pairs have the advantage of specifying a replication interval. If servers are connected by slow links, such as international connections, the replication interval can be set to keep link traffic to a minimum while still transferring updates. In addition, the network administrator can schedule WINS replication to occur after daily client registration traffic has peaked—typically after 10:00 A.M. on workdays. Doing so will improve available network bandwidth.
Do you have a story about using WINS in your network? Perhaps you would like to share your experiences with other TechRepublic readers. Feel free to post a message below. You can send us a note.