Jak intensywne jest obecnie korzystanie z usługi nazw Microsoft WINS?

Wydaje mi się, że pamiętam, jak przez lata próbowałem zatrzymać wymóg posiadania usługi nazw WINS jako części środowiska Windows.

Moje pytanie brzmi, czy strony nadal korzystają z WINS, czy przeszły na coś innego i nie potrzebują już WINS. Jeśli tak, ktoś chce się podzielić swoimi doświadczeniami?

Dzięki.

Wiele z tych odpowiedzi jest tylko częściowo prawdziwe lub po prostu błędne. WINS to kolejny sposób na przekształcenie nazw na adresy IP. Tak długo, jak aplikacje wiedzą, jak korzystać z DNS, WINS nie jest wcale potrzebny.

Edycja: Dobra, nie mogę uwierzyć, ile dezinformacji jest w tym wątku. Po pierwsze, posiadanie różnych podsieci nie wymaga użycia WINS. Tak długo, jak twoja aplikacja może komunikować się z portem udp / tcp 53 na twoich serwerach DNS, będziesz w stanie dobrze rozwiązać nazwy hostów (tak, \\ nazwa hosta też będzie działać).

Po drugie, jeśli zastanawiasz się, dlaczego nie możesz rozwiązać niczego przy użyciu krótkiej nazwy hosta (tj. Po prostu nazwy hosta bez domeny), to prawdopodobnie dlatego, że nigdy nie skonfigurowałeś domyślnej domeny (lub listy wyszukiwania domen) na swoich klientach.

I wreszcie (ale nie tylko!) Domena Active Directory nie jest warunkiem korzystania z DNS w sieci Windows. Jedynym powodem, dla którego tak myślisz, jest to, że po dołączeniu komputera do domeny system Windows ustawia dla ciebie domyślną nazwę domeny. Nic nie stoi na przeszkodzie, abyś sam to ustawił za pomocą innych środków (prawdopodobnie DHCP).

Podsumowując, po prostu ustaw domyślną domenę i używaj DNS jak reszta z nas tutaj w XXI wieku!

Wygrane są nadal wymagane dla wielu rzeczy (coraz mniej każdego dnia!). Najczęstszym przykładem, jaki widziałem, jest to, że wygrane są wymagane do uruchomienia Exchange 2007 na serwerach klastrowych 2003. Wygrane współpracują z nazwami Netbios. Nazwa NetBIOS to identyfikator używany przez usługi NetBIOS działające na komputerze. Jest to kombinacja 15-bajtowej nazwy i 16-tego znaku oznaczającego usługę. Podczas identyfikacji zasobów sieciowych NetBIOS używa się tych nazw. NetBIOS nie może rozpoznawać nazw w Internecie. Nazwy NetBIOS są nazwami pojedynczych części i nie mają żadnej hierarchicznej struktury.

Przestrzeń nazw NetBIOS jest płaska, co oznacza, że ​​do nazwy NetBIOS nie dodano przyrostków i że dwa komputery nie mogą mieć tej samej nazwy NetBIOS. Oznacza to, że każda nazwa NetBIOS w dowolnej sieci musi być unikalna.

Patrz Podstawy protokołu TCP / IP w systemie Microsoft Windows, Rozdział 11 - NetBIOS przez TCP / IP

W naszym Enterprise jest nadal wymagany w przypadku wielu starszych aplikacji.

Czułem, że muszę to edytować, ponieważ najbardziej pozytywna odpowiedź jest całkowicie NIEPRAWIDŁOWA!

WINS jest obecnie zdecydowanie wymagany w wielu organizacjach.

Jak działa WINS Zaktualizowano: 21 stycznia 2005 r

Jak działa WINS Domyślnie, gdy komputer z systemem Microsoft® Windows® 2000, Windows XP lub Windows Server 2003 jest skonfigurowany z adresami serwera WINS (ręcznie lub przez DHCP) do rozpoznawania nazw, używa węzła hybrydowego (h -node) jako typ węzła dla rejestracji nazwy NetBIOS, chyba że skonfigurowano inny typ węzła NetBIOS. W przypadku zapytań o nazwy NetBIOS i ich rozwiązywania wykorzystuje również zachowanie węzła h, ale z kilkoma różnicami.

W celu rozpoznawania nazw NetBIOS klient WINS zazwyczaj wykonuje następującą ogólną sekwencję kroków w celu rozwiązania nazwy:

Klient sprawdza, czy pytana nazwa jest nazwą lokalnego komputera NetBIOS, którego jest właścicielem.

Klient sprawdza lokalną pamięć podręczną nazw NetBIOS zdalnych nazw. Każda nazwa rozwiązana dla klienta zdalnego jest umieszczana w tej pamięci podręcznej, gdzie pozostaje przez 10 minut.

Klient przesyła zapytanie NetBIOS do skonfigurowanego podstawowego serwera WINS. Jeśli podstawowy serwer WINS nie odpowie na zapytanie - albo dlatego, że nie jest dostępny, albo dlatego, że nie ma wpisu nazwy - klient spróbuje skontaktować się z innymi skonfigurowanymi serwerami WINS w kolejności, w jakiej są wymienione i skonfigurowane dla jego użycie.

Klient rozgłasza zapytanie NetBIOS do lokalnej podsieci.

Klient sprawdza, czy plik Lmhosts jest zgodny z zapytaniem, jeśli jest skonfigurowany do używania pliku Lmhosts.

Klient próbuje pliku Hosts, a następnie serwera DNS, jeśli jest on skonfigurowany do takiego.

Problem polega na tym, że nie każda aplikacja może być skonfigurowana do korzystania z DNS.

Nawet we własnej eksploracji konfiguracji Active Directory Microsofts wspomina o potrzebie WINS.

Skonfiguruj DNS

„Rozpoznawanie nazw NetBIOS (serwer WINS, plik LMHosts lub transmisja NetBIOS) jest nadal wymagane we wcześniejszych wersjach systemu Windows do rozpoznawania zasobów sieciowych w domenie Active Directory.”

Tak więc, istnieją NIEKTÓRE organizacje, które mogą uciec bez korzystania z WINS, ale aby złożyć ogólne oświadczenie, że jeśli możesz trafić na serwer DNS, magicznie nie potrzebujesz WINS, to źle.

WINS jest nadal bardzo wymagający, pomimo każdej próby każdego administratora systemu Windows na świecie, aby obalić go na śmierć. Za każdym razem, gdy nastąpi rozdzielenie podsieci, będziesz potrzebować WINS. Prowadzisz VPN dla oddzielnych witryn? Oznacza to podsieć - i WINS. Masz starszych klientów, którzy nie rozumieją AD? Potrzebujesz WINS. Masz aplikację DOS, z którą korzystasz w sieci? WYGRYWA ponownie.

WINS służy również do zapełniania list przeglądania. Chociaż komputery oparte na usłudze Active Directory mogą działać bez WINS, może wystąpić opóźnienie, ponieważ listy przeglądania są zapełniane w następującej kolejności:

1. Pamięć podręczna nazw NetBIOS
2. WINS
3. Nadawanie
4. LMHOSTY
5. ZASTĘPY NIEBIESKIE
6. DNS

Sedno problemu wynika z korzeni LANMAN, który zrodził SMB, który zrodził CIFS ... widać, dokąd to zmierza. LANMAN był w dużej mierze protokołem opartym na sieci LAN - nie miał pojęcia „Internet”, a tym bardziej „routingu”. WINS został opracowany w celu wypełnienia tej luki i umożliwienia routingu. Szybko do przodu do chwili obecnej, a CIFS nadal ma w sobie pewne kompatybilne wstecz oprogramowanie LANMAN. Nazwy ścieżek UNC mogą być „nowoczesne”, ale nadal będą dołączane do serwera LANMAN. Potem jest cała ta „lista przeglądania” ...

MS jest bardzo blisko wydostania się z serwera WINS, ale istnieje zbyt wiele „starszych” haków, nie tylko w systemie operacyjnym, ale także w aplikacjach i usługach, które wymagają serwera WINS. I dopóki istnieje obsługa transmisji w stylu LANMAN , konieczne będzie posiadanie serwera WINS.

EDYTOWAĆ:

Tak, możesz wyłączyć WINS w płaskiej domenie.

Jednak...

• Wypróbuj to w domenie, która ma domeny abc.xyz.com i abc.123.com jako domeny podrzędne. Czy możesz trzy razy szybko powiedzieć „przeglądaj zabawną listę”?
• W niektórych przypadkach wypróbuj to z Exchange 2007.
• Spróbuj tego, gdy masz serwery, które istnieją poza podsiecią i przekraczają zaporę. Jakoś wydaje się, że są kłopoty z tymi listami przeglądania ...

