トピックモジュールの内容このモジュールでは、4 段階パッチ管理プロセスの第 3 段階 "評価と計画" について説明します。評価と計画の段階では、更新プログラムを展開するかどうかの決定、展開に必要な条件の判定、運用同様の環境でのソフトウェア更新プログラムのテストを行って、ビジネスに不可欠なシステムとアプリケーションが損なわれないことを確認します。 このモジュールの目的は、パッチ管理プロセスの評価および計画段階の原則を説明し、Microsoft® Software Update Services (SUS) や Microsoft Systems Management Server (SMS) を使用して評価と計画を実行できるようにするタスクの種類を紹介することです。 評価と計画のプロセスを完了しないと、更新プログラムを展開するかどうかを決定するときに役立つ明確な基準セットが得られません。また、更新プログラムの展開に必要な条件を把握することも、信頼できるテスト済みのリリース ソフトウェアを作成するための手順を確立することもできません。 目的このモジュールの目的 | • | 更新プログラムの展開が実際に必要かどうかを判断する。 | | • | ソフトウェア更新プログラムのリリースを計画する。 | | • | リリースを作成する。 | | • | リリースの受け入れテストを実施する。 |
適用対象このモジュールは、すべての Microsoft 製品およびテクノロジに適用されます。 モジュールの使用方法このモジュールでは、SUS と SMS を使用して評価および計画を実行するのに必要な基本タスクについて説明します。詳細な手順については、方法が説明されている次の一連のモジュールを参照してください。 このモジュールから最大限の成果を得るには、以下を参照してください。 | • | 「パッチ管理のプロセス」を参照してください。このモジュールでは、4 段階パッチ管理プロセスの各段階の概要について説明しています。また、Microsoft Windows® オペレーティング システム環境のパッチ管理をサポートするために利用可能なツールの導入情報も提供しています。 | | • | 次のモジュールを参照してください。 |
概要評価と計画の段階は、図 1 で示されるパッチ管理プロセスの第 3 段階です。  図 1パッチ管理プロセス この第 3 段階では、ソフトウェア更新プログラムを評価して (展開用に承認されることが前提)、運用環境に展開できるよう計画します。 評価と計画の最初の段階は、運用環境に関連があるものとして識別されている、ソフトウェア更新プログラムに応じた変更の要求 (RFC) になります。 評価と計画の段階の終了までに、変更の要求を緊急として分類するかどうかを決定する必要があります。また、要求の確認と承認を行って、承認された変更を運用環境に展開するのに必要なタスクを判断する必要があります。運用環境に類似した環境でソフトウェア更新プログラムをテストして、ビジネスに不可欠なシステムおよびアプリケーションが損なわれないことを確認する必要もあります。 このモジュールでは、評価と計画に関する次の主な要件に注目します。 | • | 適切な対応策を決定する。 | | • | ソフトウェア更新プログラムのリリースを計画する。 | | • | リリースを作成する。 | | • | リリースの受け入れテストを実施する。 |
適切な対応策を決定するRFC では、ソフトウェア更新プログラムの展開や脆弱性を軽減する対策の適用 (またはその両方) など、運用環境に必要な変更の種類を決定して、他人も操作できるよう必要な変更点を記述します。 評価と計画の最初の手順では、RFC を確認して、ソフトウェアの脆弱性または脅威に最も適した対応策を決定します。次の決定を行います。 | • | 要求の優先順位付けと分類 | | • | ソフトウェア更新プログラムを展開するための承認の取得 |
ソフトウェア更新プログラムの要求の優先順位を付けて分類するソフトウェア更新プログラムの要求を承認する前に、その優先順位とカテゴリを決定する必要があります。優先順位とカテゴリは、変更開始者によって最初に割り当てられ RFC に含まれますが、これらの割り当ては変更要求の承認前に確認され、合意または変更される必要があります。 ソフトウェア更新プログラムの優先順位を付ける優先度は、ソフトウェア更新プログラムを変更プロセスに適用する速さを決定するので、特に重要です。次の考慮事項は、ソフトウェア更新プログラムの優先度を判断するときに役立ちます。 | • | 重要なビジネス資産は何か。これらのビジネス資産は、ソフトウェア更新プログラムがインストールされるまで、セキュリティ違反やシステムの不安定性などのリスクにさらされる可能性があるか高価値資産に更新プログラムを適用する/しない場合の影響に基づいて、変更要求の優先順位を決定する必要があります。 | | • | ソフトウェア更新プログラムは、基幹業務アプリケーションなど、過去に攻撃者の対象となっておりビジネスに不可欠なサービスを実行するシステムに適用されるか。これは、変更要求の優先順位を上げる有効な理由になる場合があります。 | | • | 特定のセキュリティ脆弱性の脅威を軽減する対応策は既に展開しているか。ここでは、変更要求の優先順位を下げられる可能性があります。ただし、それでも脆弱性をなくすソフトウェア更新プログラムを展開することをお勧めします。 | | • | 運用環境にとって問題となっている脆弱性の脅威とはどのようなものか。セキュリティ情報と関連するソフトウェア更新プログラムは、その多くが環境内の数台のコンピュータにのみ適用されます。脆弱性の脅威のレベルが低い場合は、要求の優先順位を下げられる可能性があります。 |
次の表は、要求の優先順位を他の要求との関連で評価するときに役立ちます。表 1 では、優先度を、推奨期限と最低限の推奨期限に関連付けます。 表 1: 更新プログラムの優先順位と推奨展開期限 緊急 | 24 時間以内 | 2 週間以内 | 高 (High) | 1 か月以内 | 2 か月以内 | 中 (Medium) | 可用性によって、この脆弱性の解決を含む、新しい Service Pack または更新プログラムのロールアップを、4 か月以内に展開。 | 6 か月以内に、ソフトウェア更新プログラムを展開。 | 注意 (Low) | 可用性によって、この脆弱性の解決を含む、新しい Service Pack または更新プログラムのロールアップを、1 年以内に展開。 | 1 年以内に、ソフトウェア更新プログラムを展開するか、まったく展開しないことも選択可能。 |
表 2 では、優先順位を上げ下げする要因の例を示します。 表 2: 更新プログラムの優先順位に影響する要因 高い価値または高い公開資産が影響を受ける。 | 上げる | 過去に攻撃者の対象となった資産。 | 上げる | 脅威を最小限にする対応策などの、軽減要因が適所にある。 | 下げる | 低い価値または低い公開資産が影響を受ける。 | 下げる |
緊急変更要求 セキュリティ更新プログラムで対処する脆弱性が既に悪用されているかまたは悪用されそうになっている場合、または運用環境で起こっているシステムの不安定性が更新プログラムによって修正される場合は、状況に応じて要求を "緊急" と分類し、運用環境内で行われるその他のすべての変更よりもこの要求の優先順位を上げる必要があります。 ソフトウェア更新プログラムの分類ソフトウェア更新プログラムのカテゴリは重要です。変更確認者が運用環境内のシステムとサービスへの影響を把握するのに役立つためです。変更要求のカテゴリ (または影響) を確立するには、次の点を判断する必要があります。 | • | ソフトウェア更新プログラムをインストールする必要があるコンピュータと、それらのコンピュータの役割 (ビジネスの重大度)
ビジネスに不可欠なコンピュータの再起動が必要なソフトウェア更新プログラムは、再起動を必要としないソフトウェア更新プログラムよりも、大きな影響を与えるでしょう。 | | • | ソフトウェア更新プログラムを展開するために必要な追加の変更の存在
たとえば、ソフトウェア更新プログラムを現在の Service Pack のみに適用する場合は、その Service Pack がある特定の運用システムにインストールされていないと、それらのシステムを特定のセキュリティ脆弱性から保護できない可能性があります。この場合は、Service Pack とソフトウェア更新プログラムの両方を展開する必要があるため、影響に応じて変更要求のカテゴリが大きくなります。 | | • | いったんインストールしたソフトウェア更新プログラムをアンインストールできる可能性
アンインストールできない場合は、アンインストールできるソフトウェア更新プログラムと比較して、運用環境に対するリスクが大きくなります。そのようなソフトウェア更新プログラムを展開して、特定のセキュリティ脆弱性から保護したり、特定のシステムの不安定性に対処したりすることが必要になる場合がありますが、要求のカテゴリにこの点を反映させる必要があります。 | | • | ネットワーク インフラストラクチャに影響する可能性
同時に多数のコンピュータを対象に大規模なソフトウェア更新プログラムを展開すると、ネットワーク パフォーマンスが低下し、環境全体の適切な運用に悪影響を及ぼす可能性があります。すべてのソフトウェア更新プログラムのドキュメントを詳しくレビューし、ソフトウェア更新プログラムの規模とソフトウェア更新プログラムを適用するコンピュータ数を把握しておく必要があります。この情報は、リリースのスケジュールを適切に設定する際に役立ちます。 | | • | インストール中に特定のサービスを停止したり、一時停止したり、閉じたりする必要性
この点は、組織の重要サービスに影響する場合があります。インストール中にエンド ユーザーがコンピュータを操作できなくなる場合もあります。 |
変更要求の優先順位およびカテゴリの設定については、http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/default.mspx (英語) で「Service Management Functions」の情報を参照してください。 ソフトウェア更新プログラムを展開するための承認を取得する変更要求を優先順位付けして分類した後は、ソフトウェア更新プログラムを運用環境に展開する前に、変更要求を確認して承認する必要があります。変更要求を承認するには、次の手順を実行する必要があります。 | • | 意思決定プロセスに関与する者を決定する。 | | • | 変更要求を確認し、ソフトウェア更新プログラムを展開した場合のリスクと結果を評価して、最適なアクションの方向性を選択する。 | | • | 影響を受けるすべてのシステムにソフトウェア更新プログラムを展開する担当者を識別する。 |
関与者を決定するソフトウェア更新プログラムを運用環境に展開するには、その確認と承認に関与する者を決定することが重要です。緊急以外の更新プログラムの場合は、影響を受けるビジネスの全領域の代表者で構成された変更諮問機関 (CAB) が確認と承認を行います。 CAB メンバには、更新プログラムの展開に使用される特定のテクノロジとサービスの経験者を含める必要があります。ビジネス、ネットワーク、セキュリティ、サービス デスク、テクニカル サポートのチーム代表もこのグループに含める必要があります。 CAB とその構成方法の詳細については、http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/default.mspx (英語) を参照してください。 緊急変更要求 セキュリティ脆弱性の解消や重大なシステム障害の防止に目的が置かれた、非常に重要な要求についてすぐに決定する必要がある場合は、CAB 緊急委員会 (CAB/EC) が承認を行います。 CAB/EC は、緊急な変更を承認する権限を持っていて、迅速な決定を行える要員で構成する必要があります。CAB/EC の詳細については、次のサイトの情報を参照してください (英語)。http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/default.mspx 変更要求を確認する適任者を集めた後は、運用環境に対するソフトウェア更新プログラムのリスクと影響を評価して、展開するかどうかを決定する必要があります。この決定を行うには、次の点を検討する必要があります。 | • | 運用環境で何が発生するか。 | | • | ソフトウェア更新プログラムを適用する場合としない場合の影響は何か。 | | • | ソフトウェア更新プログラムを展開する場合としない場合に予想されるコストはどのくらいか。 | | • | ソフトウェア更新プログラムの展開時に、セキュリティ脆弱性またはシステムの不安定性の脅威を軽減するために適用できる手順は何か。 | | • | コンピュータのダウンタイムの影響は何か。ソフトウェア更新プログラムの展開を延期することのリスクと、環境へソフトウェア更新プログラムを展開した結果コンピュータのダウンタイムが生じることのリスクを比較検討する必要があります。 | | • | ソフトウェア更新プログラムを展開する最良で最も効果的なメカニズムは何か。 | | • | ソフトウェア更新プログラムに伴う既知の問題や悪影響は存在するか。また、システムを再起動する必要性はあるか。 | | • | ソフトウェア更新プログラムを展開したり、展開中の数々の問題に対処したりするためのリソースは十分に確保されているか。 | | • | ソフトウェア更新プログラムを展開する前に解決する必要がある依存関係や前提条件に対して、どう対処するか。 |
ソフトウェアの脆弱性に対する最良の対応策は、ソフトウェア更新プログラムを展開して問題を解決することです。しかし、運用環境内のシステムにソフトウェア更新プログラムをロール アウトするときに、ネットワーク ポートのクローズやシステムへの外部アクセスのシャット ダウンなど、短期の対応策を適用することが望ましい場合があります。このような対応策を適用することは、以下の利点があります。 | • | ほとんどのソフトウェア更新プログラムでは、インストールを完了してコンピュータを保護するには、インストール後に対象のコンピュータを再起動する必要があります。コンピュータの再起動が特定の保守期間に制限され、ソフトウェア更新プログラムをすぐに展開できない場合は、推奨する対応策を講じることにより、ソフトウェア更新プログラムを展開するまでコンピュータを効果的に保護できます。セキュリティ更新プログラムを展開して、自動で再起動しないようにできる場合もあります。この場合は、セキュリティ更新プログラムを通常の時間帯にインストールして、後で保守期間に適した時間にコンピュータを再起動できます。 | | • | 対応策は、リスクが小さく、ソフトウェア更新プログラム自体よりも短時間で適用できて、長時間のテストを必要としません。たとえば、ネットワーク ポートを無効化したり、特定のセキュリティ脆弱性にさらされるサービスやシステムをシャット ダウンしたりして、後からソフトウェア更新プログラムを適用した方がはるかに簡単な場合があります。 |
コンピュータを強化する対応策を実装すると、多くの場合、多数の一般的なセキュリティ脆弱性からコンピュータを保護できます。効果的にコンピュータを保護する代表的な対応策として、特定のネットワーク ポートをブロックする方法と、使用されていないサービスを無効にする方法の 2 つがあります。コンピュータを強化する対応策の詳細については、次のサイトを参照してください (英語)。http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=1b6acf93-147a-4481-9346-f93a4081eea8 注: 対応策を展開してセキュリティ脆弱性にさらされるリスクを軽減する場合でも、セキュリティ更新プログラムの展開スケジュールを確立する必要があります。
たとえば、システムに更新プログラムをまだ適用していない状態で、ワームやウイルスに感染したコンピュータをネットワークに導入すると、保護されていない全システムに感染が一気に広がる可能性があります。対応策を展開する場合は、ソフトウェアを更新する必要がなくなるのではなく、単に変更要求の優先順位が下がるだけです。 ソフトウェア更新プログラムの展開責任者を決定するソフトウェア更新プログラムを展開し、必要に応じて何らかの対応策を使用するという合意に達したら、これらの変更を確実に行う責任者を特定する必要があります。この責任者は、以下の手順を実行する必要があります。 | • | 必要な変更を行うための計画を作成する。 | | • | 必須リソースを決定して取得する。 | | • | 変更を適用するのに必要なスクリプト、ツール、およびドキュメントの開発を手配する。 | | • | 十分なテストが確実に実施されるようにする。 | | • | 変更が運用環境に確実に展開されるようにする。 | | • | 展開の成功または失敗を評価する。 |
上記の活動を監督する責任者がいないと、ソフトウェア更新プログラムを展開できないリスクが残されます。通常、指定された責任者は、以下のサイトのリリース管理 SMF 情報 (英語) で説明されているリリース マネージャの役割を担います。http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/default.mspx リリースを計画するリリースの計画は、ソフトウェア更新プログラムを運用環境にどのようにリリースするかを策定するプロセスです。新しいソフトウェア更新プログラムのリリースを計画するときは、主に次の 3 つの段階を実行する必要があります。 | • | 更新プログラムを適用する必要がある対象を特定する。 | | • | 主要な問題と制約を識別する。 | | • | リリース計画を作成する。 |
更新プログラムの適用対象を特定する更新プログラムを適用する対象を判断するには、環境に展開されているものについての正確で最新の知識が必要になります。 SUS 環境では、管理者が Microsoft Baseline Security Analyzer (MBSA) を使用して再スキャンし、ソフトウェア更新プログラムが必要なシステムを確立する必要があります。SMS が展開されている場合は、インベントリ ツールとクライアント エージェントによって取得された情報を使用して、更新プログラムをインストールする必要があるコンピュータを判定できます。 これらのツールの詳細については、「[HOWTO] SUS を使用したパッチ管理の実行」と「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 主要な問題と制約を識別するさまざまな問題や制約の存在によって、ソフトウェア更新プログラムを運用環境に完全に展開する手順が決まる場合があります。たとえば、ソフトウェア更新プログラムを展開するタスクでは、以下の点を考慮する必要があります。 | • | ソフトウェア更新プログラムが自動でインストールされるまで、ユーザーに与えられる時間はどのくらい必要でしょうか。許可できる時間は、ユーザーの役割と担当範囲、ソフトウェア更新プログラムで対処するシステムの不安定性やセキュリティ脆弱性の特徴など、さまざまな要素によって決まります。
図 2 は、ソフトウェア更新プログラムを展開する期限 (サービス レベル契約 [SLA]) の例を示しています。ビジネスに不可欠なものとは見なされない、更新プログラムのサーバーへの適用は、ソフトウェア更新プログラム (ビジネスに不可欠なものとは見なされないもの) の到着後7 日以内に行う必要があることを示しています。管理者は、7 日間の期間内に更新プログラムの適用を開始する許可を与えられますが、期限が切れると、コンピュータで更新プログラムが強制的に適用されたり、コンピュータがネットワークから切断されたりすることに注意する必要があります。  図 2 サーバー向けの更新プログラム展開 SLA の例
拡大表示する 同じような準拠期限を環境内のワークステーションに適用できますが、応答時間とアクションは異なります。 | | • | ソフトウェア更新プログラムでは、インストール先のコンピュータ上で管理権限が必要になる場合があります。ほとんどのエンド ユーザーはローカル管理者権限を与えられていません。このため、ソフトウェア更新プログラムのインストールに使用されるツールでは、上位の権利および権限を取得して、ソフトウェア更新プログラムをクライアント コンピュータにインストールできるようにする必要があります。 | | • | ソフトウェア更新プログラムで、ある一定のディスク容量がインストール時に必要な場合、またはインストール前にソフトウェア更新プログラムがローカルにキャッシュされる場合は、それぞれのクライアント コンピュータ上のディスク空き容量をチェックする必要があります。 | | • | ソフトウェア更新プログラムのサイズが大きい場合 (たとえば数メガバイト) は、モバイル クライアントでダウンロードするのに時間がかかることがあります。ソフトウェア更新プログラムが緊急と分類されていない場合は、クライアントが物理的にネットワークに接続されるまで、それらのクライアント上でのインストールを延期した方が効果的な場合があります。 | | • | ビジネスに不可欠なコンピュータは、変更とコンピュータの起動に使用できる時間 (停止期間) が限られていることがあります。ソフトウェア更新プログラムの展開と、展開後に必要になるシステム再起動は、これらの停止期間内にスケジュールする必要があります。 | | • | 特定のグループ ポリシー設定によりクライアント コンピュータがロック ダウンされていると、ソフトウェア更新プログラムを正しくインストールできない場合があります。 | | • | 更新プログラムを適用する製品が Windows Installer を使って展開されている場合は、Windows Installer で元のインストール ファイルへのアクセスが必要になることがあります。ソフトウェア更新プログラムの無人インストールを実行する場合は、これらのファイルが、製品が当初にインストールされたときと同じ場所にある必要があります。製品が当初 CD ドライブなどの物理メディアからインストールされた場合、Windows Installer はドライブに挿入されている CD 内に元のファイルがないか検索を試みます。 | | • | たとえば Microsoft Office 製品の元のインストールに管理イメージが使用された場合は、直接クライアントにではなく、イメージに対してソフトウェア更新プログラムの管理インストールを実行する必要があります。管理イメージに更新プログラムを適用する場合の問題の詳細については、http://www.microsoft.com/technet/archive/sms/sms2/proddocs/smsoffxp.mspx (英語) を参照してください。 | | • | コンピュータを単位として（そのコンピュータの全ユーザーが使えるように）ではなく、ユーザーを単位としてインストールされたアプリケーションが存在する場合は、アプリケーションをコンピュータ単位でインストールし直してから、ソフトウェア更新プログラムを新規インストールに適用する必要があります。 |
SUS を使用していて、停止期間外に展開が実行されないようにする場合は、グループ ポリシー オブジェクト (GPO) を使って、更新プログラムがダウンロード後にインストールされないように指定する必要があります。更新プログラムがダウンロードされたことがわかったら、ビジネスに不可欠な各サーバーにログオンして、有効な停止期間内にインストールを開始する必要があります。ワークステーションの場合も、予定されていたインストールに失敗したコンピュータ (クライアント コンピュータがオフになっていた場合など) で、起動にともない自動更新サービスが開始されるときに自動でインストールを再スケジュールするようにする GPO 設定があります。評価と計画での SUS の使用法の詳細については、モジュール「[HOWTO] SUS を使用したパッチ管理の実行」を参照してください。また、SMS を使用して展開をスケジュールする方法については、モジュール「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 緊急変更要求 ソフトウェア更新プログラムが緊急であることを示す変更要求がある場合は、以下の点を考慮します。 | • | 通常よりも著しく短い時間内にソフトウェア更新プログラムを展開する必要が生じる場合があります。たとえば、完全展開を、変更要求の承認後 24 時間以内に行う必要があります。
図 3 では、ソフトウェア更新プログラムの展開期限が含まれる SLA を示します。期限は、重要なソフトウェア更新プログラムの通知が到着した後 8 時間以内に更新プログラムを全サーバーに適用する必要性を示しています。 上の例で、組織はソフトウェア更新プログラムを認識してから 2 時間以内に (図では 12:00までに)、ビジネスに不可欠なサーバーへの更新プログラムの適用を開始して、全サーバーの 98 パーセントを 18:00 までに完了する必要があります。残りのサーバーは 22:00 までに完了する必要があります。この時刻を過ぎるとネットワークから切断されるリスクが生じます。同じような準拠期限を環境内のワークステーションに適用できますが、対応の期間と速度は組織によって異なる場合があります。 | | • | ビジネスに不可欠な特定システムへの更新プログラム適用または再起動のタイミングを決定する停止期間は、合意した期日内にソフトウェア更新プログラムを展開できるようオーバーライドする必要があります。 | | • | ソフトウェア更新プログラムは、ネットワークへの接続とは無関係に、影響を受けるすべてのシステムに適用する必要があります。 |
SUS を使用する場合は、グループ ポリシーを使用して、定期スケジュールされた保守期間の前に、クライアントで強制的にソフトウェア更新プログラムをインストールできます。その前に、通常はネットワークが混雑していない時間帯に更新プログラムを同期するようスケジュールされる子 SUS サーバー上で、必ずレプリケーションを強制的に行う必要があります。この操作を実行するには、SUS サーバー管理ページで [今すぐ同期] オプションを使用します。評価と計画の段階で SUS を使用する方法の詳細については、「[HOWTO] SUS を使用したパッチ管理の実行」を参照してください。 SMS 環境では、高優先度パッケージ/提供情報トランザクションを一日中レプリケートできるように、SMS サイト間送信者を構成する必要があります。高優先度設定は、ソフトウェア更新プログラム パッケージと提供情報のみに使用することが重要です。評価と計画の段階で SMS を使用する方法の詳細については、「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 リリース計画を作成するこの時点で、運用環境内のコンピュータでソフトウェア更新プログラムを展開する順序を計画し決定する必要があります。リリース計画を作成するときに考慮の必要が生じる可能性のある問題を以下に示します。 | • | 運用環境内のすべてのサーバーにソフトウェア更新プログラムを適用する場合、最初に SMS、SUS または監視ツールを実行しているサーバーから更新プログラムを適用する必要があるか。
最初に管理インフラストラクチャに更新プログラムを適用すると、管理者はこれらのサービスを使用して展開の進捗を監視できるようになります。 | | • | 運用環境の一部に対して先に更新プログラムを適用するビジネス上の理由はあるか。
ソフトウェア更新プログラムを、セキュリティ脆弱性または潜在的なシステムの不安定性のリスクがあるコンピュータに適用する強固な理由が考えられます。このようなコンピュータに更新プログラムを適用すると、他の場所でロールアウトを続行できます。 | | • | サイト間の使用可能ネットワーク帯域幅がロールアウトの順序にどのような影響を与えるか。
サイトによっては、ネットワーク帯域幅の制約により、ソフトウェア更新プログラムを他のサイトのように迅速にロールアウトできない場合があります。ネットワーク接続が良好なサイトには、ネットワーク可用性が限られているサイトよりも速くソフトウェア更新プログラムを展開できます。 |
最後に、ソフトウェア更新プログラム、その重大度、影響、展開する手順に関する情報を、いつどのようにしてユーザー、ビジネスおよびサービス デスクに伝えるかを決定する必要があります。 緊急変更要求 変更要求が緊急の場合は、以下の点を考慮する必要があります。 | • | Microsoft Operations Manager (MOM)、SUS、SMS 2003 サイト サーバーなどの管理アーキテクチャ コンポーネントにも更新プログラムを適用する必要がある場合は、ローカル管理者が手動でこれらのコンピュータに更新プログラムを適用して、運用環境内の他のコンピュータにソフトウェア更新プログラムがロールアウトされている間はこれらのサーバーが再起動されないように計画した方が適切な場合があります。 | | • | 既に 1 つのサイトまたはコンピュータ グループが、ソフトウェア更新プログラムの対象になるセキュリティ侵害やシステムの不安定性の悪影響を受けている場合は、最初にそれらのコンピュータにソフトウェア更新プログラムを適用する必要があります。 |
リリースを作成するリリース計画を確立した後は、プロセスの次の段階として、ソフトウェア更新プログラムを運用環境に展開するときに管理者が使用するスクリプト、ツールおよび手順を開発します。ここで実行する必要があるタスクと作業は、主に、SMS 2003 または SUS を使用してソフトウェア更新プログラムを展開できるかどうかによって決定されます。 SUS を使用する場合は、更新プログラムが直接パブリック Windows Update サーバーからダウンロードされ、しかも既に実行可能ファイル (.exe) 形式にパッケージされているため、追加作業を実行して展開用に再パッケージする必要はありません。評価と計画の段階で SUS を使用する方法の詳細については、「[HOWTO] SUS を使用したパッチ管理の実行」を参照してください。 SMS を使用する場合は、SMS 2003 ソフトウェア更新の配布ウィザードで更新プログラムを展開すると、最も簡単にリリースを作成できます。このウィザードでは、SMS パッケージのほかに、ソフトウェア更新プログラムの配布およびインストールに必要なプログラムを自動的に作成できます。特定の製品と Service Pack の組み合わせに適用するすべてのセキュリティ更新プログラムを、セキュリティ ロールアップ パッケージにまとめて管理を簡略化し、再起動が必要なコンピュータの数を大幅に減らすことができます。SMS 2003 ソフトウェア更新の配布ウィザードを使用して展開できない更新プログラムの場合は、標準の SMS ソフトウェア配布手順を使用してパッケージと提供情報を作成し、クライアント コンピュータ上で実行されるバッチ ファイル、Microsoft Installer (MSI) ファイル、または実行可能ファイルを指定する必要があります。更新プログラムがセットアップ実行可能ファイルと一緒に提供されない場合は、MSI オーサリング ツールを使用して実行可能ファイルを作成する必要もあります。評価と計画の段階で SMS を使用する方法の詳細については、「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 受け入れテストこの時点までのテストの目的は、開発環境内でのソフトウェア更新プログラムおよびリリース パッケージの正常な動作を確認することでした。 受け入れテストを実施すると、開発者とビジネス代表者は、運用環境を忠実にミラー化する環境で更新プログラムが機能すること、さらにはソフトウェア更新プログラムが展開された後もビジネスに不可欠なシステムが稼働することを確認できます。管理者およびビジネス代表者は、ソフトウェア更新プログラムがビジネスに不可欠と見なされるときに実行する一連のテストと、ソフトウェア更新プログラムの優先順位が低い場合に使用できる詳細なテスト セットを作成する必要があります。 ただし、ソフトウェア更新プログラムの重要度がどのようなものであっても、次のことがわかる最低レベルのテストを常に実行する必要があります。 | • | インストールが完了すると、予期したとおりにコンピュータが再起動される。 | | • | ソフトウェア更新プログラムは、低速または信頼度の低いネットワーク接続を使用するコンピュータが対象になる場合に、これらのリンクを通じてダウンロードでき、ダウンロードが完了した時点で正しくインストールされる。 | | • | ソフトウェア更新プログラムと共に、ソフトウェア更新プログラムを正しく削除するために使用できるアンインストール ルーチンが提供される。 | | • | ビジネスに不可欠なシステムとサービスは、ソフトウェア更新プログラムがインストールされた後も稼働し続ける。 |
ソフトウェア更新プログラムを展開する前に、テスト中に使用されたトラブルシューティング手順、操作、ツールについて情報を収集し、これらをサービス デスク サポート スタッフおよび運用チームが利用できるようにしておくことが重要です。 テストの結果、以下のものが作成されることが予想されます。 | • | 標準的なトラブルシューティングの手順と、関連する回避策を記述した社内知識ベース | | • | 連絡先およびエスカレーション パスの一覧 | | • | 運用担当者が効果的に運用環境でのリリースを監視できるようにする、スクリプト、規則および情報 (カウンタ、イベント、しきい値など) |
テストをどれだけ実行しても、ソフトウェア更新プログラムを運用環境にロールアウトすると、多くの場合実験環境で予期したり再現したりできない結果が生じます。起こり得る障害の影響が多くのクライアント コンピュータに及ばないようにするため、管理者は、組織全体への展開を実行する前に、ソフトウェア更新プログラムを限られた範囲の代表的コンピュータ グループにロールアウトし、ビジネスに不可欠なシステムとアプリケーションが稼働し続ける確認を行うことを検討してください。 要約評価と計画の段階で留意の必要がある主要なポイントを以下に示します。 | • | ソフトウェア更新プログラムを展開することがビジネスにとって最良の対策かどうかを判断するには、正式のプロセスを必要とします。 | | • | ソフトウェア更新プログラムを確実に展開するための責任者を決定する必要があります。 | | • | ソフトウェア更新プログラムの承認後に、その運用環境への展開方法について計画する必要があります。 | | • | パッケージを実験環境でテストし、必要に応じて運用環境でパイロット テストを実施し、LOB アプリケーションが損なわれないことを確認する必要があります。 |
展開段階に移行するパッチ管理プロセスの展開段階に移行するきっかけとなるのは、以下の条件です。 | • | パッケージを運用環境に展開する準備が整っている。 | | • | ソフトウェア更新プログラムを運用環境に展開することが承認されている。 |
展開段階の詳細については、「パッチ管理フェーズ 4 - 展開」を参照してください。
| 
