Microsoft Systems Management Server を使用した修正プログラム管理

[アーティクル]
07/12/2010

ソリューションガイド

トピック

はじめに
このガイドの要点
修正プログラムの展開
付録
寄稿者

はじめに

本書の目的

本書は、Microsoftｮ Systems Management Server (SMS) を使用して、ソフトウェア修正プログラム、Service Pack、および QFE (Quick Fix Engineering) 修正プログラムを展開するためのガイダンスを提供します。また、概念的な情報、ベストプラクティスのデザインと構成、および成功するために必要な運用事例の詳細も提供します。

対象読者

本書、社内担当メンバおよびコンサルタントの両者に役立ちます。本書は、情報技術 (IT) 実稼動環境に変更を導入またはサポートする IT マネージャと IT サポート担当者のメンバという 2 つの主要なグループを主な対象にしています。

読者は、Microsoft Operations Framework (MOF) プロセスモデル、チームモデル、およびリスクモデルに精通している必要があります。これらのモデルについて説明したドキュメントのコピーについては、https://www.microsoft.com/japan/systemcenter/default.mspx を参照してください。

読者は SMS の使用経験があり、https://www.microsoft.com/japan/smserver/ にある SMS Software Update Services Feature Pack ツールを含めて、SMS の管理者ガイドおよびその他の関連資料を一読している必要もあります。

このガイドの要点

修正プログラム管理は、運用効果と運用効率を維持し、セキュリティの脆弱性を解消し、実稼動環境の安定性を維持するために、IT 環境への臨時のソフトウェアリリースの展開と保守の管理を提供するプロセスです。

オペレーティングシステムやアプリケーションソフトウェアの既知のセキュリティレベルを判断および管理できない組織は危機に直面しています。このリスクを最小限に抑えるには、システムを適切に構成し、最新のソフトウェアを使用し、推奨される効果的な修正プログラムおよびセキュリティ修正プログラムをインストールする必要があります。

また、適切に定義された修正プログラム管理プログラムを利用して、ネットワーク環境におけるシステムソフトウェアの完全性を評価し、保守することも、システムへの物理的なアクセスの制御の種類にかかわらず、情報セキュリティを成功させるための重要な第一歩と言えます。

ただし、分散 IT 環境で修正プログラム管理を検討するときは、次のようないくつかの基本的な疑問が生じます。

必要な修正プログラムを識別できる方法は?
最新の修正プログラムを本当に適用する必要があるか?
ある特定の修正プログラムの大きな影響は何か?
修正プログラムによって何が変更されたか?
インストール後に修正プログラムを削除できるか?
異なる環境間の依存関係は何か?
修正プログラムが成功したかどうかを判断する方法は?
修正プログラムにより特定のカスタム設定が上書きされる場合はどうなるのか?
修正プログラムが適用された環境の復元シナリオとして可能なシナリオは?

本書は、修正プログラム管理のベストプラクティスを確実に実行できるようデザインされ、適切に定義されたプロセスを用いて上記の問題点に対処しています。

特定のベンダとは無関係に、開発環境や実稼働環境には可変要素が数多く存在するので、常に、修正プログラム管理が必要になります。そのため、修正プログラム管理は、無視することのできないきわめて重要な作業です。

包括的な修正プログラム管理戦略を実装できなかった場合は、組織の根幹に直接影響がある、重大な結果になる可能性があります。基幹業務の実稼動システムでの障害の発生や、セキュリティ上重要なシステムの悪意のある利用は、時間をロスし、ビジネスの収益を損なうことにつながります。

このソリューションガイドの目的は、Microsoft ツールやテクノロジの環境内で、人、プロセス、およびテクノロジの観点から、修正プログラム管理への包括的で、一貫したアプローチを提供することです。

修正プログラムの展開

修正プログラム管理プロセスの概要

図 1 のプロセスフローチャートには、IT インフラストラクチャに認可済みの修正プログラムを適切に計画および展開するために必要な作業が示されています。

図 1: 修正プログラム管理のプロセスフローチャート

図 1: 修正プログラム管理のプロセスフローチャート

Microsoft Operations Framework (MOF) プロセスモデルは、変更、サポート、最適化、運用という 4 つのエリアで構成されています。

修正プログラム管理プロセスは、MOF 変更エリア内に含まれるサービス管理機能 (SMF) に基づいています (変更管理 SMF、構成管理 SMF、およびリリース管理 SMF)。また、残りの 3 つの MOF プロセスモデルのエリアにも直接関係があります。

このように、このソリューションガイドは MOF SMF、特に MOF SMF の変更エリアにかなり依存しているので、この修正プログラム管理のソリューションガイドを使用する場合は、MOF SMF に精通している必要があります。

これらのサービス管理機能の詳細については、https://www.microsoft.com/solutions/msm/techinfo/default.asp (英語) を参照するか、https://www.microsoft.com/japan/technet/default.mspx の TechNet サイトでサービス管理機能のトピックを検索してください。

修正プログラム管理のための人とプロセス

MOF では、MOF チームモデルを使用した効果的な IT 運用について、運用者に注目したガイダンスを提供しています。このモデルは、さまざまな規模の成功した IT 運用組織に存在する一貫性のある品質目標に基づいたガイドラインを提供します。成功した IT 運用組織には、成長しつつある E ビジネスデータセンターやアプリケーションサービスプロバイダなど、大企業の IT 部門からより小規模なものまであります。

MOF チームモデルは、以下のことを説明します。

運用チームを構成するための役割群のベストプラクティス。
各役割群の主要な作業と能力。
組織の異なる規模や種類にチームをスケール変換する方法。
どの役割の兼任が適切に機能し、どれが機能しないか。
どのガイド原則を支持すると、Microsoft プラットフォーム上の分散コンピュータ処理環境の実行と運用に最も成功するか。

MOF チームモデルの詳細については、https://www.microsoft.com/japan/systemcenter/default.mspx を参照してください。

また、修正プログラムの展開を行う組織では、Microsoft Solutions Framework (MSF) のチームモデルおよびプロセスモデルで提供されるような、効果的な変更開発プロセスを利用する必要があります。 MSF の詳細については、https://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx (英語) を参照してください。

組織が運用環境で修正プログラムを効果的に管理および展開するための人、プロセス、およびツールが適切に存在するかどうか確信できない場合、運用アセスメントの実行を検討する必要があります。運用アセスメントの手配方法の詳細については、https://www.microsoft.com/japan/systemcenter/default.mspx を参照してください。

修正プログラム管理のツール

修正プログラム管理を行う組織では、管理者に更新を通知し、管理者がインストールを管理および制御できるようにする自動化されたツールを使用する必要があります。中規模および大規模な組織で修正プログラム管理をサポートする場合は、次のツールを使用します。

Systems Management Server

Microsoft Systems Management Server (SMS) は、中規模から大規模の組織内で更新や QFE (Quick Fix Engineering ) 修正プログラムの配布を展開および管理する際に好んで使用されるメカニズムです。 SMS には、展開を成功させる上で重要な次のような機能が用意されています。

展開されているコンピュータの台数、その場所、役割およびそれらのコンピュータにインストールされているソフトウェアアプリケーションと修正プログラムを判断するためのインベントリ機能。
組織が通常の勤務時間外、またはビジネス運用への影響が最も少ない時間帯に、更新および QFE 修正プログラムを展開するスケジュールを設定できるスケジューリング機能。
管理者がインストールの進捗状況を監視できるステータスレポート機能。
システムインベントリに基づいて、Microsoft Active Directoryｮディレクトリサービス、または手動で作成したグループで対象のコンピュータを示す対象設定機能。
ネットワーク経由で、簡単かつ効果的にファイルを移動できるようにするエンタープライズレプリケーション。
Microsoft Windowsｮ 2000、Windows Server・2003、および Windows XP 以外のオペレーティングシステムのサポート。

SMS の詳細については、https://www.microsoft.com/japan/smserver/default.asp を参照してください。

SMS Software Update Services Feature Pack

Systems Management Server Software Update Services Feature Pack は、以下のツールのセットを提供します。

セキュリティ更新インベントリツール
Microsoft Office 更新インベントリツール
ソフトウェア更新の配布ウィザード
ソフトウェア更新の Web レポートアドインを使用する Web レポートツール

これらのツールは、各ツールの機能を Systems Management Server のインベントリ機能とソフトウェア配布機能に統合して、セキュリティの更新や Office ソフトウェアの更新の展開に、単純化され、ほぼ自動化されたアプローチを提供します。詳細については、https://www.microsoft.com/japan/smserver/evaluation/overview/featurepacks/default.mspx を参照してください。

修正プログラム管理のセットアップ

企業組織に修正プログラム管理を適切に実装するには、ベースラインの設定および購読という 2 つの重要なセットアップ作業が必要になります。

ベースラインの設定

ベースラインは、特定の時点で確立される製品やシステムの構成です。たとえば、アプリケーションやソフトウェアのベースラインは、コンピュータを特定の状態に再構築する機能を提供します。ソフトウェアアプリケーション、ハードウェアベンダ、またはコンピュータの種類ごとにベースラインを設定する必要がある場合もあります。たとえば、Windows 2000 を実行する Compaq サーバーに定義されるベースラインは、Dell サーバーに定義されるベースラインと異なる可能性があります。

図 2 に、ベースライン設定のプロセスフローチャートを示します。

図 2: ベースライン監査を実行するためのプロセスフローチャート

図 2: ベースライン監査を実行するためのプロセスフローチャート

以下のセクションでは、図 2 のベースラインの設定フローチャートで示した各プロセスを説明します。

適切な Microsoft 監査ツールおよびベースラインツールの識別

