Windows Vista® および Windows Server® 2008 アプリケーション互換性解説書

Microsoft Corporation

バージョン 6.6.jpn.1

   このドキュメントに記載されている情報は、将来予告なしに変更することがあります。
目次

はじめに
簡単な互換性チェック
オペレーティング システムのバージョニング
ユーザー アカウント制御
UAC - アプリケーション更新ガイドライン
UAC - COM のユーザー単位の構成
Windows リソース保護 (WRP)
Internet Explorer の保護モード
Windows 64 ビット
IIS 7
Microsoft GINA (Graphical Identification and Authentication)
セッション 0 の分離
ネットワーキング: TCP/IP スタックおよび Windows Filtering Platform
ネットワーキング: カーネル モード IP ヘルパー API
ネットワーキング: IPv6
互換性のリスク
Windows ディスプレイ ドライバ モデル
既定のプログラム
プログラム互換性アシスタント (PCA)
グラフィカル デバイス インターフェイス - GDI
ユーザー インターフェイス特権の分離 (UIPI)
高 dpi スケーリング
PNG アイコン
名前付きパイプの強化
SPAP の非推奨化 (Pstore)
WMI プロバイダ: 既定のセキュリティ ホスティング モデル
ボリューム シャドウ コピー サービス
Standard User Analyzer
DHTML 編集コントロール
ヘルプ エンジン サポート
接合点およびバックアップ アプリケーション
バックアップと復旧のアプリケーションの互換性
インターネットの検索機能との統合
MMC が DEP (Data Execution Protection: データ実行防止機能) 対応である必要性
ネットワーキング: Windows ファイアウォールの無効化
Windows Server® 2008 に関連する問題
読み取りRead Only専用ドメイン コントローラ (RODC)
Windows Server® 2008 の役割
Windows Server® 2008 での Windows アプリケーションのエクスペリエンス
Windows Server® 2008 Server Core
Windows Server® 2008 の Windows Server フェールオーバー クラスタリング
ネットワーキング: Windows Server® 2008 で既定で有効の Windows ファイアウォール

はじめに

Windows Vista® および Windows Server® 2008 には、世界中のアプリケーション開発者や企業によって使用される、次世代オペレーティング システム テクノロジおよびソフトウェア開発プラットフォームが導入されています。Windows Vista® および Windows Server® 2008 のセキュリティおよびユーザー エクスペリエンスの拡張の一環として、新機能が多数導入され、既存の機能が改善されました。

Windows Vista® および Windows Server® 2008 は、Microsoft® Windows® XP、Microsoft Windows Server™ 2003、およびそれらの Service Pack 用に作成されたほとんどのアプリケーションと高い互換性を持っていますが、革新的な新機能、セキュリティの強化、信頼性の向上によって互換性が損なわれてしまう部分がないとは言えません。全体的に見ると Windows Vista® および Windows Server® 2008 の互換性は高く、マイクロソフトは、既存のアプリケーションを Windows Vista® および Windows Server® 2008 で使用するための最高の互換性を持つソリューションの実現に向けて常に努力しています。

このドキュメントは、アプリケーション開発者がアプリケーションの互換性の検証方法を理解するための第一歩となります。また、ここでは、Windows Vista® および Windows Server® 2008 におけるアプリケーションの非互換性に関する少数の既知の問題の概要について説明し、詳細なホワイト ペーパーなどの開発者向けのガイダンスへのリンクを記載しています。

アプリケーションが Windows Vista® および Windows Server® 2008 で正常に機能しない場合に開発者がトラブルシューティングや回避を行うには、いくつかの新機能があります。次の 2 つの機能が特に便利です :

  • Windows XP SP2 互換モードでは、アプリケーションを Windows XP SP2 上で動作しているように動作させることができます。アプリケーションをこのモードで実行するには、アプリケーションの EXE またはアイコンを右クリックして [プロパティ] を開き、[互換性] タブをクリックし、[互換モードでこのプログラムを実行する] チェック ボックスにチェックを入れ、[Windows XP (Service Pack 2)] を選択します。

  • ユーザー アカウント制御 (UAC) によるセキュリティ上の制限によって、管理者権限を必要とするアプリケーションが、たとえそのユーザーが Administrators グループのメンバであっても、正しく動作しなくなることがあります。この UAC の影響を受けないようにするために、管理者権限を持っているユーザーであれば、次の方法でアプリケーションを権限を昇格して実行することが可能です。アプリケーションの EXE またはアイコンを右クリックし、コンテキスト メニューから [管理者として実行] をクリックします。UAC のダイアログが表示されたら [許可] をクリックし、適切な権限でアプリケーションを実行します。

注   このドキュメントに記載されているすべての項目は、特に断りのない限り、Windows Vista® および Windows Server® 2008 の両方に適用されます。Windows Vista SP1 ではアーキテクチャの変更はありません。Windows Vista RTM と互換性のあるアプリケーションは、Windows Vista SP1 とも互換性があります。

簡単な互換性チェック

ここでは、Windows Vista® または Windows Server® 2008 でアプリケーションの互換性をテストし、評価する方法に関するガイダンスを提供します。Windows Vista® および Windows Server® 2008 で互換性をテストする場合、次のような 2 つの主要なシナリオがあります。

Windows Vista のクリーン インストール時にテストする場合

  1. テスト用のコンピュータに Windows Vista® または Windows Server® 2008 をインストールします。

  2. テスト用のコンピュータにアプリケーションをインストールします。アプリケーションのインストール許可を求めるプロンプトが表示されたら、[許可] をクリックして次に進みます。正常にインストールできたら、手順 6 に進みます。

  3. アプリケーションのインストールが失敗し、インストール許可のプロンプトが表示されなかった場合は、インストーラの EXE を右クリックし、[管理者として実行] を選択して、アプリケーションを再インストールします。インストールが正常に完了したら、手順 6 に進みます。

       MSI でインストールする場合、この手順は不要です。
  4. OS バーション、CLSID の登録、ファイルのコピーなどのエラーが発生した場合は、インストーラの EXE を右クリックし、[互換性] タブをクリックして、Windows XP SP2 互換モードを選択します。

  5. 手順 2 に戻ります。アプリケーションがインストールできなかった場合は、手順 9 に進みます。

  6. これでアプリケーションのインストールが完了しました。

  7. アプリケーションを起動します。アプリケーションが正常に起動しなかった場合やエラーが表示される場合は、Windows XP SP2 互換モードをアプリケーションの EXE に適用してから再試行します。

  8. アプリケーションが正常に起動したら、Windows XP のアプリケーションで通常行われるテストをすべて実施します。アプリケーションの機能を検証し、アプリケーションが正常に動作することを確認します。主要な機能テストのすべてに問題がなければ、手順 10 に進みます。

  9. アプリケーションがインストールできない、正常に起動しない、クラッシュする、エラーが発生する、主な機能テストに失敗するなどの問題がある場合、アプリケーションの一部が Windows Vista® の変更の影響を受けている可能性があります。このドキュメントのトピックでアプリケーションを確認してください。

  10. これでシナリオは終了です。

Windows XP Service Pack 2 から Windows Vista にアップグレードしたシステムで時にテストする場合

  1. テスト用のコンピュータに Windows XP SP2 をインストールし、アプリケーションをインストールします。処理を行う前に、アプリケーションのすべての機能を検証します。

  2. テスト用のコンピュータを Windows Vista にアップグレードします。Windows Vista のセットアップおよびアップグレードの手順に従います。アップグレードが完了したら、 Windows XP と同じ方法でログオンします。

  3. アプリケーションを起動します。アプリケーションが正常に起動しない場合、またはエラーが表示される場合、Windows XP SP2 互換モードをアプリケーションの EXE に適用してから再試行します。

  4. アプリケーションが正常に起動したら、Windows XP のアプリケーションで通常行われるテストをすべて実施します。アプリケーションの機能を検証し、アプリケーションが正常に動作することを確認します。主要な機能テストのすべてに問題がなければ、手順 6 に進みます。

  5. アプリケーションがインストールできない、正常に起動しない、クラッシュする、エラーが発生する、主な機能テストに失敗するなどの問題がある場合、アプリケーションの一部が Windows Vista® および Windows Server® 2008 の変更の影響を受けている可能性があります。このドキュメントのトピックでアプリケーションを確認してください。

  6. これでシナリオは終了です。

2つのシナリオを実行し、アプリケーションが正常に動作すれば、アプリケーションは Windows Vista® および Windows Server® 2008 で正常に機能します。アプリケーションの証明書を取得する方法の詳細については、Windows Vista のホームページを参照してください。

その他のリソースへのリンク

オペレーティング システムのバージョニング

機能の影響

概要

Windows Vista® および Windows Server® 2008 の内部バージョンは 6 です。GetVersion 関数を使用したクエリでは、アプリケーションにこのバージョン番号を返します。

   これは、Windows XP (Version 5.x) の次のメジャー バージョン番号です。

現象

このバージョン変更は、次のような、きわめてアプリケーションに固有の現象を示します。

  • OS のバージョンを厳密にチェックするアプリケーションでは、より高いバージョン番号を取得することになります。

  • アプリケーション インストーラがアプリケーションのインストールを中止する場合や、アプリケーション自体が起動を停止する場合があります。

  • アプリケーションがユーザーに警告を出して、引き続き正常に機能する場合があります。

  • アプリケーションによっては、不安定になったり、クラッシュしたりする可能性があります。

軽減策

Windows Vista® および Windows Server® 2008 のアプリケーション互換性は非常に高いため、ほとんどのアプリケーションが Windows Vista® および Windows Server® 2008 で正常に機能します。Windows Vista® および Windows Server® 2008 には、OS バーションをチェックするアプリケーションおよびインストーラ用に互換モードが用意されています。

ユーザーは、ショートカットか EXE を右クリックして、[互換性] タブで Windows XP SP2 互換モードを適用できます。これによって、ほとんどの場合、アプリケーションは Windows XP 上と同じように機能します。この場合、アプリケーションを変更する必要はありません。

対処策

  • 通常は、OS バージョン チェックが実行されないようにするか、少なくともアプリケーションがバーション 6 以降の OS で常に実行できるようにします。非常に特殊な法律またはビジネス関係のコンポーネントやシステム コンポーネントでバージョン チェックが必要でない限り、この方針に従います。

  • 64 ビットのシステム互換性を保証するために、16 ビットのアプリケーション インストーラは使用しません。

  • マルチ プラットフォーム (32 ビットと 64 ビット) の互換性を維持するために、アプリケーションで使用するドライバにはできる限りユーザー モード ドライバを使用してください。

ユーザー アカウント制御

標準ユーザーの変更

機能の影響

概要

Windows のセキュリティを高めるための根本的な方法は、インタラクティブ ユーザーが、限定的な許可や権限のセットにしかアクセスできない標準ユーザー アカウントで実行できるようにすることです。既定では、ユーザーが管理者グループのメンバーとしてログオンしていても、Windows Vista® および Windows Server® 2008 ではすべてのアプリケーションを標準ユーザーとして実行します。逆に、管理者の許可が必要とされているアプリケーションをユーザーが起動しようとすると、システムは明示的にユーザーの目的を確認しようとします。管理者権限で実行しているアプリケーションのみが、システムとグローバルの設定と動作を変更できます。この Windows Vista® および Windows Server® 2008 の機能が、ユーザー アカウント制御 (UAC) です。

現象

  • カスタム インストーラ、アンインストーラ、およびアップデータが検出されず、管理者として実行するために昇格できない場合があります。

  • 標準ユーザー アプリケーションがタスクの実行に管理者権限を必要とする場合、アプリケーションに障害が発生するか、あるいは標準ユーザーがこのタスクを利用できないことがあります。

  • 現在のユーザーが必要な許可を持っていない場合、タスクを実行しようとするアプリケーションに障害が発生することがあります。障害がどのように表れるかは、アプリケーションの作成方法によって異なります。

  • 管理タスクやシステム全体に影響を及ぼす変更を行うコントロール パネル アプリケーションが、正常に機能せず、エラーが発生することがあります。

  • RunDLL32.EXE を使用して実行される DLL アプリケーションが、グローバル操作を実行する場合に正常に機能しないことがあります。

  • 標準ユーザー アプリケーションがシステム全体の設定の保存場所に書き込みを行うと、仮想化によってユーザーごとの設定の保存場所にリダイレクトされます。

対処策

カスタム インストーラ用の解決策
  • インストーラまたはアップデータを起動するには、右クリックして [管理者として実行] をクリックします。

  • アプリケーション互換性修正プログラムを適用し、特定のインストーラが昇格を必要とすることを示します。そのためには、ショートカットまたは EXE を右クリックし、[互換性] タブから Windows XP SP2 互換モードを適用します。

システムの変更や、権限が設定された領域への書き込みに管理者権限が必要なアプリケーション用の簡単な解決方法
  • 企業ユーザーは、アプリケーション互換性修正プログラムを適用し、レガシ アプリケーションを正常に実行するためには管理者の許可や管理者権限が必要であることを示すことができます。

  • 一定の制限されたファイルについてアクセス制御リスト (ACL) の制限を軽減すると、アプリケーションがこれらのファイルへの書き込みを行いやすくなる場合があります。

  • 仮想化フォルダやレジストリ キーをチェックして、アプリケーションが管理者権限を必要とするものにアクセスしているかどうか確認します。この情報を利用して、アプリケーションの将来のバージョンから、管理者によって保護された場所へのアクセス要求をなくすことができます。仮想化ファイルやフォルダ、場所の詳細については、「シェル: テーマとマイ ドキュメントの場所」を参照してください。

  • 別の EXE に RunDll32.exe による DLL の呼び出しを含め、この EXE のマニフェストで、権限の昇格を要求します。

互換性テスト
  • すべてのインストール、アンインストール、更新のシナリオにおいて、ユーザーに同意または資格情報の入力を求めるようにします。ユーザーの同意が受理されると、操作が次に進みます。

  • エラーが発生したシナリオを組み込み管理者として再現します。このシナリオが成功した場合、エラーの原因は権限の不足によると考えられます。

  • アプリケーション互換性ツールキットの Compatibility Administrator の ユーザー アカウント制御予測ツール (User Account Control predictor tool) を使用して、管理者操作を行っているアプリケーションの領域を識別します。

Windows Vista® および Windows Server® 2008 に対応した解決策の活用
  • Windows Vista® および Windows Server® 2008 ベース アプリケーションでは、以下を実行する必要があります。

  • Windows Vista® および Windows Server® 2008 のロゴ プログラムにある所定のガイドラインおよびユーザー エクスペリエンス (UX) ガイドラインなどのドキュメントに従います (「リンク」セクションを参照)。

  • 埋め込みマニフェストを使用して、特定の requestedExecutionLevel (以前は RunLevel) を示します。

  • 管理機能と非管理機能をすべて別の EXE に分けます。より高い権限が必要なすべての機能は、実行レベルが明示された別の実行可能 EXE ファイルや管理者権限で実行される COM オブジェクト内に格納します。管理タスクは必要な場合にのみ起動します。これはすべてのアプリケーションに当てはまります。

  • 特に管理機能を持たないアプリケーションの場合は、管理者の許可や管理者権限を必要としないようにコードを修正します。

  • 管理者のみが使用するアプリケーションの場合は、アプリケーションが管理者の許可や管理者権限を使用して実行されるようにマークします。

  • アプリケーションを更新するときは、別のアップデータ EXE を使用してターゲット アプリケーションを更新します。

  • コントロール パネル アプリケーションは .cpl ファイルから .exe ファイルに置き換え、EXE 形式のコントロール パネル アプリケーションには、必要な実行レベルを指定したマニフェストを含めます。

  • 昇格が必要な RunDLL32.EXE で実行する DLL は、マニフェストに示された昇格レベルで、実行可能な EXE に変更します。

  • 可能な場合は、常に読み取り専用でファイルやレジストリ キーにアクセスします。読み取り/書き込みモードでのアクセスは必要な場合のみ使用し、操作が完了したら、許可を元の読み取り専用に戻します。

その他のリソースへのリンク

UAC - アプリケーション更新ガイドライン

機能の影響

概要

既存の多くのアプリケーションには、更新機能が組み込まれています。更新機能を組み込む目的は、ISV が提供できる最新のバイナリをクライアントが実行していることを保証することです。

アプリケーションの中には、更新機能を実行するときに、標準ユーザー以上の権限を必要とするものがあります。多くの場合、インストール中に保存されたコンピュータ単位のファイルを使用可能にする必要があります。インストール アプリケーションを実行するための UAC モデルのように、これらの処理を実行するために十分な権限を持っているのは、高い権限を持つ管理者承認モードでの管理者だけです。

Windows Vista® および Windows Server® 2008 の、経験則に基づくインストーラの検出機能は、多くのアプリケーションのアップデータを正しく検出し、更新が正常に完了するように、アップデータのプロセスの権限を適切に昇格します。ただし、次のようにアプリケーションの更新を正常に完了できない部分も少し残ります。

  • インストーラの検出機能で検出されないプロセス外のアップデータ。経験則に基づくインストーラの検出機能を通しては検出されないアップデータです。

  • 多目的実行可能ファイルおよびプロセス内の更新。複数の処理を実行する負荷が過剰な実行可能ファイルです。たとえば、バイナリがメインのアプリケーションでもあり更新アプリケーションでもある場合や、多目的実行可能ファイルがアプリケーション内のスレッドとして実行される場合などです。

現象

  • アプリケーションの更新機能で障害が発生します。

対処策

インストーラの検出機能で検出されないプロセス外のアップデータ

これは、どの企業でも起こり得る問題で、結果として、管理者権限でのアプリケーションの実行を企業が要求する可能性があります。インストーラが検出しない別のプロセスを使用してアプリケーションが自分で更新を行う場合、App Fix を使用して、この別のプロセスを管理者権限が必要であるものとして設定します。

ユーザーとして機能しないアップデータの場合、企業は最小特権では実行できません。

  • アップデータは、管理者権限を必要とするという希望の実行レベルを持つ別のプロセスとして記述します。

  • このプロセスは、更新のために必要な場合にのみ実行します。

  • ユーザーとしてプログラムの更新が必要かどうかをチェックします。

多目的実行可能ファイルおよびプロセス内の更新

Windows Vista® および Windows Server® 2008 では、実行可能ファイルが実行される状態を切り替えられないため、更新を行う多目的実行可能ファイルを作成する良い方法はありません。したがって、実行可能ファイルは常に管理者として実行する必要があります。あるいは、アプリケーションから以下のいずれかの方法で更新を行います。

  1. MSI のパッチ技術の利用 (Windows Installer、InsallShield、Wise for Windows Installer などの最新バージョンでサポート)

    1. MSI は、更新の管理機能を提供する重要なインストーラ技術です。

      1. MSI を使用して初期インストーラを作成し、MsiPatchCertificate テーブルに証明書を埋め込みます。

      2. アプリケーションの更新を作成し、先ほど指定した証明書を使用して署名します。

      3. MSI は、パッチを適用するときにアプリケーションを昇格します。

      4. この方法の主な利点は、標準ユーザーで実行可能であり、システムの安全な状態を保持できることです。標準ユーザー アカウントから管理者へのパッチのインストールの依頼や、アプリケーションを実行するための永続的な管理者権限の要求を行う必要がなくなるため、より快適なユーザー エクスペリエンスが実現されます。

  2. その他のカスタム インストーラ メカニズムの使用

    1. ユーザーが管理者以外としては実行できなくなるため、エンタープライズ環境ではお勧めしません。

    2. アップデータは、requiresAdministrator という希望の実行レベルを持つ別のプロセスとして記述する必要があります。

      1. このプロセスは、更新のために必要な場合にのみ実行します。ユーザーとしてプログラムの更新が必要かどうかをチェックします。

  3. "標準ユーザー" アプリケーションとして実行中の更新

    1. ClickOnce 技術を使用すると、標準ユーザーとして更新できます。ここでも、ユーザーが内部でアプリケーションを展開することを可能にし、アプリケーション書き込みプログラムの更新を処理するのは、インストール プラットフォームです。