Tak bardzo, jak chcę, aby ta usługa była oparta na sercu, nie zniknie, dopóki Microsoft nie obejdzie się i nie zmieni sposobu, w jaki wykonują usługi LAN. (Tak, pod tym linkiem znajduje się komentarz na temat tego, jak również nie jest potrzebny ... ale przeczytaj, co mówi pysk konia ...)

Nie mylmy się między wygranymi a netbios ..... możesz uruchamiać netbios w sieci bez serwera WINS, ale nie jest to zalecane w domenie. Naprawdę nie chcesz, aby wszystkie te funky wybory odbywały się, gdy masz odpowiedni serwer DNS w sieci, więc Netbios powinien być wyłączony lub należy użyć serwera WINS. (Używam właściwego w naj luźniejszym znaczeniu tego słowa, jeśli chodzi o MS DNS :-))

Ostatnio miałem problem z Exchange 2007 na Windows 2008, wymagający włączenia netbios. nie do wiary!!!

Wiele z tych odpowiedzi jest niepoprawnych lub częściowo poprawnych. Najpierw dowiedzmy się, dlaczego WINS może być użyty w pierwszej kolejności.

WINS jest używany jako rozwiązanie do tłumaczenia nazw hostów na adresy IP ... ale dlaczego mielibyśmy potrzebować WINS, jeśli NetBIOS działa we wszystkich serwerach? Czytaj!

DNS używany do tego samego celu i wiele więcej ... do tłumaczenia w pełni kwalifikowanych nazw domen ORAZ nazw hostów na adresy IP.

Teraz spójrzmy, dlaczego WINS został opracowany.

Problem: NetBIOS był pierwotnie używany do rozpoznawania nazw, ale jest to rozgłaszany protokół sieciowy. Tak więc w większości sieci, zarówno starszych, jak i obecnych, ruch rozgłoszeniowy nie jest w stanie przechodzić przez routery, a wkrótce zapory ogniowe, później znajdziemy to również w ruchu VPN. Dlatego większość podsieci nie replikuje ruchu NetBIOS do innych podsieci. Jeśli jesteś prawdziwym administratorem sieci IT, zapoznasz się z ruchem NetBIOS na routerach, przełącznikach i zaporach ogniowych:

Odmowa dostępu UDP przez ACL z HOST-17/137 do wewnątrz: 10.0.1.127/137

Odmowa dostępu UDP przez ACL z HOST-A / 137 do wewnątrz: 10.0.1.127/137

Odmowa dostępu UDP przez ACL z HOST-09/137 do wewnątrz: 10.0.1.127/137

Odmowa dostępu UDP przez ACL z HOST-02/137 do wewnątrz: 10.0.1.127/137

Odmowa dostępu UDP przez ACL z HOST-02/137 do wewnątrz: 10.0.1.127/137

Jest to przykład pięciu (5) emisji NetBIOS w sieci 25-bitowej z pliku syslog zapory Cisco Pix 515E. Dla tych, którzy nie są zaznajomieni z niczym innym niż to, czym ich router Linksys jest 25-bitowa sieć jest mniejsza niż twoja 24-bitowa sieć:

Sieć: 10.0.1.0/25, maska ​​podsieci: 255.255.255.128, adres rozgłoszeniowy: 10.0.1.127, maksymalna liczba hostów: 126. Jak widać, ruch jest zawarty w segmencie.

Rozwiązanie: WINS został opracowany do wdrażania w podsieci, w której występuje ruch rozgłoszeniowy, klienci mogą skonfigurować i wskazać serwer WINS, aby rozpoznawać nazwy zamiast polegać na ruchu rozgłoszeniowym, dlatego NetBios staje się teraz awaryjny, gdy zapytania WINS nie powiodą się.

Ale poczekaj ... konfigurujemy serwery DNS teraz, gdy wdrażamy nasze sieci Microsoft. Teraz DNS jest główny, gdy DNS zawiedzie, NetBIOS jest rezerwą. Jeśli wdrożony jest serwer WINS, DNS, WINS i NetBIOS.

