Faq su WINS

Cos'è WINS?
WINS (Windows Internet Name Service) è un servizio che mantiene nel proprio database la corrispondenza tra i nomi NetBios ed indirizzi IP in modo da permettere la risoluzione dinamica dei nomi. In passato prima della nascita dei servizi Wins e Dns era necessario compilare manualmente i file host (dns) e il file lmhost (wins), cosa non più fattibile con la crescita esponenziale delle reti.
L'utilità di Wins in un dominio completamente Windows 2000 (modalità originale) non è più necessaria poichè il DNS e l'integrazione con Active Directory permette di gestire efficientemente la risoluzione dei nomi. Nel caso in cui il dominio sia in modalità mista (client Windows 95/98 e Windows 2000) è necessaria la presenza del servizio Wins.

Come installo il servizio Wins?
Wins è un servizio Server. Dal pannello di controllo --- Rete --- Servizi aggiungere il servizio Wins. Se ci sono client non-wins devi aggiungere un mapping statico nome pc---indirizzo IP (vedi file lmhosts) Configurare un Wins Proxy Agent se necessario. Configurare il supporto Wins sul server DHCP.
Sul client NT Workstation posizionarsi sulle proprietà del protocollo TCP/IP e nella voce WINS aggiungere l'indirizzo IP del server primario WINS ed eventualmente del secondario. L'utilizzo del DHCP non necessita di specificare gli indirizzi IP dei server.

Cos'è un WINS Proxy Agent?
Se la tua rete utilizza client non Wins (es. Unix) è necessario utilizzare un Proxy Agent per le subnet dove risiedono i client non-wins. Un Client Wins Proxy Agent è un client Wins che ascolta le richieste broadcast per poi instradarle al proprio server Wins.
Per impostare un Client Wins Proxy Agent:
- aprire il regedit
- posizionarsi in
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
  e impostare il parametro EnableProxy ad 1.

Come posso comprimere il database WINS?
NT Server utilizza un utility chiamata Jetpack.exe che permette di comprimere sia il database DHCP che WINS. Per comprimere il database WINS esegui i seguenti passi:
1. Avvia il prompt dei comandi (cmd.exe)
2. Posizionati nel percorso c:winntsystem32wins
3. esegui "net stop Wins"
4. esegui il comando "jetpack WINS.mdb tmp.mdb"
5. riavvia il servizio "net start Wins"
Nota: Jetpack comprimerà Wins.mdb in tmp.mdb, poi eliminerà Wins.mdb e copierà Tmp.mdb in Wins.mdb.

Come ricreo un database WINS in Windows NT Server?
1. Dal prompt dei comandi (cmd.exe) ferma il servizio wins "net stop wins".
2. Crea una cartella temporanea denominata ad esempio WINS_Old.
3. Sposta il contenuto corrente della cartella WINS nella cartella temporanea. WINS si trova nella cartella winnt\System32\WINS.
4. Riavvia WINS "net start wins". All'avvio di WINS, vengono creati nuovi file di database di WINS.

Individuare i propri obiettivi da raggiungere con WINS
Numerosi amministratori di rete incontrano difficoltà nell’implementare una efficace strategia dei server Windows Internet Name Service (WINS). Questi amministratori infatti rivolgono spesso domande sulla modalità di funzionamento di WINS in ambienti piccoli o grandi, sulla determinazione del numero effettivo di server, sull’utilizzo di WINS con client Novell NetWare e sulla protezione di WINS da accessi non autorizzati al sistema. Prima di affrontare le domande che più frequentemente vengono poste, è opportuno rivedere l’evoluzione della risoluzione di nome e come si è poi arrivati a WINS (se però si desidera avere subito risposte alle suddette domande, vedere il box "WINS o non WINS?" per ricevere qualche immediato suggerimento).

