Me parece recordar a lo largo de los años movimientos para tratar de detener el requisito de tener un servicio de nombres WINS como parte de un entorno Windows.
Mi pregunta es si los sitios siguen utilizando WINS o si han cambiado a otra cosa y ya no necesitan WINS. Si es así, ¿alguien quiere compartir sus experiencias?
Gracias.
Respuestas:
Muchas de estas respuestas son solo parcialmente verdaderas o simplemente erróneas. WINS es solo otra forma de resolver nombres en direcciones IP. Mientras sus aplicaciones sepan cómo usar DNS, WINS no es necesario en absoluto.
Editar: De acuerdo, no puedo creer la cantidad de información errónea que hay en este hilo. En primer lugar, tener subredes diferentes no requiere el uso de WINS. Siempre que su aplicación pueda comunicarse con el puerto 53 de udp / tcp en sus servidores DNS, podrá resolver los nombres de host perfectamente (sí, \\ hostname también funcionará).
En segundo lugar, si se pregunta por qué no puede resolver nada usando el nombre de host corto (es decir, solo el nombre de host sin el dominio), probablemente sea porque nunca configuró el dominio predeterminado (o la lista de búsqueda de dominio) en sus clientes.
Y por último (¡pero no menos importante!), Un dominio de Active Directory no es un requisito previo para usar DNS en una red de Windows. La única razón por la que piensa eso es porque cuando une una máquina a un dominio, Windows establece el nombre de dominio predeterminado para usted. No hay nada que le impida configurarlo usted mismo a través de otros medios (probablemente DHCP).
En resumen, ¡solo configure el dominio predeterminado y use DNS como el resto de nosotros aquí en el siglo XXI!
aún se necesita ganar para un montón de cosas (¡menos y menos cada día!). El ejemplo más común que he visto es que Win es un requisito para ejecutar Exchange 2007 en servidores en clúster 2003. Wins funciona con nombres de Netbios. Un nombre de NetBIOS es un identificador utilizado por los servicios de NetBIOS que se ejecutan en una computadora. Es una combinación de un nombre de 15 caracteres (byte) y un 16to carácter que denota el servicio. Al identificar los recursos de red NetBIOS, se utilizan estos nombres. NetBIOS no puede hacer la resolución de nombres en Internet. Los nombres de NetBIOS son nombres de partes individuales y no tienen ninguna estructura jerárquica.
El espacio de nombres NetBIOS es plano, lo que significa que no se agregan sufijos al nombre NetBIOS y que dos computadoras no pueden tener el mismo nombre NetBIOS. Esto significa que cada nombre de NetBIOS en cualquier red debe ser único.
Consulte Fundamentos de TCP / IP para Microsoft Windows, Capítulo 11 - NetBIOS sobre TCP / IP
En nuestra empresa todavía es necesario para muchas aplicaciones heredadas.
Sentí que necesitaba editar esto ya que la respuesta más votada es ¡INCORRECTO!
WINS definitivamente se requiere en muchas organizaciones en estos días.
Cómo funciona WINS Actualizado: 21 de enero de 2005
Cómo funciona WINS De manera predeterminada, cuando una computadora que ejecuta Microsoft® Windows® 2000, Windows XP o un sistema operativo Windows Server 2003 está configurada con direcciones de servidor WINS (ya sea manualmente o mediante DHCP) para su resolución de nombre, utiliza un nodo híbrido (h -nodo) como su tipo de nodo para el registro de nombres NetBIOS a menos que se configure otro tipo de nodo NetBIOS. Para la consulta y resolución de nombres NetBIOS, también utiliza el comportamiento del nodo h, pero con algunas diferencias.
Para la resolución de nombres NetBIOS, un cliente WINS generalmente realiza la siguiente secuencia general de pasos para resolver un nombre:
El cliente verifica si el nombre consultado es el nombre de su computadora NetBIOS local, que es de su propiedad.
El cliente comprueba su caché de nombres NetBIOS local de nombres remotos. Cualquier nombre resuelto para un cliente remoto se coloca en este caché donde permanece durante 10 minutos.
El cliente reenvía la consulta NetBIOS a su servidor WINS primario configurado. Si el servidor WINS primario no responde la consulta, ya sea porque no está disponible o porque no tiene una entrada para el nombre, el cliente intentará contactar a otros servidores WINS configurados en el orden en que están listados y configurados para su uso
El cliente difunde la consulta NetBIOS a la subred local.
El cliente comprueba si el archivo Lmhosts coincide con la consulta, si está configurado para usar el archivo Lmhosts.
El cliente prueba el archivo Hosts y luego un servidor DNS, si está configurado para uno.
El problema es que no todas las aplicaciones se pueden configurar para usar DNS.
Incluso en la propia expiración de Microsoft de la configuración de Active Directory, menciona la necesidad de WINS.
"La resolución de nombres NetBIOS (servidor WINS, archivo LMHosts o transmisión NetBIOS) aún se requiere para versiones anteriores de Windows para resolver recursos de red en un dominio de Active Directory".
Entonces, sí, hay ALGUNAS organizaciones que pueden escapar sin usar WINS, pero hacer una declaración general de que si puede golpear el servidor DNS mágicamente no necesita WINS está mal.
WINS sigue siendo un requisito, a pesar de todos los intentos de cada administrador de Windows en el mundo para matarlo a golpes. Cada vez que haya una separación de subredes, necesitará WINS. ¿Tienes una VPN para sitios separados? Eso implica una subred y WINS. ¿Tiene clientes mayores que no entienden AD? Necesitas victorias. ¿Tienes una aplicación DOS que estás conectando en red? GANA de nuevo.
WINS también se usa para llenar listas de navegación. Si bien las máquinas basadas en Active Directory pueden funcionar sin WINS, puede haber un retraso ya que las listas de exploración se completan en la siguiente secuencia:
El quid del problema proviene de las raíces de LANMAN, que engendró a SMB, que engendró a CIFS ... puedes ver a dónde va esto. LANMAN era en gran medida un protocolo basado en LAN: no tenía ningún concepto de "Internet", mucho menos "enrutamiento". WINS fue desarrollado para cerrar esa brecha y hacer posible el enrutamiento. Avance rápido al presente, y CIFS todavía tiene algún soporte compatible con versiones anteriores para LANMAN. Los nombres de ruta UNC pueden ser "modernos", pero aún se conectarán a un servidor LANMAN. Luego está todo el asunto de la "lista de navegación" ...
MS está muy cerca de salir del negocio del servidor WINS, pero hay demasiados ganchos "heredados", no solo en el sistema operativo, sino también en aplicaciones y servicios, que requieren un servidor WINS. Y mientras haya soporte para transmisiones de estilo LANMAN , será necesario tener un servidor WINS.
EDITAR:
Sí, puede desactivar WINS en un dominio plano.
Sin embargo...
Por mucho que quiera ver que este servicio tenga una participación impulsada en su corazón, no desaparecerá hasta que Microsoft venga y renueve la forma en que prestan los servicios LAN. (Sí, hay un comentario en ese enlace sobre cómo no es necesario también ... pero lea lo que dice la boca del caballo ...)
No nos confundamos entre triunfos y netbios ..... puede ejecutar netbios en una red sin un servidor WINS, pero no se recomienda en un dominio. Realmente no desea que se realicen todas esas elecciones funky cuando tiene un servidor DNS adecuado en la red, por lo que netbios debería estar desactivado o debería usarse un servidor WINS. (Uso apropiado en el sentido más amplio del término en lo que respecta a MS DNS :-))
Recientemente tuve un problema con Exchange 2007 en Windows 2008 que requería habilitar netbios. ¡¡¡increíble!!!
Muchas de estas respuestas son incorrectas o parcialmente correctas. Primero, descubramos por qué WINS puede usarse en primer lugar.
WINS se usa como una solución para resolver nombres de host en direcciones IP ... pero ¿por qué necesitaríamos WINS si NetBIOS funciona en todos los senerios? Sigue leyendo!
DNS utilizado para el mismo propósito y más ... para resolver nombres de dominio totalmente calificados Y nombres de host a direcciones IP.
Ahora veamos por qué se desarrolló WINS.
Problema: NetBIOS se usó originalmente para resolver nombres, pero es un protocolo de red de difusión. Por lo tanto, en la mayoría de las redes, legacey y actuales, el tráfico de transmisión no puede atravesar enrutadores y, muy pronto, cortafuegos, más tarde lo encontramos también en el tráfico VPN. Por lo tanto, la mayoría de las subredes no replicarán el tráfico de NetBIOS a otras subredes. Si es un verdadero administrador de red de TI, estará familiarizado con este tráfico de NetBIOS en enrutadores, conmutadores y firewalls:
Acceso UDP denegado por ACL desde HOST-17/137 al interior: 10.0.1.127/137
Acceso UDP denegado por ACL desde HOST-A / 137 al interior: 10.0.1.127/137
Acceso UDP denegado por ACL desde HOST-09/137 al interior: 10.0.1.127/137
Acceso UDP denegado por ACL desde HOST-02/137 al interior: 10.0.1.127/137
Acceso UDP denegado por ACL desde HOST-02/137 al interior: 10.0.1.127/137
Este es un ejemplo de cinco (5) transmisiones de NetBIOS en una red de 25 bits desde un archivo syslog de Cisco Pix 515E Firewall. Para aquellos que no están familiarizados con nada más que lo que su enrutador Linksys es, una red de 25 bits es más pequeña que su red de 24 bits:
Red: 10.0.1.0/25, Máscara de subred: 255.255.255.128, Dirección de transmisión: 10.0.1.127, Máx. De hosts: 126. Como se puede ver, el tráfico está contenido dentro del segmento.
Solución: WINS está desarrollado para implementarse en una subred donde está contenido el tráfico de difusión, los clientes pueden configurar y apuntar a un servidor WINS para resolver nombres en lugar de depender del tráfico de difusión y, por lo tanto, NetBios ahora se convierte en la alternativa cuando las consultas WINS fallan.
Pero espere ... configuramos servidores DNS ahora cuando implementamos nuestras redes de microsoft. Ahora DNS es primario, cuando DNS falla, NetBIOS es el respaldo. Si hay un servidor WINS implementado, DNS, WINS y NetBIOS.
El problema con el que muchos pueden encontrarse es cuando intentan hacer ping a un nombre de host, digamos HOST-A. Dependiendo de la configuración de la interfaz de la computadora, es posible que no pueda resolver la dirección a una IP, principalmente si solo configuró DNS y los nombres NetBIOS registrados de los hosts han expirado.
Digamos que HOST-A es parte de domainhosts.com y se unió a ese dominio, un registro (A) del host en el servidor primario DNS de DC para domainhosts.com. Para resolver la dirección solo por su nombre de host y no por su FQDN (nombre de dominio completo), la configuración de IP debe tener "Anexar sufijos DNS primarios y específicos de conexión" y tener como mínimo "Sufijo DNS para esta conexión: domainhosts.com" ¡poblado! Cuando se realiza la resolución de HOST-A, se devuelven dos (2) partes de información adicional: la dirección IP que resuelve el nombre de host y su FQDN de HOST-A.domainhosts.com. En el siguiente ejemplo, la resolución de un nombre de host se realiza buscando en los registros (A) del dominio en lugar de WINS o NetBIOS:
[Usuario @ localhost ~] $ ping HOST-A
PING HOST-A.domainhosts.com (10.0.1.10) 56 (84) bytes de datos.
64 bytes de HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 1 ttl = 128 tiempo = 0.826 ms
64 bytes de HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 2 ttl = 128 tiempo = 0.342 ms
Además de tener solo el sufijo DNS principal poblado, puede hacer que los hosts busquen también en otros y configurarlos para que se agreguen en diferentes órdenes. Eliminando así WINS y NetBIOS todos juntos.
Ahora habrá algunos que dicen "Necesitará NetBIOS y WINS para que los productos de microsoft funcionen". Esto es cierto en realidad, pero solo para unos pocos productos, la mayoría de los cuales no se implementarán en pequeñas y medianas empresas y solo en entornos de grandes empresas, aplicaciones como SMS 2003 con su uso del registro 1A, SQL Server 2000 para el uso de canalizaciones con nombre, y Exchange Server 2000 y 2003 requieren WINS para una funcionalidad completa ... Funcionalidad COMPLETA, sin embargo, TODOS funcionarán según sea necesario sin WINS o NetBIOS.
Ah, sí, y solo si es anterior a 2000, Microsoft implementa. Sin embargo, tengo una mejor solución para ti que implementar WINS ... ¡ACTUALIZAR!
He estado en entornos donde todavía se mantiene porque 'algunos servidores heredados' podrían necesitarlo.
Creo que probablemente hay muchas tiendas por ahí que están en la misma situación.
Hace unos meses detuve el servicio WINS en nuestra LAN. Después de algunas semanas, lo eliminé por completo. Me pregunto cuántos años ha estado funcionando sin ninguna razón en particular. En algunos entornos, estoy seguro de que esto será imposible. Es posible que hayamos tenido problemas desde entonces que hubieran sido invisibles con WINS aún ejecutándose. Supongo que soy purista, pero WINS me recuerda a jugar al billar "slop". ¡Un disparo no debería contar a menos que estés apuntando a ese bolsillo!
Una cosa que nadie ha mencionado es que es necesario para los sitios VPN en subredes separadas si desea resolver nombres NetBIOS. Considere este escenario:
La red corporativa utiliza una LAN privada 10.xxx y una oficina remota utiliza una LAN privada 192.xxx. Tienen un túnel VPN entre ellos, pero la oficina remota no toma DHCP a través del túnel desde el servidor DHCP corporativo o el firewall.
Si tiene sus servidores corporativos registrados con WINS, los clientes remotos pueden resolver \ ServerName incluso desde una subred completamente separada. Eventaully podré actualizar el firewall de la oficina remota y usar DHCP sobre VPN, pero por ahora esta configuración me permite:
Alguien corríjame si me equivoco en esto, pero entiendo que NetBIOS no es enrutable, por lo que no puedo resolver los nombres de NetBIOS en la subred sin usar WINS.
Oh, todavía lo estamos usando. Alrededor de un tercio de las estaciones de trabajo de Windows que tenemos no están en el dominio y, por lo tanto, no están configuradas para usar los dominios DNS del dominio para la resolución de nombres. Además, tenemos un paisaje DNS monstruosamente fragmentado que conduce a configuraciones de dominio predeterminado monstruosamente fragmentadas. Debido a esto, WINS representa el único servicio de resolución de nombres que tiene la mayor cantidad de cosas. Es lo más cercano que tenemos a un índice global de servicios.
Si / cuando presionamos para que todo se domine, tendremos un panorama DNS plano. Eso será bueno.
Legacy Exchange todavía usa WINS, por lo que cualquiera que busque elevar los niveles funcionales a 2008 o 2012 y aún use WINS, si está usando Exchange 2003 o anterior (con suerte no), aún necesitará WINS habilitado.
Además, cualquier aplicación o script que no use FQDN en un entorno de múltiples dominios probablemente tendrá problemas.
WINS puede eliminarse, pero debe probarse metódicamente y en grandes corporaciones con muchas aplicaciones, SAP, Exchange y otras aplicaciones heredadas que se ejecutan, casi no vale la pena hasta que pueda llegar al 2012 nativo en su dominio, lo que ayudará con la descomposición de Gana
Por mi parte, no uso WINS y no he usado WINS durante 4 años. Microsoft DDNS hace un buen trabajo de resolución de nombres en una red de Active Directory. No puedo pensar en un programa que requiera WINS en este momento, pero recuerdo algunos. Guardian Firewall lo requería en el NIC del lado LAN en el pasado.
Los clústeres de Exchange 2007 no requieren WINS. De acuerdo con la documentación que tengo, MS recomienda el uso de archivos HOST, lo creas o no, en esa configuración ya que las IP no cambian.
Mi único problema con DDNS es a través de WAN. DDNS + ADC en cada segmento WAN ... con frecuencia tengo problemas con DDNS actualizando las tablas de nombres de los demás.
WINS está bien para una red de Clase C donde no tiene sitios remotos o enlaces WAN. Una gran cosa contra WINS ... SSL VPN + WINS = tecleando IP porque WINS no es un buen trabajo.
Nuestro entorno no ha utilizado WINS durante muchos meses y no ha visto ningún efecto adverso debido a ello. Tenemos una topología de sitios múltiples a través de conexiones VPN, con Exchange 2003 como nuestro servicio de correo electrónico.
WINS solo debe habilitarse si se requiere específicamente para resolver un problema conocido. Aferrarse a la tecnología anticuada "por si acaso" no tiene sentido cuando se ha asegurado de que no es necesario.