Microsoft Systems Management Server を使用した新規アプリケーションのインストール

  • [アーティクル]

展開ガイド

トピック

概要
新規ソフトウェアのインストール
付録

概要

はじめに

本書の目的

本書は、データ センターまたは企業のコンピュータ処理環境で Microsoft テクノロジを展開済みである、または展開を検討している組織内で、新規ソフトウェアのインストールを管理するためのガイダンスを提供します。 新規ソフトウェアのインストールの管理に関する概念情報、ベスト プラクティス、および詳細手順について説明します。

対象読者

本書は、Microsoft Services Organization およびパートナーのコンサルティング企業を対象としています。 本書は、ユーザーの観点からは、情報技術 (IT) 実稼動環境に変更を導入またはサポートする IT マネージャと IT サポート担当者のメンバという 2 つの主要なグループを主な対象にしています。

本書は、読者が Microsoft Operations Framework (MOF) のプロセス モデル、チーム モデル、およびリスク モデルに精通し、使用できることを前提としています。 これらのモデルについて説明されているドキュメントのコピーは、https://www.microsoft.com/japan/systemcenter/default.mspx から入手できます。

この展開ガイドは、MOF の変更エリアに含まれるサービス管理機能 (SMF) に基づいて作成されているので、この SMF にも精通していることも重要になります。

このガイドの要点

このガイドでは、組織内の人、プロセス、テクノロジが関与して、新規ソフトウェアのインストールを管理するベスト プラクティスを提供します。

このアプローチは、MOF と Microsoft Solutions Framework (MSF) に基づいており、Microsoft Office XP などの新規ソフトウェアの展開を実現する完全なソリューションを提供します。 このガイドでは、このような展開の実行に必要な Microsoft の補完的なテクノロジとプロセスの詳細について説明し、関連ドキュメントへのリンクを提供します。 このガイドと関連ドキュメントでは、Microsoft 製品とテクノロジによる基幹業務実稼動システムの信頼性、可用性、管理の容易性を実現する手段を提供します。

本書の「変更管理」と「リリース管理」で示す高度なプロセス フローは、組織のデスクトップ環境やモバイル環境に新規ソフトウェアの必要なバージョンを導入する上での包括的な原理を示しています。 このようなプロセスによって、組織内での新規ソフトウェアの展開が反復可能、スケーラブル、かつ管理可能となり、コストを最小化して生産性を最大化できることを保証します。 MOF プロセスと MSF プロセスを使用することにより、迅速でシームレスな統合を実現する方法で、新規展開を管理およびカスタマイズできます。

新規ソフトウェアのインストール

管理プロセスとアクティビティ

概要

組織は、新規ソフトウェアのインストールを管理することにより、異なるバージョンや互換性のないバージョンのプログラムの展開または使用が原因で発生する問題点を除去できます。

以下のフローチャートに、効果的なインストールに必要な高度なプロセスを示します。

図 1: 新規ソフトウェアのインストールを管理するためのフローチャート

図 1: 新規ソフトウェアのインストールを管理するためのフローチャート

この大まかなフローチャートは、新規ソフトウェアのインストールを管理するための包括的な詳細計画です。 本書では Office XP の新規インストールの展開を例として使用していますが、SMF 関連のガイド全般に含まれているこのようなフローチャートは、すべてのソフトウェア製品の新規インストールに当てはまります。

新 規ソフトウェアのインストール用の管理ツール

新規ソフトウェアの展開、特に Office XP のような大規模プログラムを展開するには、自動化されたツールが必要になります。このようなツールを使用すると、組織は展開の計画に必要なインベントリ情報を取得し、管理者はインストールのスケジュールを設定および管理できます。 合意済みの標準に従ってインストールをカスタマイズしたり、特定のユーザーの役割や職務権限を反映するには、新たなツールが必要になることもあります。

以下のセクションでは、組織内で新規ソフトウェアの展開をサポートするために使用される Microsoft のツールを識別し、説明します。 特定の環境で使用されるツールの数や種類は、組織の規模や予算など、多くの要因によって変化します。

Microsoft Systems Management Server

Systems Management Server (SMS) には以下のような重要な機能が含まれているので、新規ソフトウェア配布の展開と管理に好んで選択されるメカニズムです。

  • ソフトウェア インストールを開始する前に、どのコンピュータがソフトウェアを必要とするか、どのコンピュータが更新を必要とするかを判断するインベントリを取得する能力。

  • 勤務時間外、または通常のビジネス運用への影響が最も少ない時間帯に、ソフトウェア展開のスケジュールを設定する能力。

  • 管理者がインストールの進捗を監視できるステータス レポートを表示する能力。

  • システム インベントリに基づいて、手動で作成したグループまたは Microsoft Active Directoryｮ ディレクトリ サービスでコンピュータの位置付けを示す能力。

  • 組織が、ネットワーク経由で、簡単かつ効果的に新規ソフトウェアを移動できるようにするエンタープライズ レプリケーション。

  • Microsoft Windowsｮ 2000 および Windows XP 以外のオペレーティング システムのサポート。

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

カスタム インストールウィザード (CIW)

大企業ユーザーは、Office XP などの新規ソフトウェアを、企業内のすべてのユーザーに同じ方法で展開することはあまりありません。 熟練したユーザーが Office XP のすべてのアプリケーションを必要とすることもあれば、仕事上の役割を実行するために Microsoft Word のみを必要とするユーザーもいます。 管理者はカスタム インストール ウィザード (CIW) により変換 (MST) ファイルを作成できます。このファイルを使用して、特定の機能を選択的にインストールしたり、特定の機能を削除することにより、通常のインストールをカスタマイズします。

  • テクノロジ メモ Office XP は、Windows と同様に、ユーザーが Office XP 環境に適用できるすべての設定を格納する "プロファイル" を使用します。 このような設定には、チーム ドキュメントの場所から既定のフォントまで何でも含めることができます。 管理者は Office プロファイル ウィザード (OPW) を使用して、このような設定がインストール中に構成されるように、事前に定義できます。

上記のカスタム インストール ウィザードによって作成された MST ファイルと共に、OPW が保存したプロファイルが使用されます。

グループ ポリシー

Office プロファイル ウィザードで記述される構成オプションの多くは、Windows のグループ ポリシーを使用して定義できます。 管理者はこれらの設定をユーザーごとまたはコンピュータごとに定義し、グループ ポリシーにより実施させることができます。 組織がこの方法でグループ ポリシーを使用することを計画をしている場合、必要な変更を行う前に、グループ ポリシーの既存の実装を評価する必要があります。

以下のホワイト ペーパーには、長期運用向けにグループ ポリシーを構成する方法が記述されています。

https://www.microsoft.com/japan/technet/archive/ittasks/maintain/s2impgp.mspx

https://www.microsoft.com/japan/technet/archive/ittasks/maintain/s1impgp.mspx

変更管理

新規インストールのコンテキストにおける変更とは、IT 環境に意図的に導入され、IT サービス レベル アグリーメント (SLA)、IT 環境またはそのコンポーネントの一部の機能に影響を及ぼす可能性のある、ソフトウェアの何らかの追加を意味します。 変更には、一時的な変更と永続的な変更があります。 永続的な変更は、コンポーネントの現在のバージョンを完全に置き換えます。 一時的な変更は、期間限定で、または永続的な変更が実装されるまで、暫定的に適用されるものです。

変更が一時的か永続的かにかかわらず、この定義に分類されるすべての変更は変更管理プロセスで管理します。

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

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

この図 2 は、変更管理の大まかなフローチャートです。詳細については、『MOF Change Management SMF Guide』を参照してください。 このガイドは、https://www.microsoft.com/japan/systemcenter/default.mspxから入手できます。

以下のセクションでは、変更の開始から変更開発完了に至るまで、変更管理プロセス全体で新規ソフトウェアをインストールするプロセスを詳しく説明します。 その後のセクションでは、リリース管理について説明します。

変更管理の詳細情報が必要な場合は、『MOF Change Management SMF Guide』を参照してください。

変更要求

その他のすべての変更要求 (RFC) と同様に、変更の開始者は、提案する変更が新規インストールと展開に及ぼす影響を認識する必要があります。 たとえば、Office XP の新規インストールを 1 台のワークステーションに展開する場合は、複雑な影響を及ぼしません。 一方、Office XP Professional の新規インストールを複数のサイトにまたがる組織に公開する場合は、複雑な影響を及ぼす可能性があります。 後者の場合、変更の開始者は、変更によるすべての影響を判断できないにしても、構成マネージャやその他の専門スタッフと協力して最善を尽くす必要があります。

新規ソフトウェアのインストールに取り組んでいる変更の開始者が、展開に関する前提条件、順序、競合などに気が付いた場合は、RFC Web フォームに記入する必要があります。これは、対象のコンピュータにオペレーティング システムだけがインストールされている場合、またはソフトウェアの以前のバージョンがインストールされていない場合も同様です。

たとえば、Office XP Professional は、Windows 98 以上のオペレーティング システムがインストールされたコンピュータのみに展開可能です。Windows NTｮ 4.0 がインストールされたコンピュータに展開する場合は、Service Pack 6 のインストールと 245 MB 以上のハードドライブの空き容量が必要です。

変更の開始者が新規ソフトウェアの展開要求を提出するときは、RFC の優先順位とカテゴリを定義する必要があります。 この定義に影響を及ぼす要因がいくつかあります。

新規ソフトウェア製品の場合、RFC には対象製品の展開の理由、対象者、時期に関する詳しい説明を記入します。 この場合、実稼動環境に製品の新規インストールを追加することになるので、大きな変更に分類されます。 変更の開始者は、ライセンス関連などさまざまな費用がデザイン段階、構築段階、およびテスト段階でも発生するので、この段階で経済的に正当化する準備が必要になります。

また、RFC を提出する計画段階で、ライセンスの取得計画と調達計画を検討して準備する必要もあります。 Office XP の場合、製品の購入またはライセンスの取得について、さまざまなオプションを検討できます。 Office XP は世界中の小売店で購入できますが、企業や組織は企業のニーズに合わせて特別にデザインされたボリューム ライセンス プログラムによる特典を受けることができます。

  • 注意Microsoft のボリューム ライセンス プログラムは、小売パッケージ製品の購入に比べ、優れた柔軟性、高い価値、容易なライセンス管理を組織向けに提供します。 組織はライセンスの取得によって、組織内で Office XP を合法的にコピーして再配布する権利を自動的に取得できます。 ライセンスの範囲は、契約条件によって、追加サービス、アップグレード、およびその他の特典に及びます。

組織に固有の要件や組織の規模に応じた、さまざまなライセンス プログラムが用意されています。 ボリューム ライセンス プログラムの詳細については、ソフトウェア再販業者に問い合わせるか、または https://www.microsoft.com/japan/licensing/Default.asp を参照してください。

また、RFC には、展開対象の製品の種類やバージョンなどの関連詳細情報をすべて記入することも重要になります。 たとえば、Office XP の場合、アプリケーションやサービスの異なるコレクションを含む数種類の製品群を利用できます。 このため、インストールの前提条件も異なります。

変更要求で正確な情報が提供されいること、正常にプロセスが完了したことを確認するには、新規インストール用に特定の RFC Web フォームを使用する必要があります。 このフォームには、RFC に添付する付属ドキュメントとは別に、バージョンやカスタマイズなどの詳細情報を記入できます。 このフォームに詳細情報が正しく入力されていることを検証することにより、情報不足が原因で RFC が却下される事態を最小限に抑えることができます。 たとえば、ライセンス費用、影響するユーザー数、変更と前提条件の詳細などに関する十分な情報が入力されていないと、RFC は情報不足として却下される可能性があります。 この検証作業により、RFC が却下されて変更の開始者に返却されることが原因で、変更の開始者だけでなくビジネスにも遅延が生じる事態を回避できます。

新規インストールの RFC は、その他の変更と同様に、検証プロセスに関する SLA を満たす必要がある場合があります。 たとえば、Office XP の RFC には、エスカレーションなど、RFC に添付される適正審査プロセスやサポート プロセスに関する応答時間が定義されています。 新規製品の展開に関する RFC が適切な期間内に評価されなかった場合、組織に多大な費用が発生する可能性があります。