その他のリソースへのリンク

UAC - COM のユーザー単位の構成

機能の影響

概要

Component Object Model (COM) は、レジストリを利用してコンピュータにインストールされているすべての COM オブジェクトに関する情報を保持します。このレジストリ ハイブ (HKEY_CLASSES_ROOT) は仮想レジストリ ハイブであり、ユーザー単位およびコンピュータ単位のオブジェクトの登録が可能です。ユーザー単位の COM オブジェクトの構成は HKEY_CURRENT_USER\Software\Classes に格納され、コンピュータ単位の構成は HKEY_LOCAL_MACHINE\Software\Classes に格納されます。通常、ユーザー単位の COM 構成が優先されます。

Windows Vista® および Windows Server® 2008 以降は、プロセスの整合性レベルが中以上の場合、COM ランタイムはユーザー単位の COM 構成を無視し、コンピュータ単位の COM 構成にのみアクセスします。これにより、標準ユーザーの権限を持つプロセスが任意のコードで COM オブジェクトを構成することが防止され、昇格されたプロセスからこのコードが呼び出されるので、特権の昇格による攻撃の対象が小さくなります。

現象

昇格して実行されるアプリケーション (requireAdministrator とマニフェストに示されている場合またはユーザーが右クリックして [管理者として実行] をクリックする場合)、および UAC が無効になっている Administrators グループのメンバであるアカウントから実行されるアプリケーションは、ユーザー単位で構成されているどの COM オブジェクトにもアクセスできません。

対処策

管理者の権限を必要とするアプリケーションでは、インストール時にすべての依存 COM オブジェクトをコンピュータ単位の COM 構成ストア (HKEY_LOCAL_MACHINE\Software\Classes) に登録するようにします。

その他のリソースへのリンク

Windows リソース保護 (WRP)

機能の影響

高 (アプリケーションのインストールや実行をブロック)

概要

Windows リソース保護 (WRP) は、システムの安定性、予測可能性、および信頼性を向上させるための主要な機能であり、特定の OS ファイル、フォルダ、およびレジストリ キーといった、仕様により構成不可能な Windows の読み取り専用リソースを保護します。保護されるリソースの詳細については、「Protected Resource List (英語)」を参照してください。

WRP は、リソースに特別なセキュリティ記述子を指定し、Windows セキュリティによってこの保護を実施します。管理者またはシステムとして実行するプロセスを含むあらゆるプロセスには、WRP リソースを変更する権限がなく、読み取りと実行のみが可能です。WRP リソースへのフル アクセスは、Windows モジュール インストーラ サービスに限定されています。

結果として、読み取り専用システムの状態は、アプリケーションのインストールや管理者の修正による意図しない影響から保護されます。これにより、システムの安定性が向上します。

現象

アプリケーションが、保護されている OS リソースの置換や変更に失敗 (通常、アプリケーションのインストールおよびアンインストール時に発生) し、以下のような結果が生じます。

  • WRP によって保護された OS のファイルやレジストリ キーの置換、変更、または削除を行うと、エラーが発生し、リソースを更新できなかったことを示すエラー メッセージが表示されます。このエラーはリソースへのアクセスが拒否されたために発生します。

  • 保護されたレジストリ キーに新しいレジストリ キーや値の書き込みを行うと、アクセスが拒否されてエラーが発生し、変更が失敗したことを示すエラー メッセージが表示されます。

  • 保護されたリソースへの書き込みにおいて、保護されたレジストリ キーやレジストリの値への書き込みをアプリケーションが正常に完了することを前提としている場合、書き込みを試行するとエラーが発生します。

アプリケーションは WRP リソースを変更することができず、関連エラーが抑制されるため、ランタイム エラーが発生します。

軽減策

   アプリケーションが UAC に必要な requestedExecutionLevel (英語) を指定するマニフェストを持つ場合は、以下の軽減策は当てはまりません。

既知のインストーラ (英語) では、WRP リソースの作成、修正、または削除を行う場合に発生するアクセス拒否エラーは抑制され、変更は WRP リソースに適用されません。

対処策

  • Windows Vista® および Windows Server® 2008 のシステム状態 (ファイルとレジストリ) をインストールまたは更新する場合は、必ず Windows Vista® および Windows Server® 2008 用に設計されたマイクロソフト提供の再配付可能なパッケージを使用してください。

  • Windows Vista® および Windows Server® 2008 用に設計されたマイクロソフト提供の再配布可能なパッケージのコンポーネントを個別にインストールしないでください。

  • SfcIsFileProtected API を使用して、WRP で保護されているファイルを検出します。ファイルが WRP によって保護されている場合、アプリケーションによるファイルのインストールや変更は行われません。

  • WRP によって保護されるレジストリ キーの場合、アプリケーションは WRP によって発生する "アクセス拒否" のメッセージを手順に従って処理する必要があります。

  • WRP の軽減策に依存するレガシ アプリケーションが、アプリケーションをインストールすることによって正常に動作することをテストして確認します。

  • SfcIsKeyProtected API を使用して、WRP で保護されているキーを検出します。キーが WRP によって保護されている場合、アプリケーションによるキーのインストールや変更は行われません。

WRP で保護されるキー

アプリケーションが WRP で保護されるキーの作成、修正、削除を行うと、そのアプリケーションには "アクセス拒否" エラーが通知されることが予想されます。"アクセス拒否" エラーが発生した場合、そのエラーはユーザーが対象キーへの適切な書き込み権限を所持していないためではなく、キー (または親キー) に対する WRP のセキュリティ記述子のために発生したことを確認します。

WRP によって発生した "アクセス拒否" エラー メッセージへの対処方法は、このエラーがアプリケーションに与える影響によって異なります。

  1. アプリケーションが既に存在するキーや値への書き込みを行った場合、アプリケーションはエラー メッセージを無視することができます。

  2. キーや値が存在しない場合は、開発者としてアプリケーションへの影響を判断する必要があります。このキーが Windows Vista でアプリケーションを正常に実行するために必要かどうかを考えます。必要でない場合は、エラーを無視することができます。このキーが必要である場合は、アプリケーションを再設計して代替キーに書き込むか、または別の設計を使用する必要があります。

リソースが WRP で保護されているかどうかを識別する方法

