Windows インフラ

先日実際にお客さんのところで「TCPポートが涸渇する」という問題が起きたのでそのことについて書いてみようと思います。 実際のシステムはMicrosoft Dynamics CRMだったのですが、これは通常のフロントエンド/バックエンドシステムであればどのシステムでも起こりうる問題です。 フロントエンド/バックエンドシステム 「フロントエンド」、「バックエンド」という言葉が耳慣れない方もいると思うので簡単に説明しておきます。「フロントエンド」というのは実際にクライアントからの接続を受け、結果を返す役割のサーバーを指します。基本的にクライアントから見えるのはこのサーバーだけです。1台だけでは性能的にさばききれない、1台だけでは単一障害点になってしまう、というような理由から複数台配置されることが多いです。性能が足りなくなってきたらフロントエンドのサーバーの台数を単純に足してスケールアウトさせることができるというのもメリットです。 「バックエンド」というのはフロントエンドサーバーからデータの要求を受けつけ、それを返すサーバーです。フロントエンドは複数台で構成されることが多いのですが、その1台1台に実際にクライアントに応答を返すためのデータを全て保持していては、コストもかかりますし、それらをどのように更新、同期させるのかなど、色々と難しい問題が出てきてしまいます。そこで、データ自体は「バックエンド」のサーバーに持たせておき、必要なものをつど「バックエンド」から取得して、クライアントに応答する、ということにします。「バックエンド」にはデータベースサーバーが配置されることがほとんどです。また、「バックエンド」のサーバー自体も冗長化されることが多いですが、データベースサーバーを複数同時に稼動させるとデータの同期が難しいため、実際に稼動しているのは1台だけのActive-Passive構成を取る事が多いです。 フロントエンド/バックエンド構成の場合には、上記の図のようにTCP/IPのコネクションが張られます。フロントエンドの上の矢印はクライアントからの接続を意味しています。フロントエンドが複数台ある場合には、複数台に接続が分散されるように別途構成する必要があります。 Windows系のシステムでは - フロントエンドサーバーではIISが稼動 - クライアントからのHTTPの要求を受け付ける - バックエンドで稼動しているMS SQLサーバーから必要なデータを取得 - 結果のHTMLページを生成 - クライアントに返す ･･･というような処理が行われているのが一般的です。この際、フロントエンドの冗長化および負荷分散にはWindows標準のNLB(ネットワーク負荷分散)が使われ、バックエンドのMS SQLの冗長化には、Microsoft Cluster Service(フェールオーバークラスタ)が使われることが多いです。 何がおきていたのか 今回のトラブルは、フロントエンドサーバーにアクセスすると、特定のページでエラーが表示されてしまう、というトラブルでした。色々と可能性が考えられますが、結局はフロントエンドサーバーとバックエンドサーバー間のTCPコネクションに問題が発生していました。フロントエンドとバックエンド間では、SQLサーバーからのデータを取得するために、多数のコネクションが発生しています。そして今回のケースではフロントエンド側に大量にTIME_WAITのセッションが残ってしまっていて、それが原因でTCPのポートが涸渇し、バックエンドからデータを取得できない状態になってしまっていました。 TIME_WAITというのはTCPの状態を表すものです。通信の始まりから終わりまでどのようにTCPの状態が遷移するのか、ということはRFC793で定義されていて、その中のひとつです。以下の@ITの記事がこのあたりについてわかりやすく書いてあります。 - [＠IT：連載 基礎から学ぶWindowsネットワーク 第16回 信頼性のある通信を実現するTCPプロトコル（3） 2．TCPの状態遷移図](http://www.atmarkit.co.jp/fwin2k/network/baswinlan016/baswinlan016_03.html) 今回は、「フロントエンド側に大量のTIME_WAIT」「バックエンド側には特におかしな点は無い」ということでした。これはつまりフロントエンド側がアクティブクローズを行っているわけです。ですが、その量が半端な数ではありませんでした。netstat -anで確認したところ、負荷が対してかかっていない状況でも100コネクション程度はTIME_WAITが確認でき、負荷が高い時間帯では数千コネクション程度確認されました。 TCPのコネクションはいくつまで使えるのか? 数千オーダーになってくると、そもそもきちんと動くのか?と心配になるかもしれませんが、実際に今回のシステムではこのTCPのポートが涸渇してしまい、正常に接続できない状態になってしまいました。そもそもTCPのポート番号(=コネクション)はいくつまで使えるのでしょうか? 規定の状態では、Windows XPとWindows 2003では一時的なポートの範囲は1024～5000です。つまり4024個を同時に使ってしまうとそれ以上接続にいけなくなってしまいます。Windows VistaとWindows2008では49152～65535と大幅に数が増えました。 - [The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008](http://support.microsoft.com/?scid=kb%3Ben-us%3B929851&x=10&y=14) 対処方法 このようにTCPのポート番号が涸渇してしまうようなケースにはどうやって対処すればいいのでしょうか?大きく3つの方法があります。 1.アプリケーションでネットワークの扱いを変更する これが本来はいちばんいい対応方法です。TCPのコネクションを張るだけもパケットが3回も飛び交って時間がかかる(3ウェイハンドシェイク)わけですから、そんなに大量にコネクションを張らなくてはいけないくらい頻繁にデータを要求するなら、少数のTCPコネクションを張ったままにして、それをつど再利用すればいいわけです。これならポート涸渇の問題も発生しませんし、パフォーマンスすらよくなるでしょう。 ただし、もちろんこれは自分が作成しているアプリケーションならまだしも、製品であってはなかなか手がでる話ではありません。一応メーカーに文句はいいつつも、別の方法で問題を回避するより仕方が無いでしょう。 2. 一時的なポートの数を増やす 一時的なポートの数を増やすことでも対応できます。以下のレジストリの値を変更し、5000~65534までのポート番号までを使用できるようにできます。 ...

とりあえずget-commandとget-helpでヘルプを見ながらある程度のことができるようになってきたら、次に把握すべきはPowerShellが「オブジェクト指向」である、ということだと思います。これは既存のほかのシェルとは決定的に異なる点であり、PowerShellのもっともすばらしい点だと思います。 具体的に見てみましょう。例えば文字列。 P S C : \ > $ h o g e = " h o g e " .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, “Courier New”, courier, monospace; background-color: #ffffff; /white-space: pre;/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } ...

クラッシュ。ブルースクリーン。BSOD。 嫌な単語です。WindowsServer管理者としてはもっとも遭遇したくない現象の1つでしょう。でも残念ながら結構よく遭遇してしまうのが現実です。 対応としては、表示されるストップコードをGoogleやMicrosoftのKnowledgeBaseで検索してみて、該当する情報を調べてみたりする･･･ということがまずできるわけですが、それだけで問題の原因にたどり着けることは稀です。通常は色々と発生する条件を絞り込み、問題を切り分けて「このあたりが怪しい」というところまで持っていったところで機器のみなし交換やソフトウェアのバージョンアップや入れ替えを行い、問題が再発しないことを祈る･･･この程度の対応が精一杯だと思います。 しかし、このような問題を切り分けて回避していくアプローチでは結局問題の根本原因が判明せず「いつ再現するかわからない」状況になってしまいます。そうではなく、「問題の根本原因」を突き詰めていく方法、それがクラッシュダンプ解析です。 クラッシュダンプが発生するのは、何かしらのHWなり、ソフトウェアなりに問題があることは確実なわけですから、その原因となっているコンポーネントを突き止めて、そのメーカーに証拠とともに改善要求を出す、これがWindowsServer管理者が取れる最善の方法です。 これができるためには、(ケースにもよりますが)かなりHWやOSの深い知識を持ってダンプの解析を行わなければいけません。 私がエンジニアになってからも何度もこのダンプの解析の必要性に迫られたことがあるのですが、残念ながら当時の私にはその能力がなく、またその能力を身に着けたくてもその方法が全くわからない･･･ということがずっと続いていました。泣く泣くメーカーに高い費用を払ってダンプの解析を頼むことも良くありました。 ですが、ここさいきんではかなり情報が公開され、ダンプ解析をできるようになるための知識を身につけることが可能になってきています。 お勧めの書籍 ここではダンプ解析ができるようになるための知識を身につけるためのお勧めの書籍を紹介します。 Windowsダンプの極意 エラーが発生したら、まずダンプ解析! 上原 祥市 まずは、この書籍。日本語でダンプ解析のことを正面から取り扱った本は他にはないと思います。様々なケースのダンプ解析の手法が詳しく書かれており、ここに書かれていることを一通り理解できるようになれば、大抵のケースで問題モジュールの特定が可能になると思います。 プログラムはなぜ動くのか 第2版 知っておきたいプログラミングの基礎知識 矢沢 久雄 コンピューターは結局のところCPUがプログラムを実行することでうごいているわけで、ダンプ解析に関してもこの部分の理解が不可欠です。メモリとCPUの処理の関連性から基本的なマシン語の成り立ち、C言語での関数呼び出し時のスタックの使われ方などなど、基本的なコンピューター、プログラムの動作内容の理解にはこの本がわかりやすいと思います。難易度も低めです。 インサイド Microsoft Windows 第4版〈上〉 (マイクロソフト公式解説書) ディビット ソロモン マーク ルシノビッチ インサイドMicrosoft Windows第4版〈下〉 (マイクロソフト公式解説書) ディビット ソロモン マーク ルシノビッチ ダンプ自体は結局OSが保持しているメモリの内容が吐き出されたものであり、それを理解するためにはOS自体の知識が欠かせません。OSの仕組みに関してはインサイドWindowsが良く書かれています。ただし、難易度も高いですが･･･。 ダンプ解析自体は、あるいはサーバー管理者には直接必要ないという考え方もあるかと思います。お金で解決できる問題でもありますし(それを言い出したらサーバー管理自体もお金の問題なのですが)、取り組む場合に勉強すべきレベルが深すぎて、レベルも高いですし、必要となる前提知識としてかなり根源的なものが要求されてしまいます。 ですが、私は逆にこのような物事に取り組み理解することこそが、技術力の地盤となり、ある程度の年月がたっても通用するエンジニアとなるための(遠回りのように見える)近道なのではないかと考えています。 私自身まだまだ技術力不足な面が多いのですが、このブログでもダンプ解析のことについて少しずつ触れていきたいと思います。

今回はコマンドプロンプト上のコマンドの結果をファイルに保存する方法についてです。バッチファイルを実行させるときや、何かの処理の結果を記録しておきたいときには必須のテクニックになりますので、きちんと理解して楽をしましょう。 標準出力と標準エラー出力 コマンドプロンプトで何かコマンドを入力、実行したときに表示されるメッセージは、コマンドプロンプト上では見分けがつきませんが、実は以下の2種類に明確に分かれています。 - 標準出力 - 標準エラー出力 ちょっと具体的に見てみましょう。 上記のコマンドの結果を見てみてください。単純なdirコマンドはディレクトリの中身を表示しています(何もないですが)。dir hogeコマンドは、hogeというサブディレクトリが存在しないので「ファイルが見つかりません」と表示されています。 コマンドプロンプト上ではすべてコマンドの結果が表示されているだけにしか見えませんが、実はすでに標準出力と標準エラー出力が混ざっています。 ここでリダイレクトコマンドに登場してもらいます。「>」とリダイレクトすると、標準出力のみがリダイレクトされます。これを使って標準出力だけをファイルにリダイレクトさせてみます。 なかなか面白い結果になりますね。dirコマンドの結果は(特にエラーもなかったので)すべて標準出力にのみ出力されているわけです。一方dir hogeコマンドは、標準出力にある程度出力したところで、ファイル(フォルダ)が存在しなかったため、標準エラー出力に「ファイルが見つかりません」と出力していたわけです。 標準エラー出力をリダイレクトするには「2>」コマンドを使います。ちょっとやってみましょう。 見事、標準エラー出力を別ファイルに出力させることができました。 結果を出力させるには「>」コマンドでリダイレクトさせればいい、と覚えている人が多いですが、標準出力のみをリダイレクトさせると、標準エラー出力に出力されたメッセージを取りこぼしてしまうので注意してください。 結果を1つのファイルに保存する ここまでで、きちんとコマンドの結果をファイルに保存したいならば、標準出力と標準エラー出力の両方をリダイレクトさせてあげないといけないことがわかりました。それでは1つのファイルに保存させてみましょう。 と、このように単純に同じファイルに対して標準出力と標準エラー出力をリダイレクトさせるように書いてしまうと、両方のプロセスで同じファイルをつかみに行ってしまい、うまくいきません。 これを解決するには「標準エラー出力を標準出力にリダイレクト」します。なんだか文章で書くと難しいですが、コマンドは簡単です。 これでめでたく標準出力と標準エラー出力を同じファイルに収めることができました。「&1」というのは、標準出力のことを表しています。 (余談)ついでにいうと「&1」が標準出力なら「&2」が標準エラー出力で、これを使えば「標準出力を標準エラー出力にリダイレクト」することもできそう……と思って試してみたのですが、できませんでした…。 ファイルへの追記 ここまでの説明でリダイレクトは「>」というコマンドを使ってきましたが、これはファイルの新規作成です。既存のファイルがあっても上書きされます。複数コマンドの結果を1つのファイルに保存したいような場合には「追記」にする必要がありますが、これは「»」というように2つ繋げることで実現できます。

今回はアクセス権の話です。主にファイルサーバーの運用時のお話になると思いますが、ファイル共有はいつでもどこでも(クライアントOSでも)簡単にできますので、すべてに関連するお話ですのでしっかり押さえておきましょう。 NTFSアクセス権 まずはNTFSアクセス権です。これはNTFSでフォーマットされたドライブであれば、すべてのフォルダ、ファイルが持っています。逆に言うと、FATでフォーマットされている場合にはファイルシステムとしてのアクセス権は設定できません。なので、この点だけをみてもNTFSアクセス権を採用すべきなわけです。 適当にファイルやフォルダのプロパティを開くと、「セキュリティ」タブがあります。 ここで、誰がどのような権限を持つかということを詳細に設定できます。エントリを追加するには[追加]を押して、エントリを追加し、アクセス権を設定することができます。 NTFSアクセス権の継承 新しいエントリは追加できますが、すでに登録されているエントリ(上記の例だとAdministratorsの権限)に関してはグレーアウトされていて編集できません。これはNTFSアクセス権が”継承”されているためです。継承の様子は[詳細設定]の中で確認できます。 つまり、上の階層で設定されたセキュリティの設定は基本的に子供は受け継ぐようにできているのです。自由に編集できるようにするためには明示的に継承をしないようにさせる必要があります。 この操作は[詳細設定]の中の[親からの継承可能なアクセス許可をこのオブジェクトと子オブジェクトすべてに伝達できるようにし、それらをここで明示的に定義されているものに含める]という長ったらしいチェックボックスを外すことで実現できます。 チェックボックスを外そうとすると上記のように説明がなされて、現在の設定をコピーするのか、一度すべて削除するのかを選択することができます。どちらを選んでも最終的に設定したいことに変化があるわけではないので、つど、効率の良い方を選べばよいです。 上記の画像は[コピー]を選んだ場合ですが、継承元がすべて[継承なし]になり今まで編集できなかったエントリも編集できるようになっていることがわかります。 自由にアクセス権をつけるためにはバンバン継承を切る必要があり、そうすればいくらでも自由に設定できるのですが、はたしてそれで管理上良いのか?という問題が残ります。場合にもよりますが、たいていの場合はあまり良いことではないでしょう。 このあたりの話はファイルサーバーの設計の話にもつながってくるので詳細は別のエントリで書きたいと思います。 所有者 [詳細設定]ボタンの中に[所有者]というタブがあります。 ここではフォルダ、ファイルの現在の所有者の確認と、所有者の変更が行えます。つまり、他の人が作ったフォルダ、ファイルを自分のものにしてしまえるわけです。 何のためにこのような機能があるのかというと、管理者がきちんと全てのフォルダ、ファイルを管理できるようにするためです。この機能がないと、誰かが誰も触れないようなセキュリティ設定をしてしまった後で、そのアカウントすら(退社などで)消してしまったような時に打つ手がなくなってしまうからです。 共有のアクセス権 共有のアクセス権はフォルダのプロパティの[共有]タブ内の[アクセス許可]から設定できます。 NTFSのアクセス権と比べるとはるかにシンプルです。権限も3種類しかありませんし、継承という概念もありません。 共有のアクセス権とNTFSのアクセス権の適用タイミング それぞれの設定がどのように適用されるのか、というと、以下のようなルールになっています。 ファイル共有を経由したアクセスの時にのみ共有のアクセス権が適用される 同じファイル、フォルダへのアクセスであっても、別のファイル共有を経由してアクセスした場合には、異なる共有アクセス権が適用される NTFSのアクセス権は常に適用される(「別経路」が存在しないから) 共有のアクセス件とNTFSのアクセス権で異なるアクセス権の場合には、両方で許可されていることのみが行える 一番気をつけなくてはいけないのは、「共有のアクセス権でアクセス制限しているのでNTFSのアクセス権は制限していない」場合に、「直接コンソールでログインされるとアクセスできてしまう」ということです。気をつけましょう。 また、それぞれの特徴として以下のようなものがあります。 NTFSのアクセス権はファイル、フォルダ単位の設定であるため、半永久的に残る。場所を移動した場合でも残る。(※例外あり。詳細は「コピー&ペーストとカット&ペーストではNTFSアクセス権が異なる」参照。) 共有のアクセス権は共有を解除するときれいに無くなる。 共有のアクセス権に細かくエントリを追加していると、それを意図せず解除してしまった場合には、同じ設定を再度行うことが困難になりますので、気をつけましょう。 どのようにアクセス制御すべきか 「で、結局どうしたらいいの?」という問いに関しては色々な答えが考えられるでしょうが、私の方針は以下のようなものです。 共有のアクセス権は常にEveryoneフルコントロール NTFSのアクセス権でのみ制御する 共有のアクセス権とNTFSアクセス権の2重管理は嫌ですし、共有のアクセス権だけでコントロールしようとするのは抜け道があるので嫌です。そうすると必然的にこのような方針になると思います。 「いや、それだとこういった問題がある」「もっとこうしたほうがいい」などコメントありましたら、是非いただければと思います。

メール送信の仕組みを知りたい方はこの記事をどうぞ。コマンドプロンプト、バッチファイル等から自動的にメールを送信したい方はこちらをどうぞ。 今回は電子メールのお話です。メールはインターネット経由で世界中と送受信できるすばらしい仕組みなのですが、基本的な仕組みはかなりシンプルになっています。それを実感するために、メールクライアントを使用せずに、コマンドプロンプトだけでメールを送信してみましょう。仕組みを体感できますし、トラブルシュートの際にも有効に使えますよ。 ここでは、例として私のgmailのアドレスであるebibibi@gmail.comにメールを送ってみようと思います。(自分のメールアドレスで実験してみてください) メールサーバーを探す まずはじめにメールサーバーを探します。メールをどこに送ればとどくか、ということですね。これはDNSにMXレコードとして記述されています。 「set type=mx」として、MXレコードを指定した上で「gmail.com」というドメインのMXレコードを検索します。 コマンドの実行結果から以下の5台のメールサーバーが存在していることがわかりました。 - gmail-smtp-in.l.google.com - alt1.gmail-smtp-in.l.google.com - alt2.gmail-smtp-in.l.google.com - alt3.gmail-smtp-in.l.google.com - alt4.gmail-smtp-in.l.google.com どのサーバーに送信してもメールは届くはずですが、MX preferenceの値が低いものほど優先的に送信するという決まりになっていますので、ここではMX preferenceがいちばん低い5になっている「gmail-smtp-in.l.google.com」にメールを送ることにします。 メールサーバーへの接続 メールサーバーにメールを送信するにはまずTCPのコネクションを張らなくてはいけません。ポートはSMTPプロトコルの25番ポートです。 telnetコマンドで25番ポートに接続します。 SMTPでのメール送信 接続できたらSMTPプロトコルでメールを送信します。SMTPプロトコルは人間が手でメールを送れるくらいシンプルなものです。 以下の例はRFC的に正しくない部分も含まれていますが、メールの送信自体はできます。まずはまねをして体感してみてください。 以下のようにきちんとgmailに届きました。 SMTPプロトコルの詳細はRFCで定義されていますので、興味がある人は見てみるとよいでしょう。 - http://www.ietf.org/rfc/rfc2821.txt かんたんな説明 やり取りの中身をもう少し詳しく見てみます。 まず接続すると相手のSMTPサーバーのバナーが表示されます。 2 2 0 m x . g o o g l e . c o m E S M T P 5 s i 1 0 3 9 1 9 7 8 y w l . 2 8 次にこちらから相手のサーバーに挨拶をします。 ...

大量に何かを操作するときには、やはりプログラムを書くなり、WSH、PowerShellなどでスクリプトを書くなりしてしまうのがいいです。でも、プログラムやスクリプトは敷居が高くて･･･という人も多いと思います。その考え自体は直したほうがいいと思いますが、気持ちはわかります。でも、だからといって、GUIで全部操作･･･というのは現実的に無理な規模があります。何とか手作業でがんばれるのはユーザー数100人前後まででしょうか。 で、そんな人にお勧めできるのがバッチファイルをExcelで作成する方法です。「Excelって表計算ソフトじゃないの?」と思うと思いますが、うまく使ってあげればコマンドを簡単に作成してあげることができます。 例えばユーザーを大量に作成する必要があるとして、そのユーザーのリストをExcelファイルでお客さんに作成してもらう、ということはありがちです。そうしたら、その1行が1ユーザーに対応しているわけですから、コマンドを作ってしまえばいいんです。/p pユーザーを作成するコマンドは別途調べないといけませんが、windowsであればnet userコマンド、ADであればdsaddコマンドあたりでいいでしょう。 Excelで相対参照とamp;での文字連結を使ってあげるだけでもこのくらいであれば非常に簡単にできちゃいます。サンプルは。 これをプログラムでやろうと思ったら、ファイルをオープンして、CSV形式を解釈して、ADに接続して･･･と結構手間がかかります。単純にコマンドを実行するだけでできることをやるのであればExcelを有効活用すると視野が広がると思います。 もちろん限界はありますが、プログラミングが苦手な人でもGUIで操作する以外の方法を考えるいいきっかけにはなるのではないでしょうか。

Active Directoryを理解するためには、「パーティション」と「レプリケーションスコープ」の理解が欠かせません。簡単に解説してみたいと思います。 パーティション ActiveDirectoryのデータベースを保持しているのはドメインコントローラーです。そして、そのドメインコントローラーが持っているデータベースをより詳細に見ると、以下のように4つの大きなパーティションの種類があります。 パーティション名 格納されている情報 レプリケーションスコープ (複製範囲) Configuration Partition (構成パーティション) フォレスト、ドメインの構成情報 ActiveDirectory対応アプリケーションの構成情報 フォレストワイド Schema Partition (スキーマパーティション) ActiveDirectoryに存在するクラス、オブジェクトの設計情報 フォレストワイド Domain Partition (ドメインパーティション) ドメインに存在するオブジェクトの情報 ドメインワイド Application Partition (アプリケーションパーティション) ※2003から新規導入 ActiveDirectoryに情報を格納する用に設計されているアプリケーションの情報 色々 何かを操作するときに「この操作はどのパーティションに対しての操作なのか、情報はどこに保存されているのか」ということを意識できるようになるとActive Directoryのことがよくわかってきます。 特にアプリケーションパーティションを除く3つのパーティションは特に重要ですのでその用法含めてしっかり理解する必要があります。 具体的に見ていきましょう。 ADSIEdit 具体的にADの中を覗いていくためには、それ相応のツールが必要です。一番使えるのはADSIEditという、ADのデータベースを直接覗けるツールです。すべての情報が見え、すべての操作が行えるというある意味とても危険なツールです。 ADSIEditはSupport Toolsに含まれていますので、Support Toolsを導入しておきましょう。インストールCDやサービスパックCDにも含まれていますし、Webからダウンロードもできます。 - [ADSI Edit を使用した Active Directory 属性の編集](http://technet.microsoft.com/ja-jp/library/bb124152(EXCHG.65).aspx) - [Download details: Windows Server 2003 Service Pack 1 32-bit Support Tools](http://www.microsoft.com/downloads/details.aspx?FamilyId=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en) 起動方法としてはMMCを起動後、ADSIEditを組み込む方法もありますが、直接「ファイル名を指定して実行」から「adsiedit.msc」を起動してしまうのが楽だと思います。 このように起動すると、Domain, Configuration, Schemaの3つのパーティションに接続された状態でADSIEditが起動してきます。 以降の説明の中で"DC=test,DC=local"という記述が何度も出てきますが、これはこの画像を取得した環境のドメイン名(=フォレスト名)がtest.localであり、その名前が表れているものです。各自自分の環境の名前に読み替えてください。 Configuration Partition Configuration Partitionはその名の通り、構成情報が格納されています。Active Directory自身の構成情報や、Active Directory対応のアプリケーションの情報が入っています。 ...

今回はInternet Explorerの「ゾーン」と統合認証についての話です。 IEのゾーンとは IEの「ゾーン」とはセキュリティを高めるためにある仕組みで、信頼できるサイトでは、色々なことを許可し、信頼できないサイトでは極力できることを絞る･･･ということを自動的に行ってくれる仕組みです。 IEを立ち上げて、ウインドウ右下の「ゾーン」を確認してみましょう。以下はIE7でYahoo! Japanを表示したところですが、「インターネットゾーン」として認識されています。 このようにインターネット上のサイトは「インターネットゾーン」にあるものとして扱われ、できることを比較的絞った状態になっています。例えば未署名のActiveXコントロールはダウンロードできません。 ゾーンとしては以下の種類があります。 - インターネット - ローカルイントラネット - 信頼済みサイト - 制限つきサイト ぞれぞれのゾーンのレベルのカスタマイズ(できること、できないことを設定すること)は「ツール」→「インターネットオプション」→「セキュリティ」タブから行えます。 IEのシングルサインオン で、このゾーンの設定の中にシングルサインオンの設定があり、ゾーンの判定とあいまってなかなかわかりづらい挙動をしてくれます。今回はそこをお伝えしたいのです。 良くあるのが、Active Directory環境下で - IISでWebサイトを構築していてWindows統合認証に設定しているのに、アクセスするとIDとパスワードを求められてしまう - でも、IDとパスワードを求められないケース(端末、ユーザー)もある という問題です。 これは実は、セキュリティレベルの設定と、ゾーンの判定によって起こされています。 まず重要なのはそれぞれのゾーンにある、「ユーザー認証」の設定です。 規定の状態では、どのゾーンに関しても「イントラネットゾーンでのみ自動的にログオンする」という設定になっています。 なので、 - イントラネットゾーンであればWindows統合認証を使って、ドメインにログオンしているユーザーならそのIDで自動的にWebサイトにログオンする - イントラネットゾーン以外のゾーンではIDとパスワードを聞かれる という挙動になります。 どのサイトがどのゾーンに含まれるのか では、どのサイトがどのゾーンに含まれるのでしょうか?それは以下のようなルールになっています。 - 信頼済みサイト - 明示的にユーザーがアドレスを追加したサイト。 - 制限付きサイト - 明示的にユーザーがアドレスを追加したサイト。 - ローカルイントラネット - 自動判定。 - 明示的にユーザーがアドレスを追加することもできる。 - インターネット - 信頼済みサイト、制限付きサイトに含まれておらず、ローカルイントラネットと、自動判定されなかったサイト。 つまり、ローカルイントラネットの自動判定ロジックが肝になります。 ローカルイントラネットの判定基準 今回の話の一番重要なところです。ローカルイントラネットの判定基準は、規定の状態では - URLに.(ドット)が含まれるかどうか が判断基準になっています。URLに.(ドット)が含まれればそれはローカルイントラネットではなく、URLに.(ドット)が含まれなければそれはローカルイントラネットなのです。 ...

今回は「インターネット」ではなくて、「イントラネット」に繋がらないというケースについて書いてみます。 今、Active Directoryで構成されたWindowsネットワーク(ドメイン名sample.lcoal)があるとして、そこにintraという名前のメンバサーバーがあり、そこでイントラサイトが稼働しているとしましょう。このときのURLは何になるでしょうか? - http://intra/ - http://intra.sample.local/ さて、どちらが正解でしょうか? 正解は、「どちらも正解」です。 「なんだ、それは」と思うかもしれませんが、これがなかなか奥深い話もあったりします。たとえば1のhttp://intra/というアドレスを使っている場合。クライアントの設定によってはつながったりつながらなかったりします。繋がる場合でも、名前解決の方法が異なったりします。ちょっと詳しく見てみましょう。 名前解決の手段は何か? まず、http://intra/というURLですが、実際にはintraというホストのIPアドレスを知らなくてはいけません。最終的にはTCP/IPで接続するわけですから。 名前解決の手段としては様々なものがある、という話は以前しました。 - 参考：[NETBIOS名とホスト名の違い](https://windowsadmin.ebisuda.net/2009/02/10/netbios%e5%90%8d%e3%81%a8%e3%83%9b%e3%82%b9%e3%83%88%e5%90%8d%e3%81%ae%e9%81%95%e3%81%84/) この場合intraを名前解決する方法は以下のパターンがあるわけです。 - hostsファイル(ホスト名) - DNS(ホスト名) - lmhostsファイル(NETBIOS名) - WINS(NETBIOS名) - ブロードキャスト(NETBIOS名) で、厄介なのが2に関してです。 ドメインサフィックス DNSとして考えたときに「intra.」なんていうホスト名はあり得ないわけです。本来は「intra.sample.local」です。なので「intra」を裏で「intra.sample.local」に変更してくれている仕組みが存在するわけです。 マイネットワーク→プロパティ→(対象NIC)→プロパティ→インターネットプロトコル(TCP/IP)→プロパティ→詳細設定→DNSタブ (なんてわかりづらい所にあるんでしょう…) - 「プライマリおよび接続専用のDNSサフィックスを追加する」 - 「プライマリDNSサフィックスの親サフィックスを追加する」 - 「以下のDNSサフィックスを順に追加する」 - 「この接続のDNSサフィックス」 そしてもう一か所あります。 マイコンピュータ→プロパティ→コンピュータ名タブ→変更→詳細 (なんてわかりづらい所にあるんでしょう…) - 「このコンピューターのプライマリDNSサフィックス」 - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」 これらの設定が"仕組み"になります。 勝手にドメインサフィックスが追加される理由 通常は以下のような流れで、勝手に適切なドメインサフィックスが追加されるようになっています。 - Active Directoryに参加する - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」が既定で有効であるため、ドメイン名(sample.local)が「このコンピューターのプライマリDNSサフィックス」として設定される - DNSを使った「intra」の名前解決の際に「プライマリおよび接続専用のDNSサフィックスを追加する」および「プライマリDNSサフィックスの親サフィックスを追加する」が有効であるので「intra.」だけではなくて「intra.sample.local」も検索される うまくいかないケース ここまでの説明が理解できれば、http://intra/ではアクセスできないケースがあることが理解できるのではないかと思います。 具体的なケースを示します。まず前提として以下のケースで、 - hostsファイルに記載されていない - lmhostsファイルに記載されていない - WINSが構成されていない - 対象サーバーと同一サブネットに無い(ブロードキャストでの名前解決はできない) これらすべてに加えて、以下のどれかの条件に当てはまる時です。 ...

ActiveDirectoryというと、色々な要素があり、なかなかとらえずらいですが、まずはひとつの見方として、認証、アカウント管理の視点からその進化の過程を見ていこうと思います。(※あくまでもひとつの見方です。) スタンドアロンPC まず、スタンドアロンPCではローカルでユーザー管理、アクセス制御を行います。ローカルにユーザーを作成することが出来、NT系のOSではローカルにユーザーを複数つくり、それぞれプロファイルを切り替えて使うことで1台のパソコンを共有する仕組みが備わっています。その上で他の人に見られたくないファイルには自分だけがファイルにアクセスできるようにアクセス権を設定することが出来ます。1台のWindowsマシン上で、マシンの共有とリソース権限の確保が実現されています。 複数のPCがあると困ること 複数のWindowsPCが存在すると、ユーザーアカウントデータベースはそれぞれのPCに個別に保持されます。アカウントとパスワードの組み合わせを複数覚える必要があるので少々不便になります。同じIDとパスワードにしてしまうことも考えられますが、ユーザーの登録作業は必須です。また複数PC間でリソースの共有ができないので、不便です。 ワークグループでのリソース共有 リソースの共有(例えば共有フォルダや共有プリンタなど)を実現するために、WindowsPC同士をネットワークでつなぎます。具体的にはNetBEUI、TCP/IPなどのネットワークプロトコルを構成し、相互に通信可能な状態にします。そのうえで、複数のマシンがネットワークに参加します。これをWindowsネットワークでは「ワークグループ」と呼びます。ワークグループに参加してしまえば、マイネットワークからネットワーク上のコンピューターの一覧が表示でき、共有したいリソースを「共有」し、他のPCに見せることが出来ます。しかし、ここでアクセス制御をする上で少々こまったことが起きます。 ワークグループでのリソース共有で困ること リモートのPCで共有されているリソースにアクセスしようとすると、IDとパスワードを聞かれてしまいます。これは他のPCにアクセスするためにはそのPCで有効なIDパスワードを入力し、そのPCのユーザーとしてアクセスする必要があるからです。複数のパソコンにアカウントデータベースが存在し、連携されていないのですからこれは当たり前です。 複数のパソコンで複数のIDが管理されており、パスワードも一致していないとしたら・・・かなり混乱します。これを避けるために、同じIDを全てのWindowsPCに登録し、パスワードもそろえてしまうという運用方法があります。これなら他のPCのリソースにいちいちID/Passwordを入力しなくてもアクセスすることが出来ます。 しかし、ある程度大きな規模でこれを実現しようとすると、1人新しく人が加わっただけで全てのPCにユーザーを登録して回らなくてはいけません。さらにセキュリティ対策のために、定期的にパスワードを変更する必要がある・・・などとなったら面倒でやっていられません。 アカウントデータベースの一元管理(NTドメイン) そこでアカウントのデータベースを個別のWindowsPCに持つのではなくて、一括してどこかにまとめて管理してしまおうという発想が出てきます。これがWindowsドメイン(NTドメイン)です。 NTドメインによって、認証やネットワーク資源の一元管理を行うことが出来るようになりました。 ユーザーはドメインに登録し、コンピューターはドメインに参加することで、ドメインに管理をゆだねます。PCにログオンするときや別のPCにあるリソースを使用する際には、アカウントデータベースとしてNTドメイン上のアカウントデータベースを利用するわけです。これで、どのPCにでも誰でもログオンでき、別のPCにあるリソースにアクセスする際に、一々ID,パスワードを入力する必要がなくなりました。 (余談)ローカル管理から一元管理への流れ ホスト名の解決にしても、NETBIOS名の解決にしても、データベースにしても、たいていのものはローカルでの管理から始まって、ネットワーク上で共有する方向に向かっているように思われます。 NTドメインの問題点 こうしてNTドメインにアカウント情報が共有され、クライアントPCもドメインのリソースとして登録すれば、どのPCにでもログオンできるし、リソースの管理も一元化できます。しかし、以下の問題点が・・・。 扱えるオブジェクト数の限界 NTドメインでは単一のドメイン内で扱えるオブジェクト数がそれほど多くなく約4万が限界でした。そのため大規模な環境の場合、アカウントを登録するドメインとは別にリソースを登録するドメインを分ける・・・ということを余儀なくされることがありました。 管理者の権限 ドメイン内においてドメイン管理者は全てのオブジェクトに大しての権限を持つことになります。本来であればひとつの拠点や部署など小さな単位で管理権限を与えたい場合でも、一般ユーザーでない場合にはドメイン管理者にせざるを得ず、不必要に強い権限を与えなくてはいけませんでした。これを避けるためには、これまたドメインを分割する必要がありました。 信頼関係の管理 上記のような理由からにドメインを分割した場合には相互に連携するために、信頼関係を結ばなくてはいけません。この信頼関係はドメインが増えるたびに全て追加で個別に登録の必要があったため、維持、管理に問題がありました。 シングルマスタ NTドメインではアカウントの管理は一元化されたものの、大規模に展開するためには、そのデータベースを複数用意し、参照できる必要があります。そうしないとトラブル発生時に全ての情報が失われてしまい、機能がストップしてしまうことになります。NTドメインではこれはPDCがマスター、BDCがバックアップといった具合に実現されています。 しかし、データベースの更新処理自体はPDCにしか行えず、PDCのデータのコピーをBDCが保持するという形態になっていたため、運用上少々不便でした。例えば、PDCが無い拠点とのネットワーク経路に障害が発生したような場合には、PDCにアクセスできず、ユーザー情報の更新すらできなくなってしまいます。 ActiveDirectoryでの改善 ActiveDirectoyでは上記の問題点が解消されています。 扱えるオブジェクト数の限界 ActiveDirectoryでは単一のドメインで扱えるオブジェクトの数が100万オブジェクト以上となり、事実上オブジェクト数のみを問題としてドメインを分割する必要はなくなりました。 信頼関係の管理 ActiveDirectoryでは「ActiveDirectoryフォレスト」というものを形成し、自動的に推移的な信頼関係を構築するので、信頼関係の維持管理にかかるコストが減少しました。 同一フォレストに子ドメインを作成すれば、自動的に信頼関係を結んでくれるようになったのです。 管理者の権限 ActiveDirectoryでは単一のドメインの中にOUという管理組織を作成することができ、その中にオブジェクトを格納できます。その上でそのOUに対して管理の委任を行うことができ、「このアカウントにはこのOUの管理を任せる」ということが出来るようになりました。 これによってわざわざドメインを分割することなく、1つのドメインの中で管理の制御が行えるようになりました。 シングルマスタからマルチマスタへ ActiveDirectoryではドメインコントローラーが対等な立場として存在し、そのドメインコントローラーでも情報の更新が行えるマルチマスタモデルになりました。 ただし、全ての機能が対等に存在しているわけではなくて、5つの機能(フォレスト単位で2つ、ドメイン単位で3つ)に関しては単一のドメインコントローラーが保持しています、これはFSMO(フィズモ)の役割などと呼ばれます。FSMOに関しては別のところで述べます。 ActiveDirectoryのいけてないところ 色々改善されたActiveDirectoryですが、悪いところも多々あります。 データベース容量 扱えるオブジェクト数の限界は増えたものの、その分データベースにしわ寄せが来ている印象があります。データベースエンジンはMicrosoftおなじみのExtensible Storage Engine(ESE)です。それぞれのオブジェクトが消費するデータベースが結構大きく、削除済みのオブジェクトも規定で60日間、2003R2以降では180日間保持されます。なので、オブジェクトの絶対数はそれほどでもないけれども、毎日大量に削除～作成を行うようなシステムでは容量は要チェックです。 テストフェーズだからといって、大量にオブジェクトを生成、削除を繰り返していると、DBが肥大化してしまうことになりますので、気をつけましょう。 信頼関係の管理 フォレスト内での信頼関係はいいのですが、その他のNTドメインや別フォレストと信頼関係を結ぼうとすると、結局以前のNTドメインの際の問題に直面します。ある意味仕方ないのかもしれませんが・・・。 ※ただし、フォレスト間の信頼関係に関してはWindowsServer2003で改善されています。 - [Active Directory フォレスト間信頼機能](http://www.microsoft.com/japan/windowsserver2003/evaluation/demos/flash_animations/01forest.htm) OUへの効率的なリソース配置 OUを分けることで管理を委任できる・・・というところが売りなのですが、OUに対していかに効率的にリソースを移動、配置するかという点はあまりサポートされていません。たとえば、コンピューターオブジェクトは普通にドメイン参加するとComputersコンテナに作成されるので、そこから手動でOUに移動する必要があります。ドメイン参加の際にコンピューターオブジェクトが作成される規定の場所を変更することは可能ですが、それも別の1箇所に変更するのみであって、条件によって振り分けるようなことは出来ません たとえば、あるOU以下しか管理権限がない場合に、単純にドメイン参加すると、Computerオブジェクトが管理下にないOUに作成されてしまい、手も足も出なくなってしまいます。このような場合、先にコンピューターオブジェクトを管理下のOUにつくっておけば問題は回避できますが・・・。 OUへのオブジェクトの配置は今のところ独自にアプリケーションを開発するなどして管理してあげる必要があります。 シングルマスタ、マルチマスタ 複数のDCに書き込めることのメリットも確かに沢山あるのですが、複数に書き込めるようになった分だけその整合性を取るところでおかしなことが起きます。書き込んだつもりの情報があとから更新された情報によって上書きされたり、削除したはずのオブジェクトを再作成しようとすると、まだ削除の情報が全てのDCに伝わっていないためにエラーではじかれてしまったり。最悪なのはDC間の同期がおかしくなった場合です。この場合完全に全ての最新の情報を救うのは絶望的になります。DC間の同期の正常性の確保は非常に重要です！

インストール シェル、プログラムはやはり「習うより慣れろ」です。早速インストールして触ってみましょう。 .NET Framework PowerShellは.NET Framework上で動作しますので、まずは.NET Frameworkを導入します。バージョンは.NET Frameworkの2.0以上が入っていればOKです。自分の環境に合うものを導入してください。 - [ダウンロードの詳細 : .NET Framework Version 2.0 再頒布可能パッケージ (x86)](http://www.microsoft.com/Downloads/details.aspx?familyid=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=ja) - [ダウンロードの詳細 : Microsoft .NET Framework 3.0 再頒布可能パッケージ](http://www.microsoft.com/downloads/details.aspx?familyid=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=ja) - [ダウンロードの詳細 : .NET Framework 3.5](http://www.microsoft.com/downloads/details.aspx?familyid=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=ja) PowerShell PowerShellはVista用のものとそれ以外用のものとで提供されているページが異なりますので、使用しているOSにあったものを導入してください。 - [ダウンロードの詳細 : Windows Vista 用 Windows PowerShell 1.0 インストール パッケージ (KB928439)](http://www.microsoft.com/downloads/details.aspx?familyid=C6EF4735-C7DE-46A2-997A-EA58FDFCBA63&displaylang=ja) - [Windows Server 2003 用および Windows XP 用の Windows PowerShell 1.0 ローカライズ版インストール パッケージ](http://support.microsoft.com/Default.aspx?kbid=926140) とりあえず触ってみる! get-command, get-help インストールが完了したら、とりあえず起動してみましょう。 コマンドプロンプトとほぼ同じようなウインドウが表示されます。派手さは全くありませんね･･･。CUIの最大の問題として、「で、何をしたらいいの?どんなコマンドがあるの?」と、起動したあと何をしていいかわからなくなってしまうことがあげられます。 が、PowerShellでは心配無用です。まずはいつもコマンドプロンプトで使っているコマンドをたたいて見ましょう。 上記はping www.google.comを実行してみたところですが、このように普通に実行できます。PowerShellでは通常のDosのコマンドは全て使えるのです。 これだけでは、コマンドプロンプトと同じですね。PowerShellならではのコマンドは何が使えるのでしょうか?これを知るためのコマンドが用意されています。その名もそのまま「get-command」コマンドレットです。 ...

PowerShellとは PowerShellはマイクロソフトがWindows環境で提供する最新のシェルです。対話型のシェルとしても使えますし、スクリプティング環境としても使えます。本格的にオブジェクト指向を取り入れていますし、.NET Frameworkを利用することができるので、かなり強力な環境です。C#でできることなら何でもPowerShellでできるわけですね。 また、さまざまな環境で利用できます。Windows XP, Windows Server 2003以降のすべてのOSで利用できますし、Windows Server 2008以降であれば(おそらくすべてのOSに)標準搭載されます。 また、「スナップイン」を追加することでできることがどんどん増えていきます。マイクロソフトはExchange Server 2007以降のサーバー製品はすべてPowerShellのスナップインを提供する意向を表明しているので、Exchange Server 2007以降に登場するすべての製品のすべての操作がPowerShell上から行えることになります。 PowerShellの何がいいのか これは、管理者にとってはものすごく大きな変化です。サーバーを導入して、設定を変更して…ということを今までは(ほぼ)すべてGUIで行っていました。これがWindowsの長所であったのですが、同時に短所でもありました。設定値がどうなっているか知りたかったら、GUIツールですべての項目をクリックしてまわって調べないといけませんでしたし、同じ環境を作ろうと思ったら、すべての設定を全部記録しておいて、それを一からすべてGUIツールをつかってマウスでカチカチ設定して回らなければいけませんでした。 それがPowerShellに移行されれば、PowerShellのコマンドを全て記録しておくことで設定の履歴を残すことも非常に簡単ですし、たとえば検証環境で実行したコマンドを本番環境で流し込むだけで構築完了、というようなこともできるようになります。設定が一部漏れていて、検証環境と本番環境で挙動が異なってしまい、すべてのパラーメーターを確認し直す…というようなことが頻繁にあった今までのことを考えると夢のような話です。 また、今までGUIツールで手作業でやっていたら1日かかっても終わらないようなことも、PowerShellなら1行で簡単にできるのが当たり前です。「Exchangeのメールボックスのうち、使用容量が80%以上のメールボックスで、かつきちんと使われているもの(最終ログオン日時が1週間以内のもの)だけ、メールボックスの容量を1.5倍にして」なんて言われて、それをGUIツールでやろうと思ったら、10個、20個ならいいですけど、100個、1000個、1万個に対して…となったらもう手作業ではやっていられませんよね?PowerShellならコマンドを1行書けばおしまいです。 いつからPowerShellが活躍するのか 惜しいのは、Windows Vistaで標準搭載にならなかったことですね。WSHの時もそうでしたが、サーバーはいいとしても、結局クライアントの管理を全てPowerShellで完結させようと思ったら、やはり標準搭載の環境でなければハードルが高すぎるのです。これが現在でもまだDOSが使われている一番大きな原因でしょうし、WSHが便利な理由です。そういう意味ではWindows Server 2008、Windows 7からPowerShellが標準搭載されるのは非常に嬉しいことです。 サーバー管理ではすでにPowerShellが使いこなせることはすでに必須条件になりつつあります。クライアント管理に関してはまだまだ先の話にはなると思いますが、数年後にはPowerShellが当たり前の時代が来ると私は思っています。いまのうちからPowerShellに馴染んでおくのがWindows管理者として今後も活躍できるための必要条件になると思います。 ということで、このブログでもPowerShellのことも書いていこうと思っています。お付き合いください。

レイヤ2においてはまずMACアドレスを意識することが重要だという話をしました。 - 参考：[レイヤ2 –データリンク層- 宛先はMACアドレス](https://windowsadmin.ebisuda.net/2009/02/12/%e3%83%ac%e3%82%a4%e3%83%a42-%e3%83%87%e3%83%bc%e3%82%bf%e3%83%aa%e3%83%b3%e3%82%af%e5%b1%a4-%e5%ae%9b%e5%85%88%e3%81%afmac%e3%82%a2%e3%83%89%e3%83%ac%e3%82%b9/) MACアドレスを理解したら、次に理解したいのはリピータハブとスイッチングハブの違いです。 リピータハブで接続されたネットワーク上の通信 まずは復習です。リピータハブで接続されているネットワークでは大まかに以下のような動きをします。 - コンピューターが通信を行う - NICがデータを受け取り、宛先MACアドレスをセットする(レイヤ2) - NICが電気信号としてデータを流す(レイヤ1) - リピータハブは電気信号をそのまま伝える(レイヤ１) - **リピータハブは受け取った電気信号を全ポートにそのまま流す(レイヤ1) ** - (別のコンピューターの)NICが電気信号を受け取る(レイヤ1) - **受け取るべきフレームであるかどうかをMACアドレスを元に判断する(レイヤ2) ** - 受け取るべきであれば上位層にデータを渡す。受け取るべきフレームでなければ破棄する。(レイヤ2) ここでのポイントは、5と7の動きです。リピータハブは全ポートに電気信号をそのまま流すので、リピータハブにつながっている全PCで受信してしまいます。PC-1からPC-2への通信をしているときに、その全てが他のコンピューターにまで全部届くのです。１GBのファイルをコピーするとしたら、まったく無関係なのに1GB分のデータが流れてくるのです。これは非常に無駄ですし、ネットワークがすぐに混雑してしまいます。 本来、PC-1宛ての通信であればPC-1だけに届き、PC-2宛ての通信であればPC-2だけに届いてくれさえすればいいのです。 スイッチングハブの動き で、これを実現してくれるのがスイッチングハブです。結局必要なコンピューター(=ポート)にだけ、電気信号を流してあげればいいわけです。コンピューター(NIC)が7で行っていることをスイッチングハブもしてあげればいいわけです。 はい。あとは考えればどうしたら良いのかは考えれば分かると思いますので、考えてみてください。 [問題]スイッチングハブはどのような動きをするでしょうか? 考えましたか?間違っていたとしても、きちんと自分の頭で考えてみることで血肉になっていきますのできちんと考えてくださいね。 スイッチングハブの動作 - MACアドレステーブル 「スイッチングハブがフレーム内の宛先MACアドレスを見て、そのMACアドレスがつながっているポートにのみ電気信号を流せばいい。」のですが、それでは「どのポートにどのMACアドレスがつながっている」ということはどのように把握できるでしょうか。 これを実現するために、スイッチングハブには「MACアドレステーブル」が備わっています(Arpテーブルとは別物ですので注意)。どのポートの先にどんなMACアドレスがあるかを記憶しておくわけです。 以下はスイッチングハブの気持ちになって一緒にMACアドレステーブルを更新してみましょう。 まずポート1からフレームが流れてきました。フレームにはもちろん送信元MACアドレスが書いてありますから(ここではMAC Aとしましょう)、ポート1の先にはMAC Aがある、とMACアドレステーブルに書き留めておきます。 ポート1 MAC A 流れてきたフレームにはもちろん宛先MACアドレスも書いてあります(ここではMAC Bとしましょう)。MAC B宛のフレームはどのポートに流せばいいでしょうか?MACアドレステーブルを見てみると、MAC Bがどのポートの先にいるかはわかりません(まだ学習していません)。ですから全てのポートに対してとりあえず流します。この「全てのポートに対してフレームを流す」という動作を「フラッディング」と言います。 MAC Bの持ち主は実際にはポート2の先にいたとしましょう。全ポートに対してフラッディングしましたので、もちろんポート2の先にいるコンピューター(NIC)もフレームを受け取ります。その上で宛先MACが自分宛ですから受け取って上位層に渡し処理をしてもらいます。ここでは、お返事をする必要があったことにしましょう。 (スイッチの気持ちになって。)今度はポート2からフレームが流れてきました。送信元MACアドレスはMAC Bです。MACアドレステーブルに書き留めておきます。 ポート1 MAC A ポート2 MAC B 流れてきたフレームの宛先MACアドレスはMAC Aになっています。MAC Aはポート1の先に繋がっていることを知っているので、ポート1のみにフレームを流します。 ・・・。 文字だけで書くとかなりわかりづらいですが、このようにフレームから「送信元MACアドレス」を読み取り、それをポートに対して対応付けておくことで、次回以降の通信の際には宛先MACアドレスを見て必要なポートにのみフレームを流すことができる。これがスイッチングハブの動作です。 ちなみに明示的にブロードキャストを要求された場合(宛先MACアドレスがFFFFFFの場合)にはきちんとフラッディングしてくれるので大丈夫です。 MACアドレステーブルはいつまで覚えているのか? でも、ちょっと待ってください。それは確かにあるときは1つのポートに繋がっているでしょうけど、そのうちポートを変更するかもしれません(座席移動などで)。そうなると、必要なフレームが必要な場所に流れてこないのではないでしょうか? この疑問は正しくて、MACアドレステーブルが更新されないとフレームは流れてきません。なので、きちんとMACアドレステーブルが更新される以下のような仕組みが備わっています。 - 一度覚えたMACアドレスは一定時間たつと消える - 学習済みのMACアドレスからのフレームが別のポートから入ってきたら、既存のものを消し、新しいポートに学習しなおす 基本的には何も考えなくてもポートを差し替えただけで繋がりますが、何かおかしいと思ったときにはMACアドレステーブルをチェックするということを発想できるようになりましょう。 ...

※今回は番外編です。メーカーの保障も私の保証もありません(笑)。 バックアップソフトウェアって、リストアソフトウェアじゃないよね 私が思うに、「バックアップソフトウェア」は、あくまでも「バックアップ」用であって、「リストア」用ではないです。メーカーの出しているマニュアルの手順どおりに操作を行っても「バックアップしたとおりには戻らない」「導入している製品ごとに個別にリストア手順を確立する必要がある」というのが当たり前です。フルバックアップしたものをフルリストアしても動かないなんてひどいじゃないですか。 一方、素敵にバックアップが取得できて、素敵に戻ってくれるのがディスクイメージングツールです。そもそも別OSで立ち上げて、ディスクイメージを取っているわけですから戻らないわけが無いんですけどね。でも、これだと、サーバーに必ずダウンタイムを作らなくてはいけないし、自動化もかなり難しいので、実運用に乗せるのは特殊なケースを除いてかなり厳しいでしょう。 イメージングツールの良い面と日々のバックアップツールの良い面を併せ持つすばらしいソリューションであるはずだった、オンラインでディスクイメージを取得するバックアップ製品。うまく動く場合にはいいのですが、はっきり言ってあちこちからトラブルの話ばかり聞こえてきます。しかもよくあるのはスナップショットドライバのバグでBSoDが発生するような致命的なものばかり。 究極のバックアップ方法 そんな中、私が知る限り必ず完璧に環境を戻してくれる素敵な手法があります。それは、「RAID1」です。 「『RAID1』ってHDDの冗長化の手法じゃなかったっけ?」というのは正しい反応なのですが、私が言っているのもそれです。同じ内容のディスクがあるわけですから、それがバックアップになっているのです。たとえば以下のようなときに使えます。 - 「あ、今の状態を取っておきたいな」と思ったらオンラインのまま(あるいはオフラインにしてから)1本引き抜く(バックアップ)。その後、別の新しいディスクを刺しておけばまた同期される。 - 「もしもうまくいかなかったらすぐに元に戻したいな」と思ったら、オンラインのまま(あるいはオフラインにしてから)1本引き抜く(バックアップ)。その後作業がうまくいけば抜いておいたディスクをそのまま指せばいいし、もしも作業がうまくいかなかったら一度オフラインにして、とっておいたディスクだけを刺して起動し、その後もう1本のディスクを指せばいい。 バックアップとずれますが以下のようなHDDコピー機としての使い方も。 - 同じハードウェア構成のサーバーを複数台構築するときに。1台を構築し、1本HDDを抜いて、新しいHDDを刺して、同期して、1本抜いて･･･を繰り返せばあっという間に複製完了 「いきなり引き抜いたら駄目なんじゃ?」と思う人もいるかもしれませんが、はっきり言っていきなりBSoDで落ちたときと同じレベルですし、昨今はきちんとファイルシステムレベルでジャーナル機能を持っているのでおいそれとおかしくはなりません。気になるならメモリの内容をフラッシュさせてから抜くなり、安全にやりたかったらオフラインで抜けば心配事は何もありません。 「単一で稼動するサーバーならそれでいいかもしれないけど、複数台で連携して稼動するようなシステムではだめだろう」と思う人もいるかもしれません。それは正しい指摘だとは思いますが、それでは世の中にあふれているバックアップソフトがそこまできちんと整合性を取ってバックアップ取得～リストアしてくれるでしょうか?･･･同じことだと思います。それに、どうしても完全に安全にやりたければ、関連するシステムを全部シャットダウンしたうえで、オフラインの状態でHDDを引っこ抜けばいいんです。この芸当はオンラインでバックアップを取得するソリューションでは不可能です。オフラインのイメージングツールでも同じことはできますが、やろうとおもったらRAIDのドライバが･･･とか色々面倒です。ディスク引っこ抜くのは一瞬です(笑)。 「OS部分はそれでいいかもしれないけど、データが外部ストレージにあるような場合はどうするんだ」と思う人がいるかもしれませんが、まさにデータ部分に対してこの手法を用いているのがディスクのクローニングの技術です。なぜ外部ストレージにあるデータにはディスクでのコピーを許容するのに、OS部分にはそれを使わないんですかね?矛盾して無いでしょうか? ･･･。 オンラインでディスクの同期を停止してもデーターの整合性がとられるようにVSSなどの技術があるわけなので、それとこれとは話が違うじゃないかと思うと思いますが、それは正解です(笑)。 冗談はともかく真面目な話 冗談はともかくとしても、私は真面目な話としてこのRAID1を使ったバックアップを、ロールバック案としてきちんと検討、採用していいのではないかと考えています。 たとえば、Active Directoryのスキーマ拡張作業。普通に作業をするだけなら10分で終わる作業です。CD or DVDを入れてコマンド一発です。ですが、マイクロソフトが「スキーマ拡張作業で何か問題が発生したときにはフォレスト全体に悪影響が及び復旧に多大な時間がかかる可能性があるから･･･」とかなんとか脅かして、“ベストプラクティス"としてまだるっこしい手順を大々的に宣伝してしまったものだからみんなビビッて10分の作業のために何時間も、何日も、準備をふくめて何ヶ月もかけるケースすらあります。(たとえばこの辺とかMicrosoft での構造化された Active Directory スキーマ管理) もちろん、それだけの危険性がある根拠があるのであれば(たとえば、勝手にスキーマを拡張しまくっていて本当にバッティングの恐れがある、とか)わかるのですが、スキーマはだれも自分たちではいじっていないし、ADとExchangeが入っているだけ･･･というような場合には問題が起きる可能性なんてありえないんです。だって全く同じことが世界中で行われていて、問題ないんですから。 なのに、まずステージングサイトを用意して、スキーママスタをステージングサイトに移動して、そこでまずアウトバウンドの複製をとめて･･･だの何だのやり始めてしまうのは全く持ってナンセンス。だと思うのです。まずやってみて、駄目だったら戻せばいいじゃないかと言いたいのです。 そうすると、「リストア手順の確立」とか、「復旧時間が」とかそういうまためんどくさい話になります。DCの場合には複製も考慮しないといけないので、さらにめんどくさい。 で、こんなときこそ私はこのRAID1でのバックアップをロールバック手段として使えばいいんじゃないかと思うのです。 - 全DCシャットダウン～HDD1本抜く - DC起動 - スキーマ拡張 - テスト - (テストOKなら)抜いてあったHDDをオンラインのまま指す - (テストNGなら)全DCシャットダウン～抜いてあったHDDを刺して起動 これでいいじゃないですか。これならDCの数にもよりますけど1時間もあればロールバック含めて完了するでしょう?戻らない可能性なんてほぼ無いでしょう?準備も必要ないでしょう? というわけで、今回は無責任なことを言って終わりにします。あまり真に受けないでください。

今回はWindows Serverをインストールしたあとで確認しておくべきことをまとめてみます。 i386フォルダの配置 i386フォルダというのはWindowsのインストールCD内にあるフォルダです。これがWindowsのインストラーの実態で、これさえあればWindowsコンポーネントの追加のときにCDを別途用意しなくてすみます。 i386フォルダを配置しておき、サーバーに対してSPを適用するときにはスリップストリームにてi386フォルダの内容も更新しておくことで、後日追加コンポーネントが必要になったときにSP適用済みのメディアがなくてあせるようなことになりません。 もちろんそれなりに容量をとりますので、別にサーバーのローカルディスクに必ず配置する必要があるわけではないですが運用形態によってはこのようなルールも便利だと思います。 ツールのインストール Support Tools マイクロソフト製のツールです。インストールCDやサービスパックなどの「\SUPPORT\TOOLS\SUPTOOLS.MSI」というファイルがSupport Toolsのインストーラーになっています。非常に便利なツールが多数入っていますので必ずインストールしておくことをお勧めします。(ツールの内容は別エントリで解説予定です。) Resource Kit Tools これもマイクロソフト製のツールです。昔は書籍にしかついていない時期もありましたが、今はWebからダウンロードできます。こちらも非常に便利なツールが多数入っていますので必ずインストールしておくことをお勧めします。(ツールの内容は別エントリで解説予定です。) 管理タスクの Windows 2000 リソース キット ツール Download details: Windows Server 2003 Resource Kit Tools adminpak こちらは必須というわけではないですが、自身のサーバーには導入されていないサービスだけれども、リモートサーバーを管理したい、と言うようなときにはadminpakを導入しておくと便利です。 インストーラーは「%windows%\system32\adminpak.msi」です。これを導入すると、管理コンソールのみすべて導入されます。 各種更新作業 ドライバ更新 ドライバはインストール時に自動的に適用されているはずですが、きちんとドライバが適用されているかどうかを確認し、必要があれば更新を行うようにしましょう。 基本的にドライバのアップデートは各サーバーベンダーから出ているドライバのバージョンを一括管理できるツールを使って行いますが、きちんとデバイスマネージャーを見て、異常が無いことを確認しておきましょう。 黄色の感嘆符が出ないようにしましょう。 Service Pack, Hotfix 基本的にはWindows Server構築時には最新のService Packを適用した上でさらに全てのHotfixを適用しておくべきです。台数が少なければ個別に適用するべきものがなくなるまでMicrosoft Updateを実行すればいいでしょう。 一度Service Packを実行して、再起動したあとで再度Microsoft Updateを実行する･･･というように何度も繰り返す必要がありますので注意してください。 Microsoft UpdateはProxy接続の環境ではうまく動かないことがあります。この場合にはInternet explorerでのProxy設定だけではなく、proxycfg.exeコマンドでProxyを設定、再起動の上で再度実行するとうまくいくことがあります。 自動構成スクリプトの指定方法によって Windows Update が失敗する 上でも述べましたが、SP適用済みの環境に対して、SP的用済みではないメディアからWindowsコンポーネントを追加してしまった場合には、再度SPの再適用が必要ですので気をつけましょう。必ずスリップストリーム済みのi386フォルダからコンポーネントを追加しましょう。 イベントログの確認 インストール後には必ずイベントログの確認を行いましょう。警告、エラーが記録されている場合には、必ずそれに対して対処を行い、問題が無い状態にしましょう。 エラーの解消には以下のようなサイトが有効です。 マイクロソフト サポート オンライン EventID.Net 中には出ていても問題のないエラーなども存在しますので、それもあわせて確認しましょう。 Windows FireWall 現在のWindows ServerではWindows FireWallが自動的に有効になります。なんらかのサービスを提供するサーバーであれば必ずそのポートは開放する必要がありますので、忘れずに設定しましょう。 また、場合によってはWindows FireWallは無効に設定するポリシーのところもあるでしょう、いずれにしてもきちんと目的に合った設定にしましょう。 ...

TCP/IPは現在Internetを支えるもっとも重要なプロトコルであり、Windowsでも標準のプロトコルスタックとして採用されています。Windows Server管理者としてはきちんと把握しておかなくてはいけません。 お勧めの書籍 入門書としては「マスタリングTCP/IP」がお勧めです。 マスタリングTCP/IP 入門編 第4版 竹下 隆史 村山 公保 荒井 透 苅田 幸雄 私も入社したてのころに先輩からこの本を手渡され、がんばって読み込みました。基本的な部分はこの本を読んで理解できれば抑えられます。 お勧めサイト Web上の情報としては以下のサイトもお勧めです。 3 Minutes Networking ちょっとゆるい感じなので好みが分かれるかもしれませんが、とっつきやすいと思います。私も駆け出しのころにずいぶんお世話になりました。 このサイトでも少しづつTCP/IPに関することも書いていきます。

今回はレイヤ2の話です。 レイヤ2と一口に言ってもPPPやHDLCやADCCP等多数のデータリンクプロトコルがありますが、まずはなんといってもイーサネットに関しての理解が必要です。 MACアドレス レイヤ2において色々と理解すべきことはありますが、まずは何と言っても「MACアドレス」を理解しなくてはいけません。大げさに言えば、私はMACアドレス、レイヤ2の概念をきちんと理解しているかどうかが素人とプロのまず大きな違いだと思っています。そのくらい重要です。 昨今ではTCP/IPが全盛なので、「コンピューターはIPアドレスを持っていて、IPアドレスを住所のように使って通信している」という理解をしている人が多いですし、確かにそれは間違いではありません。ですが、それはレイヤ3を考えた時の話です。レイヤ2で同じようなレベルで理解をするならば「NICはMACアドレスを持っていて、MACアドレスを住所のように使って通信している」ということになります。 「NIC」というのは「Network Interface Card」の略で「LANカード」などとも言われます。このNICに、MACアドレスというものが指定されているわけです。 MACアドレスを確認する 「IPアドレスは設定したことあるけど、MACアドレスなんて設定したことないよ?」という人も多いと思います。まずは自分が今使っているコンピューター(についているNIC)のMACアドレスを確認してみましょう。 コマンドプロンプトで「ipconfig /all」を実行してみてください。 「Physical Address. . . . . . . . . : XX-XX-XX-XX-XX-XX」という行があります。これがMACアドレスです。上の例だと「00-0F-B5-8E-0B-54」ですね。 このMACアドレスはメーカーが工場でNICを生産する際に埋め込みます。ですので基本的に私たちが設定するものではありません。(例外はありますがまずはこの理解でいいでしょう。) MACアドレスからベンダーを調べる このMACアドレスは重複しないようにメーカーごとに割り当てることができる範囲が決まっています。ですので、MACアドレスを見ればどのメーカーのNICなのかわかるようになっています。具体的にはMACアドレスの先頭24ビットがベンダーをあらわしています。具体的には以下のようなサイトで調べることができます。 IEEE Registration Authority - IEEE OUI and Company_id Assignments サイトに行って「Search the public OUI listing . . .」という項目に自分のNICのMACアドレスの先頭24ビットの値を入力して「Search!」して見ましょう。 上の例であれば「00-0F-B5」というのは「NETGEAR Inc」のNICであることがわかります。 フレームの構造 レイヤ2のレベルで考えたときには宛先、送信元にMACアドレスが入力され、Ethernetに電気信号として伝えられます。これの塊をレイヤ2では「フレーム」と呼びます。「フレーム」は以下のような構造をしています。 「プリアンブル」「タイプ」「FCS」などの理解はとりあえず後回しで大丈夫です。重要なのは「宛先MACアドレス」と「送信元MACアドレス」です。 原則としてEthernetでは全てのフレームが全てのコンピューターに届けられます。レイヤ1レベルではただの電気信号なので繋がっている全てのコンピューターまで届くわけです。NICはフレーム内の宛先MACアドレスが自分のMACアドレスと等しいかを確認し、自分宛のものであれば上位の層(具体的にはレイヤ3)にデータを渡す、という動きをします。(※例外あり、後述) どうやって通信相手のMACアドレスを知るのか では、何か通信をしたい時、送信元MACアドレスには自分が知っている自分自身のMACアドレスを入れればいいとして、宛先MACアドレスはどうしたらいいでしょうか?どうしたらわかるでしょうか? たとえばpingを考えてみましょう。「ping x.x.x.x」という形でコマンドを打つときには、宛先のipアドレスはコマンドを打つ人が入力してくれますが、このときにMACアドレスを入力するということはしません。 ですので、IPアドレスからMACアドレスを知る仕組みが必要になるわけです。NICの気持ちになって考えてみると「x.x.x.xのIPアドレスを持っている人MACアドレス教えて」という事をネットワークに流せばよさそうです。そしてMACアドレスを教えてもらう。このやり取りを**ARP(Address Resolution Protocol)**と言います。 ARPは正確にはレイヤ3に属するプロトコルなのですがレイヤ2のMACアドレスを理解するために重要なのでここで登場してもらいました。 ブロードキャスト ところで、「x.x.x.xのIPアドレスを持っている人MACアドレス教えて」という時には宛先MACアドレスには何を入れればいいでしょうか?宛先MACアドレスを知るための通信をするときの宛先MACアドレスです。 なかなか難しいですが、正解は「全員宛て」です。全員に通信を受け取ってもらって、受けとったコンピューターのうち、x.x.x.xのIPアドレスを持っているコンピューターからのみ返事をもらえればいいわけです。 このような「全員宛て」という意味で「FF-FF-FF-FF-FF-FF」というMACアドレスが使われます。先ほど「NICはフレーム内の宛先MACアドレスが自分のMACアドレスと等しいかを確認し、自分宛のものであれば上位の層(具体的にはレイヤ3)にデータを渡す」というように説明しましたが、より正確にはここで宛先MACアドレスとして「ブロードキャストアドレス(FF-FF-FF-FF-FF-FF)」やマルチキャストアドレス「01-00-5E…」であっても受け取って上位層に渡します。 MACアドレスだけではなぜいけないのか? さて、MACアドレスというものを知りました。宛先のアドレスはブロードキャスト、ARPを使って知ることができます。この仕組みだけあれば他にアドレスは必要ないようにも思います。なぜMACアドレスだけでは駄目なのでしょうか? 実際、昔Windowsネットワークで使われていたNETBEUIというプロトコルには他にアドレスは存在しません。NETBIOS名というものはつけますが、NETBEUIにおいてNETBIOS名はMACアドレスと一対一に対応付けられます。サブネットマスクだのデフォルトゲートウェイだのルーティングだの面倒なことはなにもありません。ネットワークに接続しさえすればきちんと通信できるのです。こっちのほうが楽でいいのではないでしょうか? この問いへの答えはブロードキャストのことを考えるとわかります。実際にデータを届けるには相手のMACアドレスが必要なわけですからブロードキャストするわけです。そのフレームは全コンピューターに届かなくてはいけません。これは小規模なネットワークなら問題にならないでしょう。ですが、今日最大のネットワークであるインターネットではどうでしょうか? インターネット上の全てのコンピューターの発するブロードキャストが全てのコンピューターが受信する必要があるとしたら、おそらくブロードキャストパケットだけでネットワークは飽和してしまうでしょう。 ...

今回は「NETBIOS名」と「ホスト名」について解説します。「NETBIOS名」と「ホスト名」が混ざってしまいよく理解できていない人はかなり多いです。いざという時のトラブルシュートで差が出ますのでしっかり理解しましょう。 Windowsネットワークの歴史 NETBEUIの時代 「NETBOIS名」のことをよく理解するためにはWindowsネットワークの歴史を知らなくてはいけません。 まず、今のTCP/IP全盛の時代からすると信じられないかもしれませんが、初めてWindowsにネットワーク機能が標準搭載されたWindows95では規定のプロトコルはTCP/IPでは無くてNETBEUIというものでした。そしてNETBEUIはNETBIOSというAPIを利用しています。 NETBEUIはTCP/IPとは全く異なる考え方のプロトコルです。IPアドレスなんてありません。ルーティングもしません。名前だけ決めておけばアクセスできる。そんなプロトコルです。考え方は非常にシンプルです。 このNETBIOSのAPIを利用するために「コンピューターにつける名前」が「NETBIOS名」です。 Windows95, 98の時代にはコンピューターにコンピューター名(=NETBIOS名)だけつけておいて、あとはEthernetで接続(レイヤ1で接続)だけしておいてあげれば「\コンピューター名」という形式で他のコンピューターにアクセスしてファイル共有やプリンタ共有を利用することができました。 「NETBEUI時代に使っていたコンピューター名」が「NETBIOS名」です。 NETBEUIの限界 NETBEUIは現在ではほぼ使われていません。なぜ使われていないのかというと以下の点で現在のネットワーク環境に合わなくなってしまったからです。 - ルーティング機能が無いため大規模なネットワークには向かない - インターネットが普及し、NETBEUIとの相互接続性に問題がある 95, 98の時にはファイルやプリンタの共有のためにはNETBEUIプロトコルを使って、インターネット接続にはTCP/IPを使って･･･と、複数のプロトコルスタックを使うようなこともありました。今では用途別に複数のプロトコルスタックを使い分けるということはもうほぼありません。 TCP/IPへの移行 Windowsネットワークもインターネット普及の流れに乗るためにTCP/IPを標準のプロトコルに採用します。時代の流れです。ですが、単純にTCP/IPに移行してしまうと今まで使っていたNETBIEUI+NETBIOSのAPIをつかったWindowsファイル共有やプリンタ共有が使えなくなってしまいますし、Windowsネットワークの特徴であった「とりあえず名前だけ決めておけば繋がる」という利点が失われてしまいます。 そこでマイクロソフトがとったのはTCP/IPの上でNETBIOSのAPIを使えるようにする、という戦略です。これをNETBIOS over TCP/IPといいます。TCP/IP上でNETBOISを使えるようにしたわけです。これにより、NETBIOSのアプリケーションそのままに、TCP/IPを使って複数セグメントに分かれた大規模なネットワークにも対応可能になりました。 このNETBIOS over TCP/IPの機能があるため、何も設定していない状態で「ping コンピューター名」に応答が返ってくるわけです。 複数セグメントになったことで起きる問題 NETBIOS over TCP/IPによって複数セグメントに対応し、大規模なネットワークに対応できるようになりました。ですが、もともとNETBEUIは「ブロードキャスト」を多様することで簡単に接続できるようになっていたため、複数セグメントに分かれてしまうとNETBIOSのAPIがきちんとネットワーク全体で使えない、という問題が出てきてしまいます。 この問題を解決するために、セグメントを越えるために、出てきた技術がWINSです。各コンピューターがNETBIOS名とIPアドレスの対応付けをWINSサーバーに登録しておき、利用したい場合にはWINSサーバーに問い合わせることで、セグメントを越えることができるようになりました。 また、lmhostsファイルというファイルにもNETBIOS名とIPアドレスの対応付けを書くことができるようになっています。 WINSサーバーを使うかlmhostsファイルにそれぞれ記述することでセグメントを越えることが出来るようになっています。 NETBIOS名 ここまで見てきたようにNETBIOS名というのはもともとTCP/IPとは別のNETBEUIというプロトコルスタック上で使われていた名前です。WindowsがNETBEUIからTCP/IPに乗り換える際に、過去の遺産を持ってきた、そういう構造になっています。ですからはじめからプロトコルスタックにTCP/IPを採用していたUNIX系のOSではNETBIOS名という考え方は存在しません。 基本的には自分のNETBIOS名をコンピューターは知っていて、それが(ブロードキャストで)呼ばれたら変事をするような仕組みになっています。 UNIX系ネットワーク(TCP/IP)の歴史 hostsファイル TCP/IPでは他のコンピューターと通信する際にはIPアドレスを利用します。 IPアドレスを人間が全て記憶することは難しいため、hostsファイルにIPアドレスとそれにつけるコンピューターの名前(=ホスト名)を記述し、管理していました。全てのコンピューターにhostsファイルを記述する、というのがもっとも原始的な形態です。 個別のhostsファイルにホスト名とIPアドレスの対応付けを全て記述していたのでは、ネットワークにコンピュータが1台増えただけで、既存のコンピューター上の全てのhostsファイルを更新して回る必要が発生してしまいます。同じようにIPアドレスを変更したい、ホスト名を変更したいと思った場合も同様です。 このようにhostsファイルだけでは小規模なネットワークならともかく、大規模なネットワークでは事実上管理できません。 DNS hostsファイルの問題を解決する仕組みとして考え出されたのがDNSです。クライアントはDNSサーバーに問い合わせて、ホスト名とIPアドレスの変換を行います。 ただし、この際に単純にhostsファイルに記載されていたものをDNSサーバー上に登録しただけでは何百、何千、何万というレコードを1台のサーバーで管理しなくてはいけなくなります。DNSはインターネット上でも使われていますが、インターネット上のホストとなると何百万、何千万、何億という単位です。これを1台で全て管理したり、冗長化のために複数台にコピーしたり、というのはかなり効率が悪いです。 さらにもしかしたら全く同じ名前を持っているホストが存在しているかもしれません。この場合どちらかのレコードのみを登録するわけにもいきませんのでどちらかの名前を変更しなくてはいけなくなってしまいます。 そこでDNSには、このような問題を解決するためのしくみとして、「ドメイン」という概念が導入されています。「ドメイン」ごとにレコードを管理し、ホスト名のあとにドメイン名までつけて1つのホストを表します。たとえばこのブログが稼動しているサーバーはdyndns.bizというドメイン上のebiというホストです。ebi.dyndns.biz.というのが完全修飾ドメイン名(FQDN)になります。(※完全修飾ホスト名とは言わずに、完全修飾ドメイン名といいます。) ちなみにWINSにはこのような「ドメイン」という考え方は存在しませんので上記の問題をそのまま抱えています。ですので、マイクロソフトもWINSには見切りをつけていて、廃止の方向に向かっています。 ホスト名 見てきたように「ホスト名」はhostsファイルおよびDNSにて管理され、ドメインという概念を含んだものです。 NETBIOS名とは異なり、自分のホスト名に対してそのIPアドレスを返答するような仕組みは備わっていません。 Active DirectoryでDNSを導入 マイクロソフトはWindows2000でActive DirectoryというWindowsネットワークを管理する新しい仕組みを導入し、その中で名前解決の仕組みにDNSを導入します。ここから本格的にWindowsネットワークでもTCP/IP+DNSという仕組みを採用したわけです。 ですが、過去の資産を継承するためにNETBIOSの仕組みも存続させます。NETBIOS over TCP/IPも搭載していますし、NETBIOS名の名前解決の仕組みとしてWINSも健在です。 このようにして、WindowsネットワークはNETBIOS名とホスト名が混在するややこしい状態になりました。 ポイント - lmhostsファイルとhostsファイル、WINSとDNSとが技術的には対応付けられる。ただし、その技術が必要となってきた経緯は異なる。 - ホスト名はTCP/IP,Unixの文化から来ている。 - NETBIOS名はNETBEUI(プロトコルスタック)+NETBIOS(API)という過去の技術を継承しているために残っている。TCP/IPへとプロトコルスタックを変更する際にNETBIOS over TCP/IPという技術が導入され、これによりTCP/IPネットワーク上でNETBIOS(API)が利用できる。 - NETBIOS名とホスト名が混在しているのはWindowsネットワークだけ。 参考 - [Insider's Computer Dictionary [NetBEUI] － ＠IT](http://www.atmarkit.co.jp/icd/root/14/5787514.html) - [DNSの仕組みの基本を理解しよう](http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns01.html) - [＠IT：基礎から学ぶWindowsネットワーク](http://www.atmarkit.co.jp/fwin2k/serial/index/index.html#baswinlan)

今回の話題はWindowsネットワークに関してです。まずは一番基本的なところから、ということで2台のWindowsPCをネットワークで接続することから始めます。 まず接続する(レイヤー1) まず2台のPCを接続する必要があります。接続するには主に以下のような方法があります。 ハブ(スイッチングハブ、あるいはリピータハブ)を用意し、それぞれのPCをハブに接続する。ケーブルにはストレートケーブルを使う。 クロスケーブルを使い、2台のPCを直接接続する。 それぞれ無線LANのアクセスポイントに接続する。 どの方法でも構いません。下位レイヤに上位レイヤが無影響でいられるところがOSI参照モデルのメリットです。(参照：OSI参照モデルとTCP/IP) APIPA(Automatic Private Ip Addressing)を理解する 接続がすんだら次はネットワークの設定…なのですがその前に今の状態を確認してみましょう。 何もネットワークの設定をしていない状態で以下のコマンドを実行してみてください。 ping もう一台のコンピューター名 どうでしょうか?何も設定していないのにpingに応答があったと思います。(応答がない場合には後述する「通信できない原因」を参照してください)もうちょっと見てみましょう。「スタート」→「ファイル名を指定して実行」にて「\もう一台のコンピューター名」を入力してみてください。結果は環境やパスワードの設定などによって異なるのですが以下のような挙動のはずです。 パスワード入力を求められた コンピュータに接続でき、ウインドウが開いた さらに言うと、「マイネットワーク」を開いて適当にたどってもらうと、そこにもう一台のコンピューターも表示されているはずです。表示されるまでには時間がかかるのでまだ表示されていないようであれば10分程度待ってからもう一度表示してみてください。 つまり、何も設定していないのにもうネットワーク的に接続されていて、しかも、コンピューター名をお互いに認識できているわけです。Windowsは知識がないユーザーのために「とりあえず刺せば繋がる」ようになっているわけですね。 このときネットワークの設定はAPIPAという機構が働いて設定されています。アドレスは169.254.0.0/16の範囲から重複しないように選ばれます。ipconfig /allで設定を確認することができます。 この機能、親切だし便利ではあるのですが「設定されるまでに時間がかかる」「インターネットには接続できない」という致命的な問題もあり、実際にはよく分かっていない人がわけもわからず使ってしまっていることをのぞけばまず使われていません。 ネットワークの設定をする(レイヤー3) では、きちんとネットワークの設定をしていきましょう。現在はTCP/IPがデファクトスタンダードですので、WindowsのネットワークにおいてもTCP/IPの設定をすることになります。設定は以下の手順で行えます。 「マイネットワーク」を右クリック→「プロパティ」→「ローカルエリア接続」(※使用するネットワークアダプタ)を右クリック→「プロパティ」→「インターネットプロトコル(TCP/IP)」→「プロパティ」 ここで2台のコンピューターのネットワーク設定を以下のように設定します。 同一のネットワーク 重複しないIPアドレス 今はプライベートなネットワークを作ろうとしていますのでIPアドレスとしてはプライベートIPアドレスを設定すべきです。具体的には以下のアドレスの範囲から選択します。 範囲 サブネットマスク 10.0.0.0 - 10.255.255.255 255.0.0.0 172.16.0.0 - 172.31.255.255 255.240.0.0 192.168.0.0 - 192.168.255.255 255.255.0.0 実際には2台であれば192.168.1.0/24のネットワークを使って、192.168.1.1, 192.168.1.2というIPを割り当てることが慣習的に多いです。 しかし、上記のプライベートIPアドレスの範囲であれば何を使っても構いません。さらに言うと上記のプライベートIPアドレスの範囲を超えてグローバルIPアドレスの範囲を使っても通信は問題なく行えます。ただし、特殊用途のIPアドレスとして割り当てられている範囲もあるため、適当に設定すると通信できないこともあり得ますので、素直にプライベートIPアドレスを使うべきでしょう。 デフォルトゲートウェイとサブネットマスク このとき、デフォルトゲートウェイとDNSサーバーに何を入れればいいのか迷うかもしれませんが、今回の構成ではネットワーク上に存在しないわけですから何も入力しなくて構いません。あるいは何か適当なIPアドレスを入力しても構いません。このような構成は検証環境等ではよくあります。 ここでひとつ注意点です。たまにデフォルトゲートウェイに値が入っていないと正常に動作しないアプリケーションがありますので注意してください。(単にソフトウェアのつくりが悪いだけなのですが) 例：Outlook 2007 と Exchange Server の接続を試みたときに、エラー メッセージ “アクションを完了できません。Microsoft Exchange Server への接続が利用できません” または “Your Microsoft Exchange Server is unavailable” が表示される 通信してみる ここまででWindowsネットワークの設定が完了しました。 ...