Problemem, z którym wielu może się spotkać, jest próba wysłania polecenia ping do nazwy hosta, powiedzmy HOST-A. W zależności od konfiguracji interfejsu komputera rozpoznanie adresu IP może nie być możliwe, zwłaszcza jeśli skonfigurowano właśnie DNS, a nazwy NetBIOS zarejestrowane przez hostów wygasły.

Powiedzmy, że HOST-A jest częścią domainhosts.com i został przyłączony do tej domeny, rekordu (A) hosta na podstawowym serwerze DC DNS dla domainhosts.com. Aby rozwiązać adres tylko nazwą hosta, a nie jego FQDN (w pełni kwalifikowana nazwa domeny), konfiguracja IP musi mieć „Dołącz sufiksy DNS podstawowe i specyficzne dla połączenia” oraz mieć co najmniej „Sufiks DNS dla tego połączenia: domainhosts.com” zaludniony! Podczas rozwiązywania HOST-A zwracane są dwa (2) dodatkowe informacje: Adres IP, na który tłumaczona jest nazwa hosta, i jego nazwa FQDN HOST-A.domainhosts.com. W poniższym przykładzie rozpoznawanie nazwy hosta odbywa się poprzez przeszukiwanie rekordów (A) domeny zamiast WINS lub NetBIOS:

[Użytkownik @ localhost ~] $ ping HOST-A

PING HOST-A.domainhosts.com (10.0.1.10) 56 (84) bajtów danych.

64 bajty z HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 1 ttl = 128 czas = 0,826 ms

64 bajty z HOST-A.domainhosts.com (10.0.1.10): icmp_seq = 2 ttl = 128 czas = 0,322 ms

Oprócz wypełnienia tylko podstawowego sufiksu DNS, możesz również poprosić hostów o przeszukiwanie innych i skonfigurowanie ich do dołączania w różnych zamówieniach. W ten sposób całkowicie eliminuje WINS i NetBIOS.

Teraz będą tacy, którzy powiedzą „Będziesz potrzebował NetBIOS i WINS, aby produkty Microsoft działały”. Tak jest w rzeczywistości, ale tylko w przypadku kilku produktów, z których większość nie zostanie wdrożona w małych i średnich firmach i tylko w dużych środowiskach korporacyjnych, aplikacje takie jak SMS 2003 z wykorzystaniem rekordu 1A, SQL Server 2000 dla użycie nazwanych potoków, a Exchange Server 2000 i 2003 wymagają WINS dla pełnej funkcjonalności ... PEŁNA Funkcjonalność, WSZYSTKIE będą działać w razie potrzeby bez WINS lub NetBIOS.

O tak, i tylko w przypadku wdrożeń Microsoft przed 2000 rokiem. Mam dla ciebie lepsze rozwiązanie niż wdrażanie WINS ... AKTUALIZACJA !!

Byłem w środowiskach, w których jest nadal utrzymywany, ponieważ „niektóre starsze serwery” mogą go potrzebować.

Myślę, że prawdopodobnie istnieje wiele sklepów w podobnej sytuacji.

Kiedyś włączyłem WINS na serwerze samby w pracy. Było to najszybsze i najtańsze (pod względem spędzonego czasu) rozwiązanie do rozpoznawania nazw w sieci Windows bez domeny. To proste i działa dobrze w małej sieci.

Wiele urządzeń osadzonych również korzysta z WINS. Mamy wielofunkcyjne urządzenia kopiujące i niedawno zakupiony bezprzewodowy system projekcji, który nie działałby, dopóki nie podałem mu adresu IP serwera WINS.

O ile chcielibyśmy, WINS będzie tu długo.

Kilka miesięcy temu zatrzymałem usługę WINS w naszej sieci LAN. Po kilku tygodniach całkowicie go usunąłem. Zastanawiam się, ile lat upływa bez konkretnego powodu? W niektórych środowiskach jestem pewien, że będzie to niemożliwe. Możliwe, że od tego czasu mieliśmy problemy, które byłyby niewidoczne przy wciąż działającym WINS. Chyba jestem purystą, ale WINS przypomina mi grę w bilard. Strzał nie powinien się liczyć, chyba że celujesz w tę kieszeń!

Jedną rzeczą, o której nikt nie wspominał, jest to, że strony VPN w oddzielnych podsieciach są konieczne, jeśli chcesz rozpoznać nazwy NetBIOS. Rozważ ten scenariusz:

Sieć korporacyjna korzysta z prywatnej sieci LAN 10.xxx, a zdalne biuro korzysta z prywatnej sieci LAN 192.xxx. Mają między sobą tunel VPN, ale zdalne biuro nie przenosi DHCP przez tunel z korporacyjnego serwera DHCP lub zapory.

Jeśli masz zarejestrowane serwery korporacyjne w usłudze WINS, klienci zdalni mogą rozpoznać \ nazwa_serwera nawet z całkowicie oddzielnej podsieci. W końcu będę mógł zaktualizować zaporę zdalnego biura i korzystać z DHCP przez VPN, ale na razie ta konfiguracja pozwala mi:

• Nie musisz pamiętać adresów IP serwera podczas pracy na zdalnych komputerach.
• Użyj tych samych skryptów logowania, które mapują dyski sieciowe na podstawie nazw NetBIOS, a nie adresów IP.
• Zachowaj ogólną spójność.

Ktoś, proszę, popraw mnie, jeśli się mylę, ale rozumiem, że NetBIOS nie jest routowalny, więc nie mogę rozpoznać nazw NetBIOS w podsieci bez użycia WINS.

Och, nadal go używamy. Około jednej trzeciej stacji roboczych Windows, których mamy, nie ma w domenie, a zatem nie są skonfigurowani do używania domen DNS domeny do rozpoznawania nazw. Ponadto mamy monstrualnie rozdrobniony krajobraz DNS, który prowadzi do monstrualnie rozdrobnionych ustawień domeny domyślnej. Z tego powodu WINS reprezentuje pojedynczą usługę rozpoznawania nazw, która zawiera najwięcej elementów. Jest to najbliższy nam globalny indeks usług.

Jeśli / Kiedy będziemy naciskać, aby uzyskać wszystko w domenie, będziemy mieć płaski krajobraz DNS. To będzie dobre.

Starsza wersja Exchange nadal korzysta z WINS, więc każdy, kto chce podnieść poziomy funkcjonalności do 2008 lub 2012 roku i nadal korzysta z WINS, jeśli używasz Exchange 2003 lub wcześniejszej wersji (mam nadzieję, że nie), nadal będziesz musiał włączyć WINS.

Ponadto wszelkie aplikacje lub skrypty, które nie używają nazwy FQDN w środowisku z wieloma domenami, prawdopodobnie będą mieć problemy.

WINS można usunąć, ale należy go metodycznie przetestować w dużych korporacjach z wieloma aplikacjami, SAP, Exchange i innymi starszymi aplikacjami, które go uruchamiają, prawie nie jest to warte, dopóki nie dostaniesz się do 2012 roku w swojej domenie, co pomoże w dekompozycji WINS.

Ja po pierwsze, nie używam WINS i nie korzystałem z WINS od 4 lat. Microsoft DDNS doskonale radzi sobie z rozpoznawaniem nazw w sieci Active Directory. Nie mogę teraz wymyślić programu, który wymaga WINS, ale pamiętam kilka. Guardian Firewall wymagał tego po stronie sieci LAN w ciągu dnia.

Klastry Exchange 2007 nie wymagają WINS. Zgodnie z dokumentacją, którą posiadam, MS zaleca używanie plików HOST, wierzcie lub nie, w tej konfiguracji, ponieważ adresy IP się nie zmieniają.

Mój jedyny problem z DDNS dotyczy sieci WAN. DDNS + ADC na każdym segmencie sieci WAN ... często mam problemy z aktualizowaniem przez DDNS tabel nazw.

WINS jest odpowiedni dla sieci klasy C, w której nie ma zdalnych stron ani łączy WAN. Jedna wielka rzecz przeciwko WINS ... SSL VPN + WINS = wpisywanie adresu IP, ponieważ WINS nie jest dobrym pomysłem.

Nasze środowisko nie używa WINS od wielu miesięcy i nie widział z tego powodu żadnych negatywnych skutków. Mamy topologię wielu witryn za pośrednictwem połączeń VPN, a Exchange 2003 jest naszą usługą e-mail.

WINS powinien być włączony tylko wtedy, gdy jest to szczególnie wymagane do rozwiązania znanego problemu. Trzymanie się przestarzałej technologii „na wszelki wypadek” nie ma sensu, gdy masz pewność, że nie jest to wymagane.