レジストリの場合:

  1. コードから、SfcIsKeyProtected API を使用します。

  2. あるいは、regedit を使用してキーのアクセス許可を確認します。

    • [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。

    • regedit」と入力し、[OK] をクリックします。

    • キーを検索します。レジストリ キーを右クリックします。[アクセス許可] をクリックします。

    • WRP で保護されるキーであれば、Trusted Installer のアクセス許可はフル コントロールです。SYSTEM、Administrators、および Users には読み取り許可しか与えられていません。

ファイルの場合:

  1. コードから、SfcIsFileProtected API を使用します。

  2. または、エクスプローラを使用してファイルのアクセス許可を確認します。

    • 確認するプロパティを持つファイルが格納されているフォルダを開きます。

    • 確認するプロパティを持つファイルを右クリックし、[プロパティ] をクリックします。

    • WRP で保護されるキーであれば、Trusted Installer のアクセス許可はフル コントロールです。SYSTEM、Administrators、および Users には読み取り許可しか与えられていません。

その他のリソースへのリンク

Internet Explorer の保護モード

機能の影響

概要

Windows Vista® および Windows Server® 2008 では、Microsoft® Internet Explorer 7 は保護モードで実行されます。Internet Explorer プロセスをかなり制限された権限で実行することによって、ユーザーを攻撃から保護することができます。保護モードでは、攻撃によるユーザーのコンピュータ上でのデータの書き込み、変更、または破壊や、悪意のあるコードのインストールの可能性を大幅に軽減できます。また、認証なしに自己インストールを行う悪性のコードからユーザーを保護できます。これは、Windows Vista® および Windows Server® 2008 をインストールしたときに、Internet Explorer の既定のモードとなります。

現象

  • Internet Explorer 7 を使用するアプリケーションがインターネット ゾーンまたはイントラネット ゾーンにある場合、ディスクに直接書き込むことができません。

  • アプリケーションで新しいプロンプトの処理方法が認識されないことがあります。

保護モードは、新しい整合性メカニズムに基づいて構築されており、整合性レベルの高いプロセス、ファイル、レジストリ キーといったセキュリティ オブジェクトへの書き込みアクセスは禁止されます。

Internet Explorer は、保護モードで実行される場合、整合性の低いプロセスになります。したがって、ユーザーのプロファイルやシステム ロケーションにあるファイルおよびレジストリ キーへの書き込みアクセス権限を取得できません。

整合性の低いプロセスは、整合性の低い必須ラベルが割り当てられたフォルダ、ファイル、およびレジストリ キーにしか書き込みを実行できません。したがって、Internet Explorer とその拡張機能が保護モードで実行されると、整合性の低い新しいインターネット一時ファイル フォルダ、履歴フォルダ、Cookie フォルダ、お気に入りフォルダ、一時ファイル フォルダなど、下位整合性レベルのロケーションへの書き込みのみが可能になります。

さらに、Windows Vista® および Windows Server® 2008 の出荷時では、保護モード プロセスはデスクトップの整合性レベルが低い状態で実行されます。これによって、保護モードで特定のウィンドウ メッセージが整合性の高いプロセスに送信されることを防止しています。

保護モードでは、ユーザーが使用するシステムの機密領域への未承認のアクセスが行われるのを防ぐことで、問題のある Internet Explorer プロセスやマルウェアによって発生する可能性のある被害を制限することができます。たとえば、攻撃者はユーザーのスタートアップ フォルダに対して、キーストロークの記憶プログラムを通知なしにインストールできません。同様に、セキュリティに問題のあるプロセスがウィンドウ メッセージによって、デスクトップ上でアプリケーションを操作することはできません。

もちろん、この防御策により、正当な変更もより整合性の高いロケーション (IL) に制限されます。結果として、保護モードは、次の図で示すように、互換性アーキテクチャによって既存の拡張機能への影響を少なくしています。

appcompat_01.gif
1: IE の保護モードの互換性アーキテクチャ


互換性レイヤは多数の既存の拡張機能の要求に対処します。これは、ユーザー プロファイルの My Documents フォルダや HKEY_CURRENT_USER レジストリ ハイブといった中間の整合性のリソースへの書き込みを遮断します。互換性レイヤは、汎用 Windows 互換性修正プログラムを使用して、これらの処理を整合性の低い次のロケーションに自動的にリダイレクトします。

  • %userprofile%\LocalSettings\Temporary Internet Files\Virtualized

  • HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\InternetRegistry

上位にある 2 つの特権ブローカー プロセスによって、Internet Explorer と拡張機能はユーザーの同意を得た上位処理を実行できます。たとえば、ユーザー特権ブローカー (IEUser.exe) プロセスは、ユーザーが整合性の低い領域以外にファイルを保存できる関数を備えます。さらに、管理者特権ブローカー (IEInstal.exe) プロセスでは、Internet Explorer は ActiveX コントロールをインストールできます。

対処策

解決策
  • 問題のサイトを信頼済みサイトの一覧に追加します。

  • 保護モードをオフにします (非推奨)。

互換性テスト
  • 解決方法を適用し、アプリケーションで該当機能を Windows XP SP2 と同じように実行できることを確認します。

Windows Vista® および Windows Server® 2008 に対応した解決策の活用

  • アプリケーションを変更して、関連プロンプトの表示などの保護モードを処理します。

その他のリソースへのリンク

Windows 64 ビット

機能の影響

概要

Windows Vista® および Windows Server® 2008 は、AMD および Intel の 64 ビット アーキテクチャ プロセッサを完全にサポートします。Windows Vista® および Windows Server® 2008 の 64 ビット バージョンでは、WOW64 エミュレータを使用して、すべての 32 ビット アプリケーションを実行できます。ただし、16 ビット アプリケーション、32 ビット インストーラ、および 32 ビット カーネル モード ドライバは、カーネルでサポートされていません。

64 ビット ドライバは、すべて Windows Vista® および Windows Server® 2008 64 ビット バージョン用にデジタル署名が必要です。署名のないドライバはサポートされません。また、64 ビットの Windows Vista® および Windows Server® 2008 にインストールすることもできません。デジタル署名の確認は、インストール時およびドライバのロード時の両方で行われます。

現象

  • 16 ビットの実行可能プログラム、16 ビットのインストーラ、32 ビットのカーネル ドライバを使用するアプリケーションまたはコンポーネントは、Windows Vista® および Windows Server® 2008 の64 ビット版では起動に失敗するか、正常に機能しません。この場合、次のエラー メッセージが表示されます。

    プログラムまたは機能 [exepath]\[app16bit].exe は、Windows の 64 ビット バージョンでの非互換性のために起動または実行できません。64 ビットの Windows 互換バージョンが使用可能かどうかについては、ソフトウェアの製造元にお問い合わせください。

  • 16 ビットのインストーラやアプリケーションを起動すると、次のようなエラー メッセージが表示されます。

    このファイルのバージョンは、実行中の Windows のバージョンと互換性がありません。必要なプログラムのバージョンが x86 (32ビット) または x64 (64ビット) のいずれであるかをコンピュータのシステム情報で確認し、ソフトウェア メーカーにご連絡ください。

  • 64 ビットシステムでは、32 ビットのカーネル ドライバのインストールは失敗します。インストーラによってレジストリを編集して手動でドライバを追加すると、このドライバがロードされないため、システムにエラーが発生する可能性があります。

  • 64 ビット システムでは、64 ビットの署名のないドライバのインストールは失敗します。インストーラによってレジストリを編集して手動でドライバを追加すると、署名のないドライバの場合はロード時にロードされません。

対処策

新しい機能に対応した解決策の活用
  • 16 ビットのコンポーネントをアプリケーションからすべて削除し、32 ビットまたは64 ビットの同等のアプリケーションと置換します。

  • 16 ビットのインストーラをすべて 32 ビットまたは 64 ビットのインストーラに変換します。

  • アプリケーションでカーネル モード ドライバが使用されている場合は、64 ビット バージョンのドライバを作成します。アプリケーションによって OS プラットフォーム (32 ビットまたは 64 ビット) を検出し、OS プラットフォームに基づいた適切なドライバ アーキテクチャをインストールします。

  • すべての 64 ビット ドライバがデジタル署名されていることを確認します。

互換性テスト
  • 32 ビットと 64 ビットの Windows Vista® および Windows Server® 2008 コンピュータにアプリケーションをインストールし、起動します。アプリケーションは通常、両方のアーキテクチャで正常に機能します。

その他のリソースへのリンク

IIS 7

機能の影響

概要

Internet Information Server 7 は、画期的な方法で Web アプリケーションの開発と管理を実現します。IIS 7 によりさまざまコンポーネントを細かく制御することができ、管理コストが削減され、セキュリティが向上し、開発が容易になります。

また、多くの面で、以前のバージョンよりも機能が強化されています。IIS 6 またはそれ以前のバージョン用に開発されたアプリケーションについて、その機能に影響を与える可能性がある変更点を以下に示します。

  • IIS はコンポーネント化され、セットアップは細分化されています。すべてのコンポーネントが既定でインストールされるわけではありません。NTLM は既定ではインストールされません。

  • ファイルのメモリへのバッファ処理は既定で有効になっています。

  • ISAPI の変更。

  • メタベースの変更 (バックアップ/復元、インポート/エクスポート)。

  • MMC スナップイン拡張機能は機能しません。

  • IIS をリセットしても W3svc は停止しません。W3svc を開始しても IISAdmin は開始されません。

  • Aspnet_regiis.exe は大幅に変更されました。

非推奨の IIS のコンポーネント

以下の IIS の機能は廃止され、IIS 7 では利用できません。

  • IIS 5.0 分離モード

  • メタベース アカウントの再作成 (チェッカー コード)

  • サブ認証 (パスワードの同期および古いダイジェスト認証)

  • 組み込みの Passport のサポート

  • Convlog.exe

  • クラスタ化 UI のサポート

  • IISRESET –reboot オプション

  • IIS シェル拡張

  • NNTP

  • ASP コンテンツ ローテータおよび Nextlink

  • サーバー側イメージ マップ

  • インターネット データ コネクタ (HTTPODBC.DLL)

  • URLContent Rating UI

  • 承認 ISAPI

  • パスワード変更コード

  • %windir%\system32 にある IIS*.VBS コマンド ライン ツール

  • WebDAV

  • Front Page Server Extensions

現象

  • 存在しないコンポーネントを使用するサイトは実行できない場合があります。

  • 非推奨のコンポーネントを使用するサイトは、変更しないと実行されません。

  • 非推奨の IIS メタベースに依存する管理ツールや管理方法は使用できなくなります。

  • 以前のバージョンとは異なり、W3SVC のサイクル処理のみでは問題が解決されない場合があります。

対処策

インストールされている IIS の機能を確認し、適切な動作を有効にするために必要な機能を有効にします。IIS 7.0 では、Web サーバーを軽量の Server Core と、これにプラグインすることができる 40 以上の機能モジュールに分割しています。これらのモジュールは、静的な Web コンテンツをダウンロードできるようにする StaticFileModule、統合された NTLM 認証をサポートする WindowsAuthModule などの必要な機能を個々に正確に提供できるように、サーバーに個別にインストールできます。

  1. IIS 7.0 には、分散 XML 構成ファイルの階層に基づいた新しい委任された構成システムがあります。これらのファイルは、クリーンで強固に構造化された XML ディレクティブを使用して、IIS と ASP.NET の構成を並行して保存できる、ポータブルな構成管理の方法を提供します。

    以前のバージョンのリセット機能を提供するには、IIS 7 関連サービスのサイクル処理が必要になる場合があります。再開時に各サービスをチェックして、再開を確認してください。

その他のリソースへのリンク

Microsoft GINA (Graphical Identification and Authentication)

機能の影響

高 (頻度: 低)

概要

サードパーティ サーバーへのログオンやサードパーティ デバイスによるログオンの場合、ISV は Windows Vista® および Windows Server® 2008 よりも前に Windows XP で、GINA (Graphical Identification and Authentication) のダイナミック リンク ライブラリを置換する必要がありました。Windows XP では、このようなアプリケーションはさらに既存の UI を置換し、スマート カードとリモート デスクトップ機能を実装する必要がありました。

   アプリケーションが Windows XP でこのように機能していなかった場合、この情報は該当しません。

Windows Vista® および Windows Server® 2008 では、LogonUI と WinLogon が直接相互に通信する新しい認証モデルが導入されています。このモデルは、GINA には存在しなかった簡潔性、スケーラビリティ、および柔軟性を備えています。GINA モジュールとは異なり、ISV はログオン画面の UI を置換する必要はなく、ユーザーのために UI を再作成する負担がなくなります。ISV は、資格情報プロバイダという LogonUI にプラグインするモジュールを作成し、UI を記述し、資格情報を収集して WinLogon に渡すことができます。資格情報プロバイダは、WinLogon に対して完全に透過的です。

また、資格情報プロバイダは追加式です。つまり、ユーザーは複数の資格情報プロバイダをインストールし、使用するプロバイダを選択できます。資格情報プロバイダは、ユーザーによる選択やイベント ドリブンが可能なモジュールです。Windows Vista® および Windows Server® 2008 では複数の資格情報プロバイダが共存できますが、サードパーティ用にのみ提供されているのではありません。実際には、Windows にはユーザー名とパスワードの資格情報プロバイダ、およびスマート カードの資格情報プロバイダという 2 つの資格情報プロバイダが搭載されています。

また、資格情報プロバイダは CredUI 内で再利用できます。つまり、LogonUI で資格情報を記述して収集するオブジェクトを使用して、CredUI のシナリオでまったく同じ資格情報を収集できます。

Windows XP と Windows Server 2003 の GINA 機能は非推奨となり、Windows Vista® および Windows Server® 2008 から削除されました。アプリケーションの GINA モジュールは機能しないため、Windows Vista® および Windows Server® 2008 の新しい認証モデルを使用して再作成する必要があります。

現象

  • カスタム ログオン アプリケーションを正常にインストールできなくなります。

  • Windows Vista® および Windows Server® 2008 でカスタム ログオン アプリケーション (Windows XP 技術を使用) を使用してログオンできなくなります。これには、バイオメトリック デバイス、ログオン用カスタム UI、カスタム ログオン UI を使用したリモート ユーザー向け仮想プライベート ネットワーク (VPN) ソリューションなどが含まれます。

対処策

新しい機能に対応した解決策の活用
  • GINA 技術を使用するアプリケーションやコンポーネントを再作成し、Windows Vista® および Windows Server® 2008 の新しいログオン認証モデルを使用する必要があります。

その他のリソースへのリンク

  • 資格情報プロバイダに関するすべての情報と質問については、Shell Credential Provider (credprov@microsoft.com) まで電子メールでお問い合わせください。

セッション 0 の分離

機能の影響

高 (頻度: 低)

概要

Windows XP、Windows Server 2003、および Windows オペレーティング システムの以前のバージョンでは、すべてのサービスはコンソールにログオンした最初のユーザーと同じセッションで実行されます。このセッションはセッション 0 と呼ばれます。サービスとユーザー アプリケーションをセッション 0 で同時に実行することは、セキュリティ上の危険をもたらします。この場合、サービスはより高い権限で実行されるため、悪意のあるエージェントが自身の権限レベルを昇格させる手段を探している場合、その標的となります。

Microsoft Windows Vista® および Windows Server® 2008 オペレーティング システムでは、セッション 0 のサービスを分離し、セッション 0 を非対話型にすることによって、このセキュリティ上の危険が軽減されます。Windows Vista® および Windows Server® 2008 では、システム プロセスとサービスのみがセッション 0 で実行されます。最初のユーザーはセッション 1 にログオンし、その後のユーザーはそれに続くセッションにログオンします。つまり、サービスがユーザーのアプリケーションと同じセッションで実行されることはないため、アプリケーション コードに起因する攻撃を防ぐことができます。

影響を受けるドライバ クラスの例としては次のものがあります。

  • スプーラ サービスによってロードされるプリンタ ドライバ

  • ユーザー モード ドライバ フレームワーク (UMDF) によって作成されたすべてのドライバ (これらのドライバはセッション 0 のプロセスでホストされているため)

この機能により影響を受けるアプリケーション クラスには次のものがあります。

  • UI を作成するサービス

  • SendMessagePostMessage などのウィンドウ メッセージ関数を使用してアプリケーションと通信を行うサービス

  • グローバルな名前付きのオブジェクトを作成するアプリケーション

現象

アプリケーションに属しているサービスから UI が返されても、アプリケーションがサービスを待機していると、UI はユーザー セッションで表示されません。

対処策

解決策
  • アプリケーションのサービスで UI が使用される場合、Windows Vista® および Windows Server® 2008 に組み込まれた軽減策により、ユーザーは特別なデスクトップでセッション 0 の UI を利用できます。このとき、セッション 0 のデスクトップ全体は公開されず、アプリケーションに固有の UI のみが提供されます。

  • アプリケーションでグローバルな名前付きオブジェクトが作成された場合は、Windows XP 互換モードを使用して、アプリケーションがセッション 0 のサービスと引き続き連動することを確認します。

互換性テスト

Windows XP 上で、ターミナル サーバー モードまたはユーザーの簡易切り替え (FUS) モードでアプリケーションのテストと検証を行います。このシナリオで Windows XP でアプリケーションが正常に動作すれば、Windows Vista® および Windows Server® 2008 でも動作する可能性はきわめて高くなります。

Window XP 互換モードを適用した後、アプリケーションが正常に機能することを検証します。この互換モードには、セッション 0 のいくつかの問題に対する軽減策が含まれます。

Windows Vista® および Windows Server® 2008 でドライバをテストし、正常に動作することを確認します。それができない場合、FUS を有効にし、複数のユーザーがログオンしている状態で、Windows XP でドライバをテストします。ドライバが 2 番目およびそれに続くログオン ユーザーで正常に動作する場合、Windows Vista® および Windows Server® 2008 でセッション 0 の変更によって影響が出る可能性は低くなります。このテストによって検出されない唯一の問題は、Windows Vista® および Windows Server® 2008 のセッション 0 でビデオ ドライバがないことに関連して発生する問題です。

Windows Vista® および Windows Server® 2008 に対応した解決策の活用
  • リモート プロシージャ コール (RPC) や名前付きパイプなどのクライアント メカニズムまたはサーバー メカニズムを使用して、サービスおよびアプリケーション間で通信を行います。

  • WTSSendMessage 関数を使用して、ユーザーのデスクトップに簡単なメッセージ ボックスを作成します。これにより、サービスはユーザーに通知を送信し、簡単な応答を要求できます。

  • 複雑な UI の場合は、CreateProcessAsUser 関数を使用してユーザーのセッションでプロセスを作成します。

  • サービスで使用可能なイベントやマッピングされたメモリなどの名前付きオブジェクトには、明示的にLocal\ または Global\ のいずれかの名前空間を指定します。

その他のリソースへのリンク

ネットワーキング: TCP/IP スタックおよび Windows Filtering Platform

機能の影響

概要

Windows Vista® および Windows Server® 2008 ネットワーキング スタックは、完全に書き換えられました。このネットワーキング スタックでは、Windows XP または Windows Server 2003 に実装されているデュアル スタック モデル (IPv4 および IPv6 をサポート) に代わり、複数の IP レイヤをサポートする単一のトランスポートおよびフレーミング レイヤによる新しいアーキテクチャが実装されます。また、新しい機能とプロトコル拡張機能もいくつか搭載されています。新しいスタックは大幅にモジュール化され、柔軟性と拡張性に優れています。既存のアプリケーションがさまざまなレイヤのスタックと連携する際、そのアプリケーション互換性を維持するためにあらゆる試みがなされてきましたが、それにもかかわらず、変更 (大部分が改善による副次的な影響によるものであるが) によって潜在的なアプリケーション互換性の問題が発生する可能性があります。アプリケーション開発者はこのアプリケーションへの変更による影響について慎重に評価し、理解する必要があります。

Microsoft WFP (Windows Filtering Platform) API では、開発者が、Windows Vista® および Windows Server® 2008 オペレーティング システムのネットワーキング スタックおよびオペレーティング システム全体に存在する複数のレイヤで動作するフィルタリングと連携するコードを作成できるようになりました。また WFP では、アプリケーションによるソケット API の使用に基づいて、認証された通信と動的ファイアウォール構成などのファイアウォール機能の統合やサポートも行われます。

   WFP 自体は、ファイアウォールではありません。ファイアウォールの実装を可能にするシステム サービスおよび API のセットです。

Windows Vista® および Windows Server® 2008 では、次の TCP/IP スタックの要素はサポートされません。

  • ファイアウォール フック ドライバ機能およびフィルタ フック ドライバ機能 (非推奨)

  • rexec、rsh、finger などの R シリーズ ツール。これらのツールは必要に応じて Services for Unix コンポーネントから入手できます。

  • インターネットワーク パケット交換 (IPX) プロトコル。IPX は非推奨であり、マイクロソフトからは入手できなくなりました。この変更によるアプリケーションの互換性への影響はほとんどありません。

現象

  • Windows XP 用に構築されたアプリケーションがネットワーキングにパブリック関数だけを使用している場合、アプリケーションの機能に問題は発生しないはずです。その機能を検証するには、Windows Vista® および Windows Server® 2008 上でテストを行います。

  • ファイアウォール フック ドライバ関数またはフィルタ フック ドライバ関数を使用している場合、アプリケーションは動作しません。

  • マイクロソフトが公開したことがない内部構造や関数呼び出しに依存している場合も、アプリケーションは動作しません。

  • カーネル モードで記述されたトランスポート ドライバ インターフェイス (TDI) フィルタ ドライバは、OS をアップグレードした後、正常に動作しない場合があります。

   TDI インターフェイスは、将来のリリースでは非推奨となる予定です。ただし、これらのドライバは Windows Vista® および Windows Server® 2008 でも引き続き動作します。

対処策

新しい機能に対応した解決策の活用

WFP では、ネットワーク セキュリティ開発者に豊富な機能とサービスを公開し、利用可能な機能セットに関するガイダンスやドキュメントを用意しています。

   Services for Unix および R シリーズに依存するアプリケーションやスクリプトでは、これらのツールを最初にインストールする必要があります。

その他のリソースへのリンク

ネットワーキング: カーネル モード IP ヘルパー API

機能の影響

概要

Windows の以前のバージョンでは、カーネルにアクセスするための API セットが Winsock クライアントに含まれていませんでした。Windows Vista® および Windows Server® 2008 では、これが変更されました。また、Windows Vista® および Windows Server® 2008 では既定で IPv6 がサポートされるようになりました。新しいヘルパー API セットは、IPv4 および IPv6 に対して別々の API を持つのではなく、次のような新しいテクノロジ全体に共通する機能を搭載するように設計されました。

  • WSK (Windows Sockets in Kernel) クライアント向けのカーネル モード関数

  • IPv6 サポート

  • IPv4 および IPv6 のアドレス指定のための単一の関数セット

  • 一貫性のある、拡張可能なオブジェクト モデルの搭載

  • ネットワーク サービス インターフェイスに基づく優れたセキュリティ モデルの搭載

  • コンパートメントやサブインターフェイスなどの新しいスタック機能の公開

現象

旧バージョンのヘルパー API や文書化されていないカーネル関数呼び出しを使用したアプリケーションは機能せず、不安定になる場合があります。

対処策

  • アプリケーションに、新しいカーネル モード IP ヘルパー API のサポートおよび実装が必要です。

ネットワーキング: IPv6

機能の影響

高 (頻度: 中)

概要

Windows Vista® および Windows Server® 2008 の TCP/IP スタックでは、既定で IPv6 が有効になっています。利用可能な場合は IPv6 接続が推奨されます。TCP/IP スタックにフックするアプリケーションの場合、これは次のような意味を持ちます。

  • IPv6 互換のアプリケーションやサービスでは、Teredo (NAT を介して IPv4 内部に IPv6 をカプセル化する) の組み込み NAT トラバーサル機能によって、IPv4 ネットワーク上でのピア ツー ピア接続の成功率が大幅に向上する可能性があります。

  • ネットワークが IPv6 をサポートしているかどうかにかかわらず、Windows Vista® および Windows Server® 2008 スタックによって IPv6 トラフィックが生成されます。したがって、たとえば、すべての Windows Vista® および Windows Server® 2008 システムは最低 1 つの IPv6 アドレス (リンク ローカル用) を持ち、IPv4 と IPv6 の両方で DNS 参照を試行します。

  • Windows Vista® および Windows Server® 2008 スタックでは、通信する必要があるリモート システムの IPv6 アドレスを検出できた場合は、常に IPv6 の使用を優先します。セッション内で両方のシステムが IPv6 アドレスを持っている場合、IPv6 互換アプリケーションまたはサービスでネットワーク通信が行われます。たとえば、LAN 上でのファイルの共有は通常 IPv6 を使用して行われます。

  • IPv6 アドレスが存在し、既定でオンになります。さらに、6to4、6over4、ISATAP、または Teredo などのリンク ローカル、グローバル、一時、または移行テクノロジに関連付けられた、複数の IPv6 アドレスが存在する場合があります。

   Teredo は既定で有効になりますが、アプリケーションやサービスが Teredo の使用を試行しない限り休止状態のままです。Teredo サービスがアクティブになるのは、次のような場合です。1. リッスン状態のアプリケーションまたはサービス用の Windows ファイアウォールの例外で、エッジ トラバーサル オプションが有効になっている (Windows ファイアウォールの MMC スナップインの詳細設定、または Windows ファイアウォール API のオプションで呼び出される) 場合。2. アプリケーションまたはサービスが Teredo のアドレスを使用して通信を試行する場合 (Windows ファイアウォールの通常のステートフル検査機能では、発信要求に対応する IPv6 応答のみが許可されます)。
  • Windows Vista® および Windows Server® 2008 では、IPv6 専用モードでシステムを構成できます。この場合、IPv4 はサポートされません。

Windows Vista® および Windows Server® 2008 の TCP/IP スタックでは、強力なホスト ルーティング モデルがサポートされます。つまり、マルチ ホーム コンピュータから、送信先アドレス以外にパケットのソース アドレスに基づいて、パケットのルーティングが行われます。IPv6 では、各コンピュータが複数の IP アドレスを取得し、移行テクノロジによって、ルーティングに関する限り基本的にマルチ ホーム コンピュータとして見なされるため、この変更が必要になります。以上のシナリオで適切な接続が行われていることを確認するには、ネットワーキング スタックに強力なホスト ルーティング モデルを実装する必要があります。

現象

Windows XP TCP/IP スタックを使用するアプリケーションや、IPv6 プロトコルを認識しないアプリケーションは正常に機能しなくなり、クラッシュするか、システムが不安定になる場合があります。

アプリケーションの強力なホスト ルーティング モデルには、次のような意味があります。

  • 非ループバック アドレスからループバック アドレス、およびその逆方向の接続を行うと、障害が発生します。

  • ソース アドレス 127.0.0.0/8 を持つパケットは、ネットワーク上の Windows Vista® および Windows Server® 2008 コンピュータからは送信できません。

プロトコルに柔軟な API を使用せず、IPv6 互換でもないアプリケーションは、Teredo IPv4 NAT トラバーサルの利点を活用することができず、接続先で NAT が使用されている場合、接続に失敗する可能性があります。

対処策

アプリケーションを次のように書き直す必要があります。

  • スタックにフックするアプリケーションには、IPv6 トラフィックを処理する機能が必要です。少なくとも、IPv6 トラフィック受信時にアプリケーションがクラッシュしないようにします。

  • アプリケーションが IPv4 アドレスが 1 つだけ存在する状態に依存している場合、複数の IPv6 アドレスを処理するよう変更が必要になります。さらに、アプリケーションが 1 番目のアドレスを選択した場合、使用する IPv6 アドレスをより慎重に識別する必要があります。これは、IPv6 リンク ローカル アドレスがルーティング不可であるために、アプリケーションが動作しなくなる場合があるためです。その代わり、アプリケーションは名前で接続を許可する関数を使用し、最も適切なアドレスを自動的に選択する必要があります。

  • また、IPv6 専用のシナリオを処理し、サポートする必要があります。

  • アプリケーションに、強力なホスト ルーティング モデルのサポートおよび実装が必要です。

  • IPv6 互換アプリケーションで、(Windows ファイアウォール API を使用して) Windows ファイアウォールの例外にエッジ トラバーサル フラグを設定する場合は、自動的に Teredo の IPv4 NAT トラバーサルが利用されます。

その他のリソースへのリンク

互換性のリスク

非推奨のコンポーネント

Windows Vista® および Windows Server® 2008 では、Windows の以前のバージョンに含まれる以下のコンポーネントは削除されます。

  • カーネル モード プリンタ ドライバのサポート。すべてのプリンタ ドライバは、今後、ユーザー モード ドライバ フレームワークに従う必要があります。カーネル モード プリンタ ドライバはすべて Windows Vista® および Windows Server® 2008 へのロードがブロックされます。詳細については、ユーザー モード ドライバ フレームワーク (UMDF) のサイト (英語) を参照してください。

  • 32 ビット アプリケーション用の Windows ヘルプ (WinHlp32.exe) - Windows ヘルプはサポートされておらず、Windows ヘルプのコードの一部はリリースに向けて削除されています。Windows Vista® および Windows Server® 2008 でファイル名の拡張子が .HLP である 32 ビット ヘルプ ファイルを表示するには、マイクロソフト ダウンロード センターから Windows ヘルプをダウンロードしてインストールする必要があります。詳細については、「ヘルプ エンジン サポート」を参照してください。

   HTML ヘルプ ファイルと .CHM ファイルは、Windows Vista® および Windows Server® 2008 でも引き続きサポートされます。
  • Microsoft® FrontPage® Server Extentions - Windows® SharePoint® Services では、開発者コミュニティ向けに拡張機能セットが搭載されました。

  • Services for Macintosh - このコンポーネントの代替コンポーネントはありません。

  • D3DRM - DirectX は、Windows Vista® および Windows Server® 2008 でサポートされる唯一のグラフィック パッケージです。

  • Web 発行ウィザード - このコンポーネントの代替コンポーネントはありません。

  • NTLMSSSP サービス

  • Windows Management Instrumentation Driver Extensions (WMI) サービス

  • RPC-Locator サービス

  • POP3 電子メール サーバー - このコンポーネントの代替コンポーネントはありません。

  • NetDDE - セキュリティ上の理由から、Windows Vista® および Windows Server® 2008 は NetDDE をサポートしていません。NetDDE は、Windows XP SP 2 および Windows Server 2003 では既定で無効になっています。通常の DDE は引き続きサポートされます。NetDDE は、DDE トランスポートを使用するアプリケーションが、ネットワーク上でデータを透過的に交換できるようにする技術です。NetDDE がサポートされていないと、アプリケーションはネットワーク上でデータを交換できません。この問題を回避するには、DCOM や Windows Communication Foundation などの他のネットワーキング技術を使用してください。

その他のリソースへのリンク

  • NetDDE の詳細については、http://support.microsoft.com/default.aspx?scid=kb;en-us;125703 (英語) を参照してください。

    Windows ヘルプ (WinHlp32.exe) は、Windows Vista® および Windows Server® 2008 では非推奨です。Windows Vista® および Windows Server® 2008 でファイル名の拡張子が .HLP である 32 ビット ヘルプ ファイルを表示するには、マイクロソフト ダウンロード センターから Windows ヘルプをダウンロードしてインストールする必要があります。詳細については、「ヘルプ エンジン サポート」を参照してください。

       HTML ヘルプ ファイルと .CHM ファイルは、Windows Vista® および Windows Server® 2008 でも引き続きサポートされます。
  • Windows Vista および Windows Server® 2008 用の Windows ヘルプ 

Windows ディスプレイ ドライバ モデル

Windows Vista® および Windows Server® 2008 ディスプレイ ドライバ モデル (VDDM) は、Windows のディスプレイ ドライバの安定性を向上させた、まったく新しいディスプレイ ドライバ モデルです。VDDM には、主に次のようなさまざまな特長があります。

  • DX アプリケーション用のビデオ メモリと新機能の DWM (Desktop Window Manager) を効率的に管理。複数の 3-D アプリケーションで、Windows Vista® および Windows Server® 2008 のグラフィック プロセッサ ユニット (GPU) を使用します。

  • 再起動なしのドライバ アップグレード

  • GPU 停止の動的な検出、および再起動なしの回復

  • モニタのホット プラグ検出サポート

  • DX9L によって義務付けられたハードウェア機能を使用

  • エラーのないビデオ再生

  • 安全性の高い設計を実現

以前の Windows バージョンの大部分のアプリケーションでは VDDM による影響はありませんが、以下の機能に問題が発生する危険性があります。

  • DX ゲームの互換性。これにより、DX ランタイム、IHV ドライバ、またはコア グラフィック スタックの問題が発生します。

  • モバイル機能。ACPI 要件が厳しくなることにより、ホットキー、クローンビュー、明るさ、およびズームなどの機能に問題が起こります。

  • ユーザー補助機能。特に、Windows XP によって設計された画面拡大表示アプリケーションは、Windows Vista® および Windows Server® 2008 上では動作しません。

安全な例外処理

以前のバージョンの Windows では、IsBadReadPtr および IsBadWritePtr 関数を使用してパラメータを検証していました。Windows Vista® および Windows Server® 2008 では、これらの関数は禁止されました。また、アプリケーションがパラメータ検証にこれらの関数を使用している Windows コンポーネントに依存していると、Windows で既にこれらの関数が使用されていないことが判明します。パラメータ検証を行う場合、アプリケーションは Windows に依存できません (null 値のチェックが行われ、それが不正なポインタである場合、アプリケーションでエラーが発生します)。

安全な例外処理 (SEH) は実行不可フラグとも連携しています。例外がディスパッチされる前には、例外ハンドラに実行可能 (PAGE_EXECUTE) フラグが付いていないかどうか、さらにハンドラが有効なコードであり、SEH テーブルに格納されているかどうかが確認されます。

DllMain の操作

プロセスの作成時の DLL のロード順序は保証されないため、それらに依存して操作を行うことはできません。DllMain 内の複雑な処理によって アプリケーションが停止またはクラッシュする場合、新しい OS コンポーネントの依存関係が原因である可能性があります。詳細については、次の MSDN のページを参照してください。

Outlook Express の名称変更

Outlook Express は変更および移動され、Windows Mail という名称になりました。MAPI アプリケーションはこの変更を認識する必要があります。MAPI の既定のプログラムを動的に使用する大部分のアプリケーションでは、互換性の問題は何も見られないはずです。

シェル: テーマとマイ ドキュメントの場所

Windows Vista® および Windows Server® 2008 の Windows Explorer Shell に新しい視覚テーマが導入されました。Windows の以前のバージョンでテーマを処理できるアプリケーションの場合、新しいテーマによる互換性の影響はありません。

また、Windows Vista® および Windows Server® 2008 では、マイ ドキュメントの場所と構造が変更され、より優れたユーザー エクスペリエンスが実現されました。ユーザー データは、\users\%username%\ フォルダ構造に保存されるようになりました。Pictures、Music、Documents、Desktop、および Favorites は、はすべてこのフォルダ構造の直下にある新しいフォルダです。アプリケーションから ShGetFolderPath 関数およびフォルダ パスが動的に使用されると、自動的に新しいパスとファイル場所にリダイレクトされます。通常、この変更によるアプリケーション互換性の影響はありません。

ユーザーの簡易切り替え (FUS)

ユーザーの簡易切り替え (FUS) は、ドメインに参加しているコンピュータを含むすべてのバージョンの Windows Vista® および Windows Server® 2008 で使用できるようになりました。アプリケーションやインストーラは FUS を認識し、複数のログイン ユーザーのセッションやターミナル サーバーのシナリオを処理できるようにする必要があります。詳細については、「Microsoft Windows XP のユーザー簡易切り替え機能: ビジネス アプリケーションの作成に関する設計ガイド (英語)」のページを参照してください。

CriticalSection コードの変更

CriticalSection コードが変更され、セキュリティが向上し、堅牢性が高まりました。クリティカル セクション ロックを使用したアプリケーションでは、以下を実行する必要があります。

  • クリティカル セクションを常に初期化する。

  • 文書化されていないオブジェクトの読み込みは行わない。文書化されていない構造が読み込まれてクリティカル セクションの状態を評価するアプリケーションでは、未初期化クリティカル セクションや解放済みクリティカル セクションの検索中に、障害が起こる可能性が高くなります。

  • スタベーションを回避する。アプリケーションから Sleep が呼び出さるときに、クリティカル セクション ロックが保持されていると、ロックを必要とする他のスレッドでスタベーションが発生する可能性があります。Sleep 呼び出しは、LeaveCriticalSection 呼び出しの後に配置する必要があります。

詳細については、MSDN のクリティカル セクション オブジェクトのトピック (英語) を参照してください。

既定のプログラム

概要

既定のプログラムは、競合アプリケーションを念頭に置いた、ユーザーごとのファイルとプロトコルの関連付けを管理する新しいインフラストラクチャです。既定のプログラム機能を使用するには、アプリケーションで登録する必要があります。既定のプログラムは Windows Vista® および Windows Server® 2008 以降で高い視認性を実現し、特定のタスクをアプリケーションでコーディングおよび維持しやすくします。

対処策

Windows Vista® および Windows Server® 2008 には、アプリケーションで利用できる新しい機能セットが用意されています。この新しい機能セットは、"既定のプログラム" と呼ばれます。既定のプログラムは、ユーザーによる既定動作の選択を支援するために設計されました。Windows Vista® および Windows Server® 2008 以降の既定は、主にコンピュータ単位のレベルではなくユーザー単位のレベルで制御されます。これにより、マイクロソフトが今後標準化されると考えているマルチ ユーザー コンピュータ環境に対応する非常に優れた柔軟性が得られます。この一環として、ユーザー向けの新しい集中型 UI が追加され、また、ユーザーによる選択の表現を支援するために必要なツールが ISV に提供されます。既定のプログラムは、アプリケーションに以下の利点をもたらします。

  • 簡単な既定採用プロセス

  • ユーザー単位のファイルとプロトコルの関連付け

  • プログラムによる既定の確認

  • 再利用できる共通の Windows UI

  • Windows 内の通知領域

この機能は、主に競合アプリケーション向けに設計されました。競合アプリケーションとは、mp3 や jpeg などのファイル形式または http や mailto などのプロトコルの既定に設定されるアプリケーションです。主に独自のプロトコルとファイルの関連付けを扱うアプリケーションでは、他のアプリケーションに侵害されることがないため、一般的にはこの新機能を使用する必要はありません。競合しないアプリケーションは、XP の場合と同様に動作し、インストールされます。ただし、どのアプリケーションでも新しい既定のプログラム機能を利用できます。

既定のプログラム機能は、一連のコントロール パネルおよびオープン API としてオペレーティング システムに組み込まれています。コントロール パネルや API を使用するアプリケーションの場合は、特定のスキーマを記述することにより、既定のプログラムの一部としてインストール時に登録する必要があります。これにより、アプリケーションがコントロール パネルの [既定のプログラム] に表示され、ユーザーはアプリケーションの既定のファイルの関連付けとプロトコルをいつでも復元できます。

アプリケーションを既定のプログラムに登録すると、そのアプリケーションは API を通して提供される新機能を利用できます。既定のプログラムにより、API では以下の処理が実行できるようになります。

  • 登録されているすべての既定の復元

  • 登録されている 1 つの既定の復元

  • 特定の既定のファイルの関連付け、プロトコル、スタート メニューの既定の所有者のクエリ

  • 特定のアプリケーションの既定 UI の起動

  • ユーザー単位のすべての関連付けの消去

既定のプログラム機能の目的は、インストール後のユーザーによる選択を簡単に表現し、既定を求めて競合して既定を主張するための単純なフレームワークをアプリケーションに提供することです。

既定のプログラムを使用する理由

高レベルのポイントを次に示します。
  • 既定のプログラムは、アプリケーションの検出に役立ちます。

  • Windows Vista® および Windows Server® 2008 では、すべての管理者が HKLM に書き込むことを可能にする基本アーキテクチャが変更されています。

  • 既定のプログラムを使用すると、アプリケーションは、コードをほとんど変更せずに Windows XP パリティ プロセス フローを維持できます。

  • コンピュータ レベルの既定だけを主張しても、常に希望の結果が得られるわけではありません。

既定のプログラム フレームワークを使用する競合アプリケーションでは、消費者にとって明確な利点がありますが、既定のプログラムを使用するアプリケーションにとっても大きな利点があります。

既定のプログラムは、登録済みアプリケーションに充実した UI エクスペリエンスを提供するため、既定のプログラムの優れた機能をユーザーに実際に通知できます。さらに、URL でデジタル署名されているアプリケーションでは、その URL を表示でき、ユーザーは簡単にホーム Web サイトに戻り、その企業が提供している他のアプリケーションや拡張機能を確認できます。

この新しい API セットを使用すると、新しいアプリケーションの開発コストも大幅に削減できます。ほぼすべての競合アプリケーションは、それ自体が既定であるかどうかを確認するために、監視やチェックを行います。新しい API セットを使用すると、以前のバージョンの OS のようにレジストリをクロールする代わりに、1 回の API 呼び出しで監視やチェックを実行できます。

新しい API セットは、アプリケーションがユーザー アカウント制御 (UAC) を使用する新しい環境で正常に機能するためにも役立ちます。UAC は管理者を選択し、システムに標準ユーザーと見せかけることで実装されます。つまり、Windows Vista® および Windows Server® 2008 以降では、管理者は通常 HKLM に書き込むことができません。管理者を認識しないとプロセスが管理者の代わりに動作できないように、このような処理が行われます。インストールでは通常、経験によって、常に高い権限が与えられます。しかし、インストール後に既定を主張できるようにするアプリケーションの場合は、コンピュータ単位のレベルではなくユーザー単位のレベルで既定を主張する必要があります。新しい API セットに切り換えると、この処理が自動的に行われます。インストール後にコンピュータ単位で既定を主張しようとするアプリケーションでは、障害が発生します。

アプリケーションで既定のプログラムの使用に移行するもう 1 つの強力な理由は、目的の結果を常に達成することです。ファイルとプロトコルの関連付けは、レジストリ内の階層構造から導き出されます。

この構造の一部による指示で、ユーザー単位の既定はコンピュータ単位の既定よりも常に優先して選択されます。つまり、アプリケーションが XP のように HKLM に書き込んで既定を主張するために、コード内に昇格ポイントを作成する場合、希望の結果を常に実現できるとは限りません。別の類似アプリケーションをインストールし、ユーザー単位のファイルとプロトコルの関連付けを採用する既定のプログラムの API を使用すると、ユーザー単位の既定の優先度の方が高いため、以前のアプリケーションは既定ではなくなります。

既定のユーザーのチェック リスト

  • SPAD について正しく登録する

  • プログラムの既定について正しく登録する

  • ファイルの関連付け、プロトコル処理、"プログラムから開く"、スタート メニュー、クイック起動を正しく登録する

  • インストールがガイドラインに従っている (コンピュータ単位の登録を設定し、既定を採用しない)

  • 初回の実行がガイドラインに従っている (ユーザーに設定、ファイルの関連付けなどを確認する)

  • インストールまたはアップグレードが既定を採用しない

  • 既定を正しくセルフチェックする既定を採用する前のユーザーのアクセス許可

  • 仮想化をトリガしない

  • AppCompat の警告またはブロックがない (PCA)

  • XP でも正しく動作する

  • [OS のファイルの関連付けなどの UI を使用する]

  • [署名されたコード - プログラムの既定での URL]

その他のリソースへのリンク

ファイルの関連付けに関するドキュメント

プログラム互換性アシスタント (PCA)

PCA の概要

ヘルプとサポートのプログラム互換性ウィザードおよびファイル プロパティの [互換性] タブは、Windows XP でプログラムの互換性に関する問題をユーザーが修正するための便利なツールです。これらのツールの大きな制約はその検出性と、これらのツールを使用するタイミングをユーザーが把握する必要があることです。プログラム互換性アシスタント (PCA) は Windows Vista® の新機能です。PCA を使用すると、互換性の問題が含まれる古いプログラムの機能が自動的に改善されます。PCA はプログラムの既知の問題を監視します。問題が検出された場合、PCA はユーザーに問題を通知し、ユーザーが次にプログラムを実行する前に効果を発揮する解決策を提案します。

ここでは、ユーザーが PCA を使用することが予想されるシナリオ、ユーザー エクスペリエンスの詳細、各シナリオで適用される解決策、および後半では PCA が行う設定の管理方法について説明します。最後のセクションでは、PCA からプログラムを除外する方法を解説します。

PCA のシナリオ

セットアップ プログラムの障害の検出

PCA が使用される主なシナリオの 1 つは、Windows Vista® でのインストールが失敗したセットアップ プログラムを検出し、Windows XP 互換モードを適用するという解決方法を提供することです。

最も多いセットアップの失敗原因は、インストーラが対応する Windows OS バージョンのチェックをハード コーディングしていることによるものです。このようなインストーラでは、通常、現在の Windows のバージョンがサポートされていないため終了する、という意味のエラー メッセージが表示され、インストールは正常に完了しません。

以下に、テスト プログラムによるこのようなエラー メッセージの例を図で示します。

ac_pca_10.gif
10: PCA のエラー   メッセージの例


多くの場合、プログラムは GetVersion または GetVersionEx API を使用して、実行中の Windows OS のバージョンに関する情報を収集します。Windows Vista® では、これらの API はメジャー バージョンとして 6 を返します。メジャー バージョンが 5 である XP バージョンを検索するようにプログラムがハード コーディングされていると、Windows Vista® では障害が発生します。Windows XP 互換モードに含まれている XPVersionLie 修正プログラムによって、GetVersion または GetVersionEx API を呼び出したときにプログラムに提供される OS は XP バージョンになります。

PCA はこのシナリオを検出し、インストーラの終了後、以下のようなユーザー インターフェイスを表示します。このシナリオはアンインストーラにも当てはまり、同様のダイアログが表示されます。

ac_pca_11.gif
11: インストーラの終了後の PCA UI


ユーザーが [推奨の設定を使用して再インストールする] のオプションを選択すると、Windows XP 互換モードがインストーラ プログラムに適用され、インストーラが自動的に再起動します。

内部での処理内容については、以下の質問と回答を通して説明します。

  1. 検出ロジックは何ですか。PCA はバージョンの問題が原因でセットアップが失敗したことをどのようにして認識するのですか。

  2. PCA はセットアップ プログラムに関する情報をどのように取得するのですか。

  3. セットアップ用の PCA ダイアログの各オプションにはどのような機能がありますか。

    [推奨の設定を使用して再インストールする]

    Windows XP 互換モードを適用し、プログラムを再起動します。互換モードの適用方法の詳細については、後述の PCA 設定の管理に関するセクションを参照してください。

    [このプログラムは正しくインストールされました]

    セットアップ プログラムは正常に完了したが、ARP にエントリが作成されなかった場合は、PCA が表示される場合があります。このような場合、ユーザーはこのオプションを使用して、次回から PCA ダイアログが表示されないように設定できます。

    [キャンセル]

    PCA は一切の処理を行いません。

    これらのオプションを実行すると、PCA ダイアログが閉じます。ユーザーが前回の PCA ダイアログで [キャンセル] オプションを選択した場合を除き、同じセットアップ プログラムに PCA が再び表示されることはありません。

  4. PCA は、バージョンの問題によるセットアップの失敗を特に検索しているわけではありません。PCA が使用するロジックは、セットアップが正常に完了したかどうかを検出します。PCA は Windows Vista® によるセットアップとして検出されるプログラムを監視し、[プログラムの追加と削除] (ARP) にプログラムがエントリを登録したかどうかをチェックします。

    ARP にエントリが作成されていない場合、PCA はセットアップが正常に完了しなかったと判断します。PCA はインストール プログラムが終了するまで待機してから、UI を表示します。アンインストーラの場合は、エントリが ARP から削除されるかどうかを監視します。

  5. PCA はセットアップ プログラムに関する情報をどのように取得するのですか。

  6. セットアップ用の PCA ダイアログの各オプションにはどのような機能がありますか。

    [推奨の設定を使用して再インストールする]

    Windows XP 互換モードを適用し、プログラムを再起動します。互換モードの適用方法の詳細については、後述の PCA 設定の管理に関するセクションを参照してください。

    [このプログラムは正しくインストールされました]

    セットアップ プログラムは正常に完了したが、ARP にエントリが作成されなかった場合は、PCA が表示される場合があります。このような場合、ユーザーはこのオプションを使用して、次回から PCA ダイアログが表示されないように設定できます。

    [キャンセル]

    PCA は一切の処理を行いません。

    これらのオプションを実行すると、PCA ダイアログが閉じます。ユーザーが前回の PCA ダイアログで [キャンセル] オプションを選択した場合を除き、同じセットアップ プログラムに PCA が再び表示されることはありません。

  7. PCA は Windows Vista® のユーザー アクセス制御 (UAC) 機能によって、セットアップ プログラムかどうかを識別します。UAC はセットアップ プログラムの検出機能を備えており、検出されたセットアップ プログラムが管理者として実行されることを確認します。この処理では、プログラムを起動する前にユーザーから管理者の資格情報や確認が取得されます。

  8. セットアップ用の PCA ダイアログの各オプションにはどのような機能がありますか。

    [推奨の設定を使用して再インストールする]

    Windows XP 互換モードを適用し、プログラムを再起動します。互換モードの適用方法の詳細については、後述の PCA 設定の管理に関するセクションを参照してください。

    [このプログラムは正しくインストールされました]

    セットアップ プログラムは正常に完了したが、ARP にエントリが作成されなかった場合は、PCA が表示される場合があります。このような場合、ユーザーはこのオプションを使用して、次回から PCA ダイアログが表示されないように設定できます。

    [キャンセル]

    PCA は一切の処理を行いません。

    これらのオプションを実行すると、PCA ダイアログが閉じます。ユーザーが前回の PCA ダイアログで [キャンセル] オプションを選択した場合を除き、同じセットアップ プログラムに PCA が再び表示されることはありません。

UAC 下のプログラム障害の検出

PCA の 2 番目のシナリオは、ユーザー アクセス制御 (UAC) 下での実行中にプログラムの障害を検出するというものです。PCA は、UAC 下の 3 種類の異なるプログラム障害を検出します。その各障害について以下で説明します。

インストーラ起動時のプログラム障害の検出

PCA は、プログラムが管理者として実行されておらず、子プログラムは管理者として実行する必要があるために、子 exe ファイルの起動中に障害が発生するというこの特定のシナリオを検出します。よくある例は、プログラムが updater.exe を起動しようとする場合です。これは、プログラムは管理者として実行する必要のある実行可能ファイルを起動しようとして、Windows Vista® および Windows Server® 2008 から新しいエラー コードが返されるためです。同じ updater.exe をエクスプローラから実行すると、エクスプローラはこのエラー コードに対応できるため、UAC が承認した UI を起動して管理者の資格情報または同意を要求し、最終的には、プログラムを管理者として実行します。テスト プログラムによって示された、このシナリオで表示される PCA ダイアログの例を以下に示します。

ac_pca_12.gif
12: exe を起動しようとしたプログラムに関する PCA のダイアログ   ボックス


ここで、テスト プログラムでは管理者として実行する必要があるアップデータを起動しようとして、障害が発生しました。この場合、PCA はプログラムが次回に管理者として子 exe ファイルを正常に起動できるように、ELEVATECREATEPROCESS 互換モードを適用します。次回にプログラムが実行され、アップデータを起動しようとすると、障害は発生せずに、アップデータは管理者として正常に実行されます。UAC が承認した UI が表示されます。

内部での処理内容については、以下の質問と回答を通して説明します。

  1. 検出ロジックは何ですか。管理者として実行する必要がある子 exe ファイルをプログラムが起動できなかったことを PCA はどのようにして認識するのですか。

    このシナリオの検出は、管理者として実行するという要件のために子プロセスの起動が失敗した状況を検出する CreateProcess API のインスツルメンテーションによって実現されます。

  2. この PCA ダイアログにはなぜオプションがないのですか。

    このシナリオにおける問題検出には高い信頼性があり、解決策 (ELEVATECREATEPROCESS 互換モード) が自動的に適用されるため、ユーザーに提供されるオプションはありません。

管理者として実行する必要があるインストーラの検出

Windows の特長の 1 つは、ほとんどのソフトウェアのインストールに管理者権限が必要であることです。これは、インストールするアプリケーションがシステム ディレクトリにロードされて、システム リソースを操作するためです。ユーザー アクセス制御 (UAC) 機能に含まれるインストール検出機能では、セットアップ プログラムを特定して、ユーザーに自動的に管理者の承認または資格情報を求めるプロンプトを表示することで、これを支援しています。インストール プログラムが UAC によって検出されない場合もあります。一般に、Install Shield や Microsoft Windows Installer などの標準インストーラ技術を使用して構築されていないカスタム インストーラがこれに該当します。

PCA はこのシナリオを検出し、インストーラの終了後、以下のようなユーザー インターフェイスを表示します。

ac_pca_13.gif
13: 管理者として実行する必要があるインストーラの検出


ユーザーが [プログラムを管理者として再起動します] のオプションを選択すると、プログラムは管理者として実行されるようにマークされて、自動的に再起動します。

内部での処理内容については、以下の質問と回答を通して説明します。

  1. 検出ロジックは何ですか。PCA はプログラムが管理者として実行する必要があることをどのようにして認識するのですか。

  2. このシナリオに関する PCA ダイアログの各オプションにはどのような機能がありますか。

  3. PCA が使用するロジックは、プログラムが Program Files ディレクトリの下にサブ フォルダを作成してから、.exe ファイルまたは .dll ファイルをそのフォルダ内にコピーしようとする動作を検出します。PCA では、この動作はインストーラが実行する共通のアクションであると見なされます。PCA は、ユーザー アクセス制御 (UAC) 機能に含まれるファイルの仮想化機能からイベントを取得して、これを検出します。プログラムが管理者として実行されていない場合は、システム ロケーションの 1 つである Program Files ディレクトリへの書き込みは許可されません。ファイルの仮想化では、システム ロケーション上の書き込み処理を仮想ストアにリダイレクトすることで、これに対処します。たとえば、仮想ロケーションでのディレクトリ作成やドキュメント ファイルの書き込みのリダイレクトはサポートされますが、.DLL や .EXE などのバイナリ ファイルのリダイレクトはサポートされません。いずれの場合でも、ファイルの仮想化では PCA が利用できるイベントが送信されます。

  4. このシナリオに関する PCA ダイアログの各オプションにはどのような機能がありますか。

[プログラムを管理者として再起動します]

RunAsAdmin 互換モードを適用し、プログラムを再起動します。互換モードの適用方法の詳細については、後述の PCA 設定の管理に関するセクションを参照してください。

[このプログラムは正しくインストールされました]

セットアップ プログラムは正常に完了した場合にも、PCA が表示されることがあります。このような場合、ユーザーはこのオプションを使用して、次回から PCA ダイアログが表示されないように設定できます。

[キャンセル]

PCA は一切の処理を行いません。

ユーザーが前回の PCA ダイアログで [キャンセル] オプションを選択した場合を除き、同じプログラムに PCA が再び表示されることはありません。

管理者として実行する必要のあるレガシ コントロール パネルの検出

PCA が対処する UAC 関連の最後のシナリオは、管理者として実行する必要のあるコントロール パネル項目の検出です。レガシ コントロール パネル項目が実行されると、次のような PCA ダイアログが表示されます。

ac_pca_14.gif
14: 管理者として実行する必要のあるレガシ   コントロール   パネルの項目


内部での処理内容については、以下の質問と回答を通して説明します。

  1. 検出ロジックは何ですか。PCA はコントロール パネル項目が管理者として実行する必要があることをどのようにして認識するのですか。

このシナリオに使用される特定の問題検出ロジックはありません。レガシ コントロール パネル項目の実行が完了した後にこのダイアログが表示されます。この目的は、コントロール パネル項目を管理者として実行するためのオプションをユーザーに提供することです。これは UAC 下で正常に動作しないコントロール パネルに対しては、最も必要な解決策です。このシナリオに使用される特定の問題検出ロジックはありません。レガシ コントロール パネル項目の実行が完了した後にこのダイアログが表示されます。UAC およびこの UAC マニフェストの作成方法の詳細については、http://blogs.msdn.com/shawnfa/archive/2006/04/06/568563.aspx (英語) を参照してください。

このシナリオに関する PCA ダイアログの各オプションにはどのような機能がありますか。

[推奨の設定を使用してコントロール パネルを開きます]

RunAsAdmin 互換モードを適用し、管理者としてコントロール パネル項目を再起動します。互換モードの適用方法の詳細については、後述の PCA 設定の管理に関するセクションを参照してください。

[このコントロール パネルは正常に動作します]

コントロール パネル項目が正常に動作する場合、ユーザーはこのオプションを使用して、次回から PCA ダイアログが表示されないように設定できます。

[キャンセル]

PCA は一切の処理を行いません。

これらのオプションを実行すると、PCA ダイアログが閉じます。ユーザーが前回の PCA ダイアログで [キャンセル] オプションを選択した場合を除き、同じプログラムに PCA が再び表示されることはありません。

非推奨 Windows コンポーネントによるプログラム障害の検出

この PCA シナリオは、Windows Vista® の非推奨 (削除済み) コンポーネントによるプログラムへの影響を軽減します。PCA は、Windows Vista® では削除された DLL または COM オブジェクトにアクセスしようとするプログラムを検出します。既知の DLL/COM オブジェクトにアクセスするプログラムが検出されると、PCA はプログラムの終了時に UI を表示してユーザーに通知し、解決策をオンラインで検索するオプションを提供します。

テスト プログラムによって示された、このシナリオで表示される PCA ダイアログの例を以下に示します。

ac_pca_15.gif
15: PCA が非推奨の Windows コンポーネントを検出したときに表示されるダイアログ


ここでは、テスト プログラムが DHTML に関連付けられた COM オブジェクトを使用して、Windows Vista® では削除されたコントロールを編集しようとしました。

内部での処理内容については、以下の質問と回答を通して説明します。

  1. 検出ロジックは何ですか。管理者として実行する必要がある子 exe ファイルをプログラムが起動できなかったことを PCA はどのようにして認識するのですか。

  2. [オンラインで解決策の有無を確認する] オプションを選択すると、どのような処理が実行されますか。

  3. このシナリオの検出は、COM オブジェクトと DLL でそれぞれロード障害を検出する CoCreateInstance API と Loader (NTDLL) のインスツルメンテーションによって実現されます。オブジェクトやファイルが見つからないことによる障害が発生すると、既知の DLL と COM オブジェクトのリストが照合されます。照合で一致すると、PCA はプログラムの終了後に起動します。

  4. [オンラインで解決策の有無を確認する] オプションを選択すると、どのような処理が実行されますか。

  5. [オンラインで解決策の有無を確認する] を選択すると、Windows エラー報告が送信され、マイクロソフトからのオンライン回答が表示されます。回答は、クライアントの [問題の解決策] (wercon.exe) UI に表示されます。この回答は通常、ユーザーにサポート技術情報の記事を提示します。この記事では、非推奨コンポーネントの代わりとなる項目を紹介し、場合によっては、オンラインで非推奨コンポーネントをダウンロードするリンクを提供します。

64 ビット プラットフォームでの未署名ドライバの検出

これは、プログラムまたはデバイスが 64 ビット プラットフォームで未署名ドライバを使用するために、PCA がシステムの安定性を保護しようとするシナリオです。Windows Vista® および Windows Server® 2008 では、64 ビット プラットフォームの未署名ドライバはサポートされず、すべてのドライバには署名が必要であるというポリシーが施行されます。未署名ドライバを 64 ビット プラットフォームのシステムにインストールしても、ロードは実行されません。これが起動時ドライバである場合、ユーザーがコンピュータを再起動してもシステムは起動しません。ドライバを使用するデバイスやプログラムでは、システム クラッシュを引き起こす可能性のある障害が発生します。これを回避するために、PCA は未署名ドライバのインストールを監視し、未署名ドライバのインストールが検出されるとすぐに、次のようにユーザーに通知します。

ac_pca_16.gif
16: 未署名のドライバが検出された場合の PCA ダイアログ


ブート時ドライバの場合、システムが起動できるように、ドライバが無効化されます。

まず、PCA は、新しいドライバをシステムに追加するための KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services レジストリ キーへの変更を監視することによって、このシナリオを検出します。次に、レジストリのドライバのロケーションに基づいて、インストールされる新しいドライバごとに有効なデジタル署名の有無が確認されます。ドライバに有効な署名がない場合、PCA ダイアログが表示されます。他の PCA シナリオとは異なり、このメッセージは特定のアプリケーションではなく、ドライバに関するものです。ドライバのインストール方法には関係しません。

起動時に既知のプログラムの互換性問題をユーザーに通知

上記の 2 つの実行時問題検出シナリオ以外に、PCA は、プログラムが互換性問題が認識されているプログラムのリストに含まれているかどうかを、プログラムの起動時にユーザーに通知します。このリストは、システム アプリケーションの互換性データベースに格納されます。このシナリオは Windows XP から存在し、これらのメッセージはアプリケーション ヘルプ (AppHelp とも呼ばれる) メッセージと呼ばれています。AppHelp メッセージには、次の 2 種類があります。

  • ハード ブロック メッセージ - プログラムに互換性がないことがわかっている場合やプログラムを許可するとシステムに重大な影響が出る可能性がある場合 (たとえば、停止エラーやインストール後に起動できない場合など) は、以下のようなブロック メッセージが表示されます。

   マイクロソフトは、プログラムをブロックする許可を各 ISV から取得します。

ac_pca_17.gif
17: ハード   ブロック AppHelp メッセージ - 非互換性が重大な影響を持つ場合に表示


  • ソフト ブロック メッセージ - もう 1 種類のメッセージは、以下のようなブロックしないメッセージです。このメッセージは、既知の互換性問題があるものの、システムへの影響が重大ではないプログラムに使用されます。

ac_pca_18.gif
18: 非互換性の問題が重大な影響を与えない場合に表示されるソフト   ブロック   ダイアログ


いずれの場合にも、[オンラインで解決策の有無を確認する] を選択すると、Windows エラー報告が送信され、マイクロソフトからのオンライン回答が表示されます。回答は、クライアントの [問題の解決策] (wercon.exe) UI に表示されます。典型的な回答は、以下の 3 種類です。

  1. ユーザーに対してそのプログラムの ISV からの更新を提示

  2. ユーザーに対して詳細情報を取得するための ISV の Web サイトを提示

  3. ユーザーに対して詳細情報を取得するためのマイクロソフト サポート技術情報を提示

PCA による設定の管理

互換モードは、以下の場所にレジストリ キーを設定することによって、プログラムに適用されます。

Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers。レジストリ キー。値の名前はプログラムの実行ファイルの完全パスで、値は適用されている互換モードの名前です。Windows XP 互換モードの場合、値は「WINXPSP2」です。

レジストリ キーは、すべてのユーザーに対して有効なこの解決方法を適用するために、HKEY_LOCAL_MACHINE で設定されます。ただし、PCA ダイアログ が表示される前に ELEVATECREATEPROCESS 互換モードが自動的に適用されるシナリオは除きます。このシナリオでは、レジストリ キーは HKEY_CURRENT_USER で設定され、この解決方法は現在のユーザーに対してのみ有効です。

このキー以外に、PCA はすべてのプログラムの一覧を格納し、適用される互換モードがない場合でもユーザーごとに次のキー下に表示されます (プログラムが正常に動作することをユーザーが報告した場合など)。

HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted

PCA からのプログラムの除外

PCA の目的は、古いプログラムとの問題の検出であり、Windows Vista® および Windows Server® 2008 用に開発されたプログラムの監視ではありません。PCA からプログラムを除外する最適な選択肢は、プログラムで、UAC 用に設定された (管理者または限定ユーザーとしての) 実行レベルを持つアプリケーション マニフェストを含めることです。つまり、プログラムは UAC (および Windows Vista® および Windows Server® 2008) 下で機能するかどうかをテストされ、PCA はこのマニフェストをチェックして、プログラムを除外します。これは、インストーラと通常のプログラムの両方に当てはまります。

PCA からアプリケーションを除外するもう 1 つの方法は、レジストリ キー

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant の下に完全パスを持つ .exe の一覧を追加することです。値の名前は ExecutablesToExclude で、種類は REG_MULTI_SZ です。

パスに "AppCompatFlags" が追加されます。

これとは別に、PCA はネットワーク ロケーションから実行されるプログラムと、アプリケーション互換性データベースで適用される修正プログラムを含むプログラムを自動的に除外します。

必要に応じて、すべてのプログラムで PCA を無効にするグループ ポリシー設定が指定されます。このポリシーは、[プログラム互換性アシスタントを終了する] という名前で、グループ ポリシー エディタ (gpedit.msc) の [管理用テンプレート] -> [Windows コンポーネント] -> [アプリケーションの互換性] の下にあります。

特定のシナリオを無効化する個々のポリシーもあります。これらのポリシーは、グループ ポリシー エディタ (gpedit.msc) の [管理用テンプレート] -> [システム] -> [トラブルシューティングと診断] -> [アプリケーションの互換性の診断] にあります。

イベント ログ

ユーザーが PCA に基づいて操作を実行した後に、イベントがイベント ログに記録されます。このイベントは、イベント ビューアの [アプリケーションとサービス ログ] -> [Microsoft] -> [Windows] -> [Program Compatibility Assistant] -> [Operational] にあります。イベント ログには、アプリケーションの名前、アプリケーションのバージョン、実行パス、シナリオ ID、ユーザー アクション、適用された互換モードの名前などの情報が含まれます。シナリオ ID の値を以下の表に示します。

シナリオ ID

内容

1

セットアップ プログラム (インストーラ) の障害の検出

10

セットアップ プログラム (アンインストーラ) の障害の検出

3

インストーラ起動時のプログラム障害の検出

8

管理者として実行する必要があるインストーラの検出

9

管理者として実行する必要のあるレガシ コントロール パネルの検出

5

非推奨 Windows コンポーネントによるプログラム障害の検出

11

64 ビット プラットフォームでの未署名ドライバの検出

19: シナリオ ID の値

Apphelp メッセージの管理

エンタープライズ設定では、IT 専門家は Compatibility Administrator ツールを使用して、システム アプリケーション互換性データベース内の Apphelp エントリを無効にしたり、企業内で使用されるプログラム用の Apphelp メッセージを含むカスタム データベースを追加したりできます。

Compatibility Administrator ツールは、Application Compatibility Toolkit の一部として提供されます。このツールキットの詳細ついては、http://www.microsoft.com/japan/technet/windowsvista/appcompat/tools.mspx を参照してください。

グラフィカル デバイス インターフェイス - GDI

描画 (WM_PAINT) 動作の違い

軽減策

概要

Desktop Window Manager 機能の一部として、マイクロソフトは、アプリケーションが画面に描画する方法に微妙で重要な変更を加えました。Windows Vista® および Windows Server® 2008 以前は、hwnd が画面に直接描画されていました。この方法には利点もありましたが、Windows で最上位のウィンドウを表示および管理する方法が大きく限定されていました。Windows Vista® および Windows Server® 2008 では、最上位のウィンドウはすべて (WS_EX_LAYERED のような) 画面外のビットマップとして表示され、Desktop Window Manager が画像をまとめてデスクトップを描画します。

現象
ヒント、ポップアップ メニュー、バルーン、スプラッシュ画面などの周りに黒い領域が表示される

この現象は、アプリケーションが hwnd 全体を描画しない場合に発生することがあります。理由は通常、アプリケーションでは背景ウィンドウのピクセルが十分だとみなされるためです。

黒い点滅

背景に初期化されていないピクセルが含まれている場合、ユーザーには画面上に黒の点滅のように見えるという関連する問題が発生する可能性があります。これは、アプリケーションが WM_PAINT メッセージの一部ではないものを描画する場合に発生します。システムはアプリケーションがデスクトップを描画中であることを検出し、デスクトップを再描画しますが、アプリケーションは hwnd の描画を完了していない場合があります。これにより、黒の点滅が発生します。

アプリケーションに対して無効なグラス

この現象は、アプリケーションがウィンドウのクライアント領域以外 (タイトル バー) に描画するときに発生する場合があります。

ゴム バンド、カスタム シャドウなどの特殊効果

これらの特殊効果は、多くの場合、GetDC(NULL) を使用して実行されます。ただし、GetDC(NULL) からの読み取りおよび GetDC(NULL) への書き込みは、アプリケーションが画面に直接描画するのではなく、ビットマップでバックされている場合に問題となる傾向があります。画面からの読み取りと画面への書き込みは、Windows XP に比べて大幅に遅くなります。また、GDI rasterop の一部はサポートされていません (ただし、XOR はサポート)。

東アジア地域のフォントの強化

Windows Vista® および Windows Server® 2008 では、読みやすさを向上するために、中国語、日本語および韓国語フォントに多数変更を加えました。この副作用の 1 つは、文字の幅が異なる場合があるため、これらの新しいフォントではテキストのレイアウトが若干異なることがあるということです。画面とプリンタにおけるテキストのレイアウト方法のテストについて検討してください。また、東アジア言語がラテン文字セット (たとえば、英語) と混在する可能性がある場所のテストについても検討してください。

表示パフォーマンス

機能の影響

概要

Windows Vista® および Windows Server® 2008 では、大部分のアプリケーションがこれまでと同等以上のスピードで動作しますが、注意が必要な変更がいくつかあります。

現象
全体的な GDI 描画パフォーマンスが遅い

LineTo やRectangle などの GDI プリミティブは、ビデオ ハードウェアではなくソフトウェアで表示されるようになり、ディスプレイ ドライバが大幅に簡素化されました。

テキストの表示が遅い

DrawText などの呼び出しでは、多言語および東アジア言語のサポートが向上しています。

アプリケーションのアドレス空間が狭くなった

最上位ウィンドウのビットマップは、アプリケーションのアドレス空間に格納される (描画の説明を参照) ため、使用可能なアドレス空間が数 MB 減る可能性があります。

GetDC(NULL) からの読み取りと GetDC(NULL) への書き込み

アプリケーションは、画面に直接ではなく画面外のビットマップに表示するようになったため、この操作は、以前のバージョンの Windows よりも遅くなります。可能な場合は、HWND にバックされたHDC への描画またはオーバーレイ ウィンドウの作成を検討してください。GetDC(NULL) は、依然として画面のスナップショットを取得する有効な方法です。

ユーザー インターフェイス特権の分離 (UIPI)

機能の影響

概要

悪意のあるソフトウェアに対する追加防御層として、Windows Vista® および Windows Server® 2008 では異なる UI アプリケーションを 3 つのレベルの UI 権限で実行できます。アプリケーションは、許可が同等以下の他のアプリケーションとは自由に対話できますが、許可がより高いアプリケーションの変更やそのアプリケーションとの対話はできません。大部分のアプリケーションは中程度の許可で実行されますが、管理者権限を要求するアプリケーションはより高いモードで実行されます。Internet Explorer で使用されるような低いアクセス権などの制限プロセスは一番低い権限モードを使用します。

より具体的に言うと、より高い権限が必要なアプリケーションが ChangeWindowMessageFilter() を呼び出してメッセージを明示的に許可しない限り、権限モードが低いアプリケーションは、一般的に、より高い権限が必要なアプリケーションにメッセージを送信することはできません。同様に、必要な権限がより低いアプリケーションは、必要な権限がより高いアプリケーションが所有する HWND を読むことはできますが、変更はできません。互換性の理由から API が権限の問題によりブロックされた場合でも、SendMessage や他の API は正常終了を返します。同様に、互換性の影響が大きく、セキュリティ上のリスクが低い場合は、必要な権限が低いアプリケーションが必要な権限が高いアプリケーションに、要求されないメッセージを送信することが許可される場合もあります。

現象

他のアプリケーションと対話するアプリケーションが、対話を停止します。

ウィンドウの配置を変更し、キーストロークを入力するユーティリティが、ウィンドウに余分なボタンなどを追加します。

異なるアプリケーション間でカット アンド ペーストを実行できません。

アプリケーションがまったく機能していない可能性や、リッチ テキスト、HTML などの想定される各種クリップボード形式をすべてサポートしていない可能性があります。

対処策

ジャーナル フック

WH_JOURNALPLAYBACK と WH_JOURNALRECORD は本質的にプロセス間で実行されるため、最高の権限レベルが必要です。多くの場合にすべての UI 権限が必要なわけではない SendInput() API をジャーナル フックの代わりに使用することができます。

WH_JOURNALPLAYBACK および WH_JOURNALRECORD ジャーナル フックは、本質的にはプロセス間のメッセージングであるため、より高い権限が必要です。ジャーナル フックの別の方法として、SendInput() 関数がありますが、これは多くの場合フル UI 権限を必要としません。

プログラムのソース コードがあるのであれば、以下の関数を使用するコードをすべて見直すことを検討してください。これらの API は、多くの場合、プロセス間のメッセージングであることを示唆しています。このリストは完全なものではなく、すべての問題を発見することはできないかもしれませんが、効率的に問題を発見する上で役立ちます。

SendInput

RegisterWindowMessage

BroadcastSystemMessageEx

BroadcastSystemMessage

SetWindowsHook

SetWindowsHookEx

CallNextHookEx

CallNextHook

SetWinEventHook

AttachThreadInput

FindWindowEx

FindWindow

CreateDesktop

CreateDesktopEx

OpenDesktop

OpenInputDesktop

EnumDesktops

EnumDesktopWindows

SwitchDesktop

SetThreadDesktop

GetThreadDesktop

CloseDesktop

CreateWindowStation

OpenWindowStation

EnumWindowStations

CloseWindowStation

GetProcessWindowStation

ソース ファイルは、findstr /s /g:temp.txt *.c *.cpp *.h *.hpp で検索できます。temp.txt は、テキスト ファイルにコピーされた前述の API リストです。網羅的な検索ではありませんが、問題の発見と、実際は問題でないことが問題であると誤って認識されないようにするのに役立ちます。

高 dpi スケーリング

機能の影響

概要

高 dpi 設定を使用するシステムでは、高 dpi をネイティブでは認識しないアプリケーションは、自動的に拡大されます。

現象

ピクセル サイズは長い間ほぼ一定でしたが、LCD メーカーは、高 dpi (dots per inch) とも呼ばれる、さらに細かいピクセルのモニタを積極的に発売しています。アプリケーションが、高 dpi 画面で標準の 96 dpi 画面と同じピクセル数を使用した場合、アプリケーションは非常に小さく表示されます。Windows Vista® および Windows Server® 2008 では、アプリケーションのビットマップをより大きいサイズで表示することによって 96 dpi 画面用に開発されたアプリケーションを拡大する機能を導入しました。すべてのビットマップ スケーリングと同様に、この処理によって表示は少し不鮮明になりますが、その他の点では画像は正しいサイズで適切に表示されます。アプリケーションで高 dpi をネイティブにサポートすることも選択でき、この場合は最大限の鮮明な表示が得られます。現在、アプリケーションでは、SetProcessDPIAware() を呼び出すことで、スケーリングの無効化や dpi 対応の宣言が可能です。マニフェストを使用した宣言方法については、調査中です。高 dpi をネイティブにサポートするアプリケーション プログラムの作成については、http://www.microsoft.com/japan/msdn/windows/windowsxp/highdpiapp.aspx を参照してください。

このセクションの後半では、DPI 非対応アプリケーションの潜在的な問題について説明します。アプリケーションは、「スクロール バーの幅は何ピクセルか」というような質問を Windows に尋ねます。96 dpi アプリケーションが尋ねると、Windows Vista® および Windows Server® 2008 は 96 dpi 用の答えをアプリケーションに返します。ただし、Windows がアプリケーションに基づいて回答しない場合があります。これは、通常 Windows Vista® および Windows Server® 2008 がまだ十分な情報を持っていないこと (フィードバックをお寄せください) が理由ですが、アプリケーションが答えを使用して実行しようとしている処理によって "正しい" 答えが変わることが理由の場合もあります(画面座標は、しばしばこの問題の原因となります)。

ほとんどの互換性の問題は、これらの不完全な条件に起因します。テスト時には、以下のことに注意してください。

  • テキストが切り取られている (部分的に非表示になっている)。

  • テキストが大きすぎる。

  • サイズや場所が間違って描画されているものがある。

対処策

高 dpi をネイティブにサポートするアプリケーション プログラムの作成については、http://www.microsoft.com/japan/msdn/windows/windowsxp/highdpiapp.aspx を参照してください。

PNG アイコン

機能の影響

概要

アイコン ファイル形式は (*.ico)、古い BMP 形式のアイコンに加え PNG 画像をサポートするようになりました。多くの Windows Vista® および Windows Server® 2008 アイコンは、PNG バリアントを使用しています。

現象

アイコン ファイルを表示または編集するアプリケーションでは、新しい形式が認識されない場合があります。

その他のリソースへのリンク

名前付きパイプの強化

概要

Windows Vista® および Windows Server® 2008 では、多くのサービスが、ローカル システムではなく NetworkService (NS) や LocalService (LS) などの必要な権限がより少ないアカウントで実行されています。サービスの強化は、あるサービスが侵害されてもシステム上の他のサービスを簡単には攻撃できないように、サービス間の区画化を強化するイニシアチブです。Windows Vista® および Windows Server® 2008 では、他のプロセスに乗っ取られないように、RPC サーバーが使用する名前付きパイプを強化します。

Windows XP では、RPC サーバーが名前付きパイプを作成し、パイプ上の ACL が LocalService や NetworkService にフル コントロールを付与します。これには、クライアントが接続できるようにパイプの "サーバー インスタンス" を作成する機能も含まれています。パイプのインスタンスを作成するプロセスは、そのパイプを最初に作成したプロセスだけです。マイクロソフトの ACL の変更により、サーバー インスタンスを作成する機能は、パイプを最初に作成したプロセスに限定されます。

現象

影響を受けているサービスは、LocalService または NetworkService として実行されるサービス、サービス Sid の使用をオプトインするサービス、"既定の" 名前付きパイプのセキュリティ記述子を要求する名前付きパイプで RPC を使用するサービスです。

サービス Sid の使用をオプトインするサービスは、既定ではサード パーティのサービスは影響を受けないことを意味します。サービス Sid は Windows Vista® および Windows Server® 2008 の新機能で、サービス構成で DWORD を設定することによってオプトインする必要があります。開発者はオプトイン時に、新しいサービスでテストして動作を強化することができます。この変更は、それらの動作の 1 つです。

"既定の" 名前付きパイプのセキュリティ記述子を要求する名前付きパイプで RPC を使用するサービスは、ある RPC サーバーが特別なニーズによりカスタム セキュリティ記述子を指定する場合に、変更が意識されないことを意味します。影響を受けるパイプの一覧を以下に示します。

Epmapper

Eventlog

Dav rpc

Keysvc

Winreg

Tapserv

W32time_alt

Termsvcapi

Ctx_winsta

Hydralspipe

SPAP の非推奨化 (Pstore)

概要

保護ストレージ (PStore) は、セキュアな状態を保つ必要がある、または変更されることがないようにする必要があるユーザー データを格納するインターフェイスをアプリケーションに提供します。Windows Vista® および Windows Server® 2008 では、Pstore が読み取り専用に変更されました。つまり、DPAPI を使用せずに新しい PStore データ項目を作成しようとするアプリケーションでは障害が発生します。

対処策

将来の PStore 手順には、DPAPI を使用してください。

その他のリソースへのリンク

WMI プロバイダ: 既定のセキュリティ ホスティング モデル

概要

WMI プロバイダ向けの既定の HostingModel は、LocalSystem から NetworkServiceHost に変更されました。

Windows の以前のリリース (Windows Vista® および Windows Server® 2008 Beta 2 以前) では、WMI プロバイダの HostingModel (__Win32Provider.HostingModel プロパティ) が指定されていない場合、既定は LocalSystem でした。LocalSystem は必要な権限が高いアカウントであるため、このセキュリティ コンテキストで動作する WMI プロバイダでは、プロバイダのコードの質とテストによっては、オペレーティング システムが権限昇格リスクにさらされます。

多くの場合、LocalSystem は不要であり、NetworkServiceHost コンテキストの方が適切です。多くの WMI プロバイダは、WMI クライアントに代わって要求された処理を実行し、(ImpersonationLevel=1) をクライアントのセキュリティ コンテキストに偽装する必要があるため、これが特に当てはまります。

現象

WMI プロバイダにホスティング モデルの定義がなく、LocalSystem レベルで動作しているように実行されると、WMI プロバイダは正常に動作しません。

対処策

WMI プロバイダのコードが、WMI クライアントを偽装して、クライアントのセキュリティ コンテキストで処理を実行することを保証するには、予想されているホスティング モデルを変更する必要があります。LocalSystem セキュリティ コンテキストが必要になることは、きわめてまれです。ただし、LocalSystem が絶対要件の場合は、プロバイダの MOF ファイル内で HostingModel=LocalSystemHost ステートメントを使用してホスティング モデルを明示的に指定してください。

その他のリソースへのリンク

ボリューム シャドウ コピー サービス

概要

ボリューム シャドウ コピー サービス (VSS) は、Windows XP と Windows Server 2003 で導入された新しいサービスです。VSS は、アプリケーション、ストレージ サブシステム、およびストレージ管理アプリケーション (バックアップ アプリケーションなど) 間のコミュニケーションを円滑化するフレームワークです。このサービスは、ストレージ データの特定の時点でのコピーを定義、維持および活用します。

現象

Windows XP バックアップ アプリケーションとの互換性

Windows XP およびライブラリは Windows Vista® および Windows Server® 2008 と互換性がないため、複数のインターフェイスが変更されました。少なくとも、VSS SDK 7.2 または Windows Vista® および Windows Server® 2008 Beta 2 と共にリリースされた Platform SDK の、ヘッダまたはライブラリのいずれかを使用して、アプリケーションを再コンパイルする必要があります。

Windows Server 2003 SP 1 バックアップ アプリケーションとの互換性

Windows Server 2003 SP1 用のバイナリは、Windows Vista® および Windows Server® 2008 と互換性があります。多くのバックアップ アプリケーションでは、%windir%system32 内のハード リンクの使用に加え、インボックスの書き込みプログラム、ファイルとレジストリの仮想化、および WRP などの変更に対応する必要があります。そのため、Windows Server 2003 SP1 のバックアップ アプリケーションがそのまま動作する可能性が低くなります。

Windows Vista® および Windows Server® 2008 用バックアップ アプリケーションのコンパイル

Windows Server 2003 で使用可能なインターフェイスを使用するアプリケーションは、VSS SDK 7.2 で提供されるヘッダおよびライブラリを使用してコンパイルできます。Windows Vista® および Windows Server® 2008 固有の新しいインターフェイスを使用するには、Windows Vista® および Windows Server® 2008 用の Platform SDK に含まれる VSS ヘッダとライブラリを使用して再コンパイルしてください。

VSS 書き込みプログラム

Registry Writer

Registry Writer は、以前のスピット書き込みプログラム スキームと比較すると Registry のバックアップと復元を適切に実行できるようになりました。ユーザー ハイブは、Registry Writer によってレポートされません。

COM+ RegDB Writer

%systemroot%\registration の内容をバックアップします。COM+ は、バックアップされているレジストリ キーに依存するため、レジストリでバックアップおよび復旧する必要があります。

MS Search Writer

作成後、シャドウ コピーから検索インデックスを削除します。

MSDE Writer

SQL 2000 および SQL 2005 データベースの既定の書き込みプログラムです。

WMI Writer

WMI VSS 書き込みプログラムは、バックアップ動作中にWMI 固有の状態とデータをバックアップするために使用されます。データには、WBEM リポジトリのファイルが含まれ、レジストリのバックアップが必要です。

BITS (Background Intelligent Transfer Service) Writer

FilesNotToBackup レジストリ キーを使用して、ディレクトリ %allusersprofile%\application\data\microsoft\network\downloader からファイルを除外します。

ASR (Automated System Recovery) Writer

システム上にディスクの構成を格納します。

System Writer

Windows Vista® および Windows Server® 2008 では、System Writer は以下の方法でファイルのリストを生成します。

  1. インストールされているすべての静的ファイル。属性 writeabletype = "static" またはコンポーネント マニフェスト内の writeabletype が "" であることによって識別されます。すべての WRP ファイル以外に、静的と設定されるファイルがいくつかある場合もあります。たとえば、ゲームは管理者が親コントロールを変更できるように、静的ですが WRP ではありません。

  2. すべてのマニフェスト、オプション コンポーネント、およびサード パーティの Win32 ファイルを含む WinSxS フォルダ

  3. (PnP によって所有されている) インストール済みドライバのすべての PnP ファイル

  4. すべてのユーザー モード サービスと PNP ではないドライバ

  5. CryptSvc によって所有されているすべてのカタログ

%windir%\system32 内のファイルは、winsxs ディレクトリへのハード リンクです。

復旧アプリケーションは、ファイルとレジストリを保存し、システム スナップショットに一致するように ACL を設定します。また、適切なハード リンクも作成する必要があります。

Microsoft Optimization Writer

この書き込みプログラムは、スナップショットから特定のファイルを削除します。ファイルの削除により、スナップショットのメンテナンス段階での Copy On Write (COW) の入出力を最小限に抑えることができます。また、ファイルは一般的に一時ファイルであるか、またはユーザーやシステムの状態を構成しないファイルです。

その他のリソースへのリンク

Standard User Analyzer

はじめに

"Standard User Analyzer" (以前の呼び名は "LUA Analyzer") は、独立系ソフトウェア開発会社 (ISV)、IT 専門家、およびエンド ユーザーが、標準ユーザーとして実行しているときに、アプリケーション内の考えられる問題を診断するために役立つツールです。Standard User Analyzer は、Microsoft Application Verifier の一部である "LUA Predictor" 技術に基づいています。

インストールの前提条件と互換性

前提条件
  • オペレーティング   システム : Windows Vista® および Windows Server® 2008、Windows XP、および Windows Server 2003。

       現時点で入手できるのは、Standard User Analyzer の 32 ビット バージョンのみです。
  • インストールの前提条件 : Standard User Analyzer のインストールを始める前に、Application Verifier をインストールする必要があります。Application Verifier は、Microsoft Web サイト (英語) から無償でダウンロードできます。

インストール

  • Standard User Analyzer をインストールするには、SUAnalyzer.msi ファイルを実行します。Standard User Analyzer のファイルはすべて、"Program Files\Standard User Analyzer" フォルダにインストールされます。

       Standard User Analyzer を使用する前に、最新の Application Verifier をインストールする必要があります。
  • Standard User Analyzer を使用して、アプリケーション内の標準ユーザーの互換性問題を診断します。

   アプリケーションの標準ユーザーの互換性問題を正しく特定するため、Standard User Analyzer を Windows Vista® および Windows Server® 2008 コンピュータで実行することをお勧めします。

Windows Vista® および Windows Server® 2008 コンピュータの標準ユーザーによって以下の手順を実行してください。

  1. [スタート] ボタンをクリックして [すべてのプログラム] をポイントし、[Standard User Analyzer] をダブル クリックします。

  2. [App Info] タブの [Target Application] フィールドで、ターゲット アプリケーションの実行可能ファイルのディレクトリの場所を入力するか、[Browse] 機能を使用します。

  3. [App Info] タブの [Parameters] フィールドで、可能であれば、アプリケーションのパラメータを入力します。

  4. [App Info] タブで [Launch Elevated] チェック ボックスを選択し、[Launch] ボタンをクリックします。

  5. SUAnalyzerSrv.exe に対してユーザー アカウント制御資格情報プロンプトが表示されたら、管理者の資格情報を指定し、[Submit] をクリックします。

  6. ターゲット アプリケーションに対するユーザー アカウント制御資格情報プロンプトで、管理者の資格情報を指定し、[Submit] をクリックします。

       SUAnalyzerSrv.exe プロセスは、この手順の実行中に特権の昇格を要求する場合があります。このプロセスは、Application Verifier における設定の変更など、管理者のアクセス トークンを必要とするタスクの管理を担当するバックエンド プロセスです。

テスト中、Standard User Analyzer はアプリケーションを起動し、処理を監視し、アプリケーションが終了するまで待機します。Standard User Analyzer は、その後、アプリケーションのログを生成して解析しますが、完了にはある程度時間がかかる場合があります。ログが生成され解析されたら、個々のタブをクリックして、Standard User Analyzer によって発見された具体的な問題を表示してください。

タブ

詳細

File

ファイル システムのアクセスに関する問題を一覧表示します。
例: 通常は管理者しかアクセスできないファイルに書き込もうとするアプリケーション。

Registry

システム レジストリのアクセスに関する問題を一覧表示します。
例: 通常は管理者しかアクセスできない場所である HKLM の下のレジストリ キーに書き込もうとするアプリケーション。

INI

WriteProfile API に関する問題を一覧表示します。
WriteProfile API は元々 16 ビット Windows 用に使用されていましたが、新しいアプリケーションでもよく使用されています。
たとえば、Windows XP の電卓などがあります。ビューを "Standard" から "Scientific" に変更すると、calc.exe は、管理者ユーザーしか書き込めない windows\win.ini に書き込むために WriteProfile API を呼び出します。

Token

アクセス トークンのチェックに関する問題を一覧表示します。
アプリケーションでユーザーのアクセス トークンの "Builtin\Administrators" セキュリティ識別子 (SID) を明示的にチェックすると、多くの場合、アプリケーションは標準ユーザーに対して機能しません。

Privilege

権限に関する問題を一覧表示します。
例: アプリケーションが明示的に "SeDebugPrivilege" を有効にすると、アプリケーションは標準ユーザーに対して機能しません。

Name Space

アプリケーションがシステム オブジェクト (たとえば、イベント、メモリのマッピング) を、限定された名前空間に作成するときに発生する問題を一覧表示します。このエラーが発生するアプリケーションは標準ユーザーに対して機能しません。

Other Objects

ファイルとレジストリ キー以外のオブジェクトへのアクセスに関する問題を一覧表示します。

図 20: Standard User Analyzer のタブの詳細

個々のタブで問題をクリックすると、Standard User Analyzer の左下のパネルに、ログ ファイルからのすべての関連レコードが表示されます。その後、任意のレコードをクリックすると、右下のパネルに、フォーマットされたメッセージ、パラメータ、スタック トレースなどのそのレコードの詳細情報が表示されます。ISV は、アプリケーションのソース コードで問題を追跡するためにスタック トレース データを使用することができます。

Standard User Analyzer のメイン メニュー

[File] メニュー:

  • Open Log File: 保存されているログ ファイルをロードします。

  • Export Log File: 現在のログ ファイルを保存します。

  • View Raw Log File: 現在のログ ファイルを raw xml 形式で開きます(警告: ファイルが大きい場合、開くのに時間が必要)。

  • Exit: プログラムを終了します。

[View] メニュー:

  • 表示するメッセージの種類を選択します。通常は、"エラー メッセージ" の表示にのみ使用されます。

[Options] メニュー:

  • Filter Noise: "ノイズが多い" エントリの表示と非表示を切り替えます。

  • Load Noise Filter File: ノイズ フィルタ ファイルをロードします。

  • Export Noise Filter File: ノイズ フィルタ ファイルを保存します。

  • Only Display Records with Application Name in StackTrace: ノイズを低減します。ただし、Standard User Analyzer は最初の 32 個のスタック フレームしか取り込まないため、このオプションを有効にする場合、呼び出しスタックが 32 フレームよりも深いときは、本当に重要な問題が除去される可能性もあります。

  • Logging: ログのオプション。ログ ファイルが大きくなりすぎるのを避けるため、[Log Information] チェック ボックスはオフのままにすることをお勧めします。

[Help] メニュー:

  • [Help] メニュー。

DHTML 編集コントロール

その他のリソースへのリンク

ヘルプ エンジン サポート

マイクロソフトは、Windows Platform でヘルプおよびサポート技術を提供することを約束し、ソフトウェア開発者向けの新しいソリューションの調査を続行していきます。以下の情報は、Windows ヘルプ、HTML ヘルプ 1.x、ヘルプとサポート センター、および Assistance Platform クライアントという 4 つのマイクロソフト ヘルプ技術の Windows Vista® および Windows Server® 2008 でのサポートについて明記したものです。

Windows ヘルプ - WinHlp32.exe

Windows ヘルプ WinHlp32.exe は、Microsoft Windows 3.1 オペレーティング システムから Microsoft Windows に搭載されているヘルプ プログラムです。Windows ヘルプ プログラム (WinHlp32.exe) は、ファイル名拡張子が .HLP の 32 ビット ヘルプ コンテンツ ファイルを表示するために必要です。

Windows ヘルプは、Windows Vista® および Windows Server® 2008 では非推奨です。Windows Vista® および Windows Server® 2008 でファイル名の拡張子が .HLP である 32 ビット ヘルプ ファイルを表示するには、マイクロソフト ダウンロード センターから WinHlp32.exe をダウンロードしてインストールする必要があります。

マイクロソフトは、Windows Vista では Windows ヘルプ アプリケーションを使用しないことをソフトウェア開発者に強く推奨します。.HLP ファイルに依存するプログラムを出荷するソフトウェア開発者には、ヘルプ エクスペリエンスを CHM、HTML、XML などの代わりのヘルプ ファイル形式に移行することを推奨します。また、WinHelp() API からの呼び出しも新しいコンテンツ ソースに変更する必要があります。ある形式から別の形式にコンテンツを変換するときに役立つサードパーティ ツールもいくつか提供されています。

HTML ヘルプ 1.x (HH.exe)

マイクロソフトの HTML ヘルプ 1.x (HH.exe) は、Windows 98 から Windows リリースに搭載されているヘルプ システムです。HTML ヘルプは、ファイル名拡張子が .CHM のコンパイル済みヘルプ ファイルを表示するために必要です。

HTML ヘルプ は、Windows Vista® および Windows Server® 2008 に搭載されます。ただし、エンジンには重要な更新しか行われません。Windows Vista® および Windows Server® 2008 または将来の Windows リリースで HTML ヘルプ エンジンに新しい機能や拡張機能が追加される予定はありません。

HTML ヘルプの機能の詳細および HTML ヘルプ用のファイルの作成に関するガイダンスについては、HTML ヘルプ 1.4 SDK (http://msdn2.microsoft.com/en-us/library/ms670169.aspx) (英語) サイトを参照してください。

ヘルプとサポート センター (HelpCtr.exe)

ヘルプとサポート センター (HelpCtr.exe) は、Windows XP および Windows Server 2003 用のヘルプ アプリケーションであり、ファイル名拡張子が .CHM のコンパイル済みヘルプ ファイルを表示していました。

ヘルプとサポート センターは Windows Vista® および Windows Server® 2008 には搭載されておらず、この機能はサポートされていません。ファイル名拡張子が .CHM のコンパイル済みヘルプ ファイルは、上記の HTML ヘルプ アプリケーションでしか表示されません。

Assistance Platform クライアント (HelpPane.exe)

Assistance Platform クライアント (HelpPane.exe) は、Windows Vista® および Windows Server® 2008 向けの新しいヘルプ エンジンです。このヘルプ エンジンは、Windows の以前のバージョンとは互換性がありません。Assistance Platform クライアントは、ファイル名拡張子が .H1S のヘルプ ファイルを表示するために必要です。

Windows Vista® および Windows Server® 2008 では、OEM、システム ビルダ、および企業ユーザーは、ライセンス契約の下で Assistance Platform クライアントをカスタマイズできますが、サード パーティ プログラムは Assistance Platform クライアントを使用できません。Assistance Platform クライアントのカスタマイズの詳細については、Windows SDK を参照してください。

接合点およびバックアップ アプリケーション

Windows Vista® および Windows Server® 2008 では、ユーザー データの既定のロケーションが変更されました。たとえば、Documents and Settings ディレクトリのロケーションは、%systemdrive%\Documents and Settings から %systemdrive%\Users に移動しました。レガシ アプリケーションとの相互運用性を有効にするために、非推奨ロケーションには接合点が使用されて、Windows Vista® および Windows Server® 2008 の新しいロケーションを指し示します。たとえば、C:\Documents and Settings は C:\Users を示す接合点になります。Windows Vista® および Windows Server® 2008 のバックアップ アプリケーションでは、接合点を復元できる必要があります。

これらの接合点は、FILE_ATTRIBUTE_REPARSE_POINT および FILE_ATTRIBUTE_SYSTEM のファイル属性を持ち、ACL は "Everyone Deny Read" に設定されます。アプリケーションから特定のパスを変更するには、許可が必要です。ただし、これらの接合点のコンテンツを列挙することはできません。

接合点のクラス

Windows Vista® および Windows Server® 2008 では、アプリケーション互換性のプロファイルによって作成可能な 2 つのディレクトリ接合カテゴリが存在します。

  1. ユーザー単位の接合点: ユーザー プロファイルごとに内部で作成される接合点で、従来の名前空間に対してアプリケーションの互換性をもたらします。

    1. すなわち、C:\Users\<username>\My Documents から C:\Users\<username>\Documents への接合です。

    2. これらの接合点は、ユーザー プロファイル自体が作成されるときに、プロファイル サービスによって作成されます。

  2. システム接合点: システムで作成される他のすべての接合点を示し、<username> ノードの直下には存在しません。

    1. これには次の接合点が含まれます。

      1. Documents and Settings

      2. ALL User、Public、Default User のプロファイル内の接合点

    2. これらの接合点は、Windows Vista® および Windows Server® 2008 PC で Machine OOBE から呼び出されるときに、userenv.dll によって作成されます。

21: 親フォルダの接合点の要件

ディレクトリの接合点の作成場所

接合先

..\Documents and Settings\

..\Users\

22: 従来のユーザー   データ   フォルダの接合点の要件

ディレクトリの接合点の作成場所

接合先

..\Documents and Settings\<username>\My Documents

..\Users\<username>\Documents

..\Documents and Settings\<username>\My Documents\My Music

..\Users\<username>\Music

..\Documents and Settings\<username>\My Documents\My Pictures

..\Users\<username>\Pictures

..\Documents and Settings\<username>\My Documents\My Videos

..\Users\<username>\Videos

23: ユーザー単位の従来のアプリケーション   データ   フォルダの接合点の要件

ディレクトリの接合点の作成場所

接合先

..\Documents and Settings\<username>\Local Settings\

..\Users\<username>\AppData\Local

..\Documents and Settings\<username>\Local Settings\Application Data

..\Users\<username>\AppData\Local

..\Documents and Settings\<username>\Local Settings\Temporary Internet Files

..\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files

..\Documents and Settings\<username>\Local Settings\History

..\Users\<username>\AppData\Local\Microsoft\ Windows\History

..\Documents and Settings\<username>\Application Data\

..\Users\<username>\AppData\Roaming

24: ユーザー単位の従来の OS 設定フォルダの接合点の要件

ディレクトリの接合点の作成場所

接合先

..\Documents and Settings\<username>\Cookies\

..\Roaming\Microsoft\Windows\Cookies

..\Documents and Settings\<username>\Recent\

..\Roaming\Microsoft\Windows\Recent

..\Documents and Settings\<username>\Nethood\

..\Roaming\Microsoft\Windows\Network Shortcuts

..\Documents and Settings\<username>\Printhood\

..\Roaming\Microsoft\Windows\Printer Shortcuts

..\Documents and Settings\<username>\SendTo\

..\Roaming\Microsoft\Windows\Send To

..\Documents and Settings\<username>\StartMenu\

..\Roaming\Microsoft\Windows\StartMenu

..\Documents and Settings\<username>\Templates\

..\Roaming\Microsoft\Windows\Templates

25: 接合点が不要な従来のプロファイル   フォルダ

従来の場所

説明

..\Documents and Settings\<username>\Desktop

Documents and Settings の接合対象である

..\Documents and Settings\<username>\Favorites

Documents and Settings の接合対象である

..\Documents and Settings\<username>\Local Settings\Temp

Local Setting フォルダから Local への接合対象である

26: 従来の All Users フォルダの接合点の要件

共通リンクの作成場所

接合先

..\Users\All Users

..\ProgramData

27: ユーザーの接合点

ディレクトリの接合点の作成場所

接合先

..\ProgramData\Desktop

..\Users\Public\Desktop

..\ProgramData\Documents

..\Users\Public\Documents

..\ProgramData\Favorites

..\Users\Public\Favorites

..\Users\Public\Documents\My Music

..\Users\Public\Music

..\Users\Public\Documents\My Pictures

..\Users\Public\Pictures

..\Users\Public\Documents\My Videos

..\Users\Public\Videos

..\ProgramData\Application Data\

..\ProgramData

..\ProgramData\Start Menu\

..\ProgramData \Microsoft\Windows\StartMenu

..\ProgramData\Templates\

..\ProgramData\Microsoft\Windows\Templates

28: 従来の Default Users フォルダの接合点の要件

ディレクトリの接合点の作成場所

接合先

..\Documents and Settings\Default User

..\Users\Default

..\Documents and Settings\Default User\Desktop

..\Users\Default\Desktop

..\Documents and Settings\Default User\My Documents

..\Users\Default\Documents

..\Documents and Settings\Default User\Favorites

..\Users\Default\Favorites

..\Documents and Settings\Default User\My Documents\My Music

..\Users\Default\Music

..\Documents and Settings\Default User\My Documents\My Pictures

..\Users\Default\Pictures

..\Documents and Settings\Default User\My Documents\My Videos

..\Users\Default\Videos

..\Documents and Settings\Default User\Application Data\

..\Users\Default\AppData\Roaming

..\Documents and Settings\Default User\Start Menu\

..\Users\Default\AppData\Roaming\Microsoft\Windows\StartMenu

..\Documents and Settings\Default User\Templates\

..\Users\Default\AppData\Roaming\Microsoft\Windows\Templates

29: Program Files の接合点

ディレクトリの接合点の作成場所

接合先

..\Program Files (Localized name)

..\Program Files

..\Program Files\Common Files (Localized Name)

..\Program Files\Local Files

バックアップと復旧のアプリケーションの互換性

はじめに

Windows® Vista®; および Windows Server® 2008 には、バックアップ アプリケーションの互換性に影響する複数の変更点があります。このドキュメントでは、これらの変更点に関する問題と特定の要件について説明します。これはボリューム シャドウ コピー サービス (VSS) インフラストラクチャと Windows バックアップ処理に精通したバックアップ アプリケーション開発者向けです。この機能と変更点には重要でないものもありますが、ベンダは影響がないことを検証し、影響がある場合は適切な軽減処置を講じる必要があります。このドキュメントは、すべての機能を詳細に説明するのではなく、主としてバックアップ ツールへの影響に関する事項を取り扱います。特定のトピックの詳細については、このドキュメントの最後に記載されるリンクや MSDN を参照してください。

Windows XP バックアップ アプリケーションとの互換性

Windows XP およびライブラリは Windows Vista® および Windows Server® 2008 と互換性がないため、複数のインターフェイスが変更されました。少なくとも、Microsoft Volume Shadow Copy Service SDK 7.2 (VSS SDK 7.2) または Windows Vista® および Windows Server® 2008 Platform SDK のヘッダまたはライブラリを使用して、アプリケーションを再コンパイルする必要があります。

Windows Server Service 2003 Service Pack 1 のバックアップ アプリケーションとの互換性

Windows Server 2003 SP1 のバイナリは、Windows Vistar® および Windows Serverr® 2008 と互換性があります。多くのバックアップ アプリケーションでは、%windir%system32 内のハード リンクの使用に加え、インボックスの書き込みプログラム、ファイルとレジストリの仮想化、および WRP などの変更に対応する必要があります。それゆえ、Windows Server 2003 SP1 のバックアップ アプリケーションは、Windows Vistar® および Windows Serverr® 2008 の下で機能するように、これらの変更に対処する必要があります。

Windows Vista® および Windows Server® 2008 用バックアップ アプリケーションのコンパイル

Windows Server 2003 で使用可能なインターフェイスを使用するアプリケーションは、VSS SDK 7.2 で提供されるヘッダおよびライブラリを使用してコンパイルできます。Windows Vista® および Windows Server® 2008 固有の新しいインターフェイスを使用するには、Windows Vista® および Windows Server® 2008 用の Platform SDK に含まれる VSS ヘッダとライブラリを使用してアプリケーションをコンパイルする必要があります。Windows Vista® および Windows Server® 2008 のヘッダとライブラリを使用してコンパイルしたバイナリは、Windows Server 2003 では動作しません。

トランザクションとの相互運用性

Windows Vista® および Windows Server® 2008 では、トランザクションのサポートも提供され、VSS ではスナップショットを作成する前に、Kernel Transaction Manager (KTM) および Distributed Transaction Coordinator (DTC) の両方が停止します。これによって新たに次の 2 つのタイムアウト エラーが発生します。

  • VSS_E_TRANSACTION_FREEZE_TIMEOUT

  • VSS_E_TRANSACTION_THAW_TIMEOUT

要求元がこれらのエラーを受け取った場合、スナップショットの作成を再試行する必要があります。レジストリとファイル システムの処理も実行します。レジストリの場合は、Registry Writer によってトランザクションの整合性が保証されます。NTFS 処理のトランザクションの整合性は、作成後にシャドウ コピーの読み取り/書き込みを実装し、部分的に実行された処理をロールバックすることで保証されます。

インターネットの検索機能との統合

概要

Windows Vista® および Windows Server® 2008 は、[スタート] メニューからインターネットを簡単に検索できる新しい機能を搭載しています。これは、ユーザーが [スタート] メニューの検索バーにテキストを入力した後で、[インターネットの検索] オプションをクリックすると機能します。インターネットの検索機能を実行するとき、Windows Vista® および Windows Server® 2008 は、HTTP:// プロトコルの既定に設定されたアプリケーションを、引数に検索語句を付加して実行します。

拡張性

次に、インターネットの検索機能からアプリケーションを正常に起動する方法について説明します。

  • Windows Vista® および Windows Server® 2008 では、ユーザーは [スタート] メニューの検索ボックスから直接インターネット検索を実行できます。

    ac_searchinternet_003.gif
    30: [ スタート ] メニューの検索ボックス

  • ユーザーが [インターネットの検索] リンク (図 1.1 を参照) をクリックすると、Windows Vista® および Windows Server® 2008 は次のパラメータを付加して AssocQueryString 関数を呼び出すことで、http プロトコルの既定のプログラムを特定します。

    AssocQueryString(NULL, ASSOCSTR_EXECUTABLE, L"http", L"open", szBrowser, &cch)

    この szBrowser には現在登録されているブラウザの実行ファイルの場所が収められます。

    ac_searchinternet_004.gif
    31: Windows Live Search



  • ユーザーが [インターネットの検索] リンク (図 1.1 を参照) をクリックすると、Windows Vista® および Windows Server® 2008 は次のパラメータを付加して AssocQueryString 関数を呼び出すことで、http プロトコルの既定のプログラムを特定します。

    AssocQueryString(NULL, ASSOCSTR_EXECUTABLE, L"http", L"open", szBrowser, &cch)

    この szBrowser には現在登録されているブラウザの実行ファイルの場所が収められます。

    ac_searchinternet_004.gif
    31: Windows Live Search


次に、Windows Vista® および Windows Server® 2008 は ShellExecuteEX を呼び出して、このプログラムを起動し、? <search term> を lpParameters 引数として渡します。この <search term> は検索ボックスの内容に置き換えられます。これはブラウザのコマンド ラインに ? <search term> を追加するのとほぼ同じ流れです。

渡されたパラメータをどのように処理するかについては、各ブラウザが決定します。パラメータの処理については、検索文字列をブラウザの既定の検索ハンドラに直接渡す方法をお勧めします。たとえば、図 31 では Windows Vista® および Windows Server® 2008 は検索語句に "Hello World" と指定して Internet Explorer ブラウザを起動しました。Internet Explorer はこの語句を既定の検索ハンドラに直接渡します。

この機能は、どのブラウザでも利用することができます。たとえば、Contoso Internet Browser が http プロトコルの既定ハンドラとして登録されていると仮定します。このブラウザの実行ファイルは、C:\Program Files\Contoso\contoso.exe に配置されており、AssocQueryString(NULL, ASSOCSTR_EXECUTABLE, L"http", L"open", szBrowser, &cch) の呼び出しを実行すると、szBrowser にはこの exe ファイルのパスが指定されます。ShellExecuteEX は、この情報を使用して Contoso ブラウザを起動し、"?Hello World" を渡します。

ブラウザがこれを正常に処理するには、前に疑問符が付加され、両端を引用符で囲まれた引数を実行可能ファイルに確実に渡す必要があります。以下に実行ファイルの検索パラメータの受け渡し処理の例を 2 つ示します。

Internet Explorer:

C:\Program Files\Internet Explorer\iexplore.exe "? <search term> "

C:\Program Files\Internet Explorer\iexplore.exe "? Hello World"

Contoso ブラウザ:

C:\Folder\contoso.exe "? <search term> "

C:\Folder\contoso.exe "? Hello World"

対処策

その他のリソースへのリンク

MMC が DEP (Data Execution Protection: データ実行防止機能) 対応である必要性

機能の影響

概要

MMC.EXE は、常に DEP (Data execution protection: データ実行防止機能) を有効にして実行されます。スナップインは DEP 対応である必要があります。この機能はオフにすることはできず、互換モードは存在しません。

現象

DEP 対応でないスナップインは、MMC へのロード エラーの原因となる可能性や正常に機能しない可能性があります。

対処策

この機能はオフにすることはできず、互換モードは存在しません。

ネットワーキング: Windows ファイアウォールの無効化

機能の影響

概要

ユーザーがインストールしたファイアウォール (Windows XP との互換性はあるが、Windows Vista® および Windows Server® 2008 との互換性はない) によって Windows Vista® および Windows Server® 2008 の Windows ファイアウォールが無効化されることを回避するために、マイクロソフトでは、Windows Firewall XP SP2 INetFwProfile.put_FirewallEnabled(VARIANT_FALSE) 関数を Windows Vista® および Windows Server® 2008 で使用することを非推奨としています。Windows Vista® および Windows Server® 2008 でこの関数を呼び出すと、次の処理が行われます。

  1. エラー コード E_NOTIMPL を返す。

  2. ユーザーにメッセージを表示する。

  3. Windows イベント ログに適切なイベントのログを記録する。

現象

Windows XP SP2 の INetFwProfile.put_FirewallEnabled(VARIANT_FALSE) 関数を使用して Windows Vista® および Windows Server® 2008 の Windows ファイアウォールを無効化するアプリケーションは、エラー コードを受け取ります。

対処策

Windows ファイアウォールを独自のファイアウォール ソリューションに置換するアプリケーション (通常はファイアウォール) の場合、次のセキュリティに関する点を慎重に検討する必要があります。

  • Windows Vista® および Windows Server® 2008 は IPv6 と IPv4 を標準でサポートしており、IPv6 アドレスを自動的に所持します。したがって、独自のファイアウォール ソリューションでは IPv4 と IPv6 の両方のフィルタリング機能が必要になります。

  • さらに、Windows Vista® および Windows Server® 2008 は他の IP プロトコル (GRE、L2TP、PGM、ICMPv6 など) をサポートするため、独自のファイアウォール ソリューションには任意のプロトコル フィルタリング (IANA Protocol 0 ~ 255) および ICMP のタイプとコードのフィルタリングが必要です。

  • Windows Vista® および Windows Server® 2008 では、ユーザー モードとカーネル モードの両方にリスニング プロセスがあります (つまり、システム プロセス、http.sys、smb.sys)。したがって、ユーザー モードとカーネル モードの両方のネットワーク トラフィックをフィルタリングする必要があります。

さらに、マイクロソフトでは、このようなアプリケーションに対して次の事項を推奨しています。

  • アプリケーションが前述のセキュリティ関連項目のすべてに対処しない限り、Windows ファイアウォールを置き換えない。

  • アプリケーションから Windows ファイアウォールを無効化するか、あるいは Windows ファイアウォールの高度なセキュリティ機能を無効化する前に、ファイアウォールの状態を確認し、必要に応じて復元できるようにする。

  • Windows Service Hardening による規制が実施されるため、ファイアウォール サービス (mpssvc) を無効化しない。代わりに、Windows ファイアウォール API を使用してファイアウォールの状態を "オフ" に変更して、ファイアウォールを実質的に無効にするが、Windows Service Hardening の制限は適用されたままにする。

ユーザー保護のために、高度なセキュリティ機能を持つ Windows ファイアウォールの無効化は、(1) 推奨設定を持つファイアウォール ソリューションを正常に有効化し、かつ (2) 高度なセキュリティ機能を持つ Windows ファイアウォールの無効化をユーザーに通知した後にのみ行います。

その他のリソースへのリンク

Windows Server® 2008 に関連する問題

このドキュメントの以下の部分では、Windows Server® 2008 にのみ該当し、Windows Vista には該当しない項目について説明します。

読み取りRead Only専用ドメイン コントローラ (RODC)

機能の影響

概要

読み取り専用ドメイン コントローラは、Windows Server® 2008 オペレーティング システムの新しい種類のドメイン コントローラです。RODC を使用することによって、組織は物理的なセキュリティを保証できない場所に容易にドメイン コントローラを展開できます。RODC は、特定のドメインの Active Directory® ドメイン サービス (AD DS) にあるデータベースの読み取り専用レプリカをホストします。

Windows Server® 2008 のリリース以前は、ユーザーはワイド エリア ネットワーク (WAN) を介してドメイン コントローラで認証を受ける必要がある場合、現実的な代替方法はありませんでした。多くの場合、この方法は効率的なソリューションではありませんでした。支店のオフィスでは、書き込み可能なドメイン コントローラに必要とされる物理的なセキュリティを提供できないことがしばしばあります。また、支店のオフィスでは、ハブ サイトに接続するときにネットワーク帯域幅が十分ではないことも一般的です。このため、ログオンにかかる時間が増加し、ネットワーク リソースへのアクセスの障害にもなります。

Windows Server® 2008 以降では、組織は RODC を展開してこのような問題を解決できます。その結果、前述の状況にあったユーザーは、以下の恩恵を受けることができます。

  • セキュリティの向上

  • ログオン時間の短縮

  • ネットワーク上のリソースへのアクセスの効率化

現象

Active Directory に対して書き込みを行うアプリケーションは、潜在的に RODC の影響を受ける可能性があり、書き込み失敗や新たに書き込まれたデータの読み取りに失敗するといった互換性問題に遭遇する可能性があります。

対処策

データの書き込みを行うアプリケーションが、書き込み可能な DC か読み取り専用 DC かを判別することなく DC を検索することがあります。

通常、アプリケーションが最も近くのドメイン コントローラを要求する場合、次の 2 つの方法を使用します。

  • 「Binding to Active Directory Domain Services」 で推奨されているサーバーレス バインド

  • ドメイン コントローラ ロケータの呼び出し

Windows Server 2008 では、ドメイン コントローラ ロケータの呼び出しにより、任意のドメイン コントローラを返すことができます。これには、Windows 2000 Server または Windows Server 2003 を実行しているドメイン コントローラ、または Windows Server 2008 を実行している書き込み可能なドメイン コントローラまたは読み取り専用ドメイン コントローラが含まれます。アプリケーションでディレクトリ オブジェクトに対して書き込みを行う必要る場合に、サーバーを使用しないバインドの呼び出しによって RODC を取得すると、問題が発生することがあります。この場合は、書き込み操作が、ハブ サイトで Windows Server 2008 を実行している書き込み可能なドメイン コントローラに紹介されます。その時点で使用しているハブ サイトへの WAN 接続によっては、アプリケーションでハブへの接続に失敗し、エラーが報告される場合があります。書き込み操作が正常に実行された場合でも、その後書き込まれたデータの読み取りは失敗することがあります。これは、このデータを元の RODC にレプリケートするのに伴う遅延によるものです。

ドメイン コントローラで実行する必要があるアプリケーションは、RODC に対応する必要があります。

ドメイン コントローラで実行する必要があるアプリケーションでは、ドメイン コントローラが書き込み可能であるのか、または RODC であるのかを判断する必要があります。レジストリを確認したり、「OSVERSIONINFOEX」(英語) で説明されている OSVERSIONINFOEX を使用したりしても、書き込み可能なドメイン コントローラと RODC は区別できません。この方法を使用しても、RODC はドメイン コントローラとして示されます。

これを判断するには、rootDSE の supportedCapabilities 属性を確認します。詳細については、「Serverless Binding and RootDSE」(英語) を参照してください。オブジェクト識別子の値 1.2.840.113556.1.4.1920 が設定されている場合、そのドメイン コントローラは RODC です。

DsRoleGetPrimaryDomainInformation 関数を使用して、ドメイン コントローラが RODC であるかどうかを判断することもできます。DSROLE_PRIMARY_DOMAIN_INFO_BASIC 構造体に、新しいフラグが追加されました。

その他のリソースへのリンク

Windows Server® 2008 の役割

機能の影響

概要

Windows Server® 2008 は完全にコンポーネント化されています。Windows Server® 2008 の役割は、高度に細分化され、オプションになっています。既定では、どのサーバーの役割もアクティブではありません。以前のバージョンの Windows Server のサーバーの役割は、Windows Server® 2008 ではまったく同じというわけではありません。

Windows Server 2003 では 1 つの役割であった Web サーバーとアプリケーション サーバーは、Windows Server® 2008 は 2 つの役割に分割されました。

現象

インストールの手順およびスクリプトが、機能しなくなったり、結果が不適切になったりする場合があります。

対処策

新しいサーバーをインストールするためのインストールの手順およびスクリプトを更新する必要があります。

その他のリソースへのリンク

Windows Server® 2008 での Windows アプリケーションのエクスペリエンス

機能の影響

概要

Windows Server® 2008 は、既定では、ユーザーのデスクトップ エクスペリエンスに含まれると見なされるアプリケーションやアクセサリをインストールしません。これらのアプリケーションは、サーバー マネージャで選択してインストールできます。

現象

Windows デスクトップ アプリケーションおよびアクセサリに依存するアプリケーションおよびインストーラは、実行できない場合やインストールできない場合があります。Windows Server の多くのユーザーはデスクトップ アプリケーションを必要としないので、デスクトップ アクセサリおよびツールは別の機能インストールにまとめられています。

対処策

デスクトップ アクセサリおよびツールに依存するアプリケーションでは、アプリケーションのインストールの前にデスクトップ アクセサリまたはツールがインストールされるようにする必要があります。

その他のリソースへのリンク

Windows Server® 2008 Server Core

機能の影響

概要

Windows Server® 2008 では、Server Core と呼ばれる新しい概念が導入されています。

Server Core は、Windows Server® 2008 オペレーティング システムを実行するコンピュータ用の最小のサーバー インストール オプションです。Server Core は x86 および x64 (Itanium はなし) で利用可能です。

Server Core によって、機能が制限された、メンテナンス作業があまり必要ではないサーバー環境を実現できます。Server Core は、限られた役割のセットをサポートしています。現時点で、Server Core は以下の役割をサポートしています :

  • DHCP

  • DNS

  • Active Directory ドメイン コントローラ (RODC を含む)

  • Active Directory LDS (ADAM)

  • 以下を含むファイル サーバー :

  • プリント サーバー

  • メディア サービス

  • Windows Virtualization

  • IIS 7.0 (ただし ASP.NET およびリモート管理は含まず)

  • DNS

  • Active Directory ドメイン コントローラ (RODC を含む)

  • Active Directory LDS (ADAM)

  • 以下を含むファイル サーバー :

  • プリント サーバー

  • メディア サービス

  • Windows Virtualization

  • IIS 7.0 (ただし ASP.NET およびリモート管理は含まず)

  • Active Directory ドメイン コントローラ (RODC を含む)

  • Active Directory LDS (ADAM)

  • 以下を含むファイル サーバー :

  • プリント サーバー

  • メディア サービス

  • Windows Virtualization

  • IIS 7.0 (ただし ASP.NET およびリモート管理は含まず)

  • Active Directory LDS (ADAM)

  • 以下を含むファイル サーバー :

  • プリント サーバー

  • メディア サービス

  • Windows Virtualization

  • IIS 7.0 (ただし ASP.NET およびリモート管理は含まず)

  • 以下を含むファイル サーバー :

  • プリント サーバー

  • メディア サービス

  • Windows Virtualization

  • IIS 7.0 (ただし ASP.NET およびリモート管理は含まず)

    • DFSR (FRS)

    • NFS

    • ファイル クウォータ

  • プリント サーバー

  • メディア サービス

  • Windows Virtualization

  • IIS 7.0 (ただし ASP.NET およびリモート管理は含まず)

  • メディア サービス

  • Windows Virtualization

  • IIS 7.0 (ただし ASP.NET およびリモート管理は含まず)

  • Windows Virtualization

  • IIS 7.0 (ただし ASP.NET およびリモート管理は含まず)

  • IIS 7.0 (ただし ASP.NET およびリモート管理は含まず)

Server Core は以下のオプション機能をサポートしています :

  • バックアップ

  • Bitlocker ドライブ暗号化

  • フェールオーバー クラスタリング

  • マルチパス I/O

  • ネットワーク負荷分散

  • リムーバブル記憶域

  • 簡易ネットワーク管理プロトコル (SNMP)

  • UNIX ベース アプリケーション用サブシステム

  • Telnet クライアント

  • Windows インターネット ネーム サービス (WINS)

Server Core は、以下の方法でリモート管理できます :

  • Terminal Server with a command prompt shell

  • MMCs for supported components and Server Roles, e.g. Event Viewer and DNS

  • WS-Management using ShellExecute – Beta 2

Server Core は、UI をともなうようなアプリケーションのインストールはサポートしません。また、.NET 機能もサポートしません。ただし、対応した管理ツール、ユーティリティ、およびエージェントを開発することはサポートされます。

利点を最大限に活用できるように適切に実装するには、Server Core の制限事項を理解する必要があります。下位バージョンの Windows Server からServer Core へのアップグレード パスはありません。新規インストールのみがサポートされます。また、Server Core から GUI をともなう通常のサーバーへのアップグレード方法もありません。この場合、再インストールが必要です。

コマンドラインから Server Core が動作しているかどうか判別する方法 :

  • WMIC path win32_operatingsystem get OperatingSystemSKU /value

  • 12 Datacenter Server Core Edition

  • 13 Standard Server Core Edition

  • 14 Enterprise Server Core Edition Since Server Core is new, it has little impact on current applications.

その他のリソースへのリンク

Windows Server® 2008 の Windows Server フェールオーバー クラスタリング

機能の影響

概要

既存のクラスタ API の大部分は、Windows Server 2003 と同じままです。CreateCluster()、DestroyCluster()、AddClusterNode()、EvictClusterNode()、SetClusterQuorumResource()、および SetClusterResourceDependencyExpression() といった十数個の新しい API が追加されました。完全に削除された API は、BackupClusterDatabase() と RestoreClusterDatabase() です。そのため、クラスタ構成のバックアップやリストアを実行するには、新しいクラスタ VSS ライタを使用する必要があります。

クラスタ自動化サーバー (MSClus) COM インターフェイスは、廃止されました。そのため、MSClus からは新しい API は公開されません。MSClus は Windows Server® 2008 に存在していますが、将来のリリースでは削除される予定です。MSClus を使用したコードを新規に作成しないことが推奨されます。Windows Server® 2008 では、クラスタ API と MSCluster WMI プロバイダは完全に同じものです。

http://msdn2.microsoft.com/en-us/library/aa372876.aspx (英語)

ストレージ クラスのリソースを使用している場合に興味深い点として、CLUSCTL_RESOURCE_STORAGE_GET_DISK_INFO_EX と呼ばれる新しいコントロール コードが追加されました。

最後に、下位互換が損なわれています。これは、Windows Server® 2008 クラスタから下位レベルのクラスタ (NT4、Windows 2000、および Windows Server 2003) に対してクラスタ API を呼び出せないことを意味しています。またこれは同様に、下位レベルのクライアントから Windows Server® 2008 のノードに対して、クラスタ API をリモートで呼び出せないことを意味しています。ただし、この制限は Windows Server® 2008 で実行されるコードには影響しません。そのため、一般的には、コードは問題なく動作するはずです。

現象

BackupClusterDatabase() および RestoreClusterDatabase() を使用するアプリケーションは、Windows Server® 2008 クラスタ上では機能しません。

対処策

上述の API を使用するアプリケーションは、バックアップとリストア用に再設計し直す必要があります。

その他のリソースへのリンク

ネットワーキング: Windows Server® 2008 で既定で有効の Windows ファイアウォール

機能の影響

概要

Windows ファイアウォールは既定で有効です。つまり、アプリケーションのインストーラは、アプリケーションが使用するポートを認識し、ファイアウォールのポートが明示的に開かれるようにするか、または Windows ファイアウォールを無効にする (別のファイアウォールがインストールされている場合にのみ推奨) 必要があります。

Windows Server® 2008 では、サーバーの役割およびオプション コンポーネントはファイアウォールに対応しており、インストール時には自動的にファイアウォールの規則が調整されます。逆に、同じコンポーネントや役割をアンインストールするときには、ファイアウォールの規則が削除されます。

現象

レガシ アプリケーションのインストーラは、既定では依存する TCP/IP ポートが開いていないため機能しない可能性があります。

レガシ アプリケーションは、既定では依存する TCP/IP ポートが開いていないため、インストール後に機能しない可能性があります。Windows Vista では、クライアント アプリケーションはメッセージを表示して、アプリケーションを許可するか、ブロックするかをユーザーに確認します。Windows Server® 2008 では、既定ではこのような確認メッセージは表示されません。代わりに、アプリケーションがブロックされたことを示すセキュリティ監査イベントがログに記録されます。

対処策

レガシ アプリケーションのインストーラについては、管理者としてポートを明示的に開くか、Windows ファイアウォールを無効にする必要があります。

管理者は以下の方法を利用できます。

  • スクリプトからファイアウォールの規則を操作するための "netsh advfirewall" コンテキスト。

  • Windows Server の構成専用のセキュリティ構成ウィザードのテンプレート。

開発者は以下の方法を利用できます。

  • 高度なセキュリティを持つ Windows ファイアウォールにインストーラを統合するための INetFwPolicy2 ファイアウォール API。

その他のリソースへのリンク

表示: