及川です。

IEBlog の IE7 to be distributed via Automatic Updates!?という投稿でもアナウンスされていますように、自動更新（Automatic Update）にて IE7 を提供いたします。もちろん、RTW/RTM された後の話です。順調に進めば、IE7 は今年の最終四半期にリリース予定ですが、その後、自動更新にて IE7 を提供します。

自動更新は自動的に更新プログラムをダウンロードおよびインストールするための機能ですが、IE7 の配信の際には、ユーザーにインストールの有無を選択していただけるようにします。

詳しくは IE7 to be distributed via Automatic Updates!?をご覧ください。

なお、この自動更新での提供ですが、日本では IE7 の最終版のリリース後、６ヶ月経過した後に開始する予定です。これは、Windows XP SP2 をリリースした際に、ユーザーの方々からいただいたフィードバックを元に判断させていただいた結果です。特に、企業ユーザーの方に十分な評価をしていただき、準備ができてから、自動更新での提供をさせていただきます。

また、IE7 の自動更新を無効にするツールの提供も別途行います。企業ユーザーの方などで、IE7 の適用を独自に計画されている場合には、このツールを用いて、自動更新を無効にすることができます。このツール、Blocker Toolkit は http://go.microsoft.com/fwlink/?linkid=65788?からダウンロードすることができます。

IE7 最終版のリリースまでに、是非とも自社のサイトやアプリケーションなどのチェックを引き続き、行っていただき、その後の IE7 の自動更新の用意を進めていただけるようにお願いします。

マイクロソフト
及川卓也

衛藤です。

Windows Vista Beta2 の Desktop Search がハードディスクの空き容量を大量に消費してしまうという既知の問題があります。これは *ntfy.gthr というファイルがきちんとクリーンアップされないことがあるためです。ハードディスクの容量にもよりますが数十GB というサイズを消費するケースがあります。回避策としては、ご面倒ですが以下の手順で手動でこれらのファイルを削除して頂く必要があります。

1. コマンド プロンプトを起動します。
2. cd E:\ProgramData\Microsoft\Search\Data\Applications\Windows\Projects\SystemIndex
3. すべての .gthr ファイルを削除します。(例: SystemIndex.Ntfy7.gthr)
4. もしファイルが使用中で削除できない場合は、そのファイルはスキップしてください。使用中のファイルはシステムによって使用されているファイルですので削除する必要はありません。削除できるファイルがハードディスク容量を消費している犯人です。

この問題は、RC1 では解決されます。テクニカルベータに参加している場合は、Build 5472 以降の最新のビルドを入手していただくことで解決されます。

及川です。

「Windows Vista ベータ２におけるヘルプの機械翻訳パイロット」で紹介したように、Windows Vista 日本語版ベータ２では機械翻訳したヘルプを提供しています。この機械翻訳パイロットに関して、アンケートを開始いたしました。アンケートサイトはこちらです。

お手数ですが、マイクロソフトの今後の機械翻訳の利用についての参考とさせていただきますので、ご協力いただけますよう、お願い申し上げます。

• アンケートサイト: http://go.microsoft.com/?linkid=5165342
• アンケート締め切り ： 8 月 29 日 23 時 59 分

マイクロソフト
及川卓也

初めまして。上鶴と申します。

Channel 9というサイトをご覧になったことがありますか？MSDN Webサイト中にある、マイクロソフト社員によるビデオブログです。
US本社やロシア等の関連会社の社員の投稿はすでに数多く蓄積されてきていますが、日本のマイクロソフトでもこれから積極的にエンジニア自身の言葉＋アクション＋αによるブログを投稿していこうとしてがんばっています。（日々の努力については、こちらのChannel 9担当者ブログをご覧ください。）

ウィンドウズ開発統括部でも投稿に向けて撮影を開始しました。すでにActive Directory、IE7、Windows Rally等の担当者自身によるブログ撮影が終わっていますので、編集校閲作業の完了次第、続々とアップロードされる予定です。

さて、7月13日(木)には、このブログでおなじみの及川さんが登場するブログの撮影を行いました。今回はChannel 9@Japan始まって以来初めての、『外部の識者との対談』です。ゲストは、及川さんの旧友でもあるグローバル ナレッジ ネットワーク株式会社 取締役の横山哲也氏にご登場をお願いしました。主にWindows周辺のトピックについての対談でしたが、ときに脱線し、昔ばなしやコマンドラインの話へ・・・。当初15分程度の予定が、終わってみたら44分が経過していました。第1部と第2部に分割してアップロードされることになりそうです。

