Server Software Packagesの理解

Policy and Distribution Servicesには、サーバファイルおよびアプリケーションの配布やインストールを自動化および標準化するための手段が用意されています。これには、NLMTM のバージョン、環境設定ファイル、データベースなどを標準化する機能も含まれます。次の節を参照してください。


Server Software Packagesおよびコンポーネントの理解

サーバにインストールするためにサーバファイルおよびアプリケーションを配布するには、ソフトウェアパッケージにソフトウェアを含める必要があります。ソフトウェアパッケージは、ConsoleOne(R)のServer Software Packagesネームスペースに作成します。ソフトウェアパッケージの作成は、ソフトウェアのインストール実行可能ファイルの構築に似ています。

次の図は、ソフトウェアパッケージとパッケージコンポーネントの関係を示しています。


Server Software Packagesのサンプルツリー

次の点に注意してください。


ソフトウェアパッケージとコンポーネントの環境設定の理解

ソフトウェアパッケージとそのコンポーネントには、環境設定情報とインストールの要件が含まれます。各コンポーネントオブジェクトはそれぞれの環境設定パラメータによって制御されるので、インストール前のアクション、インストールのアクション、インストール後のアクションなど、1 つのソフトウェアパッケージについて複数のコンポーネントを使用できます。

サーバファイルおよびアプリケーションの配布やインストールに関する次のような項目を設定できます。


ソフトウェアパッケージのインストールの前提条件の要求

ソフトウェアパッケージでインストールの前提条件を指定できるだけでなく、パッケージの各コンポーネントでもインストールの前提条件を指定できます。前提条件は次の順序で確認され、インストールできるかどうかが判断されます。

  • パッケージの前提条件が満たされていない場合は、どのコンポーネントもインストールされません。
  • パッケージの前提条件が満たされている場合は、コンポーネントをインストールできます。
  • コンポーネントの前提条件が満たされていない場合は、そのコンポーネントはインストールされません。

一部のコンポーネントがインストールされ、他のコンポーネントがインストールされない場合があるので、ソフトウェアパッケージが部分的にインストールされる可能性があります。

重要:  前提条件を指定する場合は、すべてのコンポーネントに等しく適用される前提条件はソフトウェアパッケージレベルで作成し、特定のコンポーネントに固有の前提条件はコンポーネントレベルで作成します。


ソフトウェアパッケージの命名

ソフトウェアパッケージを作成する場合、最初は.spkという拡張子を付けます。これは、まだコンパイルされていないソフトウェアパッケージを表します。このファイルには、ソフトウェアパッケージとそのすべてのコンポーネントのインストールの要件がすべて含まれています。

警告:  ソフトウェアパッケージ名に2バイト文字を使用しないでください。このソフトウェアパッケージについてレポートを実行したときにエラーの原因になります。


ソフトウェアパッケージをインストールする順序の決定

Distribution内のServer Software Packagesの順序の指定に関して注意事項が2つあります。


複数のDistributionを使用したソフトウェアパッケージの配布順序の強制的な指定

1つのDistributionに複数のソフトウェアパッケージを含める場合は、次の点に注意してください。

  • Distributionを構築するときに、複数のソフトウェアパッケージは特定の順序でDistributionにまとめられるわけではありません。
  • Distributionを抽出してインストールするときに、複数のソフトウェアパッケージは保証された順序でサーバに適用されるわけではありません。
  • 1つのDistributionに含まれ、特定の順序でインストールが開始された複数のソフトウェアパッケージは、同じ順序でインストールが終了するわけではありません。

ソフトウェアパッケージを特定の順序でインストールするには

  1. 各ソフトウェアパッケージをそれ自体のDistributionに(Distributionごとにソフトウェアパッケージを1つ)配置します。

  2. Distributionを送信して抽出する順序をスケジュールすることによって、ソフトウェアパッケージをインストールする順序を制御します。


依存関係を使用したソフトウェアパッケージの配布順序の強制的な指定

ソフトウェアパッケージを特定の順序でインストールする別の方法としては、複数のSoftware Package Distribution間に依存関係を使用します。たとえば、前のソフトウェアパッケージと後続のソフトウェアパッケージの間に依存関係を確立します。