新規インストールの期限は、特に限定されない場合がほとんどですが、新規ユーザー用の新しいコンピュータをそのユーザーが到着するまでに構築して用意するような場合は例外です。 このような場合、SLA は、変更の開始者が決定し、RFC に記載された情報に基づいた変更の優先順位とカテゴリにリンクされて、SLA のスケジュールに関する制限をバックアップします。

反対に、たとえば、新規組織戦略プロジェクトの計画に、2002 年 9 月までに全部門で Office XP Professional を使用するという目標が盛り込まれている場合は、新規インストールの期限が限定されます。RFC の適正審査に関する SLA は、この目標の達成を阻止するのではなく、サポートする必要があります。

  • テクノロジ メモ変更の開始者は、RFC を提出する前に、Office XP を実行する必要のあるコンピュータの数と場所、およびその結果必要になる製品ライセンスの数を識別するのに役立つ SMS クエリと Web レポートを作成する必要があります。 ライセンス費用は製品のエディション間で異なるので、ソフトウェアのどのバージョン (Standard、Professional、または Developer) がインストールされるかを示すレポートを作成する必要があります。

Dd283246.naidg03s(ja-jp,TechNet.10).gif

図 3: 影響を受けるコンピュータ数の検索
拡大表示する

組織では、ライセンス費用を削減するために、開発者以外の全ユーザーのコンピュータに Office XP Standard エディションを、開発者には Developer エディションまたは Professional エディションをインストールする場合があります。 変更の開始者は、そのような内訳を明示するレポートを作成する必要があります。

どの実稼動環境にも、Office XP を実行できないコンピュータ、つまり置き換えるまたはアップグレードする (追加メモリ、より大容量のディスク、より高速の CPU を取り付ける) 必要のあるコンピュータが多数存在することがあります。 このようなコンピュータは、通常、ハードウェア インベントリおよびソフトウェア インベントリ中に取得された情報を使用して識別できます。 変更の開始者は、展開前に、置き換えやアップグレードが必要なコンピュータをリストした詳細レポートを作成する必要があります。

Office XP を実行するシステムの最低条件および推奨条件については、以下の Microsoft の Web サイトを参照してください。

https://www.microsoft.com/office/previous/xp/sysreqs.asp (英語)

レポートに必要なシステム条件を満たさない 1 台以上のコンピュータが明記されている場合、変更の開始者は別の (ただし、リンクされた) RFC でアップグレードを要求するか、元の RFC の一部としてハードウェアのアップグレードを要求します。

変更の開始者は、SMS Web レポート ツールを使用して、各レポートの URL を RFC に挿入できます。変更マネージャは、このリンクからレポートを実行して、より最新の状況を取得できます。

変更分類

変更の開始者は、RFC を提出する際に、RFC の優先順位とカテゴリを判断します。 この判断は、その他の変更と同様に、Office XP Standard などの新規ソフトウェアをインストールするときも同じです。 ただし、適正審査プロセスには、優先順位とカテゴリの詳細調査する変更マネージャが含まれます。

割り当てる "優先順位レベル" によって、変更認可と展開の "速度" が決まります。 一般的に、優先順位が高いほど、必要なプロセスは迅速に処理されます。

以下に優先順位の 4 つのレベルを示します。

  • 緊急 (Emergency)。 できるだけ早急に展開する必要があります。影響度は大です。

  • 高 (High)。 緊急な変更の次にできるだけ早急に展開する必要があります。 これも影響度は大です。

  • 中 (Medium)。 適切な期間内に展開する必要があります。影響度は中です。

  • 低 (Low)。 次の適切な Service Pack のリリース時または展開時に展開する必要があります。 影響度は小です。

割り当てる "カテゴリ" によって、承認前に変更について調査する "詳細度" が決まります。 変更のカテゴリのレベルが高くなるほど、その変更が組織に与える影響の度合いは大きくなる傾向があります。このため、承認プロセスには、優れた知識と権限を持つ意思決定者が携わることが重要になります。

カテゴリは、変更によって必要となる開発作業の範囲にも影響します。 高レベルのカテゴリに属する変更ほど、より長期間の開発作業、多数のさまざまな人的資源、多額の資本投資が必要になります。

以下にカテゴリの例を示します。

  • 重大 (Major)。 影響を受ける可能性のあるユーザーやビジネスに不可欠なシステムの割合が最も多い変更です。 変更は、新しいテクノロジまたは構成変更になる場合があります。 ネットワークまたはサービスの停止時間が発生する可能性があります。

  • 深刻 (Significant)。 影響を受けるユーザーの割合が比較的多い変更です。 変更の内容は、新製品、新規ユーザー、ネットワークの変更など、非標準の変更です。ネットワークまたはサービスの停止時間が発生する可能性があります。

  • 軽微 (Minor)。 影響を受けるユーザーの割合が比較的少ない変更です。組織には提案された変更を展開した経験があるので、リスクは比較的低くなります。

  • 標準 (Standard)。 影響を受けるユーザーの割合が最も少ない変更で、リリース プロセスが設定されています。

企業規模の新規インストールの展開は、開始時に関連する時間、労力、費用の投入が必要であり、多数のコンピュータやユーザーに影響するので、重大な変更に分類されます。 この初回の変更が成功すると、信頼済みのインストール プロセスとなり、分類のレベルは低くなる場合があります。 また、失敗した場合の影響や購入費用も RFC の分類に影響する可能性があることに注意してください。

ライセンス関連の費用は、展開の費用と見なされます。 RFC に関するすべてのライセンス情報を取得するには、構成管理データベース (CMDB) にアクセスする必要があります。このデータベースには、変更の開始者が提供した情報以外の補助情報が格納されている可能性があります。 この変更レビュー作業は、展開されるソフトウェアのレベル (Office XP Standard、Professional、または Developer など)、ライセンス モデル、ソフトウェア コンポーネントの展開に関連する費用などに関する問題点を識別するのに重要になります。 たとえば、Office XP を考えると、Microsoft Access を Office XP Professional 製品群の一部として展開するか、Office XP Standard の展開の追加要素としてインストールするかという疑問が生じます。 どちらの選択肢にも、考慮すべき費用が存在します。 このような費用は、特定のアプリケーションを必要とするユーザーの数によって決まります。 ユーザー数が 10,000 の人の組織で、9,500 人のユーザーが Office XP Standard のアプリケーション (Word、Microsoft Excel、Microsoft Outlook、Microsoft PowerPoint) だけを必要としており、残りの 500 人のユーザーが Access (Office XP Professional のアプリケーション) も必要としている場合、マネージャは残りのユーザー用に Office XP Professional を購入するか、または Access を別途購入するかを決定する必要があります。

組織や初期の RFC に記載されたライセンス契約や調達契約によって費用が発生する場合は、標準の事前承認された製品のインストールに適しているとは見なさないでください。 たとえば、サービス デスクが実行するインストールで、インストールする製品のライセンスが必要になります。 効率的な費用管理を確実に行うには、適切なレベルでの追跡と承認が必要になります。

使用する優先順位は、提示されたその他の RFC と同じです (緊急、高、中、低)。

緊急優先順位のソフトウェアの展開の例では、同期が取れた企業標準をビジネス パートナーに提供するために、ある期日に合わせるように Office XP を展開する場合があります。 この展開が複雑になる要因は、新規サポート契約ではサポート チームが Office XP に精通し、そのユーザーとなることが必要とされているのに、外部委託先のサービス プロバイダでは Office 2000 Professional しかインストールされていないような場合です。

低優先順位のソフトウェア展開の例は、Office XP が 20,000 台のクライアントに既に適用されていて、試験済みで、信頼済みである場合が該当します。

標準 RFC の例としては、同一の手法を使用して、新規 PC に Office XP のアプリケーションをインストールすることが挙げられます。

  • 注意ソフトウェアの展開は、初回から標準の変更として扱われることはありません。いったん展開された後、試行や試験まで完了して初めて標準の変更となります。 事前承認された標準の変更は、新規ソフトウェアのインストール費用の妥当性に応じて、各組織内で評価される必要があります。

変更マネージャは、この時点で、影響分析を実施する必要があります。 変更の優先順位とカテゴリを判断する際は、意思決定プロセス時に、スケジュールの制約、対象の取得、ライセンス、脅威分析、RFC の妥当性をすべて検討します。

新規製品の展開の RFC フォームには、このような分析項目を記入する必要があります。ただし、変更マネージャは、RFC を分類する上で詳細が十分であることを確認する必要があります。

  • テクノロジ メモ要求の優先順位を容易に決定するために、変更マネージャと変更諮問委員会 (CAB) のメンバは、SMS データベースを検索し、Office XP のインストールが必要なコンピュータ数を確認し、必要な製品ライセンスの数と種類を確認することを希望する可能性があります。 また、Office XP の最低条件や推奨条件を満たしていないと判断されたコンピュータのアップグレード費用を評価することも希望します。 このレベルを満たしていないコンピュータの数を示すレポートは、その時点で展開を続行すべきかどうかを判断するのに非常に役立ちます。

変更の開始者が提供するレポートには、変更マネージャと CAB が必要とするすべての情報が含まれている必要があります。 ただし、SMS Web レポート ツールにより、さらに詳細なレポートを生成できます。 変更マネージャは、インストールの優先順位とカテゴリがコンピュータごとに異なることを識別できる場合があります。 一部のコンピュータがその他のコンピュータに比べてビジネス上重要な場合、カテゴリと優先順位は RFC 単位で決定されるので、別個の RFC として処理する方が適しています。

変更認可

新規ソフトウェアの RFC の承認プロセスは、基本的にはその他の種類の変更と同じです。 このプロセスの詳細については、変更管理 SMF を参照してください。 ここでは、新規ソフトウェア要求に関する以下の特定の考慮事項について説明します。

  • RFC のカテゴリと優先順位は共に、承認プロセスで検討されます。

  • ソフトウェアの展開に関する RFC の場合でも、標準の変更とは、事前承認された変更です。変更を標準の変更と断定する前に、その変更が既に展開されていて、試行および試験済みであることを確認することが重要になります。 変更分類を事前承認済みの標準の変更に変更することを決定するのは CAB です。CAB は事前定義されたプロセスに従って決定します。

  • 標準の変更を新規製品に使用するのは、費用が発生する場合は適していない場合があります。 たとえば、ある組織で標準の変更として選択したグループに Office XP Professional を初めて展開した後で、ユーザーが増加する場合があります。 インストールを管理されていない場合は、ライセンス契約に違反し、追加費用が発生するので、元の経済的な正当性は無効になります。 このような場合、事前承認済みの変更としてこの変更を許可する前に、調達プロセスと契約プロセスを確認する必要があります。

  • 変更マネージャは軽微な変更は承認できますが、ソフトウェア展開の RFC によっては、常に、CAB の許可が必要なものもあります。 たとえば、Microsoft 製品以外の製品から Office XP Professional に移行する組織全体の戦略的決定などによる組織の標準ソフトウェアの変更は、明らかに CAB の承認が必要です。 正常に実装するには、多大な影響を及ぼす可能性のある広範な変更については、CAB のメンバが承認するようにします。

変更マネージャの承認

変更マネージャは、変更管理システムで保持された RFC と付属ドキュメントを調査して軽微な変更を承認します。 新規ソフトウェア製品のインストール CD-ROM は、確定版ソフトウェアの保管庫 (DSL) に保管する必要があります。 軽微な変更には、1 人のユーザーまたは 1 台の新規コンピュータに対する展開、機能強化のための既存のソフトウェアの構成などがあります。

  • 注意変更マネージャは、ソフトウェアのバージョンの違いも 1 つの要因であることを認識する必要があります。 たとえば、現在、Office XP 製品群には Standard、Professional、Developer の 3 種類があります。 上記で説明した軽微な変更の場合、関係する費用が発生するときは、状況を確認した上で RFC を再分類する必要があることがあります。

