Do You Still Need a WINS Server?

Published:14 April 2021 - 3 min. read

Elly Obare Image

Elly Obare

Read more tutorials by Elly Obare!

What once was a part of just about every network out there, a WINS server was once a requirement. But, is it still needed today?

In this article, you’re going to learn a bit about WINS, what it’s used for to get an idea if you still actually need that old WINS server hanging around on your network.

To Understand WINS is to Understand NetBIOS

Computers communicate through protocols such as TCP/IP using number schemes via IP addresses. To prevent having to remember all of those numbers, a method to “label” those IP addresses with names came up. By assigning names to each computer on a network, one could manage them much easier.

One of the first ways to map names to IP addresses was Network Basic Input/ Output System or NetBIOS. NetBIOS or, more specifically, NetBIOS over TCP/IP or NetBT is a service that operates at the session layer of the OSI model and runs on TCP/IP protocol to facilitate device-to-device identification and communication on a network.

NetBT traditionally resolved names over a network by sending broadcast query messages over TCP/IP. NetBIOS most notably is non-routable. NetBIOS name resolution cannot happen over multiple networks. To remedy this, Microsoft developed a NetBIOS Naming Service or what most call WINS to resolve names across routed networks.


NetBIOS had a major problem; it couldn’t be routed to other networks. Companies were starting to need many networks to segment off traffic and NetBIOS couldn’t be routed across those networks. What to do? Introduce a new protocol; Windows Internet Naming Service (WINS).

Using WINS, admins could now route name traffic across networks because it relied on the TCP/IP protocol. If admins used WINS, they also had a central place all computers could register their names and IP addresses.

How WINS Servers (and Clients) Work

WINS is a client-server system consisting of two primary components; the WINS client running on a Windows computer and a WINS server hosting a database with various records representing hostname to IP address mappings.

Client Registration and Resolution

Once a WINS server is made available on a network for clients to use, the clients interact with the server in three primary methods; assignment, registration, and name resolution.

Client Assignment

To become a member of the WINS name resolution process, a Windows computer must first know what WINS server it’s going to communicate with. To do this, the Windows computer (WINS client) is assigned a WINS server either manually or DHCP.

Once pointed to a WINS server, the client then attempts to register itself with the server thus creating a hostname to IP address mapping in the WINS database.

Client Registration

Once a WIN client first comes online, it will first send out a request to confirm it holds a unique hostname. This step is necessary to avoid name duplication. Once no other name is found on the network, the client will then register itself in the WINS database.

Client Name Resolution

After some time after all WINS clients have received the WINS server to point to and have registered themselves, all clients can resolve all other client names through name resolution even across different networks. They perform this name resolution by querying the WINS server with NetBIOS name queries and responding to the requests with the correct IP addresses of the specific machines.

  • Clients removed from the network will eventually be released from the WINS database in a task known as tombstoning.

Server Replication

The WINS ecosystem isn’t just relegated to many clients communicating with a single WINS server. Many networks still maintain many WINS servers that replicate database records to other WINS servers through replication partners.

A WINS replication partner can be either configured in a pull or push manner. Pull replication partners request updated database records from Push partners. These requests occur every 15 minutes or in response to an update notification from a Push partner.

In a large network, you should configure all WINS servers as both pull and push partners to provide up-to-date database entries for all WINS servers in the network.

Limitations of WINS

Although, WINS, at one time, helped organizations go from non-routable NetBIOS name resolution to a routable and scalable solution but it’s now outdated and considered legacy. Why? Mainly DNS.

WINS offered a flat namespace that required a name to only be used once on a network. This drawback is that it didn’t work too well on large networks.

Also, although WINS has replication options for redundancy, this can lead to a system that is overly complex and which poses troubleshooting problems.


Decades ago, Windows clients identified network devices by their NetBIOS names thus the requirement for WINS. But, nowadays, WINS is not required on modern machines starting with Windows 2000.

Some organizations running legacy applications such as Microsoft Systems Management Server (SMS) or Microsoft BackOffice Server for client/server mail configurations, may still need WINS.

WINS is now an obsolete technology that Microsoft has sunset in favor of other protocols like DNS which is more suited for name resolution in environments that run on Windows Servers 2000 and above.

But, if you must support Windows NT servers and workstation applications, you may need it.

Hate ads? Want to support the writer? Get many of our tutorials packaged as an ATA Guidebook.

Explore ATA Guidebooks

Looks like you're offline!