Una breve storia
In passato gli amministratori di rete erano costretti a eseguire due passaggi consecutivi per effettuare la risoluzione di nome su reti Microsoft TCP/IP. Il primo passaggio era il Domain Name System (DNS) - non un vero problema per gli esperti amministratori UNIX che avevano già una certa familiarità con i file HOSTS e con il namespace DNS sul server. Mantenere comunque indirizzi statistici e nomi per centinaia di nodi in numerosi server DNS può costringere gli amministratori di rete a rifletterci più di una volta sola. Standard de facto per l’attribuzione di nomi in Internet, tutte le reti adottavano il DNS. Se opportunamente configurato, il DNS permette una corretta comunicazione in rete di tutte le applicazioni basate sul TCP/IP.
Il secondo passaggio era di permettere ai client Microsoft la condivisione di file e stampanti. A partire da LAN Manager, Microsoft ha creato una risoluzione di nome su NetBIOS. Nelle reti NetBIOS i computer diffondono il proprio nome NetBIOS unico e locale sulla rete - un approccio completamente differente rispetto alla natura prettamente orientata alla connessione del TCP/IP. In piccoli ambienti dove sono presenti dei bridge, le prestazioni del NetBIOS risultavano eccellenti in termini di throughput della rete (sebbene con un elevato utilizzo dell’ampiezza di banda disponibile).
A ogni modo, via via che le reti sono diventate più grandi e il TCP/IP è risultato sempre più adottato in reti di grandi dimensioni, segmentate e provviste di router, si è resa necessaria l’adozione di NetBIOS. Poiché questo è un protocollo basato su broadcast non può passare attraverso router. Per questo motivo Microsoft a introdotto il file LMHOSTS, l’equivalente NetBIOS di un file HOSTS locale per il TCP/IP.
Il file LMHOSTS mappa i nomi NetBIOS in indirizzi IP in modo che i client possano condividere file e stampanti in una rete connessa attraverso dei router. Comunque, allo stesso modo del file HOSTS, la gestione locale di ogni workstation diventava così un incubo, se non addirittura impossibile. Infatti, sebbene LMHOSTS supportasse riferimenti per file centralizzati, non era in ogni modo sufficiente a rendere più facile la vita degli amministratori di rete.
Il passo in avanti è stato invece fatto con Windows NT 3.5 e l’introduzione di WINS. Questo infatti fornisce due importanti funzioni. Esegue una risoluzione dinamica dei nomi NetBIOS rispetto agli indirizzi TCP/IP, e riduce i broadcast della risoluzione di nome impostando i computer per il tipo H-node, il che permette ai computer stessi di far riferimento direttamente al server WINS per la ricerca del nome. Se WINS non è disponibile o il nome non si trova nel database, WINS ricorre a un broadcast. A tutti gli effetti WINS e DNS raggiungono comunque lo stesso scopo.
A questo punto dovrebbe essere chiaro cosa fa effettivamente WINS. Cercheremo ora di risolvere i dubbi degli amministratori di rete riguardo le modalità di utilizzo di WINS negli ambienti attuali.
Ambienti di piccole dimensioni
"Io gestisco una piccola rete con 20 nodi che lavora con NT e Windows 95. Ho bisogno di WINS?"
Le organizzazioni con piccole reti o uffici ramificati rifiutavano precedentemente la complessità della gestione con TCP/IP. Erano soliti infatti optare per protocolli di facile supporto su reti locali, come per esempio NWLink e IPX/SPX. Ora però che la connessione a Internet è diventata praticamente la norma, le priorità sono cambiate.
Nonostante tutto molti amministratori, a torto, credono ancora che solo le grosse reti TCP/IP necessitino di WINS. Se la vostra organizzazione gestisce numerosi piccoli ambienti con un supporto amministrativo e tecnico minimo, l’utilizzo di WINS ha un senso (anche solo da un punto di vista amministrativo l’utilizzo di WINS ha un senso).
Quando si organizzano reti NT in luoghi piccoli o in luoghi con un supporto on-site minimo, può essere opportuno considerare l’utilizzo di WINS sui domain controller presenti. Queste macchine possono essere utilizzate anche per altri servizi oltre a quello di file server dedicati.
Comunque, ambienti che utilizzano un singolo server per la gestione del dominio e la condivisione di file e stampe hanno ovviamente bisogno di WINS sul file server principale. In queste condizioni, WINS non aggiungerà molto carico lavorativo Poiché vengono utilizzate poche stazioni di lavoro e le modifiche agli indirizzi IP, nonché i cambiamenti dei nomi, sono verosimilmente pochi.
Per identificare la migliore distribuzione WINS sui server, bisogna anche decidere l’importanza della risoluzione di nome di WINS. Se il server WINS primario si guasta oppure diventa indisponibile la comunicazione sulla rete TCP/IP può divenire difficoltosa. Anche una macchina che sfoglia le risorse della rete trova problemi se non è presente un server WINS in una rete segmentata dove è presente solo TCP/IP. Sarebbe possibile eventualmente impostare i file LMHOSTS di ogni stazione di lavoro in modo da aggirare il problema del server WINS disattivato, ma questa eventualità riporta la problematica alla necessità di poter disporre di un certo supporto on-site.
Per questo motivo è una buona precauzione configurare WINS su almeno due server per ogni ambiente. Di seguito viene spiegato in che modo designare un server come server WINS primario.
In WINS Manager, fare clic sul menu Server e quindi su Replication Partners. Nella finestra Replication Partners, digitare il nome della macchina e l’indirizzo IP del server WINS secondario o di backup. Questa configurazione aggiunge il server di backup come partner di replica e permette a entrambi i server WINS di aggiornare i propri database WINS.
In ambienti con numerosi piccoli uffici connessi da lenti collegamenti geografici, mettere un server WINS in ogni località minimizza il traffico di risoluzione di nome attraverso la rete geografica. Ma come l’ambiente cresce e il traffico WINS aumenta, diventa indispensabile monitorare le richieste di risoluzione di nome attraverso la rete e pianificare il consolidamento di server WINS nei vari ambienti in modo da garantire un incremento nelle prestazioni dei servizi di risoluzione di nome.

