Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 2

Windows Internet Name Service (WINS)

Windows Internet Name Service (WINS) was developed by Microsoft to provide a DNS-like Net-BIOS
Name Service (NBNS) to map NetBIOS names to IP addresses. The “Internet” in WINS is a little
misleading, because a NetBIOS name on the Internet is like a goldfish trying to breathe in olive oil. In
essence, it also signifies taking a NetBIOS name and turning it into a neo-host name that can be
mapped to an IP address, and as long as IP rules supreme and you take the input/output out of
NetBIOS, it is nothing more than a label, even at the functional or application levels of the network.

WINS is more than just a name-IP address resolver, however. It enables centralized management of
NetBIOS namespace data and eliminates the need to remotely manage multiple LMHOSTS file
(which perform the same function for NetBIOS lookup that Hosts files perform for DNS lookup).

WINS also helps reduce NetBIOS broadcasts on the network to maximize bandwidth utilization,
because clients can query the WINS server for a name-to-address mapping, enabling them to
communicate directly with remote hosts, rather than generate broadcast traffic on the network.

WINS is needed on old Windows networks because the only way that the down-level operating
systems flag their presence is via NetBIOS; and in many respects, it has been convenient even since
the days that TCP/IP first showed up. Imagine a Windows network on which every server were listed
under only its IP address.

WINS is also essential for getting those NetBIOS names resolved over TCP/IP subnets. NetBIOS is not
routable, and it was never intended to be; nor are the primary protocols that carry Net-BIOS names,
such as NetBEUI (although they can be encapsulated in TCP/IP communication packets that can be
routed, a practice often used to route SNA traffic over TCP/IP). The only way, then, for NetBIOS to
coexist in the routable world of IP addresses and IP internetworks is via WINS.

Microsoft's strategy, in line with all the other Internet builders, is to abolish reliance on NetBIOS and
to support TCP/IP and its successors as the only routable protocol on all networks. This strategy
enables network administrators to gradually abolish NetBIOS from their networks as they replace
down-level or NetBIOS-named computers and devices, and enables them to switch to native mode
Windows Server 2008 deployment, which is more secure and rich.

However, for many companies, expect WINS and NetBIOS to be around for many years. In fact, we
predict that the last vestiges of NetBIOS, and thus WINS, are not going to vanish for a few years yet.
Change is not an overnight phenomenon in large corporate environments, where huge investments
in corporate intranets are also underway. In fact, had it not been for Y2K, many companies would
have kept Windows NTI 3.51 around. The reasons to keep WINS around are patent if you consider
the following two inescapable facts:

 Investment in legacy systems. NetBIOS has been the driving force on Windows net-works
since the advent of the networkable personal computer. In all those years, Windows has
become the pervasive desktop operating system, and it is now poised to become the
dominant server operating system.
 Our guess is that no one really knows how many copies of Windows are running in the
world. Estimates range from tens of millions to hundreds of millions, so a huge investment in
legacy, or so-called down-level, Windows operating systems still exists, from simple clients
to mega-servers, and is likely to remain so for many years to come. Insofar as these systems,
especially the servers, still use NetBIOS names, WINS is needed to resolve these names into
IP addresses. In short, the best of both worlds — an entrenched namespace coexisting with
an indispensable protocol.
 Investment in legacy applications. Many applications still use NetBIOS names in their code,
so NetBIOS remains a fact on these networks until all applications no longer depend on
NetBIOS or they can be removed from your network and information systems.

How WINS Works


All Windows 9x and later operating systems can request services of WINS. To request a name-IP
address resolution, the client queries any WINS server designated to it on the network. It tries to
contact WINS servers in the order assigned in the WINS address list in its TCP/IP configuration.

The client tries to connect to the WINS server three times before giving up and moving on to the
next WINS server in the list.

After the client boots and authenticates on the network, it registers its name and IP address with the
designated WINS server. If the client does not register automatically, the registration takes place
whenever the client next makes a query or targets a folder on a remote server.

The process to connect to a NetBIOS name by using TCP/IP is as follows:

 Computer MCSOLO1 logs on to the network and makes a registration request with WINS.
The NetBIOS name and IP address are thus recorded to the WINS database.

 You come along and you need to connect workstation SQLCLIENT {at 10.5.4.132)
to\\MCSQLOL\SHARE] (at 100.50. 2.32), which you see in the browse list. SOLCLIENT needs
to make a request of the WINS server for the IP address of MCSQLO1 to effect a connection
Lo the server via TCP/IP. In other words, the client needs Lo turn the target
address\\MCSOLOL\MY SHARE into \\100.50.2.32\MYSHARE because the only way to
connect to the remote server, via several routers, is TCP/IP.

 If the WINS server is unavailable, then SQL CLIENT tries two more times before trying the
next WINS server in its list. Assuming that MCSOQLO1 happens to register with WINS and an
IP address exists, the resolve is successful and the connection can he established.

 Finally (and we are not being cheeky because we have needed to do this on many occasions
with the old WINS), if you cannot see or connect to the share, you can phone the owner or
admin of the server and ask for the IP address. For network administrators to do this to
troubleshoot connections is okay. For users to do this every time that they need a file or a
printer, however, is not okay.

You might also like