いやあ、この間、SQL Server につながらないときの Windows ファイアウォールの設定について書いたんだけど・・・ごめん、嘘でした。
あれ、通信の方向が逆ですわ。自分が SQL Server のホスト機をする時の設定ですな。今回は自分はクライアントなので、設定するところは別。
一応、何でそんな誤解をしてしまったのかというと、Windows フィアウォールって、設定しても、すぐにはその設定が有効にならんよね？
例えば、ファイアウォールを「無効」にしてて、それを「有効」にしても、しばらくパケットだだ漏れなのよ(^^;
しばらくすると「有効」になって、突然通信ができなくなったりするんだけど。そのため、色々やった中の、どの設定が「効いた」のかわかんなかったのよ・・・ごめん。
実際には、Windows ファイアウォール（firewall.cpl）を実行して、（[詳細設定]タブではなく(^^;）「例外」タブを開き、
名前：SQL Serverポート番号：1433プロトコル：TCP名前：SQL Server Browser サービスポート番号：1434プロトコル：UDP
を追加。
ここまでは、（設定する場所間違えてたけど(^^;）前回の設定と一緒。
問題は、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 に接続出来るようになるぞ！！
ま、そういうことやってる人、あんまりいないと思うけど（笑）
