Je semble me rappeler au fil des ans les tentatives visant à arrêter l'exigence d'avoir un service de noms WINS dans le cadre d'un environnement Windows.
Ma question est de savoir si les sites utilisent toujours WINS ou sont passés à autre chose et n'ont plus besoin de WINS. Si oui, quelqu'un veut-il partager ses expériences?
Merci.
Réponses:
Beaucoup de ces réponses ne sont que partiellement vraies ou tout simplement fausses. WINS est juste une autre façon de résoudre des noms en adresses IP. Tant que vos applications savent utiliser DNS, WINS n'est pas nécessaire du tout.
Edit: D'accord, je ne peux pas croire combien il y a de désinformation sur ce fil. Tout d'abord, avoir différents sous-réseaux ne nécessite pas l'utilisation de WINS. Tant que votre application peut communiquer avec le port udp / tcp 53 sur vos serveurs DNS, vous pourrez très bien résoudre les noms d'hôtes (oui, \\ nomhôte fonctionnera également).
Deuxièmement, si vous vous demandez pourquoi vous ne pouvez rien résoudre en utilisant le nom d'hôte court (c'est-à-dire juste le nom d'hôte sans le domaine), c'est probablement parce que vous n'avez jamais configuré le domaine par défaut (ou la liste de recherche de domaine) sur vos clients.
Et enfin (mais pas des moindres!), Un domaine Active Directory n'est pas une condition préalable à l'utilisation de DNS sur un réseau Windows. La seule raison pour laquelle vous pensez que c'est parce que lorsque vous joignez une machine à un domaine, Windows définit le nom de domaine par défaut pour vous. Rien ne vous empêche de le configurer vous-même par d'autres moyens (probablement DHCP).
Donc en résumé, il suffit de définir le domaine par défaut et d'utiliser le DNS comme nous tous ici au 21e siècle!
des victoires sont encore nécessaires pour un tas de choses (de moins en moins chaque jour!). L'exemple le plus courant que j'ai vu est que Wins est une condition requise pour exécuter Exchange 2007 sur des serveurs 2003 en cluster. Wins fonctionne avec les noms Netbios. Un nom NetBIOS est un identifiant utilisé par les services NetBIOS exécutés sur un ordinateur. Il s'agit d'une combinaison d'un nom de 15 caractères (octets) et d'un 16e caractère désignant le service. Lors de l'identification des ressources réseau NetBIOS, ces noms sont utilisés. NetBIOS ne peut pas faire de résolution de noms sur Internet. Les noms NetBIOS sont des noms de pièce unique et n'ont pas de structure hiérarchique.
L'espace de noms NetBIOS est plat, ce qui signifie qu'aucun suffixe n'est ajouté au nom NetBIOS et que deux ordinateurs ne peuvent pas avoir le même nom NetBIOS. Cela signifie que chaque nom NetBIOS d'un réseau doit être unique.
Voir Fondamentaux TCP / IP pour Microsoft Windows, Chapitre 11 - NetBIOS sur TCP / IP
Dans notre entreprise, il est toujours requis pour de nombreuses applications héritées.
Je sentais que je devais modifier cela car la réponse la plus votée est catégorique FAUX!
WINS est définitivement requis dans de nombreuses organisations ces jours-ci.
Fonctionnement de WINS Mise à jour: 21 janvier 2005
Fonctionnement de WINS Par défaut, lorsqu'un ordinateur exécutant Microsoft® Windows® 2000, Windows XP ou un système d'exploitation Windows Server 2003 est configuré avec des adresses de serveur WINS (manuellement ou via DHCP) pour sa résolution de nom, il utilise un nœud hybride (h -node) comme type de nœud pour l'enregistrement de nom NetBIOS, sauf si un autre type de nœud NetBIOS est configuré. Pour la requête et la résolution de nom NetBIOS, il utilise également le comportement du nœud h, mais avec quelques différences.
Pour la résolution de noms NetBIOS, un client WINS effectue généralement la séquence générale suivante d'étapes pour résoudre un nom:
Le client vérifie si le nom interrogé est le nom de son ordinateur NetBIOS local, dont il est propriétaire.
Le client vérifie son cache de noms NetBIOS local de noms distants. Tout nom résolu pour un client distant est placé dans ce cache où il reste pendant 10 minutes.
Le client transfère la requête NetBIOS à son serveur WINS principal configuré. Si le serveur WINS principal ne répond pas à la requête - soit parce qu'il n'est pas disponible, soit parce qu'il n'a pas d'entrée pour le nom - le client essaiera de contacter d'autres serveurs WINS configurés dans l'ordre dans lequel ils sont répertoriés et configurés pour Son usage.
Le client diffuse la requête NetBIOS vers le sous-réseau local.
Le client vérifie le fichier Lmhosts pour une correspondance avec la requête, s'il est configuré pour utiliser le fichier Lmhosts.
Le client essaie le fichier Hosts puis un serveur DNS, s'il est configuré pour un.
Le problème est que toutes les applications ne peuvent pas être configurées pour utiliser DNS.
Même dans la propre explication de Microsofts de la configuration d'Active Directory, il mentionne la nécessité de WINS.
"La résolution de noms NetBIOS (serveur WINS, fichier LMHosts ou diffusion NetBIOS) est toujours requise pour les versions antérieures de Windows pour résoudre les ressources réseau sur un domaine Active Directory."
Alors oui, il y a QUELQUES organisations qui peuvent s'en tirer sans utiliser WINS, mais faire une déclaration générale que si vous pouvez frapper le serveur DNS, comme par magie, vous n'avez pas besoin de WINS, c'est faux.
WINS est toujours une exigence, malgré chaque tentative de chaque administrateur Windows dans le monde pour le matraquer à mort. Chaque fois qu'il y a une séparation des sous-réseaux, vous aurez besoin de WINS. Vous utilisez un VPN pour des sites distincts? Cela implique un sous-réseau - et WINS. Vous avez des clients plus âgés qui ne comprennent pas la MA? Vous avez besoin de WINS. Vous avez une application DOS que vous mettez en réseau? GAGNE à nouveau.
WINS est également utilisé pour remplir les listes de navigation. Bien que les machines basées sur Active Directory puissent fonctionner sans WINS, il peut y avoir un délai car les listes de navigation sont remplies dans l'ordre suivant:
Le nœud du problème vient des racines de LANMAN, qui a engendré SMB, qui a engendré CIFS ... vous pouvez voir où cela va. LANMAN était vraiment un protocole basé sur LAN - il n'avait pas de concept d '"Internet", encore moins de "routage". WINS a été développé pour combler cet écart et rendre possible le routage. Avance rapide jusqu'à présent et CIFS a toujours un support rétrocompatible pour LANMAN. Les noms de chemin UNC peuvent être "modernes", mais ils seront toujours attachés à un serveur LANMAN. Ensuite, il y a toute la "liste de navigation" chose ...
MS est sur le point de sortir du serveur WINS, mais il y a tout simplement trop de crochets "hérités", non seulement dans le système d'exploitation, mais aussi dans les applications et les services, qui nécessitent un serveur WINS. Et tant qu'il y aura un support pour les transmissions de type LANMAN , il sera nécessaire d'avoir un serveur WINS autour.
ÉDITER:
Oui, vous pouvez désactiver WINS dans un domaine plat.
Pourtant...
Autant que je veux voir ce service avoir un enjeu dans son cœur, il ne va pas disparaître jusqu'à ce que Microsoft revienne et réorganise la façon dont ils font les services LAN. (Oui, il y a un commentaire sur ce lien sur la façon dont ce n'est pas nécessaire aussi ... mais lisez ce qui est dit par la bouche du cheval ...)
Ne confondons pas les victoires et les netbios ..... vous pouvez exécuter netbios sur un réseau sans serveur WINS, mais ce n'est pas recommandé sur un domaine. Vous ne voulez pas vraiment que toutes ces élections géniales se déroulent lorsque vous avez un bon serveur DNS sur le réseau, donc netbios doit être désactivé ou un serveur WINS doit être utilisé. (J'utilise correctement dans le sens le plus vague du terme en ce qui concerne MS DNS :-))
Récemment, j'ai eu un problème avec Exchange 2007 sur Windows 2008 nécessitant l'activation de NetBIOS. incroyable!!!
Beaucoup de ces réponses sont incorrectes ou partiellement correctes. Voyons d'abord pourquoi WINS peut être utilisé en premier lieu.
WINS est utilisé comme solution pour résoudre les noms d'hôtes en adresses IP ... mais pourquoi aurions-nous besoin de WINS si NetBIOS fonctionne dans tous les senerios? Continuer à lire!
DNS utilisé dans le même but et plus ... pour résoudre les noms de domaine ET les noms d'hôte pleinement qualifiés en adresses IP.
Voyons maintenant pourquoi WINS a été développé.
Problème: NetBIOS était à l'origine utilisé pour résoudre des noms mais c'est un protocole réseau de diffusion. Ainsi, dans la plupart des réseaux, hérités et actuels, le trafic de diffusion est incapable de traverser les routeurs, et bientôt assez de pare-feu, plus tard, nous le constatons également dans le trafic VPN. Ainsi, la plupart des sous-réseaux ne répliqueront pas le trafic NetBIOS vers d'autres sous-réseaux. Si vous êtes un véritable administrateur de réseau informatique, vous serez familiarisé avec ce trafic NetBIOS sur les routeurs, les commutateurs et les pare-feu:
Accès UDP refusé par ACL de HOST-17/137 à l'intérieur: 10.0.1.127/137
Accès UDP refusé par ACL de HOST-A / 137 à l'intérieur: 10.0.1.127/137
Accès UDP refusé par ACL de HOST-09/137 à l'intérieur: 10.0.1.127/137
Accès UDP refusé par ACL de HOST-02/137 à l'intérieur: 10.0.1.127/137
Accès UDP refusé par ACL de HOST-02/137 à l'intérieur: 10.0.1.127/137
Ceci est un exemple de cinq (5) diffusions NetBIOS sur un réseau 25 bits à partir d'un fichier syslog de pare-feu Cisco Pix 515E. Pour ceux qui ne connaissent rien d'autre que ce que leur routeur Linksys est un réseau 25 bits est plus petit que votre réseau 24 bits:
Réseau: 10.0.1.0/25, masque de sous-réseau: 255.255.255.128, adresse de diffusion: 10.0.1.127, hôtes maximum: 126. Comme on peut le voir, le trafic est contenu dans le segment.
Solution: WINS est développé pour être déployé sur un sous-réseau où le trafic de diffusion est contenu, les clients peuvent être configurés et pointés vers un serveur WINS pour résoudre les noms au lieu de s'appuyer sur le trafic de diffusion et donc NetBios devient désormais la solution de rechange lorsque les requêtes WINS échouent.
Mais attendez ... nous configurons les serveurs DNS maintenant lorsque nous déployons nos réseaux Microsoft. Désormais, DNS est principal, lorsque DNS échoue, NetBIOS est la solution de rechange. Si un serveur WINS est déployé, DNS, WINS et NetBIOS.
Le problème que beaucoup peuvent rencontrer est quand ils essaient de cingler un nom d'hôte, disons HOST-A. Selon la configuration de l'interface des ordinateurs, il peut ne pas être en mesure de résoudre l'adresse en IP, principalement si vous venez de configurer DNS et que les noms NetBIOS enregistrés par les hôtes ont expiré.
Supposons que HOST-A fait partie de domainhosts.com et a été joint à ce domaine, un enregistrement (A) de l'hôte sur le serveur DNS DC principal pour domainhosts.com. Pour résoudre l'adresse uniquement par son nom d'hôte et non par son nom de domaine complet (FQDN), la configuration IP doit avoir "Ajouter des suffixes DNS principaux et spécifiques à la connexion" et avoir au moins le "Suffixe DNS pour cette connexion: domainhosts.com" peuplé! Lorsque la résolution de HOST-A est effectuée, deux (2) morceaux d'informations supplémentaires sont renvoyés: l'adresse IP vers laquelle le nom d'hôte se résout et son nom de domaine complet HOST-A.domainhosts.com. Dans l'exemple ci-dessous, la résolution d'un nom d'hôte est effectuée en recherchant les enregistrements (A) du domaine au lieu de WINS ou NetBIOS:
[Utilisateur @ localhost ~] $ ping HOST-A
PING HOST-A.domainhosts.com (10.0.1.10) 56 (84) octets de données.
64 octets de HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 1 ttl = 128 time = 0.826 ms
64 octets de HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 2 ttl = 128 time = 0.342 ms
En plus de ne remplir que le suffixe DNS principal, vous pouvez également demander aux hôtes de rechercher d'autres personnes et de les configurer pour les ajouter dans des ordres différents. Éliminant ainsi WINS et NetBIOS tous ensemble.
Maintenant, il y en aura qui diront "Vous aurez besoin de NetBIOS et WINS pour que les produits Microsoft fonctionnent." Cela est vrai en réalité, mais seulement pour quelques produits, dont la plupart ne seront pas déployés dans des petites ou moyennes entreprises et uniquement dans des environnements de grande entreprise, des applications telles que SMS 2003 avec son utilisation de l'enregistrement 1A, SQL Server 2000 pour l'utilisation de canaux nommés et Exchange Server 2000 et 2003 nécessitent tous WINS pour une fonctionnalité complète ... Fonctionnalité COMPLÈTE, ils fonctionneront TOUS selon les besoins sans WINS ou NetBIOS.
Oh oui, et seulement si vous êtes déployé par Microsoft avant 2000. J'ai une meilleure solution pour vous que de déployer WINS ... MISE À NIVEAU !!
J'ai été dans des environnements où il est toujours maintenu car «certains serveurs hérités» pourraient en avoir besoin.
Je pense qu'il y a probablement beaucoup de magasins qui sont dans la même situation.
De nombreux appareils intégrés utilisent également WINS. Nous avons des photocopieuses multifonctions et un système de projection sans fil acheté récemment qui ne fonctionnerait pas tant que je ne lui aurais pas donné l'IP d'un serveur WINS.
Autant que nous le souhaiterions, WINS sera là pour longtemps.
Il y a quelques mois, j'ai arrêté le service WINS sur notre réseau local. Après quelques semaines, je l'ai entièrement retiré. Je me demande depuis combien d'années cela fonctionne sans raison particulière? Dans certains environnements, je suis sûr que ce sera impossible. Il est possible que nous ayons eu des problèmes depuis lors qui auraient été invisibles avec WINS toujours en cours d'exécution. Je suppose que je suis un puriste, mais WINS me rappelle de jouer au billard "slop". Un tir ne devrait pas compter à moins que vous ne visiez cette poche!
Une chose que personne n'a mentionnée est qu'il est nécessaire pour les sites VPN sur des sous-réseaux distincts si vous souhaitez résoudre les noms NetBIOS. Considérez ce scénario:
Le réseau d'entreprise utilise un LAN 10.xxx privé et un bureau distant utilise un LAN 192.xxx privé. Ils ont un tunnel VPN entre eux, mais le bureau distant ne prend pas DHCP via le tunnel depuis le serveur DHCP ou le pare-feu de l'entreprise.
Si vos serveurs d'entreprise sont enregistrés auprès de WINS, les clients distants peuvent résoudre \ ServerName même à partir d'un sous-réseau entièrement distinct. Finalement, je pourrai mettre à niveau le pare-feu du bureau distant et utiliser DHCP sur VPN, mais pour l'instant cette configuration me permet de:
Quelqu'un, s'il vous plaît, corrigez-moi si je me trompe, mais je crois comprendre que NetBIOS n'est pas routable, donc je ne peux pas résoudre les noms NetBIOS sur le sous-réseau sans utiliser WINS.
Oh, nous l'utilisons toujours. Environ un tiers des postes de travail Windows que nous avons ne se trouvent pas dans le domaine et ne sont donc pas configurés pour utiliser les domaines DNS du domaine pour la résolution de noms. De plus, nous avons un paysage DNS monstrueusement fragmenté qui conduit à des paramètres de domaine par défaut monstrueusement fragmentés. Pour cette raison, WINS représente le service de résolution de nom unique qui contient le plus de contenu. C'est le plus proche que nous ayons d'un index mondial des services.
Si / Quand nous poussons pour que tout soit dominé, nous aurons un paysage DNS plat. Ça sera bien.
Legacy Exchange utilise toujours WINS, donc quiconque cherche à augmenter les niveaux fonctionnels à 2008 ou 2012 et utilise toujours WINS, si vous utilisez Exchange 2003 ou une version antérieure (espérons-le non), vous aurez toujours besoin de WINS activé.
En outre, toutes les applications ou scripts qui n'utilisent pas le nom de domaine complet dans un environnement multi-domaine auront probablement des problèmes.
WINS peut être supprimé, mais il doit être méthodiquement testé et dans les grandes entreprises avec beaucoup d'applications, SAP, Exchange et d'autres applications héritées, il n'en vaut presque pas la peine tant que vous ne pourrez pas accéder à 2012 en natif sur votre domaine, ce qui vous aidera à décomposer GAGNE.
Pour ma part, je n'utilise pas WINS et je n'ai pas utilisé WINS depuis 4 ans. Microsoft DDNS fait un excellent travail de résolution de noms sur un réseau Active Directory. Je ne peux pas penser à un programme qui nécessite WINS en ce moment, mais je me souviens de quelques-uns. Guardian Firewall en avait besoin sur la carte réseau côté LAN dans la journée.
Les clusters Exchange 2007 ne nécessitent pas WINS. Selon la documentation que j'ai, MS recommande l'utilisation de fichiers HOST, croyez-le ou non, dans cette configuration car les IP ne changent pas.
Mon seul problème avec DDNS concerne le WAN. DDNS + ADC sur chaque segment WAN ... fréquemment, j'ai des problèmes avec DDNS pour mettre à jour les tables de noms des autres.
WINS est bien pour un réseau de classe C où vous n'avez pas de sites distants ou de liaisons WAN. Une chose énorme contre WINS ... SSL VPN + WINS = taper cuz WINS IP n'est pas goona werk.
Notre environnement n'a pas utilisé WINS depuis de nombreux mois et n'a vu aucun effet indésirable à cause de cela. Nous avons une topologie multisite via des connexions VPN, avec Exchange 2003 comme service de messagerie.
WINS ne doit être activé que s'il est spécifiquement requis pour résoudre un problème connu. Conserver la technologie désuète "au cas où" n'a aucun sens lorsque vous vous êtes assuré qu'elle n'est pas nécessaire.