変更マネージャは、利用可能なソフトウェアのバージョンはどれか、また必要な追加アプリケーションがそのバージョンに含まれているかどうかを考慮する必要があります。 たとえば、Access をインストールする必要のあるユーザーが、ワークステーションに Office XP Professional を既にインストールしている場合、Access をインストールしないようにカスタマイズしていただけなので、ライセンス費用は発生せず、単純に Access をインストールするだけで済みます。 しかし、Office XP Standard をインストールしていた場合は、Access のライセンスか、Office XP Professional へのアップグレードの追加費用が発生します。

標準の変更や軽微な変更でも、費用の妥当性を判断するのは変更マネージャの責任です。 変更管理者は、ライセンス契約内容の確認、脅威分析の実行 (RFC を展開しない場合の費用と展開する場合の費用) 、変更の開始者が最初に実行した影響分析の拡張と確認、RFC に設定可能なスケジュール (展開を完了する期限) の評価、CMDB の検索による調達の確認などを実行します。 この時点で、予算承認も要求する必要があります。 承認されない場合、変更を却下する必要があります。

CAB の承認

新規製品の展開の RFC の場合は、変更マネージャと変更の開始者は、適切なグループが CAB を代表していることを確認する必要があります。 組織で初めて展開する製品の場合、関係者と担当がまだ十分に定義されていない可能性があります。 そのため、変更の開始者と変更マネージャは、協力して CAB の関係メンバの参加を確保する必要があります。

CAB の承認プロセスには、経済的な妥当性検査を含める必要があります。 変更管理者は、ライセンス契約内容の確認、脅威分析の実行 (変更を展開しない場合の費用と展開する場合の費用) 、変更の開始者が最初に実行した影響分析の拡張と確認、RFC に設定可能なスケジュール (展開を完了する期限) の評価、CMDB の検索による調達の確認などを実行します。

このような考慮事項によって取得した詳細情報は、CAB が新規ソフトウェアのインストールについて決定する上で重要になります。 この分析には長い準備期間が必要であり、通常は変更の開始者が CAB が集まる前に準備します。

RFC の情報が不足している場合、CAB は決定を下すことができません。 RFC は却下されるので、変更の開始者は不足情報をすべて補足し、RFC を再提出する必要があります。

CAB のメンバは、決定を支援するために、RFC の承認 Web フォーム上のリンクを使用して、付属ドキュメントが保存されている共有場所またはサーバーにアクセスします。 このレビューには、新規製品に関する付属ドキュメントの表示、ライセンス契約の確認、経済的な妥当性の確認、潜在的な影響の分析、Outlook メッセージングとコラボレーション クライアントを使用した現在の変更スケジュールのレビューなどを含めることができます。

変更マネージャは、この時点で予算が承認されていることを確認する必要があります。 予算の確保は変更マネージャの担当ではありません。 ただし、変更マネージャは関連予算の保持者から変更に関する承認を得、関係者が予算超過の原因となる可能性のあるすべてのリスクと脅威に関して承諾したことを確認する必要があります。

CAB は、調達とライセンスに関する戦略や方針を討議する場ではありません。ただし、その分野の代表者が意思決定プロセスに関与することはあります。 RFC の提出前にライセンスと調達の詳細情報がすべて揃っているのが理想的です。 変更が予算承認に値すると証明できない限り、変更は却下されます。

1 台以上のワークステーションへの新規ソフトウェアの展開に関する RFC を検討する際は、経済的な妥当性を判断する上で必要となる、ライセンスの問題点に関するすべての情報および提示された展開手法に関するすべての情報が CAB のメンバに提供されていることが重要です。

CAB/EC の承認

新規製品の展開の RFC の場合は、変更マネージャと変更の開始者は、適切なグループが CAB/EC を代表していることを確認する必要があります。 組織で初めて展開する製品の場合、関係者と担当がまだ十分に定義されていない可能性があります。 このことは、変更の開始者と変更マネージャが協力してすべての関連メンバの参加を確保することの必要性を強調しています。

緊急ソフトウェア展開の場合は、技術的な専門家の参加が必要な場合があります。 変更の開始者に十分な技術的知識があっても変更を開始する権限がないときは、変更の開始者が技術者として参加する可能性もあります。 CAB/EC のメンバは、緊急の RFC に関する通知を電子メールで受け取ります。レビュー対象の RFC の緊急度と潜在的な影響度によっては、電子メールの代わりに電話、または口頭で通知されることもあります。 緊急の変更としては、既存のインストールに新規コンポーネントを追加する場合などがあります。 たとえば、Word へのアクセス権しか持っていないユーザーが、緊急の見積書を提出するために Excel を使用する必要がある場合などです。 これは、ビジネス主導型の緊急事態になります。

緊急の RFC に関するすべての情報は、緊急 CAB に提供する必要があります。CAB は、提供された情報 (ライセンスの詳細情報、調達の詳細情報、RFC の予算承認に関する確認など) に基づいて意思決定を行います。 これらの情報が確認できない場合、その時点で RFC は却下されます。

変更管理システムには、付属ドキュメントとソフトウェア アプリケーション ファイルの DSL が保管されている共有場所またはサーバーへのリンクが含まれている必要があります。 必要な情報は readme ファイルに含まれているので、技術専門家はリンク先のドキュメントや DSL を分析し、展開による影響を評価する必要があります。

CAB/EC は、ライセンス契約内容の確認、脅威分析の実行 (変更を展開しない場合の費用と展開する場合の費用) 、変更の開始者が最初に実行した影響分析の確認、RFC に設定可能なスケジュール (展開を完了する期限) の評価、CMDB の検索による調達の確認などを実行する必要があります。

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

最初に、変更分類プロセスによって提供されたレポートと情報をレビューします。 次に、提供された情報が十分かどうか、変更を続行できるほビジネス ケースが強力かどうかを判断して、決定を行います。 たとえば、SMS サイト サーバーと配布ポイントの場所を把握し、公開をサポートするのに十分なディスク空き容量があるかどうかを判断することが役に立ちます。

Dd283246.naidg04s(ja-jp,TechNet.10).gif

図 4: 配布ポイントの空き容量の確認
拡大表示する

規模と複雑性から考えて、Office XP がすべての場所やすべてのコンピュータに同時に公開されることはありません。そのため、変更管理チームとリリース管理チームが、サイト別、部門別、コンピュータの種類別などの公開オプションを確認して評価するために使用する追加レポートが必要になります。

変更開発

新規製品を展開するには、変更開発に大量の時間が必要になります。 権限の設定とユーザーの互換性の検討、他のシステムとの互換性の確認、必要なインターフェイスの開発などに時間がかかります。

ソフトウェア展開の変更は、その他の変更と同じプロセスに従います。 新規製品の展開に関する RFC では、相互依存する変更、変更の順序、前提条件、競合、変更経路なども考慮することが重要になります。 また、この段階では、開発する変更の定義が既に作成されていて、新規製品の属性に対応することを確認することが重要です。 ここでは、変更が将来のニーズに対応するかどうかを分析します。

次に、RFC のスケジュールを設定し、変更担当者を指名します。変更担当者は、必要なテクノロジを理解しているのが理想的です。 Office XP Standard を組織全体に新規展開する場合など、新規製品の RFC については、展開とそれに伴う問題を処理する適切なスキルを持っている人物を変更担当者に指名するように、注意深く検討する必要があります。

カスタマイズを行う前に、Office XP のファイルを隔離された場所に保管する必要があります。これは、ウィルスによる感染や伝染、または組織の IT インフラストラクチャに悪影響を及ぼす悪意のあるコードのチェック中に、外部ソースからのファイルを隔離するためにデザインされたプロセスです。 この隔離は、すべてのソフトウェアおよびドキュメントに行う必要があります。 隔離された環境では、これらは厳重に管理される必要があります。 このプロセスの完全性を確保するには、組織の専門グループが隔離を実行する必要があります。

Office XP の標準のインストールが、すべての組織に適しているとは限りません。 特定のコンポーネントや機能のインストール (または削除) を必要とする組織もあれば、特定の機能を要求時に利用可能にする組織もあります。 変更開発チームは、組織の要件を検討し、必要に応じてインストールをカスタマイズする必要があります。

カスタム インストール ルーチンの開発に従って、構成アイテム (CI) を CMDB に作成し、DSL を更新して "Status = test" を追加します。

  • テクノロジ メモ多くの場合、大企業ではすべてのユーザーとコンピュータに同じインストール ルーチンを使用することはありません。 同じ設定および構成オプションもありますが、多くの場合、異なるユーザーやコンピュータに対して、カスタム インストールを作成する必要があります。

組織に Microsoft .NET ドメインまたは Windows 2000 ドメインが導入されている場合、Office XP のインストールは、CIW、OPW、またはグループ ポリシーによりカスタマイズできます。 ただし、必要な結果を得るには、これらのツールを組み合わせて使用する必要がある場合もあります。

必要なインストールの種類ごとに MST ファイルを作成します。 このファイルでは、以下の事項を定義します。

  • インストールする Office XP のパーツ。コンポーネントを表示するか、ローカルにインストールするか、初回使用時にインストールするか、ネットワークから実行するかということも定義します。

  • 既定のユーザー設定、標準ファイルの場所など、Office XP の構成情報。

新規 MST ファイルは、Office XP コンポーネントと構成設定の組み合わせごとに必要です。

ある構成から別の構成にアップグレード (ダウングレード) が必要な場合、MST ファイルのほかに、メンテナンス ファイル (CMW) が必要です。 このファイルでは、新規構成を実現するために必要な初期 MST ファイルからの変更を定義します。 たとえば、TeleSales.mst という名前のファイルで Outlook と Word のみのインストールを定義している場合、PowerPoint を追加するためにアップグレードが必要なときは、TeleSales+PPt.cmw という名前の新規ファイルを作成します。 このファイルでは、TeleSales.mst をベースラインとして使用して、PowerPoint を追加します。 このファイルのアプリケーションは、PowerPoint を追加するように telesales ベースのインストールをアップグレードできます。 Office XP のインストールから機能を削除するダウングレードにも、同様のファイルが必要になります。

Office XP インストール群を構成するファイルの最終的なパッケージには、展開するすべての構成の種類が含まれています。このパッケージは、以下の要素で構成されます。

  • 管理インストール (下記参照) からの Office XP インストール ファイル。

  • カスタム インストールを提供する 1 つ以上のカスタム MST ファイル。

  • MST ファイルで定義されたインストールをアップグレードまたはダウングレード目的で変更する 0 個以上の CMW ファイル。

インストール ポイントの作成

変更開発チームは、コマンド ラインに以下のように入力することによって、最初に Office XP の管理インストールを実行する必要があります。 setup.exe /a

これにより、Office XP のインストールに必要なすべてのファイルのコピーが作成され、開発チームは MST ファイルと CMW ファイルを作成できるようになります。 このセットアップ コマンドは、隔離された Office XP ソース ファイルで実行するか、オリジナルの CD-ROM から実行します。 この管理インストールは、開発チームが所有するストレージ領域にインストールされます。 リリース マネージャが最終的に Office XP をインストールするときに、別の管理インストールが実行されます。

最終システムに展開されるカスタマイズされたインストールを作成するには、必要な MST ファイルを作成する以下のツールを使用できます。

  • Office プロファイル ウィザード (OPW)

  • カスタム インストール ウィザード (CIW)

どちらのツールも、Office リソース キット (ORK) にあります。

ユーザーの構成設定

Office XP は、多数の構成オプションと設定によってカスタマイズできます。 Office XP では、ユーザーに個人データ領域 (マイ ドキュメントなど) に各自のドキュメントを保存するよう指示しますが、特定の部門でのインストールでは、この既定の動作を変更し、ユーザーにファイル サーバーの共有 (ワークグループ) フォルダに保存するよう指示する必要がある場合があります。

新規インストールごとに管理者がこの設定を手動で構成する必要がないように、OPW を使用して構成設定を Office XP の既存のインストールからテンプレート ファイルにエクスポートできます。 その後、このファイルを使用することによって、保存済みの設定を将来のインストールに適用できます。

チームのメンバは、OPW を正しく使用するために、最初に Office XP を新しく構築したワークステーションにインストールして、特定の部門やユーザー グループの要件に合わせて設定を変更します。次に、OPW を使用して、変更した設定をファイルに取得します。

Dd283246.naidg05s(ja-jp,TechNet.10).gif

図 5: OPW を使用する設定の取得
拡大表示する

内容の異なる設定が異なるユーザー グループに設定されている場合、このプロセスを数回繰り返して、複数のプロファイルを作成する必要があります。 特定のアプリケーションの設定がすべてのユーザーに対して同じでも、アプリケーションの組み合わせが異なる場合は、管理者は不要なアプリケーションのチェック ボックスをオフにして、別の名前でプロファイルを保存する必要があります。

このように、さまざまな設定を適用するには、グループ ポリシーを使用できることに注意してください。これは、Windows 2000 ドメインまたは Windows .NET ドメインを備えた組織が Office XP のインストールをカスタマイズするのに適した管理しやすい方法です。

カスタマイズしたインストールの作成

管理インストールを作成すると、変更開発チームは、CIW を使用して MST ファイルを作成できます。この MST ファイルでは、特定のインストールからインストールまたは削除する Office XP のコンポーネント、適用する Office プロファイルやその他の設定などを定義します。 管理者は、CIW を使用して MST ファイルを作成する場合、インストール対象の Office XP 製品群のコンポーネントとサブコンポーネント、および適用する構成設定を詳細に規定できます。たとえば、テンプレート ファイル用の別の場所などを規定できます。

CIW は、インストールを変更するパッケージ ファイル (MSI) を最初に問い合わせます。 この作業を正常に完了するには、Office XP Professional の場合は ProPlus.msi ファイルを指定する必要があります。 また、MST ファイルとインストール対象の Office XP の各コンポーネントも指定します。 コンポーネントとサブコンポーネントごとに、ローカルにインストールする、初回使用時にインストールする、ネットワークから実行する、またはインストールしないというオプションを指定できます。 SMS を使用してパッケージを展開するというコンテキストでは、使用するインストール オプションを選択する際は、さまざまな問題点を考慮する必要があります。

  • ネットワーク経由の実行は、SMS 配布ポイントから Office XP のコンポーネントを実行することになるのでお勧めしません。 ネットワーク間で実行する際に発生するプロファイルの読み込み用に配布ポイントがデザインされていることはほとんどありません。 また、配布ポイントの場所と Office XP パッケージへのパスは、クライアント上に保存されます。 SMS 配布ポイントが将来再構成される合、たとえば、配布ポイントが廃止されたり別の場所に移動された場合、または Office パックが一部の配布ポイントから削除された場合、クライアントは当初インストールに使用していた場所から Office ファイルにアクセスできなくなります。 (SMS インフラストラクチャではこのような配布ポイントの変更を自動的に処理するので、SMS を使用した新規インストールの成功には影響しません。)

SMS 配布ポイントが Office XP に問題が生じる方法で変更または削除されないことが保証されている場合、またはアプリケーション サーバーの機能向けにデザインおよびインストールされている場合は、ネットワークからの実行や初回使用時のインストールを指定できます。

  • 初回使用時のコンポーネントのインストールは、配布ポイントが後日再構成された場合、ネットワーク経由で実行する際に発生する問題と同じ問題が発生します。

  • コンポーネントに利用不可、非表示、またはロックが設定されている場合、CMW メンテナンス ファイルを使用して後でインストールすることはできません。

次に、CIW は、プロファイル ファイル (OPS) を問い合わせます。 この操作では、OPW を使用して事前に作成および保存された構成設定のセットを MST ファイルにインポートできます。 CIW のいくつかの手順を使用して、この時点でほとんどの構成設定をカスタマイズできるので、構成の変更に OPS ファイルを使用する必要はありません。 代わりに、OPS ファイルの設定と CIW ファイルの設定のカスタマイズの組み合わせを使用することもできます。

インストールの種類ごとに、管理者は設定の保存に使用する MST ファイルを指定する必要があります。

Dd283246.naidg06s(ja-jp,TechNet.10).gif

図 6: CIW を使用するマクロの保護の有効化
拡大表示する

変更開発チームは、目的がわかるような名前とバージョン番号を MST ファイルに付けることが重要です。

CIW を実行するたびに、MST ファイルをインストールの "出発点" として指定できます。 これにより、MST ファイルごとに各機能を選択することなく、それぞれの最終バージョンに基づいて構築された MST ファイル、利用可能な Office XP アプリケーションと機能の構成やレベルが異なる MST ファイルなど、多数の MST ファイルを作成できます。

必要な機能のレベル (たとえば、電話販売やマーケティング) が異なるだけでなく、コンピュータの種類が異なる、さまざまなインストールが多数作成されます。 たとえば、ポータブル コンピュータは、必要なコンポーネントをすべてローカルにインストールするよう構成する必要があります。 初回使用時のインストールやネットワーク経由での Office コンポーネントの実行は決して行わないようにします。

MST ファイルの他に、上記で説明したように、CMW ファイルを Office リソース キットに組み込まれたカスタム メンテナンス ウィザードを使用して作成します。 これらのファイルは、たとえば、アップグレードを実行する目的で、MST ファイルを使用して既に作成済みのインストールに機能を追加または削除するために使用します。

CMW は、CIW と同様の方法で機能します。 設定を変更中の MST ファイルが指定されている場合、カスタム メンテナンス ウィザードで設定の変更が可能です。 ただし、CIW で利用不可、非表示、またはロックが設定されている機能は、利用できない状態のままになります。

変更開発チームは、カスタマイズされたインストール、プロファイル、アップグレード ファイルをすべて作成した場合、多数の MST ファイル、CMW ファイル、および OPS ファイルを作成したことになります。 これらのファイルはすべて、DSL に保管する必要があります。テストと展開のフェーズでは、DSL のファイルにアクセスします。

承認済みの変更

変更認可を得るには、変更開発プロセスを通じていくつか改訂が必要な場合があります。また、選出された CAB のメンバによるマイルストーン レビューが必要になることもあります。 作成した変更のテストが完了し、すべての成果物と受け入れ基準を満たし、受け入れのレビューに合格したら (改訂の有無に関係なく)、その変更は承認済みの変更になり、リリース管理プロセスに従って実稼動環境に展開できます。リリース管理については、次のセクションで説明します。

リリース管理

変更が承認されたら、リリース管理プロセスに移ります。ここで、変更担当者はリリース マネージャを指名します。 リリース マネージャは、このプロセスにおける調整を担当し、場合によっては (少数のインストールしか必要でない場合など) このプロセスに関連する大部分の作業を担当します。

リリース管理の内容は、プロセス フローチャート (図 7) のように表現できます。このフローチャートには、リリースを計画し、IT インフラストラクチャに承認済みのリリースを正常に展開するために必要なアクティビティを示しています。

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

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

この大まかな概要は、リリース管理プロセスの包括的な詳細計画で、さらに多くの詳細アクティビティとプロセス フローに細分化できます。 このプロセスの詳細については、https://www.microsoft.com/japan/systemcenter/default.mspx の『MOF Release Management SMF Guide』を参照してください。

このガイドでは、リリース管理プロセスによる Office XP の展開に関する特定の情報について、概要レベルで説明します。 特定の内容の詳細については、リリース管理 SMF ガイドを参照してください。

リリース管理のプロセスは、変更管理によって RFC の承認を取得した後で実行する必要があります。

リリース計画

新規ソフトウェア アプリケーションのリリースを計画するときは、リリース管理 SMF ガイドに記載されているプロセスに従います。 ただし、以下に示すように、リリース戦略ドキュメントで扱うべき特定の要素がいくつかあります。

  • リリースの内容と目的は? スケジュールの内容とスケジュールが重要な理由は? この質問の回答は、RFC の承認プロセスで導き出されるべきものですが、リリース マネージャは RFC を実装するために変更する必要のあるコンポーネントやサービスを確認する必要があります。 変更承認プロセス中に CMDB を検索した場合でも、まだ発見されていない何らかの影響が残っている可能性もあります。このようなことはめったにありませんが。

  • リリース マネージャは、各ユーザー グループが機能に関する異なる要件を持っている可能性を認識する必要があります。 また、展開を実行すべきでない業務時間帯が存在する場合もあります。 たとえば、電話販売部門でコア タイム中の停止時間を容認できなくても、その他のユーザー グループは容認できるという場合もあります。

  • スケジュールの設定に影響を及ぼす条件や制限事項が多数存在する場合があります。たとえば、24 時間営業の場合、新規製品のインストールによる停止時間は、ユーザーにとって都合が悪い場合があります。 このような制約は、段階的なリリース手法によって解決できます。この段階的な手法では、ユーザーが生産的な業務を行わない時間帯を使ってインストールを完了します。 たとえば、勤務の交代時間、コンピュータを使用しない休憩時間、または新製品のトレーニング セッションに参加している時間などにインストールのスケジュールを設定します。

  • また、リリース戦略ドキュメントには、ネットワーク リンクが低速で混雑している場所へのリリース展開方法についても明記する必要があります。

テクノロジ メモ

リリースの範囲設定

リリースの範囲設定では、環境に存在する項目に関する正確で最新の知識を持っていることが不可欠です。 ソフトウェアとハードウェアのインベントリ エージェントで対象のコンピュータからデータを最後に収集した日時を確認するには、Web レポートを使用してクライアントのステータス メッセージを調査する必要があります。 最近インベントリが行われていない場合、管理者は強制的にクライアントにインベントリ サイクルを実行させる SMS の提供情報を作成し、Web レポートをチェックすることによってインベントリの進捗状況を追跡する必要があります。

図 8: サンプル インベントリ レポート

図 8: サンプルインベントリレポート

リリース マネージャが SMS データベースの情報が最新であると確認したら、変更プロセスで作成した SMS のレポートおよび情報を使用できます。または、リリース プロジェクトの正確な規模を把握するために追加レポートを作成します。

たとえば、SMS ハードウェア インベントリが実稼動環境の異なる種類のコンピュータの詳細情報を取得するよう変更されている場合 (『アーキテクチャ ガイド』の「付録 A」を参照)、リリース マネージャは Office XP をインストールするコンピュータの種類に関する情報を含むカスタム レポートを作成できます。 ポータブル コンピュータ、リモート クライアント、およびターミナル サーバーでは、ローカル エリア ネットワーク (LAN) で接続されたデスクトップ コンピュータとは異なる配布方針やインストール方針が必要なので、コンピュータの種類はリリース計画段階では重要な情報です。 (ターミナル サーバーへの Office XP のインストールは、このガイドの範囲外です。)

また、リリース マネージャは、SMS データベース内の情報を使用して、SMS サイトにレポートするコンピュータ数、または特定のインターネット プロトコル (IP) サブネットに割り当てられているコンピュータの数を判断できます。 この情報は、パイロット サイトの選定や最適な公開順序の決定に役立ちます。 コンピュータが属する部門または OU 構造も SMS データベースに記録されている場合 (『アーキテクチャ ガイド』の「対象とするコンピュータ」を参照)、その情報はこの意思決定プロセスにも役立ちます。

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

リリース チームは、Office XP が破損したコンポーネント (ユーザーが誤って削除したファイルや別の製品が置換したファイル) を自動的に修復しようとして、Office XP のソース ファイルにアクセスすることを考慮する必要があります。 オリジナルのソース ファイルへのアクセスは、Service Pack や特定の修正プログラムを適用するときにも必要になります。 このような場合、リリース チームは、Office XP のソース ファイルをコンピュータのハードディスク上の非表示の場所に配置するリリースを作成する必要があります。 あるいは、リリース チームは、このようなクライアントに Office XP のインストール CD-ROM のコピーを提供する必要があります。

リリース チームは、リリース計画を円滑に進めるために、インストール対象の、または各ユーザー グループが必要に応じてインストールする Office XP 製品群の機能とコンポーネントごとの詳細を示した一連の表を作成する必要があります。

表 1: Office XP の展開の計画

コンポーネント

役員

Marketing

電話販売部門

ポータブル コンピュータ

Word

インストールする

インストールする

インストールする

インストールする

Excel

インストールする

要求時インストール

使用不可

インストールする

PowerPoint

インストールする

インストールする

使用不可

インストールする

Outlook

インストールする

インストールする

インストールする

インストールする

修正プログラム管理プロセスでは、エンド ユーザーに提供する前に、Office XP に適用する必要のある修正プログラムの数を識別することがあります。 リリース マネージャは Office XP の CIW を使用して、セットアップに Office XP のインストールを指示する MST ファイルを作成し、その後修正プログラムと Service Pack をインストールする追加コマンドを実行できます。

Office XP が正常に実稼動環境に展開された後は、SMS 修正プログラム管理プロセスによって、最新の修正プログラムと Service Pack で更新されるようにする必要があります。 詳細については、『SMS を使用する修正プログラム - 展開ガイド』を参照してください。

トレーニング、手配、通信に関する要件の識別

承認を得るには、リリース戦略ドキュメントに以下の質問に対する回答を含める必要があります。

  • 特に低速ダイアルアップ ネットワークで接続されている場合に、アプリケーションのソース ファイルをサイト間でどのように転送するか?

  • ポータブル コンピュータやリモート クライアントをどのように可能にするか?

  • ユーザーやヘルプ デスク/テクニカル サポートのトレーニングをいつ開始するか?

リリース開発

選択するリリース メカニズムによって、リリース展開に必要なアクティビティが決まります。 リリース パッケージは、リリースの適切な配布に必要なすべてのコンポーネントで構成し、リリースが原因で変更が必要となる運用プロセスに対処するデザインに仕上げる必要があります。 Office XP Standard、Office XP Professional、Office Developer の展開に関する前提条件とシステム要件の完全な説明は、Office XP リソース キットにすべて収録されています。 また、Microsoft Web サイトには、移動ユーザー、ポータブル コンピュータ、Office XP 製品群の世界規模の展開など、特殊なリリース シナリオに関するガイドラインも記載されています。

組織は、リリースをデザインする際に、展開対象の製品または製品群のサイズと、カスタマイズなどの開発段階での変更を十分に検討する必要があります。 さまざまなユーザーの要件ごとに異なるリリース パッケージが必要になる可能性があるので、リリース メカニズムは適切な手法でアプリケーションの展開を処理するように構築する必要があります。

たとえば、電話販売チームや 24 時間運用では、業務時間中の停止時間は避ける必要があるので、インストールでのユーザーとの対話は許されません。 業務時間外までインストールを延期することにより、インストール中のコンピュータにログオンして時間を浪費する事態を防ぐことができます。 ただし、このような停止時間は、その他のユーザー グループでは許される場合もあります。 リリースのデザインとその後の構築では、このような要素をすべて考慮する必要があります。

パッケージ (MSI) ファイルの構築では、エンド ポイントと配布ポイントの使用の他、展開の速度を考慮する必要があります。 通常、ソフトウェアの展開は、標準の SMS 階層を通じて行われます。ただし、そのような手法では、大規模展開の場合、容認できない遅延が生じる可能性があります。 このような場合、応答速度の速い並列アーキテクチャを使用します。 ただし、この手法では、追加サーバーや帯域幅の拡大などの追加費用が発生します。 個別の要素について、RFC の脅威分析と経済的な妥当性の要因分析を行う必要があり、予算の承認を得る必要があります。

Office XP 製品のインストールでは、Setup.exe ファイルが以下のタスクを順に処理します。

  1. 初期化タスクを実行します。

  2. (必要に応じて) システム ファイルの更新を検出してインストールします。

  3. (必要に応じて) コンピュータを再起動して再開します。

  4. Office XP パッケージをインストールします。

  5. 連鎖パッケージをインストールします。

  6. 完了します。

次に、リリース キットが評価される組織での使用に適しているかどうかをテストします。 新規製品のテストには、リリースとリリースのユーザーの受け入れを含める必要があります。 たとえば、配布ポイントから各パーソナル コンピュータのエンド ポイントへのダウンロードは、リリース パッケージがユーザー コミュニティで受け入れられることを確認するためにテストする必要があります。このとき、ダウンロードと再起動中の停止時間とユーザーとの対話に留意します。

リリース手法が受け入れテストに合格した場合、新規ソフトウェア製品のリリース キットを構成アイテム (CI) として CMDB に追加する必要があります。 リリース キットには、テスト計画、トレーニング計画、リリース製品、すべての付属ドキュメントなど、リリースの完了に必要なすべての資料を含める必要があります。これは、すべての資料が全面的な受け入れテスト段階で必要になるためです。

次に、DSL を更新して、"test" というソフトウェア製品のステータスを追加します。 組織の別の領域 (たとえば、さまざまなセットアップ権限、セキュリティ、ユーザー プロファイルなど) に関する別のリリース パッケージが存在する場合、CMDB に定義して、DSL に追加する必要があります。

リリースがテストに合格しなかった場合、生じた問題点に対処するため、開発プロセスのデザイン段階および構築段階に戻される必要があります。

テクノロジ メモ

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

管理者が、Office XP のインストールのためにユーザーやコンピュータの特定のグループを対象にしたり、通常の営業時間外に行われるインストールを計画したり、低速ネットワークまたはダイヤルアップ リンクで接続しているクライアントを処理できるように、SMS はソフトウェア配布の機能を提供します。

SMS は、Office XP の配布とインストールの作業に最適であり、このガイドで採用しているリリース メカニズムです。

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

リリース管理チームは、管理インストールから Office XP ファイルと、変更開発チームが作成したカスタマイズ済みの MST ファイルと CMW ファイルを受け取り、Office XP の実稼働環境への展開を担当します。 このチームは、クライアントの数、クライアントの特徴と場所、ネットワーク接続の種類を考慮して、最適な展開の実施方法を判断する必要があります。 MST ファイルと CMW ファイルは、インストールのすべての種類とクライアントのシナリオに十分に対応する必要があります。

SMS を Office XP の配布に使用しますが、多数の異なるカスタマイズを展開する場合があります。 展開する各カスタマイズが同一の Office 製品 (たとえば、Office XP Professional) のカスタマイズである場合、これらのカスタマイズは、単一の SMS パッケージ内の独立したプログラムになります。 異なる Office 製品 (たとえば、Office XP Standard と Office XP Professional) がそれぞれのカスタマイズに使用されている場合、それぞれ独立した SMS パッケージが必要になります。

パッケージ デザイン段階でのその他の考慮事項は以下のとおりです。

  • ユーザーは各自のコンピュータの管理者権限を持っているか? 管理権限を持っていない場合、SMS プログラムは管理者として実行する必要があります。

  • インストールは、必須、任意、または両方の組み合わせか? たとえば、Office XP はクライアントのコミュニティに対してユーザーの都合に合わせて各自でインストールするように提供される一方、十分な "猶予" 期間が経過した後はインストールされる必要があることを取り決められる場合があります。この場合は、インストールが必須になります。 Office XP をユーザーがコンピュータにログオンしない業務時間外にインストールする場合、インストールは必須とする必要があります。

  • コンポーネントのどの構成がユーザーに必要か? コンポーネントの各構成は、既に作成済みの MST ファイルに割り当てる必要があります。また、コンポーネントの構成のアップグレードには関連付けられた CMW ファイルが必要になります。

  • 追加のソースの保存場所が必要か? この場所は、MST ファイルの作成の一環として構成されている必要があります。

  • ローカライズして他の国で使用する場合、多言語ユーザー インターフェイス (MUI) パックは必要か? この件は、変更開発段階で MST ファイルを作成時に検討される必要があります。

  • Office XP パッケージを受信するクライアントは、ダイアルアップまたはその他の低速または断続的なリンク経由で接続しているか? 該当する場合、以下で説明する CD-ROM によるインストール手法を使用するのが賢明です。

  • インストールの直後にソフトウェア インベントリを実行して SMS インベントリ データベースを更新する必要があるか? 更新する必要がある場合、MST ファイルの一部としてコマンドを作成するか、別の SMS プログラムを実行し、最初に実行する Office XP のインストールによってコマンドを作成します。

  • パッケージをどのようにアンインストールするか? Office XP は Setup.exe /x を実行することによってアンインストールされます。アンインストールを実行するには、独立したプログラムが必要になります。

ポータブル コンピュータとリモートクライアントへの展開

リリース マネージャは、Office XP のような大規模アプリケーションを、低速で断続的なダイアルアップ接続経由でネットワークに接続するポータブル コンピュータなどのモバイル クライアントに展開する場合、以下の問題点を認識する必要があります。 ダイアルアップ接続の場合、インストールの完了には数時間かかることがあります。また、接続が中断した場合、インストールが突然 "失敗" することがあります。

Office XP の管理インストールのファイルは、CD-ROM に書き込んで、その CD-ROM を関連するクライアント コンピュータのすべての所有者に送信できます。 次に、SMS パッケージ ラッパーに、通常の配布ポイントの代わりに CD-ROM から Office XP のセットアップ プログラムを実行することをに記述します。

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

この手法では、正しいステータス メッセージが送信されることを確認することが重要です。 このメッセージは、ラッパー プログラムが正常に実行されたかどうかを示すのではでなく、Office のインストールが成功したかどうかを示す必要があります。 このことは、ラッパー プログラムが実行されるときに、ユーザーが CD-ROM を利用できず、操作が中止される可能性により、さらに複雑になります。 このような場合は、ステータスとして "failed" を返す必要があります。

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

以下の図 9 に、リモート ユーザーに表示される画面を示します。この画面では、Office XP のインストールと、ユーザーが既に受領しているはずの CD-ROM の存在を通知しています。

図 9: ラッパー プログラムの例

図 9: ラッパープログラムの例

配布ポイントの配置

SMS は、既定では配布ポイントの隠し共有からインストールします。 たとえば、\\<DPServerName>\SMSPkgc$\abc00023 です。 たとえば、ファイル フィルタなどの他のコンポーネントの追加によって、Office のインストールが更新されると、必ずソース ファイルに再度アクセスするために元のインストール パスが使用されます。 しかし、元のソースは、配布ポイントが削除されたり、サイトの階層が再編成された場合は使用できなくなります。 この状況では、Office XP の更新が失敗し、アンインストールもできなくなります。

したがって、別のインストール場所も用意しておくことをお勧めします。 この場所にもソース ファイルを保存し、常時利用可能にしておく必要があります。 このような場所は、CIW を使用して MST ファイルを作成するときに指定できます。

Dd283246.naidg10s(ja-jp,TechNet.10).gif

図 10: インストールポイントの指定
拡大表示する

指定した共有の Office XP のソース ファイルには、SMS パッケージ共有にアクセスできない場合のみアクセスする必要があります。 ネットワーク トポロジとこの共有が使用される可能性 (たとえば、SMS 配布ポイントが移動または廃止される頻度が高い場合) によっては、すべてのクライアントが容易にアクセスできるように、組織内の戦略的な場所を共有に指定する必要があります。 また、代替ファイル場所へのアクセスを常に確保するには、その他のメカニズムが必要になることがあります。

CIW の詳細については、https://www.microsoft.com/office/ork/xp/appndx/appa04.htm (英語) を参照してください。

上記は、インストールの種類ごとに識別される必要があります。 また、各 MST ファイルに適切な名前を付ける必要があります。

リリース パッケージの構築

SMS パッケージの構築

上記の手順をすべて完了すると、作成されたファイルは Office の管理インストールのルート ディレクトリに保存されるので、リリース チームはインストール用に SMS パッケージを構築できます。

MST ファイルの作成時に定義された別のインストール場所が代わりに使用されている場合、最初に Office の管理インストール ディレクトリ (または DSL) からその場所にパケージをコピーします。 その後、その場所をパッケージのソースの場所として使用します。 これにより、SMS パッケージと代わりの場所のコピーが同一のファイルになります。

CD-ROM を使用するポータブルコンピュータユーザーへの Office の展開

上記で説明したように、リモート ユーザーが CD-ROM 配布を使用している場合、MST ファイルと CMW ファイルは CD-ROM で配布するのではなく、集中管理される場所に保存する必要があります。 この方法により、MST ファイルと CMW ファイルで定義したとおりに構成を容易に変更でき、追加の CD-ROM を配布する必要がなくなります。 CD-ROM には、Office XP の管理インストールのファイルのみを保持するので、変更は必要ありません。

CD-ROM を使用して Office を展開するには、以下の一般的な手順に従います。

  1. 管理インストールを含む共有のファイルを CD-ROM にコピーします。ただし、MST ファイルと CMW ファイルは除きます。

  2. MST ファイルと CMW ファイルを含むラッパー プログラムを作成します (上記を参照)。

  3. ラッパーに対応するパッケージ、プログラム、提供情報を作成します。ただし、ユーザーが CD-ROM を受領していない場合、または Office のインストール時期をユーザーが選択できる場合があるので、提供情報は必須ではありません。 また、プログラムが非表示で実行されないことを確認します。

リモート ユーザー グループごとに異なるインストール要件がある場合、ラッパー プログラムに、使用する特定の MST ファイルなどのパラメータを指定し、リモート ユーザーで必要な MST ファイルごとに個別のプログラムを SMS で作成できます。 以下にコマンドの例を示します。

D:\setup.exe TRANSFORMS=%CD%\BasicOffice01.MST /qb+

このコマンドは、ラッパーのバッチ ファイルから実行できます。ここでは、CD-ROM が D ドライブに挿入されていて、環境変数 %CD% が MST ファイルが保存されている SMS パッケージの場所を指していると仮定しています。

プログラムの作成

上記の「リリース パッケージの構築」で作成した各 MST ファイルに対応するプログラムを作成します。パッケージの対象に応じて、適切な SMS オプションを選択していることを確認します。 たとえば、以下のプログラムを定義します。

プログラム名

コマンド

環境

備考

基本ユーザー インストール

setup.exe TRANSFORMS=Basic.mst /qb+

ユーザーがログオンしているときのみ。

ユーザー入力が必要。

&

管理権限で実行。

基本ユーザー インストール (非表示)

setup.exe TRANSFORMS=Basic.mst /qn

ユーザーがログオンしているかどうかは無関係。

管理権限で実行。

マーケティング部門インストール

setup.exe TRANSFORMS= Marketing.mst /qb+

ユーザーがログオンしているときのみ。

ユーザー入力が必要。

&

管理権限で実行。

マーケティング部門インストール (非表示)

setup.exe TRANSFORMS= Marketing.mst /qn

ユーザーがログオンしているかどうかは無関係。

管理権限で実行。

基本インストールに PowerPoint 追加

MaintWiz.exe /c AddPPt.cmw /qb+

ユーザーがログオンしているときのみ。

ユーザー入力が必要。

&

管理権限で実行。

基本インストールに PowerPoint 追加 (非表示)

MaintWiz.exe /c AddPPt.cmw /q

ユーザーがログオンしているかどうかは無関係。

管理権限で実行。

アンインストール

setup.exe /x ProPlus.msi /qb+

ユーザーがログオンしているときのみ。

ユーザー入力が必要。

&

管理権限で実行。

アンインストール (非表示)

setup.exe /x ProPlus.msi /qn

ユーザーがログオンしているかどうかは無関係。

管理権限で実行。

MST ファイルを使用して作成したインストールのアップグレードまたは変更に CMW ファイルが使用されている場合、MaintWiz.exe コマンドを使用します。 MaintWiz.exe は、Office XP の管理インストールの一部としては提供されません。ORK からパッケージ ファイルにコピーする必要があります。

展開する Office 製品群 "ごと" に個別の SMS パッケージが必要です。 特定の製品群の Office XP コンポーネントを追加または削除する場合は、以下の図に示すように、パッケージ "内" でプログラムを定義します。

Dd283246.naidg11s(ja-jp,TechNet.10).gif

図 11: パッケージ内のプログラム
拡大表示する

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

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

  • 非表示インストールやアンインストールなど、実稼動環境で使用するすべてのプログラムとコマンド ラインによる、パッケージの基本インストールのテスト。

  • 対象のコンテキストでの SMS 提供情報内からのパッケージの実行のテスト。 たとえば、ログオフや管理コンテキスト。

  • 終了コードが目的どおりで、SMS ステータス システムが終了コードをレポートすることを確認するテスト。

  • 1 つの配布ポイントが機能しない場合でも、インストールが続行可能であることを確認するテスト。

テスタはインストールの完了後に、以下の項目も確認する必要があります。

  • オプション コンポーネント (要求時インストール) が機能し、ユーザーが必要としたとき、またはアクセスしたときに、オプション コンポーネントを追加できることの確認。

  • ユーザーがコンポーネントを損傷または削除した場合に、自動修復機能が機能することの確認。

DSL へのリリースパッケージのコピーの格納と CMDB の更新

Office XP のインストールのカスタマイズが完了した後、後日も同じファイルを取得、識別、および再使用できることを保証するために、ファイルを安全な場所に保管してバージョン管理を行う必要があります。 そのため、このようなファイルは CMDB に格納する必要があります。 テストの完了後、ファイルはテスト環境からではなく、CMDB から実稼働環境に取得されます。 これにより、実稼動環境では、テストで使用するファイルと完全に同じファイルが使用されます。

管理インストールのディレクトリ (MST、CMW、プロファイル ファイルを含む) を DSL にコピーします。 すべての MST ファイル、CMW ファイル、プロファイル ファイルがドキュメント化されていることを確認します。 次に、BackOffice リソース キットの SMS Site Properties Manager ツールを使用して、パッケージの定義を DSL に保存します。 これにより、パッケージのプロパティとプログラムのプロパティのバージョンも管理されるようになります。

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

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

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

配布ポイントやパッケージ ソースを含む、すべてのパッケージ詳細が保存されるようになります。 このパッケージは、テスト用と実際の SMS インフラストラクチャ用では異なるので、パッケージ情報をインポートした後それを変更する必要があります。

受け入れテスト

インストール対象のリリースと製品のテストを効率的に実施し、不具合を発見するには、実稼働環境をミラー化した環境でテストを実施する必要があります。 この段階でのテストは、リリース パッケージを単体でテストするだけではなく、変更管理プロセス中に開発された製品とリリース パッケージの組み合わせをテストする最初の機会です。 この段階では、チームは新規製品の機能が、ソリューションのすべてのニーズと受け入れ条件を満たしていることを確認する一方、ユーザーに効率的に製品を配布できる必要があります。 このテストでは、リリースと展開の完全なテストだけでなく、トレーニング パッケージ、各種のプロセスとその他のシステムとのインターフェイス、運用プロセスに対する変更のテストを実施する必要があります。 また、セキュリティと機能のテストも実施します。

Microsoft ではリリース前にソフトウェア製品群のテストを実施していますが、組織内で実施するテストでは、カスタマイズと、異なる言語を使用する多国籍企業など、製品が使用される特別な条件のテストを確実に実行することが重要になります。

テスト結果のレビュー後、製品のカスタマイズとリリース パッケージの改訂が必要と判明した場合、RFC を関係する段階に戻す必要があります。 また、この段階では、組織の状況が急激に変化し、展開対象の製品が組織の要件を満たさなくなっている可能性もあるので、当初の RFC の成果物が引き続き該当することを確認することが重要になります。

受け入れテスト プロセスで、リリース パッケージと製品のカスタマイズがすべて適切であることを確認したら、Microsoft Project にこのマイルストーンの完了を追加して、更新したすべてのドキュメントを共有アクセス ポイントに格納する必要があります。 また、変更管理システム、CMDB、DSL を更新し、製品とパッケージのステータスを "trusted" に変更します。

  • テクノロジ メモテスト環境の性質は、実施するテストと、テスト環境に複製する実稼動環境のアーキテクチャによって異なります。

Office XP の展開では、以下の点を考慮する必要があります。

  • 作成したクエリが対象のコンピュータを正しく識別するか?

  • Office XP が特定のコレクションを対象としている場合、このコレクションに Office がインストールされていない新規コンピュータが追加されたとき、Office XP は自動的にインストールされるか?

  • 組織が CD-ROM によるインストール手法をリモート クライアントに使用している場合、CD-ROM は意図したとおりに機能するか、また、インベントリは正しくレポートを作成するか?

  • 低速リンクで接続された多数の SMS サイトにパッケージを送信する場合、パッケージのコピー中のネットワークの利用をテストするためにこのような環境が再現されているか?

テスタは、実稼動環境の構成を反映したテスト ラボを使用します。 この構成には、SMS 階層とクライアント/サーバーの構成も含まれます。 構成情報を取得するには CMDB を参照します。また、SMS インベントリ プロセスでクライアントとサーバーが使用するソフトウェアとハードウェアを識別するために取得した情報を使用します。

テスト ラボのセットアップ

テストでは、MST ファイルまたは CMW ファイルを変更する可能性があるので、テスタは Office XP の管理インストールのディレクトリを DSL からコピーし、テスト ラボにコピーを作成する必要があります。

テスタは、Site Properties Manager を使用して、DSL に保存されたパッケージをテスト階層にインポートします (前のセクションを参照)。 テスタは、パッケージをインポート後、配布ポイントが適切にテスト ラボに設定されていることを確認します。

Dd283246.naidg13s(ja-jp,TechNet.10).gif

図 13: Site Properties Manager の使用
拡大表示する

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

SMS を使用した Office XP の展開をテストする際は、以下のシナリオを考慮する必要があります。

  • Office XP がインストールされていない新規コンピュータをネットワークに追加する場合。 SMS インベントリをコンピュータに対して実行後、Office XP がそのコンピュータに提供され、次に提供情報が実行されるときにインストールされます。

  • ダイアルアップ接続経由でポータブル コンピュータに展開する場合 (テストでは "低速リンク経由で提供しません")。

  • ワイド エリア ネットワーク (WAN) 経由で展開する場合 (低速ネットワーク接続によって配布ポイントから分離されたクライアント)。

  • CD-ROM 展開を使用して Office XP を直接クライアントにインストールする (SMS 媒体使用センダではなく) 場合。インストールが中断された場合、または CD-ROM が使用できない場合も含めます。

  • Office XP をアンインストールする場合。

  • 対話型プロセス (コンピュータにユーザーがログオンしている場合) またはバックグラウンド プロセス (ユーザーがログオンしている場合/ログオンしていない場合の両方) で、Office XP をインストールおよびアンインストールする場合。SMS 階層自体も Office XP などの大規模パッケージでテストする必要があります。 これをテストするには、以下の領域において、SMS 階層が可能な限り実際の階層を反映している必要があります。

  • サイト間の WAN 対応の帯域幅。

  • 配布ポイントあたりのクライアントの競合率。

  • 階層の深さ。

テスト項目は以下のとおりです。

  • パッケージが階層全体に伝達され、すべての配布ポイントに展開されるまでに要する時間。 パッケージの複製に使用可能な帯域幅が狭く、SMS 階層が深い場合は、数時間または数日かかる可能性があります。

  • 配布ポイントへのパッケージの配布がネットワークに及ぼす影響。

  • 複数の Office XP のインストールが同時に発生したときの配布ポイントとネットワークの負荷。

テスト ラボでは、このようなスケーラビリティの問題に関するテストを効率的に実施できない場合があります。この場合は、パイロットの実行が不可欠です。

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

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

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

プロファイル ファイル、MST ファイル、CMW ファイルが変更されている場合、これらのファイルにバージョン管理を実装して、DSL の管理インストール ディレクトリにコピーして戻す必要があります。 また、すべての変更と変更理由がドキュメント化されていることを確認します。

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

