Mi sembra di ricordare nel corso degli anni le mosse per cercare di fermare il requisito di avere un nameservice WINS come parte di un ambiente Windows.
La mia domanda è se i siti utilizzano ancora WINS o sono passati a qualcos'altro e non hanno più bisogno di WINS. Se è così, qualcuno vuole condividere le proprie esperienze?
Grazie.
Risposte:
Molte di queste risposte sono solo parzialmente vere o semplicemente sbagliate. WINS è solo un altro modo per risolvere i nomi in indirizzi IP. Finché le tue applicazioni sanno come usare il DNS, WINS non è affatto necessario.
Modifica: Okay, non riesco a credere a quanta disinformazione ci sia su questo thread. Innanzitutto, avere sottoreti diverse non richiede l'uso di WINS. Finché l'applicazione può comunicare con la porta 53 udp / tcp sui server DNS, sarai in grado di risolvere bene i nomi host (sì, funzionerà anche \\ nomehost).
In secondo luogo, se ti stai chiedendo perché non riesci a risolvere nulla utilizzando il nome host breve (ovvero solo il nome host senza il dominio), è probabilmente perché non hai mai configurato il dominio predefinito (o l'elenco di ricerca del dominio) sui tuoi client.
Infine, (ma non meno importante!), Un dominio Active Directory non è un prerequisito per l'utilizzo del DNS su una rete Windows. L'unica ragione per cui pensi che sia perché quando si unisce una macchina a un dominio, Windows imposta il nome di dominio predefinito per te. Non c'è nulla che ti impedisca di impostarlo da solo con altri mezzi (probabilmente DHCP).
Quindi, in sintesi, basta impostare il dominio predefinito e usare DNS come tutti noi qui nel 21 ° secolo!
le vincite sono ancora necessarie per un sacco di cose (sempre meno ogni giorno!). L'esempio più comune che ho visto è che vincere è un requisito per eseguire Exchange 2007 su server cluster 2003. Wins funziona con i nomi Netbios. Un nome NetBIOS è un identificatore utilizzato dai servizi NetBIOS in esecuzione su un computer. È una combinazione di un nome di 15 caratteri (byte) e di un sedicesimo carattere che indica il servizio. Quando si identificano le risorse di rete NetBIOS, vengono utilizzati questi nomi. NetBIOS non può eseguire la risoluzione dei nomi su Internet. I nomi NetBIOS sono nomi di parti singole e non hanno alcuna struttura gerarchica.
Lo spazio dei nomi NetBIOS è piatto, il che significa che non sono stati aggiunti suffissi al nome NetBIOS e che due computer non possono avere lo stesso nome NetBIOS. Ciò significa che ogni nome NetBIOS in una rete deve essere univoco.
Vedere Fondamenti TCP / IP per Microsoft Windows, Capitolo 11 - NetBIOS su TCP / IP
Nella nostra Enterprise è ancora necessario per molte applicazioni legacy.
Ritenevo necessario modificarlo poiché la risposta più votata è completamente sbagliata!
Oggigiorno WINS è sicuramente richiesto in molte oraganizzazioni.
Come funziona WINS Aggiornato: 21 gennaio 2005
Come funziona WINS Per impostazione predefinita, quando un computer che esegue Microsoft® Windows® 2000, Windows XP o un sistema operativo Windows Server 2003 è configurato con indirizzi di server WINS (manualmente o tramite DHCP) per la risoluzione dei nomi, utilizza un nodo ibrido (h -node) come tipo di nodo per la registrazione del nome NetBIOS a meno che non sia configurato un altro tipo di nodo NetBIOS. Per la query e la risoluzione dei nomi NetBIOS, utilizza anche il comportamento del nodo h, ma con alcune differenze.
Per la risoluzione dei nomi NetBIOS, un client WINS esegue in genere la seguente sequenza generale di passaggi per risolvere un nome:
Il client verifica se il nome richiesto è il nome del computer NetBIOS locale di cui è proprietario.
Il client controlla la cache dei nomi NetBIOS locale dei nomi remoti. Qualsiasi nome risolto per un client remoto viene inserito in questa cache dove rimane per 10 minuti.
Il client inoltra la query NetBIOS al suo server WINS primario configurato. Se il server WINS primario non risponde alla query, perché non è disponibile o perché non ha una voce per il nome, il client proverà a contattare altri server WINS configurati nell'ordine in cui sono elencati e configurati il suo utilizzo.
Il client trasmette la query NetBIOS alla sottorete locale.
Il client controlla la corrispondenza del file Lmhosts con la query, se è configurato per utilizzare il file Lmhosts.
Il client prova il file Hosts e quindi un server DNS, se è configurato per uno.
Il problema è che non tutte le applicazioni possono essere configurate per l'uso del DNS.
Anche nella spiegazione di Microsoft dell'installazione di Active Directory viene menzionata la necessità di WINS.
"La risoluzione dei nomi NetBIOS (server WINS, file LMHosts o trasmissione NetBIOS) è ancora necessaria per le versioni precedenti di Windows per risolvere le risorse di rete su un dominio Active Directory."
Quindi sì, ci sono ALCUNE organizzazioni che possono cavarsela senza usare WINS, ma per fare un'affermazione generale che se riesci a colpire il server DNS, magicamente non hai bisogno di WINS è sbagliato.
WINS è ancora un requisito, nonostante ogni tentativo da parte di tutti gli amministratori di Windows nel mondo di razziarlo a morte. Ogni volta che c'è una separazione di sottoreti, avrai bisogno di WINS. Esegui una VPN per siti separati? Ciò implica una sottorete - e VINCE. Hai client più vecchi che non capiscono la pubblicità? Hai bisogno di vittorie. Hai un'applicazione DOS che stai collegando in rete? VINCE di nuovo.
WINS viene anche utilizzato per popolare gli elenchi di ricerca. Mentre le macchine basate su Active Directory possono funzionare senza WINS, può esserci un ritardo poiché gli elenchi di ricerca vengono popolati nella seguente sequenza:
Il nocciolo del problema deriva dalle radici di LANMAN, che ha generato SMB, che ha generato CIFS ... puoi vedere dove sta andando. LANMAN era molto un protocollo basato su LAN - non aveva il concetto di "Internet", tanto meno di "routing". WINS è stato sviluppato per colmare questa lacuna e rendere possibile il routing. Avanti veloce al presente, e CIFS ha ancora un supporto retrocompatibile per LANMAN. I nomi di percorso UNC possono essere "moderni", ma si collegheranno comunque a un server LANMAN. Poi c'è l'intera cosa "sfoglia l'elenco" ...
MS è molto vicino a uscire dal biz del server WINS ma ci sono troppi hook "legacy", non solo nel sistema operativo, ma anche in applicazioni e servizi che richiedono un server WINS. E finché esiste il supporto per le trasmissioni in stile LANMAN , sarà necessario disporre di un server WINS.
MODIFICARE:
Sì, puoi disattivare WINS in un dominio flat.
Tuttavia...
Per quanto voglia vedere che questo servizio ha una posta in gioco nel suo cuore, non andrà via fino a quando Microsoft non si riunirà e rinnoverà come fanno i servizi LAN. (Sì, c'è un commento a quel link su come non è necessario anche ... ma vai a leggere ciò che viene detto dalla bocca del cavallo ...)
Non confondiamo tra vittorie e netbios ..... puoi eseguire netbios su una rete senza un server WINS, ma non è raccomandato su un dominio. Non vuoi davvero che tutte quelle elezioni funky si svolgano quando hai un server DNS adeguato sulla rete, quindi netbios dovrebbe essere disabilitato o dovrebbe essere usato un server WINS. (Uso proprio nel senso più lento del termine per quanto riguarda MS DNS :-))
Recentemente ho avuto un problema con Exchange 2007 su Windows 2008 che richiede l'attivazione di netbios. incredibile!!!
Molte di queste risposte sono errate o parzialmente corrette. Innanzitutto, cerchiamo di capire perché WINS può essere utilizzato in primo luogo.
WINS viene utilizzato come soluzione per risolvere i nomi host in indirizzi IP ... ma perché dovremmo aver bisogno di WINS se NetBIOS funziona in tutti i senerios? Continuare a leggere!
DNS utilizzato per lo stesso scopo e altro ... per risolvere nomi di dominio e nomi host completi in indirizzi IP.
Ora diamo un'occhiata al motivo per cui WINS è stato sviluppato.
Problema: NetBIOS era originariamente utilizzato per risolvere i nomi ma è un protocollo di rete di trasmissione. Quindi nella maggior parte delle reti, legace e attuali, il traffico di trasmissione non è in grado di attraversare i router, e presto abbastanza firewall, in seguito lo troviamo anche nel traffico VPN. Pertanto, la maggior parte delle sottoreti non replicherà il traffico NetBIOS su altre sottoreti. Se sei un vero amministratore di rete IT, avrai familiarità con questo traffico NetBIOS su router, switch e firewall:
Accesso UDP negato da ACL da HOST-17/137 all'interno: 10.0.1.127/137
Accesso UDP negato da ACL da HOST-A / 137 all'interno: 10.0.1.127/137
Accesso UDP negato da ACL da HOST-09/137 all'interno: 10.0.1.127/137
Accesso UDP negato da ACL da HOST-02/137 all'interno: 10.0.1.127/137
Accesso UDP negato da ACL da HOST-02/137 all'interno: 10.0.1.127/137
Questo è un esempio di cinque (5) trasmissioni NetBIOS su una rete a 25 bit da un file syslog del firewall Cisco Pix 515E. Per coloro che non hanno familiarità con qualcosa di diverso da quello che il loro router Linksys è una rete a 25 bit è più piccola della tua rete a 24 bit:
Rete: 10.0.1.0/25, Subnet Mask: 255.255.255.128, Indirizzo di trasmissione: 10.0.1.127, Max host: 126. Come si può vedere, il traffico è contenuto nel segmento.
Soluzione: WINS è sviluppato per essere distribuito su una sottorete in cui è contenuto il traffico di trasmissione, i client possono configurare e puntare a un server WINS per risolvere i nomi invece di fare affidamento sul traffico di trasmissione e quindi NetBios ora diventa il fallback quando le query WINS falliscono.
Ma aspetta ... configuriamo ora i server DNS quando implementiamo le nostre reti microsoft. Ora DNS è primario, quando DNS fallisce, NetBIOS è il fallback. Se è distribuito un server WINS, DNS, WINS e NetBIOS.
Il problema che molti potrebbero incontrare è quando provano a eseguire il ping di un nome host, diciamo HOST-A. A seconda della configurazione dell'interfaccia del computer, potrebbe non essere possibile risolvere l'indirizzo in un IP, principalmente se si è appena configurato il DNS e i nomi NetBIOS registrati degli host sono scaduti.
Diciamo che HOST-A fa parte di domainhosts.com ed è stato unito a quel dominio, un record (A) dell'host sul server DNS DC primario per domainhosts.com. Per risolvere l'indirizzo solo con il suo nome host e non con il suo nome di dominio completo (nome di dominio completo), la configurazione IP deve avere "Aggiungi suffissi DNS primari e specifici della connessione" e avere il minimo "Suffisso DNS per questa connessione: domainhosts.com" popolato! Quando viene eseguita la risoluzione di HOST-A, vengono restituiti due (2) pezzetti di informazioni extra: l'indirizzo IP a cui il nome host si risolve e il suo FQDN di HOST-A.domainhosts.com. Nell'esempio seguente la risoluzione di un nome host viene eseguita cercando i record (A) del dominio anziché WINS o NetBIOS:
[Utente @ localhost ~] $ ping HOST-A
PING HOST-A.domainhosts.com (10.0.1.10) 56 (84) byte di dati.
64 byte da HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 1 ttl = 128 tempo = 0.826 ms
64 byte da HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 2 ttl = 128 tempo = 0.342 ms
Oltre ad avere solo il suffisso DNS primario popolato, puoi fare in modo che anche gli host cerchino gli altri e configurarli per aggiungerli in diversi ordini. Eliminando così WINS e NetBIOS tutti insieme.
Ora ci saranno alcuni là fuori che dicono "Avrai bisogno di NetBIOS e WINS perché i prodotti Microsoft funzionino". Questo è vero nella realtà, ma solo per alcuni prodotti, la maggior parte dei quali non verrà implementata in piccole o medie imprese e solo in grandi ambienti aziendali, applicazioni come SMS 2003 con il suo utilizzo del record 1A, SQL Server 2000 per l'uso di pipe denominate, ed Exchange Server 2000 e 2003 richiedono tutti WINS per la piena funzionalità ... Funzionalità COMPLETA, funzioneranno TUTTI secondo necessità senza WINS o NetBIOS.
Oh sì, e solo se sei Microsoft prima del 2000. Ho una soluzione migliore per te che distribuire WINS però ... AGGIORNAMENTO !!
Sono stato in ambienti in cui è ancora gestito perché "alcuni server legacy" potrebbero averne bisogno.
Penso che ci siano probabilmente molti negozi là fuori che si trovano nella stessa situazione.
Alcuni mesi fa ho interrotto il servizio WINS sulla nostra LAN. Dopo alcune settimane l'ho rimosso del tutto. Mi chiedo da quanti anni corre senza un motivo particolare? In alcuni ambienti sono sicuro che questo sarà impossibile. È possibile che da allora abbiamo avuto problemi che sarebbero stati invisibili con WINS ancora in esecuzione. Immagino di essere un purista, ma WINS mi ricorda di giocare a "slop" pool. Un tiro non dovrebbe contare se non miravi a quella tasca!
Una cosa che nessuno ha menzionato è che è necessario per i siti VPN su sottoreti separate se si desidera risolvere i nomi NetBIOS. Considera questo scenario:
La rete aziendale utilizza una LAN 10.xxx privata e un ufficio remoto utilizza una LAN 192.xxx privata. Hanno un tunnel VPN tra di loro, ma l'ufficio remoto non prende DHCP attraverso il tunnel dal server DHCP aziendale o dal firewall.
Se i server aziendali sono registrati con WINS, i client remoti possono risolvere \ ServerName anche da una sottorete completamente separata. Alla fine sarò in grado di aggiornare il firewall dell'ufficio remoto e utilizzare DHCP su VPN, ma per ora questa configurazione mi consente di:
Qualcuno, per favore, mi corregga se sbaglio su questo, ma la mia comprensione è che NetBIOS non è instradabile, quindi non posso risolvere i nomi NetBIOS attraverso la sottorete senza usare WINS.
Oh, lo stiamo ancora usando. Circa un terzo delle workstation di Windows che abbiamo non sono nel dominio e quindi non sono configurate per utilizzare i domini DNS del dominio per la risoluzione dei nomi. Inoltre, abbiamo un panorama DNS mostruosamente frammentato che porta a impostazioni di dominio predefinito mostruosamente frammentate. Per questo motivo WINS rappresenta il singolo servizio di risoluzione dei nomi che contiene più elementi. È il più vicino che abbiamo a un indice globale di servizi.
Se / quando spingiamo per ottenere tutto il dominio, avremo un panorama DNS piatto. Quello sarà buono.
Scambio legacy utilizza ancora WINS, quindi chiunque cerchi di aumentare i livelli funzionali al 2008 o 2012 e continua a utilizzare WINS, se si utilizza Exchange 2003 o versioni precedenti (si spera di no), sarà comunque necessario abilitare WINS.
Inoltre, eventuali app o script che non utilizzano FQDN in un ambiente multi-dominio avranno probabilmente problemi.
I WINS possono essere rimossi ma dovrebbero essere testati metodicamente e in grandi aziende con molte app, SAP, Exchange e altre app legacy in esecuzione non ne vale quasi la pena fino a quando non si può arrivare al 2012 nativo sul proprio dominio, che aiuterà con il decom WINS.
Io per primo, non uso WINS e non uso WINS da 4 anni. Microsoft DDNS fa un ottimo lavoro di risoluzione dei nomi su una rete di Active Directory. Non riesco a pensare a un programma che richiede WINS in questo momento, ma ne ricordo alcuni. Guardian Firewall lo richiedeva nella scheda NIC lato LAN nel corso della giornata.
I cluster di Exchange 2007 non richiedono WINS. Secondo la documentazione che ho, MS consiglia l'uso di file HOST, che ci crediate o no, in quella configurazione poiché l'IP non cambia.
Il mio unico problema con DDNS è attraverso WAN. DDNS + ADC su ogni segmento WAN ... frequentemente ho problemi con DDNS che aggiorna le tabelle dei nomi degli altri.
WINS va bene per una rete di classe C in cui non si hanno siti remoti o collegamenti WAN. Una cosa enorme contro WINS ... SSL VPN + WINS = digitando IP perché WINS non è perfetto.
Il nostro ambiente non utilizza WINS da molti mesi e non ha visto effetti negativi a causa di ciò. Abbiamo una topologia multi-sito tramite connessioni VPN, con Exchange 2003 come nostro servizio di posta elettronica.
WINS deve essere abilitato solo se è specificamente richiesto per risolvere un problema noto. Mantenere la tecnologia antiquata "per ogni evenienza" non ha senso quando si è assicurati che non sia necessario.