いやあ、この間、SQL Server につながらないときの Windows ファイアウォールの設定について書いたんだけど・・・ごめん、嘘でした。

あれ、通信の方向が逆ですわ。自分が SQL Server のホスト機をする時の設定ですな。今回は自分はクライアントなので、設定するところは別。

一応、何でそんな誤解をしてしまったのかというと、Windows フィアウォールって、設定しても、すぐにはその設定が有効にならんよね？

例えば、ファイアウォールを「無効」にしてて、それを「有効」にしても、しばらくパケットだだ漏れなのよ(^^;

しばらくすると「有効」になって、突然通信ができなくなったりするんだけど。そのため、色々やった中の、どの設定が「効いた」のかわかんなかったのよ・・・ごめん。

実際には、Windows ファイアウォール（firewall.cpl）を実行して、（[詳細設定]タブではなく(^^;）「例外」タブを開き、

を追加。

ここまでは、（設定する場所間違えてたけど(^^;）前回の設定と一緒。

問題は、SQL Server ホストの名前解決に「NetBios による名前解決」が行われていること。

IP アドレスや、DNS で解決したホスト名ではなく、今回設定を行っているシステムでは俗に言う「コンピュータ名」で SQL Server に接続を行っている。その名前解決に、「ファイルとプリンタの共有」で使われる 137, 138, 139 といったポートが使われるのだ。NetBios だからな。

いや、それはわかっていたのだ。だから、「例外」タブを開いて、ちゃんと「ファイルとプリンタの共有」を例外としてチェックしていたのだ。

しかし、それだけでは足りなかった(^^;

うっかりしてたけど、Windows Virtual PC ってホスト OS とは「ルータ接続」なんだよね。

例えばホスト OS が「192.168.100.21/24」なネットワークでも、ゲスト OS である Windows XP 側は「192.168.131.65/24」とか、全然別のネットワーク（サブネット）に所属してるんだよね。

だから各ポートを「どのネットワークに対して例外とするか」をちゃんと設定してやらないといけないのだ。

なぜなら、「ファイルとプリンタの共有」のためのポートは、そのスコープが「ユーザのネットワーク（サブネット）のみ」になっているのであります。

だから、192.168.131.0/24 というサブネットに属している Windows XP から、192.168.100.0/24 という別のサブネットに属している SQL Server への137ポート行きのパケットは Windows ファイアウォールで止められてしまうのであーる。

ということで、今回の設定のキモは、「137, 138, 139 ポートのスコープの変更を行ってやること」だった(^^;

「サービスの編集」画面で対象のポート（名前）を選択し、「スコープの変更」ボタンを押そう。「ユーザにネットワーク（サブネット）のみ」にチェックが付いているはずだ。これを、「任意のコンピュータ（インターネット上のコンピュータを含む）」に変えよう。

これで、君の Windows XP Mode から無事 SQL Server に接続出来るようになるぞ！！

ま、そういうことやってる人、あんまりいないと思うけど（笑）