最近のMicrosoft WINS nameserviceの使用はどのくらい広範ですか？
私は何年にもわたって、Windows環境の一部としてWINS nameserviceを持つという要件を止めようとする動きを思い出しているようです。
私の質問は、サイトがまだWINSを利用しているのか、それとも他のものに切り替えてWINSを必要としなくなったのかということです。もしそうなら、誰かが彼らの経験を共有したいですか？
ありがとう。
これらの答えの多くは、部分的に正しいか、まったく間違っています。 WINSは、名前をIPアドレスに解決するもう1つの方法です。アプリケーションがDNSの使用方法を知っている限り、WINSはまったく必要ありません。
編集：さて、私はこのスレッドにどれほどの誤った情報があるのか信じられません。まず第一に、異なるサブネットを持つことはWINSの使用を必要としません。アプリケーションがDNSサーバーのudp/tcpポート53と通信できる限り、ホスト名を問題なく解決できます（はい、\\ hostnameも機能します）。
次に、短いホスト名（つまり、ドメインのないホスト名のみ）を使用して何も解決できない理由がわからない場合は、クライアントでデフォルトのドメイン（またはドメイン検索リスト）を構成したことがないことが原因である可能性があります。
そして最後に（大事なことを言い忘れましたが！）、ActiveDirectoryドメインはWindowsネットワークでDNSを使用するための前提条件ではありません。あなたがそれを考える唯一の理由は、あなたがマシンをドメインに参加させるとき、Windowsがあなたのためにデフォルトのドメイン名を設定するからです。他の手段（おそらくDHCP）を使用して自分で設定することを妨げるものは何もありません。
要約すると、デフォルトのドメインを設定し、21世紀の他の人々と同じようにDNSを使用してください。
私たちのエンタープライズでは、それはまだ多くのレガシーアプリケーションに必要です。
最も賛成の答えは間違っているので、私はこれを編集する必要があると感じました！
WINSは、最近の多くの組織で間違いなく必要とされています。
WINSの仕組み更新日：2005年1月21日
方法WINSの動作デフォルトでは、Microsoft®Windows®2000、Windows XP、またはWindows Server2003オペレーティングシステムを実行しているコンピューターがWINSサーバーアドレスで構成されている場合） （手動またはDHCPを介して）名前解決に、別のNetBIOSノードタイプが構成されていない限り、NetBIOS名登録のノードタイプとしてハイブリッドノード（hノード）を使用します。NetBIOS名のクエリと解決には、hノードも使用します。動作しますが、いくつかの違いがあります。
NetBIOS名前解決の場合、WINSクライアントは通常、名前を解決するために次の一般的な一連の手順を実行します。
クライアントは、照会された名前が、所有しているローカルNetBIOSコンピューター名であるかどうかを確認します。
クライアントは、リモート名のローカルNetBIOS名キャッシュをチェックします。リモートクライアント用に解決された名前はすべてこのキャッシュに配置され、10分間保持されます。
クライアントは、NetBIOSクエリを構成済みのプライマリWINSサーバーに転送します。プライマリWINSサーバーが、使用できないか、クエリに応答できない場合、名前のエントリはありません。クライアントは、他の構成済みWINSサーバーに、リストされて使用するように構成されている順序で接続しようとします。
クライアントは、NetBIOSクエリをローカルサブネットにブロードキャストします。
クライアントは、Lmhostsファイルを使用するように構成されている場合、クエリと一致するかどうかLmhostsファイルをチェックします。
クライアントは、Hostsファイルを試し、次にDNSサーバー（DNSサーバーが構成されている場合）を試します。
問題は、すべてのアプリケーションがDNSを使用するように構成できるわけではないということです。
Microsoft独自のActiveDirectoryセットアップの説明でも、WINSの必要性について言及しています。
「以前のバージョンのWindowsでActiveDirectoryドメインのネットワークリソースを解決するには、NetBIOS名前解決（WINSサーバー、LMHostsファイル、またはNetBIOSブロードキャスト）が引き続き必要です。」
そうです、WINSを使用せずに逃げることができる組織がいくつかありますが、DNSサーバーにアクセスできれば、魔法のように必要はないという包括的な声明を出すにはWINSは間違っています。
たくさんのことにはまだ勝利が必要です（毎日ますます少なくなっています！）。私が見た最も一般的な例は、winsがクラスター化された2003サーバーでExchange2007を実行するための要件であるということです。 WinsはNetBIOS名で機能します。 NetBIOS名は、コンピューターで実行されているNetBIOSサービスによって使用される識別子です。これは、15文字（バイト）の名前とサービスを示す16番目の文字の組み合わせです。 NetBIOSネットワークリソースを識別するとき、これらの名前が使用されます。 NetBIOSは、インターネット上で名前解決を行うことはできません。 NetBIOS名は単一パーツ名であり、階層構造はありません。
NetBIOS名前空間はフラットです。つまり、NetBIOS名にサフィックスが追加されておらず、2台のコンピューターが同じNetBIOS名を持つことはできません。これは、1つのネットワーク内の各NetBIOS名が一意である必要があることを意味します。
MicrosoftWindowsのTCP/IPの基礎、第11章-NetBIOS over TCP/IP を参照してください。
WINSは、世界中のすべてのWindows管理者がそれを棍棒で殺そうとするあらゆる試みにもかかわらず、まだ非常に要件です。サブネットが分離されている場合は常に、WINSが必要になります。別々のサイトでVPNを実行していますか？これは、サブネットとWINSを意味します。 ADを理解していない古いクライアントがいますか？ WINSが必要です。ネットワークに接続しているDOSアプリケーションがありますか？ WINSもう一度。
WINSは、ブラウズリストの作成にも使用されます。 Active DirectoryベースのマシンはWINSがなくても機能しますが、参照リストは次の順序で入力されるため、遅延が発生する可能性があります。
- NetBIOSリモートネームキャッシュ
- WINS
- 放送
- LMHOSTS
- ホスト
- DNS
問題の核心は、SMBを生み出しCIFSを生み出したLANMANのルーツにあります...これがどこに向かっているのかがわかります。 LANMANは非常にLANベースのプロトコルでした。「インターネット」の概念はなく、「ルーティング」の概念はほとんどありませんでした。 WINSは、そのギャップを埋めてルーティングを可能にするために開発されました。現在まで早送りし、CIFSにはLANMANの下位互換性のあるサポートがいくつかあります。UNCパス名は「モダン」である可能性があります。 、ただし、それらは引き続きLANMANサーバーに接続します。次に、「参照リスト」全体があります。
MSはWINSサーバービズから抜け出すのに非常に近いですが、OSだけでなく、アプリケーションやサービスにも、=を必要とする「レガシー」フックが多すぎます。 WINSサーバー。そしてLANMANスタイルの送信がサポートされている限り、 WINSサーバー周辺。
編集：
はい、フラットドメインでWINSをオフにすることができます。
しかしながら...
- 子ドメインとしてabc.xyz.comとabc.123.comがあるドメインで試してみてください。 「閲覧リストの楽しみ」を3倍速く言うことができますか？
- 場合によっては、Exchange2007でそれを試してください。
- サブネットの外部に存在し、ファイアウォールを通過しているサーバーがある場合は、それを試してください。どういうわけか、それらのブラウズリストに問題があるようです...
このサービスがその中心にある利害関係を持っていることを私が見たいのと同じくらい、 Microsoftがやって来て、LANサービスのやり方を刷新するまで消えることはないでしょう。 （はい、コメントがありますそれがどのように必要とされないかについてのそのリンクで...しかし、馬の口によって言われていることを読んでください...）
これらの答えの多くは正しくないか、部分的に正しいです。まず、WINSが最初に使用される理由を理解しましょう。
WINSは、ホスト名をIPアドレスに解決するためのソリューションとして使用されます...しかし、NetBIOSがすべてのセネリオで機能する場合にWINSが必要なのはなぜですか？続きを読む！
DNSは、完全修飾ドメイン名とホスト名をIPアドレスに解決するために同じ目的などで使用されます。
次に、WINSが開発された理由を見てみましょう。
問題：NetBIOSは元々名前を解決するために使用されていましたが、ブロードキャストネットワークプロトコルです。そのため、レガシーおよび現在のほとんどのネットワークでは、ブロードキャストトラフィックはルーターを通過できず、すぐに十分なファイアウォールが通過できますが、後でVPNトラフィックでも通過できることがわかります。そのため、ほとんどのサブネットはNetBIOSトラフィックを他のサブネットに複製しません。あなたが本当のITネットワーク管理者であれば、ルーター、スイッチ、ファイアウォールでのこのNetBIOSトラフィックに精通しているでしょう。
ホスト-17/137から内部：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 Pix515Eファイアウォールのsyslogファイルからの25ビットネットワーク上の5つのNetBIOSブロードキャストの例です。 linksysルーターが25ビットネットワークである以外のことをよく知らない人にとっては、24ビットネットワークよりも小さいです。
ネットワーク：10.0.1.0/25、サブネットマスク：255.255.255.128、ブロードキャストアドレス：10.0.1.127、最大ホスト数：126。ご覧のとおり、トラフィックはセグメント内に含まれています。
解決策：WINSは、ブロードキャストトラフィックが含まれているサブネット全体に展開するように開発されており、クライアントは、依存する代わりに、名前を解決するためにWINSサーバーを構成し、ポイントすることができますブロードキャストトラフィック、したがってNetBiosは、WINSクエリが失敗したときにフォールバックになります。
しかし、待ってください... Microsoftネットワークを展開するときに、DNSサーバーを構成します。現在、DNSがプライマリであり、DNSに障害が発生した場合、NetBIOSがフォールバックになります。 WINSサーバーが展開されている場合、DNS、WINS、およびNetBIOS。
多くの人が遭遇する可能性のある問題は、ホスト名、たとえばHost-Aにpingを実行しようとするときです。コンピューターのインターフェイス構成によっては、主にDNSを構成したばかりで、ホストに登録されているNetBIOS名の有効期限が切れている場合、アドレスをIPに解決できない場合があります。
Host-Aがdomainhosts.comの一部であり、そのドメインに参加しているとしましょう。これは、プライマリDC domainhosts.comのDNSサーバー上のホストの（A）レコードです。 FQDN（完全修飾ドメイン名）ではなくホスト名のみでアドレスを指定するIP構成には、「プライマリおよび接続固有のDNSサフィックスを追加する」が必要であり、「この接続のDNSサフィックス：domainhosts.com」が最小限である必要があります。ホストの解決が実行されます-追加情報の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が必要です」」と言う人が出てくるでしょう。これは実際には当てはまりますが、一部の製品にのみ当てはまり、そのほとんどはそうではありません。中小企業および大企業環境にのみ展開され、SMS 2003、1Aレコードを使用、SQL Server 2000、名前付きパイプを使用、Exchange Server 2000など）および2003はすべてWINS完全な機能を必要とします...完全な機能ですが、WINSまたはNetBIOSがなくても、必要に応じてすべて機能します。
そうそう、2000年より前のMicrosoftが展開している場合に限ります。 WINSしかし、...アップグレードするよりも優れたソリューションが得られました。
Winsとnetbiosを混同しないようにしましょう..... WINSサーバーがなくても、ネットワーク上でnetbiosを実行できますが、ドメインでは推奨されません。これらすべてが必要なわけではありません。ネットワーク上に適切なDNSサーバーがある場合にファンキーな選挙が行われるため、NetBIOSを無効にするか、WINSサーバーを使用する必要があります（私は、最も緩い意味で適切に使用します。 MSDNSが関係しています:-)）
最近、Windows2008上のExchange2007で問題が発生し、NetBIOSを有効にする必要がありました。信じられない!!!
誰も言及していないことの1つは、NetBIOS名を解決する場合は、別々のサブネット上のVPNサイトが必要であるということです。このシナリオを検討してください。
企業ネットワークはプライベート10.x.x.xLANを利用し、リモートオフィスはプライベート192.x.x.xLANを使用します。それらの間にVPNトンネルがありますが、リモートオフィスは企業のDHCPサーバーまたはファイアウォールからトンネルを介してDHCPを取得しません。
企業サーバーをWINSに登録している場合、リモートクライアントは完全に別のサブネットからでも\ ServerNameを解決できます。最終的には、リモートオフィスファイアウォールをアップグレードしてDHCP over VPNを使用できるようになりますが、今のところ、この設定により次のことが可能になります。
- リモートPCで作業する場合、サーバーのIPアドレスを覚えておく必要はありません。
- IPアドレスではなくNetBIOS名に基づいてネットワークドライブをマップするのと同じログオンスクリプトを使用します。
- 一般的に、すべての一貫性を保ちます。
私がこれについて間違っている場合は誰かが私を訂正してください、しかし私の理解はNetBIOSがルーティング可能ではないので、WINSを使用せずにサブネット全体でNetBIOS名を解決することはできません。
多くの組み込みデバイスはWINSも使用します。多機能コピー機と最近購入したワイヤレスプロジェクションシステムがあり、WINSサーバー。
私たちが望む限り、WINSは長い間ここにあります。
数か月前、LAN上のWINSサービスを停止しました。数週間後、完全に削除しました。特別な理由なしに何年実行されているのでしょうか。環境によっては、これは不可能だと確信しています。それ以来、WINSがまだ実行されていると、問題が発生した可能性があります。私は純粋主義者だと思いますが、WINSは、「スロップ」プールをプレイしていることを思い出させます。そのポケットを狙っていない限り、ショットはカウントされません。
レガシーExchangeは引き続きWINSを使用するため、機能レベルを2008または2012に上げ、WINSを引き続き使用する場合、Exchange 2003以前を使用している場合（できればそうではない）、WINSを有効にする必要があります。
また、マルチドメイン環境でFQDNを使用しないアプリやスクリプトには問題がある可能性があります。
WINSは削除できますが、系統的にテストする必要があります。多くのアプリ、SAP、Exchange、その他のレガシーアプリを実行している大企業では、ドメインで2012ネイティブに到達するまで、ほとんど価値がありません。 WINS。
'いくつかのレガシーサーバー' かもしれないそれを必要とするので、私はそれがまだ維持されている環境にいます。
おそらく同じ状況にあるお店はたくさんあると思います。
ああ、まだ使っています。私たちが持っているWindowsワークステーションの約3分の1はドメインに属していないため、名前解決にドメインのDNSドメインを使用するように構成されていません。また、非常に断片化されたDNSランドスケープがあり、これが非常に断片化されたデフォルトドメイン設定につながります。このため、WINSは、最も多くのものを含む単一の名前解決サービスを表します。これは、サービスのグローバルインデックスに最も近いものです。
すべてをドメイン化するためにプッシュする場合、フラットなDNSランドスケープが得られます。それは良いだろう。
私はかつて、職場のSambaサーバーでWINSを有効にしました。これは、ドメインのないWindowsネットワークでの名前解決の（費やした時間の点で）最速かつ最も安価なソリューションでした。シンプルでうまく機能します。小さなネットワークで。
私は、WINSを使用せず、4年間WINSを使用していません。MicrosoftDDNSは、ActiveDirectoryネットワーク上で名前解決の優れた仕事をします。 WINSを必要とするプログラムは今のところ考えられませんが、いくつか覚えています。GuardianFirewallはLAN側でそれを必要としましたNIC日。
2007ExchangeクラスターはWINSを必要としません。私が持っているドキュメントによると、MSは、IPが変更されないため、そのセットアップでホストファイルを使用することをお勧めします。
DDNSに関する私の唯一の問題は、WAN全体です。各WANセグメント...のDDNS + ADC ...頻繁にDDNSが他の名前テーブルを更新する際に問題が発生します。
WINSは、リモートサイトまたはWANリンクがないクラスCネットワークに適しています。WINSに対する1つの大きな問題... SSL VPN + WINS=入力IPのcuz WINSは、グーナワークではありません。
私たちの環境は、WINSを何ヶ月も使用しておらず、そのために悪影響は見られませんでした。Exchange2003を電子メールサービスとして、VPN接続を介したマルチサイトトポロジがあります。
WINSは、既知の問題を解決するために特に必要な場合にのみ有効にする必要があります。 「万が一に備えて」時代遅れのテクノロジーを保持することは、それが必要とされていないことを確認した場合には意味がありません。