例:

  1. Software Package Distribution 1を作成します。
  2. Software Package Distribution 1からインストールされる内容と何らかの依存関係を持たせてSoftware Package Distribution 2を作成します。
  3. 両方のDistributionを送信します。
  4. SubscriberがSoftware Package Distribution 2を最初に抽出しようとすると、抽出は失敗します。
  5. SubscriberがSoftware Package Distribution 1を抽出すると、Software Package Distribution 2を抽出するのに必要な依存関係がSubscriberに提供されます。
  6. これにより、Subscriberは正常にSoftware Package Distribution 2を抽出できます。

依存関係を使用すると、スケジュールを使用してインストール順序を制御する必要がありません。


ソフトウェアパッケージの順序によるロールバックへの影響

1つのDistributionに複数のソフトウェアパッケージが含まれている場合、開始した順序で抽出が終了するとは限らないので、ロールバックもこの影響を受けます。

Distributionに含まれるソフトウェアパッケージの処理の順序を指定することはできますが、この順序は保証されません。これは、ソフトウェアパッケージの処理を終了するまでにかかる時間が各パッケージによって異なり、ロールバックの順序を決定するのがソフトウェアパッケージの処理の終了時刻であるからです。

つまり、最後に正常に処理されたソフトウェアパッケージをロールバックした後、処理が終了した順序とは逆の順序でのみ、その他のソフトウェアパッケージをロールバックできます。

［Package List］コマンドを使用して、ソフトウェアパッケージの処理が終了した順序を表示できます。アスタリスクは、次にロールバックが可能なパッケージを示します。

ロールバックの詳細については、ソフトウェアパッケージのインストールのロールバックを参照してください。


抽出したファイルの実行

Software Package Distributionでは、ソフトウェアパッケージからサーバにコピーされるファイルの中に、パッケージの抽出時に実行する実行可能ファイルが含まれている場合があります。

ソフトウェアパッケージを通じて配布される実行可能ファイルを実行するには、ソフトウェアパッケージのファイルに対して、実行前後のアクション(実行順序など)を設定します。前後のアクションは、Server Software Packageの作成時とSoftware Package Distributionの作成時に使用できます。

詳細については、Distributionの前後の処理およびソフトウェアパッケージコンポーネントの環境設定を参照してください。


ソフトウェアパッケージのコンパイル

コンポーネントの環境設定など、ソフトウェアパッケージを定義した後、ソフトウェアパッケージをコンパイルする必要があります。この処理では、ファイルやアプリケーションとその環境設定を配布用の1つのファイルに圧縮します。

コンパイルされたソフトウェアパッケージのデフォルトの拡張子は.cpkです。コンパイル済みのバージョンには、ソフトウェアパッケージが表すファイルやアプリケーションをインストールするために必要なすべてのファイルが含まれています。

重要:  コンパイル済みファイル名の指定を求められたときに.spkファイルのパスとファイル名を指定すると、その.spkファイルは上書きされ、編集できなくなります。コンパイル済みバージョンの名前を指定するときには、.cpkという拡張子を使用してください。

ソフトウェアパッケージにはコピーされる多くのファイルが含まれる場合があるので、.cpkファイルのサイズは非常に大きく(数百メガバイト)になる可能性があります。したがって、通常、.cpkファイルは十分な空きディスク容量があるサーバに保存してください。

ただし、ソフトウェアパッケージによって単純な機能を実行することもでき、この場合.cpkファイルのサイズは比較的小さくなるため、ワークステーションに保存することもできます。たとえば、ファイルサーバ上のディレクトリを削除するだけのためにソフトウェアパッケージを設定することもできます。Server Software Packagesによるサーバ上のディレクトリの削除を参照してください。

ロールバックに対応したソフトウェアパッケージが正常にインストールされると、サーバ上にロールバックパッケージが作成されます。このロールバックパッケージを処理すると、サーバはパッケージがインストールされる前の元の状態に戻ります。詳細については、ソフトウェアパッケージのインストールのロールバックを参照してください。


ソフトウェアパッケージへのアクセス

ソフトウェアパッケージを保存する場所(ワークステーションまたはサーバ)は、ソフトウェアパッケージの管理方法によって異なります。

Server Software PackagesコンポーネントはConsoleOneのネームスペースを使用するので、ConsoleOneを実行している任意のワークステーションまたはサーバからソフトウェアパッケージにアクセスできます。

ただし、次の点に注意する必要があります。

複数のワークステーションからのソフトウェアパッケージの管理については、Server Software Packageの管理を参照してください。


ワークステーションからのConsoleOneの実行

ワークステーションからConsoleOneを実行し、ソフトウェアパッケージをそのワークステーションに保存する場合、ConsoleOne内のそのパッケージは、ConsoleOneを実行する他のワークステーションやサーバで利用できません。


サーバからのConsoleOneの実行

異なるワークステーションでサーバ上のConsoleOneを実行する場合は、各ワークステーションのサーバへのドライブマッピングが同じである必要があります。ドライブマッピングが異なる場合、そのサーバに保存したソフトウェアパッケージを別のワークステーションで読み込むことができません。

たとえば、次のような場合にはパッケージを見つけることができます。

  1. ワークステーションAからConsoleOneを実行してサーバAにアクセスします。
  2. サーバAはワークステーションAのS:ドライブとしてマッピングされています。
  3. pkg_a.spkをサーバAに保存します。
  4. ワークステーションBからConsoleOneを実行してサーバAにアクセスします。
  5. サーバAはワークステーションBでもS:ドライブとしてマッピングされています。
  6. 両方のワークステーションがS:ドライブにマッピングされているので、pkg_a.spkを見つけることができます。

次のような場合にはパッケージを見つけることができません。

  1. ワークステーションAからConsoleOneを実行してサーバAにアクセスします。
  2. サーバAはワークステーションAのS:ドライブとしてマッピングされています。
  3. pkg_a.spkをサーバAに保存します。
  4. ワークステーションBからConsoleOneを実行してサーバAにアクセスします。
  5. サーバAはワークステーションBではT:ドライブとしてマッピングされています。
  6. pkg_a.spkはS:ドライブに保存されており、T:ドライブでパッケージを検索しているので、パッケージを見つけることはできません。

この2つの例の違いは、各ワークステーションでのサーバAに対するドライブ名だけです。


ソフトウェアパッケージの配布

Distributionには、インストールされるソフトウェアパッケージまたは抽出されるファイルのグループを含めることができます。

Policy/Package Agentは、SubscriberサーバにSoftware Package Distributionを抽出またはインストールします。

ソフトウェアパッケージを作成するときに、ターゲットSubscriberサーバにパッケージをインストールするために満たしていなければならないシステムの要件をパッケージに含めることができます。Subscriberが要件を満たしている場合、パッケージが実際にインストールされる時期は購読スケジュールによって決まります。


クラスタへのソフトウェアパッケージの配布

ソフトウェアパッケージを含むDistributionをクラスタに送信して各ノードのsys:ボリュームを更新する場合、クラスタ内で現在Subscriberソフトウェアを実行しているノードだけがパッケージを受信します。

クラスタ内のノードを構成するコンピュータがSubscriberソフトウェアを実行するので、ある時点でSubscriberソフトウェアをアクティブに実行しているノードは1つだけです。

したがって、Software Package Distributionを使用してクラスタ内の各ノードのsys:ボリューム上のファイルを更新する場合は、手動でこの作業を行う必要があります。まず、1つのノードを更新し、そのノードを停止することによって、フェールオーバーシーケンス内の次のノードが前のノードでエラーが発生したことを確認し、Subscriberソフトウェアの実行が開始されるようにします。次に、そのコンピュータを更新して停止するという作業を、クラスタ内のすべてのコンピュータが更新されるまで続けます。次に、停止したすべてのサーバを再起動すると、プライマリノードのコンピュータが再び処理を引き継ぎます。

Software Package Distributionを使用して、Tiered Electronic Distributionの.ncfファイルなど、クラスタコンピュータ自体に保存されているファイルを更新できます。これは、Subscriberソフトウェアがクラスタコンピュータの共有ハードディスクドライブに保存されているからです。


Server Software Packageの管理

次の節では、Server Software Packageのファイルの保存場所および管理方法について説明します。


Server Software Packageのファイルの理解

ソフトウェアパッケージに関連するファイルには3つの種類があります。

  • 環境設定ファイル(.spk): Server Software Packageを作成する場合、最初にパッケージの環境設定ファイル(.spk)を作成します。このファイルの環境設定は、ConsoleOneのServer Software Packagesネームスペース内のソフトウェアパッケージオブジェクトのプロパティで作成します。

    .spkファイルは一般的にサイズの小さい(約100KB)ファイルです。したがって、このファイルは一般的に、ソフトウェアパッケージの作成や管理に使用するConsoleOneのインスタンスを実行しているワークステーションに保存できます。

  • コンパイル済みファイル(.cpk): ソフトウェアパッケージをコンパイルするときに、.spkファイルの環境設定情報から.cpkファイルが作成されます。このファイルは、ファイルや機能などのソフトウェアパッケージの内容を提供します。.cpkファイルはソフトウェアパッケージの内容をサーバにインストールするために使用されます。

    コンパイル済みのソフトウェアパッケージには多数のファイルが含まれる場合があるので、一般的に、.cpkファイルは十分な空きディスク容量があるサーバに保存します。ただし、機能だけを含む小さな.cpkファイルはワークステーションに保存することもできます。

  • 初期設定ファイル(.ser): 初期設定ファイル(snapinprefs.ser)は、ソフトウェアパッケージの作成に使用したワークステーション上に自動的に作成されます。このファイルには、ソフトウェアパッケージの.spkファイルへのポインタが含まれています。

    この初期設定ファイルによって、ソフトウェアパッケージがConsoleOneのネームスペースにあることを確認できます。つまり、ソフトウェアパッケージがConsoleOneのインスタンスのServer Software Packagesネームスペースに表示されるのは、.spkファイルのパスがConsoleOneのインスタンスを実行するワークステーション上にある初期設定ファイルにリストされている場合だけです。

新しいソフトウェアパッケージを作成する場合は、.spkファイルのローカルパスを指定します。ソフトウェアパッケージをコンパイルする場合は、サーバの.cpkファイルのパスを指定します。ConsoleOneを終了した後、ソフトウェアパッケージを作成、削除、またはコンパイルするたびに、.spkファイルのパスがsnapinprefs.serファイルに記録されます。

.cpkファイルへのパスもsnapinprefs.serファイルに記録されます。次回ソフトウェアパッケージをコンパイルするときには、ウィザードによって.cpkファイルの以前の保存場所が表示されるので、パッケージをコンパイルするたびにファイルの場所を覚えておく必要はありません。ただし、Tiered Electronic Distributionを使用して.cpkファイルを配布する場合は、.cpkファイルを保存した場所をメモしておく必要があります。.cpkファイルの場所はソフトウェアパッケージのプロパティには保存されないからです。


ソフトウェアパッケージ管理オプションの理解

特定のワークステーションを1台だけ使用して、すべてのソフトウェアパッケージファイルを表示、作成、および管理している場合は、.spkファイルをそのワークステーションに保存できます。

複数のワークステーションからソフトウェアパッケージを管理することもできます。この場合は、.spkファイルの保存場所をネットワークサーバに一元化する必要があります。また、この方法では、マスタsnapinprefs.serファイルを使用して、任意のワークステーションからすべてのソフトウェアパッケージを表示できるようにする必要があります。

次の2つの節では、これらの管理オプションについて説明します。


1台のワークステーションによる.spkファイルの保存と管理

ワークステーションを1台だけ使用してソフトウェアパッケージを表示、作成、および管理する場合は、.spkファイルをワークステーションに、.cpkファイルをサーバに保存できます。

ConsoleOneがインストールされているワークステーションからConsoleOneを実行している場合でも、ネットワークサーバ上にインストールされているConsoleOneを使用するワークステーションからConsoleOneを実行している場合でも、ConsoleOneを実行するために使用されているワークステーション上のsnapinprefs.serファイルが更新されます。


.spkファイルのネットワークサーバへの保存と複数のワークステーションからの管理

複数のワークステーションを使用して同一セットのソフトウェアパッケージを表示、作成、および管理する場合は、すべての.spkファイルをネットワークサーバに保存して、各ワークステーションからアクセスできるようにする必要があります。

異なるワークステーションを使用して、異なるソフトウェアパッケージのセットを管理することもできます。任意のワークステーションを使用して.spkファイルを作成すると、それ自体のソフトウェアパッケージ初期設定ファイルが、ソフトウェアパッケージの管理に使用するワークステーションに作成されます。

snapinprefs.serファイルのマスタコピーを使用する場合は、複数のワークステーションからすべてのソフトウェアパッケージを管理できます。


ソフトウェアパッケージ初期設定ファイルの理解

ConsoleOneでServer Software Packageオブジェクトを作成すると、ソフトウェアパッケージ初期設定ファイル(snapinprefs.ser)が、ConsoleOneを実行しているワークステーションの次の場所に作成されます。

c:\documents and settings\user_ID\.consoleone (Windows 2000)

user_IDは、ログインしたときの権限(管理者など)に関連するユーザディレクトリです。

ソフトウェアパッケージのフルパスおよびファイル名はドライブに依存します。snapinprefs.serファイルには、ワークステーションによって作成された各.spkファイルのドライブ名、パス、およびパッケージ名が記述されます。

snapinprefs.serファイルは各ワークステーションに固有です。ワークステーションを使用して.spkファイルを追加または削除するたびに更新されるのは初期設定ファイルです。したがって、3台の異なるワークステーションを使用して.spkファイルを作成した場合、各ワークステーションに1つずつ、3つの異なるsnapinprefs.serファイルが作成されます。

ConsoleOneを起動すると、そのワークステーションで実行されているConsoleOneのインスタンスによって、そのワークステーション用のsnapinprefs.serファイルが作成されているかどうかが確認されます。また、ConsoleOneがそのワークステーションにインストールされているか、またはサーバにインストールされているインスタンスをそのワークステーションで実行しているかが確認されます。snapinprefs.serファイルが存在しない場合は、ConsoleOneを終了するときにsnapinprefs.serファイルが作成されます。snapinprefs.serファイルが存在する場合は、snapinprefs.serファイルが更新され、新しい.spkファイルへのフルパスが保存されます。

snapinprefs.serファイルを、あるワークステーションから別のワークステーションにコピーできます。ただし、snapinprefs.serファイルを別のワークステーションからのコピーと置換した後、変更を有効にするには、ConsoleOneを再起動する必要があります。

パッケージを作成した後でドライブマッピングを変更すると、パッケージに対するsnapinprefs.serファイルの場所が変わるので、ソフトウェアパッケージが使用できなくなる場合があります。ただし、UNCパスを使用している場合は、ワークステーションがそのUNCパスにアクセスできる限り、この問題は発生しません。

ワークステーション上のsnapinprefs.serファイルを置き換える場合は、新しくコピーしたsnapinprefs.serファイルに不足しているソフトウェアパッケージを手動で挿入する必要があります。この作業を行わない場合、置換されたsnapinprefs.serファイルにリストされていたソフトウェアパッケージは、ワークステーション上でアクセスできなくなります。

ワークステーションをソフトウェアパッケージの作成に一度も使用したことがない場合でも、別のワークステーションから適切な場所(c:\....\.consoleone)にsnapinprefs.serファイルをコピーできます。コピーした後、ConsoleOneを起動すると、コピーしたsnapinprefs.serファイルにリストされていたすべてのソフトウェアパッケージが表示されます。

詳細については、例:マスタsnapinprefs.serファイルの使用を参照してください。


複数のワークステーションからのソフトウェアパッケージの管理

複数のワークステーションを使用して同一セットのソフトウェアパッケージを作成、削除、およびコンパイルする場合は、次のようにしてください。

  1. .spkファイルをネットワークサーバ(通常、対応する.cpkファイルを保存しているサーバ)に保存し、すべてのソフトウェアパッケージが任意のワークステーションからアクセスできるようにします。
  2. .spkおよび.cpkファイルが保存されているサーバにワークステーションをマッピングする場合は、すべてのワークステーションで同じドライブ名を使用します。
  3. すべてのワークステーションでソフトウェアパッケージの追加、削除、およびコンパイルの情報を最新情報に更新するために使用されるマスタsnapinprefs.serファイルを作成します。マスタsnapinprefs.serファイルの設定を参照してください。
  4. ワークステーション上でConsoleOneを起動および停止するバッチファイルを作成します。ConsoleOneのバッチファイルの作成と使用を参照してください。このバッチファイルで次の2つの処理を実行します。
    • ワークステーションでConsoleOneが起動されるたびに、ストレージサーバからワークステーションに最新のsnapinprefs.serファイルを自動的にアップロードします。

      これによって、ConsoleOneを起動したワークステーションですべてのソフトウェアパッケージを表示できます。

    • ワークステーションでConsoleOneを終了するときに、変更されたsnapinprefs.serファイルをワークステーションからストレージサーバに自動的にダウンロードします。

      これによって、ワークステーションの最新のソフトウェアパッケージの追加が記述された.serファイルの新しいマスタコピーが作成されます。

  5. ソフトウェアパッケージを管理するワークステーションからバッチファイルを実行します。ConsoleOneバッチファイルの使用を参照してください。

複数のワークステーションからのソフトウェアパッケージの管理に関する一般的な規則

snapinprefs.serファイルのマスタコピーの使用に意味があるのは、あるワークステーションでConsoleOneを終了し、別のワークステーションでConsoleOneを起動する場合だけです。この連続的な方法は、ConsoleOneの複数のインスタンスを同時に実行し、各インスタンスがローカルのsnapinprefs.serファイルを更新する場合には機能しません。最後に終了したConsoleOneのインスタンスが、そのローカルの.serファイルをマスタコピーに上書きします。

重要:  snapinprefs.serファイルにログが記録される処理は、ConsoleOneでのソフトウェアパッケージの作成、削除、またはコンパイルだけです。したがって、バッチファイルからConsoleOneを起動しなくても、ConsoleOneを使用して、プロパティの表示や編集など、ソフトウェアパッケージを管理することができます。バッチファイルを使ってConsoleOneを起動しない場合は、ConsoleOneで.spkファイルを追加、削除、またはコンパイルしないでください。

このマスタコピー/単一のサーバ/複数のワークステーションを使用する方法でソフトウェアパッケージを管理するには、以下の一般的な規則に従ってください。

  • ソフトウェアパッケージ(.spkファイル)を新規作成するか、新しいパッケージ(.cpkファイル)をコンパイルした後、常にConsoleOneを終了します。これによって、マスタsnapinprefs.serファイルに最新のソフトウェアパッケージのリンクが含まれます。
  • 複数のワークステーションでソフトウェアパッケージを同時に管理しないでください。これらのワークステーションでバッチファイルを使用してConsoleOneを起動すると、新規作成したソフトウェアパッケージへのパスが失われる場合があります。
  • ソフトウェアパッケージを管理する場合以外は、バッチファイルを使用してConsoleOneを起動しないでください。バッチファイルを使用せずに、ConsoleOneを起動してください。

    この操作が必要になるのは、バッチファイルはConsoleOneを終了するときに、常にソフトウェアパッケージストレージサーバ上のマスタコピーを上書きするからです(バッチファイルを使用してConsoleOneを起動した場合)。誤ってマスタsnapinprefs.serファイルが上書きされ、新規作成したソフトウェアパッケージへのリンクが失われる場合があります。

    たとえば、ワークステーションAでバッチファイルを使用してConsoleOneを起動し、ソフトウェアパッケージ以外の管理作業を行い、何らかの理由でワークステーションBを使ってソフトウェアパッケージを新規作成する(再度バッチファイルを使用する)ことにして、ワークステーションBでConsoleOneを終了した後、ワークステーションAでConsoleOneを終了したとします。ワークステーションBで新規作成したソフトウェアパッケージは、マスタsnapinprefs.serファイル内でのリンクが失われます。


複数のワークステーションによるソフトウェアパッケージの管理の最適なシナリオ

最適なシナリオは、1人の管理者が複数のワークステーションを使用してソフトウェアパッケージを管理できるようにすることです。複数の管理者がいる場合は、マスタsnapinprefs.serファイルでソフトウェアパッケージの追加や削除に関する最新情報を互いにを上書きしないように調整する必要があります。

