我似乎回想起了多年来尝试停止WINS名称服务作为Windows环境一部分的要求。
我的问题是，网站是否仍在使用WINS或切换到别的东西，不再需要WINS。 如果是这样，有人想分享他们的经验？
谢谢。
很多这些答案只是部分是真的或者是错的。 WINS是parsing名称到IP地址的另一种方法。 只要您的应用程序知道如何使用DNS，根本就不需要WINS。
编辑：好的，我不能相信这个线程有多less错误信息。 首先，拥有不同的子网不需要使用WINS。 只要您的应用程序可以与您的DNS服务器上的udp / tcp端口53进行通信，您就可以parsing主机名（没错，\\ hostname也可以）。
其次，如果你想知道为什么你不能使用简短的主机名（即没有域的主机名）来解决任何问题，那可能是因为你从来没有在你的客户机上configuration默认域（或域search列表）。
最后（但并非最不重要），Active Directory域不是在Windowsnetworking上使用DNS的先决条件。 您认为这是因为当您将计算机join域时，Windows会为您设置默认域名。 没有什么能阻止你通过其他手段（可能是DHCP）来设置它。
所以总之，只需设置默认的域名，并使用DNS就像我们这里在21世纪的其他人一样！
胜利仍然是一堆事情所必需的（每天越来越less！）。 我见过的最常见的例子是胜利是在集群2003服务器上运行Exchange 2007的必要条件。 胜利与Netbios名称一起使用。 NetBIOS名称是在计算机上运行的NetBIOS服务使用的标识符。 它是15个字符（字节）名称和一个表示服务的第16个字符的组合。 在识别NetBIOSnetworking资源时，使用这些名称。 NetBIOS无法在Internet上进行名称parsing。 NetBIOS名称是单个部分名称，并没有任何分层结构。
NetBIOS名称空间是平的，这意味着没有后缀添加到NetBIOS名称，并且两台计算机不能具有相同的NetBIOS名称。 这意味着任何一个networking中的每个NetBIOS名称都必须是唯一的。
请参阅Microsoft Windows的TCP / IP基础知识，第11章 – 基于TCP / IP的NetBIOS
在我们的企业中，许多遗留应用程序仍然需要它。
觉得我需要编辑这个，因为最高的答案是平坦的错误！
现在许多组织肯定需要WINS。
WINS的工作原理更新：2005年1月21日
WINS的工作原理默认情况下，当运行Microsoft®Windows®2000，Windows XP或Windows Server 2003操作系统的计算机使用WINS服务器地址（手动或通过DHCP）进行名称parsing时，它将使用混合节点（h -node）作为其NetBIOS名称注册的节点types，除非configuration了另一个NetBIOS节点types。 对于NetBIOS名称查询和parsing，它也使用h节点的行为，但有一些差异。
对于NetBIOS名称parsing，WINS客户端通常执行以下一般步骤序列来parsing名称：
客户端检查查询名称是否是其拥有的本地NetBIOS计算机名称。
客户端检查远程名称的本地NetBIOS名称caching。 为远程客户端parsing的任何名称都将放置在此caching中，并保留10分钟。
客户端将NetBIOS查询转发到其configuration的主WINS服务器。 如果主WINS服务器无法回答查询，或者因为它不可用，或者因为它没有用于名称的条目，客户端将尝试联系其他configuration的WINS服务器，按其列出和configuration的顺序它的使用。
客户端将NetBIOS查询广播到本地子网。
如果客户端configuration为使用Lmhosts文件，客户端将检查Lmhosts文件是否与查询匹配。
客户端尝试主机文件，然后尝试DNS服务器（如果configuration为一个）。
问题是不是每个应用程序都可以configuration为使用DNS。
即使在微软自己的活动目录设置探讨它提到了WINS的需要。
设置DNS
“早期版本的Windows仍然需要NetBIOS名称parsing（WINS服务器，LMHosts文件或NetBIOS广播）才能parsingActive Directory域上的networking资源。”
所以是的，有些组织可以在不使用WINS的情况下离开，但是如果你能打DNS服务器，你就不需要WINS了。
WINS 仍然是一个非常重要的要求，尽pipe世界上每一个Windowspipe理员的每一个尝试都会把它吓死。 任何时候都有一个子网的分离，你将需要WINS。 为不同的网站运行VPN？ 这意味着一个子网 – 和WINS。 有不懂AD的老客户？ 你需要WINS。 有一个你的networkingDOS应用程序？ 再次胜利。
WINS也用于填充浏览列表。 尽pipe基于Active Directory的计算机可以在没有WINS的情况下工作，但浏览列表按以下顺序填充时可能会有延迟：
问题的症结源于LANMAN的根源，它生下了CIFS生成的SMB ……你可以看到这是怎么回事。 LANMAN是非常基于局域网的协议 – 它没有“互联网”的概念，更不用说“路由”。 WINS的开发是为了填补这一空白，并使路由成为可能。 快进到现在，CIFS仍然有一些向后兼容的LANMAN的支持。 UNCpath名称可能是“现代”，但它们仍将附加到LANMAN服务器。 然后是整个“浏览列表”的事情…
MS非常接近WINS服务器业务，但是不仅在操作系统中，而且在应用程序和服务中也有太多的“传统”挂钩，它们需要WINS服务器。 只要支持LANMAN风格的传输 ，就需要有一个WINS服务器。
编辑：
是的，你可以在一个平坦的域中closuresWINS。
然而…
尽pipe我希望看到这项服务的内容受到了很大的影响 ， 但是直到微软围绕它们改变局域网服务的方式之后 ， 它才会消失。 （是的，在那个链接上有一个评论，这个链接是不需要的，但是阅读马的嘴里说的话）
不要让wins和netbios混淆…..你可以在没有WINS服务器的情况下在networking上运行netbios，但是不推荐在域上使用。 当你在networking上有一个合适的DNS服务器时，你并不是真的想要所有这些时髦的选举，所以netbios应该被禁用，或者应该使用WINS服务器。 （我使用适当的最松散的术语，其中MS DNS的关注:-)）
最近我遇到了Windows 2008上的Exchange 2007问题，需要启用netbios。 难以置信的！！！
许多这些答案是不正确的或部分正确的。 首先让我们弄清楚为什么可以使用WINS。
WINS被用作将主机名parsing为IP地址的解决scheme…但是如果NetBIOS在所有的senerios中工作，我们为什么还需要WINS呢？ 继续阅读
DNS用于相同的目的＆更多…来parsing完全合格的域名和主机名到IP地址。
现在让我们来看看为什么开发WINS。
问题：NetBIOS最初用于parsing名称，但是它是一个广播networking协议。 因此，在大多数networking中，Legacey和Current，广播stream量都无法穿越路由器，并且很快就有足够的防火墙，之后我们也发现VPNstream量。 所以，大多数子网不会将NetBIOSstream量复制到其他子网。 如果您是真正的ITnetworkingpipe理员，则您将熟悉路由器，交换机和防火墙上的NetBIOSstream量：
ACL从HOST-17/137到内部：10.0.1.127/137拒绝UDP访问
ACL从HOST-A / 137到内部：10.0.1.127/137拒绝UDP访问
ACL从HOST-09/137到内部：10.0.1.127/137拒绝UDP访问
ACL从HOST-02/137到内部：10.0.1.127/137拒绝UDP访问
ACL从HOST-02/137到内部：10.0.1.127/137拒绝UDP访问
这是Cisco Pix 515E防火墙系统日志文件在25位networking上进行五（5）个NetBIOS广播的示例。 对于那些不熟悉Linksys路由器是25位networking的人，其实并不比24位networking小：
networking：10.0.1.0/25，子网掩码：255.255.255.128，广播地址：10.0.1.127，最大主机数：126。可以看出，通信量被包含在段内。
解决scheme：开发WINS以在包含广播stream量的子网上进行部署，客户端可以configuration并指向WINS服务器来parsing名称，而不是依赖广播stream量，因此当WINS查询失败时，NetBIOS现在成为回退。
但是等等…我们现在在部署我们的微软networking时configurationDNS服务器。 现在DNS是主要的，当DNS失败时，NetBIOS是后备。 如果部署了WINS服务器，DNS，WINS和NetBIOS。
许多人可能遇到的问题是当他们尝试ping主机名时，可以说HOST-A。 根据计算机接口configuration，可能无法将地址parsing为IP，主要是如果您刚刚configuration了DNS，并且主机注册的NetBIOS名称已过期。
可以说，HOST-A是domainhosts.com的一部分，并join到该域，在主域DC DNS服务器上为domainhosts.com的主机（A）logging。 要通过其主机名parsing地址而不是其FQDN（完全限定的域名），IPconfiguration必须具有“附加主要和特定连接的DNS后缀”，并且具有“此连接的DNS后缀：domainhosts.com”填充！ 当parsing执行HOST-A时，将返回两（2）个额外信息：主机名parsing的IP地址及其HOST-A.domainhosts.com的FQDN。 在下面的例子中，通过search域的（A）logging而不是WINS或NetBIOS来执行主机名的parsing：
[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.826ms
来自HOST-A.domainhosts.com（10.0.1.10）的64字节：icmp_seq = 2 ttl = 128时间= 0.342ms
除了只填写主要的DNS后缀之外，您还可以让主机search其他人，并将其configuration为以不同的顺序追加。 从而一起消除了WINS和NetBIOS。
现在会有一些人说“你将需要使用NetBIOS和WINS来运行微软产品”。 这是事实，但只有less数产品，其中大部分不会部署在中小型企业，只有在大型企业环境中，应用程序（如SMS 2003使用1Alogging，SQL Server 2000使用命名pipe道和Exchange Server 2000和2003都需要WINS的全部function…完整的function，他们将尽可能没有WINS或NetBIOS的所有工作。
哦，是的，只有当你是2000年以前的微软部署。 我得到了一个更好的解决scheme比你部署WINS …升级！
我一直在维护它的环境中，因为“一些传统服务器” 可能需要它。
我认为可能有很多店铺在相同的情况。
我曾经在一个samba服务器上启用了WINS。 这是在没有域名的Windowsnetworking中名称parsing速度最快且最便宜的（花费时间）解决scheme。 这很简单，在小型networking中运行良好。
许多embedded式设备也使用WINS。 我们有多function复印机和最近购买的无线投影系统，直到我给它一个WINS服务器的IP才能工作。
尽可能多的，WINS将在这里很长一段时间。
几个月前，我停止了我们局域网上的WINS服务。 几个星期后，我完全删除了它。 我不知道有多less年没有特别的原因呢？ 在某些环境下，我相信这是不可能的。 从那以后，我们可能会遇到问题，在WINS仍在运行的情况下，这些问题已经隐藏起来了。 我想我是一个纯粹主义者，但WINS让我想起玩“slop”游泳池。 除非你瞄准那个口袋，否则射击不应该算在内！
有一点没有人提到过，如果你想parsingNetBIOS名字的话，那么VPN站点就需要在不同的子网上。 考虑这种情况：
企业networking使用私有的10.xxx局域网，远程办公室使用私有的192.xxx局域网。 它们之间有一个VPN隧道，但是远程办公室并不通过来自公司DHCP服务器或防火墙的隧道。
如果您的企业服务器使用WINS注册，则远程客户端即使从完全独立的子网也可以parsing\ ServerName。 事实上，我将能够升级远程办公室防火墙，并通过VPN使用DHCP，但现在这个设置允许我：
有人请纠正我，如果我错了，但我的理解是，NetBIOS不可路由，所以我不能解决NetBIOS名称跨子网不使用WINS。
哦，我们仍在使用它。 大约三分之一的Windows工作站不在域中，因此未configuration为使用域的DNS域进行名称parsing。 此外，我们有一个巨大的碎片化的DNS景观，导致默认域设置巨大的碎片。 因为这个WINS代表了其中包含最多东西的单一名称parsing服务。 这是我们最接近的全球服务指数。
如果/当我们推动所有的事情时，我们将有一个平坦的DNS景观。 那会很好。
传统交换仍然使用WINS，所以任何人都在提升function级别到2008或2012年仍然使用WINS，如果您使用Exchange 2003或更早版本（希望不是），您仍然需要启用WINS。
另外，在多域环境中不使用FQDN的任何应用程序或脚本都可能有问题。
WINS可以被删除，但应该进行系统的testing，在大型应用程序，SAP，Exchange和其他旧版应用程序运行它的大公司几乎是不值得的，直到你可以到你的域的2012本地，这将有助于分解WINS。
我作为一个，不要使用WINS并且没有使用WINS 4年。 Microsoft DDNS在Active Directorynetworking上做了很好的名称parsing工作。 我想不出一个需要WINS的程序，但是我记得有一些。 Guardian防火墙需要在局域网侧的网卡当天返回。
2007年Exchange群集不需要WINS。 根据我的文档，MSbuild议使用HOST文件，不pipe信不信，在这个设置中，因为IP不会改变。
我唯一的问题与DDNS，是在广域网。 每个广域网段上的DDNS + ADC …我经常遇到DDNS更新其他名称表的问题。
WINS适用于没有远程站点或WAN链接的C类networking。 反对WINS的一个巨大的事情… SSL VPN + WINS =键入IP的因为WINS不是goona混蛋。
我们的环境没有使用WINS好几个月，也没有看到因此而产生的不利影响。 我们有一个通过VPN连接的多站点拓扑，使用Exchange 2003作为我们的电子邮件服务。
只有在特别需要解决已知问题时才能启用WINS。 保持陈旧的技术“以防万一”是没有意义的，当你确保它不是必需的。