おそらく脱線部分も、Channel 9オーディエンスの方々が楽しめる内容になっていると思いますので、アップロードされる日をお楽しみに。（このブログで随時お知らせいたします。）

及川です。

Windows Vista （もしくは Windows Server "Longhorn"） を評価されている方なら、もう気付かれていると思いますが、（ファイルの属性を変更して、）テキストエディタでブート構成ファイル（boot.ini）を修正する必要はもうありません。そう。２つ以上の OS をインストールした場合やブートパラメータを OS ローダーに引き渡す場合などには、メモ帳で boot.ini を変更することがあったと思います。Windows Vista ではその必要はありません。

Windows Vista では boot.ini に変わって BCD（ブート構成データ）と呼ばれるもので、ブート情報を管理しています。この BCD を変更するには、Windows XP などと同じように、システムのプロパティからも行えますが、Windows XP までの Bootcfg.exe にかわる BCDEdit.exe というユーティリティも用意されています。

Windows Vista の複数のバージョンを同一 PC にインストールすることや Windows XP と共存させることなどもあると思います。ブート情報の変更が必要になることもあると思いますが、その際には、boot.ini ではなく BCD の変更が必要になるということを思い出していただければと思います。

詳しくは、ブート構成データ エディタについてよく寄せられる質問をご覧ください。

マイクロソフト
及川卓也

及川です。

Windows Vista の TCP/IP ネットワークではルーティングコンパートメントという新機能が実装されています。Windows Vista Product Guide では、この機能は次のように説明されています。

仮想プライベート ネットワーク (VPN)、ターミナル サーバー、およびマルチユーザー ログオン構成インターフェイス間の望ましくないトラフィック転送を防ぐため、次世代の TCP/IP スタックはルーティング コンパートメントをサポートしています。ルーティング コンパートメントは、個別の IP ルーティング テーブルを持つ単一のログイン セッションとインターフェイス セットの組み合わせです。 1 つのコンピュータは互いに分離した複数のルーティング コンパートメントを持つことができます。各インターフェイスは、単一のコンパートメントにのみ属すことができます。たとえば、現在の TCP/IP スタックを使用してユーザーがインターネットを通過する VPN 接続を開始した場合、ユーザーのコンピュータは IPv4 ルーティング テーブル内のエントリを操作して、インターネットとプライベート イントラネットの両方に部分的な接続を確立します。ある状況では、インターネットからのトラフィックが、VPN 接続を越えてプライベート イントラネットに転送される可能性があります。次世代の TCP/IP スタックのルーティング コンパートメントでは、個別の IP ルーティング テーブルを使用することによって、プライベート イントラネット接続からインターネット接続を分離します。

ここには書かれていませんが、簡単に言うと、このルーティングコンパートメントはいわゆる「マルチホーミング」環境における問題の解になります。マルチホーミング環境はいろいろな種類があります。実際に複数のキャリアさん/プロバイダさんからネットワークを複数敷設している場合などありますが、ここではもっと身近な例をあげて説明しましょう。

もっとも一般的な例としては、ターミナルサービスや FUS (Fast User Switching) による複数ユーザーの VPN 環境になります。たとえば、あるユーザーがターミナルサービス上のセッションで VPN 接続をしたとします。VPN 接続されたことにより変更されたルーティングテーブルは Windows Vista/Windows Server "Longhorn" より前の現行の Windows では、システムで共有されます。したがって、あるユーザーの VPN 接続がほかのユーザーのネットワーク利用に影響を与えることになってしまいます。同じことは FUS においても言えます。FUS、すなわち、あるユーザーがログオフすることなく、ほかユーザーに切り替える機能ですが、現行の Windows では、切り替えられる前のユーザーによる VPN 接続がほかのユーザーのネットワーク接続に影響を与えます。Windows Vista/Windows Server "Longhorn" では、ルーティングコンパートメントにより、ルーティングテーブルがユーザーのログオンセッションごとに保持できるようになりますので、あるユーザーの VPN 接続がほかユーザーに影響を与えることはなくなります。これがルーティングコンパートメントの威力を理解する、もっともわかりやすい利用シーンかと思います。