詳細については、例:マスタsnapinprefs.serファイルの使用を参照してください。


例:マスタsnapinprefs.serファイルの使用

サーバ上のマスタコピーが常に正しく更新されるようにすることは、タイミングの問題です。たとえば、次のシナリオでは、まずワークステーションAで最初のsnapinprefs.serファイルが作成され、マスタsnapinprefs.serファイルとしてネットワークサーバにコピーされました。両方のワークステーションでWindows 2000を使用しています。

ConsoleOneの使用前後のイベントを制御するために、バッチファイルを使用してConsoleOneを起動しています。たとえば、次のように入力します。

  1. 管理者AがワークステーションA上でバッチファイルを使用してConsoleOneを起動します。
  2. ワークステーションAで実行されているバッチファイルが、M:ドライブとしてマッピングされているストレージサーバを識別します(またはバッチファイルがM:ドライブをそのサーバにマッピングします)。
  3. このバッチファイルは、M:ドライブにマップされているサーバからマスタsnapinprefs.serファイルを、ワークステーションA上のc:\documents and settings\user_ID\.consoleoneディレクトリにコピーします。
  4. 管理者Aがソフトウェアパッケージを新規作成し、ssp1.spkという名前を付けます。
  5. 管理者BがワークステーションB上でバッチファイルを使用してConsoleOneを起動します。
  6. ワークステーションBで実行されているバッチファイルが、M:ドライブとしてマッピングされているストレージサーバを識別します(またはバッチファイルがM:ドライブをそのサーバにマッピングします)。
  7. このバッチファイルは、M:ドライブにマップされているサーバからマスタsnapinprefs.serファイルを、ワークステーションB上のc:\documents and settings\user_ID\.consoleoneディレクトリにコピーします。

    これは、管理者AがワークステーションAにコピーしたsnapinprefs.serと同じものですが、管理者Aが追加したssp1.spkの情報は更新されていません。

  8. 管理者Bがソフトウェアパッケージを新規作成し、ssp2.spkという名前を付けます。
  9. 管理者BがConsoleOneを終了し、ワークステーションB上のsnapinprefs.serでssp2.spkのパスを更新します。
  10. ワークステーションBで実行されているバッチファイルは、ワークステーションBから更新されたsnapinprefs.serファイルを使用して、M:ドライブにマッピングされているネットワークサーバ上のマスタsnapinprefs.serファイルを更新します。

    この更新されたマスタsnapinprefs.serファイルには、ssp2.spkの場所が保存されています。

  11. 管理者AがConsoleOneを終了し、ワークステーションA上のsnapinprefs.serでssp1.spkのパスを更新します。
  12. ワークステーションAで実行されているバッチファイルは、ワークステーションAから更新されたsnapinprefs.serファイルを使用して、M:ドライブにマッピングされているネットワークサーバ上のマスタsnapinprefs.serファイルを更新します。

    この更新されたマスタsnapinprefs.serファイルには、ssp1.spkの場所が保存されています。ただし、ssp2.spkの場所は失われます。これは、ワークステーションBによって更新されたマスタsnapinprefs.serファイルが、後で行われたワークステーションAからの更新によって上書きされるからです。

このシナリオでは、マスタsnapinprefs.serファイルにssp2.spkの場所の情報が含まれていないので、管理者Bはssp2.spkにアクセスできなくなります。マスタsnapinprefs.serファイルは、ssp1.spkの場所だけが含まれている管理者Aのsnapinprefs.serファイルに置き換えられています。ただし、［Insert Software Package］オプションを使用して手動でssp2.spkをConsoleOneに挿入し、ssp1.spkファイルと共にsnapinprefs.serファイルにリストすることができます。

この複数のワークステーションによる管理が機能するには、ネットワークサーバに保存しているマスタsnapinprefs.serファイルが、.spkファイルを作成、削除、またはコンパイルするために、一度に1台のワークステーションでのみ使用されるようにする必要があります。ただし、複数のワークステーションを使用して、同時にServer Software Packageオブジェクトのプロパティを表示または編集できます。これは、表示および編集機能によってsnapinprefs.serファイルが更新されることはないからです。

