回答:
これらの答えの多くは、部分的にしか真実ではないか、単に間違っています。WINSは、名前をIPアドレスに解決する別の方法です。アプリケーションがDNSの使用方法を知っている限り、WINSはまったく必要ありません。
編集：さて、このスレッドにどれだけの誤報があるか信じられません。まず第一に、異なるサブネットを持つことはWINSの使用を必要としません。アプリケーションがDNSサーバーのudp / tcpポート53と通信できる限り、ホスト名を問題なく解決できます（はい、\\ hostnameも機能します）。
第二に、短いホスト名（つまり、ドメインのないホスト名のみ）を使用して何も解決できないのか疑問に思っている場合は、おそらくクライアントでデフォルトのドメイン（またはドメイン検索リスト）を設定したことがないためです。
そして最後に（しかし、少なくとも！）、Active DirectoryドメインはWindowsネットワークでDNSを使用するための前提条件ではありません。あなたが考える唯一の理由は、マシンをドメインに参加させると、Windowsがデフォルトのドメイン名を設定するからです。他の手段（おそらくDHCP）を使用して自分で設定することを妨げるものはありません。
要約すると、デフォルトドメインを設定し、21世紀の私たちと同じようにDNSを使用するだけです。
たくさんのことを勝ち取るためにはまだ必要です（毎日少なくなってきています！）。私が見てきた最も一般的な例は、クラスター化された2003サーバーでExchange 2007を実行するための要件がwinsであることです。WinsはNetbios名で動作します。NetBIOS名は、コンピューターで実行されているNetBIOSサービスが使用する識別子です。これは、15文字（バイト）の名前と、サービスを示す16番目の文字の組み合わせです。NetBIOSネットワークリソースを識別する場合、これらの名前が使用されます。NetBIOSはインターネット上で名前解決を行うことはできません。NetBIOS名は単一のパーツ名であり、階層構造はありません。
NetBIOS名前空間はフラットです。つまり、NetBIOS名にサフィックスが追加されておらず、2台のコンピューターが同じNetBIOS名を持つことはできません。つまり、1つのネットワーク内の各NetBIOS名は一意でなければなりません。
Microsoft WindowsのTCP / IPの基礎、第11章-NetBIOS over TCP / IPを参照してください。
当社のエンタープライズでは、多くのレガシーアプリケーションに必要です。
最も賛成の答えは完全に間違っているので、私はこれを編集する必要があると感じました！
WINSは、最近の多くの組織で間違いなく必要です。
WINSの仕組み更新：2005年1月21日
WINSの仕組みデフォルトでは、Microsoft®Windows®2000、Windows XP、またはWindows Server 2003オペレーティングシステムを実行しているコンピューターが、名前解決のために（手動またはDHCPを介して）WINSサーバーアドレスで構成されている場合、ハイブリッドノード（h -node）別のNetBIOSノードタイプが構成されていない限り、NetBIOS名登録のノードタイプとして。NetBIOS名のクエリと解決では、hノードの動作も使用しますが、いくつかの違いがあります。
NetBIOS名前解決の場合、WINSクライアントは通常、次の一般的な一連の手順を実行して名前を解決します。
クライアントは、照会された名前が、所有しているローカルNetBIOSコンピューター名であるかどうかを確認します。
クライアントは、リモート名のローカルNetBIOS名キャッシュをチェックします。リモートクライアント用に解決された名前はすべてこのキャッシュに配置され、10分間保持されます。
クライアントは、構成されたプライマリWINSサーバーにNetBIOSクエリを転送します。プライマリWINSサーバーが使用できないか、名前のエントリがないためにクエリに応答できない場合、クライアントは、リストされ、構成されている順に他の構成されたWINSサーバーに接続しようとしますその使用。
クライアントは、NetBIOSクエリをローカルサブネットにブロードキャストします。
クライアントは、Lmhostsファイルを使用するように構成されている場合、クエリに一致するかどうかLmhostsファイルを確認します。
クライアントは、Hostsファイルを試行し、DNSサーバーが構成されている場合はDNSサーバーを試行します。
問題は、すべてのアプリケーションがDNSを使用するように構成できるわけではないことです。
Microsoft自身がActive Directoryのセットアップについて説明していても、WINSの必要性に言及しています。
「以前のバージョンのWindowsがActive Directoryドメインのネットワークリソースを解決するには、NetBIOS名前解決（WINSサーバー、LMHostsファイル、またはNetBIOSブロードキャスト）が引き続き必要です。」
そうです、WINSを使用せずに逃げることができる組織もありますが、DNSサーバーにアクセスできれば魔法のようにWINSを必要としないという包括的な声明を出すのは間違っています。
WINSは、世界中のすべてのWindows管理者がそれを殺そうとするあらゆる試みにもかかわらず、依然として非常に要件です。サブネットが分離されている場合はいつでも、WINSが必要になります。個別のサイトでVPNを実行していますか？これは、サブネットとWINSを意味します。ADを理解していない古いクライアントがいますか？WINSが必要です。ネットワーキングしているDOSアプリケーションをお持ちですか？再びWINS。
WINSは、ブラウズリストの設定にも使用されます。Active DirectoryベースのマシンはWINSなしでも機能しますが、次の順序で参照リストが作成されるため、遅延が発生する可能性があります。
問題の核心は、LANMANのルーツにあります。これはSMBを生み、CIFSを生みます...これがどこに起こっているかを見ることができます。LANMANはLANベースのプロトコルであり、「インターネット」という概念はなく、「ルーティング」という概念はほとんどありませんでした。WINSは、そのギャップを埋め、ルーティングを可能にするために開発されました。現在に至るまで、CIFSにはまだLANMANに対する下位互換性のサポートがいくつかあります。UNCパス名は「近代的」かもしれませんが、それでもLANMANサーバーに接続されます。次に、「参照リスト」全体があります...
MSはWINSサーバービジネスから抜け出すのに非常に近づいていますが、OSだけでなく、アプリケーションやサービスにもWINSサーバーを必要とする「レガシー」フックが多すぎます。また、LANMANスタイルの送信がサポートされている限り、WINSサーバーを使用する必要があります。
編集：
はい、フラットドメインでWINSをオフにできます。
しかしながら...
このサービスが心を動かされるようにしたいのと同じくらい、Microsoftが来てLANサービスのやり方を刷新するまで、それは消え去りません。 （はい、そのリンクにはそれがどのように必要でないかについてのコメントがあります...しかし、馬の口で言われていることを読んでください...）
これらの答えの多くは間違っているか、部分的に正しいです。最初に、WINSが最初に使用される理由を理解しましょう。
WINSは、ホスト名をIPアドレスに解決するためのソリューションとして使用されます... 読む！
同じ目的などで使用されるDNS。完全修飾ドメイン名とホスト名をIPアドレスに解決します。
次に、WINSが開発された理由を見てみましょう。
問題：NetBIOSはもともと名前を解決するために使用されていましたが、ブロードキャストネットワークプロトコルです。そのため、ほとんどのネットワークでは、昔から現在まで、ブロードキャストトラフィックはルーターを通過できず、すぐに十分なファイアウォールを通過しますが、後でVPNトラフィックでも発見します。そのため、ほとんどのサブネットはNetBIOSトラフィックを他のサブネットに複製しません。実際のITネットワーク管理者であれば、ルーター、スイッチ、およびファイアウォール上の次のNetBIOSトラフィックに精通しています。
HOST-17 / 137からinside：10.0.1.127/137へのACLによってUDPアクセスが拒否されました
HOST-A / 137からinside：10.0.1.127/137へのACLによってUDPアクセスが拒否されました
HOST-09 / 137からinside：10.0.1.127/137へのACLによってUDPアクセスが拒否されました
HOST-02 / 137からinside：10.0.1.127/137へのACLによってUDPアクセスが拒否されました
HOST-02 / 137からinside：10.0.1.127/137へのACLによってUDPアクセスが拒否されました
これは、Cisco Pix 515E Firewall syslogファイルからの25ビットネットワークでの5つのNetBIOSブロードキャストの例です。linksysルーターが25ビットネットワークであるということ以外になにも慣れていない場合は、24ビットネットワークよりも小さくなります。
ネットワーク：10.0.1.0/25、サブネットマスク：255.255.255.128、ブロードキャストアドレス：10.0.1.127、最大ホスト：126.ご覧のように、トラフィックはセグメント内に含まれています。
解決策：WINSは、ブロードキャストトラフィックが含まれるサブネットに展開するように開発されています。クライアントは、ブロードキャストトラフィックに依存する代わりにWINSサーバーを構成してポイントし、名前を解決することができます。
ただし、Microsoftネットワークを展開するときにDNSサーバーを構成します。DNSがプライマリになり、DNSに障害が発生すると、NetBIOSがフォールバックになります。WINSサーバーが展開されている場合、DNS、WINS、およびNetBIOS。
多くの人が遭遇するかもしれない問題は、ホスト名をpingしようとするときです。主にDNSを構成しただけで、ホストに登録されているNetBIOS名の有効期限が切れている場合、コンピューターのインターフェイス構成によっては、アドレスをIPに解決できない場合があります。
HOST-Aがdomainhosts.comの一部であり、そのドメイン（domainhosts.comのプライマリDC DNSサーバー上のホストの（A）レコード）に参加したとしましょう。FQDN（完全修飾ドメイン名）ではなくホスト名のみでアドレスを解決するには、IP構成に「プライマリおよび接続固有のDNSサフィックスを追加」し、「この接続のDNSサフィックス：domainhosts.com」を最小限にする必要があります。人口！HOST-Aの解決が実行されると、2つの追加情報が返されます。ホスト名が解決されるIPアドレスと、HOST-A.domainhosts.comのFQDN。以下の例では、ホスト名の解決は、WINSまたはNetBIOSの代わりにドメインの（A）レコードを検索することにより実行されます。
[User @ localhost〜] $ ping HOST-A
PING HOST-A.domainhosts.com（10.0.1.10）56（84）バイトのデータ。
HOST-A.domainhosts.com（10.0.1.10）からの64バイト：icmp_seq = 1 ttl = 128 time = 0.826 ms
HOST-A.domainhosts.com（10.0.1.10）からの64バイト：icmp_seq = 2 ttl = 128 time = 0.342 ms
プライマリDNSサフィックスのみを入力することに加えて、ホストに他のホストを検索させ、異なる順序で追加するようにホストを構成することができます。したがって、WINSとNetBIOSを一緒に削除します。
「Microsoft製品を動作させるにはNetBIOSとWINSが必要です」と言う人がいます。これは実際には当てはまりますが、ほとんどの製品は中小企業や大企業環境にのみ展開されず、1Aレコードを使用するSMS 2003などのアプリケーション、SQL Server 2000名前付きパイプの使用、およびExchange Server 2000および2003はすべて、完全な機能のためにWINSを必要とします。
そうそう、そしてあなたが2000年以前のマイクロソフトを展開している場合のみ。しかし、WINSを展開するよりも優れたソリューションが得られました...アップグレード!!
「一部のレガシーサーバー」で必要になる可能性があるため、私はそれがまだ維持されている環境にいました。
同じ状況にあるお店はおそらくたくさんあると思います。
誰も言及していないことの1つは、NetBIOS名を解決したい場合、別々のサブネット上のVPNサイトが必要であることです。このシナリオを考慮してください：
企業ネットワークはプライベート10.xxx LANを使用し、リモートオフィスはプライベート192.xxx LANを使用します。それらの間にはVPNトンネルがありますが、リモートオフィスは企業のDHCPサーバーまたはファイアウォールからトンネルを介してDHCPを取得しません。
企業サーバーをWINSに登録している場合、リモートクライアントは完全に別のサブネットからでも\ ServerNameを解決できます。最終的には、リモートオフィスのファイアウォールをアップグレードし、VPN経由でDHCPを使用できるようになりますが、現時点では、このセットアップにより次のことが可能になります。
これについて間違っている場合は誰かが私を修正してください。しかし、NetBIOSはルーティングできないため、WINSを使用せずにサブネット全体でNetBIOS名を解決することはできません。
ああ、まだ使っています。所有しているWindowsワークステーションの約3分の1はドメイン内にないため、ドメインのDNSドメインを名前解決に使用するように構成されていません。また、途方もなく断片化されたDNSランドスケープがあり、それが途方もなく断片化されたデフォルトドメイン設定につながります。このため、WINSは最も多くのものを含む単一の名前解決サービスを表します。サービスのグローバルインデックスに最も近いものです。
すべてをドメイン化するためにプッシュする場合、フラットなDNSランドスケープがあります。それは良いだろう。
従来のExchangeは引き続きWINSを使用するため、機能レベルを2008または2012に上げてWINSを使用する場合は、Exchange 2003以前を使用している場合（うまくいけない場合）、WINSを有効にする必要があります。
また、マルチドメイン環境でFQDNを使用しないアプリまたはスクリプトには問題が発生する可能性があります。
WINSは削除できますが、綿密にテストする必要があり、多くのアプリ、SAP、Exchange、およびその他のレガシーアプリを実行している大企業では、ドメインの2012ネイティブに到達するまで価値がありません。 WINS。
私は、WINSを使用せず、WINSを4年間使用していません。Microsoft DDNSは、Active Directoryネットワークでの名前解決の素晴らしい仕事をします。現在WINSを必要とするプログラムは考えられませんが、いくつか覚えています。Guardian Firewallは、当時LAN側のNICで必要でした。
2007 ExchangeクラスタにはWINSは必要ありません。私が持っているドキュメントによると、IPは変更されないので、MSはそのセットアップでHOSTファイルを使用することをお勧めします。
DDNSでの私の唯一の問題は、WAN全体です。各WANセグメントのDDNS + ADC ...頻繁に他のネームテーブルの更新でDDNSに問題があります。
WINSは、リモートサイトまたはWANリンクがないクラスCネットワークに適しています。WINSに対する1つの大きなこと... SSL VPN + WINS = IPの入力WINSはgoona werkではありません。