Parece que me lembro ao longo dos anos de tentativas de interromper o requisito de ter um serviço de nomes WINS como parte de um ambiente Windows.
Minha pergunta é se os sites ainda estão utilizando o WINS ou mudaram para outra coisa e não precisam mais do WINS. Se sim, alguém quer compartilhar suas experiências?
Obrigado.
Respostas:
Muitas dessas respostas são apenas parcialmente verdadeiras ou completamente erradas. O WINS é apenas outra maneira de resolver nomes para endereços IP. Desde que seus aplicativos saibam usar o DNS, o WINS não será necessário.
Edit: Ok, eu não posso acreditar quanta desinformação existe neste tópico. Primeiro de tudo, ter sub-redes diferentes não requer o uso do WINS. Contanto que seu aplicativo possa se comunicar com a porta 53 udp / tcp no (s) servidor (es) DNS, você poderá resolver os nomes de host corretamente (sim, \\ hostname também funcionará).
Em segundo lugar, se você está se perguntando por que não consegue resolver nada usando o nome abreviado do host (ou seja, apenas o nome do host sem o domínio), provavelmente é porque você nunca configurou o domínio padrão (ou lista de pesquisa de domínio) em seus clientes.
E, por último (mas não menos importante!), Um domínio do Active Directory não é um pré-requisito para usar o DNS em uma rede Windows. A única razão pela qual você pensa que isso ocorre porque quando você ingressa uma máquina em um domínio, o Windows define o nome de domínio padrão para você. Não há nada impedindo você de configurá-lo por outros meios (provavelmente DHCP).
Então, em resumo, basta definir o domínio padrão e usar o DNS como todos nós aqui no século XXI!
vitórias ainda são necessárias para várias coisas (menos e menos todos os dias!). O exemplo mais comum que eu vi é que vitórias é um requisito para executar o Exchange 2007 em servidores 2003 em cluster. Wins funciona com nomes Netbios. Um nome NetBIOS é um identificador usado pelos serviços NetBIOS em execução em um computador. É uma combinação de um nome de 15 caracteres (byte) e um 16º caracterizando o serviço. Ao identificar os recursos de rede NetBIOS, esses nomes são usados. O NetBIOS não pode fazer a resolução de nomes na Internet. Os nomes NetBIOS são nomes de peça única e não possuem estrutura hierárquica.
O espaço para nome NetBIOS é simples, o que significa que não há sufixos adicionados ao nome NetBIOS e que dois computadores não podem ter o mesmo nome NetBIOS. Isso significa que cada nome NetBIOS em qualquer rede deve ser exclusivo.
Consulte Fundamentos de TCP / IP para Microsoft Windows, Capítulo 11 - NetBIOS sobre TCP / IP
Em nossa empresa, ainda é necessário para muitos aplicativos herdados.
Senti que precisava editar isso, pois a resposta mais votada é totalmente ERRADA!
Definitivamente, o WINS é exigido em muitas organizações atualmente.
Como o WINS funciona Atualizado: 21 de janeiro de 2005
Como o WINS funciona Por padrão, quando um computador executando o sistema operacional Microsoft® Windows® 2000, Windows XP ou Windows Server 2003 é configurado com endereços de servidor WINS (manualmente ou através do DHCP) para sua resolução de nomes, ele usa o nó híbrido (h -node) como seu tipo de nó para registro de nome NetBIOS, a menos que outro tipo de nó NetBIOS esteja configurado. Para consulta e resolução de nomes NetBIOS, ele também usa o comportamento do nó h, mas com algumas diferenças.
Para resolução de nomes NetBIOS, um cliente WINS normalmente executa a seguinte seqüência geral de etapas para resolver um nome:
O cliente verifica se o nome consultado é o nome do computador NetBIOS local, de sua propriedade.
O cliente verifica seu cache de nomes NetBIOS local de nomes remotos. Qualquer nome resolvido para um cliente remoto é colocado nesse cache, onde permanece por 10 minutos.
O cliente encaminha a consulta NetBIOS para o servidor WINS primário configurado. Se o servidor WINS primário falhar em responder à consulta - porque não está disponível ou porque não possui uma entrada para o nome - o cliente tentará entrar em contato com outros servidores WINS configurados na ordem em que estão listados e configurados para seu uso.
O cliente transmite a consulta NetBIOS para a sub-rede local.
O cliente verifica se o arquivo Lmhosts corresponde à consulta, se estiver configurado para usar o arquivo Lmhosts.
O cliente tenta o arquivo Hosts e, em seguida, um servidor DNS, se estiver configurado para um.
O problema é que nem todos os aplicativos podem ser configurados para usar o DNS.
Mesmo no próprio Microsoft Microsofts, a explicação da instalação do Active Directory menciona a necessidade do WINS.
"A resolução de nomes NetBIOS (servidor WINS, arquivo LMHosts ou transmissão NetBIOS) ainda é necessária para versões anteriores do Windows para resolver os recursos de rede em um domínio do Active Directory."
Então, sim, existem ALGUMAS organizações que podem se safar sem usar o WINS, mas fazer uma declaração geral de que, se você pode acessar o servidor DNS, magicamente não precisa do WINS, está errado.
O WINS ainda é um requisito, apesar de todas as tentativas de todos os administradores do Windows em espancá-lo até a morte. Sempre que houver uma separação de sub-redes, você precisará do WINS. Você está executando uma VPN para sites separados? Isso implica em uma sub-rede - e no WINS. Tem clientes mais antigos que não entendem o AD? Você precisa de WINS. Tem um aplicativo DOS que você está conectando em rede? GANHA novamente.
O WINS também é usado para preencher listas de navegação. Embora as máquinas baseadas no Active Directory possam funcionar sem o WINS, pode haver um atraso, pois as listas de navegação são preenchidas na seguinte sequência:
O cerne do problema decorre das raízes da LANMAN, que gerou o SMB, que gerou o CIFS ... você pode ver para onde isso está indo. O LANMAN era basicamente um protocolo baseado em LAN - não tinha conceito de "Internet", muito menos "roteamento". O WINS foi desenvolvido para preencher essa lacuna e possibilitar o roteamento. Avanço rápido para o presente, e o CIFS ainda possui algum suporte compatível com versões anteriores para LANMAN. Os nomes de caminhos UNC podem ser "modernos", mas ainda serão anexados a um servidor LANMAN. Depois, há toda a coisa "lista de navegação" ...
A Microsoft está muito perto de sair do negócio do servidor WINS, mas existem muitos ganchos "herdados", não apenas no sistema operacional, mas também em aplicativos e serviços, que exigem um servidor WINS. E enquanto houver suporte para transmissões no estilo LANMAN , será necessário ter um servidor WINS por perto.
EDITAR:
Sim, você pode desativar o WINS em um domínio plano.
Contudo...
Por mais que eu queira que esse serviço tenha uma participação significativa, ele não desaparecerá até que a Microsoft chegue e revise como eles fazem os serviços de LAN. (Sim, há um comentário nesse link sobre como não é necessário também ... mas leia o que está sendo dito pela boca do cavalo ...)
Não vamos ficar confusos entre vitórias e netbios ..... você pode executar o netbios em uma rede sem um servidor WINS, mas isso não é recomendado em um domínio. Você realmente não deseja que todas essas eleições descoladas aconteçam quando você tiver um servidor DNS adequado na rede; portanto, o netbios deve ser desativado ou um servidor WINS deve ser usado. (Eu uso apropriado no sentido mais lato do termo no que diz respeito ao MS DNS :-))
Recentemente, tive um problema com o Exchange 2007 no Windows 2008 exigindo a ativação do netbios. inacreditável!!!
Muitas dessas respostas estão incorretas ou parcialmente corretas. Primeiro vamos descobrir por que o WINS pode ser usado em primeiro lugar.
O WINS é usado como uma solução para resolver nomes de host para endereços IP ... mas por que precisamos do WINS se o NetBIOS funciona em todos os senerios? Leia!
DNS usado para o mesmo objetivo e muito mais ... para resolver nomes de domínio E nomes de host totalmente qualificados para endereços IP.
Agora vamos ver por que o WINS foi desenvolvido.
Problema: O NetBIOS foi originalmente usado para resolver nomes, mas é um protocolo de rede de difusão. Portanto, na maioria das redes, legada e atual, o tráfego de transmissão não consegue atravessar roteadores e, em breve, firewalls, mais tarde descobrimos isso também no tráfego VPN. Portanto, a maioria das sub-redes não replicará o tráfego NetBIOS para outras sub-redes. Se você é um administrador de rede de TI real, estará familiarizado com esse tráfego NetBIOS em roteadores, comutadores e firewalls:
Acesso UDP negado pela ACL do HOST-17/137 para dentro: 10.0.1.127/137
Acesso UDP negado pela ACL do HOST-A / 137 para dentro: 10.0.1.127/137
Acesso UDP negado pela ACL do HOST-09/137 para dentro: 10.0.1.127/137
Acesso UDP negado pela ACL do HOST-02/137 para dentro: 10.0.1.127/137
Acesso UDP negado pela ACL do HOST-02/137 para dentro: 10.0.1.127/137
Este é um exemplo de cinco (5) transmissões NetBIOS em uma rede de 25 bits a partir de um arquivo syslog do Cisco Pix 515E Firewall. Para aqueles que não estão familiarizados com nada além do que o roteador linksys é uma rede de 25 bits, é menor que a sua rede de 24 bits:
Rede: 10.0.1.0/25, Máscara de sub-rede: 255.255.255.128, Endereço de transmissão: 10.0.1.127, Máximo de hosts: 126. Como pode ser visto, o tráfego está sendo contido no segmento.
Solução: O WINS foi desenvolvido para implantar na sub-rede onde o tráfego de broadcast está contido, os clientes podem configurar e apontar para um servidor WINS para resolver nomes em vez de depender do tráfego de broadcast e, portanto, o NetBios agora se torna o substituto quando as consultas WINS falham.
Mas espere ... nós configuramos os servidores DNS agora quando implantamos nossas redes da Microsoft. Agora, o DNS é primário, quando o DNS falha, o NetBIOS é o substituto. Se houver um servidor WINS implantado, DNS, WINS e NetBIOS.
O problema que muitos podem estar enfrentando é quando eles tentam executar ping em um nome de host, digamos HOST-A. Dependendo da configuração da interface do computador, talvez não seja possível resolver o endereço para um IP, principalmente se você tiver apenas o DNS configurado e os nomes NetBIOS registrados pelos hosts tiverem expirado.
Digamos que o HOST-A faça parte do domainhosts.com e tenha ingressado nesse domínio, um registro (A) do host no servidor DNS primário da DC para domainhosts.com. Para resolver o endereço apenas pelo nome do host e não pelo FQDN (nome de domínio totalmente qualificado), a configuração do IP deve ter "Anexar sufixos DNS primários e de conexão específicos" e ter o mínimo de "Sufixo DNS para esta conexão: domainhosts.com" populosa! Quando a resolução é executada no HOST-A, duas (2) partes de informações extras são retornadas: O endereço IP para o qual o nome do host é resolvido e seu FQDN de HOST-A.domainhosts.com. No exemplo abaixo, a resolução de um nome de host é realizada pesquisando os registros (A) do domínio em vez de WINS ou NetBIOS:
[Usuário @ localhost ~] $ ping HOST-A
PING HOST-A.domainhosts.com (10.0.1.10) 56 (84) bytes de dados.
64 bytes de HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 1 ttl = 128 time = 0.826 ms
64 bytes de HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 2 ttl = 128 time = 0.342 ms
Além de ter apenas o Sufixo DNS primário preenchido, os hosts também podem procurar outros e configurá-los para anexar em ordens diferentes. Assim, eliminando WINS e NetBIOS todos juntos.
Agora haverá alguns que dizem "Você precisará do NetBIOS e WINS para que os produtos da Microsoft funcionem". Isso é verdade na realidade, mas apenas para alguns produtos, a maioria dos quais não será implantada em pequenas e médias empresas e apenas em grandes ambientes corporativos, aplicativos como o SMS 2003 com o uso do registro 1A, SQL Server 2000 para o uso de pipes nomeados e o Exchange Server 2000 e 2003 exigem o WINS para funcionalidade completa ... Funcionalidade COMPLETA, TODOS funcionarão conforme necessário, sem o WINS ou o NetBIOS.
Ah, sim, e somente se você tiver implantações anteriores à 2000 da Microsoft. Eu tenho uma solução melhor para você do que implantar o WINS ... ATUALIZAÇÃO !!
Já estive em ambientes em que ele ainda é mantido porque "alguns servidores herdados" podem precisar dele.
Acho que provavelmente existem muitas lojas por aí que estão na mesma situação.
Há alguns meses, parei o serviço WINS em nossa LAN. Depois de algumas semanas, eu o removi completamente. Gostaria de saber quantos anos se passaram sem nenhuma razão específica? Em alguns ambientes, tenho certeza de que isso será impossível. É possível que tenhamos problemas desde então que seriam invisíveis com o WINS ainda em execução. Eu acho que sou purista, mas o WINS me lembra de jogar sinuca "slop". Um tiro não deve contar, a menos que você esteja mirando nesse bolso!
Uma coisa que ninguém mencionou é que é necessário para sites VPN em sub-redes separadas se você quiser resolver nomes de NetBIOS. Considere este cenário:
A rede corporativa utiliza uma LAN 10.xxx privada e um escritório remoto usa uma LAN 192.xxx privada. Eles têm um túnel VPN entre eles, mas o escritório remoto não leva o DHCP através do túnel do servidor DHCP corporativo ou do firewall.
Se você tiver seus servidores corporativos registrados no WINS, os clientes remotos poderão resolver \ ServerName mesmo de uma sub-rede totalmente separada. É possível que eu atualize o firewall do escritório remoto e use o DHCP pela VPN, mas por enquanto essa configuração me permite:
Alguém por favor me corrija se eu estiver errado, mas meu entendimento é que o NetBIOS não é roteável, por isso não consigo resolver nomes do NetBIOS na sub-rede sem usar o WINS.
Ainda estamos usando. Cerca de um terço das estações de trabalho Windows que possuímos não estão no domínio e, portanto, não estão configuradas para usar os domínios DNS do domínio na resolução de nomes. Além disso, temos um cenário DNS monstruosamente fragmentado que leva a configurações de domínio padrão monstruosamente fragmentadas. Por esse motivo, o WINS representa o serviço único de resolução de nomes com mais itens. É o mais próximo que temos de um índice global de serviços.
Se / Quando pressionarmos para manter tudo em ordem, teremos um cenário DNS simples. Isso vai ser bom.
O Exchange herdado ainda usa o WINS; portanto, qualquer pessoa que queira aumentar os níveis funcionais para 2008 ou 2012 e ainda usar o WINS, se você estiver usando o Exchange 2003 ou anterior (espero que não), ainda precisará do WINS ativado.
Além disso, todos os aplicativos ou scripts que não usam o FQDN em um ambiente de vários domínios provavelmente terão problemas.
O WINS pode ser removido, mas deve ser metodicamente testado e em grandes empresas com muitos aplicativos, SAP, Exchange e outros aplicativos herdados que o executam quase não valem a pena até que você possa obter o nativo de 2012 em seu domínio, o que ajudará na decomposição de WINS.
Por um lado, não uso o WINS e não o utilizo há 4 anos. O Microsoft DDNS faz um bom trabalho de resolução de nomes em uma rede do Active Directory. Não consigo pensar em um programa que exija WINS agora, mas lembro de alguns. O Guardian Firewall o exigia na NIC do lado da LAN naquele dia.
Os Clusters do Exchange 2007 não exigem WINS. De acordo com a documentação que tenho, a MS recomenda o uso de arquivos HOST, acredite ou não, nessa configuração, pois os IPs não mudam.
Meu único problema com o DDNS é através da WAN. DDNS + ADC em cada segmento da WAN ... frequentemente, tenho problemas com o DDNS atualizando as tabelas de nomes dos outros.
O WINS é bom para uma rede de Classe C na qual você não possui sites remotos ou links WAN. Uma grande coisa contra o WINS ... SSL VPN + WINS = digitar IPs, porque o WINS não é um problema.
Nosso ambiente não usa o WINS há muitos meses e não apresenta efeitos adversos por causa disso. Temos uma topologia de vários sites por meio de conexões VPN, com o Exchange 2003 como nosso serviço de email.
O WINS só deve ser ativado se for especificamente necessário para resolver um problema conhecido. Manter a tecnologia antiquada "just in case" não faz sentido quando você garante que ela não é necessária.