警告:  snapinprefs.serファイルに影響を与えずにServer Software Packageオブジェクトのプロパティに対する編集を実行できます。ただし、Server Software PackageオブジェクトはeDirectoryTM内ではなく、ネームスペース内にのみ存在するので、サーバのオペレーティングシステムがファイルロックによる保護機能を提供していない限り、.spkファイルがファイルロックによって保護されない場合があります。したがって、複数のワークステーションを使用してソフトウェアパッケージを管理する場合は、.spkファイルの上書きを防止するための管理コントロールを考案する必要があります。


ソフトウェアパッケージのインストールの失敗

サーバがソフトウェアパッケージの要件のいずれかを満たしていない場合、ソフトウェアパッケージはインストールされません。


インストール中のエラー

ソフトウェアパッケージのインストールによるすべての変更はシステムによってトラッキングされます。ソフトウェアパッケージのインストールのロールバックで説明されている例外を除いて、サーバが要件を満たしており、インストールが開始された後、エラーによってインストールが途中で停止した場合は、インストールプログラムは、自動的に、その時点までに行った変更を元に戻し、サーバの状態をインストールが開始される前の状態に戻します。


コンポーネントのエラー

サーバがソフトウェアパッケージの要件を満たしている場合に、インストールの要件を満たしているコンポーネントと満たしていないコンポーネントがある場合、要件が満たされていないコンポーネントを除いて、インストールが終了します。この場合、パッケージは部分的にインストールされています。

このような場合に、接続されていないかまたは不完全なファイルやアプリケーションがターゲットコンピュータに残らないように、ソフトウェアパッケージとそのコンポーネントを構成する必要があります。


ソフトウェアパッケージのインストールのロールバック

ソフトウェアパッケージのロールバックはデフォルトで有効になっています。インストールを元に戻す必要がないことが明確である場合以外は、ロールバックを無効にしないでください。


ロールバックの方法

ソフトウェアパッケージのインストールをロールバックするには、2つの方法があります。

  • ロールバックするパッケージが保存されているサーバ上で、サーバのZENworks Server Managementコンソールのプロンプトでpackage rollbackと入力します。
  • Webブラウザを使用して、ZENworks Server Managementの役割にアクセスし、ロールバックオプションを選択します。詳細については、Novell iManagerを参照してください。

ソフトウェアパッケージはアンインストールされ、サーバはパッケージがインストールされていなかった状態に戻ります。ただし、インストールしたアプリケーションを使用してサーバに対して行った変更内容は除きます。

正常なパッケージのインストールの途中で、一部のコンポーネントがインストールされなかった場合でも、インストールプログラムはソフトウェアパッケージによってインストールされなかった対象をトラッキングしているので、ロールバックは機能します。


以前のインストールのロールバック

ソフトウェアパッケージのインストールをロールバックする場合、そのサーバに最後にインストールされたソフトウェアパッケージがロールバックされます。最後にインストールされたソフトウェアパッケージ以外のソフトウェアパッケージをロールバックする必要がある場合は、最新のインストールから順に、対象となるパッケージまで、各インストールをロールバックする必要があります。

たとえば、1台のサーバに3つのパッケージ(パッケージ1、パッケージ2、パッケージ3)をインストールしたとします。パッケージ1を最初にインストールし、パッケージ3を最後にインストールしました。パッケージ2をロールバックする場合、まずパッケージ3をロールバックする必要があります。そのためには、サーバのZENworks Server Managementコンソールのプロンプトで、パッケージ3についてpackage rollbackコマンドを実行した後、パッケージ2についてもう一度このコマンドを実行します。


ロールバックの例外

通常、正常にインストールされたソフトウェアパッケージを、ロールバックによって元に戻すことができます。ただし、インストールされたソフトウェアパッケージが、サーバを変更するNetBasicスクリプト、Java Class、またはNLMなどのプログラムを実行する場合、このソフトウェアパッケージを正しくロールバックできません。これは、これらのプログラムやサービスがサーバ上で変更を行う別のプログラムを起動している可能性があり、このようなプログラムをトラッキングしてロールバックすることができないからです。