I seem to recall over the years moves to try to stop the requirement of having a WINS nameservice as part of a Windows environment.

My question is whether sites are still utilizing WINS or have switched over to something else and no longer need WINS. If so, anybody want to share their experiences?


15 Answers 15


A lot of these answers are only partially true or just plain wrong. WINS is just another way to resolve names to ip addresses. As long as your applications know how to use DNS, WINS is not needed at all.

Edit: Okay, I can't believe how much misinformation there is on this thread. First of all, having different subnets does not necessitate the use of WINS. As long as your application can communicate with udp/tcp port 53 on your DNS server(s), you will be able to resolve hostnames just fine (yes, \\hostname will work too).

Secondly, if you're wondering why you can't resolve anything using the short hostname (i.e. just the hostname without the domain), it's probably because you never configured the default domain (or domain search list) on your clients.

And lastly (but not leastly!), an Active Directory domain is not a prerequisite for using DNS on a Windows network. The only reason you think that is because when you join a machine to a domain, Windows sets the default domain name for you. There is nothing preventing you from setting it yourself through other means (probably DHCP).

So in summary, just set the default domain and use DNS like the rest of us here in the 21st century!

  • 2
    I'm actually kinda stunned that this answer is being voted so high. Wins work with netbios names- not hostnames.
    – Jim B
    Jun 2, 2009 at 3:25
  • 1
    Who cares? Yes, DNS and WINS work differently, but they both solve the same problem (resolving names to IPs), and if you're running DNS (which you had better be in this day and age), then WINS is almost definitely unnecessary. The point is that people should not be running services just because they "think they might need them for some reason." Superstitious administration like that leads to the IT-equivalent of Rube Goldberg machines. Jun 2, 2009 at 12:01
  • 3
    I will not downvote you (it's not my style), but I can't upvote your answer when I know better. You can turn off WINS in some cases, but not all cases. And there's the heart of it - no matter how hard you try, you won't always be able to escape WINS. Jun 2, 2009 at 13:07
  • 2
    This is probably the MOST wrong of all of the answers. :( Sad it is voted so high.
    – Jim March
    Jun 2, 2009 at 13:57
  • 1
    @Jason, WINS is actually still required for some products becuase resolves a very specific type of name - a netbios name
    – Jim B
    Jan 19, 2011 at 1:22

wins is still required for a bunch of things (less and less every day!). The most common example I've seen is that wins is a requirement for running exchange 2007 on clustered 2003 servers. Wins works with Netbios names. A NetBIOS name is an identifier used by NetBIOS services running on a computer. It is combination of a 15 character (byte) name and a 16th character denoting the service. When identifying NetBIOS network resources, these names are used. NetBIOS can not do name resolution on the Internet. NetBIOS names are single part names and don't have any hierarchical structure.

The NetBIOS namespace is flat, which means that there are no suffixes added to the NetBIOS name and that two computers cannot have the same NetBIOS name. This means that each NetBIOS name in any one network must be unique.

See TCP/IP Fundamentals for Microsoft Windows ,Chapter 11 - NetBIOS over TCP/IP

  • I think this should have been voted the correct answer. Nov 25, 2010 at 0:35

In our Enterprise it is still required for many legacy applications.

Felt I needed to edit this since the most upvoted answer is flat out WRONG!

WINS is definitely required in many oraganizations these days.

How WINS works Updated: January 21, 2005

How WINS works By default, when a computer running Microsoft® Windows® 2000, Windows XP, or a Windows Server 2003 operating system is configured with WINS server addresses (either manually or through DHCP) for its name resolution, it uses hybrid node (h-node) as its node type for NetBIOS name registration unless another NetBIOS node type is configured. For NetBIOS name query and resolution, it also uses h-node behavior, but with a few differences.

For NetBIOS name resolution, a WINS client typically performs the following general sequence of steps to resolve a name:

Client checks to see if the name queried is its local NetBIOS computer name, which it owns.

Client checks its local NetBIOS name cache of remote names. Any name resolved for a remote client is placed in this cache where it remains for 10 minutes.

Client forwards the NetBIOS query to its configured primary WINS server. If the primary WINS server fails to answer the query--either because it is not available or because it does not have an entry for the name--the client will try to contact other configured WINS servers in the order they are listed and configured for its use.

Client broadcasts the NetBIOS query to the local subnet.

Client checks the Lmhosts file for a match to the query, if it is configured to use the Lmhosts file.

Client tries the Hosts file and then a DNS server, if it is configured for one.

The problem is that not every application can be configured to use DNS.

Even in Microsofts own explination of Active Directory setup it mentions the need for WINS.

Settup Up DNS

"NetBIOS name resolution (WINS server, LMHosts file, or NetBIOS broadcast) is still required for earlier versions of Windows to resolve network resources on an Active Directory domain."

So yes, there are SOME organizations that can get away without using WINS, but to make a blanket statement that if you can hit the DNS server you magically do not need WINS is wrong.


WINS is still very much a requirement, despite every attempt by every Windows admin in the world to bludgeon it to death. Anytime there is a separation of subnets, you're going to need WINS. Running a VPN for separate sites? That implies a subnet - and WINS. Have older clients that don't understand AD? You need WINS. Have a DOS application that you're networking? WINS again.

WINS is also used for populating browse lists. While Active Directory based machines can work without WINS, there can be a delay as the browse lists are populated in the following sequence:

  1. NetBIOS Remote Name Cache
  2. WINS
  3. Broadcast
  5. HOSTS
  6. DNS

The crux of the problem stems from the roots of LANMAN, which begat SMB, which begat CIFS...you can see where this is going. LANMAN was very much a LAN-based protocol - it had no concept of "Internet", much less "routing". WINS was developed to bridge that gap and make routing possible. Fast-forward to the present, and CIFS still has some backwards-compatible support for LANMAN in it. UNC path names may be "modern", but they will still attach to a LANMAN server. Then there's the whole "browse list" thing...

MS is very close to getting out of the WINS server biz but there are just too many "legacy" hooks, not only in the OS, but in applications and services as well, that require a WINS server. And as long as there is support for LANMAN-style transmissions, there will be a need to have a WINS server around.


Yes, you can turn off WINS in a flat domain.


  • Try that in a domain that has abc.xyz.com and abc.123.com as child domains. Can you say "browse list fun" three times fast?
  • Try that with Exchange 2007 in some cases.
  • Try that when you have servers that exist outside of your subnet and are traversing a firewall. Somehow, there just seems to be trouble with those browse lists...

As much as I want to see this service have a stake driven through its heart, it's not going to go away until Microsoft comes 'round and revamps how they do LAN services. (Yes, there is a comment at that link about how it's not needed as well...but go read through what's being said by the horse's mouth...)

  • 3
    browselistfunbrowselistfunbrowselistfun Mar 4, 2010 at 22:27
  • +1, you get a cookie. Or a coffee. Or espresso. Or whatever it is you like as a treat. Mar 5, 2010 at 23:00

Lets not get confused between wins and netbios..... you can run netbios on a network without a WINS server, but it's not recommended on a domain. You don't really want all those funky elections going on when you have a proper DNS server on the network, so netbios should either be disabled or a WINS server should be used. (I use proper in the loosest sense of the term where MS DNS is concerned :-) )

Recently I had a problem with Exchange 2007 on Windows 2008 requiring netbios to be enabled. unbelievable!!!


Many of these answers are incorrect or partially correct. First lets figure out why WINS may be used in the first place.

WINS is used as a solution to resolve hostnames to IP addresses... but why would we need WINS if NetBIOS works in all senerios? Read on!

DNS used for same purpose & more... to resolve fully qualified domain names AND hostnames to IP addresses.

Now lets look at why WINS was developed.

Problem: NetBIOS was originally used to resolve names but its a broadcast network protocol. So in most networks, legacey and current, broadcast traffic is unable to traverse routers, and soon enough firewalls, later on we find that also in VPN traffic. So, most subnets won't replicate NetBIOS traffic to other subnets. If you are a real IT Network Administrator, you will be familiar with this NetBIOS traffic on routers, switches, and firewalls:

UDP access denied by ACL from HOST-17/137 to inside:

UDP access denied by ACL from HOST-A/137 to inside:

UDP access denied by ACL from HOST-09/137 to inside:

UDP access denied by ACL from HOST-02/137 to inside:

UDP access denied by ACL from HOST-02/137 to inside:

This is an example of five (5) NetBIOS broadcasts on a 25 bit network from a Cisco Pix 515E Firewall syslog file. For those not familiar with anything other than a what their linksys router is a 25 bit network is smaller than your 24 bit network:

Network:, Subnet Mask:, Broadcast Address:, Max Hosts: 126. As can be seen, the traffic is being contained within the segment.

Solution: WINS is developed to deploy across on subnet where broadcast traffic is contained, clients can configured and pointed at a WINS server to resolve names instead of relying on broadcast traffic and thus NetBios now becomes the fallback when WINS queries fail.

But wait... we configure DNS Servers now when we deploy our microsoft networks. Now DNS is primary, when DNS fails, NetBIOS is the fallback. If there is a WINS server deployed, DNS, WINS, and NetBIOS.

The problem that many may be running into is when they try to ping a hostname, lets say HOST-A. Depending on the computers interface configuration, it may not be able to resolve the address to an IP, primarily if you have just DNS configured and the hosts registered NetBIOS names have expired.

Lets say HOST-A is a part of domainhosts.com and was joined to that domain, an (A) record of the host on the primary DC DNS server for domainhosts.com. To resolve the address by just its hostname and not its FQDN (fully qualified domain name) the IP configuration must have "Append primary and connection specific DNS suffixes" and have the the very least of "DNS Suffix for this connection: domainhosts.com" populated! When resolution is perform of HOST-A two (2) peices of extra information is returned: The IP address the hostname resolves to and its FQDN of HOST-A.domainhosts.com. In the example below the resolution of a hostname is performed by searching the (A) records of the domain instead of WINS or NetBIOS:

[User@localhost ~]$ ping HOST-A

PING HOST-A.domainhosts.com ( 56(84) bytes of data.

64 bytes from HOST-A.domainhosts.com ( icmp_seq=1 ttl=128 time=0.826 ms

64 bytes from HOST-A.domainhosts.com ( icmp_seq=2 ttl=128 time=0.342 ms

In addition to having just the primary DNS Suffix populated, you can have the hosts search others as well, and configure them to append in different orders. Thus eliminating WINS & NetBIOS all together.

Now there will be some out there who say "You will need NetBIOS and WINS for microsoft products to work." This is true in reality, but only for a few products, most of which will not be deployed in small or medium sized businesses and only in large enterprise environments, applications such as SMS 2003 with its use of the 1A record, SQL Server 2000 for use of named pipes, and Exchange Server 2000 and 2003 all require WINS for full functionality... FULL Functionality, they will ALL work as needed without WINS or NetBIOS though.

Oh yeah, and only if you are pre-2000 Microsoft deploys. I got a better solution for you than deploying WINS though... UPGRADE!!


I've been in environments where it's still maintained because 'some legacy servers' might need it.

I think there's probably a lot of shops out there that are in the same situation.


I once enabled WINS on a samba server at work. It was the fastest and cheapest (in terms of spent time) solution of name resolution in a windows network without a domain. It's simple and works good in a small network.


Many embedded devices use WINS as well. We have multi-function copy machines and a very recently purchased wireless projection system that wouldn't work till I gave it the IP of a WINS server.

As much as we'd like to, WINS will be here for a long time.


A few months ago I stopped the WINS service on our LAN. After a few weeks, I removed it entirely. I wonder how many years it's been running for no particular reason? In some environments I'm sure this will be impossible. It's possible we've had issues since then that would've been invisible with WINS still running. I guess I'm a purist, but WINS reminds me of playing "slop" pool. A shot shouldn't count unless you were aiming for that pocket!


One thing nobody has mentioned is that it is necessary for VPN sites on separate subnets if you want to resolve NetBIOS names. Consider this scenario:

The corporate network utilizes a private 10.x.x.x LAN and a remote office uses a private 192.x.x.x LAN. They have a VPN tunnel between them, but the remote office does not take DHCP through the tunnel from the corporate DHCP server or firewall.

If you have your corporate servers registered with WINS, the remote clients can resolve \ServerName even from an entirely separate subnet. Eventaully I will be able to upgrade the remote office firewall and use DHCP over VPN, but for now this setup allows me to:

  • Not have to remember server IP addresses when working on the remote PCs.
  • Use the same logon scripts which map network drives based on NetBIOS names rather than IP addresses.
  • Keep everything more consistent in general.

Somebody please correct me if I'm wrong on this, but my understanding is that NetBIOS is not routable, so I can't resolve NetBIOS names across the subnet without using WINS.

  • DNS still works perfectly in this situation, though, so WINS still isn't necessary.
    – Jeff Miles
    Jun 2, 2009 at 13:36
  • No it doesn't. The remote firewall doesn't know anything about the corporate DNS servers, so how could it resolve corporate DNS names? Jun 2, 2009 at 15:15
  • 1
    DNS does work perfectly. In linux, use your search function in /etc/resolv.conf or in windows append the correct suffixes. If DNS is not working properly, than you have failed the setup in your environment. Jul 29, 2009 at 21:34
  • "NetBIOS is not routable" - I did a trace once on a machine that had WINS disabled, DNS disabled and NetBios over TCP/IP enabled. A query for a name in the same network, generated a single broadcast, answered by the local Browse Master. With that Browse Master turned off, the client sent X (can't remember but it was >=10) broadcasts before another client responded. And when a query was made for a machine on another network, the client broadcast 100 queries and then received a response from a machine in that second network. Netbios must have a mechanism for forwarding requests between networks. May 27, 2011 at 19:58
  • 1
    NetBios is very resilient and might be picking up the slack more often than people know (like on networks with WINS disabled). May 27, 2011 at 19:58

Oh, we're still using it. About a third of the Windows workstations we have are not in the domain and thus aren't configured to use the domain's DNS domains for name resolution. Also, we have a monstrously fragmented DNS landscape which leads to monstrously fragmented default-domain settings. Because of this WINS represents the single name-resolution service that has the most stuff in it. It's the closest we have to a global index of services.

If/When we push to get everything domained, we'll have a flat DNS landscape. That will be good.

  • +1, excellent example of why the monster yet still lives...grab your torch and pitchforks! Aug 6, 2009 at 15:15

Legacy Exchange still uses WINS, so anyone looking at raising functional levels to 2008 or 2012 and still using WINS, if you are using Exchange 2003 or earlier (hopefully not) you will still need WINS enabled.

Also, any apps or scripts that do not use FQDN in a multi-domain environment will likely have issues.

WINS can be removed but it should be methodically tested and in large corporations with a lot of apps, SAP, Exchange and other legacy apps running it almost isnt worth it until you can get to 2012 native on your domain which will help with the decom of WINS.

  • Microsoft makes (made) a recommendation for WINS in certain scenarios and for specific functions. WINS was never a requirement AFAIK. I've never used WINS with Exchange Server 2000 or 2003. - support.microsoft.com/kb/837391
    – joeqwerty
    Feb 4, 2015 at 0:05

I for one, do not use WINS and have not used WINS for 4 years. Microsoft DDNS does a fine job of name resolution on an Active Directory network. I can't think of a program that requires WINS right now, but I remember a few. Guardian Firewall required it on the LAN side NIC back in the day.

2007 Exchange Clusters do not require WINS. According to the documentation I have, MS recommends the use of HOST files, believe it or not, in that setup since the IP's don't change.

My only issue with DDNS, is across WAN. DDNS + ADC on each WAN segment... frequently I have issues with DDNS updating either other's name tables.

WINS is fine for a Class C network where you have no remote sites or WAN links. One huge thing against WINS... SSL VPN + WINS = typing in IP's cuz WINS ain't goona werk.


Our environment has not used WINS for many months, and have seen no adverse affects because of it. We have a multi-site topology through VPN connections, with Exchange 2003 as our email service.

WINS should only be enabled if it is specifically required to solve a known issue. Holding onto antiquated technology "just in case" makes no sense when you have ensured that it is not required.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.