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?
Thanks.
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!
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.
"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 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
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:
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.
EDIT:
Yes, you can turn off WINS in a flat domain.
However...
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...)
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:10.0.1.127/137
UDP access denied by ACL from HOST-A/137 to inside:10.0.1.127/137
UDP access denied by ACL from HOST-09/137 to inside:10.0.1.127/137
UDP access denied by ACL from HOST-02/137 to inside:10.0.1.127/137
UDP access denied by ACL from HOST-02/137 to inside:10.0.1.127/137
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: 10.0.1.0/25, Subnet Mask: 255.255.255.128, Broadcast Address: 10.0.1.127, 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 (10.0.1.10) 56(84) bytes of data.
64 bytes from HOST-A.domainhosts.com (10.0.1.10): icmp_seq=1 ttl=128 time=0.826 ms
64 bytes from HOST-A.domainhosts.com (10.0.1.10): 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.
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.
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:
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.
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.
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.
