Server Managementでは、Novell Application LauncherTMによって配布されたアプリケーションの地理的、負荷、および冗長の問題を解決できます。これらの問題解決には、Server Managementを使用しなければDesktop Managementでの手作業による設定に多くの時間を必要とします。Server Managementがデスクトップアプリケーションの作業の自動化にどのように役立つかについては、次の節を参照してください。
Desktop Managementでは、Novell Application Launcherを経由してユーザやワークステーションがアプリケーションを受信するために、アプリケーションオブジェクトを作成できます。アプリケーションオブジェクトにはアプリケーションに属するファイルへのポインタが含まれ、アプリケーションをどのようにインストールしてデスクトップ上に設定するかを定義する環境設定パラメータも含まれます。
Desktop Managementでは、アプリケーションに属するファイルを任意のサーバに配置でき、関連するアプリケーションオブジェクトをツリーの任意の場所に配置できます。したがって、Novell Application Launcherを経由してアプリケーションを受信するワークステーションに対して、アプリケーションのファイルがサーバからコピーされ、ワークステーションにインストールされます。
ただし、Desktop Management管理者に対しては次のような問題が発生する可能性があります。
ネットワークトラフィック: アプリケーションを入手する場合に、多くのユーザやワークステーションでネットワークトラフィックが大きくなる可能性があります(特に低速なWANリンクを経由した場合)。
Desktop Managementのみを使用している場合にネットワークトラフィックが大きくなる地理的な問題に対処するには、多くの手作業を必要とします。アプリケーションオブジェクトの再作成とカスタム設定を何度も行い、ワークステーションにサービスをローカルに提供するさまざまなサーバにファイルをコピーする必要があります。
ローカルアプリケーションアクセス: ユーザは、ネットワークに接続している場所に関係なくアプリケーションにローカルアクセスできる必要があります。
手作業でアプリケーションオブジェクトを複製し、アプリケーションオブジェクトの各コピーにサイトリストを作成する必要があります。
サイトリストの詳細については、『ZENworks 6.5 Desktop Management管理ガイド』の「サイトリストのセットアップ」を参照してください。
サーバの負荷: さまざまなアプリケーションファイルを1つのサーバにロードしていると、すべてのワークステーションにサービスを提供するには負担が大きすぎる場合があります。
Desktop Managementのみを使用している場合は、アプリケーションオブジェクトの負荷分散を設定してサーバ間で配布負荷を共有し、複数のサーバが同じサービスを実行できるようにすることでサーバの過重負荷に対処できます。ただし、この機能を使用するには多くの手作業が必要になります。
サーバの冗長性: さまざまなアプリケーションファイルをロードされたサーバが停止した場合は、ワークステーションがアプリケーションを受信できません。
Desktop Managementのみを使用している場合は、アプリケーションオブジェクトの障害対策を設定してサーバを冗長化し、アプリケーションオブジェクトにリストされているバックアップサーバを複数にすることでサーバが停止している状況に対処できます。ただし、この機能を使用するには多くの手作業が必要になります。
Server Managementには、このような地理的な問題や手作業の問題を解決するソリューションが用意されています。方法を参照するには、Server Managementの配布されたアプリケーションに進みます。
Server Managementには、ネットワークトラフィック、アプリケーションへのローカルアクセス、サーバの帯域幅、および冗長の問題を最小限にし、管理者の負担を軽減するDesktop Application Distributionが用意されています。
例:
ネットワークトラフィック: アプリケーションを含むDesktop Application Distributionを作成した後、各地域のSubscriberがアプリケーションのローカルコピーを作成します。そこでは、Novell Application Launcherがローカルアプリケーションを使用してSubscriberサーバのユーザとワークステーションにサービスを提供できます。
ローカルアプリケーションアクセス: Desktop Application Distributionを作成して送信した後、リンクアップサイトがリストされ、地理的な場所を移動したユーザが自分のアプリケーションにローカルアクセスできるようになります。
Server Managementによるサイトリストのセットアップ方法については、ステップ 13を参照してください。
サーバの負荷: 負荷分散機能を使用すると、Novell Application Launcherによって複数のサーバを利用して多くのユーザやワークステーションにサービスを提供できます。Desktop Application Distributionを受信する各サーバに、共通の作業コンテキストを使用します。これで、複数のサーバが負荷分散を使用できます。
重要: 負荷分散はSubscriberサーバ上のソースパスへのアクセスに関係し、配布されたアプリケーションオブジェクトへのアクセスには関係しません。
サーバの冗長性: 障害対策機能を使用すると、冗長化が行われ、Novell Application Launcherによって、サーバが停止したときに他のサーバがユーザとワークステーションにサービスを同じように提供できます。Desktop Application Distributionを受信する各サーバに、共通の作業コンテキストを使用します。これで、複数のサーバが障害対策を使用できます。
重要: 障害対策はSubscriberサーバ上のソースパスへのアクセスに関係し、配布されたアプリケーションオブジェクトへのアクセスには関係しません。
負荷分散や障害対策を行うには、次の作業のみを実行します。
Server Managementが各サーバの環境に基づいてアプリケーションを自動的に設定します。
これにより各サーバは次のようになります。
アプリケーションオブジェクトは、Novell Application Launcherを経由してワークステーションにアプリケーションをインストールするために使用されます。
Distributionプロセスは、複数のアプリケーションオブジェクトの作成、カスタム環境設定、およびファイルコピー作業を自動的に実行します。
これらの問題をServer Managementが解決する方法について理解を深めるには、配布されたアプリケーションの問題に進みます。
Desktop Application Distributionを送信する場合は、アプリケーションオブジェクトの内容の一部は保持され、一部は保持されず、一部は変更されます。次の節では、このことについて説明します。
Desktop Application Distributionを作成する場合は、配布するアプリケーションオブジェクトを選択します。Server Managementでは、これは「配布準備のできた」アプリケーションオブジェクトと呼ばれます。Distributionによって作成されたすべてのアプリケーションオブジェクトは、「配布された」アプリケーションオブジェクトと呼ばれます。
管理者はDistributionに対する配布準備のできたアプリケーションオブジェクトがどれであるかを知っておく必要があります。アプリケーションオブジェクト同士はConsoleOne(R)で見分けがつかないからです。
アプリケーションオブジェクトに関連したDesktop Managementの通常の作業がオブジェクトの内部リビジョン番号を変更する可能性があるため、Distributionの不必要なデルタがトリガされ、送信される場合があります。たとえば、Distributionの再構築が、Distributionに含まれるアプリケーションに関連付けられたユーザグループオブジェクトの単純な変更によってトリガされる可能性があります。この情報は配布されたアプリケーションにまったく転送されません。したがって、配布準備のできたアプリケーションをユーザやワークステーションで使用しないでください。
配布準備のできたアプリケーションオブジェクトを固有のNovell eDirectoryTMコンテキストに保持し、ユーザとワークステーションを配布されたアプリケーションオブジェクトだけに関連付けることをお勧めします。詳細については、Desktop Application Distributionの再構築を参照してください。
Distributionが再構築され、再送信された場合は、すべての配布されたアプリケーションオブジェクトが配布準備のできたアプリケーションオブジェクトと同期化されます。つまり、配布されたアプリケーションオブジェクトに重要な変更を加えたが配布準備のできたアプリケーションオブジェクトには加えなかった場合にDistributionを再構築して再送信すると、変更が失われる可能性があります。Distributionは配布準備のできたアプリケーションオブジェクトの内容だけを使用して配布されたオブジェクトを更新するからです。したがって、Distributionを再送信する場合に変更するオブジェクトは、配布準備のできたアプリケーションオブジェクトのみです。
ただし、配布されたアプリケーションオブジェクトが上書きされない場合は、再送信されるDistributionによって一般的に上書きされない属性を変更できます。これは、次の節で説明します。
配布準備のできたアプリケーションの属性の保持に進みます。0201納品ここまで
Server Managementは、配布準備のできたアプリケーションオブジェクトの属性のすべてではなく、大部分を配布します。したがって、Distributionが再構築されたときに配布されたアプリケーションオブジェクトに含まれる属性に応じて、さまざまな結果が発生する可能性があります。
次の節では、属性が配布された場合と配布されなかった場合について説明します。
属性がConsoleOneで変更できる場合は、配布準備のできたアプリケーションオブジェクトに存在する、次の3つの節でリストされないすべての属性が配布されます。これらの属性はDistribution構築時に配布準備のできたアプリケーションオブジェクトから読み取られ、Server Managementが配布されたアプリケーションオブジェクトを作成または更新するたびに送信されます。
配布準備のできたアプリケーションオブジェクトの属性は、更新されたものだけではなくすべてが、Distributionの再構築、送信、および抽出時に、配布されたアプリケーションオブジェクトで更新されます。つまり、すべての配布されたアプリケーションオブジェクトは、次の3つの節に記載されているものを除き、配布準備のできたアプリケーションと同期化されています。
eDirectory属性名ごとにリストされた次の属性は、Distribution構築プロセスで読み取られず、Server Managementによって配布されたアプリケーションオブジェクトに設定されません。
このリストには、ConsoleOneで変更できる属性のみが含まれています。
eDirectory属性名ごとにリストされた次の属性は、最初のアドレス帳を提供するために一度だけ送信されます。
| 属性名 | アプリケーションオブジェクトのプロパティ内のロケーション |
|---|---|
App:Contacts |
［Identification］タブ>［Contacts］サブタブ |
この属性は、2回目以降のDistribution更新では更新されません。このため、配布されたアプリケーションオブジェクトのこの属性の変更が、配布準備のできたアプリケーションオブジェクトのオリジナルまたは更新済みアドレス帳によって上書きされることがありません。
この属性は、ConsoleOneで変更できます。
eDirectory属性名ごとにリストされた次の属性は、Distribution構築時に配布準備のできたアプリケーションオブジェクトから読み取られ、ターゲットサーバの作業コンテキストにおける配布されたアプリケーションオブジェクト作成時にアプリケーションオブジェクトの新環境に合わせて変更されます。
| 属性名 | アプリケーションオブジェクトのプロパティ内のロケーション |
|---|---|
ACL |
［NDS Rights］タブ>［Trustees of This Object］サブタブ |
App:Alt Back Link |
［Fault Tolerance］タブ>［Remote Alternate App］サブタブ |
App:Associations |
［Associations］タブ |
App:Back Link |
［Run Options］タブ>［Application Dependencies］サブタブ>［Show Chain］ボタン |
App:Fault Tolerance |
［Fault Tolerance］タブ>［Fault Tolerance］サブタブ |
App:Load Balancing |
［Fault Tolerance］タブ>［Load Balancing］サブタブ |
App:Site List |
［Distribution］タブ>［Link Up Site List］ボタン(Server ManagementスナップインがConsoleOneにインストールされている場合のみ表示される)。このボタンの使用方法と理由については、ステップ 13を参照してください。 |
アプリケーションGUID |
［Distribution Options］タブ>［Options］サブタブ>［GUID］フィールド |
creatorsName |
［Listed on the Other］タブ(表示するには［Show Read Only］をクリック)。 |
modifiersName |
［Other］タブ(表示するには［Show Read Only］をクリック)。 |
Object Class |
［Listed on the Other］タブ。 |
Revision |
［Listed on the Other］タブ(表示するには［Show Read Only］をクリック)。 |
Used By |
［Listed on the Other］タブ(表示するには［Show Read Only］をクリック)。 |
このリストにはConsoleOneで変更できる属性のみが含まれ、属性はアプリケーションを定義する必要がある場合にのみアプリケーションオブジェクトに表示されます。
オブジェクト配布時の関連付けの保持に進みます。
Desktop Application Distributionを設定する場合は、関連付けの保持を指定できます。つまり、配布準備のできたアプリケーションオブジェクトに設定されている属性の関連付けが、Distributionによって作成される配布されたアプリケーションオブジェクトに保持されます。
Desktop Application Distributionでは、適用可能なユーザやワークステーションを配布されたアプリケーションオブジェクトに追加するなど、手作業がいくつか必要です。Desktop Application Distributionオブジェクトにはその情報がありません。これは、ユーザとワークステーションが、配布されたアプリケーションを受信するサーバによって異なる可能性があるためです。
［Maintain Associations］オプションを選択すると、属性の関連付けが次の方法で処理されます。
［Maintained］: ユーザグループ、ワークステーショングループ、組織、および部門の各オブジェクト。
これらは信頼されるグループおよびコンテナです(ソースのルートコンテナ内)。これらは次の方法で保持されます。
［Created New］: グループおよびコンテナのオブジェクトが存在しない場合、それらのオブジェクト。
配布されたアプリケーションを必要とするユーザやワークステーションにそのオブジェクトを手作業で設定する必要があります。
［Not Overwritten］: グループおよびコンテナのオブジェクトがすでに存在する場合、それらのオブジェクト。
グループオブジェクトとコンテナオブジェクトがすでに存在して配布されたアプリケーションオブジェクトに割り当てられている場合、設定が上書きされません。配布されたアプリケーションを使用する必要があるユーザやワークステーションにすでに設定されている可能性があるからです。既存のグループやコンテナに他のユーザやワークステーションを追加する場合は、手動で追加する必要があります。
［Not Created］: ユーザおよびワークステーションオブジェクト。
Distributionの抽出後に、適用可能なユーザやワークステーションを配布されたアプリケーションオブジェクトに追加できます。
チェーンアプリケーションの情報やフォルダを配布する場合は、［Maintain Associations］オプションが必要です。これはDistributionのチェーンアプリケーションに記載されています。
アプリケーションのファイル権利の保持に進みます。
配布準備のできたアプリケーションオブジェクトに設定したファイル権利は、配布されたアプリケーションオブジェクトに渡されません。ファイルの場所はサーバによって異なり、予想できないからです。
Desktop Application Distributionでは、ファイルアクセス権の追加など、いくつかの手作業が必要です。このような処理は、配布されたアプリケーションオブジェクト作成時のZENworksによる最小セット以外の作業となります。(通常のアプリケーションには最低限の権限で十分です。)
Desktop Application Distributionでのファイル権利処理方法については、次の節を参照してください。
［Rights to Files and Folders］タブを使用してアプリケーションオブジェクトに明示的に割り当てられているファイル権利は転送されませんが、ユーザが配布されたアプリケーションを使用するのに必要な最小限度(読み込み権およびファイルスキャン権)にリセットされます。配布されたアプリケーションオブジェクトが作成された後でコンテナやグループに関連付けられたときに、ファイル権利は設定されます。
アプリケーションオブジェクトの［Common］>［File Rights］タブで割り当てられたファイル権利も、配布されません。
配布されたアプリケーションオブジェクトのこれらのタブで後に追加の権利を付与でき、権利は削除も置換もされません。
ユーザやワークステーションがDesktop Application Distributionの配布グループのメンバーである場合は、ユーザやワークステーションのファイル権利を個別に設定する必要はありません。ユーザやワークステーションは、アプリケーションに対する自分の権利をグループのメンバーシップによって取得します。
チェーンアプリケーションを使用する場合は、ディレクトリに対する権利を必要とするチェーンのすべてのアプリケーションが、配布準備のできたアプリケーションのツリー構造のユーザグループ、ワークステーショングループ、またはコンテナに関連付けられている必要があります。ユーザやワークステーションのオブジェクトの権利は、配布されたアプリケーションオブジェクトに個別に保持されないからです。
チェーンアプリケーションに属するファイルへの読み取りと書き込みのアクセス権を付与するには、ユーザグループオブジェクトまたはワークステーショングループオブジェクトの［Rights to Files and Folders］タブでファイル権利を割り当てます。
Server ManagementではNetWare(R)用のファイルに権利が個別に設定されません。そのファイルを含むディレクトリにトラスティのみが設定され、権利は常に読み込み権利およびファイルスキャン権利になります。したがって、NetWareサーバ上では、アプリケーションのファイルが配布されるディレクトリにユーザの読み込み権を付与してください。たとえば、ファイルを\appsディレクトリにコピーした場合は、そこにファイルがコピーされたアプリケーションをユーザが使用するには、\appsディレクトリへの読み込み権が必要です。
Server Managementでは、Windowsでもファイル権利が設定されません。したがって、アプリケーションの配布ファイルにアクセスするユーザごとに共有を設定します。
Subscriber作業コンテキストの競合に進みます。
Subscriberのすべてが同じ作業コンテキストを使用するか固有の作業コンテキストを使用するかは、アプリケーション配布の設計ニーズによって異なります。負荷分散または障害対策を使用する場合は、Desktop Application Distributionを受信するすべてのSubscriberが同じ作業コンテキストを使用している可能性があります。詳細については、Desktop Application Distributionの目的を参照してください。
同じ作業コンテキストを使用するSubscriberが複数存在する場合は、eDirectoryが衝突する可能性があります。つまり、複数のSubscriberは同時に同じDesktop Application Distributionからツリーの同じ作業コンテキストにコピーを抽出できません。
たとえば、2つのSubscriberが同時にアプリケーションを抽出し、2つの異なるeDirectorysレプリカにアプリケーションオブジェクトを作成した場合は、eDirectoryの同期化に問題が発生します。eDirectoryは2つの異なるオブジェクトを検出しますが、2つの異なるレプリカに同じ名前と同じタイムスタンプがあるため、eDirectoryは重複したオブジェクトの名前に数字を付けてオブジェクトのうち1つの名前を変更し、これを解決します。(詳細については、技術情報10062001を参照)。
Subscriberのグループに同じ作業コンテキストを使用する場合は、各Subscriberの抽出スケジュールが異なる時間に開始されるか確認し、Subscriberが抽出を完了してから次のSubscriberが抽出を開始できるように、スケジュールの間に十分な時間をあける必要があります。
各Subscriberが固有の作業コンテキストを使用する場合は、すべてのSubscriberが同時に同じDesktop Application Distributionのコピーを抽出でき、eDirectoryの衝突は発生しません。
すぐに抽出するようにDistributionが設定されている場合、同じシナリオになります。
ソースパスの保持に進みます。
アプリケーションの多くはサポートするファイルを必要とし、ソースファイルへのパスがDesktop Managementのアプリケーションオブジェクトに設定されている必要があります。これは「ソースパス」と呼ばれます。
この節では、ソースパスを使用するアプリケーションオブジェクトを含むDesktop Application Distributionについて説明します。notepad.exeなどの実行可能ファイルのみを必要とするアプリケーションの場合は、アプリケーションオブジェクトにソースパスは必要ありません。
Desktop Application Distributionでのソースパス使用方法については、次の節を参照してください。
Desktop Application Distributionプロセス時に配布準備のできたアプリケーションオブジェクトと配布されたアプリケーションオブジェクト間の属性に起きることを示すために、次の表にConsoleOneで表示および設定できるソースパス、その目的、場所の設定方法、および配布ステータスをリストします。
1 Desktop Managementの「マクロ」は、Server Managementの「変数」と同じ機能を持っています。
SOURCE_PATHマクロは、Distributorサーバのファイルシステム上のアプリケーションオブジェクトのファイルがある場所に、アプリケーションオブジェクトのソースパスを定義します。これは、Desktop Application Distributionを構築するためにDistributorがアプリケーションファイルにアクセスする場所です。
SOURCE_PATHマクロの値は、Subscriberサーバのファイルシステムに場所を作成するために使用されます。そこには配布されたアプリケーションオブジェクト作成時にSubscriberがアプリケーションファイルを配置します。
SOURCE_PATHマクロの値に含まれる情報は、次のとおりです。
次に例を示します。
server1.novell.com\sys\apps\acrobat
server1.novell.com\n\apps\acrobat
これは次のような有効なUNCパスとして解決されます。
\\server1\sys\apps\acrobat
SOURCE_PATHマクロの値にマクロまたは変数が含まれていると、Server Managementが埋め込まれた情報を解決しません。Server ManagementはSOURCE_PATHマクロの値を有効なUNCパスとしてのみ解決します。
グローバルポリシー変数が定義されている場合、マップされたドライブ文字を使用することもできます。
Tiered Electronic Distributionでは、配布準備のできたアプリケーションオブジェクトのソースパスと一致するものを見つけるために変数が検索されます。たとえば、配布準備のできたアプリケーションオブジェクトのソースパスが\apps\acrobatである場合、次の順序で一致するものが検索されます。
n:\
N:\
n:
N:
n
N
ただし、配布準備のできたアプリケーションオブジェクトのソースパスがN:\apps\acrobatである場合、次の順序で一致するものが検索されます。
N:\
n:\
N:
n:
N
n
.mstファイルは、ファイルのフルパスを指定せずに入力できます(［MSI］>［Transforms］タブ)。Server Managementが、アプリケーションオブジェクトに定義されたソースパスを使用して、Desktop Application Distribution構築時に.mstファイルを検索するからです。ただし、このことが適用されるのは.mstファイルがMSIファイルと同じディレクトリに存在する場合のみです。
従来、マップされたドライブは、デスクトップ上のマップされたドライブからアプリケーションを起動する手段として、アプリケーションオブジェクトに埋め込まれてきました。Server Managementでは変数を使用して、ドライブマッピングに使用するアプリケーションを配布します。
DistributorおよびDistributionを受信するすべてのSubscriberのボリューム名とマップされたドライブが異なっている可能性があるため、変数を使用することでDistributorと各Subscriberによって解釈される値でこれらの場所を識別できるようになります。
変数は、次のようにグローバルおよび個別に定義できます。
SLPのプロパティパッケージのTiered Electronic Distributionポリシーによるグローバルな定義
Tiered Electronic Distributionポリシー(SLPのプロパティパッケージ)に定義された変数は、ポリシーパッケージをSubscriberオブジェクトの親コンテナに関連付けるなど、そのポリシーに関連付けられたすべてのSubscriberオブジェクトで使用できます。各Subscriberに対して有効にするポリシーについて、［Variables］のプロパティページで［Include Policy］チェックボックスが選択されていることを確認してください。
ポリシーパッケージは、Distributorオブジェクトの親コンテナにも関連付けられている必要があります。ポリシーの変数定義によって、Distributorにアプリケーションファイルを収集する場所を確実に通知できます。
DistributorとSubscriberの両方が同じ変数値を使用している場合は、Tiered Electronic Distributionポリシーが1つだけ必要で、そのSLPのプロパティパッケージをDistributorとSubscriber両方の親コンテナに関連付けることができます。
たとえば、配布準備のできたアプリケーションオブジェクトのマップされたドライブのソースパスがn:\applications\acrobatであり、Distributorサーバのsys:\publicディレクトリをn:で表すとします。変数を作成するには、Tiered Electronic Distributionポリシーで［Variables］タブを選択した後、変数のn:とその値のsys:\publicを入力します。これで、DistributorはDistributionを構築する必要がある場合に、sys:ボリュームの\applications\acrobatディレクトリを見つけることができます。
このポリシーの詳細については、Tiered Electronic Distributionを参照してください。
任意のSubscriberオブジェクトに対して変数を定義できます。この定義は、Subscriberが関連付けられているTiered Electronic Distributionポリシーに定義されている場合は、同じ変数を上書きします。
これは、Subscriberサーバのボリューム名またはマップされたドライブがDistributorサーバのものと異なる場合(同じTiered Electronic Distributionポリシーを使用できないため)、またはDistributionを受信するSubscriber同士のボリューム名やマップされたドライブが異なる場合に便利です。
Subscriberの変数定義方法については、変数の定義を参照してください。
配布準備のできたアプリケーションオブジェクトがマップされたドライブを使用する場合は、Desktop Application Distributionウィザード実行時に［Keep the Same Source Paths for the Replicated Objects］オプションを有効にします。このオプションを有効にすると、配布されるアプリケーションがマップされたドライブの指定を使用できるよう、Distributionが配布準備のできたアプリケーションのソースパスを保持するようになります。マップされたドライブの値によって、アプリケーションファイルのコピー先が決まります。
配布準備のできたアプリケーションのソースパスがドライブにマップされているが、抽出ディレクトリに基づいて配布されたアプリケーションにUNCパスを使用させる場合は、このオプションを選択する必要はありません。しかし、マップされたドライブに定義された変数を使用して、SLPのプロパティパッケージのTiered Electronic Distributionポリシーを定義する必要があります。このパッケージは、Distributionを構築するために、変数によってDistributorに関連付けられている必要があります。また、ドライブマッピングが同じ場合、Subscriberオブジェクト、またはその上位のすべてのコンテナにも関連付けられている必要があります。
このオプションについては、次の点に注意する必要があります。
依存関係と要件は、属性の配布に関して次のように設定できます。
依存関係: チェーンアプリケーションなど、アプリケーションの依存関係は、Distributionの再構築、送信、および抽出時に配布されたアプリケーションオブジェクトで更新されます。
アプリケーションの依存関係を表示するには:アプリケーションオブジェクトのプロパティで、［Run Options］>［Application Dependencies］をクリックします。
システム要件: アプリケーションを実行するオペレーティングシステムなどのシステム要件は、Distributionの再構築、送信、および抽出時に配布されたアプリケーションオブジェクトで更新されます。
システム要件を表示するには:アプリケーションオブジェクトのプロパティで、［Availability］>［Distribution Rules］をクリックします。
例外には、Distributionの再構築、送信、および抽出時に、アプリケーション要件が配布されたアプリケーションオブジェクトで更新されないことがあります。代わりにアプリケーションの依存関係を使用することをお勧めします。
複数のアプリケーションに同じチェーンアプリケーションが含まれる場合は、アプリケーションのファイルはDistributionに一度だけ含まれます。これによってDistributionのファイルサイズが小さくなります。
たとえば、複数のアイコンを配布し、それぞれがそれ自体のアプリケーションオブジェクトを持ちオフィスソフトウェアスイートを必要とする場合は、そのスイートソフトウェアはDistributionに一度だけ含まれます。
Desktop Application Distributionがチェーンアプリケーションを持つ場合は、Distribution構成時に［Maintain Associations］オプションを有効にする必要があります。
Distributionのチェーンアプリケーションは、ZENworks for Desktops 4.x以降でのみ使用できます。
チェーンアプリケーションの理解とセットアップの詳細については、『ZENworks 6.5 Desktop Management管理ガイド』の「高度な配布: アプリケーションの依存関係とチェーンの設定」を参照してください。
AOTアプリケーションオブジェクトの.filファイルへのパスに拡張文字(など)が含まれる場合、DistributorとそのSubscriberの両方に対してコードページ変数を定義する必要があります。
DistributorがDistributionを構築するときに、ファイルシステムからアプリケーションファイルを収集できるようにするために、Distributorにはコードページ変数が必要です。SubscriberがDistributionからファイルシステムにアプリケーションファイルを正常にコピーできるようにするために、Subscriberにもコードページ変数が必要です。つまり、DistributorおよびSubscriberによって使用されるコードページには、Distributionに含まれるパスで使用される拡張文字が必要です。
コードページ変数を作成するには
Distributionで使用される各国文字について、ConsoleOneで使用されるコードページを決定します。
コードページは、AOTファイルへのパスに拡張文字を含む、配布準備のできたアプリケーションオブジェクトの作成に使用されるワークステーションから受け取る必要があります。
ZENworks 6.5 Companion 2 CDの\codepageutilityディレクトリに収録されているencoding.cmdユーティリティを使用して、必要なコードページを決定できます。このユーティリティの使用方法の詳細については、\codepageutilityディレクトリに収録されているreadme.docファイルを参照してください。
ConsoleOneでSLPのプロパティパッケージを作成して、プロパティにアクセスします。
Tiered Electronic Distributionポリシーをクリックして有効にし、［Properties］をクリックします。
ポリシーに変数 CODE_PAGE を追加します。
変数の値として、目的のコードページを入力します。
たとえば、Cp1252などです。
コードページの値では、大文字と小文字が区別されます。ﾄ
［OK］をクリックしてポリシーを保存します。
ポリシーパッケージをDistributorオブジェクトのコンテナに関連付けます。
Subscriberがコードページにアクセスできるようにするには、次のいずれかの操作を行います。
Distributionがすでに作成されている場合は、再構築します。