及川です。

MUI、MUI 続き?と２つの投稿を最近行いましたが、想像以上に、皆様に興味を持って読んでいただけたようです。

タイミング良く、さらに詳しい内容については、新しい Windows SDK として公開されていることが本社の Michael Kaplan のブログでアナウンスされています（Its a whole new way to look at MUI）。

従来は NLS（National Language Support）のセクションで MUI についても触れられていましたが、新しい SDK では International Text Display というセクションの下で NLS と MUI の両方が並列に扱われるようになり、情報量も大幅に増加されています。

この MUI の下では以下のようなことが解説されています。MUI についてさらに詳しいことをお知りになりたい方、MUI 対応のアプリケーションの開発を行いたい方はどうぞご覧ください。

マイクロソフト
及川卓也

及川です。

IE7 ベータ２をリリースしてからしばらく経ちますが、おかげさまで、多くの方にダウンロードしていただき、評価していただけているようです。皆様のご協力に感謝します。Windows Vista ベータ２もすでにリリースしていますが、こちらもさらに多くの方にお試しいただけるように、現在手配中です。

ベータ版は、皆様に製品のリリースに向けて準備を進めていただくことも目的としておりますが、同時に製品開発チームとしては少しでも不具合を無くし、使い勝手を高めることために、皆様からの忌憚のないご意見をいただくことを期待しています。

製品の仕様の決定については、さまざまなマーケットリサーチ手法を用い、ユーザーの方のニーズを把握させていただき、行わせていただいています。これは多くの場合、製品開発のフェーズのかなり早い段階で行います。しかし、実装が進み、ベータの段階に入ってからも、細かい点でどのような動作がユーザーの方に満足していただけるかで、悩むことがあります。ベータプログラムに入られている方はご存知だと思いますが、このような場合、われわれ開発チームはベータユーザーの方にアンケートをとらしていただくことがあります。アンケートの結果ですべてを決めるわけではありませんが、その結果を最大限尊重し、慎重に仕様を決定することになりますので、もしアンケートの依頼がいきましたら、積極的にご参加いただくようにお願いいたします。

また、以前のベータプログラムと今回の Windows Vista のベータプログラムで、ユーザーの方の声を把握する方法は大きく変わりました。たとえば、このブログもユーザーの方とをつなぐ重要なインフラです。トラックバックやコメントでいただいた声はすべて目を通しています。さらに、このサイトをご覧になる方のアクセス解析もある程度行えますので、同じリファラから多くの方がアクセスしている場合には、そのアクセス元を拝見させていただき、どのようにこのブログの投稿を参照していただけているのかを見させていただいています。時間があるときには、ブログ検索エンジンで IE7 や Windows Vista というキーワードを検索し、IE7 や Windows Vista をお使いになられている方の感想などを拝見させていただくこともあります。

これらは以前のベータプログラムではできなかったことです。ブログをはじめ、個人の方が情報発信をするようになった結果、できるようになった新たなユーザーの方とのつながり方でしょう。ベータプログラムも時期や内容によっては、守秘義務など微妙な問題もあり、どこまでユーザーの方にオープンに発言していただけるかは難しい問題ですが、できるだけ皆様にオープンに発言していただけるようなカルチャーは大事にしていきたいと思います。

ということですので、今後も、もし本ブログの投稿が皆様の琴線に触れましたら、是非遠慮せずにコメントやトラックバックしていただければと思います。

これからもよろしくお願いします。

マイクロソフト
及川卓也

及川です。

Windows Vista の IPv6 サポートの話は何度かしているのですが、整理して話したことがありませんでした。お約束していたにも関わらず、大変失礼しました。今日は、Windows Vista および Windows Server "Longhorn" の IPv6 サポートについて概略を解説します。

IPv6 は既定でインストールされ、有効であり、そして優先して使用されます

Windows XP や Windows Server 2003 までの IPv6 はプロトコルスタックの追加インストールが必要でした。Windows Vista（Windows Server "Longhorn" も含む。以下同じ）では違います。既定の状態でインストールされ、逆に GUI から簡単にアンインストールすることはできなくなっています。

また、アプリケーションもマイクロソフトが推奨するインターフェイス、たとえば、.NET Framework や上位 API をお使いの場合には、IPv6 がそのまま使えるようになっています。WinSock アプリケーションの場合もプロトコルを意識しない関数（Address Agnostic API）を使う場合には、IPv6 がそのまま使えます。さらに、IPv4 および IPv6 が両方使える場合は、IPv6 が優先して使われるようになっています。

この方針はたとえば DNS の名前解決の際にも適用されます。DNS に名前解決する際、A レコードと AAAA レコードの両方を問い合わせますが、AAAA レコードが返ってきた場合には、AAAA レコードが優先して使われます。

デュアル IP 層アーキテクチャ

Windows XP（Windows Server 2003 を含む。以下同じ）では、IPv4 と IPv6 で異なるプロトコルドライバが使われていました。具体的には %windir%\system32\drivers にある tcpip.sys（IPv4用）とtcpip6.sys（IPv6用）です。このため、これをデュアルスタックアーキテクチャと呼びます。IPv4 と IPv6 では同じフレーミングのサポートや TCP & UDP のサポートがあるにも関わらず、別の実装がそれぞれのプロトコルドライバで行われていたのです。

Windows Vista ではこれがデュアル IP 層アーキテクチャに変更されます。１つのプロトコルドライバ（tcpip.sys）には共通の TCP & UDP のサポートとフレーミングのサポートが含まれ、唯一 IP 層の部分だけが、プロトコルドライバ内で異なる実装になっています。

Windows Vista の IP スタックは１から書き直されており、パフォーマンスも劇的に向上していますが、そのメリットは IPv4 だけでなく、IPv6 にも適用されています。

GUI による構成

Windows XP での IPv6 の構成は netsh で行うコマンドラインのものが唯一のものでしたが、Windows Vista からは GUI により IPv6 の構成（アドレス設定なども含む）が行えるようになっています。

Windows XP で実装されていなかった基本機能のサポート

Windows XP ではいくつか実装されていなかった IPv6 の機能がありましたが、それらのほとんどが Windows Vista では実装されています。代表的なものを以下に列挙します。

• DNS トランスポート: Windows Server 2003 では実装されていましたが、Windows XP では DNS の問い合わせが、たとえ AAAA レコードの問い合わせであっても、すべて IPv4 で行われていました。これにより、ピュア IPv6 の環境では DNS への問い合わせができないという問題がありました。Windows Vista ではこれがきちんと実装されています。
• IE での IPv6 リテラルアドレス: IE で URL のアドレス部分に IPv6 アドレスを利用できないという制限がありました。Windows Vista ではこれが解決されています。
• IPsec のサポート: Windows XP では IPv6 用の IPsec がサポートはされているものの、IPv4 用の IPsec と異なり、コマンドライン（それも netsh ではない独自コマンドラインツール）でのみ構成可能であり、さらに IKE がサポートされていませんでした。また、ESP において NULL 暗号化しかサポートされておらず、実質ペイロードに暗号化ができない実装となっていました。Windows Vista の IPsec では IPv4 と IPv6 の差はありません。GUI（MMCのスナップイン）において IPv6 用の IPsec も構成できるようになっていますし、IKE のサポートも、ESP での暗号化もサポートしています。
• MLDv2 のサポート: MLDv1 に加えて、MLDv2 もサポートします。
• PPP のサポート: PPP において IPv6 がサポートされるようになります。具体的には IPCP に加えて、IPV6CP がサポートされます。
• DHCPv6 のサポート: Windows XP のリリースのタイミングでは間に合わなかったのですが、今回は DHCPv6 がクライアントとサーバーともサポートされます。また、ISP の IPv6 接続サービスを利用する場合、ブロードバンドルーターに DHCPv6PD でプレフィックスを取得し、ルーターが RA を発行するという環境を構築することもあると思いますが、Windows Vista のインターネット接続共有では、DHCPv6PD をサポートしていますので、ブロードバンドルーター代わりに利用することもできます。

