Answers:
这些答案中有很多只是部分正确或完全错误。WINS只是将名称解析为IP地址的另一种方法。只要您的应用程序知道如何使用DNS，就根本不需要WINS。
编辑：好的，我不敢相信这个线程上有多少错误信息。首先，拥有不同的子网不一定需要使用WINS。只要您的应用程序可以与DNS服务器上的udp / tcp端口53通信，您就可以解析主机名（是的，\\ hostname也可以）。
其次，如果您想知道为什么使用短主机名（即没有域的主机名）无法解析任何内容，那可能是因为您从未在客户端上配置默认域（或域搜索列表）。
最后（但并非最不重要！），Active Directory域不是在Windows网络上使用DNS的先决条件。您认为的唯一原因是因为将计算机加入域时，Windows会为您设置默认域名。没有什么可以阻止您通过其他方式（可能是DHCP）自行设置的。
因此，总而言之，只需设置默认域并像21世纪的其他人一样使用DNS！
一堆事情仍然需要胜利（每天越来越少！）。我见过的最常见的示例是，在集群2003服务器上运行Exchange 2007的要求是获胜。Wins使用Netbios名称。NetBIOS名称是计算机上运行的NetBIOS服务使用的标识符。它是一个15个字符（字节）的名称和一个表示服务的第16个字符的组合。标识NetBIOS网络资源时，将使用这些名称。NetBIOS无法在Internet上进行名称解析。NetBIOS名称是单个部件名称，没有任何层次结构。
NetBIOS名称空间是扁平的，这意味着没有后缀添加到NetBIOS名称，并且两台计算机不能具有相同的NetBIOS名称。这意味着任何一个网络中的每个NetBIOS名称都必须是唯一的。
在我们的企业中，许多旧版应用程序仍然需要它。
觉得我需要进行编辑，因为最受好评的答案很差劲！
如今，在许多组织机构中绝对需要WINS。
WINS的工作方式更新：2005年1月21日
WINS的工作方式默认情况下，当为运行Microsoft®Windows®2000，Windows XP或Windows Server 2003操作系统的计算机配置了WINS服务器地址（手动或通过DHCP）以进行名称解析时，它将使用混合节点（h -node）作为其用于NetBIOS名称注册的节点类型，除非配置了另一个NetBIOS节点类型。对于NetBIOS名称查询和解析，它还使用h节点行为，但有一些区别。
对于NetBIOS名称解析，WINS客户端通常执行以下一般步骤来解析名称：
客户端检查查询的名称是否为其本地NetBIOS计算机名称。
客户端检查其本地NetBIOS名称缓存的远程名称。为远程客户端解析的任何名称都将放置在此缓存中，并保留10分钟。
客户端将NetBIOS查询转发到其配置的主WINS服务器。如果主WINS服务器无法回答查询（由于该查询不可用或没有名称输入），客户端将尝试按照列出和配置的其他WINS服务器的顺序进行联系。它的使用。
客户端将NetBIOS查询广播到本地子网。
如果客户端被配置为使用Lmhosts文件，则客户端将检查Lmhosts文件是否与查询匹配。
客户端先尝试“主机”文件，然后再尝试使用DNS服务器（如果配置为一个）。
问题在于，并非每个应用程序都可以配置为使用DNS。
即使在Microsoft自己对Active Directory安装程序的探索中，它也提到需要WINS。
“早期版本的Windows仍需要NetBIOS名称解析（WINS服务器，LMHosts文件或NetBIOS广播）来解析Active Directory域上的网络资源。”
因此，是的，有些组织可以不使用WINS而逃脱，但是要做出一个明确的声明，即如果您可以使用DNS服务器，那么神奇地不需要WINS是错误的。
尽管世界上每个Windows管理员都试图将WINS毁灭，但仍然非常需要WINS 。每当子网分开时，您将需要WINS。为单独的站点运行VPN？这意味着一个子网-和WINS。是否有不懂广告的老客户？您需要WINS。您正在联网的DOS应用程序？再次获胜。
WINS还用于填充浏览列表。尽管基于Active Directory的计算机可以在不使用WINS的情况下运行，但是由于浏览列表按以下顺序填充，因此可能会有延迟：
问题的症结源于LANMAN的根源，它源于SMB，源于CIFS ...您可以看到问题的发展方向。LANMAN很大程度上是基于LAN的协议-它没有“ Internet”的概念，更不用说“ routing”了。WINS的开发是为了弥合这一差距并使路由成为可能。快进到现在，CIFS仍然对LANMAN具有一些向后兼容的支持。UNC路径名称可能是“现代”的，但它们仍将连接到LANMAN服务器。然后是整个“浏览列表”内容...
MS非常接近退出WINS服务器业务，但不仅有OS，而且还有需要WINS服务器的应用程序和服务中都有太多的“遗留”钩子。而只要有对LANMAN式传输的支持，将会有一个需要有各地的WINS服务器。
编辑：
是的，您可以在平面域中关闭WINS。
然而...
就我所希望看到的这项服务的利益而言，它不会消失，直到微软全面开展并改进其局域网服务的方式后，它才会消失。 （是的，在该链接上有一条评论，也是关于如何不需要它的……但是请仔细阅读马口中所说的话……）
这些答案中有许多是不正确的或部分正确的。首先让我们弄清楚为什么可以首先使用WINS。
WINS用作将主机名解析为IP地址的解决方案...但是，如果NetBIOS在所有senerios中都起作用，为什么我们需要WINS？继续阅读！
DNS用于相同目的及其他用途...将完全限定的域名和主机名解析为IP地址。
现在让我们看看为什么WINS是开发的。
问题：NetBIOS最初用于解析名称，但是它是广播网络协议。因此，在大多数网络中（无论是传统网络还是最新网络），广播流量都无法穿越路由器，很快就无法穿越防火墙，后来我们发现VPN流量中也是如此。因此，大多数子网不会将NetBIOS通信复制到其他子网。如果您是真正的IT网络管理员，您将熟悉路由器，交换机和防火墙上的此NetBIOS通信：
ACL拒绝从HOST-17 / 137到内部的UDP访问：10.0.1.127/137
ACL拒绝从HOST-A / 137到内部的UDP访问：10.0.1.127/137
ACL拒绝从HOST-09 / 137到内部的UDP访问：10.0.1.127/137
ACL拒绝从HOST-02 / 137到内部的UDP访问：10.0.1.127/137
ACL拒绝从HOST-02 / 137到内部的UDP访问：10.0.1.127/137
这是从Cisco Pix 515E防火墙syslog文件在25位网络上广播五（5）个NetBIOS广播的示例。对于那些不熟悉linksys路由器的25位网络小于24位网络的用户：
网络：10.0.1.0/25，子网掩码：255.255.255.128，广播地址：10.0.1.127，最大主机数：126。可以看出，流量包含在网段内。
解决方案：WINS被开发为跨包含广播流量的子网进行部署，客户端可以配置并指向WINS服务器以解析名称，而不是依赖广播流量，因此当WINS查询失败时，NetBios现在成为后备。
但是，等等...部署Microsoft网络时，我们现在配置DNS服务器。现在DNS是主要的，当DNS失败时，NetBIOS是后备的。如果已部署WINS服务器，则使用DNS，WINS和NetBIOS。
许多人可能会遇到的问题是他们尝试ping主机名时，可以说是HOST-A。根据计算机接口的配置，它可能无法将地址解析为IP，主要是如果您仅配置了DNS并且注册的NetBIOS名称主机已过期。
假设HOST-A是domainhosts.com的一部分，并且已加入该域，这是domainhosts.com在主DC DNS服务器上主机的（A）记录。要仅通过其主机名而不是其FQDN（全限定域名）来解析地址，IP配置必须具有“附加主要和连接特定的DNS后缀”，并且至少具有“此连接的DNS后缀：domainhosts.com”人口稠密！当执行HOST-A解析时，将返回两（2）pepe的额外信息：主机名解析为的IP地址及其FOST的HOST-A.domainhosts.com。在下面的示例中，主机名的解析是通过搜索域的（A）记录而不是WINS或NetBIOS来执行的：
[User @ localhost〜] $ ping HOST-A
PING HOST-A.domainhosts.com（10.0.1.10）56（84）个字节的数据。
来自HOST-A.domainhosts.com（10.0.1.10）的64个字节：icmp_seq = 1 ttl = 128时间= 0.826 ms
来自HOST-A.domainhosts.com（10.0.1.10）的64个字节：icmp_seq = 2 ttl = 128 time = 0.342 ms
除了仅填充主DNS后缀之外，您还可以让主机搜索其他主机，并将其配置为按不同顺序追加。从而消除了WINS和NetBIOS。
现在会有一些人说“您需要NetBIOS和WINS才能使Microsoft产品正常工作。” 实际上，这是正确的，但仅适用于少数产品，大多数产品将不会部署在中小型企业中，并且仅在大型企业环境中才会使用SMS 1等应用程序（使用1A记录，SQL Server 2000 for使用命名管道，Exchange Server 2000和2003都需要WINS才能具有全部功能...完整功能，尽管没有WINS或NetBIOS，它们也将根据需要全部工作。
哦，是的，只有在2000年之前的Microsoft才可以部署。与部署WINS相比，我为您提供了更好的解决方案……升级！！
我去过仍然需要维护的环境，因为“某些旧服务器” 可能需要它。
我认为可能有很多商店处于相同的状况。
没有人提到的一件事是，如果要解析NetBIOS名称，则必须在单独的子网上使用VPN站点。考虑这种情况：
公司网络使用专用的10.xxx LAN，而远程办公室使用专用的192.xxx LAN。它们之间有一个VPN通道，但是远程办公室不会通过公司DHCP服务器或防火墙通过通道获得DHCP。
如果您的公司服务器已注册到WINS，则远程客户端甚至可以从完全独立的子网中解析\ ServerName。最终，我将能够升级远程办公室防火墙并使用基于VPN的DHCP，但现在此设置使我能够：
如果我错了，请有人纠正我，但是我的理解是NetBIOS不可路由，因此如果不使用WINS，就无法跨子网解析NetBIOS名称。
哦，我们还在用它。我们拥有的大约三分之一的Windows工作站不在域中，因此未配置为使用域的DNS域进行名称解析。此外，我们还有一个非常零散的DNS格局，这导致了非常零散的默认域设置。因此，WINS代表其中包含最多内容的单个名称解析服务。这是我们最接近全球服务指数的地方。
如果/当我们努力使所有领域都成为域名时，我们将拥有一个平坦的DNS环境。那会很好。
旧版Exchange仍使用WINS，因此任何希望将功能级别提高到2008或2012并仍在使用WINS的人，如果您使用的是Exchange 2003或更早版本（希望不是），则仍需要启用WINS。
另外，在多域环境中不使用FQDN的任何应用程序或脚本都可能会出现问题。
可以删除WINS，但应该对其进行系统地测试，并且在运行许多应用程序，SAP，Exchange和其他旧版应用程序的大型公司中，几乎不值得这样做，直到您可以在自己的域上使用2012年原生版本，这将有助于赢了。
我为一个，不使用WINS并且已经四年没有使用WINS了。Microsoft DDNS在Active Directory网络上可以很好地进行名称解析。我想不出现在需要WINS的程序，但我记得其中一些。过去，Guardian防火墙在LAN侧NIC上需要它。
2007 Exchange群集不需要WINS。根据我拥有的文档，由于IP不变，因此MS建议在该设置中使用HOST文件，无论是否相信。
关于DDNS的唯一问题是跨WAN。每个WAN区段上的DDNS + ADC ...经常出现DDNS更新彼此的名称表的问题。
对于没有远程站点或WAN链接的C类网络，WINS很好。反对WINS的一件大事... SSL VPN + WINS =输入IP的cuz WINS不会太奇怪。