テスタはテストが完了したら、関連パッケージを実稼動環境に作成し、コンピュータのパイロット グループに対してテストする必要があります。 テスタはパッケージを作成するために、SMS Site Properties Manager を使用してパッケージの定義をインポートします。

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

  • Office XP の種類の異なる製品群やコンポーネントを必要としている場所を検索します。 たとえば、Office XP Developer のパイロットを IT 部門で実行し、Office XP Standard のパイロットを財務部門で実行するようなことが適しています。

  • サイト間でワイド エリア ネットワークを経由する Office パッケージの配布と、複数のインストールを同時に実行するときのネットワークとサーバーの負荷の両方を十分にテストできる場所を使用します。

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

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

パイロットのロールバックが必要な場合、以下で説明するように、実稼動環境で使用するアプローチと同じテクノロジ アプローチを使用します。

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

パイロットの結果として、Office XP パッケージまたはプログラムの設定の一部を変更する必要が生じる場合があります。

たとえば、ネットワークの影響を軽減するには、公開をいくつかの小規模なフェーズに細分化する必要があります。 この場合、各公開フェーズで対象のクライアントを特定するために使用した SMS クエリを変更する必要があります (たとえば、各サブネットに同時に実行する公開を限定します)。

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

展開計画

Office XP Professional をグローバルな組織に展開するなど、物理的な展開が複雑なリリースでは、綿密な展開計画が必要になります。

計画者は展開計画を作成するために、展開順序を確認する必要があります。 新規製品の展開の場合は、変更開始段階で始めた経済的な妥当性と分析を考慮する必要があります。 たとえば、新規 Office XP の展開は、主要な役割として他のアプリケーションを使用している財務部門にはほとんど影響を与えませんが、サポート チームと管理チームには多大な影響を及ぼします。 このため、展開の順序を決定する際は、改善したソリューションの展開がこれらの部門に及ぼす影響と利点を見極める必要があります。

また、変更経路を確認する必要があります。 展開の必要性を打ち消すような新規変更が変更経路に追加されている可能性があるので、展開順序を確認する上で役立ちます。

たとえば、展開には 各部門の特定のユーザーに対する Office XP Standard の展開が含まれるとします。 しかし、この RFC が提出および開発されて、リリース パッケージが構築およびテストされた後、企業の標準を Office XP Professional に移行するという戦略的な決定が新たに下されます。 このような場合、Office XP Standard のインストールを完全に行うべきか、却下すべきかを確認するために、経済的な妥当性を完全に調査し、適切なレベルで承認を得る必要があります。

展開順序を確認後、展開に必要なアクティビティ計画を完了し、特定の作業の担当者を決定します。 新規製品では、この種の展開に新規プロセスが関係し、各ユーザーが新しい職務を担うことになるので、展開の担当者について十分検討する必要があります。 このような変更は、変更開発段階とリリース開発段階が強調されますが、このような変更はすぐに効果を発揮し始めることに注意してください。

これまで、展開の前提条件としてさまざまな作業を完了しましたが、この段階では資産の詳細調査が必要です。 調査の結果、ネットワークの帯域幅の能力やディスクの容量の問題など、これまでに発見されなかった要因によっては、展開順序のプロセスに戻り、展開の計画を変更する必要がある場合もあります。

展開順序をレビューする必要がある場合、経済的な妥当性とビジネスに対する妥当性に留意してレビューを完了する必要があります。 ある部門に最初に展開が予定されている場合 (展開によって影響される多数のビジネス プロセスで重要になる場合)、調査の完了前、展開の前提条件が満たされるまでの間、別の部門に展開することは適していません。 この場合、展開全体を保留した方が合理的です。

関係者は、計画が完了し、リソースが割り当てられたら、計画に合意し、Microsoft Project でマイルストーンのステータスを "complete" に更新する必要があります。 組織の共有サイトに計画を追加し、必要に応じて変更ログを更新します。

  • テクノロジ メモOffice XP の配布は比較的大規模なパッケージなので、綿密な計画が必要です。 計画者は、対象とするユーザーまたはコンピュータを判断し、その対象に対応するコレクションを作成する必要があります。

通常、ユーザーや構築の種類によってコンピュータを定義する既存のコレクションがあります。ただし、既存のコレクションは多数のクライアントが含まれているので、少数のコンピュータを対象とする場合は小規模なコレクションを作成する必要があります。 この作業では、展開の速度が低下したり、その他のビジネスに不可欠なアプリケーションに影響を及ぼさないことを確認する必要があります。 前のセクションで概説したスケーラビリティのテストでは、必要な配布ポイントの数と、サーバーやネットワークに過度の影響を及ぼすことなく、Office XP を同時にインストール可能なクライアントの数を確認します。 インストールが必須で、自動インストールが行われる場合は、インストールが任意で、手動によるインストールに比べると同時期にインストールが集中するので、このことが特に重要になります。

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

Active Directory の同期ツールを使用して SMS データベースに組織単位 (OU) (およびすべてのサブ OU) のすべてのコンピュータを登録している場合、このクエリで SMS クライアントではないすべてのコンピュータを検出できます。

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

十分な配布ポイントの提供

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

  • 配布ポイントとディスク容量

  • クライアント アクセス ポイント

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

十分なネットワーク帯域幅の提供

パッケージを所定の期間内に送信するには、サイト間に十分な WAN 容量が必要になります。 WAN 容量を把握すると同時に、サイト間のセンダ設定を確認し、この中間サイトのセンダが別のサイトにパッケージを送信できないという制限が設定されていないことを確認します。 Service Pack などの大規模パッケージの場合は、このことが特に重要になります。

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

正常に機能している SMS サイトの確保

SMS サイトは正常に機能している必要があります。 SMS ステータス システムをチェックし、すべてのサービスがすべてのサイト システム上で実行されていることを確認します。 詳細については、https://www.microsoft.com/japan/systemcenter/default.mspx にある『System Management Server 運用ガイド』を参照してください。

最新インベントリの確保

一般的には、最新のインベントリ情報がクライアントに提供される必要があります。 最新のインベントリが必要な場合、https://www.microsoft.com/japan/systemcenter/default.mspx にある『Microsoft Systems Management Server を使用した修正プログラム管理 - 展開ガイド』の「ベースラインの設定」で説明されている操作を実行できます。 インベントリの実行、サイトへの結果の返送、サイトのデータベースへの登録には、十分な時間が必要です。 すべてが単一のサイトにまとめられ、インベントリの提供情報がそのサイトで作成される場合、この操作によるデータ センター サーバーの遅延は短縮されます。

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

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

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

  • 注意配布ポイントに Office XP コードをホストするのに十分な容量を確保することも重要です。 配布ポイントの容量を確認するには、配布ポイントでインベントリを実行し、サイト コンポーネントをチェックし、各ディスク容量を表示します。 この手順は、サイトごとに実行できます。 また、すべてのサーバーの使用可能なディスク容量を表示する以下のクエリを実行することもできます。
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

展開準備

新しい製品リリースごとに、実稼働環境を準備する必要があります。 このプロセスは、リリース管理の SMF ガイドに記述されているプロセスとほとんど同じです。

ハードウェア、ソフトウェア、テクノロジなどのリソースは、取りまとめて展開します。

展開に関する通知は、すべての関係者に確実に通知する必要があります。 ユーザー、サポート チーム、管理チーム、技術専門家、元の変更を承認した CAB のメンバに通知します。

サポート担当者と管理担当者は、新規製品のトレーニングを受ける必要があります。 サポート担当者や管理担当者がまったく初めて扱う製品の場合は、新規プロセスに関して教育を受けるために相当なトレーニングが必要になることを留意しておくことが重要になります。 たとえば、Office XP には多数の新機能があり、この機能が組織にとって必要であればこれをトレーニングに含める必要があります。 Office XP の新機能には、エラー レポートの管理を支援する企業内エラー報告ツールがあります。 その他の Office 製品に精通している管理者でも、この機能に関するトレーニングを受ける必要があります。

展開用に実稼動環境を準備し、展開を続行するための条件が揃っているかどうかを判断します。 条件が満たされていない場合、変更管理で状況を認識し、展開を中止する必要があります。 また、展開を続行できない理由に関する詳細情報により、変更管理システムを更新する必要があります。

すべての条件が満たされて、展開を計画どおり続行できる場合、変更管理システムを適宜更新します。 内部の知識ベースも新規製品の展開に関する新情報に更新します。

以下に、Office XP を組織に展開する前の最終手順を示します。

リソースの取り まとめ

SMS 環境を詳細に調査した結果、SMS 階層を変更する必要があると判明する場合があります。 たとえば、組織で WAN の帯域幅を検討した結果、新規 SMS サイトが必要だと判断するとします。 一部のサイトで展開に必要な配布ポイントを追加したり、パッケージのサイズに対応するために一部の配布ポイントのディスク容量を増加する必要があります。

SMS 管理者は、このような新規 SMS リソースを SMS 階層に構成する必要があります。 詳細調査の一部のアクションを繰り返し実行し、新規コンポーネントが変更に向けて準備できていることを確認します。 このようなアクションには以下のものがあります。

  • 新規サイト システムが実行されていることを確認します。

  • 新規配布ポイントがオンライン状態であり、十分なディスク容量があることを確認します。 新規配布ポイントを稼動させる場合、SMS で定義されている既存の配布ポイント グループにも追加する必要があります。

  • パッケージを新規配布ポイントにコピーする必要があるかどうか判断します。 新規配布ポイントを配布ポイント グループに追加するときに、その配布ポイント グループに既に展開されているパッケージは新規配布ポイントに自動的にコピーされません。

  • 追加したディスク容量が使用可能であることを確認します。

実稼動環境の準備 : SMS パッケージの作成

パッケージに関連付けられたプログラムを含むパッケージの定義は、受け入れテストの段階で保存され、SMS の実稼働環境にインポートできるようになります。 この定義をインポートするには、BackOffice リソース キットの SMS Site Properties Manager を使用します。これは、テスト環境からのエクスポートに使用したのと同じツールです。

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

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

配布ポイントの割り当て

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

一般的に、すべてのクライアントで Office XP が必要なので、Office XP はすべての配布ポイントに展開されます。 データ センターのサーバー専用の配布ポイントがある場合、一部のサーバーでは警告やその他のイベントのメッセージング用に Outlook をインストールする必要があるので、Office XP はこのサーバーにも展開される必要があります。

SMS パッケージの場合は、配布ポイントのプロパティを SMS コンソールにセットアップする必要があります。このとき、各 SMS サイトの対象コンピュータのカテゴリに関する情報を使用して、影響を受けるすべてのサイトの配布ポイントが確実に含まれるようにします。 対象コンピュータの一覧を返すクエリは、各サイトのコンピュータの明細も提供できます。

SMS バックログの確認

SMS パッケージをエンド ポイントに提供して、できる限り迅速に実行し、実行インジケータを同様に SMS 集中管理サイトにレポートするには、バックログや SMS 階層における遅延が発生しないようにする必要があります。 つまり、システム内のどこにも中間サイト トラフィックのキューが存在せず、インベントリの受信トレイが空で、すべてのサイトのステータス メッセージが最新の状態である必要があります。

SMS 階層が正常であることを確認する手段の詳細については、https://www.microsoft.com/japan/systemcenter/default.mspx にある SMS 管理ガイドを参照してください。

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

SMS によりエンド ポイントに Office XP をインストールする前に、パッケージ ファイルが配布ポイントに準備できていることを確認します。 SMS ステータス メッセージを使用して、パッケージがすべてのサイト上の該当の配布ポイントに正常に配布されていることを確認できます。 サイト間で使用可能な WAN 帯域幅に制限がある場合、パッケージをすべての配布ポイントに準備するのに時間を要する可能性があります。 特に Office XP パッケージはサイズが大きいので、時間がかかります。 媒体使用センダを使用して接続状態の悪いサイトにパッケージを送信する場合、メディアを作成して発送するプロセスに配慮し、リモート サイトへのパッケージの配送状況の進捗を手動で追跡する必要があります。

リリース展開

新規製品の展開に関するタスクとアクティビティは、展開の複雑性と規模、リリース パッケージの性質などによって異なります。 ただし、すべての場合において、高度なプロセスに従う点は共通しています。

展開グループは、承認済みの公開計画に基づいて選択されます。 ユーザーは、新規製品のトレーニングを受けます。 トレーニングでは、製品自体だけでなく、カスタム システムや業務慣例など、使用中の既存のソリューションとのインターフェイスについても習得します。