Troppo per una buona soluzione
"Il mio ambiente possiede due server WINS per ogni gruppo di 10 client. Questa strategia WINS può essere considerata un approccio efficace?"
Siti con migliaia di nodi in più sedi collegate hanno spesso troppi server WINS. Un’effettiva pianificazione WINS significa ottimizzare la disponibilità dei server WINS rispetto ai client e non di massimizzare il numero di server WINS. Inoltre bisogna essere a conoscenza dell’entità della domanda di replica che sussiste fra ogni partner di replica WINS. Partendo da una media di tre modifiche al database ogni ora per ogni server WINS, il traffico di replica può arrivare a creare un quantità significativa di scambio di informazioni, anche fino a un 8% in una giornata lavorativa di otto ore.
Concretamente, gestire WINS in ambienti estesi implica i seguenti tre passaggi principali.
1. Determinare il numero effettivo di server necessari. Utilizzare più di due WINS server per ogni 100 o 200 nodi probabilmente porta a un sovraccarico del sistema. Questo è particolarmente vero quando tutte le workstation si connettono a una singola LAN. È indispensabile tenere a mente che numerosi fattori influenzano la capacità di un singolo server WINS. Comunque, se questi contatori indicano un’attività bassa, se non nulla, è opportuno considerare la possibilità di eliminare, o almeno spostare, questi server WINS poco utilizzati.
2. Determinare la collocazione geografica dei server. Avere più server WINS in un singolo segmento non determina un considerevole incremento delle capacità di risoluzione dei nomi. WINS invece eccelle nella sua abilità di distribuire meglio le richieste attraverso segmenti connessi da router, specialmente su reti geografiche. Per minimizzare la dipendenza da lenti collegamenti geografici per il traffico della risoluzione di nome, può essere utile collocare il server WINS in un punto geograficamente strategico. Per esempio, in una rete a più livelli i server potrebbero trovarsi in un segmento connesso attraverso un router per il Nordest. Collocare i server WINS nei segmenti Nordest migliora la risoluzione di nome e riduce la necessità di definire server WINS, per la risoluzione di nome, per altre regioni. Inoltre, per aumentare le prestazioni, può essere vantaggioso mettere i server WINS in segmenti ad elevato traffico di broadcast. Questa strategia facilita la risoluzione di nome in quella regione senza che il traffico WINS debba per forza attraversare un numero eccessivo di segmenti di rete.
3. Controllo degli intervalli di replica. Tre comandi gestiscono il traffico di replica WINS: Update Count, Replication Interval e Start Time. Con Update Count si determina il numero di record aggiornati riscontrabili in un database WINS prima che il server WINS notifichi ai suoi partner che deve essere effettuato un aggiornamento nei database replica. A seconda del numero di cambiamenti dei nomi nell’ambiente, l’incremento del parametro Update Control porta a una riduzione del numero delle notifiche di replica inviate dal server (a ogni modo, possono presentarsi fallimenti della risoluzione di nome perché i cambiamenti di nome WINS impiegano diverso tempo a raggiungere i server WINS partner).
Di seguito viene illustrato come incrementare il proprio Update Count: in WINS Manager, selezionare il menu Options/Preferences e quindi Partners. Quando viene visualizzata la finestra Preferences, fare clic su Update Count.
Invece di incrementare l’Update Count, è possibile semplicemente aumentare il Replication Interval. Infatti WINS predispone il Replication Interval standard ogni 30 minuti. Ciò significa che quando WINS notifica ai partner di replica che sono presenti record aggiornati, i partner possono prelevare i record di replica nel giro di 30 minuti. È necessario regolare questo valore in maniera coerente in tutti i partner WINS di replica e controllare il momento del giorno in cui avviene la replica.
Se si rende necessario incrementare il Replication Interval nel vostro ambiente, sincronizzare gli aggiornamenti in modo che avvengano durante ore non lavorative - specialmente se i server WINS sono collegati su reti geografiche. Per impostare il Replication Interval, fare clic su Replication Interval nella finestra Preferences e digitare un intervallo nel formato HH:MM:SS.
In ambienti estesi, gli amministratori spesso configurano i server WINS in una gerarchia a più livelli. Può rendersi necessario configurare i Replication Intervals in modo che i cambiamenti si diffondano ai partner server WINS in maniera appropriata. In altre parole, bisogna assicurarsi che WINS replichi i record aggiornati dal server A al server B e quindi dal server B al server C, ecc..

Gli ambienti misti
"La nostra rete consiste di server applicativi Windows NT con la maggior parte di client NetWare. Come è possibile impostare WINS?" Ambienti misti di rete sono la normalità al giorno d’oggi. Però la maggior parte di questi ambienti non necessitano obbligatoriamente di utilizzare WINS. Per esempio, si prenda il caso di un utente che abbia apportato un aggiornamento a 400 workstation con il passaggio da Windows 3.11/Netware 3.x a Windows 95. In questo ambiente l’azienda aveva utilizzato dei server Windows NT per le applicazioni su database SQL, ma erano i sistemi NetWare 3.x e 4.x i server principali per la gestione dei file e della stampa. Ad eccezione di una manciata di client, la maggior parte delle stazioni di lavoro operava su Windows 3.11 con un client Novell a 16 bit, in questo modo i server WINS non hanno apportato alcun beneficio all’azienda. Il client Novell utilizzava sia un protocollo IPX a 16 bit che un’insieme di protocolli TCP/IP e in questo modo la risoluzione di nome di NetBIOS non era né una componente né un requisito.
Anche altri ambienti utilizzano sistemi di trasporto dipendenti da NetBIOS. Questi ambienti comprendono IBM LAN Server o Pathworks di Digital Equipment. Le workstation client che sono in grado di riconoscere direttamente i server WINS possono comunque trarre vantaggio dalla risoluzione di nome dinamica offerta da WINS utilizzando i WINS proxy agent. Questi possono essere costituiti da qualsiasi stazione di lavoro client Windows NT o Windows 95 configurata in modo da poter accedere ad un determinato server WINS.
I proxy agent accettano broadcast da client non-Microsoft ed inoltrano le richieste al server WINS. Piuttosto che mantenere un database WINS, è possibile utilizzare un proxy agent che dia accesso, a client di tipo B-node, alla sua cache locale di nomi per un dato periodo. Se si vogliono utilizzare i proxy agent, i client devono attenersi al Request for Comments (RFC) 1001 e RFC 1002 e creare una risoluzione di tipo B-node (broadcast).
I proxy agent di WINS possono essere utili anche in organizzazioni di grandi dimensioni dove numerosi client Microsoft lavorano con TCP/IP ma non hanno accesso ad un server WINS. Questi agent utilizzano broadcast piuttosto che richieste di risoluzione dirette a un server WINS. Utilizzare un proxy agent nelle subnet può aiutare a ridurre la necessità di coinvolgere ulteriori server WINS.
Le mappature statiche sono un altro metodo per migliorare la risoluzione di nome in ambienti misti. Queste mappature sono costituite da voci permanenti per macchine specifiche nel database di WINS. Questa soluzione coinvolge host non-Microsoft nel database WINS, migliorando così le performance della risoluzione di nome.
Di seguito viene illustrato come aggiungere una mappatura statica: in WINS Manager, selezionare il menu Mapping e quindi fare clic su Mappings. Quando viene visualizzato il menu Static Mapping, digitare il nome e l’indirizzo IP del server in considerazione.
Le mappature statiche sono anche di aiuto in ambienti piccoli e misti; bisogna comunque ricordarsi di documentare la propria configurazione di rete. Questa documentazione può tornare utile in caso si debbano effettuare cambiamenti degli indirizzi IP.

Gli ambienti sicuri
"Io mantengo reti di prova che necessitano di un isolamento dalla rete di produzione. WINS potrebbe compromettere la sicurezza di questa organizzazione?"
In organizzazioni che richiedono elevati livelli di sicurezza su diverse rete locali, gli amministratori potrebbero non voler configurare i client per l’accesso a WINS. Quando sussiste la necessità di isolare le stazioni di lavoro, come per esempio nelle aule, ci si potrebbe trovare nella situazione di dover impedire agli utenti l’accesso a risorse della rete centrale. Allo stesso tempo invece le macchine degli istruttori potrebbero necessitare di un libero accesso a tutta la rete. In questa situazione, non definire i server WINS nei client dell’aula garantisce la protezione delle risorse.
Bisogna assicurarsi che non sia stata selezionata l’opzione di attivazione del DNS per la risoluzione di nome del NetBIOS. Questa opzione infatti permette ai client NetBIOS di risolvere host definiti nel server DNS e viene specificata nelle opzioni di configurazione della rete del client. L’istruttore invece può configurare un file LMHOSTS con i nomi dei server richiesti per la risoluzione NetBIOS.
Bisogna comunque ricordare che rinunciare a WINS rende solo più difficile l’accesso a risorse NT per operazioni che riguardano i file e la stampa. Si renderà infatti ancora necessario monitorare l’accesso attraverso servizi TCP/IP, quali FTP e HTTP. Utenti tecnicamente aggiornati possono utilizzare il comando NET SEND specificando l’indirizzo IP della risorsa a cui eventualmente connettersi semplicemente da un prompt di comando NT.

La fine di WINS?
WINS compie un grande lavoro nel minimizzare le complessità amministrative dell’attribuzione di nome NetBIOS e allo stesso tempo fornisce elevate prestazioni per i client NetBIOS. Questo è il motivo per cui Microsoft ha in origine progettato WINS. Ovviamente il valore di questi benefici cresce in rapporto all’entità e alla complessità dell’ambiente di rete.
Poiché la prossima versione di NT 5.0 sostituirà NetBIOS con l’aggiornamento della risoluzione di nome DNS, WINS fornirà supporto solo alle reti preesistenti dotate di NT 3.51 e 4.0. Senza i vincoli NetBIOS di WINS, gli amministratori non dovrebbero averne bisogno eccetto che per l’interoperare con reti basate su Windows NT 4.0.
Anziché progettare nuovi strumenti per ampliare le potenzialità di Windows NT, Microsoft si sta muovendosi verso soluzioni industriali standard per ciò che riguarda, servizi comuni come l’autenticazione del logon e la risoluzione di nome. Per questo motivo, Windows NT si ricaverà un ruolo sicuramente importante nelle reti aziendali e su Internet. Nel frattempo capire quando e come adottare WINS, non solo migliora l’affidabilità delle vostre reti Windows NT, ma assicura anche stabilità mentre vi preparate a una eventuale integrazione o all’aggiornamento alle prossime versioni di NT.

Quando non implementare WINS: 

  • Non utilizzare troppi server WINS in ambienti molto grandi. Le domande di replica fra ogni partner WINS possono creare una significativa quantità di comunicazioni di rete. Dovrebbero venire eliminati i server presenti in numero superiore ad uno ogni 200 client presenti. È consigliabile ridurre il numero di server WINS dove possibile.

  • Non utilizzare WINS in ambienti a elevata sicurezza se si vuole impedire agli utenti l accesso a risorse centrali della rete. Al contrario, utilizzare file LMHOSTS con i dovuti nomi di server per le risoluzioni NetBIOS.

Quando implementare WINS: 

  • Utilizzare WINS in ambienti TCP/IP di piccole dimensioni. Utilizzare WINS riduce la gestione dei nomi NetBIOS e WINS è in grado di lavorare meglio rispetto al DNS.

  • Utilizzare WINS in ambienti misti. I proxy agent di WINS possono ridurre il traffico broadcast per i client non configurati per utilizzare un server WINS.

  • Utilizzare WINS in ambienti distribuiti dal punto di vista geografico. Installare server WINS in ogni sede remota può minimizzare il traffico broadcast sulla rete geografica. Tenere sotto accurato controllo il traffico di replica e regolarlo con l’intervallo di replica e il tempo di inizio qualora si renda necessario.