Windows のコンポーネントのほとんどが IPv6 対応に

そして、最後に申し上げたいのが、Windows Vista ではネットワーク機能を持つコンポーネントのほとんどが IPv6 対応になるということです。Windows XP ではプラットフォームと API の IPv6 化は完了していましたが、その上で動作するアプリケーションは IE と Windows Media Player、FTP クライアントなどとお世辞にも多くはありませんでした。Windows Vista では開発方針として、すべてのネットワーク機能を持つコンポーネントが IPv6 にも対応すると決められています。Active Directory や DNS（クライアントとサーバー）、DHCP を含み、基本的には、すべてのコンポーネントが IPv6 になると期待していただいて結構です。

さらには、ピュア IPv6 モードでの動作も可能です。これはマイクロソフト社内でのテスト目的の意味合いも大きいのですが、本当にそのコンポーネントが IPv6 で動作しているかどうかを確認するために、IPv6 のみのモード（ピュア IPv6 モード）で構成し、コンポーネントをテストしています。したがって、アカデミックな環境などで、IPv6 のみで操作する場合にも、十分実用になる OS となっています。

以上、ざっと Windows Vista での IPv6 対応について解説させていただきました。もちろん、以前、解説した Teredo なども引き続きサポートされています（実は、Teredo は Teredo で改良が加えられているのですが）。まだ、何か説明し忘れているような気もするのですが、もし思い出したら、ここで皆さんにお知らせしたいと思います。

マイクロソフト
及川卓也

及川です。

ブログのタイトルが少しキャッチーですが、IEBlog で Windows Vista 上の IE7 を Internet Explorer 7+ と呼ぶことが発表されました。

While all versions of IE7 are built from the same code base, there are some important differences in IE7+, most significantly the addition of Windows Vista-only features like Protected Mode, Parental Controls, and improved Network Diagnostics.

と書かれているように、IE7 のコードベースは同じなのですが、いくつか重要な差異がダウンレベル（マイクロソフト用語だと思いますが、対象の OS より以前の OS のことを指します。この場合は、Windows XP SP2 と Windows Server 2003 SP1です）と Windows Vista、それぞれで動作する IE7 にはあります。特に、保護モード、保護者による制限（Parental Controls）、改善されたネットワーク診断といった機能は Windows Vista 上の IE7 でだけ実現されるものです。

このように、今後、Windows Vista 上の IE7 とダウンレベル上の IE7 を言い分けることが多くなると思うのですが、

"The version of IE7 in Vista" doesn’t roll off the tongue as easily...

毎回毎回、「Vista 上の IE7 バージョンでは…」と説明するのは、舌が簡単に回りません。そこで今回、Windows Vista 上の IE7 を IE7+ と名付けさせていただきました。

両者の違いを判別するには、IE7/RSS Platform - User-agent 文字列で説明したように、User-agent 文字列を用いることができます。

• Windows Vista 上の IE7+: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
• ダウンレベル上の IE7: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)

マイクロソフト
及川卓也

及川です。

すでにお話しているように、米国シアトルでは WinHEC が開催されています。

それにあわせて、いくつかの技術がアナウンスされたり、技術文書（ホワイトペーパー）が公開されたりしています。

その１つとして、Kernel Enhancements for Windows Vista and Windows Server "Longhorn" が公開されました。

今まで、このブログでも、Windows Vista や Windows Server "Longhorn" についても、どちらかというと、利用者や管理者、アプリケーション開発者の視点で、興味を持っていただけると思う技術をご紹介してきました。しかし、OS としてもまだまだ着実に発展しているのだということを、この文書を読んでいただくとわかります。

昨今、巷では、にわかに OS ブームだとも聞きます。新しく OS を開発するプロジェクトがあったり、OS のカーネルを開発する書籍が売れていたり。是非興味を持っていただけた方は、この文書もご覧になっていただければと思います。このブログでも、IE や上位のアプリケーションだけでなく、この文書で紹介されているようなカーネルの改良などについても紹介していこうと思います。

マイクロソフト
及川卓也

及川です。

昨日に続き、MUI の話をします。

リソース DLL の配置

Windows Vista では真のシングルバイナリが実現され、実行形式ファイルや DLL などはリソース（Resource String）を含まず、リソースはそれだけが分離されリソース DLL として用意されていると説明しました。

例として、%windir%\system32 に置かれる実行ファイルや DLL を取り上げました。この例では、%windir%\system32\ja-JP に日本語のリソース DLL が <実行ファイル名>.mui の名前で置かれます。同じように、%windir% に置かれているファイルの場合は、%windir%\ja-JP に日本語のリソース DLL が置かれます。また、%windir%\system32\drivers にあるドライバの場合には、%windir%\system32\drivers\ja-JP に xxxx.sys.mui という形式で置かれているのが日本語のリソース DLL となります。

リソース DLL は UI 言語を追加することで、追加されます。たとえば、日本語版の Windows Vista に英語を UI 言語として追加した場合は、ja-JP の下のリソース DLL に加えて、en-US というフォルダの下にリソース DLL がコピーされます。ただし、%windir%\system32 の下のロケール名のフォルダ（ja-JP や en-US という命名規則で作成されているフォルダ）を探してみるとわかりますが、UI 言語を追加していなくても、フォルダはすでに作成しており、それぞれの下にいくつかのリソース DLL がすでに置かれていることに気づくと思います。たとえば、ベータ２の場合だと、%windir%\system32\zh-TW というフォルダには次のファイルが既定の状態で置かれています。

• comctl32.dll.mui
• comdlg32.dll.mui
• mlang.dll.mui
• msimsg.dll.mui

これらは多言語に対応するアプリケーションが利用する可能性のあるファイルです。OS 側が MUI として利用されなかったとしても、アプリケーションだけでも MUI として利用したいというニーズに応えるために、このようないくつかのファイルは既定の状態ですでにリソース DLL が配置されています。

実行ファイル以外のファイルの MUI 化

Windows の UI は実行ファイル以外でも構成されています。

たとえば、ユーザーの方がお使いになるヘルプファイル。これも MUI に対応する必要があります。したがって、Windows Vista ではヘルプファイルも UI 言語ごとにフォルダを持ち、そこに置かれています。たとえば、日本語版の Windows Vista ではヘルプファイルは CHM の場合には、%windir%\Help\mui\0411 に（0411 は日本語の識別子です）、Windows Vista から導入された新しいフォーマットのヘルプの場合には、%windir%\Help\Windows\ja-JP に置かれています。

マイクロソフト
及川卓也

及川です。

一昨日と昨日、本社からの MUI 担当者と打ち合わせを行いました。MUI は Multilingual User Interface もしくは Multilanguage User Interface の略で、日本語では多言語版などと呼ばれています。

MUI とは

MUI は Windows 2000 から導入された技術で、企業ユーザー向けライセンス購入者や OEM 版としてリリースされています。たとえば、Windows ベースのアプライアンスなどを OEM パートナー様より提供させていただいていますが、それらは MUI を利用して日本語の表示ができるようにしているものです。

現在リリースしている Windows XP および Windows Server 2003 用の MUI では、英語版の Windows を基本とし、その上に各言語用の追加モジュールを導入することで、UI 言語（UI Language）として他言語を利用することができます。たとえば、日本語と韓国語を追加し、ユーザーごとに UI 言語を選択することで、同一マシンであっても、A さんは英語、B さんは韓国語、C さんは日本語というように、ログインするユーザーによって UI 言語を使い分けることができます。

MUI では、実行ファイル（EXE）や DLL などに含まれているリソース（Resource String）をリソース DLL という形で分離し、UI 言語の設定にあわせて、適切なリソースをロードするように変更しています。英語版の実行ファイルや DLL には手を加えていませんが、MUI 用のリソース DLL にはリソースだけが含まれています。

Windows XP および Windows Server 2003 までの MUI については次の資料をご覧ください。

• Windows XP の Multi User Interface （MUI/多言語版）
• Windows XP Embedded の言語サポート
• Windows MUI/LIP Knowledge Center?（英語での情報です）

2 番目に紹介している資料は Windows XP Embedded という組み込み用 OS における MUI の解説です。実は、組み込み用の OS も MUI を用いて日本語の表示を行うようにしています。この資料は Windows XP Embedded 向けの解説ではありますが、一般の Windows?MUI の理解にも役立つような汎用的な内容となっています。

Windows Vista における MUI

Windows XP および Windows Server?2003 では、MUI はあくまでも一部の製品やお客様に利用されているにすぎませんでしたが、Windows Vista ではすべての製品が MUI となります。実は、この説明は多少誤解を呼ぶ可能性があります。正確には、Windows のローカライズモデルが技術的に MUI を利用するようになり、英語版も１つのローカライズ版としての位置付けになるというのが正しい説明になります。つまり、Windows XP/Windows Server 2003 では、MUI は英語版に追加する別パッケージという位置付けであり、実行ファイルや DLL には英語版のリソースが含まれていました。一方、Windows Vista では実行ファイルや DLL にはリソースが含まれていません。英語版も含めて、すべての言語はリソース DLL からリソースをロードします。これが MUI がすべての言語のインフラとして利用されるようになったという意味です。Windows XP や Windows Server 2003 でも、「シングルバイナリ」という説明をすることがありましたが、厳密にはリソース部分が異なっていましたので、真の「シングルバイナリ」にはなっていませんでした。Windows Vista では、英語版を含むすべてローカライズ版は「ベース OS ＋ 言語パック」という形態で実現されることになり、真の「シングルバイナリ」環境が実現されます。

もう少し詳しく見てみましょう。Windows Vista でも実行ファイルや DLL の多くは %windir%\system32 にあります。ただし、ここにある実行ファイルや DLL にはリソースがありません。リソースだけを含んだリソース DLL は UI 言語ごとに用意されたフォルダに置かれています。日本語版の場合、%windir%\system32\ja-JP というフォルダを見つけることができると思います。ここに置かれた <実行ファイル名または DLL 名>.mui というファイルがリソース DLL になります。たとえば、%windir%\system32\shell32.dll に対応するリソース DLL は日本語用が %windir%\system32\ja-JP\shell32.dll.mui になり、英語用が %windir%\system32\en-US\shell32.dll.mui になります。

以上が技術的な説明となります。製品として、異なる言語パックを追加することができる（つまり、MUI を利用できる）のは、Windows Vista Enterprise と Ultimate の２つになります。

MUI の利点

MUI には多国籍企業で、同一のバージョンでありながら、複数の言語の UI をサポートできるという利点があります。これが主に、Windows XP や Windows Server 2003 でWindows Vista における MUI の利点になります。ただし、Windows XP/Windows Server 2003 では英語版の上にのみ MUI を構築可能でしたが、Windows Vista ではベースとなる言語を選ばなくなるため、ユーザーの方にはより一層使いやすくなります。

さらに、Windows Vista では、英語版や日本語版などの言語による違いは原理的にはリソース DLL の違いだけになります。したがって、更新プログラムなどでリソースを含まないものは、１つのパッケージで全言語に対応することが可能になります。ここ数年で、Windows の更新プログラムやサービスパックでは言語によるリリースの遅延というものは、まったく無い（セキュリティ更新プログラムなど）か、あってもごくわずかになっていましたが、Windows Vista ではさらにそれが改善されることが期待できます。

マイクロソフト
及川卓也

及川です。

現在、米国シアトルでは WinHEC（Windows Hardware Engineering Conference）が開催されていますが、そこで Windows Vista および Windows Server "Longhorn" のベータ２のリリースが Bill Gatesによりアナウンスされました。

ベータプログラムに参加の方は、すでに Connect サイトからダウンロード可能になっていますので、是非お試しください。

WinHEC での Bill Gates の基調講演のオンデマンドストリーミングは WinHEC のサイトから見ることができます。このサイトの構成が変わる可能性もあるので、念のため、直接の URL をここに記載しておきます。

• 56K: http://metahost.savvislive.com/microsoft/20060523/winhec_billgates_20060523_56.asx
• 100K: http://metahost.savvislive.com/microsoft/20060523/winhec_billgates_20060523_100.asx
• 300K: http://metahost.savvislive.com/microsoft/20060523/winhec_billgates_20060523_300.asx

もちろん、Bill Gates のプレゼンテーションは英語ですが、トランスクリプトも用意されていますので、こちらとあわせて見ていただければ、雰囲気や重要な部分はつかんでいただけるのではないかと思います。是非ご覧ください。

ベータ２のリリースにはマイクロソフト社内のエンジニアだけではなく、社外の多くのお客様やパートナーの方々にご協力いただきました。ベータプログラムを通じてのフィードバックやサーベイでのご協力はもちろんのこと、ほかにもオフィシャル/アンオフィシャルの形でいろいろな方々にご意見をいただきました。この場を借りて、Windows Vista および Windows Server "Longhorn" への開発にご協力いただいている方々に改めて御礼を申し上げます。ありがとうございました。

この後、 RC、そして RTM に向かって、開発グループは手綱を緩めずに作業を続けていきます。皆さんの継続したご協力をこれからもよろしくお願いします。

マイクロソフト
及川卓也

及川です。

今日はセキュリティ対策としてのブラックリストとホワイトリストについて考えてみます。

ブラックリストとホワイトリスト

良くとられるセキュリティ上の対策にブラックリスト方式とホワイトリスト方式というものがあります。フィルタリングや迷惑メール（スパムメール）の対策でこれらの方式を用いた対策がとられることが多いので、皆さん、すでにご存知かと思います。

以前書いた 「Winny の利用禁止と削除」でソフトウェア制限ポリシーを用いた方法を紹介しましたが、この方法はブラックリスト方式です。すなわち、Winny をはじめとする既知の P2P ソフトウェアの利用を明示的に制限する方法です。

一方、ホワイトリスト方式とは、これとは逆に利用できるソフトウェアだけを登録しておき、それ以外のソフトウェアの利用はすべて禁止する方法です。

どちらが安全かと言えば、それは当然、ホワイトリスト方式になります。リストに含まれていないソフトウェアは起動することができませんので、前回の投稿で紹介できなかった P2P ソフトウェアだけでなく、未知のマルウェアなど、すべてに対応可能です。

しかし、良く言われることですが、セキュリティとユーザーの利便性はトレードオフの関係にあります。この場合、ユーザーの利便性とは、実際のエンドユーザーと ITPro と言われるシステム管理者の方の両者を含みます。ホワイトリスト方式にする場合には、企業で利用する可能性のあるソフトウェアをすべて登録する必要があります。これは管理者にとって、ブラックリストを作成するよりは労力が必要な作業となります。また、エンドユーザーにとっても、情報システム部署によって許可されたソフトウェア以外は一切動作させることができなくなりますので、見方によっては柔軟性のないシステムとなってしまいます。

繰り返しになりますが、セキュリティとユーザーの利便性はトレードオフの関係です。したがって、十分考慮した上で、ホワイトボックス方式をとれるならば、それに越したことは無いでしょう。Winny の対策でもホワイトボックス方式をとれる方は是非そちらで対応していただければと思います。

IE7 のフィッシング詐欺検出機能

「IE7 - フィッシング詐欺検出機能」では IE7 で導入されたフィッシング詐欺検出機能の仕組みについて解説しました。ローカルに保存される正当なサイトリスト（Legitimate List または Known-safe ste List）とマイクロソフトのサーバーで管理されるフィッシングサイトリストの２つのリストを組み合わせ、サイトがフィッシングサイトかどうかを判断しています。

ここでは、前者がホワイトリスト、後者がブラックリストとなります。

IE7 のフィッシング詐欺検出機能の場合は、ホワイトリストとブラックリストをハイブリッドに組み合わせるだけでなく、両者に含まれなかったサイトの対しては、ソフトウェア的にサイトが疑わしかどうかを判断し、疑わしいと判断された場合には、ユーザーに警告を発するようにしています。これにより、ブラックリストとホワイトリストの両者の良い点を利用するとともに、どちらにも分類されなかったサイトに対して「ヒューリスティックな」（マイクロソフトは正式にはヒューリスティックとは言っていないと思いますが）なアプローチでサイトがフィッシングサイトかを判断するようになっています。

?

以上のように、マイクロソフトのセキュリティ機能でも、ホワイトリスト方式、ブラックリスト方式のそれぞれをユーザーの方に提供し、環境に応じて使い分けていただくようにしているものもありますし、IE7 のフィッシング詐欺検出機能のようにハイブリッドな方式で提供しているものもあります。皆様には、それぞれの仕組みを理解していただき、適切な使い分けをしていただければと思います。

マイクロソフト
及川卓也

及川です。

IE7 の日本語版ベータがリリースされて、しばらくたちますが、かなり多くの方に評価していただいているようです。ありがとうございます。私が個人的に持っているブログにも IE7 からアクセスされている方が何名かいらっしゃいました。

Web サイトのアクセス解析で訪問者のブラウザ種別を判別するには、ブラウザから送出される User-agent 文字列を用いるのが一般的です。IE7 は RSS リーダー（アグリゲーター）機能を標準装備していますので、IE7 からブラウザとしてアクセスした場合と、RSS のフィードにサブスクライブし、そこからアクセスする場合とで、送出される User-agent 文字列は異なります。

それぞれの User-agent 文字列は次のようになります。

IE7 からブラウザとしてアクセスした場合:

• Windows XP SP2 上の IE7
  User-agent = "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)"
• Windows Vista 上の IE7
  User-agent = "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)"

RSS フィードにサブスクライブした場合:

• Windows XP SP2 上の RSS 機能
  User-agent = "Windows RSS Platform/1.0 (MSIE 7.0; Windows NT 5.1)"
• Windows Vista 上の RSS 機能
  User-agent = "Windows RSS Platform/1.0 (MSIE 7.0; Windows NT 6.0)"

後者の RSS フィードにサブスクライブした場合の User-agent 文字列は実は HTTP 標準に沿っていません。実際には "Windows-RSS-Platform" というように、スペースの代わりにダッシュ（-）が使われなければいけません。ベータ２では残念ながら修正できませんでしたが、RTM に向けてはこの正しい文字列 "Windows-RSS-Platform" が使われることになります。

参考情報:

• User-Agent string (Microsoft Team RSS Blog)
• A quick note on the Beta 2 Preview user agent string (IEBlog)

マイクロソフト
及川卓也

及川です。

マイクロソフトのオープンソースソフトウェアラボである Port 25?に書かれていますが、Windows Security and Directory Services for UNIX Solution Guide のベータ版が公開されています。

これは Windows と UNIX の相互運用を高めるためのソリューションを解説したドキュメントで、以下の情報が含まれています。

• UNIX クライアントが UNIX ベースの承認機能を使い続けながらも、Windows の Active Directory Kerberos 認証を用いる方法
• UNIX クライアントが Windows の Active Directory Kerberos を認証に使い、さらに Active Directory を LDAP として承認機能としても用いる方法

ちょっとわかりにくいかもしれませんが、承認は英語での "Authorization"、認証は "Authentication" です。簡単に言うと、Kerberos の KDC として、また LDAP サーバーとして Active Directory を用い、UNIX をクライアントとする方法が解説されているものです。Windows 側の解説だけでなく、オープンソースやサードパーティのソフトウェアを用いて、実現するいくつかのシナリオが紹介されています。

このドキュメント、かなりの大作です。実際にダウンロードされるとお分かりになると思いますが、複数の Word 文書や Excel シートから構成されています。すべて英語なので、読むのは骨が折れるかと思いますが、UNIX と Windows 混在環境でお困りの方で、興味のある方は是非お読みになり、フィードバックをいただければと思います（まだベータですので）。

このドキュメントは Microsoft Connect サイト?からダウンロードできます。Connect サイトにアクセスし、左側の [利用可能プログラム] をクリック。Microsoft Passport アカウントもしくは Windows Live ID をお持ちの方は、そのアカウントを用いてサインインしてください。お持ちでない方は、[今すぐサインアップ] でサインアップしてください（Web ページの説明が少し紛らわしいので注意してください）。

利用可能なプログラムが一覧になって表示されると思います。これらが参加可能なベータプログラムの一覧です。この中から "Windows Security and Directory Services for UNIX Solution Guide V1.0" を探し、[申し込み] をクリックしてください。すると、使用条件が表示されますので、異存がなければ、[同意する] をクリックします。その後、コンタクト情報などの入力を行い、ドキュメントのダウンロードページまで進むことができます。

ZIP ファイルをダウンロードしていただき、解凍していただくことで、ドキュメントをお読みいただくことができます。

興味のある方は是非トライしてみてください。

マイクロソフト
及川卓也

及川です。

Windows XP での WinInet アプリケーションのトラブルシュートの課題

昨日、「WinInet アプリケーションのトラブルシュート」で紹介したように、Windows XP までは WinInet アプリケーションのトラブルシュートにはデバッグバージョンの WinInet.dll を適切な場所に起くなどの事前準備が必要でした。また、生成されるログファイルは単純なテキストファイルではあるものの、可読性に課題を抱えていました。

Windows Vista では、WinInet モジュールを置き換えることなく、WinInet のトラブルシュートができるようになっています。

Windows Vista での WinInet のトラブルシューティング

Windows Vista では Event Tracing for Windows (ETW) という機能を使って、WinInet のトレースログを取得します。ETW は実は Windows XP でも利用できますが、WinInet 用のプロバイダは Windows Vista から提供されています。ETW についてはまた機会を改めて解説しようと思います。それまでの間は、英語で恐縮ですが、MSDN Windows SDK の情報をご参照ください。

ETW を使って、Windows Vista で WinInet のトレースログを取得するには、まずコマンドプロンプトを管理者権限で起動します。スタートメニューから [アクセサリ] → [コマンドプロンプト] を右クリックし、[管理者として実行] で起動させます。これもまだ説明しなかったと思いますが、Windows Vista では UAC（ユーザーアカウント制御）という機能があるため、Administrators グループに含まれているユーザーであっても、このように明示的に管理者としてコマンドプロンプトを起動する必要があります。

コマンドプロンプトが起動したら、次のコマンドを入力します。