次に、リリースを展開します。 当初の RFC に記載された成果物と受け入れ基準に基づいて、成功か失敗かを判断します。この場合、変更管理プロセスとリリース管理プロセス全体でこの RFC が変更または更新されていないことを前提とます。 展開が成功した場合、今回の経験に基づいて手順を更新します。 たとえば、最初のリリースとインストールがシームレスでなく、プロジェクトの次のリリース段階でより多くユーザーへの展開が予定されている場合、リリース パッケージを変更する必要があります。ただし、リリース展開が失敗し、理由が明確でない場合、問題管理を導入して根本原因の分析を実行する必要があります。

妥当なレベルで展開が実行されていれば、ロールバックの必要はありません。 ただし、インストールを完全に取り消す必要がある場合もあります。この場合、取り消し計画が必要となり、公開を中止し、変更管理プロセスでこの問題の発生を通知する必要があります。 経済的に妥当であれば、この状況を改善するために RFC が変更管理プロセスとリリース管理プロセスに戻されて管理されます。

また、インストールでは、修正プログラムや Service Pack によって修正可能な制限付きの機能を提供する場合があります。 このような修正の必要性は、修正プログラム管理プロセスにより確認します。このプロセスでは、新規製品の修正プログラム通知を受け取るために、新しいテクノロジの流れが確立されます。

  • テクノロジ メモコンピュータを識別する SMS コレクションまたはクエリが、既に作成されている必要があります。 ただし、このようなコレクションは、どのクライアントがどのアプリケーションを取得するかを制御するので、同時に同じ Office パッケージを配布するコンピュータをグループ化するようデザインします。

大規模コレクションは、いくつかの小規模コレクションに分割でき、ネットワークとサーバーが同時にインストールするクライアント数を確実に処理できるようにします。

管理者は段階的に公開するために、単一のクエリとコレクションを使用する必要がありますが、公開の段階ごとにクエリを修正する必要があります。 クエリは入れ子にできないので、適切なクエリを識別するために適切な命名規則が存在する必要があります。 以下に例を示します。

  • すべての管理職ワークステーション。

  • OfficeXP 展開用実行バッチ 1。

  • OfficeXP 展開用実行バッチ 2。

管理者は、提供情報のステータスを確認し、すべてのワークステーションで提供情報が正常に完了していることも確認します。

次に、数台のワークステーションにリモート接続し、Office XP が適切に動作し、ワークステーションで利用できる必要のあるすべてのオプションが存在することをテストします。

次に、Office Update Inventory ツールの提供情報の実行スケジュールを設定し、Office XP がインストールされたすべてのコンピュータをスキャンして関連修正プログラムを検出します。 このスキャンでは、元のリリースがデザインされた後にリリースされた修正プログラムや見落とされていた修正プログラムを検出できます。

管理者は、Update Inventory ツールの提供情報が完了したら、"適用可能な修正プログラムの種類別の数 (Count of applicable patches by type)" レポートをチェックして、Office の修正プログラムが識別されたかを確認します。

ラッパー技法 (上記参照) を使用するのではなく、CD-ROM によって Office XP をリモート クライアントにインストールするよう指示されている場合、インストールは SMS の外部で行われます。 この場合、このクライアントに関する提供情報は存在しないので、インベントリ更新データによってのみ進捗を監視できます。

展開グループの選択

パッケージの提供対象とする SMS クライアントを識別するために、1 つ以上の SMS クエリを範囲の設定段階で既に使用しました。 このようなクエリをコピーして、対象コレクション作成用のクエリとして使用するために修正する必要があります。 以下に例を示します。

  • サーバー、ワークステーション、ポータブル コンピュータにはそれぞれ異なるスケジュールが設定されて、異なるプログラムを実行する可能性があるので、独立したクエリが必要です。

  • 異なる部門や地理的に離れた場所にあるコンピュータにも異なるスケジュールが設定されるので、独立したクエリが必要です。

場合によっては、イベントのサブコレクションの規模が大きすぎることがあります。 このような場合、管理者は手動でコレクションのメンバーシップを小規模なコレクションに分割します。 コレクションのメンバーシップの条件のセットがサブネットの基づいている場合、このアクションが必要になります。

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

  • 管理者は、単一のクエリとコレクションを使用して、公開の段階ごとにクエリを修正します。

  • 管理者は、単一の SMS クエリを定義し、そのクエリを使用して単一のコレクションを作成します。 最初に、元のクエリを修正して、公開の最初の段階で対象とするクライアントの範囲を絞り込みます。

  • 管理者は、単一のコレクションを使用して提供情報を作成します。 公開の最初の段階が完了後、クエリを修正し、次の段階のクライアントを含めます (たとえば、次に展開するサイト)。 プログラムに自動的に新しいクライアントのセットが提供された後、コレクションを手動で更新するか、または定義済みのスケジュールで更新します。

  • 管理者は、クエリに対する変更を監視し、それ以前のすべてのバージョンを保存しておきます。 段階的な手法でロールバックが必要な場合、または単に直前の段階に戻す必要がある場合、単純に最新のクエリ テキストを取得します。 このアプローチにより、クエリ、コレクション、および提供情報の数を最小限に抑えることができますが、公開の進捗に伴い、管理者による介入が必要になります。

  • 管理者は、単一の提供情報とコレクションを使用します。これにより、SMS ステータス メッセージを確認することで、Office XP の全体的な公開ステータスを容易に確認できます。

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

展開用にコレクションを作成したら (Office XP をインストールするすべてのクライアントを含むか、サブネットだけを含むかにかかわらず)、関連する提供情報を作成し、コレクションに Office XP をインストールするプログラムを実行します。 この提供情報のスケジュールは、変更認可時に決定されたインストール スケジュールに従って設定されます。 インストールのスケジュールの例は以下のとおりです。

  • ログオフ状態のコンピュータにインストールするための夜間展開。

  • ユーザーへの影響が最小限に抑えられる時間帯。

最初のコレクションをクライアントのサブネットに展開する場合、コレクションの範囲がクライアントのインストールに伴い増加される可能性があります。 この手順を管理して、同時にインストールする数をネットワークとサーバーの容量に合わせて制限します。

ネットワークに追加した新規コンピュータでは、SMS により自動的に Office XP を受け取る必要があるので、コレクションと関連する提供情報が SMS から決して削除されないようにします。 新規クライアントが Office XP のインストール対象を決定するためのクエリに一致すると、Office XP パッケージが提供されます。 これは、空のコレクションに提供されている提供情報が存在する可能性があることを意味します (展開済みのすべてのコンピュータに Office XP がインストールされており、新規コンピュータがオンラインになったときに、コレクションが新規コンピュータだけをピック アップしている場合)。

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

展開は成功したか ?

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

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

  • コレクションに含まれていたが、提供情報を受け取らなかったクライアント。

  • 提供情報を受け取ったが、実行していないクライアント。

  • プログラムを実行したが、失敗したクライアント。

これには、関連するすべてのステータス メッセージを取得し、対象のコレクションのクライアントの一覧と照合するスクリプトが必要になります。 このスクリプトでは、特定のクライアントの特定の提供情報に関する成功ステータス メッセージに続いて、失敗ステータス メッセージが存在する場合を考慮する必要があります。

SMS コンソールから直接入手可能なステータス メッセージも使用できます。 [提供情報ステータス] で、Office XP の展開に使用した提供情報を選択し、すべてのステータス メッセージを表示できます。 インストールの成功または失敗に関連するステータス メッセージだけを表示することもできます。

特に大規模展開の場合、このようなステータス メッセージを調査することにより、簡単に目視で確認するよりも有用な結果を返すことができます。 特定のステータス メッセージのクエリを作成すると、より役に立つ結果を返すことができます。

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

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 <INSERT COLLECTION担 QUERY HERE>

および

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 = 鄭vailable Programs Manager (APM)・and 
stat.MessageID = 10008 and att2.AttributeID = 401 and att2.AttributeValue 
=・lt;INSERT ADVERTISEMENT ID HERE>・)

このクエリでは、目的の結果を返す入れ子になったサブ クエリを使用しています。 クエリは、提供情報が提供された対象コレクションに使用したクエリと同じですが、システム名のみを返します。 Office XP がインストールされていないすべての Windows XP システムを返すクエリは、以下のようになります。

(select SMS_G_System_SYSTEM.Name from SMS_R_System 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_SoftwareFile.FileName 
= 展inword.Exe・and 
(SMS_G_System_SoftwareFile.FileVersion 
like ・0.0.2627・or 
SMS_G_System_SoftwareFile.FileVersion 
like ・0.0.3416・)

使用されたその他のサブクエリは、特定の提供情報に関するすべての "成功" ステータス メッセージ (10008) を返します。 クエリ全体では、コレクションに属しているのに、Office XP のインストールに成功したシステムのリストに入っていないシステムを返します。

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

失敗の根本的原因の分析

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

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

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

既に部分的に展開済みの Office XP のリリースをロールバックするには、インストールを正常に実行済みの SMS クライアントにのみアンインストール プログラムを提供する必要があります。 Office XP をインストールする提供情報を正常に実行しているコンピュータを識別するクエリを作成することにより、リリースをアンインストールする必要のあるコンピュータの一覧を作成できます。

または、SMS Inventory Status ツールを使用して、Office XP がインストールされているシステムを識別できます。 この場合、インストールの最後に強制的なインベントリ サイクルを組み込むことにより、インベントリを最新の状態にする必要があります。

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

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

公開は完了したか ?

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

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

変更レビュー

新規製品の RFC の変更レビュー段階では、その他の変更と同様に、変更が目的を満たしているかどうかを判断します。

たとえば、公開の最初の段階では Office XP は機能しているものの、その後再評価が必要な問題が確認されることがあります。 この場合、公開の中止、またはこの問題を解決できる修正プログラムの識別など、次に実行するアクションを決定する必要があります。

変更の無効にする必要があれば、RFC 承認段階と同じように、経済的な調整および影響分析を実施する必要があります。 新たに展開した製品に関して修正プログラムを使用する場合は、https://www.microsoft.com/japan/systemcenter/default.mspx の展開ガイドを参照してください。

  • テクノロジ メモ以下に、変更レビュー時に発生する可能性のある問題の例を示します。

IT 環境での変更の監視

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

変更の取り消し

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

このようなコンピュータを識別するには、以下の方法のいずれかを使用します。

  • Office XP を正常にインストールした SMS クライアントを識別する元の提供情報ステータス メッセージを使用し、このようなコンピュータに基づいてコレクションを作成します。

  • Office XP がインストールされたコンピュータを検索する、ソフトウェア インベントリに基づくクエリを使用します。

最初の方法は、セットアップが複雑です。 また、実稼働環境を再評価して製品のアンインストールに失敗したコンピュータを検出することはありません。 ただし、新規インベントリが SMS 階層全体に伝達されるように、インベントリ サイクルを待機する必要がなく、その後の遅延も生じないという利点があります。

このようなコレクションで使用できるクエリは、以下のような形式になります。

select * 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 =<INSERT ADVERTISEMENT ID HERE>)

このクエリは、提供情報で定義されたとおりに Office XP インストール プログラムを正常に実行したコンピュータのみを返します。 提供情報は、ロールバックが完了するまで削除する必要はありません。削除すると、提供情報 ID が無効になるので、このクエリは正しく機能しなくなります。

付録

寄稿者

プログラム管理チーム

Anthony Baron, Microsoft Corporation

主執筆者

Nigel Cain, Microsoft Corporation

Ben Gamble, Microsoft Corporation

Kamal Patel, Microsoft Corporation

Andrew Speake, The G2G3 Group Ltd.

テクニカル ライタ

Jerry Dyer, Microsoft Corporation

Angus Stewart, The G2G3 Group Ltd.

編集者

Matt Baszner, Volt Technical Services

Pat Rytkonen, Volt Technical Services

その他の寄稿者

Mark Ross Sutherland, The G2G3 Group Ltd.