もしかしたら、Windows XP の FUS などで PC を共有していた際に、わざわざルーティングテーブルを書き換えていたという方がいらっしゃるかもしれませんが、Windows Vista ではもうその必要はありません。

もし興味のある方はお試しいただけると幸いです。

マイクロソフト
及川卓也

及川です。

昨日は JANOG18 Meeting に参加してきました。

初めての参加だったのですが、Meeting と呼ばれている理由がよく分かりました。会場からの活発な質問にまず感激しました。また、それも、会場の出席者（参加者とは言わないそうです）からスピーカーへの一方通行の質問ではなく、時にはスピーカーのほうから問題提起させてもらい、会場の出席者と議論をすることもできます。出席者間で話し、ある程度の提案にまとまることも。非常に刺激的な Meeting でした。

私が参加させていただいた「ほっといたらIPv4運用に影響するIPv6の話」では、ネットワークオペレータからの観点での Windows への疑問や意見をいただくことができましたので、今後の製品開発での参考させていただく予定です。また、ここでの議論の内容については、資料が公開されるタイミングでまた紹介させていただきます。

通常、マイクロソフトに勤務していると、マイクロソフト製品をすでにお使いいただいているお客様やパートナーの方々とお話する機会は多いのですが、違うドメインの方々とじっくり話し合う機会はあまりありません。今回は JANOG 様から貴重な機会をいただくことができ、とても感謝しております。今後も、同様の機会がありましたら、積極的に参加するようにしたいと思います。

マイクロソフト
及川卓也

及川です。

IE7 ベータ３の日本語版がリリースされました。以前の投稿に書いたように、ベータ２からいくつかのバグ修正とともに、新機能も搭載しております。こちらからダウンロードできます。

また、前回のベータ２ではリリースノートの翻訳が遅れてしまいましたが、今回は同時に日本語版リリースノートを用意することができました。こちらからご参照ください。

なお、以前の投稿にも書かせていただかせていただきましたが、IE7 ベータ３を搭載した Windows Vista については次回の Windows Vista の評価版の公開をお待ちください。

Web サイトやアプリケーションの互換性の確認および対応について、是非、新しいベータ３で進めていただけるように、お願いいたします。

マイクロソフト
及川卓也

及川です。

Windows 上にアプリケーションをインストール際に必要な確認事項とその方法はアプリケーションによってまちまちだと思いますが、マイクロソフトのアプリケーションではどうやっているのかと興味を持つ方もいらっしゃると思います。ちょうど、Aaron Stebner's WebLog?で「Pre-installation checks performed by .NET Framework 2.0 setup」と題した投稿がありました。これは .NET Framework 2.0 のセットアップが行っているチェック事項とその方法を紹介したものであり、多くの Windows アプリケーション開発者の方に参考になると思いますので、ここでざっとポイントだけを紹介します。

セットアップが単一のインスタンスしか起動されていないかの確認

つまり、同時に２つ以上のセットアップが起動されていないかどうかの確認ですが、.NET Framework 2.0 ではセットアップの最初で Mutex を取得しており、それによりほかにセットアップを起動しているプロセスがいないかどうかを判断しています。

管理者権限の有無の確認

.NET Framework 2.0 では KB118626 に記されている内容にしたがって、管理者権限の有無を確認しています。

OS バージョンチェック

OS のバージョンチェックには GetVersionEx() を使っています。もし、OSVERSIONINFO 構造体の dwPlatformId メンバーが VER_PLATFORM_WIN32_WINDOWS だったならば、OS は Windows 9x なので、バージョンチェックは終了です（Windows 9x をサポートしないため）。

dwPlatformId が VER_PLATFORM_WIN32_NT だったならば、OSVERSIONINFO の dwMajorVersion と dwMinorVersion メンバーを確認します。

dwMajorVersion が５より小さいならば、Windows NT 4.0 以前の OS であることがわかります（.NET Framework 2.0 では Windows NT 4.0 以前の OS はサポートしないので、ここでセットアップは終了です）。

dwMajorVersion が５以上ならば、Windows 2000 以降の OS であることがわかります。正確に OS のバージョンを把握するには、以下のように dwMajorVersion と dwMinorVersion を使って判断します。