C:\>logman start "wininettrace" -p "microsoft-windows-wininet" –o "wininettrace.etl" –ets

これで WinInet のトレースが始まります。

トレースを停止させるには、次のコマンドを入力します。

C:\>logman stop "wininettrace" -ets

-o パラメータで指定した「wininettrace.etl」というのが出力ファイルとなります。これは logman コマンドを実行したフォルダに作成されます。これはバイナリファイルのため、そのまま読むことはできません。形式を変換するには、次のコマンドを用います。

C:\>tracerpt "wininettrace.etl" –y –o "wininetracelog.xml" -of xml

このコマンドでは、logman によって生成された「wininettrace.etl」を「wininettracelog.xml」という XML フォーマットのファイルに変換しています。出力形式はほかにも CSV などをサポートしていますので、「-o "wininettracelog.csv" -of csv」とすることで、CSV でレポートを出力することもできます。

XML にしても、CSV にしても、可読性は Windows XP　でデバッグバージョンの WinInet.dll を使ったログファイルよりも非常に高くなっています。両方とも人間の目で見て、わかりやすいだけでなく、アプリケーションによりさらに解析することもできるようになっていますので、必要な部分だけをさらに抽出することなどができるようになっています。

Windows Vista のベータユーザーの方は、是非お試しください。

マイクロソフト
及川卓也

及川です。

ちょっと前に、WinHTTP の解説をしましたので、今回は WinInet の話をします。

WinInet とは

以前に書いた「WinHTTP - ユーティリティの紹介と Windows Vista での改善」では WinHTTP が WinInet に取って代わりつつあるという話をしましたが、取って代わりつつあるというのは少し御幣がある言い方だったかもしれません。IE をはじめとして多くのアプリケーションがまだ使っていますし、Windows Vista でも使われています。

WinInet とは、そもそも何物？ ということについて、詳しくは MSDN のページを見ていただきたいのですが、簡単に言うと、HTTP や FTP などのインターネットプロトコルを扱うための高レベル API です。WinSock でしこしこと HTTP プロトコルのハンドリングをすることなしに、HTTP 対応のクライアントアプリケーションを開発することができます。

WinInet のアプリケーションは IE だけでなく、多くのサードパーティアプリケーションやカスタムアプリケーションで使われています。今回は、それらのアプリケーションで障害が発生した場合のトラブルシュートについて解説します。

WinInet アプリケーションのトラブルシュート

WinInet のトラブルシュートは、デバッグバージョンの WinInet.dll を利用することで行えます。デバッグバージョンの WinInet.dll はマイクロソフトのダウンロードセンターより入手できます。ダウンロードできるのは、WinINET_Debug.exe という自己解凍型のファイルになっています。

ダウンロード後、このファイルを実行し、中のモジュールをフォルダに展開すると、IE や Windows のバージョンごとのモジュールが複数のフォルダに展開されます。ここでは、Windows XP SP2 の場合を例にとって説明します。本日執筆している時点で入手できるWinINET_Debug.exe を実行すると、展開されたフォルダの中に「XPSP2_customer_ready_2180」というフォルダがあるのを見つけられると思います。これが Windows XP SP2 用の WinInet.dll デバッグバージョンの含まれるフォルダになります。

デバッグバージョンの WinInet.dll を入手したら、次はトラブルシュートを行う WinInet アプリケーションのフォルダにその DLL をコピーします。Windows XP の IE の場合、「%ProgramFiles%\Internet Explorer」にコピーすることになります。次に、同じフォルダに＜アプリケーション名＞.localという中身が空のテキストファイルを作成します。IE の場合、IEXPLORE.EXE.local という名前で IE のフォルダに作成します。

この状態で、コマンドプロンプト（cmd.exe）を開き、WinInet アプリケーションのフォルダ（IE の場合は、「、「%ProgramFiles%\Internet Explorer」）に?cd し、そこで次のように環境変数を設定します。

          c:\>set wininetlog=1

その後、コマンドプロンプトから WinInet アプリケーション（IE の場合は IEXPLORE.EXE）を実行すると、デバッグログが生成されます。ログの生成場所はデスクトップかアプリケーションのフォルダです。この中に WinInet の API コールのトレースがすべて含まれますので、そこでどこに問題があるかを把握することができます。この生成されるログファイルですが、とてつもなく巨大です。わずか、１つの Web ページを開くだけでも 1MB を超えるサイズのログファイルとなります。ですので、問題の起きる部分を特定し、その部分だけのログをとるようにする必要があります。

コマンドプロンプトを閉じることで、ログ収集を終了することができます。

詳しくはマイクロソフトサポート技術情報および WinINET_Debug.exe を展開した後にできる inetdbg.txt をご覧ください。

Windows Vista では

この WinInet のデバッグバージョンを利用することで、WinInet アプリケーションのトラブルシュートやデバッグを行うことができるのですが、Windows XP まででは、このデバッグバージョンをわざわざ導入しなければいけないということ、およびログファイルの可読性があまり良くないという２つの大きな課題がありました。ログはあまりにもサイズが大きいので、ここには載せませんが、正直、あまり読みやすいものではありません。また、最終的にはマイクロソフトのサポートエンジニアでないと対応できない部分もありました。

Windows Vista ではこの２つの課題への対応がされています。

それについては、次回解説させていただきます。

マイクロソフト
及川卓也

及川です。

昨年すでにアナウンスさせていただいているように、マイクロソフトは Windows Vista に新日本語フォント「メイリオ」を搭載し、さらに MS ゴシック/明朝フォントも JIS 2004 対応を行います。

本日、本件についてプレスの方々を招いてセミナーを開催させていただきました。その模様がプレス各社より報道されていますので、ここで紹介させていただきます。

• ITmedia さん: Vista新フォントは「現代日本語に必要な漢字を網羅」
• インプレス PC Watch さん: マイクロソフト、Vistaの新フォント「メイリオ」について説明 ～可読性の高いフォントで生産性も向上
• 日経 BP ITPro さん: Windows Vistaの新フォント「メイリオ」の詳細を発表
• 日経 BP ITPro さん: マイクロソフト，新文字セット「JIS2004」への移行措置を明らかに

ポイントとしては、

1. 初の OS 標準搭載となる日本語 ClearType フォント「メイリオ」を Windows Vista に搭載する。
2. Windows Vista では標準で JIS 2004 対応を行う。
3. ただし、JIS 2004 への移行措置として、JIS90 対応の MS ゴシック/明朝フォントを Windows Vista に提供する。また、JIS 2004 対応の新バージョンの MS ゴシック/明朝フォントを Windows XP および Windows Server 2003 にも提供する。

ということになります。

既存のアプリケーションの互換性などにも影響を与えることになりますので、積極的なご評価をよろしくお願いします。

マイクロソフト
及川卓也

及川です。

WinHTTP - ユーティリティの紹介と Windows Vista での改善 で紹介したように、Windows Vista では、今まで別個に提供されていた WinHTTP ユーティリティが Netsh もしくは MMC の証明書スナップインに統合されることになります。

前回、

Windows Network Developer Platform チームのブログでは、これは Part 1 ということになっていますので、Part 2 が書かれましたら、それも紹介させていただきます。

と書いたのですが、結果的に Windows Network Developer Platform チームのブログでは、Part 4 までかけて解説がされました。

それぞれについて、日本語で解説をしようかと思ったのですが、基本的に Netsh でのコマンド例や MMC のスナップインでの使い方なので、それぞれのブログ記事へのリンクをご紹介するにとどめておきます。英語ですが、基本的にコマンド例および操作方法が書かれているので、直感的にもお分かりいただけると思います。

