トピックモジュールの内容このモジュールでは、4 段階のパッチ管理プロセスの第 4 段階 "展開" について説明します。展開段階では、確立されている展開サービス レベル 契約 (SLA) のすべての要件を満たせるように、承認済みのソフトウェア更新プログラムを運用環境に正しくロールアウトすることが重要になります。 このモジュールの目的は、パッチ管理プロセスの展開段階の原則を説明し、Microsoft® Software Update Services (SUS) および Microsoft Systems Management Server (SMS) を使用して展開を実行できるようにするためのタスクの種類を紹介することです。 このモジュールを参照すると、以下を正しく実行するのに必要なタスクを計画できるようになります。 | • | 承認済みのソフトウェア更新プログラムをロールアウトする。 | | • | 必要な対応策を展開する。 |
展開プロセスを完了しないと、ソフトウェア更新プログラムを運用環境に展開するのに必要な、試行と試験済みのタスクと作業が明らかになりません。また、必要な対応策や軽減手順を展開できません。 目的このモジュールの目的 | • | 展開の準備をする。 | | • | ソフトウェア更新プログラムを対象のコンピュータに展開する。 | | • | 展開の実装後レビューを実行する。 |
適用対象このモジュールは、すべての Microsoft 製品およびテクノロジに適用されます。 モジュールの使用方法このモジュールでは、SUS と SMS を使用して評価を実行するのに必要な基本タスクについて説明します。詳細な手順については、方法が説明されている次の一連のモジュールを参照してください。 このモジュールを最大限に活用するには、次の手順を実行する必要があります。 | • | 「パッチ管理のプロセス」を参照してください。このモジュールでは、4 段階パッチ管理プロセスの各段階の概要について説明しています。また、Microsoft Windows® オペレーティング システム環境でパッチ管理のサポートに使用できるツールの導入情報も提供しています。 | | • | 次のモジュールを参照してください。 |
概要展開段階は、図 1 で示されるパッチ管理プロセスの第 4 段階です。  図 1パッチ管理プロセス 展開段階では、ソフトウェア更新プログラムを運用環境に展開するのに必要なタスクと作業に重点が置かれます。対応策や軽減手順を展開するには、追加のタスクが必要になる場合があります。 この段階へ進むきっかけとなるのは、ソフトウェア更新プログラムを運用環境に展開する準備が整っていることと、ソフトウェア更新プログラムを展開するための承認が得られていることについての判断です。 展開段階での目標は、承認済みのソフトウェア更新プログラムまたは対応策 (またはその両方) を運用環境に正しくロールアウトすることです。 ソフトウェア更新プログラムの展開は、次の作業で構成されます。 | • | 展開の準備 | | • | 対象のコンピュータに対するソフトウェア更新プログラムの展開 | | • | 実装後のレビュー |
展開を準備する新しいリリースごとに、運用環境を準備する必要があります。ソフトウェア更新プログラムを展開できるようにするには、次の手順が必須となります。 | • | 組織全体へのロールアウト スケジュールの伝達 | | • | SUS が展開される場合 | | • | SMS が展開される場合 | • | テスト環境からのプログラムと提供情報のインポート | | • | 配布ポイントの割り当て | | • | 配布ポイント上での更新の準備 | | • | 展開グループの選択 |
|
SUS 環境での展開の準備については、「[HOWTO] SUS を使用したパッチ管理の実行」と「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 組織全体にロールアウト スケジュールを伝達する差し迫った更新プログラムのリリースについて、エンド ユーザーと管理者に通知することが重要です。明確で確認しやすい電子メール メッセージをユーザーと管理者に送信する必要があります。いずれの場合も、更新プログラムとそのインストール方法について通知します。このメールには、ユーザーや管理者に必要なアクションを通知するために "ご協力お願いします" というフラグを付ける必要があります。 営業時間外にデスクトップに更新プログラムを展開する場合、電子メール メッセージでは、指定された日にユーザーが夜間コンピュータの電源をオンにしたままにする必要があることを示します。図 2 に示すように、このメッセージに "ご協力お願いします" のフラグが付けられている場合、ユーザーは、2003 年 5 月 30 日の午後 4 時 30 分に夜間コンピュータの電源をオンにしたままにするようリマインダを受け取ることになります。  図 2 このスクリーン ショットは、"ご協力お願いします" のフラグが付いた電子メールをどのようにリマインダとして使用できるかを示しています。 SUS を使用する場合は、SUS クライアントのダウンロードおよびインストール ポリシー設定に応じて、次のように伝達プロセスに追加して考慮すべき事項が含まれます。 | • | ダウンロードの通知とインストールの通知 - ローカル管理者権限を使用してログオンしたユーザーは、新しい更新プログラムがダウンロードできるという旨の通知がタスク バーに表示されている場合、更新プログラムをダウンロードするオプションを必ず選択する必要があります。さらに、インストールを完了するには、新しい更新プログラムがインストールできるという旨の通知が表示されたときに、ソフトウェア更新プログラムをインストールする必要があります。 | | • | 自動ダウンロードとインストールの通知 - クライアント コンピュータに適用する承認済みの新しい更新プログラムは、自動更新クライアントによって自動的にダウンロードされます。更新プログラムをインストールする場合、ローカル管理者権限を使用してログオンしたユーザーは、新しいソフトウェア更新プログラムがインストールできるという旨の通知が表示されたとき、ソフトウェア更新プログラムをインストールするオプションを選択する必要があります。 | | • | 自動ダウンロードとインストールのスケジュール設定 - ローカル管理者権限を使用してログオンしたユーザーは、予定されたインストール時刻より前に更新プログラムをインストールしたり、インストール完了後必要に応じて再起動を延期したりすることができます。ローカル管理者権限のないユーザーの場合、更新プログラムは予定された時刻にバックグラウンドでインストールされます。これらのユーザーがコンピュータの再起動を延期できるのは、[自動更新のインストールで、システムを自動的に再起動しない] ポリシー設定が有効になっている場合のみです。 |
展開段階で SUS を使用する方法の詳細については、「[HOWTO] SUS を使用したパッチ管理の実行」を参照してください。 SMS を使う展開を準備するSMS 2003 を使用する場合は、展開の準備を整えるために次の手順を追加して考慮する必要があります。 | • | テスト環境からのプログラムと提供情報のインポート - 最初に、テスト環境で作成およびテストしたパッケージを、SMS 2003 運用環境にインポートする必要があります。 | | • | 配布ポイントの割り当て - 次に、配布ポイントを割り当てる必要があります。つまり、ソフトウェア更新プログラムのバイナリ ファイルは、対象のクライアントがあるすべてのサイトの配布ポイントに配置する必要があります。ソフトウェア更新の配布ウィザードを使用できる場合は、そのウィザードを使用して配布ポイントを割り当てることができます (パッケージが作成されたら手動で変更します)。 | | • | 配布ポイント上での更新の準備 - 次の手順として、すべてのファイルのコピーが配布ポイント サーバーに用意されるようにします。ソフトウェア更新プログラムのバイナリ ファイルを配布ポイントに送信するプロセスでは、SMS サイト間でファイルを送信すると共に、SMS サイトからローカル配布ポイントへの送信を行います。 | | • | 展開グループの選択 - ソフトウェア更新の配布ウィザードを使用して新しいソフトウェア更新プログラムを配布する場合は、対象のコンピュータを正確に指定する必要はありません。これは、ウィザードによってスマート エージェントが展開され、新しいソフトウェア更新プログラムをインストールする必要が生じたときにこのエージェントが起動されるためです。このエージェントによって、更新プログラムがそのコンピュータに適用可能かどうか (そして既にインストールされているかどうか) が自動的に判断されます。更新プログラムがカスタム パッケージとコレクションを使用して配布される場合は、更新プログラムを適切なコンピュータに展開する目的で SMS クエリを 1 つまたは複数作成する必要が生じることがあります。 |
展開段階で SMS を使用する方法の詳細については、「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 対象のコンピュータにソフトウェア更新プログラムを展開するソフトウェア更新プログラムを運用環境に展開するときに使用するプロセスは、リリースの種類と性質、および選択したリリース メカニズムによって決定されます。 また、ソフトウェア更新プログラムが緊急のものとして分類されるどうかによっても大きく左右されます。緊急の変更は緊急性に関連しているため、変更の展開方法に違いがあります。それらの違いは、このセクション全体で強調されています。 段階的な展開によってソフトウェア更新プログラムをリリースすることが理想的です。この方法では、ソフトウェア更新プログラムの初期配布によって生じる可能性のある障害や逆効果の影響を最小限に抑えることができます。 ソフトウェア更新プログラムを運用環境に展開するには、次の手順が必須となります。 | • | クライアント コンピュータにソフトウェア更新プログラムを提供する。 | | • | 展開の進捗について監視してレポートする。 | | • | 失敗した展開を処理する。 |
クライアント コンピュータにソフトウェア更新プログラムを提供するSUS を使用する場合は、段階的なロールアウトは必要ありません。単に SUS 親サーバー上で更新プログラムを承認して、クライアントで利用できるようにするだけです。SUS クライアントは、次の検出サイクルで、またはローカル管理者によって指示されたときに、新しく承認された更新プログラムのダウンロードを開始します (新しい更新プログラムが利用可能になった時点でローカル管理者に通知されるよう自動更新クライアントが構成されている場合)。 ただし、段階的なロールアウトを行う場合は、最初に親 SUS サーバー上のみで更新プログラムを承認する必要があります。親サーバーがサポートするクライアントへの更新プログラムの展開が正常に完了した後で、公開の次の段階でクライアントをサポートする SUS 子サーバーにある許可リストの同期を有効にする必要があります。 展開段階で SUS を使用する方法の詳細については、「[HOWTO] SUS を使用したパッチ管理の実行」を参照してください。 SMS が展開されているときは、ソフトウェア更新の配布ウィザードを使用すると、繰り返し提供情報が自動的に作成され、対象のコレクション内のコンピュータ上でソフトウェア更新プログラム インストール エージェントが実行されます。必要に応じて、繰り返し間隔を既定値の 7 日から変更できます。たとえば、サーバーが含まれているコレクションでは、エージェントを 1 日 1 回実行できます。異なる種類のコンピュータ用に異なるスケジュールを作成する必要がある場合は、同じパッケージとプログラムを使用して、複数のコレクションに使用する提供情報を作成できます。ロールアウトを段階的に実行する場合は、それぞれの段階の後にクエリを変更して、次の段階のクライアントが含まれるようにします。 ソフトウェア更新の配布ウィザードを使用しない場合は、更新プログラムをインストールするように提供情報をセットアップするときに、一定間隔で繰り返されるようにそのスケジュールを構成する必要があります。これにより、インストールが失敗した場合は、自動的に再試行されます。既に更新プログラムを正しくインストールしたクライアントは、新しいインベントリが収集されるまで （インストール プログラム自体がきっかけになる場合がある）、またはインベントリが SMS データベースで更新されてコレクションが再評価されるまで、対象のコレクションに残ります。そのため、提供情報の繰り返し間隔は慎重に選択する必要があります。そのため、プログラムは一度正常に実行したクライアントで再実行できます。以上の理由により、実行プログラムは、最初にソフトウェア更新プログラムがインストールされていることを確認し、インストールされている場合はすぐに終了することが重要になります。 展開段階で SMS を使用する方法の詳細については、「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 緊急変更要求SUS を使用して緊急変更要求を管理する方法の詳細については、「[HOWTO] SUS を使用したパッチ管理の実行」を参照してください。また、SMS を使用して緊急変更要求を管理する方法については、「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 展開の進捗状況を監視してレポートするコンピュータでは、以下のような理由で更新プログラムのインストールに失敗する場合があります。 | • | コンピュータがオフラインになっている。 | | • | コンピュータが再構築中、または再イメージ化中である。 | | • | コンピュータに十分なディスク空き容量がない。 | | • | SUS 環境の場合: | • | コンピュータと SUS サーバーの通信が確立されていない (自動更新クライアントが設定されているコンピュータの場合)。 | | • | 自動更新クライアント サービスが停止されている。 |
| | • | SMS 環境の場合: | • | コンピュータの SMS クライアントと SMS サイト サーバーとの通信が確立されていない。 | | • | コンピュータ上で、ユーザーまたは保守の一環によってエージェント サービスが停止されている。 |
| | • | SMS 2003 環境の場合: | • | コンピュータの MSXML 3 が SP1 までとなっている (SMS 2003 では MSXML 3.0 SP4 が必要)。 |
|
SUS 環境で展開済みの更新プログラムが正しくリリースされていることを監視するには、Microsoft Baseline Security Analyzer (MBSA) を使用して複数のコンピュータをスキャンし、更新に失敗したという情報が MBSA レポートで表示されないことを確認する必要があります。展開段階で SMS を使用する方法の詳細については、「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 SMS で更新プログラムが正しくリリースされていることを監視するには、Advertisement Status Viewer を使用して、提供情報の展開ステータスをそのステータス メッセージに基づいて表示できます。ステータス メッセージでは、繰り返し提供情報が実行されたかどうかがレポートされるのみです。更新プログラムがインストールされているかどうかを確認することはできません。この情報を取得するには、ステータス メッセージを分析して、いつ更新プログラム インストール用プログラムがそれぞれのクライアントで最後に正しく実行されたかを判断する必要があります。プログラムが実行されてからの時間が、クライアントの繰り返し間隔よりも長い場合、調査する必要があります。 セキュリティ更新インベントリ ツールまたは Microsoft Office 更新インベントリ ツールを使用して識別されたソフトウェア更新プログラムの場合は、組み込みレポートを使用して、正しい展開のチェックを実行できます。Compliance by Software ID レポートを使用して、更新プログラムがインストールされたかインストールに失敗したシステムの総数の概要と、ソフトウェア更新プログラムの配布に関するステータスを確認できます。 識別段階で SMS を使用する方法の詳細については、「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 失敗した展開を処理する通常の展開中に例外が発生した場合は、展開を停止し、十分な時間をかけて根本的な原因を特定し、再展開する必要があります。ただし、緊急展開の実行中は、優先順位付けと根本原因の評価に、ごく短い時間しか割り当てられません。 実際の組織でも、展開に失敗したと判断され、停止とロールバックが必要になる可能性があります。公開を停止し、失敗した更新プログラムをアンインストールして、再展開するための計画を準備しておく必要があります。 SUS 環境の場合SUS 環境で展開に失敗した場合は、それ以上インストールが行われないよう、SUS サーバー上の更新プログラムの承認を取り消す必要があります。更新プログラムを既にダウンロードしているもののインストールが済んでいないクライアントでは、ローカル管理者は、インストールされる更新プログラムの一覧からその更新プログラムを手動で削除できます。承認済みの更新プログラムがコンピュータにインストールされている場合は、更新プログラムを削除する唯一の方法として、コントロール パネルの [プログラムの追加と削除] 機能を使用します (更新プログラムをアンインストールできる場合)。展開段階で SUS を使用する方法の詳細については、「[HOWTO] SUS を使用したパッチ管理の実行」を参照してください。 SMS 環境の場合SMS を使用している場合は、失敗した展開を処理するときに、次の 4 つのメイン タスクを実行します。 | • | 問題が解決されるまで、アクティブ パッケージの展開を停止する。 | | • | 問題を識別して解決する。つまり、なぜ展開に失敗したかを解明する。 | | • | パッケージを再提供する。 | | • | アンインストール パッケージを作成して、ソフトウェア更新プログラムをアンインストールする (更新プログラムをアンインストールできる場合)。 |
展開段階での SMS の使用法の詳細については、「[HOWTO] SMS を使用したパッチ管理の実行」を参照してください。 実装後のレビュー実装後のレビューは、通常、リリースを展開してから 1 週間から 4 週間以内に実行し、パッチ管理プロセスの改善点を調査する必要があります。 一般的な確認事項は以下のとおりです。 | • | 脆弱性を脆弱性スキャン レポートとセキュリティ ポリシーの標準に追加して、攻撃が再発する機会を提供しないようにする。 | | • | 構築したイメージを更新して、展開後の最新のソフトウェア更新プログラムが含まれるようにする。 | | • | 計画と実際の結果を比較検討する。 | | • | リリースに関連するリスクを検討する。 | | • | 緊急事態全体での組織のパフォーマンスをレビューする。この機会を利用して、対応計画を改善し、得られた教訓が含まれるようにします。 | | • | サービス期間の変更を検討する。 | | • | ダウンタイムのコストと復旧のコストの両方について、緊急事態の損傷とコストの合計を査定する。 | | • | 環境に合わせて別のベースラインを作成するか、既存のベースラインを更新する。 |
要約 展開段階では、以下の主な作業を完了する必要があります。 | • | ソフトウェア更新プログラムを運用環境にロールアウトする順序を確立する。 | | • | 運用環境を調査して、ソフトウェア更新プログラムを処理できることを確認する。 | | • | ソフトウェア更新プログラム ファイルを、SMS 配布ポイントまたは SUS サーバーに配置する。 | | • | ソフトウェア更新プログラムを運用環境に展開する。 | | • | 環境を再スキャンして、結果を査定し、ソフトウェア更新プログラムのインストールに失敗したコンピュータに更新プログラムを適用する。 | | • | 展開が完了したら、パッチ管理プロセスのレビューを実行する。 |
次の手順ソフトウェア更新プログラムを展開したら、査定段階に戻って、以下の手順を引き続き実行する必要があります。 | • | 既存のコンピューティング資産のインベントリ作成と発見を行う。 | | • | セキュリティの脅威と脆弱性を査定する。 | | • | ソフトウェア更新プログラムに関する情報の最適なソースを判断する。 | | • | 既存のソフトウェアの配布インフラストラクチャを査定する。 | | • | 運用の効果を査定する。 |
| 