IT 状態の監査には、監査自体または収集されたデータの照合のいずれかを行うためのソフトウェアが必要です。この場合、適切なツールを選択することが重要になります。 Microsoft Web サイト (https://www.microsoft.com/japan/) と TechNet Web サイト (https://www.microsoft.com/japan/technet/default.mspx) には、適切なツールの選択事例のない組織向けに、ツールの選択に役立つ情報が含まれています。

また、Microsoft TAM (Technical Account Manager) との契約がある場合は TAM の協力を得たり、適切なセミナーやカンファレンス、ツールのデモに出席して使用できる監査ツールについての考え方を得ることをお勧めします。一般的に、ツールおよびそれらが展開に適しているかどうかに関する情報は、事前に収集する必要があります。また、ツールの受け入れ基準、およびベースラインの設定時にツールが必要とするリソースを把握しておく必要もあります。

注意SMS と SMS Software Update Services Feature Pack の組み合わせは、修正プログラム管理を効果的に行うために必要な情報を収集したり、管理者がベースラインを定義し作成できるようにする場合に最適です。詳細については、SMS Web サイト (https://www.microsoft.com/japan/smserver/) を参照してください。製品開発の最新情報を入手するためにも、管理者はこのサイトを参照することをお勧めします。

修正プログラム管理プロセスの作業を支援するその他の Microsoft 製品の詳細については、Microsoft Management Web サイト https://www.microsoft.com/japan/systemcenter/default.mspx も参照してください。

監査の実行

監査を実行すると、前述のツールを使用してベースラインを設定する前に、組織の状態についての正確な記録をより容易に把握および取得できます。また、監査の結果は、この時点で構成管理データベース (CMDB) に保存される必要があります。これは、監査が正しいことだけでなく、CMDB が最新状態に維持されることも保障するという、2 重の意味合いを持つ参照ポイントになります。監査の結果と CMDB レコード間で何かしらの差異がある場合は、これを記録し、調査のため問題管理に渡します。問題管理では、今後同様の問題が発生しないように、監査結果を記録する際に問題が発生した箇所を特定し、必要であれば、回避策を考案するようにします。

注意『Microsoft Systems Management Server を使用した修正プログラム管理 - アーキテクチャガイド』に記述されているように、実稼働環境で通常の監査を実行する場合は、SMS Software Update Services Feature Pack のセキュリティ更新ツールおよび Office 更新インベントリツールと、SMS ハードウェアおよびソフトウェアインベントリクライアントエージェントを合わせて使用します。

修正プログラム管理には、その環境に存在しているものの正確で最新の情報が不可欠です。管理者は、修正プログラム管理のタスクや作業をサポートするために、SMS データベースに格納された情報を使い始める前に、監査が正しく行われたことを確認する必要があります。

管理者は、監査を行う前に、SMS 配布ポイントで、最新の MSSecure.xml (セキュリティ更新の場合) および Invcm.exe と Invcif.exe (Office アップデートの場合) が使用できることを確認する必要があります。これらのファイルは、Software Update Services Feature Pack がインストールされた SMS サイトサーバーにより、Microsoft Web サイトから毎週水曜日に自動的にダウンロードされます。ファイルは、そこから SMS 配布ポイントに送信されます。ダウンロードと送信で何らかのエラーが発生したかどうかを判断するために、セキュリティ更新同期タスクと Office 更新同期タスクの両方の提供情報ステータスメッセージを確認する必要があります。これらのタスクのいずれかでエラーが発生した場合は、インシデント管理に通知する必要があります。

SMS 配布ポイントでこれらのファイルの最新バージョンが利用できる場合、SMS 管理者は、次に、各クライアントコンピュータで Office 更新インベントリツールとセキュリティ更新インベントリツールが正しく実行されたことを確認する必要があります。ツールの実行で何らかのエラーが発生したかどうかを判断するために、これらのツールの両方の SMS 提供情報ステータスメッセージを確認する必要があります。インベントリツールの実行に失敗したクライアントコンピュータをインシデント管理に報告する必要があります。

管理者はこのプロセスを容易にするため、図 3 のようなカスタムの Web レポートを構築できます。

図 3: カスタムの Web レポートを使用した提供情報の正常完了の識別

図 3: カスタムの Web レポートを使用した提供情報の正常完了の識別

管理者はインベントリツールが正常に実行されていることを確認したら、各 SMS クライアントのハードウェアおよびソフトウェアのインベントリのステータスを確認します。このためには、ハードウェアおよびソフトウェアインベントリクライアントエージェントがインストールできていない、またはこれらのエージェントが指定された間隔 (データセンタークラスのコンピュータでは毎日、これ以外については毎週) で実行されていない SMS クライアントコンピュータを一覧表示する図 3 のような Web レポートを作成します。このレポートに表示されたコンピュータについてはすべて、問題管理に報告する必要があります。

(迅速な) インベントリツールで提供情報を作成した場合、不足している更新のスキャンが完了した時点で、ハードウェアインベントリが強制的に実行される可能性があることに注意してください。既定では、これらのツールによって取得される情報は、次にスケジュールされているハードウェアインベントリサイクルで SMS サイトサーバーに報告されます。

ベースラインの定義

監査が完了したら、監査によって取得された情報を使用して、実稼働環境内の IT コンポーネントの運用ベースラインを定義します。実稼動環境内に展開されるさまざまな種類のハードウェアやソフトウェアによっては、多くのベースラインが必要になる場合があります。たとえば、ラップトップコンピュータの中には、Microsoft Windows XP を実行している場合、休止モードまたはスタンバイモード時に応答を停止しないようにするための修正プログラムが必要なものもあります。このようなラップトップのベースラインには、この修正プログラムが含まれるようにします。

修正プログラム管理実施中に新しい修正プログラムや新しいソフトウェアアプリケーションが利用できるようになったら、ベースラインを再検討し、更新する必要があります。図 4 は、Microsoft Visioｮ 2000 と Office XP が修正プログラムまたは QFE 修正プログラムをまったく含んでいない場合の初期ベースラインです。ただし、Windows XP は Service Pack 1 (SP1) にベースラインが設定されています。つまり、Windows XP オペレーティングシステムを必要とする新しいワークステーションまたはラップトップは、自動的に SP1 にアップグレードされます。

修正プログラムの実稼働環境へのリリースが承認されるときに、管理者はその修正プログラムが実稼働環境内のコンピュータにインストールされることを確認する必要があります。また、管理者は、構築プロセスがその環境に新しく導入されたコンピュータにも修正プログラムをインストールすることを確認する必要があります。たとえば、ベースライン 1.0 でビルドされ、2002 年 1 月 30 日以降に実稼働環境に追加されたコンピュータには、Q263721、Q300533、Q307843、および Q317087 をインストールする必要があることになります。

管理者は、どこかの時点で、以下の例の修正プログラムを含む新しいベースラインをセットアップすることを決断します。このベースライン 2.0 では、Windows XP は SP1 と Q317087 を適用したものと定義されます。 Windows XP の新規インストールはすべて、Service Pack 1 と Q317087 に関連する修正プログラムを自動的に含むようになります。

図 4: ベースラインの定義

図 4: ベースラインの定義

各ベースラインのレベルは、状態の規模、適用される修正プログラムの共通度、特定のレベルへのベースラインのアップグレードに必要なコストなど、さまざまな要素によって異なる可能性があります。たとえば、Windows XP を実行しているラップトップの 86% には Service Pack 1 および修正プログラム Q317087 がインストールされていて、残りの 14% には Service Pack 1 しかインストールされていない場合、この残りの 14% のベースラインをアップグレードするには、これらのコンピュータおよびこれらのコンピュータに適用される関連のある修正プログラムまたは Service Pack を特定する必要があります。

Service Pack 1 がインストールされているコンピュータのベースラインが設定され、このようなコンピュータが占める割合が低い場合、つまり、大多数のコンピュータのレベルがこのベースラインのレベルではない場合は、これらの大多数のコンピュータを対象とできるレベルまでベースラインをダウングレードする方が合理的な可能性があります。この場合、図 4 のようなビルドベースラインが作成されます。また、将来新しく追加されるコンピュータはすべてこのベースラインに合わせて構築され、さらに、運用ベースラインのレベルに合うように、追加の関連修正プログラムが適用されます。

この構築ベースラインは、展開やバックアップの目的もイメージする必要があります。

また、修正プログラムまたは Service Pack を展開する前提条件、展開順序の規則、および修正プログラムまたは Service Pack 間の競合を把握しておくことも重要になります。これは、これらすべてによって、停止時間が発生する可能性が高まり、作成するベースラインの定義に影響する可能性があるためです。

注意ハードウェアおよびソフトウェアインベントリ時に取得された情報を利用して、実稼動環境に展開されているコンピュータおよびソフトウェアアプリケーション各種のベースラインを定義できます。

管理者は SMS Web レポートまたは SMS 管理ユーザーインターフェイス (UI) を使用して、SMS クライアントにインストールされているソフトウェアアプリケーションを特定できます。図 5 に示されている Web レポートの例では、実稼動環境内で検出されたプログラムがすべて表示されています。これらのプログラムは、SMS クライアントの [ アプリケーションの追加と削除 ] に登録されています。

図 5: 展開されている製品すべてのカウント

図 5: 展開されている製品すべてのカウント

最近のソフトウェアは、ソフトウェア自体により [ アプリケーションの追加と削除 ] に登録されますが、古いソフトウェアまたは適切に作成されていないソフトウェアの中には、ソフトウェア自体により登録されないものもあります。インストールされているすべてのソフトウェアが確実に修正プログラム管理プロセスにおいて検討されるようにするため、図 6 に示されている Web レポート「Count all installed products and versions」により取得される情報を確認する必要もあります。

図 6: インストールされているすべてのソフトウェアの特定

実稼働環境に展開されているすべてのアプリケーションが特定できたら、ベースラインの定義を開始するために、まず、どの修正プログラムと更新 (これらが存在する場合) がこれらのアプリケーションに適用されているかを特定する必要があります。

たとえば、Windows XP ワークステーションが展開されている場合は、図 7 に示すように「Installed software updates for a specific product」レポートを使用して、インストールされている重要な更新を特定できます。

図 7: Windows XP に展開されている更新

SMS Software Update Services Feature Pack で提供されるセキュリティインベントリツールは、インストール済みの Service Pack に関連する修正プログラムだけを識別し、報告することに注意することが重要です。たとえば、Windows 2000 SP1 を実行しているコンピュータでは、Windows 2000 SP2 に必要なセキュリティの更新は表示されません。

インストールされている QFE 修正プログラムおよびカスタム修正プログラムを特定するには、『Microsoft Systems Management Server を使用した修正プログラム管理 - アーキテクチャガイド』で解説されているように SMS_Def.MOF ファイルを変更する必要があります。 SMS_Def.MOF ファイルを変更し、ハードウェアインベントリが SMS クライアント上で実行されたら、Web レポートを作成して実稼動環境にインストールされている QFE およびカスタムの修正プログラムを特定できるようになります。この場合、カスタムの修正プログラムおよび QFE 修正プログラムにより、ID 情報がレジストリに追加され、ハードウェアインベントリサイクル中にレジストリプロバイダによってこの情報が読み取れるようになることを前提としています。この情報のレジストリへの書き込み方法の詳細については、『Microsoft Systems Management Server を使用した修正プログラム管理 - アーキテクチャガイド』の「カスタム修正プログラムの識別」を参照してください。

Microsoft から配布される QFE およびカスタム修正プログラムの中には、[ アプリケーションの追加と削除 ] に登録されるものもあります。これらのプログラムがインストールされると、SMS Software Updates Services Feature Pack で提供されている Enterprise Agreement (EA) license True-Up Report によってレポートされます。

SMS のハードウェアインベントリの既定の構成では、CPU の速度や、メモリ、ディスク容量などの情報が提供されます。この情報だけでは、ハードウェアの種類に基いたベースラインを構築する際に必要になると考えられる、ハードウェアベンダの種類を特定できません。この場合、『Microsoft Systems Management Server を使用した修正プログラム管理 - アーキテクチャガイド』で説明されているように、SMS_Def.MOF も変更して Win32_SystemEnclosure クラスの詳細を取得する必要があります。

ベースラインに対する結果の比較

いくつの項目がベースラインに適合しているかを把握するために、結果の評価を実行します。基準を満たしていない項目が多数存在する場合は、ベースラインを再定義する必要があることがあります。たとえば、 Windows XP を実行している IBM ラップトップコンピュータが状態の 86% を占め、それらすべてに Service Pack 1 がインストールされている場合は、これがベースラインになるでしょう。しかし、状態の 20% にしか Service Pack 1 が実装されていない場合は、このベースランを満たすために残りの 80% をアップグレードするのに多大な作業が必要になるでしょう。この場合は、ベースラインの定義に Service Pack 1 を使用しない方が適切です。

例外の有無の確認

多くの場合、いくつかの項目はベースラインに適合していて、他の項目ではベースラインのレベル以上であるという評価結果になることが考えられます。ベースラインのレベルを超えている項目を判断し、これらの項目が組織内の残りの項目と同期が取れているかどうかを確認します。記録されていない変更を分析用に問題管理に報告します。

変更パイプラインについても、変更管理 SMF により概説されているベストプラクティスを使用して、監視する必要があります。これにより、このような例外を修正する、またはベースラインのレベルに影響する、進行中の変更を特定します。このプロセスは、一般にパイプライン分析と呼ばれます。たとえば、すべてのコンピュータを Office XP にアップグレードするようなプロジェクトが進められている場合に、Office 2000 の Service Pack 2 を導入することは、上位製品へのアップグレードが行われてこの変更は無効となってしまうので、意味がないか、経済的に実行可能ではないでしょう。

サポートエリアへの移行

ベースラインが選択されたら、ベースラインのレベルを超えているコンピュータを調査し、未認可の変更が行われていないかどうかを判断します。これは、サポートエリアの担当者が処理する必要があります。コンピュータがベースラインを超えている場合、このコンピュータを信頼済みのベースラインレベルまで戻す必要がある場合があります。また、この間は、変更を停止を検討することが適切な場合があります。

状態の整合性が保たれるように、ベースラインの評価を一定期間ごとに実行し、結果として次のレベルのベースラインが作成されるようにします。この場合、環境内の変更が新しいベースラインと互換性がなかった場合など、今後ベースラインを最初のベースラインに戻す必要が生じた場合に備え、元のベースラインのレコードは保存しておきます。

注意管理者は識別されたベースラインごとに、次の操作を実行する必要があります。

定義済みのベースラインに適合する "必要のある" コンピュータをすべてを含むコレクションを作成します。たとえば、Service Pack がインストールされていない Windows XP ワークステーションすべてを対象とするベースラインを作成する場合は、次のクエリに基づいて SMS コレクションを作成します。
```
select SMS_G_System_SYSTEM.Name from  SMS_R_System inner join 
SMS_G_System_OPERATING_SYSTEM on 
SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId 
inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceID = 
SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Version 
= "5.1.2600" and SMS_G_System_OPERATING_SYSTEM.CSDVersion IS NULL 
```

定義済みのベースラインに "実際に" 適合するコンピュータをすべて選択するクエリを作成します。たとえば、Windows XP コンピュータ用のベースラインが、Q313450、Q321232、および Q315000 の 3 つの修正プログラムがインストールされている Windows XP ワークステーションのレベルで定義されている場合は、このベースラインに適合しているコンピュータを選択するためのクエリは次のようになります。

select SMS_G_System_SYSTEM.Name from  SMS_R_System inner join 
SMS_G_System_OPERATING_SYSTEM on 
SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId 
inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceID = 
SMS_R_System.ResourceId inner join SMS_G_System_PATCHSTATE as su1 on 
su1.ResourceID = SMS_R_System.ResourceId inner join 
SMS_G_System_PATCHSTATE as su2 on su2.ResourceID = 
SMS_R_System.ResourceId inner join SMS_G_System_PATCHSTATE as su3 on 
su3.ResourceID = SMS_R_System.ResourceId where su1.QNumbers = 
"Q313450" and su1.Status = "Installed" and su2.QNumbers = "Q321232" 
and su2.Status = "Installed" and su3.QNumbers = "Q315000" and 
su3.Status = "installed"

ただし、このクエリは、手順 1 で作成したコレクションのみを対象としていることに注意してください。

定義済みのベースラインに "適合しない" コンピュータをすべて選択するクエリを作成します。たとえば、Windows XP コンピュータ用のベースラインが、Q313450、Q321232、および Q315000 の 3 つの修正プログラムがインストールされている Windows XP ワークステーションのレベルで定義されている場合は、以下のクエリを使用して、これらの修正プログラムがインストールされていないコンピュータを特定できます。

select SMS_G_System_SYSTEM.Name from SMS_R_System where 
SMS_G_System_SYSTEM.ResourceID  not in(select 
SMS_G_System_SYSTEM.ResourceIDfrom SMS_R_System inner join 
SMS_G_System_OPERATING_SYSTEM on 
SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId 
inner join SMS_G_System_PATCHSTATE as su1 on su1.ResourceID = 
SMS_R_System.ResourceId inner join SMS_G_System_PATCHSTATE as su2 on 
su2.ResourceID = SMS_R_System.ResourceId inner join 
SMS_G_System_PATCHSTATE as su3 on su3.ResourceID = 
SMS_R_System.ResourceId where su1.QNumbers = "Q313450" and 
su1.Status = "Installed" and su2.QNumbers = "Q321232" and su2.Status 
= "Installed" and su3.QNumbers = "Q315000" and su3.Status = 
"installed"and SMS_G_System_OPERATING_SYSTEM.Version = "5.1.2600" 
and SMS_G_System_OPERATING_SYSTEM.CSDVersion IS NULL)

XP SPx が適用されていて、修正プログラムを適用していないクライアントがベースラインを満たす場合。

select SMS_G_System_SYSTEM.Name from SMS_R_System where 
SMS_G_System_SYSTEM.ResourceID  not in(select 
SMS_G_System_SYSTEM.ResourceIDfrom SMS_R_System inner join 
SMS_G_System_OPERATING_SYSTEM on 
SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId 
left join SMS_G_System_PATCHSTATE as su1 on su1.ResourceID = 
SMS_R_System.ResourceId left join SMS_G_System_PATCHSTATE as su2 on 
su2.ResourceID = SMS_R_System.ResourceId left join 
SMS_G_System_PATCHSTATE as su3 on su3.ResourceID = 
SMS_R_System.ResourceId where (su1.QNumbers = "Q313450" and 
su1.Status = "Installed" and su2.QNumbers = "Q321232" and su2.Status 
= "Installed" and su3.QNumbers = "Q315000" and su3.Status = 
"installed"and SMS_G_System_OPERATING_SYSTEM.Version = "5.1.2600" 
and SMS_G_System_OPERATING_SYSTEM.CSDVersion IS NULL)or 
(SMS_G_System_OPERATING_SYSTEM.Version = "5.1.2600" and 
SMS_G_System_OPERATING_SYSTEM.CSDVersion IS NOT NULL))

ただし、このクエリは、手順 1 で作成したコレクションのみを対象としていることに注意してください。

場合によっては、ベースラインを超えているコンピュータを特定するためのクエリも追加で作成する必要があります。
管理者は、識別および保守するベースラインごとに、上記の処理を繰り返す必要があります。たとえば、オペレーティングシステムやハードウェアの種類に応じて専用のベースラインを作成する必要がある場合があります。また、特定の部門やグループが所有している特定のハードウェアやコンピュータごとに専用のベースラインを作成する必要がある場合もあります。

ベースラインが設定できたら、通知の購読を設定して、ベースラインよりも低い修正プログラムの通知を受け取らないようにします。たとえば、ベースランの設定が Microsoft Office XP である場合は、Microsoft Office 2000 の修正プログラム取得のための購読は必要ありません。

購読を考慮して常に変化するベースラインの状態を監視し、ベースラインに変更があった場合はこれを購読プロセスに携わる担当者に通知することが、管理者にとっての重要な作業です。月に一度程度の定期的なレビューと、購読プロセスと強く結び付けることで、購読プロセスとベースラインとの整合性が保たれ、購読設定を常に有効な状態に保持し、通知ソースの設定に間違いが生じないようにできます。

図 8 は、購読のプロセスフローチャートを示しています。

図 8: 購読のプロセスフローチャート

図 8: 購読のプロセスフローチャート

以下のセクションでは、図 8 の購読のフローチャートで示した各プロセスを説明します。

テクノロジストリームの特定と確立

監査が完了したら、実稼働環境内で使用されているテクノロジの種類を特定し、必要に応じて、管理しやすいようにそれらのテクノロジをグループ分けできるようになります。たとえば、Windows XP ワークステーション、Office 2000、および他のエンドユーザーアプリケーションはデスクトップサポートグループに、Windows 2000 サーバー、Microsoft Internet Information Services (IIS)、および Microsoft SQL Server・をサーバーサポートグループに割り当てることができます。

テクノロジストリームに基づく修正プログラムの通知場所の確立

関係のあるテクノロジストリームが特定できたら、購読がこれらのテクノロジに適したものになるようにします。さまざまな修正プログラムの通知場所が製品または製品グループごとに専用に用意されるので、これが必要になります。たとえば、Office XP の修正プログラムは、Office XP のアップデートサイトで提供されています。

各テクノロジストリームの通知場所は、多数存在する可能性があります。最適な通知場所を確立することが不可欠です。また、通知場所は、テクノロジストリームごとに異なる可能性があります。たとえば、いくつかの Microsoft テクノロジについての電子メールによる通知、その他のテクノロジ製品についての Web サイト、TechNet、TAM、コンピュータパブリケーションがあります。

発見作業を実行し、割り当てられている信頼レベルなど、各発行元の有用性を見極めることが重要です。

注意セキュリティ更新インベントリツールおよび Office 更新インベントリツールによって、必要な修正プログラムについての情報が含まれている、更新された XML (Extensible Markup Language) データベースファイルが定期的にダウンロードされます。更新済みの XML ファイルを持つクライアントコンピュータ上でこれらの更新ツールが次に実行されるときに、これらのツールにより、このクライアントコンピュータにインストールする必要のある新しい修正プログラムが特定される可能性があります。

QFE 修正プログラムの場合は、新しい修正プログラムについての通知を受け取るには、Microsoft Web サイトで提供されているメーリングリストを購読するか、以下の Web ページを定期的に確認する必要があります。

Web ページ

セキュリティ修正プログラム:
https://www.microsoft.com/japan/security/

一般的な修正プログラムダウンロード:
https://www.microsoft.com/downloads/search.aspx?displaylang=ja

Service Pack ダウンロード:
https://support.microsoft.com/default.aspx?scid=FH;ja;sp&FR=0&SD=GN&LN=ja&

マイクロソフトプレミアサポートユーザー:
https://premier.microsoft.com (英語)

電子メールニュースレター

https://www.microsoft.com/japan/technet/abouttn/subscriptions/flash_register.mspx

https://www.microsoft.com/japan/technet/security/bulletin/notify.mspx

ニュースグループ

適切なテクノロジニュースグループを定期的に確認して、同様のシナリオで他のユーザーが抱えている問題を参考にしてください。

https://www.microsoft.com/japan/communities/default.mspx で [ ニュースグル - プ ] をクリックします。

通知方法の確立

テクノロジストリームの通知場所を特定できたら、次は、電子メールによる通知や Web サイト、パブリケーション、直接の連絡など、利用可能な購読方法の中から購読方法を 1 つ選択します。

選択内容をドキュメント化し、何か変更があった場合に、担当者により対処されるようにします。たとえば、あるテクノロジストリームの管理者がサードパーティの供給元と電話で応対をしていた場合、この管理者のプロセスを確立およびドキュメント化し、この管理者または管理者の所属するチームが不在の場合でも、同じようにプロセスが実行されるようにすることが重要です。

通知方法の割り当てと購読

適切なテクノロジストリームの担当者に、識別したテクノロジストリームごとに購読を管理する責務を割り当てる必要があります。

たとえば、アプリケーションチームで SQL Server と Office を担当するとします。このチームには、担当しているテクノロジの修正プログラムすべてが通知される必要があります。また、修正プログラム情報を取得する上でチームにとって最適なテクノロジストリーム修正プログラムの通知場所を特定し、適切な通知方法を使用してこの通知場所からの購読が可能であるかどうかを判断する必要があります。

以下の例は、修正プログラムの情報源を例示しています。

例 1: TAM (Technical Account Manager) とチームのメンバーで毎週 1 回の会合持つことは、有益な情報源になるでしょう。チーム側は責任を持ってメンバの 1 人を毎週行われるこのミーティングに出席させ、通知についての情報を収集するようにします。

例 2: 電子メールによる購読を設定して、毎日、毎週、または毎月、Web ベースの発行元からの通知の一覧がチームに配布されるようにします。

例 3: 毎日、毎週、または毎月、通知 Web サイトを確認するようにします。また、組織は担当チームによって通知 Web サイトが確認され、このチームが担当するテクノロジにかかわる通知がすべて採用されていることを確認するプロセスを持つ必要があります。

通知の受信テスト

選択した通知方法は、どの方法であってもテストを行い、すべての重要な修正プログラムの通知が受信できることを確認する必要があります。これは、電子メールや Web サイトを利用した通知の場合は非常に簡単ですが、個別の会議や電話による通知は直接確認をとる必要があり、プロセスが必要になります。また、通知の受信は、とりわけ通知が電子メールの購読によるものでない場合には、監視する必要もあります。これらの確認を行う方法の例を以下に示します。

例 1: Web サイトの確認が必要な場合は、テクノロジストリームのメンバにより、見つかった適切な通知を集中管理された情報共有ポイントで各自のグループの他のメンバに向けて投稿します。また、このテクノロジでは、チームが Web サイトにアクセスしたかどうかを確認できるようにして、チームが通知の確認を怠ったことにより、組織が危険な状態に置かれることがないようにします。

例 2: 個人またはチームが、職務の一環として、TAM またはサードパーティの供給元と会合を持ちて、公開された新しい修正プログラムや Service Pack がないかどうかを確認します。これは、個人またはチームの責務の一部としてドキュメント化および報告しておくことができます。

購読方法の確立の完了

テストが成功したら、テクノロジストリームの購読通知方法の確立は完了です。管理者は、どの時点であってもテストが失敗した場合は、通知場所の特定、購読方法の再確立、通知の割り当てと購読の手順をテストが成功するまで繰り返し行う必要があります。

変更の開始

修正プログラム管理の変更の開始プロセスは、次の 3 つの主要コンポーネントで構成されます。

"識別"。修正プログラムがどの修正プログラムであるか、新しいものかまたは既にリリースされているものか、および有効であるかどうかを判断します。
"関連性評価"。修正プログラムが、組織の IT インフラストラクチャの環境で意味があるかどうかを判断します。
"検疫"。修正プログラムに、組織の IT インフラストラクチャに影響する可能性があるウィルス、またはその他の悪意のあるコードが存在しないかどうかを検査する間、修正プログラムに関連するファイルを分離します。

識別

識別のプロセスを図 9 のフローチャートに示します。識別は主に次の 3 つのコンポーネントで構成されています。

"通知"。既に選択されている何らかの購読方法により修正プログラムについて通知を受けます。
"通知の審査"。修正プログラムが組織の IT インフラストラクチャに適用可能なものであるかどうかを確認します。
"修正プログラムの妥当性確認"。修正プログラムを調べ、これらが信頼済みの発行元から提供されていること、および第三者が修正プログラムを装いウィルスの侵入を試みているものでないことを確認します。

図 9: 識別のプロセスフローチャート

以下のセクションでは、図 9 の識別のフローチャートで示した各プロセスを説明します。

通知

購読プロセスが正常に完了したら、新しい修正プログラムについての通知が到着しはじめます。ただし、この時点では、これまでに見落とされていた発行元からの通知が送られてくる可能性があることに注意してください。この情報の発行元が有益であると確認できた場合は、テクノロジストリームの担当者によって、これを有効で管理対象としている購読の一覧に追加する必要があります。

注意SMS Software Update Services Feature Pack を使用している組織は、「Count of applicable patches by type」 Web レポートを使用して、実稼働環境に展開されているコンピュータに、関連修正プログラムでまだインストールされていないものを判断できます。

このレポートによって生成される情報の例を図 10 に示します。

図 10: 適用可能なソフトウェアの更新の種類別の数

注意セキュリティの更新インベントリツールと Office 更新インベントリツールは、Mssecure.xml ファイル (セキュリティ更新の場合) または Invcm.exe ファイルと Invcif.exe ファイル (Office アップデートの場合) に記録された情報に関する修正プログラムだけを認識し、報告します。これらのファイルに更新に関する情報が示されない場合、管理者は SMS ソフトウェアとハードウェアインベントリクライアントエージェントで取得した情報を使用して、修正プログラムが特定のクライアントコンピュータにインストールされているかどうかを判断する必要があります。

また、セキュリティの更新インベントリツールで使用されるスキャンツール (MBSA) が特定の更新の存在の有無を明確に判断できない場合は、このツールが警告メッセージまたは情報メッセージを報告します。 "たとえ"、更新がインストールされている場合でも、更新のステータスが変更されないときは、セキュリティの更新インベントリツールがこのような更新に関する情報を破棄します。詳細については、以下のサポート技術情報の資料を参照してください。 https://support.microsoft.com/default.aspx?scid=kb;ja;306460&sd=tech

このような場合、管理者は SMS ソフトウェアとハードウェアインベントリクライアントエージェントによって取得された情報を使用して、これらの更新がインストールされているかどうかを判断する必要があります。

QFE 修正プログラムの場合は、通常、Microsoft Web サイトで新しい修正プログラムが公開されたことを通知する電子メールメッセージによって、更新情報がテクノロジストリームの担当者に通知されます。このメッセージのコピーは、監査プロセス用に保存される必要があります。

サーバーオペレーティングシステムのニュース速報の例を図 11 に示します。

図 11: 新しい修正プログラムについて管理者に通知する電子メールメッセージの例

なお、本書の「購読」で説明されているように、Web サイトを確認することでも新しい修正プログラムについての通知を取得できます。

通知の審査

審査プロセスでは、通知および組織の IT インフラストラクチャにとってその通知が適切であるかどうかの一次レベルの検査を行います。通知は、適切なテクノロジストリーム宛てに配信され、これを評価できる知識のある担当者によって審査される必要があります。また、購読プロセスにエラーがあり、このために通知が適切でないテクノロジストリームに配信された場合は、必要に応じてこれらのエラーを修正します。

たとえば、通知が IIS のバージョン 5 用に配信されたとしても、組織で使用している IIS がバージョン 6 だった場合、この通知は組織にとって無関係な通知です。このような場合は、特に対処は必要ありませんが、購読を確認し、IIS の通知の設定が更新されていること、およびこのプロセスが適切なバージョンに対して行われていることを確認します。

注意「Count of applicable patches by type」 Web レポートを使用して、実稼働環境に展開されているコンピュータに関係がある修正プログラムで、インストールが必要なものを特定できます。この場合、このレポートで特定されたすべての修正プログラムは、審査プロセスを実行してから、次の操作のために適切なテクノロジストリームに渡される必要があります。

審査担当者は、Microsoft から電子メールによって到着した修正プログラムの通知を検証する必要があります。このためには、電子メールのヘッダーを調べ "差出人" のアドレスが有効であることを確認します。ただし、これだけでは、有効性が実証されたとは認められません。セキュリティニュースレターには、PGP (Pretty Good Privacy) 署名が付けられています。PGP は、パブリックドメイン PGP 署名チェッカーを使用して、検証できます。

電子メールメッセージは改ざんされる可能性があるので、審査担当者は、Microsoft サポート Web サイト (https://support.microsoft.com/) でこの通知に記載されているサポート技術情報が存在していることを確認する必要があります (図 12 参照)。

図 12: サポート技術情報の有無の確認

なお、審査担当者は、電子メールメッセージ内にあるリンクについては参照しないようにする必要があります。

通知が有効である場合は、審査担当者は、次に実稼働環境内の IT コンポーネントに適用可能な修正プログラムについての情報を記載しているサポート技術情報をすべて特定し、これらを適切なテクノロジチームに通知します。

通知が実稼動環境のテクノロジコンポーネントに当てはまるかどうかが審査担当者に判断できなかった場合は、「Count all installed products and versions」 Web レポートまたは「List all products for a specific company」 Web レポートを使用して、インストールされているコンポーネントを特定します。

期日前に審査が実行されたかどうかの確認

各通知の優先順位および通知方法には、特定のサービス条件を設定できます。たとえば、セキュリティ修正プログラム (Hotfix) に高い優先順位が設定されているとします。そのため、このような通知は配信された時点ですぐに審査される必要があるので、このような審査の実施を助けるサービス条件を設定し、審査が決められた期日内に完了しなかった場合にエスカレーションプロセスが実行されるようにします。

エスカレーション

通知が期日内に審査されなかった場合は、適切な担当者にエスカレーションされる必要があります。各組織で、それぞれの要件にもっとも適したエスカレーションの手順を確立するようにします。

たとえば、セキュリティ修正プログラムは、きわめて迅速に処理し、組織を潜在的な脅威から保護する必要があります。このような通知が決められた期日内に審査されなかった場合は、IT 管理にこのことがエスカレーションされる必要があります。

通知が審査に合格したかどうかの確認

審査プロセスでは、通知および通知が組織の IT インフラストラクチャにとって適切であるかどうかの最初の検証が行われます。通知は、適切なテクノロジストリーム宛てに配信され、これを評価できる適切な知識のある担当者によって審査される必要があります。通知が適切なテクノロジストリームに配信されなかった場合は、この通知に関連のあるテクノロジストリームに引継ぎます。また、管理者が必要であると判断した場合は、この通知が不適切なテクノロジストリームに配信される原因となった購読プロセス中のエラーについて、この購読プロセスの担当者にフィードバックします。

修正プログラムの妥当性確認

修正プログラムまたはセキュリティ通知を装い、ウィルスを送信する可能性のある悪質な発信元が多いので、修正プログラムの妥当性をそのまま信用することはできません。 Microsoft から発行される新しい修正プログラムや更新については、電子メールメッセージにより通知されますが、これらのメッセージにソフトウェアファイルが含まれる (添付される) ことは決してありません。

Microsoft からは、時折、更新や修正プログラムが公開されていることを知らせる電子メールメッセージを送付しています。ただし、このようなメッセージには、ダウンロードサイトへのリンクのみが含まれています。ソフトウェア自体が添付されることは決してありません。また、ダウンロードサイトへのリンクは "常に" Microsoft の Web サイトまたは FTP (ファイル転送プロトコル) サイトにリンクされていて、サードパーティのサイトにリンクされていることはありません。悪質な電子メールメッセージの中には、HTML 形式の電子メールメッセージの場合、表示されているリンクテキストとは異なるインターネットリンクが含まれているものもあります。参照される Web サイトの URL を確認することが重要になります。
Microsoft では、ソフトウェア修正プログラムをインターネット上で公開しています。修正プログラムは、https://www.microsoft.com/japan/ または FTP サイト ftp://ftp.microsoft.com/ からダウンロードできます。
修正プログラムのファイルは、CD-ROM やフロッピーディスクなどの物理メディアで提供される場合もあります。
Microsoft では、常に Authenticode を使用して製品にデジタル署名し、製品ファイルが改ざんされていないことを確認できるようにしています。

管理者は、必ず Microsoft サポート Web サイト (http://www.support.microsoft.com) でサポート技術情報を検索し、修正プログラムが有効であることを確認する必要があります。電子メールメッセージ内のサポート技術情報へのリンクや URL を使用して、Web ページを参照しないようにしてください。

Microsoft からの通知として、ソフトウェアファイルが添付されている電子メールメッセージ通知を受信した場合は、添付されているファイルは開かないようにし、直ちにその電子メールメッセージを削除してください。また、組織のセキュリティチームに連絡して、サポートを依頼します。

ソフトウェアの配布に関する Microsoft のポリシーの詳細については、https://www.microsoft.com/japan/technet/security/bulletin/info/swdist.mspx を参照してください。

注意電子メールによる通知の購読プロセス中に、これらの通知の信頼性を検証した方法についての情報を収集しておく必要があります。 PGP 署名が使用されている場合も、デジタル署名が使用されている場合もあるでしょう。また、管理者は通知の発信元を確立しておく必要もあります。このような電子メールメッセージの "差出人" のアドレスが偽造される可能性はありますが、受信メッセージの SMTP (Simple Mail Transfer Protocol) 電子メールヘッダーを手動で確認することで、メッセージの信頼性をより一層保証できるようになります。

修正プログラムの妥当性

妥当性確認プロセスでは、修正プログラムを以降の作業のために解放するか、セキュリティ上問題のある修正プログラムについてはこれを特定します。妥当でない通知を受け取ったときは、詳しく調査するために購読プロセスにフィードバックされる必要があります。

たとえば、通知が通常信頼している発行元から配信されていて、特定の通知で検証の結果エラーが検出された場合、これは、この発行元から発信される通知の品質についてのセキュリティ上の懸念を生むことになりかねません。この発行元を調査し、問題がある場合は解決する必要があります。

関連性評価

たくさんの修正プログラムが、IT 運用コミュニティに毎日リリースされています。修正プログラムの情報源および作成理由はさまざまで、システム内で注目されているバグやセキュリティを侵害する可能性のあるエラーの出現が含まれています。膨大な種類の使用可能なソフトウェアに適用できる修正プログラムが多数あるので、すべての修正プログラムを徹底的に検査して、組織の IT インフラストラクチャとの関連性を確認することが重要です。この前のセクションで概説した通知の審査プロセスで、無関連な修正プログラムの大半は取り除かれますが、廃棄できる修正プログラムがまだある可能性があります。

配信された修正プログラムは、関連のあるものであるかどうかを 1 つ 1 つ確認する必要があります。通知に複数の修正プログラムに関する情報が含まれている場合は、各修正プログラムについて、組織に関連のあるものであるかどうかをそれぞれ確認する必要があります。

図 13 のフローチャートは、修正プログラムの関連性を確認するプロセスを示しています。

図 13: 関連性評価のプロセスフローチャート

図 13: 関連性評価のプロセスフローチャート

以下のセクションでは、図 13 の関連性評価のフローチャートで示した各プロセスを説明します。

修正プログラムのレビュー

通知の各修正プログラムは、詳細で綿密なレビューが必要です。このレビューでは、修正プログラムと合わせて送付されたものも含めて関連するすべてのドキュメントと、Microsoft の TechNet Web サイトなど、入手可能なサポート情報を参照する必要があります。また、レビューでは、修正プログラムの性質と目的を確認する必要があります。さらに、通常は、関連する製品と CMDB の両方のサポート情報の詳しい調査も行います。インシデント管理と問題管理を含め、他の SMF の担当者からの情報も必要になる可能性があります。

注意セキュリティ更新インベントリツールおよび Office 更新インベントリツールによって更新する必要があると特定された修正プログラムはすべて、実稼働環境のコンピュータに関連があるものです。

QFE 修正プログラムの場合、適用可能な修正プログラムを特定するテクノロジストリームに電子メールメッセージが配信されたら、チームのメンバをこの修正プログラムの調査に割り当てる必要があります。これにより、このチームメンバがこの修正プログラムを担当することになります。レビュー担当者は、関連するサポート技術情報に目を通し、この修正プログラムによって何が修正されるかを把握する必要があります。

修正プログラムは、特定のシナリオや構成にしか関連がない場合があります。レビュー担当者は、実稼働環境に展開されるシナリオや構成が、サポート技術情報と一致するかどうかを確認する必要があります。 SMS クエリおよび Web レポートを作成して、この情報を取得する必要がある可能性があります。

たとえば、サポート技術情報で、3 GB を超えるメモリが実装されているコンピュータで実行されている SQL Server にのみこの修正プログラムが必要であると記載されている場合は、このような構成の SQL Server が存在するかどうかを判断するため、クエリや Web レポートを作成する必要があるでしょう。

修正プログラムのドキュメントでは、多くの場合、特定の現象が確認される場合にのみ、修正プログラムを展開するように記載されています。これを確認するには、問題管理のログを参照するか、具体的なイベント ID が指定されている場合は、システム上でこの ID が収集されていないかどうか Microsoft Operations Manager (MOM) を確認するか、危険な状態にある可能性のあるコンピュータのイベントログを参照します。 Microsoft Operations Manager の詳細については、https://www.microsoft.com/japan/mom/default.mspx を参照してください。ただし、セキュリティ修正プログラムの場合は、このような現象が確認されていなくても、予防的に前もって修正プログラムを適用する必要があります。

修正プログラムが適用可能かどうかの確認

最初の通知で収集された情報と、修正プログラムの審査によって得た詳細情報から、修正プログラムが組織の IT インフラストラクチャにに適用可能かどうかを確認できます。ただし、修正プログラムの中には、最初は適用可能に思われても、適用できない修正プログラムもあります。以下に、いくつか例を挙げます。

例 1: 修正プログラムが Microsoft Windows 2000 を実行するすべてのコンピュータにインストールするように推奨されています。しかし、その修正プログラムが特定のサーバーで実行されている基幹業務アプリケーションと互換性がない (またはテストされていない) 場合は、そのアプリケーションの稼動停止時間でのビジネス上のリスクや可能性のある問題点により、その修正プログラムを適用すべきではないと決断することがあります。

例 2: 受け取った修正プログラムが、Office XP の機能追加を目的とするものであった場合に、現状の機能を使用することについて何の問題も報告されていない場合は、この修正プログラムは組織にとってはほとんど価値がありません。

例 3: 修正プログラムが、Service Pack 2 が適用されている Windows 2000 Server の潜在的なセキュリティ上の問題を修正するものであった場合に、既に Service Pack 3 へのアップグレードをすぐに実行する計画がある場合、Service Pack 3 により、これ以前の Service Pack 以降に発行された修正プログラムがまとめて適用されます。

例 4: 配布された修正プログラムが SQL Server を実行する 64 MB メモリを備えたすべてのコンピュータにインストールする必要があるものであった場合に、組織に展開されている SQL Server を実行するコンピュータがすべて 256 MB 以上のメモリを備えている場合、この修正プログラムは組織の環境には無関係な修正プログラムです。

修正プログラムが組織にとって適用可能でない場合は、廃棄できます。ただし、組織にとって無関係な修正プログラムが多数配布されている場合は、無関係な修正プログラムについての情報を購読プロセスの担当者にフィードバックする必要がある可能性があります。これは、通知の購読ソースやテクノロジストリームに問題がある可能性あるためです。

修正プログラムの情報が、無関係なものと判断されても、問題管理担当者に連絡し、この修正プログラムが存在することを記録しておくことは重要です。これにより、将来、この修正プログラムが組織の環境に関連のあるものになり、必要になった場合、最初の発行元からこの情報を取得できます。

修正プログラムをすぐに適用すべきかの確認

次の関連性についての問題は、修正プログラムが適用可能で、関連性のあるものであった場合、これを即座に適用する必要があるかどうかという問題に対処することです。場合によっては、修正プログラムは直ちに適用する必要があります。たとえば、セキュリティ上の問題が発生している場合や、ウィルス保護の更新が必要な場合、解決が必要なエラーやインシデントが発生している場合など、事態に対応して修正プログラムを適用する必要がある場合です。逆に、同じ理由に対して修正プログラムを事前に適用する、つまりセキュリティ対策やウィルス保護を最新状態に保つためや、他の組織から報告されたエラーやインシデントに対応するための場合もあります。

管理者が修正プログラムを直ちに適用する必要がないと判断した場合は、この修正プログラムおよび組織の IT インフラストラクチャに影響を与える可能性のある潜在的な問題の詳細や、利用可能な修正プログラムなどの関連情報情報を問題管理の担当者に連絡する必要があります。

修正にファイルが含まれるかどうかの確認

適切なテクノロジストリームにより、修正が組織の環境に関連性があり、適用する必要がある可能性があると判断され、関連ドキュメントの確認も済んだら、次はその修正にダウンロードが必要なファイルがあるかどうかを確認します。

修正には、関連するファイルがない場合もあります。ダウンロードが必要な関連ファイルがなく、レジストリや構成ファイルの変更、または管理者によりアプリケーションの設定変更を行うものである場合もあります。この場合、修正は関連性プロセスの次のプロセスに進むことができます。

ただし、修正に .exe ファイルなどの関連ファイルがある場合は、使用前にこれらのファイルに対して検疫プロセスを実行する必要があります。このプロセスによって、IT インフラストラクチャのセキュリティおよび可用性が脅かされることがないようにします。詳細については、本書の後半の「検疫」を参照してください。

前提条件、競合、および順序の評価

修正プログラムの担当者は、修正プログラムファイルの検疫が完了したら、直接的影響およびカスタマイズに対する影響の両方を考慮して、修正プログラムの前提条件や順序に問題がないかどうかを検討する必要があります。

たとえば、Windows 2000 DNS の管理者が、その管理者が担当するテクノロジストリームで修正プログラムの通知を受け取り、この修正プログラムには Windows 2000 Service Pack 2 が必要であった場合、管理者は、SP2 とこの修正プログラムの両方を展開する変更の要求を作成することになります。その後、変更管理により、一度に両方の展開が承認されるか、両方が拒否されます。修正プログラムは DNS のパフォーマンス強化のためのものですが、SP2 はすべての Windows 2000 サーバーにインストールする必要があり、これを実行するのは経済的でない可能性があります。 DNS 管理者には、この判断を下す能力または権限がないでしょう。この判断は、変更管理の責務です。

前提条件、競合、順序について判明した詳細や情報はすべて、変更管理プロセスで使用できるように、また経済的に妥当であると認められる修正プログラムの展開の開発など、一般的な意思決定に利用できるように記録しておきます。

検疫

ウィルスの感染や悪質なコードによる組織の IT インフラストラクチャへの悪影響を防ぐため、修正プログラムのすべて関連ファイルは、独立した (検疫) 環境で検査する必要があります。この検疫は、すべてのソフトウェアおよびドキュメントに行う必要があります。検疫済みの環境で、厳密な管理を適切に行う必要があります。これを保証するために、組織内の専門家のグループが検疫プロセスを実行する必要があります。

修正プログラムに対する検疫にかける時間は、修正プログラムを展開する上での緊急性および組織に対する修正プログラムの関連性に基づいて、サービスレベル契約 (SLA) により決定されます。修正プログラムには、既に担当者が割り当てられ、優先順位が検討されているので、緊急性および関連性の特定にはこれらを判断要因として利用できます。

図 14 は、検疫環境において修正プログラムファイルを検査する場合のプロセスフローチャートを示しています。

図 14: 検疫のプロセスフローチャート

図 14: 検疫のプロセスフローチャート

検疫の SLA は、個別の組織、および特定の通知や修正プログラムに割り当てられた優先順位と影響によって異なります。たとえば、セキュリティ修正プログラムには高い優先順位が割り当てられていても、検疫の SLA はこの修正プログラムが適用されるテクノロジによって異なる可能性があります。 Microsoft Windows NTｮ Server のセキュリティ更新の場合は数時間以内に適用する必要があり、リモートユーザーの場合は数日以内に適用すればよい場合もあります。

注意検疫の管理者は、電子メールメッセージやタスク内で指定されている URL は、ウィルスに感染した修正プログラムを含むファイルを保持するページにリンクされている可能性があるので、直接参照しないようにする必要があります。代わりに、Microsoft サポート技術情報で修正プログラムを検索します。サポート技術情報には、修正プログラムに必要なファイルの入手先が掲載されています。

ダウンロード場所では、すべての受信トラフィックに対してウィルス検査を有効にし、修正プログラムの実行ファイルに対してウィルススキャンが実行されるようにします。また、スキャンプログラムを利用して、.zip ファイルや .cab ファイルなどの圧縮ファイルに対してもスキャンを実行するようにし、圧縮ファイル中のファイルにもウィルス検査が実行されるようにします。

以下のセクションでは、図 14 の検疫のフローチャートで示した各プロセスを説明します。

修正プログラムファイルのレビュー

修正プログラムは、既知の信頼できる発行元により妥当性確認されていますが、プロセスのこの段階でようやく修正プログラムパッケージが検疫環境にダウンロードされ、exe や .doc、Readme などの関連ファイルを閲覧できるので、さらにエラーが検出される可能性があります。

修正プログラムファイルのこのレビューでは、ファイルのサイズを考慮する必要もあります。プログラムは 1 つだけでしょうか、または複数あるのでしょうか? 通知とダウンロードパッケージとではバージョン番号が一致しているでしょうか。またダウンロードパッケージと通知とでは、ファイルのサイズが一致しているでしょうか? 不整合がある場合は、これによりこのファイルのレビューの合否が決まる要因となるので、明記しておく必要があります。

注意管理者は、ファイルを適切なディレクトリにダウンロードしたら、このファイルの妥当性を検証する必要があります。図 15 に示すように、Microsoft のセキュリティ修正プログラムは、すべて署名されています。

図 15: デジタル署名の確認

図 15: デジタル署名の確認

署名されていないセキュリティ修正プログラム以外の修正プログラムの場合は、修正プログラムのファイルを解凍し、Microsoft Web サイトのサポート技術情報に記載されているファイルの内容と比較する必要があります。

修正プログラムから各ファイルを解凍するには、次のコマンドを実行します。

<patch.exe> /c /t:d:\patches\<KB article number>

これにより、ファイルは、修正プログラム (サポート技術情報の文書番号) と同じ名前の、修正プログラムのサブディレクトリに解凍されます。ファイルを解凍したら、解凍したファイルのサイズとバージョン番号と、関連するサポート技術情報に記載されているファイルのサイズとバージョン番号を比較します。

修正プログラムファイルのレビューの合非

ファイルが信頼できない、または通知とダウンロードファイル間に不整合がある場合は、管理者は修正プログラムを廃棄する必要があります。修正プログラムのレビュー中に、検疫環境が障害を受けた場合は、環境を再構築する必要があります。

修正ファイルが有効な発行元から配布されていたにもかかわらず、レビューに合格しなかった場合は、購読プロセスの担当者にこの情報を送り、何が起こっているかを調査できるようにします。また、修正プログラムの担当者にも通知する必要があります。 (修正プログラムの担当者は、適切なテクノロジストリームのメンバでない場合でも、このような通知を扱うのに必要な技術的知識を備えている必要があります。)

修正プログラムの担当者には、修正プログラムがレビューに合格しなかった理由を連絡する必要があります。担当者は、問題のあった修正プログラムを廃棄することも、調査を進めて別のソースから修正プログラムを取得し、通知プロセスの段階からプロセスを繰り返すこともできます。

修正プログラムファイルが検疫レビューに合格すると、ファイルは実際にウィルスのない安全なファイルになります。安全な修正プログラムファイルは、これらのファイルの保管場所となるセキュリティで保護された記憶域に移動し、修正プログラムを展開する準備が整うまで、ウィルスなどの障害を与えるアクセスからの影響を受けることがないようにします。

検疫およびセキュリティの専門家は、この時点で、修正プログラムの展開の SLA を開始できるテクノロジストリームの担当者に連絡します。

注意検疫サーバーが障害を受けた場合に、このサーバーを再構築する場合は、リモートインストールサービス (RIS) や無人ビルドなどの自動化されたビルドプロセスを利用することをお勧めします。ただし、どのような方法で再構築を行うとしても、インターネットに接続する前に、最新のウィルス対策ソフトウェアとセキュリティ構成を使用して、検疫環境のコンピュータを更新する必要があります。

変更管理

修正プログラム管理における変更とは、Service Pack や修正プログラム (Hotfix) など、IT 環境に十分な計画の下に導入されるソフトウェアへの追加で、IT SLA に影響する可能性があり、導入されない場合は環境や環境のコンポーネントの機能に悪影響が出る可能性のある、ソフトウェアへの追加と定義されます。変更には、一時的な変更と永続的な変更があります。一時的な変更は、永続的な変更が実装されるまで、または期間限定である特定の目的のために適用されるものです。永続的な変更は、コンポーネントの現在のバージョンを完全に置き換えます。ただし、一時的であれ永続的であれ、すべての変更は変更管理プロセスに合格する必要があります。

図 16: 変更管理プロセスのフローチャート

図 16: 変更管理プロセスのフローチャート

図 16 のフローチャートは、変更管理の大まかなプロセスモデルを示しています。このプロセスは、変更管理 SMF ガイドで詳しく説明されています。変更管理サービス管理機能の詳細については、https://www.microsoft.com/solutions/msm/techinfo/default.asp (英語) を参照するか、https://www.microsoft.com/japan/technet/default.mspx の TechNet サイトで関連ドキュメントを検索してください。

変更管理 SMF はこのセクション全体で触れていますが、修正プログラムおよび Service Pack の処理に関連する変更管理の位置づけを概説しているにとどまります。変更管理プロセスについての詳細については、変更管理 SMF ガイドを参照してください。

以下のセクションでは、図 16 で示す変更管理プロセスを説明します。

変更要求

他のすべての変更要求 (RFC) の場合と同様に、修正プログラム管理の開始者は、提案された修正プログラムの展開に関連する変更から受ける影響を認識するために、あらゆる努力をする必要があります。開始者はすべての影響を受ける構成アイテム (CI) を識別できない可能性がありますが、識別するように努力することが重要です。

修正プログラム管理の開始者が何らかの前提条件を認識している場合は、適用の順序の要件または競合についても RFC に含めるようにします。

また、変更の開始者はある通知のソースには他のソースよりも高い優先順位が設定されている場合があるので、通知のソースも RFC に含めるようにします。たとえば、Microsoft TAM (Technical Account Manager) からの通知は、Web サイトからの通知よりも重要であると見なされる場合があります。

最後に、変更の開始者は、変更の開始の識別、関連性評価、および検疫の各段階で特定された情報も、変更要求に関係がある場合はすべて RFC に含める必要があります。 RFC には、RFC に添付する関連ドキュメントの他に、URL や前提条件、順序、既知の競合、サポート技術情報の文書番号など、修正プログラム固有の詳細情報を記すためのフィールドを用意する必要があります。

他の RFC と同様に、修正プログラムの RFC も、審査プロセスにかかる時間に関するサービスレベルアグリーメント (SLA) に適合することになるでしょう。たとえば、セキュリティ修正プログラムの RFC には、このような修正プログラムの評価が迅速に行われない場合、組織に大きな損害を与える可能性があるので、エスカレーションなど、これに関連付けられている審査プロセスおよびサポートプロセスの応答時間が指定されている場合があります。

注意RFC は、セキュリティ更新インベントリツールおよび Microsoft Office 更新インベントリツールにより、適用可能であると特定された修正プログラムすべてに対して提出する必要があります。

また、すべての RFC について、修正プログラムが適用されるコンピュータを特定する Web レポートを生成します。このとき、Web レポートでは、コンピュータの物理的な配置場所およびハードウェアの種類 (ラップトップ、デスクトップ、サーバーなど) を特定するようにします。

注意『Microsoft Systems Management Server を使用した修正プログラム管理 - アーキテクチャガイド』では、ハードウェアの種類やコンピュータの場所についての情報を SMS データベースに追加する方法が記載されています。

修正プログラムを展開する上で、他の修正プログラムとの依存関係がある場合は、このことを RFC に明示し、その修正プログラムがリリース管理の段階でリンクされるようにします。

依存関係にあると判断された修正プログラムはすべて、可能であれば、1 つの RFC にまとめて提出するようにします。依存関係にある修正プログラムが、最初に適用される修正プログラムを必要とするコンピュータ以外のコンピュータにも展開される必要がある場合は、これらの追加のコンピュータを明示する別個のレポートを生成します。

たとえば、ある Exchange 用の修正プログラムの要件として、Windows 2000 Service Pack 2 が Exchange サーバーにインストールされている必要があるとします。この場合、Exchange サーバーにだけでなく、すべての Windows 2000 コンピュータに SP2 を展開した場合の影響を示す個別のレポートが必要になるでしょう。

変更分類

修正プログラム管理の変更の開始者は、他の任意の変更と同様に、RFC を提出する作業の一環として、修正プログラムの優先順位とカテゴリを割り当てる必要があります。

割り当てられる可能性がある優先順位とカテゴリの例をいくつか以下に挙げます。

例 1: セキュリティベースの修正プログラムや、深刻な問題を解決する修正プログラムには、緊急優先順位を設定します。

例 2: Microsoft から発行されるセキュリティ修正プログラムは、自動的に高い優先順位を割り当てます。ただし、カテゴリについては、組織のガイドラインに従って個別に判断します。

例 3: 多くのクライアントに適用されている、試用され、信頼されている修正プログラムは、標準カテゴリに分類されます。プラグアンドプレイの更新など、新しいパーソナルコンピュータにこの修正プログラムを適用することは、標準変更となるでしょう。

注意初めて展開される修正プログラムは決して標準変更として扱ってはなりません。

変更の分類も、変更によるインフラストラクチャへの影響を考慮して、検討する必要があります。コンピュータの再起動が必要な修正プログラムは、再起動を必要としない修正プログラムよりも、大きな影響を与えるでしょう。

修正プログラムは、適用するコンピュータの種類によって、異なる分類に割り当てられる場合もあります。たとえば、再起動が必要な修正プログラムは、サーバーではある程度の稼働時間を犠牲にする必要があるので重大な影響がありますが、ユーザーのワークステーションに同じ修正プログラムを適用しても、ワークステーションは毎日再起動されるので最小限の影響しかありません。サーバーの種類によって受ける影響は異なるので、サーバーの中でもカテゴリは異なる場合があります。たとえば、高可用性が要求される基幹サービスを提供するサーバーと、毎週実行されるバッチサービスを提供するサーバーとでは、受ける影響が異なります。このような分類が行われる場合は、修正プログラムを複数の変更要求に分割し、影響を受けるコンピュータの分類ごとに個別に処理する必要があります。注意変更マネージャは要求に優先順位を割り当てる場合、SMS データベースをクエリし、修正プログラムをインストールする必要があるコンピュータの台数と、これらのコンピュータにカスタムの修正プログラムがインストールされているかどうかを確認します。

変更の開始者のレポートには、変更マネージャが必要とするすべての情報が含まれている必要があります。ただし、変更マネージャは、SMS Web レポートツールを使用して、追加の、おそらく極めてより詳細なレポートを生成することができます。すべての Windows 2000 Service Pack 2 コンピュータを展開の対象とし、特に再起動が必要となるような 1 つ以上の修正プログラムを必要とする変更が提出された場合、影響を受けるサーバーシステムを特定しておくことが重要になります。これらのサーバーをドメインコントローラやファイルおよびプリントサーバーなどの役割ごとに分類することによっても、変更による影響をより明確にできます。

このような分析により、変更マネージャは修正プログラムにコンピュータの種類によって異なる優先順位とカテゴリを割り当てる必要があるかどうかを判断できます。コンピュータの中には、他のコンピュータよりもビジネス上の重要度が高いと見なされるものがある場合もあるので、それぞれの状況ごとに個別の RFC を作成する方が、RFC に個別にカテゴリおよび優先順位を割り当てられるので適している場合があります。

変更認可

修正プログラムのための変更の認可は、標準の変更の認可と変わりませんが、修正プログラムの RFC には、さらにその他の考慮点があります。それらは以下のとおりです。

RFC のカテゴリと優先順位は共に、認可プロセスで検討されます。
標準変更は、事前承認済みです。したがって、修正プログラムの RFC の場合は、問題の修正プログラムが既にテストされ、展開されていることを確認する必要があります。この分類の変更は、通常、変更諮問委員会 (CAB) により事前に承認されています。
軽微な変更に分類された変更はすべて、変更マネージャにより承認されます。
修正プログラム RFC の中には、常に CAB による承認が必要なものもあります。これには、セキュリティ変更や、重大な影響を持つ可能性がある修正プログラムなどが含まれます。
修正プログラムの RFC および関連ドキュメントは、変更管理システム内に保管します。ただし、修正プログラムファイルは、検疫後はセキュリティで保護された記憶域に保管します。この変更管理システムとセキュリティで保護された記憶域の間にはリンクを設定する必要がありますが、検疫が済んだら、元のファイルを汚染されない状態に維持することが重要になります。

軽微な変更であっても、ある程度の経済的な妥当性の検討を行う必要があるでしょう。たとえば、ライセンス契約の内容を確認したり、脅威分析 (修正プログラムを展開しなかった場合のコストと展開した場合のコストの比較) を実行したり、変更の開始者によって最初に実行された影響の分析を拡張および確認したり、この修正プログラムに適した期限を考慮したり、CMDB を参照して目標を確認したりします。

意思決定を支援するために、変更マネージャは RFC 承認 Web フォームのリンクを使用して、サポートドキュメントの RFC の共有ポイントにアクセスできます。これには、修正プログラム RFC を検討する場合に、関連するサポート技術情報や URL リンクを参照したり、Microsoft Outlookｮを使用して現在の変更スケジュールを確認することが含まれます。

CAB が認可する変更

修正プログラムによって必要とされる変更が深刻なまたは重大な変更の場合、RFC は変更諮問委員会 (CAB) により承認される必要があります。

変更マネージャにより認可された変更と同じく、RFC および関連ドキュメントは変更管理システムに保管します。ただし、変更管理システムには、修正プログラムファイルの検疫後の保管先であるセキュリティで保護された記憶域に保管されている修正プログラムファイルへのリンクを設定しておくようにします。

CAB メンバは、経済的な妥当性の検討を考慮および支援する必要があります。これには、ライセンス契約の内容を確認したり、脅威分析 (修正プログラムを展開しなかった場合のコストと展開した場合のコストの比較) を実行したり、変更の開始者によって最初に実行された影響の分析を拡張および確認したり、この修正プログラムに適した期限を考慮したり、CMDB を参照して対象とする取得物を確認したりする作業が含まれます。

CAB/EC による認可済みの変更

修正プログラムの RFC が緊急の変更である場合は、CAB 緊急委員会 (CAB/EC) による認可が必要になります。メンバに保留中の緊急 RFC を早急に通知できることが重要になります。これには、レビュー対象の RFC の緊急性や潜在的な影響に応じて、電子メールが利用されることも、人的な通知 (電話または直接) が利用されることもあります。

CAB/EC のメンバは、経済的な妥当性の検討を考慮および支援する必要があります。これには、ライセンス契約の内容を確認したり、脅威分析 (修正プログラムを展開しなかった場合のコストと展開した場合のコストの比較) を実行したり、変更の開始者によって最初に実行された影響の分析を拡張および確認したり、この RFC に適した期限を考慮したり、対象とする取得物を確認したりする作業が含まれます。

注意いったん RFC が変更の承認プロセスに達した後は、変更マネージャ、CAB、または CAB/EC のいずれが承認を行うにしても、使用するテクノロジは同じです。

まず、承認者は、変更の分類プロセスにより提供されたレポートと情報をレビューし、提供された情報が十分であるかどうか、ビジネスケースが変更を進めるられるほど十分に堅牢であるかどうかを判断します。たとえば、図 17 に示すように、SMS サイトサーバーと配布ポイントの場所を把握し、公開をサポートするのに十分なディスク空き容量があるかどうかを判断することが役に立ちます。

図 17: SMS を使用した各サイト内の配布ポイントの特定

変更の承認に先立ち、承認を行う担当者またはグループは、要求された修正プログラムが、今後 Service Pack が展開される際に冗長にならないことを確認する必要があります。 Service Pack がすぐに提供される予定がある場合は、Service Pack では再現テストが実施されているので、Service Pack のリリースを待つことがおそらく最適であると言えます。ただし、修正プログラムの展開が非常に重要であると考えられる場合は、Service Pack のリリースを待つことはできません。このような情報については、RFC に含めるようにします。

変更開発

修正プログラムの RFC のスケジュールを設定するときは、他の RFC の事前定義されたスケジュール設定プロセスに加えて、相互依存関係のある変更、順序、前提条件、競合を考慮することが重要になります。変更のスケジュールを設定する際は、パイプライン内の既存の修正プログラムに影響を与える可能性のある変更についても、考慮する必要があります。

RFC のスケジュールが設定されたら、担当者が指名され、この情報が RFC Web フォームを使用して記録されます。理想的には、変更の担当者には、関連するテクノロジストリームのメンバであり、関係のあるテクノロジの理解があるメンバを指名します。

修正プログラムが変更開発プロセスを完了したら、新しい構成アイテム (CI) を作成し、これを CMDB に登録します。確定版ソフトウェアの保管庫 (DSL) を更新して、"Test" というステータスを設定する必要があります。これは、変更がまだ完全にテストされておらず、信頼できないので、これが重要な作業になります。また、CI とサポート技術情報の文書番号および DSL の場所との間にリンクを設定し、CMDB に格納しておく必要があります。

注意Microsoft から提供される修正プログラムのほとんどは、すぐにインストールが可能な .exe ファイルの形式で提供されます。この .exe ファイルにより、展開先のプラットフォームの必要なレジストリキーが更新され、認識が可能になります。ただし、その他の修正プログラムの場合、ファイル、レジストリの変更、およびその他の構成変更をインストール可能な形式で、SMS を使用して展開できる形式にパッケージ化するための開発作業が必要なものもあります。

修正プログラムに添付されているドキュメントを使用して、.exe ファイルによって正しいファイルがインストールされ、その他の必要な変更が行われることを確認します。カスタム修正プログラムは、『Microsoft Systems Management Server を使用した修正プログラム管理 - アーキテクチャガイド』で説明されているように、レジストリに適切な変更を行ってその修正プログラムが特定されるようにします。

リリース中に、複数の修正プログラムが同時に展開される可能性があります。リリースの組み合わせについては、本書の「リリースの計画」で取り上げています。要約すると、ソフトウェア更新の配布ウィザードを使用して配布される修正プログラムの場合、複数の修正プログラムを処理できるようにするには追加の作業が必要になります。ウィザードの一部として展開される修正プログラムインストールエージェントにより、自動再起動などの問題が処理されます。このウィザードを利用しない場合は、他のすべてのセキュリティ修正プログラムおよび QFE 修正プログラムで、複数の修正プログラムを互いに悪影響を与えることなく、また何度も再起動を必要とすることなくインストールできるようにするために、さらに開発作業が必要になります。

ソフトウェア更新の配布ウィザードの機能には、アンインストールメカニズムは含まれていません。このような修正プログラムをアンインストールするには、削除用に修正プログラムによって定義されるプログラムを提供し、クライアントコンピュータ上で実行する必要があります。 Micorosoft の修正プログラムの大部分には、修正プログラムをアンインストールするための "-y" または "/y" フラグが用意されています。

リリース管理

リリース管理は、承認された変更 (修正プログラム管理の場合は、修正プログラムや Service Pack) を IT 環境に展開するプロセスです。このプロセスの目的は、環境への影響を最小限に抑えながら、実稼動環境にすべての変更を首尾よく適用することです。つまり、各リリースの準備状態を判断する主要な責務を担います。

図 18 のプロセスフローチャートでは、 IT インフラストラクチャに承認済みのリリースを適切に計画および展開するために必要な作業の概要が示されています。修正プログラム管理の場合は、Service Pack および QFE 修正プログラムの実稼働環境への展開も含まれます。

図 18: リリース管理のプロセスフローチャート

図 18: リリース管理のプロセスフローチャート

本書では、ほとんどの場合、リリース管理プロセスの概要しか取り上げていません。リリース管理の詳細については、https://www.microsoft.com/solutions/msm/techinfo/default.asp (英語) を参照するか、https://www.microsoft.com/japan/technet/default.mspx の TechNet サイトで関連ドキュメントを検索してください。

以下のセクションでは、図 18 で示すリリース管理プロセスを説明します。

リリース計画

通常、修正プログラムのリリースを計画する場合は、リリース管理 SMF ガイドの推奨事項に従います。このような推奨事項に加えて、次のような特定の事項も考慮する必要があります。

何がリリースされ、リリース先はどこか、リリースの期限はどのようなものであり、これはなぜ重要か、といった重要な問題を解決します。ただし、これらの問題の一部は、RFC の認可時に行われた作業により、すでに答えが出ているでしょう。
修正プログラム管理のリリースの範囲設定には以下の項目を含める必要があります。
- 修正管理プログラムのサイズ。これはサイズが直接リリースパッケージの展開に影響するためです。
- 修正プログラムの優先順位。これは、展開の速度に影響するためです。
- ビジネスの優先順位。これは IT インフラストラクチャへの修正プログラムの展開に直接影響する可能性があります。

場合によっては、組織の運用上の理由で、修正プログラムの展開に伴う停止時間が許されないので、修正プログラムを展開できないこともあります。このような組織の例としては、24 時間体制で運用を行っている組織やロックダウンされた環境を使用している組織などが挙げられます。また、リモートクライアント状態への展開には、より詳細な計画を立てる必要があります。これは、モバイルクライアント (販売チームや遠隔地にいる従業員) は、会社のネットワークに恒常的にアクセスしていない可能性があるためです。

修正プログラムを展開しなかったことにより発生する組織にとってのリスクを特定するために、脅威分析を実行します。リスクが特定されたら、これをビジネスの優先順位を考慮しながら検討できます。
必要なリソース、影響、ビジネスの停止時間を最小限にとどめるため、複数の修正プログラムを組み合わせて 1 つのリリース計画にまとめることができるかどうかを判断します。これは、パイプライン分析によって判断できます。前提条件が指定されている修正プログラムは、可能性のある競合を回避するために展開順序を決める必要があるので、場合によっては、パイプライン分析が必須になります。たとえば、リリース間近の 2 つの修正プログラムがある場合、同時に展開できるでしょうか? 脅威分析は検証されたでしょうか? 個別の修正プログラム (Hotfix) と同じ効果があり、これらを展開する必要性を排除できる、Service Pack がリリースされる予定はあるでしょうか?
リリースの計画では、スケジュール設定に影響する条件を特定する必要があります。たとえば、特定のビジネス条件、変更の一時停止、24 時間体制の運用などは、計画の期間に影響する可能性があります。また、ユーザーのトレーニングや実稼働環境でのテストについても、考慮する事項があります。
リリースの管理者は、アンインストールができない場合に組織にもたらされる脅威の分析も含めて、完全な取り消し計画のドキュメントを作成する必要があります。簡単にアンインストールできる場合は、組織に対する脅威は低いと言えます。アンインストールまたはロールバックが不可能な場合は、組織に対する脅威は高く、修正プログラムをインストールすることによる利点と比較検討する必要があります。このような場合は、バックアップメディアからの復元も含め、代替のロールバック方法を開発する必要があります。

注意以下のリリース計画の中間段階では、SMS の利用方法の詳細に注目しています。

リリースの範囲設定

リリースの範囲を設定するには、環境に展開されているものについての正確で最新の知識が必要になります。ソフトウェアとハードウェアのインベントリエージェントで対象のコンピュータからデータを最後に収集した日時を確認するには、Web レポートを使用してクライアントのステータスメッセージを調査します。

これが最新ではない場合、管理者は強制的にクライアントにインベントリサイクルを実行させる SMS の提供情報を作成し、Web レポートをチェックすることによってインベントリの進捗状況を追跡する必要があります。

リリースマネージャが SMS データベースの情報が最新であると確認したら、変更プロセス中に作成した SMS レポートや情報を使用できます。また追加のレポートを構築して、リリースプロジェクトの規模についてのより正確なイメージを得ることもできます。

リリースマネージャは、リリースの計画段階中に、次の条件にあてはまるコンピュータを特定する必要があります。

修正プログラムの適用対象のオペレーティングシステムまたはアプリケーションが実行されているコンピュータ。
修正プログラムの適用対象のバージョンのソフトウェア (またはハードウェア) が実行されているコンピュータ。

注意修正プログラム配布ウィザードでは、修正プログラムを必要とするコンピュータにしか、修正プログラムがインストールされないので、上記の点は、修正プログラム配布ウィザードを利用して展開される修正プログラムには当てはまりません。

たとえば、SMS ハードウェアインベントリがシステムに収容されているもの詳細を取得するように変更されていた場合、リリースマネージャは、修正プログラムをインストールするコンピュータの種類を示すカスタムレポートを作成する必要もあります。この情報は、ポータブルコンピュータやリモートクライアントには、LAN に接続されているデスクトップコンピュータとは異なる配布方法やインストール方法が必要になる可能性があるので、リリースの計画段階では非常に重要になります。

また、リリースマネージャは、SMS データベース内の情報を使用して、SMS サイトにレポートするコンピュータ数、または特定のインターネットプロトコル (IP) サブネットに割り当てられているコンピュータの数を判断できます。この情報は、パイロットサイトの選定や最適な公開順序の決定に役立ちます。

リリースの定義と優先順位の設定

ソフトウェア更新の配布ウィザードにより配布された修正プログラムは、通常、1 つの提供情報内のクライアントを対象にします。これにより、同時にインストールされる修正プログラムの数にかかわりなく、再起動が一度だけで済むようになります。

注意クライアントでは、任意の修正プログラムをインストールする前に適切なインベントリ更新ツール (セキュリティ修正プログラムまたは Microsoft Office 用) が実行され、これにより適用可能であると認識された修正プログラムのみがインストールされます。

新しい Windows XP ワークステーションがネットワークに追加された場合は、さまざまなセキュリティ修正プログラムを含む提供情報が配信される可能性があります。ただし、このワークステーションでは、ワークステーションにインストールされているソフトウェアに適した修正プログラムのみがインストールされます。これらの修正プログラムのうち、複数で再起動が必要とされている場合でも、インストールの完了に必要な再起動は 1 回だけで済みます。

また、変更管理プロセスから短期間のうちに修正プログラム関係の変更が多数受け渡される可能性があるので、承認済みの QFE 修正プログラムをいくつか組み合わせて、1 つのリリースにまとめることをお勧めします。承認済みの修正プログラムを組み合わせる際の基準は、以下のとおりです。

リリースマネージャは、適用対象のクライアントのセットが同じである場合のみ、修正プログラムを組み合わせる必要があります。たとえば、Windows XP を使用しているコンピュータすべてに適用される一般的な Windows XP の修正プログラムは、ラップトップコンピュータのみを対象とする修正プログラムと組み合わせることはできません。
重要な修正プログラムとあまり重要ではない修正プログラムを組み合わせて同じリリースにまとめないでください。重要でない修正プログラムをロールバックする必要が発生した場合、リリースのロールバックメカニズムにより、重要な修正プログラムも自動的にアンインストールされてしまいます。

複数の修正プログラムを 1 リリースで展開する場合に考慮すべき点は、以下のとおりです。

修正プログラム同士が競合する可能性があります。たとえば、複数の修正プログラムによって、同じファイルが更新されるとします。この場合、特にカスタム修正プログラムを展開する場合は、修正プログラムが適切な順序で適用され、新しく加えられた変更が古いファイルによって上書きされないようにすることが重要です。 Microsoft から提供される修正プログラム用のインストールプログラムは、既定で新しいファイルが上書きされないようになっています。
それぞれの修正プログラムで、コンピュータの再起動が必要とされている場合があります。中断する回数を最小限にするために、この場合 1 回の再起動で済むようにします。 SP3 よりも前の Windows 2000 コンピュータに複数の QFE 修正プログラムをインストールする場合は、Qchain.exe ツールを使用します。 Windows XP および Windows 2000 SP3 (以降) コンピュータには、Qchain.exe プログラムは必要ありません。入手方法も含め、Qchain.exe の詳細については、サポート技術情報の 296861 「複数の Windows Update または修正プログラムを同時にインストールし、再起動を 1 回で済ませる方法」を参照してください。

修正プログラムをアンインストールできない場合は、このことをドキュメント化する必要があります。このような場合は、変更のロールバックメカニズムは、Microsoft Windows Installer (MSI) など、変更の実装に使用されたテクノロジに基づきません。代わりに、その他のメカニズム、通常はより複雑または時間のかかるメカニズムを採用する必要があります。これには、変更の実装前のコンピュータのハードディスクイメージを取ることが挙げられます。これにより、修正プログラムをロールバックする必要が発生した場合でも、コンピュータに元のイメージを復元できます。

リリースの構築

リリース計画が合意されれば、リリースチームのメンバは、リリースを運用環境に展開するためのプロセス、ツール、必要なテクノロジの開発を始めることができます。このプロセスの実行中に、リリースメカニズムの選択、リリースパッケージのデザイン、構築、およびテストを行う必要があります。

選択するリリースメカニズムによって、リリースの展開に必要な作業が決まります。このメカニズムは、少なくとも、設定されているベースラインを満たすことができる必要があります。また、このメカニズムでは、状態を最新に保つことができ、計画された複数のイメージ更新の間に追加された新しいコンピュータを考慮した、最も効果的な方法で更新を配信する必要があります。

関係する変更の種類により、選択される可能性があるリリースメカニズムがいくつかあります。たとえば、バッチファイルおよびレジストリの変更は、MSI ファイルまたは SMS インストーラプログラムによる処理が可能です。 SMS は、配布メカニズムとしても使用できます。場合によっては、特に同時に展開する変更が多数ある場合は、展開イメージを使用した方が効果的な場合があります。これらの変更を 1 イメージで展開する方が、経済的で賢明と言えるでしょう。

イメージを構築し、新たに設定されるベースラインに対するバックアップとしてイメージを定期的に更新することも重要です。計画された複数のイメージ更新の間に状態に導入されたコンピュータについては、(イメージに最新の修正プログラムが含まれていない可能性がある場合) 修正プログラム管理プロセスを利用してこれらのコンピュータを現在のベースラインレベルまでアップグレードする必要があります。

リリースパッケージのビルド中に、MSI のオーサリングツールを使用して、MSI ファイルおよび MSI カスタマイズファイルを作成する必要があります。 SMS では、修正プログラムの配布に、バッチファイル、.msi ファイル、または実行可能ファイルが必要です。ただし、場合によっては、実行可能ファイルを利用できないことがあるので、SMS により配布が実行される場合は、MSI ファイルまたはバッチファイルを開発する必要があります。

リリースパッケージが作成され、完全にテストされたら、構成アイテム (CI) を作成し、これを CMDB に登録します。リリースパッケージは、確定版ソフトウェアの保管庫 (DSL) に格納し、ステータスに "Test" を設定します。元の情報は、最初の通知とのリンクの整合性が確保されるように、CMDB 内で相互参照される必要があります。

注意以下のリリース開発の中間段階では、SMS の利用方法の詳細に注目しています。

リリースメカニズムの選択

リリース管理チームは、変更の開発チームから提供されたファイルを受け取り、これを実稼働環境に展開することを担当します。チームのメンバは、クライアント数、クライアントの種類、クライアントの場所、ネットワーク接続の速度と可用性から、この展開の最適な実行方法を判断します。

Service Pack のような大きな修正プログラムを、低速の断続的なダイヤルアップリンク経由でネットワークに接続しているポータブルコンピュータなどのモバイルクライアントに展開する場合は、問題が発生する可能性があることを認識しておく必要があります。ダイアルアップ接続の場合、インストールの完了には数時間かかることがあります。また、接続が中断した場合、インストールが突然失敗することがあります。

これを回避するための好ましい方法は、対象となるポータブルコンピュータをネットワーク接続が確保されているオフィスに持参し、SMS のローカル配布ポイントから信頼できる、高速のネットワーク経由で、素早く修正プログラムを展開できるようにする方法です。この場合、保留されているその他のアプリケーションのインストールも、同時に行う機会も得られます。

しかし、この方法を常に実行できるとは限りません。ユーザーが事務所を訪れることがほとんどない場合や、オフィスからかなり離れた場所にいるので、オフィスを訪問することがユーザーの生産性に悪影響を及ぼす可能性がある場合もあります。会社のネットワークへの高速接続を確立する方法が考えられない場合は、修正プログラムを CD-ROM に書き込み、この CD-ROM を関係のあるクライアントコンピュータの所有者に送付します。次に、SMS パッケージラッパーに、通常の配布ポイントの代わりに CD-ROM からセットアッププログラムを実行することを記述します。

ラッパープログラムまたはスクリプトは、最初に CD-ROM の存在を確認し、必要に応じて CD-ROM の挿入を求める問い合わせを行う必要があります。ラッパープログラムは極めて小さくする必要があり、このラッパープログラムのみが SMS 経由で配布されます。低速のダイアルアップ接続経由で送信されるデータが極めて少量だとしても、依然として修正プログラムは SMS を使用して配布され、インストール結果 (成功/失敗) に関するステータスメッセージが収集されます。

この手法では、正しいステータスメッセージが送信されることを確認することが重要です。ステータスメッセージでは、ラッパープログラムが正常に実行されたかどうかではなく、修正プログラムのインストールが成功したかどうかが示される必要があります。このことは、ラッパープログラムが実行されるときに、ユーザーが CD-ROM を利用できない可能性により、さらに複雑になります。これは、操作の停止につながります。このような場合は、ステータスとして "failed" を返す必要があります。また、提供情報は再試行するように設定されるので、提供情報は後日再実行されます。詳細については、本書の後半の「公開の準備」を参照してください。

図 19 は、リモートユーザーのコンピュータに表示される画面を示しています。この画面により、リモートユーザーが受け取る必要のある CD-ROM の存在とインストールが通知されます。

図 19: リモート クライアント用のラッパー プログラムの使用

この CD-ROM による手法を使用できない場合、管理者は長時間のダイアルアップ接続による影響にかかわらず、修正プログラムをネットワーク経由で配布することを決断することになります。この手法を採用する場合、ユーザーに各自のダイアルアップ接続は特定の期間その他の目的に使用できないことと、インストール中は接続を切断してはいけないことを通知するラッパーを添えて、パッケージを再度パッケージ化する必要があります。

どのような場合でも、ラップトップと他のリモート接続コンピュータに対して異なる配布メカニズムやインストールメカニズムを使用する場合は、これらのコンピュータを対象とする SMS コレクションをそれぞれ作成する必要があります。詳細については、本書の後半の「公開の計画」を参照してください。

直接的であれ、間接的であれ、コンピュータが会社のネットワークに高速ブロードバンドインターネット接続や VPN 経由で接続されている場合は、修正プログラムのリリース、配布、およびインストールのメカニズムには、SMS Software Update Services Feature Pack のソフトウェア更新の配布ウィザードを選択します。ソフトウェア更新の配布ウィザード自体によりメカニズムが事前定義されているため、リリースプロセスにおいて追加のデザインは必要ありません。

リリースパッケージのデザイン

リリースパッケージのデザインプロセスには、変更の開発段階の成果物 (通常は、.exe ファイル) の引継ぎ、クライアントコンピュータへの修正プログラムの展開に使用する SMS パッケージおよびプログラムの作成が含まれます。したがって、この段階では、クライアント上で実行される .exe ファイルや .msi ファイルのビルドや、必要なファイルのインストールは行われません。

リリースパッケージのデザインとビルドに必要な作業の手順および作業量は、修正プログラムの展開に使用するメカニズムと、カスタム修正プログラムが展開されるかどうかによって決まります。以下に検討するオプションを挙げます。

SMS Software Update Services Feature Pack のソフトウェア更新の配布ウィザードの使用。
Microsoft のダウンロード Web サイトから直接ダウンロードした .exe ファイルの使用。
社内で専用の実行可能ファイルまたは .msi ファイルを開発したカスタム修正プログラムの使用。

すべての展開メカニズムの共通注意事項

大部分の修正プログラムは、ローカル管理者のコンテキストでインストールする必要があります。パッケージ作成自体に影響することはあまり考えられませんが、HKEY_CURRENT_USER レジストリハイブやある特定のユーザーの Documents and Settings フォルダ内のものなど、ユーザー固有の設定は使用しないように注意します。 SMS プログラムを作成するときは、ユーザーが修正プログラムのインストール時にログオンしていても、管理コンテキストで実行されるように指定できます。

通常、修正プログラムのインストール時に、インストール先のコンピュータにユーザーがログオンしている必要はありません。修正プログラムのインストール時にユーザーがログオンしている場合、インストールのためにコンピュータのパフォーマンスが影響を受けたり、アプリケーションを閉じるよう要求されたり、インストールの終了時には再起動が必要になることがあります。これらはすべて、デザイン時に考慮される必要があります。修正プログラムの緊急性にもよりますが、ユーザーがログオンしていないときにのみインストールを実行することをお勧めします。

ユーザーがコンピュータにログオンしているときに修正プログラムをインストールする場合に、このインストールにより応答の遅延など悪影響が発生することが考えられるときは、プログラムによりユーザーにこのことが通知される必要があります。悪影響が発生しない場合は、インストールを非表示インストールにします。こうすることで、ユーザーがオプションを選択する必要がなくなり、「[OK] をクリックして続行してください。」といった無意味なダイアログボックスが表示されないようになります。

修正プログラムのインストールが成功したかどうかを正確に特定するには、インベントリを再度実行し、SMS クエリを使用して修正プログラムが適用されたファイルや関連するレジストリの変更を確認します。このために、修正プログラムのインストールに続いて、SMS インベントリが強制的に実行されることが望ましい場合があります。ソフトウェア更新の配布ウィザードを使用する場合は、修正プログラムのインストールの一環としてインベントリの操作を含めることができます。これについては、以下の「展開は成功したか?」に詳細を示します。

ソフトウェア更新の配布ウィザードを使用しない場合は、SMS クライアントで次のプログラムを実行することで、インベントリを実行できます。

cliutils.exe /START "Hardware Inventory Agent" 
cliutils.exe /START "Software Inventory Agent"

Cliutils.exe ツールは、Microsoft BackOfficeｮのリソースキットで提供されています。

カスタムビルド修正プログラムの注意事項

カスタム修正プログラムが社内でビルドされているとき、または修正プログラムの実行可能ファイル自体によって適切な終了コードや再起動などの問題が自動的に処理されない実行可能ファイルが配布された場合、SMS パッケージを作成する際に、さらに多くの点について考慮する必要があります。

修正プログラムをインストールするために実行されるプログラムはすべて、適切な終了コードを返す必要があります。その結果、SMS ステータスシステムにより正しいステータスが返されます。終了コードは、インストールが成功した場合は 0、失敗した場合は 0 以外の値にします。このリターンコードは、SMS ステータスシステムによって使用され、提供情報の成功または失敗が示されます。

実行されるプログラムは、インストールが完了するまでは終了できません。 SMS では、提供情報に関連付けられているプログラムが終了した時点で、提供情報の実行が完了したものと見なされます。プログラムが別のプロセスを生成し、この新しいプロセスにより修正プログラムのインストールが完了される前にプログラムが終了した場合、プログラムはインストールの成否を示す適切な終了コードを返すことができません。また、プログラムはインストールが完了する前にステータスを報告することになるでしょう。

パッケージには、SMS 提供情報を利用して修正プログラムをアンインストールできるように、アンインストールコマンドラインオプションが実装されている必要があります。これが実装されていない場合は、変更開発チームにパッケージを返し、この機能を実装するようにします。

再パッケージ化した修正プログラム (Hotfix) に再起動処理を含める場合は、修正プログラムのインストール時にユーザーがコンピュータにログオンしていないかどうか、ユーザーの作業を止めることが可能であるかどうかを検討する必要があります。コンピュータを再起動する必要がある場合は、再パッケージ化したプログラムにより、またはプログラムの詳細が定義されている場合は SMS により、再起動できます。実行するプログラムが、インストールプロセスが完了する前に終了するようにデザインされている場合は、SMS を使用した再起動は行わないようにします。これは、インストールが完了した時点ではなく、プログラムが終了した時点で、SMS が再起動を行ってしまうためです。

Microsoft からダウンロードした修正プログラムの実行ファイルに関する注意事項

Microsoft の Web サイトからダウンロードしたた Qxxxxxx.exe 形式の修正プログラムでは、カスタム修正プログラムの作成時に考慮する必要があった機能の多くが既に含まれています。この実行可能ファイルから返されるリターンコードでは、インストールステータスが正しく反映されます。

また、このような修正プログラムでは、修正プログラムのインストールを完了するためにシステムの再起動が必要な場合、再起動が自動的に実行されます。

単一の修正プログラム、または修正プログラムを複数を組み合わせたリリースパッケージをデザインするときは、再起動要件を検討する必要があります。再起動回数を削減する方法は、単一のリリースでまとめて複数の修正プログラムを展開する場合で既に説明しました。修正プログラムのインストール後に再起動が必要な場合は、次のようなさまざまな方法でこれを実現できます。

Q162532.exe などの修正プログラムによる再起動の実行を許可します。
複数の修正プログラムを連鎖して展開する場合は、Shutdown.exe のようなコンピュータを再起動するプログラムを呼び出すか、インストールプログラムから再起動を実行します。
プログラムのプロパティの設定時に SMS により再起動を実行させます。
何もしません。

最初の 2 つの方法では、プログラムにより再起動が実行されることを示すように、プログラムのプロパティを設定する必要があります。

3 番目の方法では、SMS に再起動を実行させるようにプログラムのプロパティを設定する必要があります。

最後の方法は、提供情報が必須ではないシナリオでのみ使用されます。したがって、この場合は、サーバーコンピュータにログオンしている管理者により、再起動が実行される必要があります。修正プログラムのインストールが完了したら、管理者が手動でコンピュータを再起動します。これは、Microsoft クラスタサービスクラスタに修正プログラムを適用する場合など、インストールの順序が重要で、問題が発生した場合に介入できるオペレータによってプロセスを監視できる場合が該当します。

ソフトウェア更新の配布ウィザードを使用する場合

ソフトウェア更新の配布ウィザードにより、このメカニズムを利用して展開可能な修正プログラムのための SMS パッケージを作成する場合、必要な作業の大部分を省略できます。 SMS Software Update Services Feature Pack のツールによって、修正プログラムの配布に使用する SMS パッケージおよびプログラムが自動的に作成されます。また、同じパッケージにインストールの承認を得ている新しい修正プログラムがダウンロードされるので、パッケージが自動的に最新状態に保たれます。

注意1 つのパッケージを使用して複数の重要なセキュリティ修正プログラムを配布していて、新しい修正プログラムが認識されるのに合わせてこのパッケージが定期的に更新される場合、SMS 2.0 では、新しく承認された修正プログラムだけでなく、すべての修正プログラムを配布サーバーに配布します。

新しい修正プログラムをインストールにこの "迅速な" プログラムを使用した場合、SMS インベントリに新しくインストールされた修正プログラムができるだけ早く反映されるように、修正プログラムのインストールに続いてインベントリプロセスが開始されます。

SMS クライアントでは、修正プログラムインストールエージェントにより、再起動が処理されます。ソフトウェア更新の配布ウィザードを実行し、修正プログラムインストールエージェント設定を設定する場合は、サーバーに対してのみ再起動を強制的に実行したり、ワークステーションに対してのみ実行したり、または再起動が実行されないようにできます。

リリースパッケージのビルド

インストールプログラムを実行する前に、追加の検査を実行する必要があるので、場合によっては、修正プログラムの再パッケージ化が必要になることがあります。このような検査は、たとえば、SMS インストーラ実行可能ファイル内で実行される必要があります。このような検査によって、修正プログラムをインストールできないと判断された場合は、プログラムを終了し、適切な終了コードを返して、SMS ステータスシステムによってインストールが失敗したことが検出されるようにする必要があります。ただし、SMS を使用して失敗した理由を返すことはできません。

Microsoft Operations Manager (MOM) を使用して監視されているサーバーの場合は、イベントログにイベントを書き込むことができ、MOM コンソールで、イベントに対して警告を生成するためのルールを作成できます。こうすることで、失敗の理由を確認できるようになります。 MOM により管理されていないワークステーションについても、イベントをイベントログに書き込むことはできますが、失敗したコンピュータ上のイベントログを管理者が調査する必要があります。

1 回のリリースで複数の修正プログラムがインストールされる場合に、これらの修正プログラムが単に連続して実行される必要がある一連の .exe ファイルである場合は、1 つの SMS インストーラ実行可能ファイルにまとめたり、単純なバッチファイル (.bat) として実行できます。 .bat ファイルを実行する場合は、インストール先のコンピュータで SMS 配布ポイント共有をドライブ記号を使用してマウントできる必要があります。また、必要な SMS プログラムのプロパティの設定を行う必要があります。 SMS プログラムのプロパティの [ 環境 ] タブで、[ ドライブ名を要求する ] または [ 指定ドライブ名を要求する ] を選択する必要があります。

バッチファイルを使用するときは、バッチプログラム内部でエラーレベル変数を正しく使用し、各修正プログラムの実行可能ファイルの実行に合わせて、個別にインストールステータスを確認できるようにします。バッチファイルからは、インストールプロセス全体の成否を示す終了コードが返される必要があります。

修正プログラムの中には、修正プログラムのインストールプログラム自体の実行前に実行する必要がある、自己解凍型の .exe ファイルとして提供されているものもあります。この場合、ユーザーの選択した任意のフォルダにファイルを解凍し、ここから修正プログラムのインストールプログラムを実行します。このような場合、最初に実行するファイルの解凍作業は、すべてのエンドポイント上で実行する必要がある、修正プログラムのインストールプロセスの一部ではありません。これは、再パッケージ化プロセスの一環として行い、解凍したファイルは SMS パッケージのパッケージソースとして扱います。これにより、これ以上の再パッケージ化が必要なくなります。

修正プログラムが、既にインストールされている別の修正プログラムに依存する場合があります。この情報は、修正プログラムと合わせて提供されているドキュメントに注意深く目を通すことでしか取得できません。このような場合、リリースパッケージは、次のような方法で作成できます。

1 つのリリースに修正プログラムと依存する修正プログラムをまとめることができます。これにより、前述されているように、依存する修正プログラムが、既にインストールされているかどうかにかかわらず、依存する修正プログラムのインストールが強制的に実行されます。
依存する修正プログラムが SMS により展開されている場合、これを SMS 内で依存プログラムとして指定できます。これにより、修正プログラムは、依存する修正プログラムのインストールが SMS によって実行されない限り、インストールされなくなります。

リリースパッケージのテスト

受け入れテストを実施するためにパッケージをテストチームに渡す前に、単体テストを実施して基本機能を検証する必要があります。このテストには、以下の項目を含める必要があります。

非表示インストールやアンインストールなど、実稼動環境で使用するすべてのプログラムとコマンドラインによる、修正プログラムの基本インストールのテスト。
(同じパッケージを複数のオペレーティングシステムで実行する場合の) 異なるオペレーティングシステムでのテスト。
想定しているコンテキスト (ログオフした状態、管理者コンテキストなど) での SMS 提供情報内部からの修正プログラムインストールプログラムの実行。
終了コードが目的どおりで、SMS ステータスシステムが終了コードをレポートすることを確認するテスト。
アンインストールルーチンまたは削除ルーチンのテスト。

DSL へのパッケージのコピーの格納および CMDB の更新

インストールのテストが完了したら、ファイルをセキュリティで保護された、バージョン管理が実行されている場所に保管し、後日同じファイルを取得、認識、再使用できるようにします。 CMDB も、DSL に追加されるファイルの情報を使用して更新する必要があります。テストの完了後、ファイルはテスト環境からではなく、DSL から実稼働環境に取得されます。これにより、テストで使用されたものとまったく同じファイルが実稼働環境で使用されることになります。

図 20 に示すように、SMS Site Properties Manager 内から、テストを完了したパッケージに移動して、ショートカットメニューの [Export Selected Package] をクリックします。

図 20: パッケージのエクスポート

図 20: パッケージのエクスポート

これで、パッケージの詳細のすべてが保存されるようになります。配布ポイントおよびパッケージソースの詳細については、テスト時の SMS インフラストラクチャと実稼動環境での SMS インフラストラクチャに応じてそれぞれ異なるので、後で実行されるパッケージ情報のインポート時に変更する必要があります。

受け入れテスト

この時点までのテストの目的は、開発環境内でのリリースおよびリリースパッケージの正常な動作を確認することでした。開発者およびビジネスの代表者は、受け入れテストにより、実稼働環境を忠実にミラー化する環境で、リリースおよびリリースパッケージが共にどのように機能するかを確認できます。場合によっては、企業規模の公開に進むために必要な信用を築くために、パイロットテストが必要になることもあります。

リリースが実稼動環境に悪影響を与えないことを確認するには、各リリースのテストを実稼動環境を事実上モデル化した設備で実行する必要があります。

テスト環境は、実稼働環境に合わせて構築する必要がありますが、実稼動環境のベースラインよりもレベルの低いコンピュータが新たに追加されても、これに対処できるように構築されている必要もあります。たとえば、新しいコンピュータのビルドが修正プログラムを適用していない Windows XP で構成されている場合、リリースの展開メカニズムによって、ベースラインが現状よりも高いレベルであることが認識され、このベースラインに合うように必要な修正プログラムをすべてコンピュータにインストールできる必要があります。

テスト環境の構成は、バージョン管理の対象とし、CMDB に保存される必要があります。関連ドキュメントについても、組織の共有ポイントに格納し、参照されるようにします。

SMS で、たとえば Windows XP を実行しているコンピュータすべてを対象とする提供情報を設定する必要があります。新しい Windows XP コンピュータが追加されたときに、受け入れ済みのベースラインのレベルに合わせるための関連する修正プログラムが SMS により自動的にインストールされるようにします。

初期テストが正常に完了したら、CMDB および DSL の情報を更新します。

多くの場合、実稼働環境でのパイロットテストが必要になると考えられます。修正プログラムをアンインストールできないことにより、組織が直面する可能性のあるすべての脅威について、考慮する必要があります。単純なアンインストールが利用できない場合は、このパイロットテストが失敗した場合に、完全に復元を行えるように準備をしておく必要があります。

実稼働環境でのパイロットテストが正常に実行され、公開に向けて受け入れられた場合は、DSL を更新して修正プログラムが正常にテストされていることを示す必要があります。この場合、"trusted" など、実稼働環境での使用が可能であることを示すステータスを割り当てるのが適切です。

注意以下の受け入れテストの中間段階では、SMS の利用方法の詳細に注目しています。

テスト環境のデザインとビルド

修正プログラムを適用するテスト用の SMS クライアントを設定したら、実稼働環境のクライアントの修正プログラムレベルに合うように、これらのクライアントを設定する必要があります。この情報については、CMDB から取得できます。実稼働環境の適用対象のコンピュータで修正プログラムレベルが異なっている場合は、これらすべてについてラボでテストをする必要があります。

テストラボの SMS 階層も、可能な限り、実稼働環境の SMS 階層に合わせるようにします。サイト階層は、特に実際の WAN (ワイドエリアネットワーク) リンクが低速の場合は、サイト間の WAN リンクをシミュレーションして構築します。低速で接続されているクライアントについても、同様にテストします。

テストの実施と結果の評価

管理者が SUS を使用した修正プログラムの展開をテストするときは、以下のシナリオを検討する必要があります。

修正プログラムがインストールされていない新規コンピュータをネットワークに追加する場合。 SMS インベントリが問題のコンピュータに対して最初に実行される際に、必要な修正プログラムがこのコンピュータに提供され、提供情報が実行されると必要な修正プログラムがインストールされるようにする必要があります。ただし、依存関係が構成されていない限り、プログラムがインストールされる順序を判断できないことに注意してください。つまり、このようなコンピュータにインストールされた修正プログラムをロールバックする場合は、インストールと逆の順序でロールバックされます。これは、非常に複雑なプロセスです。
1 つのリリースに複数の修正プログラムをまとめる場合。

ワークステーションへの修正プログラムの展開

管理者が修正プログラムをワークステーションに展開するときは、以下のシナリオを検討する必要があります。

ダイヤルアップリンク経由のラップトップへの展開。
WAN 経由の展開 (低速ネットワーク接続経由で配布ポイントにリンクするクライアント)。
デザイン時点での、デザインされた方法による正常なコンピュータの再起動。
CD-ROM 展開を使用して修正プログラムを直接クライアントにインストールする (SMS 媒体使用センダではなく) 場合。インストールが停止される場合、または CD-ROM が使用できない場合も含めます。
ロールバック。

サーバーへの修正プログラムの展開

管理者が修正プログラムをサーバーに展開するときは、以下のシナリオを検討する必要があります。

サーバーの正常な再起動。多くの場合、サーバーは、バックアップが正しく行われることを確認するために、オペレータが介在している場合しか再起動されません。
デザインされた手順に従った、クラスタ (Microsoft クラスタサービス) への修正プログラムの正常なインストール。
クラスタを特に意識した、サーバーでの修正プログラムのアンインストール。

テスト中に使用されたトラブルシューティング手順、操作、ツールについての情報を収集し、実稼働環境にリリースが展開される前に、これらをサービスデスクサポート担当者および運用チームが利用できるようしておくことが重要です。テストの結果、以下のものが作成されることが予想されます。

標準的なトラブルシューティングの手順と、(ある場合は) 関連する回避策を記述した社内知識ベース。
連絡先およびエスカレーションパスの一覧。
運用担当者が効果的に実稼働環境でのリリースを監視できるようにする、情報 (カウンタ、イベント、しきい値)、スクリプト、および規則。

テスト結果に基づいたリリースキットの更新

受け入れテストが正常に完了した場合、SMS テスト環境には実稼動環境で再使用可能な一定の構成が存在します。この構成は、SMS Site Properties Manager を使用して SMS テスト環境からエクスポートし、実稼働環境にインポートする前に、DSL またはその他の場所に保存する必要があります。

パッケージまたはプログラムが変更されている場合、バージョン番号を使用して、パッケージを DSL にエクスポートして戻す必要があります。また、行われたすべての変更がドキュメント化されていることを確認します。

パイロットの実施と結果の評価

パイロットサイトは、多くの場合、対象のユーザーグループと場所、テクノロジ自体に基づいて選択します。ただし、最初の範囲指定の段階で使用したように、SMS クエリを使用して適切なパイロット環境を識別できます。以下に例を示します。

一般的なオペレーティングシステムの修正プログラム用には、さまざまな種類のコンピュータが展開されている場所を検索します。
特定のコンピュータ用の修正プログラムには、特定の種類のコンピュータが展開されている割合の高い場所を検索します。

パイロットは、DSL によって SMS パッケージの情報をテスト環境からパイロット環境に移行するという点では、完全な公開と同じ手法で実装される必要があります。

パイロットテストの成否を計る場合は、完全な展開の際に使用されるものと同じ方法を使用します。また、ラボでは完全に認識されていなかった、あるいは評価できなかった事項についても評価を行い、完全な公開を行った場合に成功するかどうかを評価します。たとえば、WAN を使用する場合の完全な影響は、実稼働環境でしか確認できない可能性があるので、パイロットテスト中に何かしらの WAN ネットワーク分析を実行し、完全な公開を行った場合の結果を推定できるようにする必要があります。

パイロットのロールバック

テストラボでどれほどテストを実施したとしても、実稼働環境に変更を公開した場合、ラボで確認できなかった影響が発生し、またこれらをラボでは決して再現できないことが多くあります。したがって、パイロットテスト中に公開を阻止するような問題や重大な問題が発生する可能性や、パイロット公開が予想通りに進まない可能性があります。

たとえば、予想した台数またはラボで使用された台数よりも多くのコンピュータでは、修正プログラムのインストールが正常に実行されない可能性があります。パイロットテストが計画通りに進まなかった場合は、パイロットテスト中に加えられた変更をすべてロールバックし、変更を再評価する必要がある可能性があります。

必要な場合、パイロット展開のロールバックには、次のセクションで説明している実稼働環境と同じテクノロジを使用します。

パイロットの経験に基づくリリースキットの更新

パイロットの結果、修正プログラムの展開方法に関する想定の見直しが必要になる可能性があります。以下に例を示します。

ネットワークの影響を軽減するために、より多くの小さなプロセスに分割して公開を行う必要がある可能性があります。この場合、各公開段階で対象のクライアントを特定するために使用した SMS クエリを変更する必要があります。たとえば、1 つのサブネットに同時に実行する公開を限定します。

ワークステーション

ワークステーションでは、以下の事項を検討します。

強制的な再起動により、保存していなかった作業が失われる可能性があります。このような場合、プログラムを変更して再起動が直ちに実行されないようにするか、提供情報を夜間に実行するように変更します。
夜間に提供情報を実行した場合、多くのコンピュータの電源が切られているために、提供情報が失敗し、翌朝これらのコンピュータが起動された時点で提供情報が実行される場合があります。コンピュータの電源を切らないように要請できない場合は、提供情報を日中行うように再スケジュールする必要があるでしょう。

サーバー

サーバーでは、以下の事項を検討します。

強制的な再起動により、サーバーが予期せず停止する可能性があります。再起動は、手動により実行する必要がある場合もあります。

変更が必要な場合は、パイロットサイトで変更を行うことができます。その後、Site Properties Manager を使用して、変更されたパッケージとプログラム設定をエクスポートし、DSL に格納して、後で残りの実稼働環境で使用できるようにします。

展開計画

場合によっては、リリースの計画には、リリースを実稼動に物理的に展開または展開するのに必要なすべてのタスクと作業が含まれます。しかし、複雑なリリースの場合、リリース計画には、いくつかの上層レベルの作業しか含まれていない可能性があります。この場合、リリース計画は単にリリースプロセスのある特定の段階の期間や担当者を特定しており、作業担当者が展開計画を作成しこれを指定された期間内に行うために必要なリソースを用意する責務を負います。

リリースを計画するときは、この展開のニーズに反するような変更が変更パイプラインで加えられている可能性があるので、変更パイプラインを確認して、展開順序を確認します。これは、たとえば、Windows 2000 に対する修正プログラムの展開を予定している場合に、展開先のサイトで Windows XP がインストール中であるような場合に発生します。

調査の結果、展開計画への変更が必要になる場合もあります。帯域幅の能力やディスク領域などに問題がある場合、展開順序を見直す必要がある可能性があります。たとえば、グローバルな展開が計画されている場合、対象とされている領域の 1 つで利用可能な帯域幅に制限があることが調査により特定されたとします。この場合、この帯域幅の制限に対処するような新しい RFC を提出するために必要な時間を確保するため、展開順序を変更する必要があるでしょう。このような場合は、この展開対象サイトが展開順序の後の方で処理されるように、展開順序を変更するようにします。

十分な数の配布ポイントが用意され、配布ポイントには十分なディスク容量とネットワーク帯域幅があることを確認する必要があります。これらが準備できない場合は、このような制限を考慮して展開順序を変更します。

注意以下の展開計画の中間段階では、SMS の利用方法の詳細に注目しています。

SMS 環境の調査

SMS 実稼動環境と関連するネットワーク環境の調査は、以下の事項を実現するのに必要になります。

SMS サイトに属する対象コンピュータの確認

すべての対象のコンピュータは、SMS サイトに属している必要があります。すべてのコンピュータが SMS クライアントであり、サイトに属しているのが理想的です。ただし、ネットワーク環境に対する最新の変更により、一部のコンピュータが SMS クライアントではなくなる場合があります。以下に例を示します。

IP サブネットアドレス情報を変更すると、特に関連する SMS サイトの範囲が変更されていない場合は、コンピュータの IP アドレスが SMS サイトの範囲内に相当しなくなることがあります。このような場合、このコンピュータは SMS サイトからアンインストールされます。
ネットワークに追加された新規コンピュータが、まだ SMS クライアントではない場合があります。 SMS クエリを使用して SMS サイトに属していないすべてのコンピュータを検索できます。これには、次のようなクエリを使用します。
```
select Name, SMSAssignedSites, NetbiosName, ResourceId from 
SMS_R_System where Client = 0 or Client is NULL or SMSAssignedSites 
is NULL 
```

小規模支社で少数のコンピュータしか使用していない環境では、低速ネットワーク経由でコンピュータが接続されている状況でも、その場所に SMS サイトを設定しない決定を下す場合があります。このような場合でも、この種のコンピュータが SMS サイトのクライアントになることができ、SMS サーバーには WAN 経由でアクセスされます。これは、このようなコンピュータにソフトウェアの配布が行われていないとき、またはソフトウェアの配布が非常に小規模なパッケージのみである場合は問題ありません。管理者が配布ポイントから直接修正プログラムをインストールすることを決定した場合 (CD-ROM によるインストールではなく)、使用可能な WAN リンクの帯域幅と、特定の期間中に段階的にクライアントに公開する方法を注意深く調査する必要があります。あるいは、新しい SMS サイトを展開する必要がある可能性があります。

十分な数の配布ポイントが存在することの確認

各 SMS サイトには、十分な配布ポイント、クライアントアクセスポイント、および LAN の容量が必要です。この情報を判断するには、SMS データベースを検索してサイトごとに以下の情報を提供できます。

配布ポイントとディスク容量
クライアントアクセスポイント

新しい SMS サイトを作成する必要がある場合があります。たとえば、少数のコンピュータしか使用せず、独立した SMS サイトを設定していない小規模支社 (上記参照) の規模が大量のクライアントを備えるように大幅に拡大された場合、クライアントに新規ソフトウェアを配布する前に、新規 SMS サイトを導入する必要があります。また、少数のクライアントとローカル配布ポイントを使用している小規模支社には、以前に Service Pack などの大規模パッケージが展開されたことがない場合があります。そのため、SMS サイトが必要になります。

利用可能なネットワーク帯域幅の確認

パッケージを所定の期間内に送信するには、サイト間に十分な WAN 容量が必要になります。また、管理者は WAN 容量の認識に加え、サイト間のセンダ設定も確認し、帯域幅調整と優先順位設定がパッケージの送信が可能な設定になっていることを確認します。 Service Pack などの大規模パッケージの場合は、このことが特に重要になります。

WAN の帯域幅がパッケージの送信のネックになっている場合、現在使用可能な帯域幅と、修正プログラムの送信の所要時間を調査する必要があります。パッケージ全体のコピーに数日以上かかる場合は、修正プログラムの実稼働環境への展開の提案済みスケジュールに影響を及ぼす可能性があります。

SMS サイトが正常に機能しているかどうかの確認

SMS サイトは正常に機能している必要があります。 SMS ステータスシステムをチェックし、すべてのサービスがすべてのサイトシステム上で実行されていることを確認します。 SMS 製品運用ガイドの詳細については、https://www.microsoft.com/technet/sms/20/smspog.mspx (英語) を参照してください。

インベントリが最新かどうかの確認

クエリまたはスクリプトを作成して、すべてのクライアントから最後にレポートされたハードウェアインベントリの時間をレポートできます。これは、インベントリ期間を過ぎてもレポートしていないクライアントを確認するために使用できます。

公開順序の変更は必要か ?

パッケージの送信に使用可能な WAN 帯域幅を調査することにより、パッケージの公開順序を変更する必要を示す場合があります。帯域幅に制限があるか、または媒体使用センダを使用する必要があるので、一部のサイトに短時間でパッケージを送信できない状況では、パッケージを迅速に公開する必要がある場合、公開順序を変更する必要があります。このような場合、ネットワーク接続が良好なサイトが先にパッケージを受け取るので、このようなサイトの公開順序が先になるようにスケジュールを設定します。

注意また、配布ポイントに修正プログラムをホストするだけの十分な領域があることも確認してください。これは、配布ポイントでインベントリを実行し、サイトコンポーネントを確認して各コンポーネントのディスク容量を参照することで確認できます。この場合、インベントリは、サイトごとに実行できます。また、すべてのサーバーの使用可能なディスク容量を表示する以下のクエリを実行することもできます。

SELECT Distinct SYS.name0 as 'Mach Name', LDISK.Description0 as 
'Logical Drive Description', LDISK.DeviceID0 as 'Drive Letter', 
LDISK.VolumeName0 as 'Vol Name', LDISK.FileSYStem0 as 'File System', 
Ldisk.Size0 AS 'Log. Disk Size',LDISK.FreeSpace0 as 'Free Space' FROM 
V_R_SYSTEM SYS, V_GS_Logical_Disk LDISK, V_GS_Operating_SYStem 
OPSYSWHERE SYS.Resourceid = LDISK.ResourceID AND SYS.ResourceID = 
OPSYS.ResourceIDANDSYS.OPERATING_SYSTEM_Name_AND0 LIKE '%server% 'ORDER 
BY SYS.Name0.

展開準備

実稼動環境は、新しいリリースごとに個別に準備される必要があります。この準備に必要なタスクと作業は、リリースと選択したリリースメカニズムによって異なります。共通のタスクは、リリースに関する情報をユーザーやその他のスタッフ、トレーニングサービスデスク、およびテクニカルサポート担当者に通知し、重要な IT コンポーネントのバックアップを作成することです。

展開準備をする場合は、ユーザー、企業、サポート担当者に事前に計画を通知します。また、実稼働環境の準備も整え、社内知識ベースもこれを反映して更新します。

注意以下のを展開準備の中間段階では、SMS の利用方法の詳細に注目しています。

実稼働環境の準備

修正プログラムを実稼働環境に公開する前に、SMS 階層に多少の変更が必要になることがあります。修正プログラムのサイズが、以前に公開されたソフトウェアに比べてかなり大きい場合は、ネットワークおよび記憶域容量が問題になる可能性があります。また、1 か所に新しいクライアントが多数追加されたり、ある場所から別の場所へ多数のクライアントが移動されるなど、最近クライアント数に変更があった場合は、SMS 階層自体の再編成が必要になる可能性があります。

1 SMS サイトあたりの対象クライアント数、SMS コンポーネントサーバーの数とその場所、サイト間通信インフラストラクチャを再確立するために、SMS 環境の調査が必要になります。

SMS バックログの確認

SMS 階層にはバックログや遅延がないようにして、できるだけ迅速に SMS パッケージがエンドポイントに配布および実行されるようにし、また、同様に SMS パッケージの実行を示すレポートが SMS の集中管理サイトに返されるようにします。つまり、システム内にサイト間トラフィックの待ち行列が発生しないようにする必要があります。インベントリの受信トレイを空にし、すべてのサイトからのステータスメッセージが最新になるようにします。

SMS 階層の保守方法の詳細については、https://www.microsoft.com/technet/sms/20/smspog.mspx で公開されている『Microsoft Systems Management Server 2.0 Product Operation Guide』 (英語) に記載されています。

SMS パッケージの作成

ソフトウェア更新の配布ウィザードを使用して修正プログラムを展開する場合は、ウィザードを使用してパッケージの作成とパッケージの内容の配布を行います。

本書の後半の「展開グループの選択」で説明するように、複数の修正プログラムを含む単一のパッケージを多数のクライアントに展開できます。この場合、クライアントの中には既に修正プログラムがインストールされているものや、まだインストールされていないものがある可能性があります。展開する各修正プログラムごとに新しいパッケージを作成する必要はありません。したがって、このウィザードを使用して適用されるすべての修正プログラム (Hotfix) を処理するために作成する必要があるパッケージはわずかで済みます。異なるパッケージを使用して展開を行う場合に対象となるコンピュータをグループに分類するための基準としては、次のものが挙げられます。

一部の修正プログラムの対象から除外されるコンピュータ (ある修正プログラムを適用可能なコンピュータであっても、この修正プログラムが適用されていない可能性がある全部のコンピュータには適用しないことにしている場合)。
再起動ポリシー (サーバーによっては、再起動が手動で実行されるものも、自動的に実行されるものもあります)。
インストールが必須になるまでの期間。

既存のパッケージを使用して新しい修正プログラムを展開する場合は、ウィザードの [ ソフトウェア更新パッケージの選択 ] 手順で既存のパッケージを選択する必要があります。この作業は、パッケージごとに繰り返し実行し、パッケージ数を最小限にとどめ、パッケージインストールエージェントの機能を使用して、適切に対象コンピュータが特定されるようにします。

コレクションが重なりあっているパッケージや関連対象コレクションは作成しないようにします。重複していると、新規修正プログラムのインストールを呼び出すプログラムが必要以上に何回も実行されることになります。これによりエラーが発生することはありませんが、コンピュータに不要な負荷がかかり、不要なネットワークトラフィックが生成されます。

パッケージソースを指定するように求められたら、[ ソースファイルを自分でダウンロードする ] をクリックし、検証済みの修正プログラムを直接インターネットからではなく検疫領域から取得できるようにします。

ソフトウェア更新の配布ウィザードを使用して展開されていない修正プログラムの場合、パッケージに関連付けられたプログラムを含むパッケージの定義は、受け入れテストの段階で保存され、SMS の実稼働環境にインポートできるようになります。この定義をインポートするには、BackOffice リソースキットの SMS Site Properties Manager を使用します。これは、テスト環境からのエクスポートに使用したのと同じツールです。

注意この手順は、パイロットの一部として既に実行された可能性があります。

Site Properties Manager を使用してパッケージ定義をインポートすると、パッケージ定義がテスト環境に保存された時点でパッケージに定義された配布ポイントも、インポートされます。これらの配布ポイントは実稼働環境では無効なので、すぐに削除する必要があります。この操作を実行しない限り、[Update distribution points] コマンドは実行しないでください。正しい配布ポイントは、次の手順で追加されます。

配布ポイントの割り当て

パケージを SMS にインポートした後、そのパッケージを対象クライアントが存在するすべてのサイトの配布ポイントに配布する必要があります。

SMS Software Update Services Feature Pack のセキュリティ更新インベントリツールおよび Microsoft Office 更新インベントリツールにより特定された修正プログラムについては、ウィザードの手順の 1 つとして配布ポイントの割り当てが行われますが、これらの配布ポイントは通常のパッケージのプロパティを使用して変更できます。

通常、修正プログラムの展開対象となるクライアントグループは同じにし、各修正プログラムに使用する配布ポイントが同じになるようにします。たとえば、サーバーおよびサーバーアプリケーション用の修正プログラムは、データセンターのサイト内の配布ポイントすべてに配布される必要があります。会計アプリケーションの修正プログラムは、会計部門のサイトの配布ポイントにのみ配布されます。したがって、特定のクライアントグループ専用の配布ポイントのみを含む配布ポイントグループを SMS に設定できます。配布ポイントグループを使用すると、展開される修正プログラムの配布ポイントの割り当てプロセスがより迅速に処理されるようになります。調査により得られた情報を使用して、新しい配布ポイントが必要な場所を特定できます。ただし、配布ポイントを配布ポイントグループに追加しただけでは、[Update distribution points] オプションを使用しても、新しい配布ポイントにパッケージが送信されるようにはなりません。配布ポイントグループがパッケージに割り当てられている場合にしか、配布ポイントグループを使用した配布ポイントの評価は行われません。新しい配布ポイントを個別にパッケージに追加し、配布ポイントの更新を実行する必要があります。

公開の準備はできているか ?

公開が実行される前に配布ポイントで、修正プログラムのパッケージファイルが公開できる状態になっていることを確認します。 SMS ステータスメッセージを使用して、パッケージがすべてのサイト上の該当の配布ポイントに正常に配布されていることを確認できます。これには、次のようなステータスメッセージクエリを使用できます。

select stat.*, ins.*, att1.*, stat.Time from  SMS_StatusMessage as stat 
left join SMS_StatMsgInsStrings as ins on ins.RecordID = stat.RecordID 
left join SMS_StatMsgAttributes as att1 on att1.RecordID = 
stat.RecordID inner join SMS_StatMsgAttributes as att2 on stat.RecordID 
= att2.RecordID where att2.AttributeID = 400 and att2.AttributeValue = 
##PRM:SMS_StatMsgAttributes.AttributeValue## and stat.Component = 
"SMS_DISTRIBUTION_MANAGER" and ( stat.MessageID = 2329 OR 
stat.MessageID = 2330 ) and stat.Time >= ##PRM:SMS_StatusMessage.Time## 
order by stat.Time DESC

このクエリにより、パッケージが指定されたパッケージ ID 用の配布ポイントに配布されているかどうかを示すステータスメッセージすべてと、ステータスメッセージを確認された期間が示されます。この期間をパッケージの最新の更新以降に制限すると、この条件にあった関連するステータスメッセージのみが表示されます。

サイト間で使用可能な WAN 帯域幅に制限がある場合、パッケージをすべての配布ポイントに準備するのに時間を要する可能性があります。媒体使用センダを使用して接続状態の悪いサイトにパッケージを送信する場合、メディアを作成して発送するプロセスに配慮し、リモートサイトへのパッケージの配送状況の進捗を手動で追跡する必要があります。

公開

修正プログラム管理の公開プロセスは、通常、他のリリースと同じです。プロセスの詳細については、以下で入手できるリリース管理 SMF ガイドを参照してください。

https://www.microsoft.com/solutions/msm/techinfo/default.asp (英語) を参照するか、https://www.microsoft.com/japan/technet/default.mspx の TechNet サイトで関連ドキュメントを検索してください。

ただし、次の注意事項は、このソリューションガイドに特有の情報です。

注意以下のリリースの展開の中間段階では、SMS の利用方法の詳細に注目しています。

展開グループの選択

ソフトウェア更新の配布ウィザードを使用して修正プログラムを配布する場合は、新しい修正プログラムを配信する際に、厳密に対象となるコンピュータを特定する必要はありません。これは、ウィザードによってスマートエージェントがクライアントに展開され、新しい修正プログラムがインストールされる必要があるときに、このエージェントが起動されるためです。このエージェントによって、ウィザードから提供される修正プログラムがコンピュータに適用可能かどうか、また、これは既にインストールされていないかどうかが、自動的に判断されます。また、複数の修正プログラムの連鎖や、修正プログラムを有効にするために必要な再起動も処理されます。

この方法でインストールされる修正プログラムのグループを作成する場合は、次の点を基準にします。

コンピュータを確認し、新しい修正プログラムをインストールする頻度。 (SMS 提供情報は、指定された間隔で新しい修正プログラムを確認するように作成されます。)
再起動ポリシー。異なるクライアントには、異なる再起動ポリシーが必要になります。たとえば、クライアントによっては手動の再起動を必要とするものがあります。つまり、異なるクライアントには異なるコレクションやパッケージが必要になります。
公開のスケジュール。これは、ウィザードを使用しないで展開される修正プログラムの場合に検討された方法と同じ方法で、処理される必要があります。ただし、この場合 (公開が進むにつれて、メンバーシップルールが変化する場合) は "進化する" グループ定義を使用することはできません。これは、エージェントが展開され、すべてのクライアントで定期的に実行されるためです。このため、段階的な公開を実行する能力は失われます。

この場合、クエリおよび後続のコレクションは、既にインストールされている他の修正プログラムを基準にしないようにします。修正プログラムインストールエージェントにより、コンピュータに何がインストールされ、何がインストールされていないかが判断されます。

ソフトウェア更新の配布ウィザードが使用されず、修正プログラムがカスタムパッケージとコレクションを利用して配布される場合は、既に範囲設定の段階で、修正プログラムを配布する SMS クライアントを特定するために、少なくとも 1 つの SMS クエリが使用されています。このようなクエリをコピーして、対象コレクション作成用のクエリとして使用するために修正する必要があります。以下に例を示します。

サーバー、ワークステーション、ラップトップにはそれぞれ異なるスケジュールが設定されて、異なるプログラムを実行する可能性があるので、独立したクエリが必要です。
異なる部門や地理的に離れた場所にあるコンピュータにも異なるスケジュールが設定されるので、独立したクエリが必要です。

ただし、公開を分割して行うための独立したクエリの数は、多すぎないようにします。使用するクエリが多すぎると、クエリ全体の整合を取るための余分な作業が発生し、エラーやクライアントの遺漏につながる可能性が高くなります。

段階的にリリースを実行する場合、たとえば異なる時点で異なるクライアントグループに適用する場合は、以下の手順を実行する必要があります。

1 つのクエリとこのクエリに基づいた 1 つのコレクションのみを使用し、公開の段階ごとにこのクエリを変更するようにします。最初は、1 つのサイトやワークグループなど、公開の最初の段階で対象となるクライアントの範囲を絞り込めるようにクエリを変更します。公開が拡張され、より多くのクライアントが対象になるにつれて、クエリも拡張し、クエリの対象範囲に公開の次の段階で対象となるクライアントが含まれるようにします。
クエリに加えた変更を追跡し、それまでのバージョンを保管しておくようにします。段階的な手法でロールバックが必要な場合、または直前の段階に戻す必要がある場合、最新のクエリテキストの取得を容易にします。

このアプローチにより、クエリ、コレクション、および提供情報の数を最小限に抑えることができますが、公開の進捗に伴い、管理者による介入が必要になります。

選択したグループへのリリースの展開

管理者は、ソフトウェア更新の配布ウィザードを使用すると、修正プログラムインストールエージェントを繰り返し実行する提供情報を自動的に作成するコレクションを指定できます。繰り返し間隔の既定値 (7 日間) は、コレクションに合わせて変更できます。たとえば、サーバーを含むコレクションは、毎日 1 回、またはそれ以上の頻度でエージェントを実行できます。

コンピュータの種類に応じて異なるスケジュールが必要な場合は、同一のパッケージとプログラムを使用する複数のコレクションに対して、複数の提供情報を作成できます。

修正プログラムインストールエージェントを繰り返し実行する間隔を毎日に設定している場合、重要な修正プログラムが提供されたときは、すぐにインストールエージェントを実行する必要があります。その後、できるだけ迅速に実行するための一度しか使用しない提供情報を新たに割り当てる必要があります。

提供情報の変更がクライアントアクセスポイントに反映されると、次に提供情報を受け取ったクライアントを確認するプログラムが、すぐに修正プログラムインストールエージェントを実行し、新しい修正プログラムをインストールします。

ソフトウェア更新の配布ウィザードを使用しないで、修正プログラムをカスタムパッケージとコレクションを使用して配布する場合は、「配置グループの選択」で作成したコレクションを使用して、修正プログラムのインストールを実行するための単一の提供情報を作成する必要があります。

公開を段階的に実行し、1 つのクエリまたはコレクションを使用する場合は、最初の段階の公開が完了したときに、クエリに次の段階 (たとえば、次のサイトで展開を実行する) にクライアントが含めるように修正する必要があります。修正プログラムインストールプログラムに自動的に新しいクライアントのセットが通知された後、コレクションを手動で更新するか、または定義済みのスケジュールで更新します。

提供情報とコレクションを 1 つしか使用しないため、1 つの提供情報の SMS ステータスメッセージを参照するだけで、修正プログラムの公開全体のステータスを容易に確認できます。

QFE 修正プログラムの場合、対象のコレクションに使用される SMS クエリは、インストール対象の修正プログラムが不足しているコンピュータを示すインベントリ情報に基づいて作成されます。つまり、次のことを行います。

コンピュータに修正プログラムがインストールされ、続いてインベントリが実行されると、クエリの定義に一致しなくなるので、コレクションの更新時にこのコンピュータはコレクションから削除されます。
新しいコンピュータがネットワークに追加され、SMS によってインベントリが作成されてコレクションが更新されると、そのコンピュータに修正プログラムが不足している場合、修正プログラムインストールプログラムに自動的に提供されます。

2 番目の処理のため、コレクションとこれに関連付けられている提供情報は、ビルドプロセスの一環としてすべての新しいコンピュータに展開されるベースラインの構成に修正プログラムが追加されるまで、SMS から削除しないようにします。追加される修正プログラムには、ビルドプロセスの一環としてインストールされる修正プログラムか、ビルドプロセスで使用される修正プログラムを含む新しい Service Pack を使用できます。これは、空のコレクションに提供されている提供情報が存在する可能性があることを意味します (展開済みのすべてのコンピュータに修正プログラムがインストールされており、新規コンピュータがオンラインになったときに、コレクションが新規コンピュータだけをピックアップしている場合)。

プログラムを設定するときには、[ 提供しないソフトウェアは削除する ] 詳細設定オプションを使用しないようにします。このオプションを使用すると、インベントリによってクライアントに修正プログラムがインストールされていると判断されると、そのクライアントはコレクションから削除されます。この時点で、修正プログラムのインストールはそのクライアントに提供されなくなります。このオプションを使用すると、修正プログラムがこの時点でアンインストールされて、修正プログラムのインストールとアンインストールが無限に繰り返されることになります。

修正プログラムをインストールする提供情報が設定されている場合、一定の間隔で繰り返されるようにスケジュールを構成します。これにより、インストールが失敗した場合は、自動的に再試行されます。提供情報が繰り返されない場合は、インストールが失敗したクライアントに対する再試行プロセスは手動プロセスとなり、失敗したクライアントのコレクションを作成し、このコレクション用の提供情報を新たに作成します。このプロセスは、すべてのクライアントに修正プログラムがインストールされるまで、繰り返す必要があります。 CD-ROM ベースのインストールについての記述で説明したようなラッパープログラムを使用する場合は、サイクルごとに発生する失敗の数は多くなる傾向があります。

以下のような理由により、提供情報の繰り返し間隔は、注意深く選択する必要があります。

正常にリリースがインストールされているクライアントは、新しいインベントリ情報が収集されるまで (インストールプログラム自体で実行可能)、または SMS データベースのインベントリ情報が更新されてコレクションが再評価されるまで、対象のコレクションに含まれたままになります。そのため、プログラムは一度正常に実行したクライアントで再実行できます。以上の理由により、実行プログラムは、最初に修正プログラム (複数可) がインストールされていることを確認し、インストールされている場合はすぐに終了することが重要になります。
その他の何らかのエラーが原因で、繰り返しプログラムの実行に失敗すると、ユーザーに負担がかかります。
インストールプログラムを繰り返し実行すると、クライアントとネットワークに余分な負荷が発生します。
ただし、特に修正プログラムを緊急に適用する必要があるときは、間隔を長くしすぎないようにする必要があります。

修正プログラムが重要で、非常に短期間で展開する必要がある場合があります。この場合は、緊急な変更として優先順位が付けられるので、おそらくテスト段階が非常に短くなります。リスクが高くなるので、対象のクエリとコレクションは、できるだけ最小限の数のクライアントに抑え、修正プログラムの展開を忘れるリスクに注意してください。

データセンターのすべてのサーバーが 1 つの SMS サイトに存在する SMS アーキテクチャでは、重要な修正プログラムを短期間で展開できます。パッケージがそのサイトで作成され、対象のコレクションの設定とプログラムへの通知が完了した後、選択した SMS アーキテクチャによって、サーバーの SMS クライアントへのこの情報の通知が遅れないようにする必要があります。サーバーが、次に新しい提供情報を確認するとすぐに提供情報が実行されます。つまり、間隔が短く設定されます。

展開は成功したか ?

管理者はクライアントのコレクションにパッケージを提供することによってパッケージを展開した後は、クライアントが提供情報を正常に実行したかどうかを判断する必要があります。 SMS クライアントから返されるステータスメッセージの確認に使用できるツールは多数あります。

SMS のサポートツールに、Advertisement Status Viewer ツールがあります。このツールは、ステータスメッセージに基づいて提供情報の展開ステータスを提供します。ただし、提供情報の展開ステータスを確認するときは、多くの場合、以下のことを認識しておくと役立ちます。

コレクションに含まれていたが、提供情報を受け取らなかったクライアント。
提供情報を受け取ったが、実行していないクライアント。
プログラムを実行したが、失敗したクライアント。

たとえば、特定の提供情報に関して成功のインストールステータスメッセージを返さなかったコレクションのすべてのコンピュータを表示するには、以下のクエリを使用します。

select 
SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name, 
SMS_R_System.SMSUniqueIdentifier,SMS_R_System. 
ResourceDomainORWorkgroup,SMS_R_System.Client from 
SMS_R_System inner join SMS_G_System_SYSTEM on 
SMS_G_System_SYSTEM.ResourceID = SMS_R_System.ResourceId 
where  <コレクションのメンバーシップを定義するクエリをここに挿入します> And 
Name not in (select Name from SMS_R_System where Name is in (select 
distinct stat.MachineName from SMS_StatusMessage as stat left join 
SMS_StatMsgAttributes as att1 on att1.RecordID = stat.RecordID inner 
join SMS_StatMsgAttributes as att2 on att2.RecordID = stat.RecordID 
where stat.Component = "Available Programs Manager (APM)" and 
stat.MessageID = 10008 and att2.AttributeID = 401 and 
att2.AttributeValue ="<提供情報 ID をここに挿入します>"))

セキュリティ更新インベントリツールおよび Microsoft Office 更新インベントリツールにより特定された修正プログラムについては、Web レポートを使用して修正プログラムの展開が成功したかどうかを確認できます。「Machines where a specific patch is available」レポートを使用すると、修正プログラムがインストールされていないコンピュータを特定できます。このレポートでは、更新済みのインベントリに基づいて特定を行うため、ステータスメッセージを参照しても同等の最新情報は確認できません。

ステータスメッセージでは、繰り返し実行される提供情報が実行されたかどうかしか確認できません。実際に実行される修正プログラムインストールプログラムでは、新しく認証された修正プログラムがあった場合、これらがインストールされます。このプログラムが正常にクライアントで実行されているかどうかを確認するには、ステータスメッセージを分析して、各クライアントでこのプログラムが最後に正常に実行された時期を特定します。プログラムが実行されてからの時間が、クライアントの繰り返し間隔よりも長い場合、調査する必要があります。

修正プログラムやそのインストールで、公開を直ちに停止する必要があるエラーが発生した場合は、提供情報を無効にする必要があります。 SMS プログラムの [ プロパティ ] で、[ 提供されるコンピュータで、このプログラムを無効にする ] チェックボックスをオンにして提供情報を無効にします。

これにより、提供情報のスケジュールを解除したり、削除しなくても、プログラムがクライアント上で実行されなくなります。実際、原因分析のために提供情報のステータスメッセージを分析するのは難しいので、提供情報は削除しないでおく必要があります。

展開を直ちに停止するかどうかは、修正プログラムのエラーの持つ影響によって異なります。修正プログラムをインストールするコンピュータが不安定になったり、比較的大きなセキュリティリスクが発生する場合は、展開を中止する方が賢明でしょう。この修正プログラムにより、この修正プログラムが作成された目的となった問題が解決されず、ただしこの問題の重要度は低い場合で、実行予定のプログラムによって、直ちに必要とされている他の修正プログラムもインストールされる場合は、展開を続行してもよいでしょう。

複数の QFE プログラムを 1 つのパッケージにまとめてインストールする場合、1 つの修正プログラムのエラーにより公開が中止され、残りの修正プログラムすべてが展開されなくなるので、不安定になる可能性、大きなセキュリティのリスク、または公開のエラーが増加します。このようなインストールを行うかどうかは、変更の承認時に決定する必要があります。

失敗の根本的原因の分析

根本的原因の分析の一環として、SMS ステータスメッセージを使用できます。

ステータスメッセージ 10006 と 10007 は、プログラムが正常に実行されないときに生成されます。ステータスメッセージ 10018 と 10019 は、クライアントが提供情報を拒否したときに生成されます。

変更のロールバックと変更管理へのリリースの受け渡し

既に部分的に展開済みのリリースをロールバックするには、インストールを正常に実行済みの SMS クライアントにのみアンインストールプログラムを提供する必要があります。管理者は提供情報が正常に実行されたことを示すステータスメッセージを基にしたクエリを作成することで、リリースをアンインストールする必要があるコンピュータの一覧を作成できます。このステータスメッセージクエリでは、新しい修正プログラムが配布された時点以降に生成されたステータスメッセージのみを検索するようにします。これにより、同じ提供情報のステータスメッセージで、以前に実行された提供情報に対するステータスメッセージは検索対象から外します。これは、不適切な結果を取得を避けるために、ソフトウェア更新の配布ウィザードを使用している場合など、繰り返し実行される提供情報が使用されているときは、特に重要になります。

この方法は、ステータスメッセージが既に SMS データベースから削除されている場合など、ステータスメッセージを利用できない場合には使用できません。このような場合には、SMS ハードウェアインベントリを使用して、問題の修正プログラムがインストールされているシステムを特定します。この方法を成功させるには、SMS データベース内の情報が正確かつ最新である必要があります。

修正プログラムがインストールされているシステムの一覧を作成したら、このようなシステムのコレクションを作成し、アンインストールプログラムを提供できます。

インストール時に使用した技法と同じ確認技法を使用して、すべての対象のクライアントでアンインストールが正常に実行されたことを確認後、提供情報とパッケージをこの順序で削除します。

公開は完了したか ?

修正プログラムの公開が完了したら、コンピュータは新規インベントリを実行します。このインベントリはインストールの一環として、修正プログラムのインストール直後に強制的に実行される場合もあります。更新されたインベントリ情報には、新しくインストールされた修正プログラムの詳細が含まれます。修正プログラムがインストールされていないことを検出するクエリに基づいた動的なコレクションを使用すると、すべてのコンピュータが更新され最終的には空になるまで、コレクションのメンバーシップが削除されます。

または、提供情報ステータスに基づくクエリを使用して、すべてのコンピュータに修正プログラムがインストールされた時点を判断できます。

提供情報、コレクション、およびプログラムは、展開が完了したと見なされる場合でも、有効かつ最新状態に保持しておく必要があります。これにより、修正プログラムが適用されていない新しいコンピュータがネットワークに接続された場合に、これらのコンピュータに自動的に修正プログラムが配布されます。

セキュリティ更新インベントリツールおよび Microsoft Office 更新インベントリツールにより特定された修正プログラムについては、「Software Updates」 Web レポートを使用してセキュリティや修正プログラムの展開が成功したかどうかを確認できます。「Machines where a specific patch is available」レポートを使用すると、修正プログラムがインストールされていないコンピュータを特定できます。 QFE 修正プログラムの提供情報のステータスを監視するには、カスタム Web レポートを作成する必要があります。

変更のレビュー

修正プログラムに注目した変更のレビュー段階は、他の変更の場合と同様に、変更が目標を満たしているかどうかを確認するために実施されます。

たとえば、修正プログラムは、公開の最初の段階で正常に機能しても、その後に問題が発見されて、再評価が必要になる場合があります。

この場合、問題を解決する次の修正プログラムの特定や公開の中止などの作業を決定する必要があります。変更の無効にする必要があれば、RFC 承認段階と同じように、経済的な調整および影響分析を実施する必要があります。

注意以下のリリースの展開の中間段階では、SMS の利用方法の詳細に注目しています。

IT 環境での変更の監視

提供情報に関する SMS ステータスメッセージを監視して、すべての対象のクライアントに修正プログラムパッケージが正常にインストールされたことを確認します。 Microsoft Operations Manager (MOM) を使用して、SMS サイトサーバーのイベントログに記録されたエラーを監視することもできます。

最近の修正プログラムでは、インストール時にシステムイベントログへの書き込みが行われます。したがって、MOM エージェントが実行されているサーバーでは、これらのイベントを収集および監視できます。基幹サーバーでは、このサーバー上で特定の期間内に発生した修正プログラムのインストールイベントを監視するための期間限定のイベントを作成できます。あるいは、重要な修正プログラムが期限内にこのサーバーに配布されなかったことをオペレータに知らせる警告を生成することもできます。

実装後のレビュー

変更のレビューの結果、修正プログラムを取り消す必要がある場合、修正プログラムのアンインストールプログラムを、修正プログラムをインストール済みのすべてのコンピュータに提供する必要があります。修正プログラムが提供されたすべてのコンピュータに既にインストールされている場合、アンインストールプログラムを同じコレクションに提供する必要があります。一部の関連コンピュータに修正プログラムがインストールされていない場合、アンインストールプログラムは既にインストール済みのコンピュータにのみ提供する必要があります。

修正プログラムがインストールされたコンピュータを識別するには、2 つの方法があります。

修正プログラムを正常にインストールした SMS クライアントを識別する元の提供情報ステータスメッセージを使用し、このようなコンピュータに基づいてコレクションを作成します。
修正プログラムがインストールされたコンピュータを検索する、インベントリに基づくクエリを使用します。

最初の方法は、設定がより複雑で、しかも結果として得られるコレクションは動的コレクションではありません。これは、コレクション内のメンバが、アンインストールプログラムの公開につれて少なくなるためです。ただし、新規インベントリは SMS 階層全体に伝達されますが、インベントリサイクルを待機する必要がなく、その後の遅延も生じないという利点があります。

修正プログラムを削除した場合は、通常、システムの再起動が必要になります。特にサーバーから修正プログラムを削除する場合は、修正プログラムの最初の展開と同様に、慎重に計画および実行する必要があります。クラスタ化されているサーバーの場合は、修正プログラムをロールバックするには、修正プログラムを最初にインストールした時と同様に、細部にわたり注意が必要です。

修正プログラムにより、システムに加えた変更を取り消せなくなっている場合があります。この場合は、単純なアンストールによってロールバックすることはできません。このような場合は、ロールバックを行うために、通常の定期的に作成されたバックアップやディスクイメージから、システムを前回のバックアップの状態に復元するなどします。たとえば、SQL Server に修正プログラムが適用されている場合は、実稼動ネットワーク上で、通常の方法でデータベースを更新して、修正プログラムのアンインストールが必要になる前の状態に復元します。この場合、修正プログラム適用以前のシステムバックアップを復元する前に、SQL Server データベースをバックアップする必要があります。その後、バックアップされていたデータベースを復元します。

修正プログラムのアンインストールは、後入れ先出し方式で実行される必要があります。複数の修正プログラムがシステムに適用されている場合は、異なる修正プログラムによって、同じ 1 つのファイルが更新されている可能性があります。修正プログラムをロールバックする場合に、ロールバックの影響を受けるファイルの中に別の修正プログラムによって更新されているファイルが含まれている場合、システムが不安定になったり、どの修正プログラムが実稼働環境に実装されているかを特定する際に矛盾が生じる可能性があります。

付録

付録 A: SQL Server 2000 への修正プログラムの適用

目的

この付録の目的は、Microsoft SQL Server・2000 への修正プログラムの展開に、『Microsoftｮ Systems Management Server (SMS) を使用した修正プログラム管理 - ソリューションガイド』で説明している手順や作業をどのように使用するかの例を組織に提供することです。

以下の作業は、『Microsoft Systems Management Server (SMS) を使用した修正プログラム管理 - ソリューションガイド』で説明した手順に基づいています。

監査の実行

SMS ソフトウェアとハードウェアインベントリクライアントエージェントを、セキュリティの更新スキャンツール (SMS Software Update Services Feature Pack の一部) と併用して、SQL Server 2000 を実行しているすべてのコンピュータを定期的に監査する必要があります。組織がベースラインを決定する前に、このようなコンピュータの状態の正確な記録を入手するのに、この監査が役に立ちます。また、監査の結果を使用して、構成管理データベース (CMDB) を更新する必要があります。

ベースラインの定義

通常、運用ベースラインには、SQL Server 2000 の最新のサービスリリースを含める必要があります。この資料を執筆している時点の最新のサービスリリースは、SQL Server 2000 Service Pack 3 (SP3) です。以下の SMS/SQL クエリは、SQL Server 2000 を実行しているすべてのコンピュータとそれぞれのバージョン番号を識別します。

select distinct SMS_R_System.Name, 
SMS_G_System_SoftwareProduct.ProductVersion from SMS_R_System inner 
join SMS_G_System_SoftwareProduct on 
SMS_G_System_SoftwareProduct.ResourceID = SMS_R_System.ResourceId where 
SMS_G_System_SoftwareProduct.ProductName = "Microsoft SQL Server" and 
SMS_G_System_SoftwareProduct.ProductVersion >= "8.00" order by 
SMS_G_System_SoftwareProduct.ProductVersion DESC

SMS データベース内の情報は、インストールが必要な一部のセキュリティ修正プログラムについての通知を提供しますが、管理者は電子メールによるセキュリティ情報を購読し、定期的に Microsoft Web サイトを参照し、すべての関連修正プログラムを確認する必要があります。セキュリティ修正プログラムと SQL Server 2000 修正プログラムの電子メールによる通知を受け取るには、以下の Web ページから利用できるメーリングリストを購読します。

https://www.microsoft.com/japan/sql/techinfo/administration/2000/security/

https://www.microsoft.com/japan/technet/security/current.aspx

https://support.microsoft.com/default.aspx?scid=https://www.microsoft.com/japan/support/newsgroup/default.asp

上記で一覧した通知サービスは、無償で提供されています。 Microsoft では、これらの通知サービスを使用して、SQL Server 2000 などの Microsoft 製品のセキュリティに関する情報を購読者に配布しています。

変更の開始

修正プログラム管理の変更の開始プロセスは、認識、関連性、および検疫の 3 つの主要コンポーネントで構成されます。

認識

SQL Server の修正プログラムに関する情報は、電子メール通知、Microsoft Web サイト、SMS データベース内に含まれる情報など、多くのソースから届けられます。 SMS が不足していることを検出したセキュリティの修正プログラムを特定するには、「Applicable software updates for a specific product-SQL Server 2000 Gold」 Web レポートを実行します。これにより、図 21 のようなレポートが生成されます。

図 21: SQL Server 2000 サーバーに適用可能な修正プログラムを特定するレポート

注意SMS/SUS Feature Pack は、常に、すべてのセキュリティ修正プログラムを識別するわけではありません。インストールされているソフトウェアのバージョンに関連する修正プログラムのみを識別します。仕様上、不足している Service Pack は特定しません。そのため、管理者はシステムを最新状態に維持するために、セキュリティ情報を購読し、推奨の Web サイトを確認することが不可欠になります。詳細については、https://support.microsoft.com/default.aspx?scid=kb;ja;306460 を参照してください。

管理者は、受け取る通知ごとに、その通知の信頼性を確認する必要があります。参照した Web ページや受け取った電子メールメッセージが信頼するソースからのものであることを確認します。これを行うには、https://support.microsoft.com/default.aspx のサポート技術情報の検索ページで関連文書番号を入力して、関連するサポート技術情報の資料を読みます。

関連性評価

SQL Server 2000 に適用できる修正プログラムはたくさんあるので、すべての修正プログラムを徹底的に検査して、組織との関連性を確認することが重要です。各修正プログラムの詳細レビューには、以下の項目が含まれます。

その修正プログラムを必要とする実稼働環境内のサーバー (存在する場合) を確認するための現在の SQL Server 2000 構成の調査。
適用可能なデータベース管理者（DBA) からの入力。
すべての関連ドキュメントのレビュー。たとえば、修正プログラムと共に送付されたドキュメント、Microsoft の TechNet (https://support.microsoft.com) で見つかった補足情報などがあります。
修正プログラムの性質と目的の確認。通常は、関連する製品と CMDB の両方のサポート情報の詳しい調査を行います。

たとえば、取得した修正プログラムがクラスタ内のすべての SQL Server 2000 サーバーにインストールする必要があるものであった場合に、組織に展開されている SQL Server サーバーがすべてスタンドアロンの場合、この修正プログラムは無関係な修正プログラムです。

検疫

ウィルスの感染や悪質なコードによる組織の IT インフラストラクチャへの悪影響を防ぐため、修正プログラムのすべて関連ファイルは、独立した (検疫) 環境で検査する必要があります。この検疫は、すべてのソフトウェアおよびドキュメントに行う必要があります。隔離された環境では、これらは厳重に管理される必要があります。厳密な管理を確保するには、組織の専門家グループが検疫プロセスを実行する必要があります。検疫プロセスが完了すると、ファイルを配布準備用の基準ソフトウェアライブラリ (DSL) フォルダに配布できます。

修正プログラムに対する検疫にかける時間は、組織の SQL Server SLA により決定されます。上記の SP3 の例は最も優先順位が高いものになリ、検疫プロセスはその緊急性を反映する必要があります。

変更管理

すべての変更は、要求、分類、承認、および開発の変更管理プロセスによって管理される必要があります。

変更要求

管理者は、修正プログラムと関連する問題点や要件を詳しく示した変更要求 (RFC) を発行する必要があります。変更の承認は、修正プログラムの配布の許可を発行します。詳細については、『Microsoft Systems Management Server を使用した修正プログラム管理 - ソリューションガイド』を参照してください。

変更分類

変更の開始者は、RFC の提示の一部として、その修正プログラムに優先順位とカテゴリを割り当てる必要があります。優先順位は、その修正プログラムがシステムに与える影響によって変化します。 SQL Server 2000 の修正プログラムの大部分は再起動を必要とするので、稼動停止時間が修正プログラムの分類に影響します。

変更の開始者は、この修正プログラムまたは適用後に必要な稼動停止により、どのユーザーが影響を受けるかも考慮する必要があります。このようなユーザーは修正プログラムの展開中に代替のサービスを必要とするでしょうか? 混乱を最小限にとどめるために、混雑していない時間帯にこの修正プログラムを展開すべきでしょうか? この修正プログラムはできる限り迅速に展開する必要があるのでしょうか (セキュリティの修正プログラムなど)? 社外のユーザーにどのような影響を与えるでしょうか?

変更認可

変更の優先順位が緊急に設定されている場合、Microsoft SQL Server 2000 を実行しているサーバーに関連する要求されたすべての変更 (修正プログラムのインストールを含む) は、変更諮問機関 (CAB) または変更諮問機関緊急委員会 (CAB/EC) によって検討され、レビューされる必要があります。

変更開発

修正プログラムを組織に配布する前に、新たな開発が必要になる場合があります。たとえば、SQL Server の一部の修正プログラムは、バイナリの実行可能ファイルそのものではなく、圧縮されたファイルです (ファイルを使用する前にそのイメージからファイルを解凍する必要があります)。このような場合、ダウンロードした実行可能ファイルではなく、解凍したファイルを修正プログラムのソースとして使用する必要があります。

リリース管理

リリース管理には、承認された変更を IT 環境に展開する役割があります。混乱を最小限に抑えながら、実稼動環境に変更を正しく展開することが目的です。

リリース計画

『Microsoft Systems Management Server を使用した修正プログラム管理 - ソリューションガイド』で説明したように、リリースマネージャは、修正プログラムを展開する方法、およびこの展開をサポートするために必要なリソースやトレーニングを概説するリリース方針を構築します。リリース方針では、修正プログラムを実稼働環境から削除する方法も記載する必要もあります (これが必要だと立証される場合)。

実稼働環境には数多くの異なる構成の SQL Server 2000 が存在する可能性があるので、リリースマネージャは構成ごとに必要な異なるタスクや作業を特定する必要があります。たとえば、SQL Server クラスタに修正プログラムを展開するために必要なタスクは、スタンドアロンサーバーに展開するために必要なタスクと異なる可能性があります。また、サーバーから修正プログラムを削除する手順 (失敗した場合) も異なる可能性があります。

注意Systems Management Server 2.0 はクラスタの仮想ノードを特定できないので、この点では、物理ノードにインストールされる修正プログラムの配布のみに SMS を使用することをお勧めします。 SQL Server Service Pack は、通常、仮想ノードにインストールされ、非表示でインストールすることはできません。 SQL Server Service Pack を SMS を使用して配布およびインストールすることはできません。

リリース構築

リリース計画に同意すると、リリースチームのメンバは、リリースを実稼動に展開するためのプロセス、ツール、必要なテクノロジの開発を始めることができます。このプロセスの実行中に、リリースメカニズムの選択、リリースパッケージのデザイン、構築、およびテストを行う必要があります。ロールバック計画も開発し、テストする必要があります。

ここでも、SQL Server の一部の修正プログラムは、ダウンロード状態ではインストールできないことに注意することが重要になります。このような修正プログラムは、最初にアーカイブから抽出する必要があります。次に、抽出したファイルを調査とその後の配布のために、検疫領域に配置します。

可能であれば、SMS/SUS Feature Pack の配布ウィザードを使用して、修正プログラムを配布します。ただし、SQL Server のカスタム修正プログラムまたは SQL Server 2000 Service Pack を配布する場合は、ソフトウェア配布の通常の SMS プロセスに従って、プログラムや提供情報を開発する必要があります。

注意SQL Server の修正プログラムを配布するときは、再起動を抑え、予期しない稼動停止時間を避けることをお勧めします。

最後に、テスト完了後、適切なバイナリファイルで DSL を更新し、それに合わせて CMDB を更新します。

受け入れテスト

開発者およびビジネスの代表者は、受け入れテストにより、実稼働環境を忠実にミラー化する環境で、リリースおよびリリースパッケージが共にどのように機能するかを確認できます。場合によっては、企業規模の公開に進むために必要な信用を築くために、パイロットテストが必要になることもあります。

リリースが実稼動環境に悪影響を与えないことを確認するには、各リリースのテストを実稼動状態を事実上モデル化した設備で実行する必要があります。これには、スタンドアロンコンピュータまたはクラスタ化されたコンピュータのいずれかにホストされる実稼動データベースを正確にミラー化することも含まれます。

テスト環境の構成は、バージョン管理の対象とし、CMDB に保存される必要があります。すべての補足ドキュメントもバックアップし、安全に保管します。

受け入れてストの詳細については、『Microsoft Systems Management Server を使用した修正プログラム管理 - ソリューションガイド』を参照してください。

展開計画

リリースの計画段階には、リリースを実稼動に物理的に展開または展開するのに必要なすべてのタスクと作業が含まれます。展開マネージャは調査を実施して、影響しそうなネットワークの制限事項、利用可能な帯域幅、十分な配布ポイント、修正プログラムの優先順位 (たとえば、ユーザーを強制的にオフラインにするほど修正プログラムのインストールが緊急かどうか)、および SMS インベントリが最新であることを明確にする必要があります。

修正プログラムをインストールする順序とスケジュールを計画します。 SQL Server に修正プログラムをインストールするときは、ある日は一部のサーバーに修正プログラムをインストールし、別の日には他のサーバーにインストールして、ビジネス上重要なデータベースの稼働時間を増加する必要があります。

展開準備

新しいリリースごとに、実稼働環境を準備する必要があります。このテストには、以下の項目を含める必要があります。

DBA への通知。
稼動が停止する可能性のあるユーザーへの通知。
サポート担当者を支援するトレーニングのスケジュール設定。
テスト環境からのプログラムと提供情報のインポート。
修正プログラムと関連バイナリファイルの存在を確認するための、配布ポイントの調査。

注意最大レベルの信頼性とセキュリティを確保するために、可能であれば、常に、テスト環境からパッケージをインポートすることをお勧めします。

展開

リリース管理には、承認された変更を IT 環境に展開する役割があります。管理者は、この段階で修正プログラムの公開を開始します。可能であれば、管理者はソフトウェア更新の配布ウィザードを使用して、修正プログラムを配布します。これは、ウィザードによってスマートエージェントがクライアントに展開され、新しい修正プログラムがインストールされる必要があるときに、このエージェントが起動されるためです。このエージェントによって、ウィザードから提供される修正プログラムがコンピュータに適用可能かどうか、また、これは既にインストールされていないかどうかが、自動的に判断されます。また、複数の修正プログラムの連鎖や、修正プログラムを有効にするために必要な再起動も処理されます。

注意展開を開始する前に、展開によって影響を受ける各 SQL Server 2000 サーバーで、主要なデータベースをすべてバックアップします。

管理者は、ここで、対象とする関連コンピュータの特定に役立つクエリを作成する必要があります。その後、対応するコレクションがそのクエリに基づいて構築され、そのコレクションに修正プログラムが展開されます。

以下の SMS クエリは、最新バージョンの SQL Server 2000 Service Pack 3 を実行していないすべてのコンピュータの詳細を示します。

select distinct SMS_G_System_COMPUTER_SYSTEM.Name, 
SMS_G_System_SoftwareProduct.ProductName from SMS_R_System inner join 
SMS_G_System_SoftwareProduct on SMS_G_System_SoftwareProduct.ResourceID 
= SMS_R_System.ResourceId inner join SMS_G_System_COMPUTER_SYSTEM on 
SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where 
SMS_G_System_COMPUTER_SYSTEM.Name not in (select 
SMS_G_System_COMPUTER_SYSTEM.Name from SMS_R_System inner join 
SMS_G_System_SoftwareProduct on SMS_G_System_SoftwareProduct.ResourceID 
= SMS_R_System.ResourceId inner join SMS_G_System_COMPUTER_SYSTEM on 
SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where 
SMS_G_System_SoftwareProduct.ProductName = "Microsoft SQL Server" and 
SMS_G_System_SoftwareProduct.ProductVersion = "8.00.760") and 
SMS_G_System_SoftwareProduct.ProductName = "Microsoft SQL Server" order 
by SMS_G_System_COMPUTER_SYSTEM.Name

管理者は、SMS がクラスタの物理ノードと仮想ノードを区別できないことを知っておく必要があります。また、管理者は SMS を使用したクラスタの管理の技術的な側面を理解する必要があります。詳細については、以下の資料を参照してください。

https://www.microsoft.com/japan/SMSERVER/techinfo/administration/20/integrating/clusterinterop.asp

管理者は、それ以前の段階でダウンロードして検疫環境に配置した修正プログラムのバイナリファイルと、修正プログラムの展開に選択した手法 (ソフトウェア更新の配布ウィザードまたは SMS 提供情報とプログラム) を使用して、ジョブを作成し、関連する SMS コレクションに修正プログラムを配布する必要があります。

管理者は、クラスタ化された SMS クライアントまたは以前の修正プログラムに修正プログラムを展開するときに必要な技術的な手順を理解する必要があります。 SQL Server 修正プログラムインストーラツールを使用しない一部の修正プログラムには、手動でインストールする必要があり、SMS を使用してインストールできません。ただし、修正プログラムインストーラツールを使用する最新の修正プログラムは、SMS と SUS Feature Pack を使用して完全に自動化できます。

そのため、修正プログラム管理プロセスを SQL Server 修正プログラムインストーラテクノロジのみに基づかせることをお勧めします。 SQL Server 修正プログラムインストーラ以外を使用する場合は、手動のファイルコピープロセスや TSQL スクリプトの実行が必要になり、特定の DLL との再バインドが必要になる可能性があります。SMS は、このような手順をセキュリティで保護された効果的な方法で確実に実行できません。ベースラインは、常に、最新の Service Pack (この資料の執筆時点では Service Pack 3) および SQL Server 修正プログラムインストーラを使用する修正プログラムに基づかせるようにします。

SQL Server 修正プログラム

SQL Server 修正プログラムを展開する方法

すべてのスタンドアロンコンピュータまたは修正プログラムが適用されるクラスタのプライマリ/アクティブノードを選択するクエリに基づくコレクションを作成します。
ソフトウェア更新の配布ウィザードを起動し、更新の種類で [ セキュリティの更新 ] を選択します。インベントリスキャンプログラムとしてセキュリティ更新ツールを選択していることを確認します。
関連する更新を選択、クリックしてソースファイルをダウンロード後、バイナリファイルを含む関連フォルダを参照します。
修正プログラムをスタンドアロンコンピュータまたはプライマリ/アクティブノードのみに配布します。 (修正プログラムインストーラが、関連ファイルをセカンダリ/パッシブノードに自動的に配布します。)

管理者は、修正プログラムの展開作業を完了した後に、標準の SMS ステータスビューアを使用して、修正プログラムが正常に作成され、配布ポイントに配布され、関連クライアントに送付され、正しくインストールされたかどうかを確認できます。また、管理者は以下のクエリを使用して、カスタム Web レポートを作成することもできます。

select CASE Severity WHEN -1073741824 THEN 'Error' WHEN 1073741824 THEN 
'Informational' WHEN -2147483648 THEN 'Warning' ELSE 'Unknown' END As 
'Severity', smsgs.MachineName as 'Mach Name', smsgs.Time, 
v_StatmsgInsStrings.InsStrValue from v_statusmessage smsgs join 
v_StatmsgInsStrings on v_StatmsgInsStrings.RecordID = smsgs.RecordID 
where smsgs.MessageID in('39997', '39998','39999') Order by smsgs.Time 
DESC

このレポートは、SMS サイト内で修正プログラムが正しくインストールされた場合と、されなかった場合に関する詳細情報を提供します。

このデータが返され、修正プログラムが正常に展開され、インストールされたときに、関連するサーバーを必要に応じて再起動できるように、稼動停止時間のスケジュールを設定する必要があります。

変更のレビュー

変更のレビューでは、修正プログラムが正常に実装されたかどうか、および修正プログラムが目的を満たしているかどうかを判断します。

たとえば、修正プログラムは、公開の最初の段階で正常に機能しても、その後に問題が発見されて、再評価が必要になる場合があります。

この場合、問題を解決する次の修正プログラムの特定や公開の中止などのオプションを決定する必要があります。変更の無効にする必要があれば、RFC 承認段階と同じように、経済的な調整および影響分析を実施する必要があります。

変更のレビューで入手した情報は、CMDB に追加される必要があります。

付録 B: Exchange 2000 Server への修正プログラムの適用

目的

この付録の目的は、Microsoft Exchange 2000 Server への修正プログラムの展開に、『Microsoftｮ Systems Management Server (SMS) を使用した修正プログラム管理 - ソリューションガイド』で説明している手順や作業をどのように使用するかの例を組織に提供することです。

以下の作業は、『Microsoft Systems Management Server (SMS) を使用した修正プログラム管理 - ソリューションガイド』で説明した手順に基づいています。

監査の実行

SMS ソフトウェアインベントリとハードウェアインベントリクライアントエージェントを、セキュリティの更新スキャンツール (SMS Software Update Services Feature Pack の一部) と併用して、実稼働環境内のすべての Exchange 2000 Server コンピュータを定期的に監査する必要があります。組織がベースラインを決定する前に、このようなコンピュータの状態の正確な記録を入手するのに、この監査が役に立ちます。また、監査の結果を使用して、構成管理データベース (CMDB) を更新する必要があります。

ベースラインの定義

通常、運用ベースラインには、Exchange 2000 Server の最新のサービスリリースを含める必要があります。この資料を執筆している時点の最新のサービスリリースは、Exchange 2000 Server Service Pack 3 です。

以下の SMS/SQL クエリは、Exchange 2000 Server を実行しているすべてのコンピュータとそれぞれのバージョン番号を識別します。このクエリは、ファイル Events.exe のバージョンとサービス MSExchangeMTA が自動開始に設定されているかどうかに基づいています。

select distinct SMS_G_System_SYSTEM.Name, 
SMS_G_System_SoftwareProduct.ProductName, 
SMS_G_System_SoftwareFile.FileVersion from SMS_R_System inner join 
SMS_G_System_SoftwareProduct on SMS_G_System_SoftwareProduct.ResourceID 
= SMS_R_System.ResourceId inner join SMS_G_System_SERVICE on 
SMS_G_System_SERVICE.ResourceID = SMS_R_System.ResourceId inner join 
SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceID = 
SMS_R_System.ResourceId inner join SMS_G_System_SoftwareFile on 
SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId where 
SMS_G_System_SoftwareProduct.ProductName = "Microsoft Exchange" and 
SMS_G_System_SoftwareProduct.ProductVersion >= "6" and 
SMS_G_System_SoftwareFile.FileVersion >= "6.0" and 
SMS_G_System_SoftwareFile.FileName = "EVENTS.EXE" and 
SMS_G_System_SERVICE.Name = "MSExchangeMTA" and 
SMS_G_System_SERVICE.StartMode = "Auto"

SMS データベース内の情報は、インストールが必要な一部のセキュリティ修正プログラムについての通知を提供しますが、管理者は電子メールによるセキュリティ情報を購読し、定期的に Microsoft Web サイトを参照し、すべての関連修正プログラムを確認する必要があります。セキュリティ修正プログラムと Exchange 2000 修正プログラムの電子メールによる通知を受け取るには、以下の Web ページから利用できるメーリングリストを購読します。

https://www.microsoft.com/japan/technet/security/default.mspx

https://www.microsoft.com/japan/technet/security/current.aspx

上記で一覧した通知サービスは、無償で提供されています。 Microsoft では、これらの通知サービスを使用して、Exchange 2000 Server などの Microsoft 製品のセキュリティに関する情報を購読者に配布しています。

変更開始

修正プログラム管理の変更の開始プロセスは、認識、関連性、および検疫の 3 つの主要コンポーネントで構成されます。

認識

Exchange 2000 の修正プログラムに関する情報は、電子メール通知、Microsoft Web サイト、SMS データベース内に含まれる情報など、多くのソースから届けられます。 SMS が不足していることを検出したセキュリティの修正プログラムを特定するには、「Applicable software updates for a specific product-Exchange 2000 Gold」 Web レポートを実行します。これにより、図 22 のようなレポートが生成されます。

図 22: Exchange 2000 Server に適用可能な修正プログラムを特定する SMS レポート

関連性評価

Exchange 2000 Server に適用できる修正プログラムはたくさんあるので、すべての修正プログラムを徹底的に検査して、組織との関連性を確認することが重要です。各修正プログラムの詳細レビューには、以下の項目が含まれます。

その修正プログラムを必要とする実稼働環境内のサーバー (存在する場合) を確認するための現在の Exchange 2000 Server 構成の調査。
メッセージング管理者からの入力。
すべての関連ドキュメントのレビュー。たとえば、修正プログラムと共に送付されたドキュメント、Microsoft の TechNet (https://www.microsoft.com/japan/technet/default.mspx) で見つかった補足情報などがあります。
修正プログラムの性質と目的の確認。通常は、関連する製品と CMDB の両方のサポート情報の詳しい調査を行います。

たとえば、取得した修正プログラムがクラスタ内のすべての Exchange 2000 Server サーバーにインストールする必要があるものであった場合に、組織に展開されている Exchange 2000 Server サーバーがすべてスタンドアロンの場合、この修正プログラムは無関係な修正プログラムです。

検疫

ウィルスの感染や悪質なコードによる組織の IT インフラストラクチャへの悪影響を防ぐため、修正プログラムのすべて関連ファイルは、独立した (検疫) 環境で検査する必要があります。この検疫は、すべてのソフトウェアおよびドキュメントに行う必要があります。隔離された環境では、これらは厳重に管理される必要があります。厳密な管理を確保するには、組織の専門家グループが検疫プロセスを実行する必要があります。検疫プロセスが完了すると、ファイルを配布の準備用の基準ソフトウェアライブラリ (DSL) フォルダに配布できます。

変更管理

すべての変更は、要求、分類、承認、および開発の変更管理プロセスによって管理される必要があります。

変更要求

管理者は、修正プログラムと関連する問題点や要件を詳しく示した変更の要求 (RFC) を発行する必要があります。変更の承認は、修正プログラムの配布の許可を発行します。詳細については、『Microsoft Systems Management Server を使用した修正プログラム管理 - ソリューションガイド』を参照してください。

変更分類

変更の開始者は、RFC の提示の一部として、その修正プログラムに優先順位とカテゴリを割り当てる必要があります。優先順位は、その修正プログラムがシステムに与える影響によって変化します。 Exchange 2000 Server の修正プログラムの大部分は再起動を必要とするので、稼動停止時間が修正プログラムの分類に影響します。

変更認可

変更の優先順位が緊急に設定されている場合、Microsoft Exchange 2000 Server を実行しているサーバーに関連する要求されたすべての変更 (修正プログラムのインストールを含む) は、変更諮問機関 (CAB) または変更諮問機関緊急委員会 (CAB/EC) によって検討され、レビューされる必要があります。

変更開発

修正プログラムを組織に配布する前に、新たな開発が必要になる場合があります。たとえば、Exchange の一部の修正プログラムは、バイナリの実行可能ファイルそのものではなく、圧縮されたファイルです (ファイルを使用する前にそのイメージからファイルを解凍する必要があります)。このような場合、ダウンロードした実行可能ファイルではなく、解凍したファイルを修正プログラムのソースとして使用する必要があります。

リリース管理

リリース計画

実稼働環境には数多くの異なる構成の Exchange が存在する可能性があるので、リリースマネージャは構成ごとに必要な異なるタスクや作業を特定する必要があります。たとえば、Exchange クラスタに修正プログラムを展開するために必要なタスクは、フロントエンド/バックエンド Exchange サーバーまたはスタンドアロンサーバーに展開するために必要なタスクと異なる可能性があります。また、サーバーから修正プログラムを削除する手順 (失敗した場合) も異なる可能性があります。

リリース構築

リリースチームのメンバは、リリースの方針に同意すると、リリースを実稼動に展開するためのプロセス、ツール、必要なテクノロジの開発を始めることができます。このプロセスの実行中に、リリースメカニズムの選択、リリースパッケージのデザイン、構築、およびテストを行う必要があります。ロールバック計画も開発し、テストする必要があります。

Exchange の一部の修正プログラムは、ダウンロード状態ではインストールできないことに注意することが重要になります。このような修正プログラムは、最初にアーカイブから抽出する必要があります。次に、抽出したファイルを調査とその後の配布のために、検疫領域に配置します。

可能であれば、SMS/SUS Feature Pack の配布ウィザードを使用して、修正プログラムを配布します。ただし、Exchange のカスタム修正プログラムまたは Exchange 2000 Server Service Pack を配布する場合は、ソフトウェア配布の通常の SMS プロセスに従って、プログラムや提供情報を開発する必要があります。

注意Exchange の修正プログラムを配布するときは、再起動を抑え、予期しない稼動停止時間を避けることをお勧めします。

最後に、テスト完了後、適切なバイナリファイルで DSL を更新し、それに合わせて CMDB を更新します。

受け入れテスト

受け入れてストの詳細については、『Microsoft Systems Management Server を使用した修正プログラム管理 - ソリューションガイド』を参照してください。

テストが正常に完了したら、リリース準備レビューのスケジュールを設定する必要があります。このレビューでは、適切な担当者が開発とテストの結果をレビューし、修正プログラムの公開を承認するために、修正プログラムの開発とテストが正常に行われたかどうかを判断します。

展開計画

リリースの計画段階には、リリースを実稼動に物理的に展開するのに必要なすべてのタスクと作業が含まれます。展開マネージャは調査を実施して、影響しそうなネットワークの制限事項、利用可能な帯域幅、十分な配布ポイント、修正プログラムの優先順位 (たとえば、ユーザーがインストールを行うためにネットワーク接続を失うほど修正プログラムが重要かどうか)、および SMS インベントリが最新であることを明確にする必要があります。

修正プログラムをインストールする順序とスケジュールを計画します。 Exchange に修正プログラムをインストールするときは、ある日は一部のサーバーに修正プログラムをインストールし、別の日には他のサーバーにインストールして、ビジネス上重要なデータベースの稼働時間を増加する必要があります。

展開準備

新しいリリースごとに、実稼働環境を準備する必要があります。このテストには、以下の項目を含める必要があります。

メッセージング管理者への通知。
稼動が停止する可能性のあるユーザーへの通知。
サポート担当者を支援するトレーニングのスケジュール設定。
テスト環境からのプログラムと提供情報のインポート。
修正プログラムと関連バイナリファイルの存在を確認するための、配布ポイントの調査。

展開

注意展開を開始する前に、展開によって影響を受ける各 Exchange 2000 サーバーで、主要なデータベースとメッセージングインフラストラクチャをすべてバックアップします。

以下の SMS クエリは、最新バージョンの Exchange 2000 Server Service Pack 3 を実行していないすべてのコンピュータの詳細を示します。

select distinct SMS_G_System_SYSTEM.Name, 
SMS_G_System_SoftwareProduct.ProductName, 
SMS_G_System_SoftwareFile.FileVersion from SMS_R_System inner join 
SMS_G_System_SoftwareProduct on SMS_G_System_SoftwareProduct.ResourceID 
= SMS_R_System.ResourceId inner join SMS_G_System_SERVICE on 
SMS_G_System_SERVICE.ResourceID = SMS_R_System.ResourceId inner join 
SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceID = 
SMS_R_System.ResourceId inner join SMS_G_System_SoftwareFile on 
SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId where 
SMS_G_System_SoftwareProduct.ProductName = "Microsoft Exchange" and 
SMS_G_System_SoftwareProduct.ProductVersion >= "6" and 
SMS_G_System_SoftwareFile.FileVersion < "6.0.6249" and 
SMS_G_System_SoftwareFile.FileName = "EVENTS.EXE" and 
SMS_G_System_SERVICE.Name = "MSExchangeMTA" and 
SMS_G_System_SERVICE.StartMode = "Auto"

https://www.microsoft.com/japan/SMSERVER/techinfo/administration/20/integrating/clusterinterop.asp

管理者は、スタンドアロン Exchange 2000 Server サーバー、アクティブ/パッシブ Exchange 2000 Server クラスタ、またはアクティブ/アクティブ Exchange 2000 Server クラスタに修正プログラムを展開するときに必要な技術的な手順を理解する必要があります。

スタンドアロン Exchange 2000 Server への修正プログラムの適用

スタンドアロン Exchange 2000 Server サーバーに修正プログラムを展開する方法

修正プログラムを適用するすべての Exchange サーバーを選択するクエリに基づいてコレクションを作成します。
ソフトウェア更新の配布ウィザードを起動し、更新の種類で [ セキュリティの更新 ] を選択します。インベントリスキャンプログラムとしてセキュリティ更新ツールを選択していることを確認します。
関連する更新を選択、クリックしてソースファイルをダウンロード後、バイナリファイルを含む関連フォルダを参照します。
修正プログラムを配布する前に、関連する ESM コンソールおよび Exchange サービスがすべてシャットダウンされていることを確認します。これは再起動を防ぐのに役立ちます。
修正プログラムをスタンドアロン Exchange コンピュータに配布します。
完了時に必要なサービスをすべて再開します。

アクティブ / パッシブ Exchange 2000 クラスタ

注意クラスタでは、優れた信頼性と冗長性のために、修正プログラムを手動で配布するか、SMS とその他の追加スクリプトを使用して配布するかを選択できます。この追加スクリプトは、修正プログラムのインストール中にクラスタの自動的なフェールオーバーを容易にするために開発されるものです。

アクティブ / パッシブ Exchange 2000 Server サーバークラスタに修正プログラムを展開する方法

修正プログラムを適用するすべての Exchange 物理ノードサーバーを選択するクエリに基づいてコレクションを作成します。
ソフトウェア更新の配布ウィザードを起動し、更新の種類で [ セキュリティの更新 ] を選択します。インベントリスキャンプログラムとしてセキュリティ更新ツールを使用することを確認します。
関連する更新を選択、クリックしてソースファイルをダウンロード後、バイナリファイルを含む関連フォルダを参照します。
修正プログラムを配布する前に、関連する ESM コンソールおよび Exchange サービスがすべてシャットダウンされていることを確認します。これは再起動を防ぐのに役立ちます。
クラスタ内のパッシブノードに修正プログラムを配布します。
手動またはスクリプト化されたプロシージャの使用のいずれかにより、"すぐに"クラスタグループを他のノードに移動します。これは、このプロセス中にデータベースがアップグレードされるためです。
新しいパッシブノード (以前はアクティブノードだったノード) に修正プログラムを配布します。
完了時に必要なサービスをすべて再開し、通常の構成にフェールオーバーします。

アクティブ / アクティブ Exchange 2000 クラスタ

注意クラスタのシナリオでは、優れた信頼性と冗長性のために、修正プログラムを手動で配布するか、SMS とその他の追加で開発されたスクリプトを使用して配布するかを選択できます。このスクリプトは、修正プログラムのインストール中に、クラスタの自動的なフェールオーバー手順を容易にします。

アクティブ / アクティブ Exchange 2000 Server サーバークラスタに修正プログラムを展開する方法

修正プログラムを適用するすべての Exchange 物理ノードサーバーを選択するクエリに基づいてコレクションを作成します。
Exchange をシングルノードに移行します (つまり、アクティブ/パッシブクラスタになります)。
ソフトウェア更新の配布ウィザードを起動し、更新の種類で [ セキュリティの更新 ] を選択します。インベントリスキャンプログラムとしてセキュリティ更新ツールを使用することを確認します。
関連する更新を選択、クリックしてソースファイルをダウンロード後、バイナリファイルを含む関連フォルダを参照します。
修正プログラムを配布する前に、関連する ESM コンソールおよび Exchange サービスがすべてシャットダウンされていることを確認します。これは再起動を防ぐのに役立ちます。
クラスタ内のパッシブノードに修正プログラムを配布します。
手動またはスクリプト化されたプロシージャの使用のいずれかにより、"すぐに"クラスタグループを他のノードに移動します。これは、このプロセス中にデータベースがアップグレードされるためです。
新しいパッシブノード (以前はアクティブノードだったノード) に修正プログラムを配布します。
クラスタを再度アクティブ/アクティブ設定にします。
完了時に必要なサービスをすべて再開します。

select CASE Severity WHEN -1073741824 THEN 'Error' WHEN 1073741824 THEN 
'Informational' WHEN -2147483648 THEN 'Warning' ELSE 'Unknown' END As 
'Severity', smsgs.MachineName as 'Mach Name', smsgs.Time, 
v_StatmsgInsStrings.InsStrValue from v_statusmessage smsgs join 
v_StatmsgInsStrings on v_StatmsgInsStrings.RecordID = smsgs.RecordID 
where smsgs.MessageID in('39997', '39998','39999') Order by smsgs.Time 
DESC

このレポートは、SMS サイト内で修正プログラムが正しくインストールされた場合と、されなかった場合に関する詳細情報を提供します。

このデータが返され、修正プログラムが正常に展開され、インストールされたときに、関連するサーバーを必要に応じて再起動できるように、稼動停止時間のスケジュールを設定します。

変更レビュー

変更レビューでは、修正プログラムが正常に実装されたかどうか、および修正プログラムの機能が目的を満たしているかどうかを判断します。

たとえば、修正プログラムは、公開の最初の段階で正常に機能しても、その後に問題が発見されて、再評価が必要になる場合があります。

変更レビューで入手した情報は、CMDB に追加される必要があります。

寄稿者

プログラムマネージャ

Anthony Baron, Microsoft Corporation

Nigel Cain, Microsoft Corporation

主執筆者

Ben Gamble, Microsoft Corporation

Kamal Patel, Microsoft Corporation

Andrew Speake, G2G3 Group Ltd.

その他の寄稿者

Josh Bradbury, PCR Recruitment

Andrew Savvides, consultant

Mark Ross Sutherland, G2G3 Group Ltd.

QA マネージャ

Jim Ptaszynski, Microsoft Corporation

テクニカルライタ

Jerry Dyer, Microsoft Corporation

Angus Stewart, G2G3 Group Ltd.

編集者

Bill Karn, Volt Technical Services

Patricia Rytkonen, Volt Technical Services

Christine Waresak, VMC Consulting

編集者

Kevin Klein, Volt Technical Services

このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。

このドキュメントは情報提供のみを目的としており、明示、黙示、または法律上の保証に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。

ただしこれは、著作権法上のお客様の権利を制限するものではありません。マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。

別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メールアドレス、ロゴ、人物、出来事などの名称は架空のものです。実在する会社、組織、商品、ドメイン名、電子メールアドレス、ロゴ、個人名、場所、出来事などとは一切関係ありません。

Microsoft、 Active Directory、BackOffice、Outlook、Visio、Windows、Windows NT、および Windows Server は米国 Microsoft Corporation の米国またはその他の国における登録商標または商標です。

記載されている会社名、製品名には、各社の商標のものもあります。

Microsoft Systems Management Server を使用した修正プログラム管理

ソリューション ガイド

トピック

はじめに

このガイドの要点

修正プログラムの展開

付録

寄稿者

その他のリソース

ソリューションガイド