• WinHttp Configuration for Windows Vista Beta 2 - Part 2
• WinHttp Configuration for Windows Vista Beta 2 - Part 3 Tracing
• WinHttp Configuration for Windows Vista Beta 2 - Part 4 Client Certificates

マイクロソフト
及川卓也

こんにちは、及川です。

今日は IE7 のフィッシング詐欺検出機能について解説します。

フィッシング詐欺検出機能（またはアンチフィッシング機能）はその名のとおりフィッシングサイトを検出し、ユーザーを保護する機能です。

フィッシング詐欺検出機能の動作

IE7 のフィッシング詐欺検出機能は動的にフィッシングサイトの検出を行います。「動的」ということからわかるように、IE7 ではサイトが安全なサイトかどうかの確認をオンラインで行います。

IE7 である Web サイトを閲覧する際、IE7 は最初にそのサイトがすでにユーザーが訪れたことがあり、マイクロソフトのサーバーに安全なサイトであるとレポートされているかどうかをローカルに保存されている正当なサイトリスト（Legitimate List または Known-safe site List）と照らし合わせて確認します。この正当なサイトリストはマイクロソフトのサーバーから周期的にダウンロードされます。もし、このリストの中にすでに存在しているサイトであれば、フィッシング詐欺の検出はここで終了し、ユーザーはサイトの Web ページを表示することができます。

ローカルに保存されている正当なサイトリストにないサイトを閲覧しようとした場合、まず、IE7 はフィッシング詐欺検出機能の自動検出を有効にするかどうかを確認します（下図 ＊注: 昔キャプチャしたものなので、最新の画面と違うかもしれません）。

このように、ユーザーにはフィッシング詐欺検出機能を常に自動で有効にするかどうかを選択する権利が与えられます。

ここでユーザーがフィッシング詐欺自動検出機能を有効にした場合、その後、正当なサイトリストにないサイトに最初に訪れるたびに、その情報がマイクロソフトに送信され、マイクロソフト側で保持しているリストと照らし合わせ、サイトがフィッシングサイトかどうかが判断されます（なお、フィッシング詐欺検出は手動で行うことも可能です）。

サイトがフィッシングサイトであると判断された場合、アドレスバーは赤くなり、ブラウザー画面にサイトは表示されません（下図。クリックして拡大）。

一方、マイクロソフトのサーバーで管理するフィッシングサイト リストに該当するものはないものの、サイトの特徴からフィッシングサイトと高い確率で疑われるサイトは次のように警告画面が表示されます。

ブラウザー画面にはサイトが表示されますので、フィッシングサイトでないと確信できる場合は、そのまま操作できます。また、マイクロソフトに対し、誤検出の事実をレポートすることができます。

動的な検出の利点

フィッシング詐欺検出機能を提供する他社の製品にはフィッシングサイトのリストを定期的に PC にダウンロードするものもあります。確かに、この方法のほうが、新しいサイトにアクセスするたびにマイクロソフトのサーバーにオンラインで確認するよりも、ローカルのリストに対してチェックを行うだけですので、パフォーマンスは高いかもしれません。

しかし、ある種のフィッシングサイトは頻繁に移動し、同一のサイト名（FQDN）や IP アドレスで長い間存在しているケースは少ないことがわかっています。このような頻繁に移動するサイトをローカルで保持しているリストでチェックするためには、一日に何度もリストを PC にダウンロードしなければならず、かえって時間がかかることにもなりますし、最悪のケースではインターネット全体のパフォーマンスにも悪影響を及ぼす可能性があります。

このような理由により、マイクロソフトではフィッシングサイトのリストを PC にダウンロードすることは行わずに、動的にオンラインでチェックする方法を選択しています。

なお、フィッシングサイトのリストはダウンロードされませんが、正当なサイトリストは周期的に PC にダウンロードされます。説明したように、このローカルに保持されている正当なサイトリストにないサイトにアクセスする場合に、オンラインでのチェックが行われます。

プライバシー保護対策

さて、マイクロソフトのサーバーにデータが送出されることから、プライバシーの問題を懸念される方がいらっしゃるかもしれません。マイクロソフトはこの点に関して最大限の対応をしており、ユーザーをフィッシング詐欺の脅威から守るとともにプライバシーも保護することを実現しています。

具体的には、以下の対応がとられています。

1. フィッシング詐欺検出機能の利用にはユーザーの許諾を求めるよう（Opt-in）になっています。ユーザーはいつでもフィッシング詐欺検出機能の使用をやめることができます。
2. フィッシング詐欺検出機能は、ローカルに保持されている正当なサイトリストにないサイトにアクセスする場合のみ行われます。
3. アクセスしている Web サイトのアドレスと、お使いのコンピュータの IP アドレス、ブラウザの種類、フィッシング フィルタのバージョン番号などの標準情報がマイクロソフトに送信され、検索用語やフォームに入力したデータ、Cookie などの情報は送信されません。
4. マイクロソフトに送信される情報は SSL により暗号化されます。

関連情報

IEBlog（英語）より:

• Phishing Filter in IE7
• Principles behind IE7’s Phishing Filter
• New enhancements to Phishing Filter protection for IE

プライバシーステートメント:

• Microsoft Internet Explorer (Pre-Release Version 7.0) Privacy Statement ← 英語ですが、最新版です。
• Microsoft Internet Explorer (プレリリース バージョン 7.0) のプライバシーに関する声明 ← 日本語ですが、古いです。もうすぐ更新されると思います。

ホワイトペーパー

• アンチフィッシィング (Anti-phishing) に関するホワイト ペーパー

?

マイクロソフト
及川卓也

及川です。

皆さんすでにご存知のとおり、Winny をはじめとする P2P ファイル交換/ファイル共有ソフトウェアによる情報漏えいの問題が社会問題化しています。少し前の日経 BP さんの「Winny 商法」にご用心にも書かれていますが、Windows の標準機能を用いることで、この問題に対応することが可能です。

ソフトウェア制限ポリシーでの対応

私の友人である PTRS の吉田氏のサイトにこのソフトウェア制限ポリシーでの対応の仕方とそのためのハッシュ値情報が掲載されました。

まず、吉田氏のサイトのソフトウェア制限のポリシーで P2P ファイル共有ソフトを実行させない方法をご覧下さい。ここでは、P2P ファイル共有ソフトウェアをソフトウェア制限ポリシーを用いて、その実行を禁止させる方法が解説されています。吉田氏のサイトではローカルセキュリティポリシーを用いた方法が解説されていますが、Active Directory とグループポリシーを用いた集中管理を行うことで中～大規模な環境における効率的な制御が可能です。

グループポリシーを用いて、ソフトウェア制限ポリシーを設定するには、MMC のグループポリシー スナップインから行います。適切なポリシーを選択し（以下の画面図ではローカルコンピュータポリシーを選択してしまっていますが、通常は OU などの Active Directory のコンテナを選択します）、[コンピュータの構成] → [Windows の設定] → [セキュリティの設定] → [ソフトウェア制限のポリシー] をクリックします。そこで、マウスの右ボタンで表示されるコンテキストメニューから [新しいハッシュの規則] をクリックします。

グループポリシーの図（クリックして拡大）"

ここで、たとえば Winny なら Winny のハッシュ値を入れることになります。再び、吉田氏のサイトの
P2P ファイル共有ソフトの「ソフトウェア制限のポリシー」用ハッシュ値一覧をご覧いただき、ここから実行を制限する Winny のハッシュ値をコピーし、[ファイル ハッシュ] の欄に貼り付けます。

これで該当の Winny の実行が禁止されます。試しに、Winny を起動してみると、次の画面のように、エラーが表示され、実行できないことがわかります。

これを実行を制限したい P2P ファイル交換ソフトウェアの分だけ行うことで、Active Directory 管理下にある Windows での実行を禁止させることができます。

Winny は亜種を含め、全部で 82 種類ほどあると言われています。残念ながら、吉田氏のサイトでもすべては網羅されていません。ですが、最近のポピュラーなものはカバーされていますので、これらの制限をかけるだけでも、かなりの効果があると思います。

参考情報: Windows XP におけるソフトウェア制限ポリシーの説明

サードパーティアプリケーションの利用

ご存知のように、サードパーティアプリケーションからも Winny 対策のソフトウェアが提供されています。その１つが Winny を介して感染する Antinny を削除するものです。これは、マイクロソフトからも悪意のあるソフトウェアの削除ツールとして提供されています（悪意のあるソフトウェアの削除ツールは Windows Update およびダウンロードページからダウンロードできます）。

多くのウィルス対策ソフトウェアではすでに Antinny の対応は行われているようですので、確実に最新のパターンファイルがダウンロードされていることを確認していただければと思います。

もう１つが Winny そのものを検出もしくは削除するものです。いくつかのベンダーがすでにこのようなツールを提供しているようです。その中にはネットワーク上流れるパケットを解析し、Winny の実行を検出するものもあります。ですが、この方法では、社員が Winny を社内ネットワークで実行した場合しか検出することができません。帰宅後にだけ Winny を使っているような場合には、この方法では検出できないことになります。これとは別にウィルス検出の場合と同じように、Windows のフォルダをスキャンし、Winny を検出/削除するものもあります。

後者のものを提供しているベンダーをここではいくつか紹介します。

シマンテックさん: Winnyによる情報漏えい対策に関するシマンテックの考え

シマンテックさんからは単体で Winny を検出することができるツールが無償で提供されています。こちらは GUI を表示させずに動作させることができ、上のサイトではログオンスクリプトで動作させることも簡単に解説されています。ログオンスクリプトである共有フォルダに検出ツールのログを吐き出させるなどすると良いでしょう。

マカフィーさん: Winny による情報漏えいにご注意を

マカフィーさんは製品の一部として Winny 自体を検出/隔離/削除するソリューションを提供しています。

トレンドマイクロさん: Winnyによる情報漏えい対策

トレンドマイクロさんは製品の一部として Winny 自体を検出/削除するソリューションを提供しています。

アークンさん: 情報セキュリティ対策製品 評価版ダウンロード

アークンさんからは単体で Winny を検出/削除するツールが無償で提供されています。ざっと見たところ、GUI は表示されるようですので、サイレントにログオンスクリプトで動作させることは難しいようですが、こちらは削除まで可能ですので、社員の方に協力を得て、定期的に起動していただくことを義務付けるのも良いかもしれません。

以上、4 社を取り上げさせていただきましたが、おそらくこれ以外にもあると思います。是非、自社で使われているセキュリティ製品を確認し、Winny 自体の動作を停止させたり、削除するようなソリューションがないかを確認していただきたいと思います。

Winny 自体が悪か？

もしかしたら、Winny 自体を削除する必要があるのかという疑問もあるかもしれません。

個人的には、P2P アプリケーションというのは、技術的にも社会的にも可能性を秘めた優れたアプリケーションだと思っています。ファイル交換ソフトウェアも著作権を無視し、不正にファイル交換してしまうユーザーの存在が問題にはなっていますが、技術的には非常に興味深いエリアで、今後発展の可能性も高いと思います。

しかし、少なくとも Winny に関してはバッファーオーバーフロー（ヒープオーバーフロー）の問題が指摘され、現時点では残念ながら修正が期待できないとなると、Winny を使うことそのものが極めて危険といわざるを得ません。現時点では、Winny の使用は禁止するしかないでしょう。

参考情報

以下、いくつかほかの参考情報です。

Winnyによる情報漏えいを防止するために（IPA さん）

こちら IPA さんから情報は一般的な Winny による情報漏えいのリスクから技術的および管理上の対策がカバーされています。

ファイル共有ソフトによる情報の流出について（マイクロソフト）

こちらは主に一般ユーザー向けの啓発を目的とした情報です。

企業向け: ファイル共有ソフトによる情報漏えいの防止策（マイクロソフト）

こちらは企業向けユーザーに対し、情報漏えいのリスクと対策について解説してあります。

SMS 2003による企業内のファイル交換ソフト、ネットワーク構築・通信ソフトの検出（マイクロソフト）

こちらは SMS を用いた対策が紹介されています。SMS ではソフトウェアインベントリーにより P2P ファイル交換ソフトウェアの検出やソフトウェアメータリングによる起動の監視を行うことができます。

今日は、Winny をはじめとする P2P ファイル交換ソフトウェアの対策について整理してみました。いくつかはすでに知られているものだと思いますが、現時点で有用と思われるものを整理してみましたので、皆様のご参考になれば幸いです。

マイクロソフト
及川卓也

及川です。

お待たせしました！

IE7 ベータ２の日本語版がリリースされました。以前の投稿に書いたように、IE7 ベータ２は Windows XP SP2 (x86 & x64), Windows Server 2003 SP1 (x86, x64 & ia64) に対応しています。こちらからダウンロードできます。

[6/28 更新] 日本語版のリリースノートがようやく用意できました。以下の記述はそのまま残しておきますが、日本語版リリースノートのほうをご覧いただきますようお願いします。

残念ながらリリースノートの日本語版は用意できなかったのですが、大事なことが書かれていますので、是非、目を通すようにお願いします。「英語はちょっと…」という方のために、インストールで大事な部分と日本語 Windows で使う上で重要な部分について抄訳を下に載せますので、参考にしてください。

Installation Notes

Japanese Installation Prerequisite

You must install the Rights Management Add-on from the RMA Download Page before you install Internet Explorer 7 Beta 2. The add-on cannot be installed after IE7 Beta 2.

日本語版のインストール前の作業

Internet Explorer 7 ベータ２のインストールの前に、Rights Management アドオンを RMA ダウンロードページから Rights Management アドオンをインストールしてください。このアドオンは IE7 ベータ２のインストール後にはインストールできません。［追記 18:40 -?RM アドオンのインストールをしなくても IE7 ベータ２は利用できますが、RM アドオンを後からインストールすることができません。もし RM の利用を行う可能性があるならば、先に RM アドオンをインストールするようにしてください。］

Installation Errors

If you receive notification that the installation failed you should always reboot your system to ensure that any changes made during setup are completely undone.

For more information on the problem, you can refer to the log files at:
%windir%\ie7beta2_main.log
%windir%\ie7bet2p.log
%windir%\ie7bet2pUninst.log

where %windir% is the location of your Windows directory, which can usually be found at C:\Windows.

If you receive the error "Setup was unable to open the log file for writing: C:\WINDOWS\ie7beta2_main.log", log in with a user account that has administrator privileges and re-run IE 7 Beta 2 setup.

インストレーションエラー

インストールに失敗した場合は、システムを再起動し、セットアップにより行われた作業が完全に除去される（アンドゥされる）ことを確認してください。

問題点の確認には次のファイルを確認してください。オリジナルのリリースノートに間違いがありました。以下のように訂正します。

%windir%\ie7beta2_main.log
%windir%\ie7bet2.log
%windir%\ie7bet2Uninst.log
%windir%\ie7bet2p.log
%windir%\ie7bet2pUninst.log

?

もしログファイルに書き込めないというエラーに遭遇した場合には、管理者権限付きのアカウントで再度 IE7 ベータ２のセットアップを起動してください。

Reinstalling Internet Explorer 7 Beta 2

If you want to reinstall Internet Explorer 7 Beta 2 (or install a newer version) you must first remove any existing Internet Explorer 7 versions. You cannot install Internet Explorer 7 over itself.

Internet Explorer 7 ベータ２の再インストール

Internet Explorer 7 ベータ２を再インストールするには、最初にインストール済みの Internet Explorer 7 をアンインストールしてください。

Uninstalling Internet Explorer 7 Beta 2 before reinstalling Internet Explorer 7 Beta 2

To uninstall Internet Explorer 7 Beta 2 and return to Internet Explorer 6 on Windows XP

Click “Start,” and then click “Control Panel.”

Click “Add or Remove Programs.”

Check “Show Updates” at the top of the dialog box. (If you are running Internet Explorer 7 Beta 2 Preview - March 20, or a newer version of IE7, this step is not necessary.)

Scroll down the list to “Windows XP – Software Updates,” select “Internet Explorer 7 Beta 2 Preview,” and then click "Change/Remove."

If "Internet Explorer 7 Beta 2" does not exist, run %windir%\$NtUninstallie7bet2p$\spuninst\spuninst.exe. (To do this, you need to have "view hidden folders" enabled.)

Windows XP 上で Internet Explorer 7 ベータ２をアンインストールし、 Internet Explorer 6 に戻すには

オリジナルのリリースノートに間違いがありました。以下のように訂正します。

コントロールパネルの [プログラムの追加と削除] から行ってください。[プログラムの追加と削除] に Internet Explorer 7 Beta 2 が存在しない場合には、%windir%\$NtUninstallie7beta2$\spuninst\spuninst.exe %windir%\$NtUninstallie7beta2p$\spuninst\spuninst.exe を起動してください。

Hangs During Uninstall--If the uninstall process hangs while removing Internet Explorer 7 Beta 2, delete any custom sound schemes created after installing the Internet Explorer 7 Beta and retry the uninstall.

アンインストールの途中でハングしてしまった場合 -- Internet Explorer 7 ベータ２のインストール以降に作成したサウンドスキーマをすべて削除し、再度アンインストールを試してください。

Removing Internet Explorer 6 updates

Updates associated with Internet Explorer 6 will remain in Add/Remove Programs after Internet Explorer 7 is installed. If these updates are removed, your system will likely become unstable or unusable. Uninstalling Internet Explorer 7 should return the system to a working state and you can then reinstall the updates to IE6.

Internet Explorer 6 更新の削除

Internet Explorer 6 に関係した更新は Internet Explorer 7 のインストール後も [プログラムの追加と削除] に残ります。もしこれらの更新を削除した場合、システムが不安定になり、利用できなくなるかもしれません。Internet Explorer 7 をアンインストールすることで、システムを正常状態に戻すことができ、さらにその後、Internet Explorer 6 への更新を再インストールすることができます。

IME Hot Key Language Switch -- Users cannot use the Input Method Editor (IME) hot keys to switch language inputs when entering characters into HTML (for example, forms and text boxes.) To work around this issue:

• Switch the input method using the Language bar icon in the task bar
• Turn off "Advanced Text Services" on the Internet Control Panel - Regional and Language Options - Languages - Details - Advanced).

Note: When you disable Advanced Text Services, you will no longer have a visible Language Bar Icon in the task bar.

IME ホットキー言語スイッチ　--　ユーザーは HTML（たとえば、フォームやテキストボックス）に文字を入力する際に、IME による言語の切り替えが行えません。これに対処するには、

• タスクバーの言語バーで言語を切り替える
• コントロールパネル（原文では Internet Control Panel と書かれていますが、コントロールパネルです）の [地域と言語のオプション] → [言語] タブ → [詳細設定] ボタン → [詳細設定] タブの中の [詳細なテキストサービスをオフにする] をチェックします。

注: 詳細なテキストサービスをオフにすると、タスクバーに言語バーが表示されなくなります。

［追記 18:40?- この現象は常に再現するものではありません。再現した場合は、上の手順で対処をお願いします。］?

以上がリリースノートの重要な部分の抄訳です。

これ以外に１つ日本語版に関係する問題がありますので、ここでお知らせしておきます（ブログ以外の正式なチャネルでもこの情報は載せる予定です）。

アドオン無しモードで IE を立ち上げるためのリンクが所定の位置に作られません
?
Internet Explorer 7 ベータ２インストール後、[スタート] メニューの [すべてのプログラム] の下に、アルファベット名で [Accessories] → [System Tools]?→ "Internet Explorer (No Add-ons)" が作成されてしまいます。アドオンを無効にした状態で Internet Explorer 7 を実行する場合は、このリンクを利用してください。本問題は日本語版最終リリースまでに修正され、"Internet Explorer (アドオンなし)" が ?[アクセサリ]?→ [システム ツール] の下に現れる予定です。

以上の注意点に留意の上、是非、新しい Internet Explorer を試してみてください！

よろしくお願いします。

マイクロソフト
及川卓也

P.S. 18:40 に２箇所ほど追記いたしました。
P.P.S. 5/23 に２箇所ほど訂正いたしました。コメントでのご指摘ありがとうございました。
P.P.P.S. 6/28 に日本語版リリースノートの公開について記述を追加しました。

及川です。

ゴールデンウィークがあった関係で、少し間が空いてしまいました。

今日は WinHTTP について解説したいと思います（元ネタは本社の Windows Network Developer Platform チームのブログです）。

WinHTTP とは

Windows アプリケーションから HTTP を扱う方法はいくつかあります。古くは WinINET というコンポーネントがありました。正確には、古くというべきではないですね。今でも、マイクロソフトの製品の多くが、これを使っています。WinINET は HTTP だけでなく、FTP などほかのインターネットで用いられるプロトコルをプログラマブルに扱うためのコンポーネントとして利用されてきました。

WinHTTP はその WinINET を補完する形で開発されました。WinINET が元来クライアントアプリケーションを対象として設計されていたのに対して、WinHTTP はサーバーの中からの動作やサービスとしての動作もサポートします。当初はこのように　WinINET はクライアント、WinHTTP はサーバーという形で使い分けされていましたが、今ではクライアントアプリケーションにおいても WinHTTP を推奨しています。

たとえば、Windows Update や Windows インストーラは（MSI）では URL で指定された場所よりモジュールをインストールすることを行いますが、その内部では WinHTTP が使われています。

WinHTTP についての詳しい解説はMSDN の情報（英語）をご覧下さい。

WinHTTP 用ユーティリティ

WinHTTP 用のユーティリティとして以下の 3 つが提供されています。

• ProxyCfg.exe : 既定のプロキシ設定
• WinHTTPTraceCfg.exe : トレース設定
• WinHTTPCertCfg.exe : クライアント証明書設定

ProxyCfg.exe は Windows に同梱されています（コマンドプロンプトで "proxycfg" と叩いてみてください）が、ほかの 2 つは Windows Server 2003 Resource Kit Tools?をダウンロードする必要があります。

Windows Vista での改善

Windows Vista では、これらのユーティリティを外部から別途入手することなく使えるように、ProxyCfg.exe と WinHTTPTraceCfg.exe については Netsh に統合し、WinHTTPCertCfg.exe については MMC の証明書のスナップインに統合しています。

以上、Windows Network Developer Platform チームのブログからの情報を中心にご紹介しました。

Windows Network Developer Platform チームのブログでは、これは Part 1 ということになっていますので、Part 2 が書かれましたら、それも紹介させていただきます。