• Windows 2000: dwMajorVersion =5 かつ dwMinorVersion =0 の場合
• Windows XP: dwMajorVersion =5 かつ dwMinorVersion =1 の場合
• Windows Server 2003: dwMajorVersion=5 かつ dwMinorVersion =2 の場合
• Windows Vista 以降: dwMajorVersion=6

６４ビット OS チェック

６４ビット OS かどうかの判断が必要なのは、３２ビット版のアプリケーションが WOW64 環境で動作していないかを判断するときです。.NET Framework 2.0 の場合は、３２ビット版と６４ビット版の両方が用意されているので、６４ビット OS では６４ビット版の .NET Framework をインストールする必要があります。

このチェックのためには、GetSystemWow64Directory() を呼びだします。この呼び出しが成功し、適切なパスが返ってきたならば、現在、６４ビット OS で WOW64 環境で動作していることがわかります。

逆に、３２ビット環境で６４ビットのアプリケーションのインストールを試みた場合への対処は特に必要ありません。なぜならば、３２ビット環境では６４ビットアプリケーション（インストーラー）は動作しないからです。

Windows インストーラーのバージョンチェック

Windows インストーラーのバージョンをチェックするには、まず、次のレジストリを確認することで、MSI.DLL の場所を特定します。

• キー名前: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer
• 値の名前: InstallerLocation
• 値のデータタイプ: REG_SZ

セットアップは次にここで得られた MSI.DLL のパス名を元に、実際に DLL をロードし、DLLGetVersion() によってバージョンを取得します。

すでに同一アプリケーションがインストールされていないかのチェック

すでに同一アプリケーションがインストールされていないかのチェックには、MSI のプロダクトコードを取りだして、それを MsiQueryProductState() に渡します。INSTALLSTATE_DEFAULT が返却されたら、新しくアプリケーションをインストールするのではなく、構成変更モードに入ることになります。

そのほかのチェック

そのほかにも「Pre-installation checks performed by .NET Framework 2.0 setup」の投稿では、.NET Framework 2.0 が OS の一部としてすでにインストールされていないか（現段階では、その可能性があるのは、Windows Vista だけですが）や IE のバージョンチェック、以前のベータ版がインストールされていないかのチェックなどについて紹介されています。

Windows Vista に向けてのアプリケーション開発でも、Windows XP や Windows Server 2003 といった OS もサポートするケースは多いでしょう。また、Windows インストーラーなどのほかコンポーネントのバージョンに依存がある場合も多いと思います。アプリケーションのセットアップの作法はいろいろなところで紹介されていますので、「Pre-installation checks performed by .NET Framework 2.0 setup」で紹介されているのが絶対ではないと思います。ですが、マイクロソフトの代表的なソフトウェアである .NET Framework がセットアップ時にどのようなチェックをしているかを知ることは、皆様のアプリケーション開発の参考にきっとなるでしょう。

マイクロソフト
及川卓也

及川です。

以前、紹介した Windows Security and Directory Services for UNIX v1.0 がリリースされています。ダウンロードはこちらから。もしくは TechNet サイトでオンラインでお読みください。

及川です。

いくつか質問をいただいていることもありますので、IE7 でフィッシングサイトと誤判定された場合の対処について解説させていただこうと思います。

まず、証明書を使った SSL サイトである場合には、その証明書が Windows の証明書ストアにルート証明書が保存されているかどうかを確認してください。ルート証明書が保存されていない場合には、フィッシングサイトの問題とは別に警告が表示されますので、これは以下で説明するホワイトリストへの登録とは別に解決されなければいけません。

証明書について、もう少し補足すると、たとえばログオンが必要な Web 画面で SSL を使っているとした場合、ログオンサイトの SSL 証明書とログオン後の画面で使われている SSL 証明書が異なっているようなことが無いかも確認する必要があります。SSL の有無が混在していたり、SSL の証明書が異なっているような場合には、フィッシングサイトと検出される可能性があります。

また、外部コンテンツを含めている場合には、そのリンク先のコンテンツがフィッシングサイトと疑われる要素を持っていないかを確認する必要があります。

以上を確認しても、サイト側に問題が無い場合は、誤検出の可能性が高いので、IE7 の [ツール] - [フィッシング詐欺検出機能] - [この Web サイトを報告する] から報告してください。

アンチフィッシング ホワイト ペーパー?もあわせて参照お願いします。

マイクロソフト
及川卓也