次の節を順に参照してください。
Policy and Distribution Servicesは、次の3つのコンポーネントで構成されています。
Tiered Electronic Distribution: ネットワーク用の配布システムです。
Server Software Packages: ソフトウェアのサーバへのインストールおよびアップグレードを自動化する機能です。
大半のポリシーおよびすべてのServer Software Packageは配布されるため、これらのコンポーネントのいずれかを使用する場合は、通常Tiered Electronic Distributionが必要になります。したがって、この章では主にTiered Electronic Distributionを理解し、設定するための情報を提供します。Policy and Distribution Servicesを構成する他の2つのコンポーネントの詳細については、次の各章を参照してください。
次の節では、Tiered Electronic Distributionを理解し、設定するうえで必要な基本的情報について説明します。
Tiered Electronic Distributionを使用して、次の種類の電子データを配布できます。
このリストから、サーバに配布できる電子データにはさまざまなタイプがあることがわかります。
Tiered Electronic Distributionでは、DistributionファイルがDistributorサーバからSubscriberサーバに送信されます。基本的な配布プロセスは次の通りです。
このプロセスから、いくつかのTiered Electronic Distributionコンポーネントを作成および設定する必要があることがわかります。詳細については、基本配布プロセスおよび配布プロセスの理解を参照してください。
これらの情報を決定するには、Distributionの選択に進みます。
この節では、各Distributionタイプの基本的な情報について説明します。
Distributionを追加してから必要なDistributorを追加することで、配布システムを徐々に構築できます。新しいDistributionを追加する場合は、いつでもこのプロセスを繰り返すことができます。
設定計画ワークシートを印刷してください。計画に関する節では、このワークシートに記入するよう求められます。
Distributionタイプに関する次の節を参照し、今回作成する種類を選択してください。計画ワークシートの項目は、各Distributionタイプに用意されています。
このDistributionタイプを使用すると、eDirectoryツリーとターゲットSubscriberサーバ上の指定の場所に、アプリケーションオブジェクトと関連ファイルを配布できます。
Desktop Managementとの統合については、Desktop Application Distributionを参照してください。
Desktop ApplicationタイプのDistributionについては、Desktop Applicationを参照してください。
Desktop Application Distributionを今回作成するかどうかを決定してください。
| 設定計画ワークシート |
|---|
Distributionでトラスティ権利を保持する場合、項目3および項目20に、Desktop ApplicationタイプのDistributionを作成するため、Desktop Application Distributionを受信する各サーバでSubscriberオブジェクトとNCPTMサーバオブジェクトを同じツリーに配置する必要があることを記入します。 項目19に、作成するDistributionの種類として「Desktop Application」と記入します。また、次の情報も指定してください。
|
このDistributionタイプでは、Distributorサーバのファイルシステムからファイルまたはディレクトリを選択し、Subscriberサーバのファイルシステム上の選択した場所に配布できます。
Distributionウィザードを使用して、FileおよびFTPタイプのDistributionの作成プロセスを自動化できます。詳細については、Distributionウィザードの使用を参照してください。
FileタイプのDistributionについては、Fileを参照してください。
File Distributionを今回作成するかどうかを決定してください。
| 設定計画ワークシート |
|---|
項目19に、作成するDistributionの種類として「File」と記入します。また、次の情報も指定してください。
|
このDistributionタイプでは、1つまたは複数のFTPソースのファイルで構成されるDistributionを作成できます。各ソースには、1つまたは複数のディレクトリやファイルを含めることができます。
Distributionウィザードを使用して、FileおよびFTPタイプのDistributionの作成プロセスを自動化できます。詳細については、Distributionウィザードの使用を参照してください。
FTPタイプのDistributionについては、FTPを参照してください。
FTP Distributionを今回作成するかどうかを決定してください。
| 設定計画ワークシート |
|---|
項目19に、作成するDistributionの種類として「FTP」と記入します。また、次の情報も指定してください。
|
このDistributionタイプでは、1つまたは複数のHTTPソースで構成されるDistributionを作成できます。各ソースには、1つまたは複数のターゲットエントリを含むことができます。
HTTPタイプのDistributionについては、HTTPを参照してください。
HTTP Distributionを今回作成するかどうかを決定してください。
| 設定計画ワークシート |
|---|
項目19に、作成するDistributionの種類として「HTTP」と記入します。また、次の情報も指定してください。
|
これはMSIエンジンによってWindows環境にインストールされるMSIパッケージのDistributionです。
MSIタイプのDistributionについては、MSIを参照してください。
MSI Distributionを今回作成するかどうかを決定してください。
| 設定計画ワークシート |
|---|
項目19に、作成するDistributionの種類として「MSI」と記入します。また、次の情報も指定してください。
|
このDistributionタイプは、Subscriberサーバに次のいずれかのポリシーを適用するメカニズムを提供します。
各ポリシーの詳細については、サーバポリシーの説明を参照してください。
ポリシーおよびポリシーパッケージについては、Server Policies (サーバポリシー)を参照してください。
Policy PackageタイプのDistributionについては、ポリシーパッケージを参照してください。
Policy Package Distributionを今回作成するかどうかを決定してください。
| 設定計画ワークシート |
|---|
項目19に、作成するDistributionの種類として「Policy Package」と記入します。また、次の情報も指定してください。
|
これは、LinuxまたはSolarisプラットフォームのDistributionです。RPM Distributionを使用して、RPM (Red Hat* Package Manager)パッケージを配布できます。
RPMタイプのDistributionについては、RPMを参照してください。
RPM Distributionを今回作成するかどうかを決定してください。
| 設定計画ワークシート |
|---|
項目19に、作成するDistributionの種類として「RPM」と記入します。また、次の情報も指定してください。
|
このDistributionタイプを使用すると、ConsoleOneのServer Software Packageネームスペースで作成したServer Software Packageを配布できます。まず.spkファイルを作成し、その後に.cpkファイルにコンパイルして配布します。
Server Software Packagesの詳細については、Server Software Packageに関する問題を参照してください。
Software Package Distributionタイプについては、Software Packageを参照してください。
今回作成するソフトウェアパッケージを決定してください。
| 設定計画ワークシート |
|---|
項目19に、作成するDistributionの種類として「Software Package」と記入します。また、次の情報も指定してください。
|
配布システムを効率的に管理するには、ネットワークトポロジについて理解する必要があります。たとえば、次のように入力します。
この種の情報は、ネットワークに最良の配布管理ソリューションを設定するために役立ちます。
ネットワークに関する情報を取得するには
Server Managementのスキーマを拡張したツリーをメモします。
| 設定計画ワークシート |
|---|
項目1で、Server Managementのスキーマを拡張したネットワーク内のツリー名を指定します。 |
ネットワーク構造の図を作成します。
この図は、後で配布ルートを決定するときに使用します。
図には次の情報を示します。
現在のツリー構成を示す図を作成します。次のような主なコンテナを示します。
次の情報をツリー図に示します。
これはネットワーク図で示した低速接続の場所と一致している必要があります。
次の情報をネットワーク図に示します。
Policy and Distribution Servicesをはじめてインストールした場合、Distributorとデータベースファイルは1つずつインストールされます。通常、追加のDistributorは企業構造や地理的な場所に応じて必要になります。
Distributorの必要数は、Distributorサーバの負荷(Distributionの構築作業を完了できるかどうかなど)によって決まります。たとえば、オフピーク時に構築する大規模なDistributionと、ウィルスパターンのDistributionがあり、いずれもただちに送信する必要がない場合は、これらのDistributionが予定どおりに構築、送信されるように、日ごとの更新スケジュールが設定されたDistributor(Distributionを1日に1度作成するため)と、新しいウィルスパターンの発見用に頻繁な更新スケジュールが設定されたDistributorの、2種類のDistributorが必要になります。
作成した図を使用して、追加のDistributorをインストールする必要があるかどうかを決定してください。
| 設定計画ワークシート |
|---|
項目2で、Distributorソフトウェアをインストールするサーバ名を指定します。 |
DistributorサーバでDistributionの構築と送信の負荷がどのように処理されるかを確認してから、Distributorを追加して負荷を分散するかどうかを決定できます。
Distributorごとに、次の情報も決定する必要があります。
インストール時に、Distributorプロパティをデフォルトから次のように変更できます。
［Object Name］: Distributorオブジェクトの名前を変更する場合は、そのサーバがDistributorであることなど、サーバの識別情報を名前に保持することをお勧めします。
［Container］: Distributorオブジェクトがインストールされているコンテナの使用について計画します。
Distributorとして使用するWindows 2000/2003サーバにeDirectoryがインストールされていない場合、そのサーバのデフォルトのコンテナオブジェクトはインストール中に表示されません。したがって、そのDistributorオブジェクトのコンテナを決定します。
［Working Directory］: Distributorの作業ファイルには、デフォルトのパス以外のボリューム、ドライブ、またはディレクトリパスを使用できます。
作業ディレクトリは、Distributionのサイズに応じてかなり大きくなる可能性があるため、十分なディスク容量を確保しておく必要があります。
NetWareサーバのデフォルトのボリュームはsys:です。NetWareサーバでは、別のボリュームを指定することを強くお勧めします。
NetWareおよびWindowsサーバのデフォルトの作業ディレクトリパスは、次のとおりです。
\zenworks\pds\ted\dist
LinuxまたはSolarisサーバのパスを次に示します。
/var/opt/novell/zenworks/zfs/pds/ted/dist
Distributorの作業ディレクトリは、Distributionの作成時にも使用されます。DistributionオブジェクトのDNを使用して、作業ディレクトリの下位にサブディレクトリが作成されます。
作業ディレクトリの詳細については、作業ディレクトリを参照してください。
| 設定計画ワークシート |
|---|
項目7で、デフォルトから変更するDistributorのプロパティ情報を指定します。これには、オブジェクト名、オブジェクトのコンテナ、および作業ディレクトリが含まれます。 |
Server Managementでは、次のデフォルトのインストールパスが使用されます。
LinuxまたはSolarisのパスは変更できません。
| 設定計画ワークシート |
|---|
Distributorのインストールパスをデフォルトから変更する場合は、項目5でパスを指定します。パス情報には、インストールパスを変更するDistributorの識別情報を含めます。 Subscriberのインストールパスをデフォルトから変更する場合は、項目6でパスを指定します。パス情報には、インストールパスを変更するSubscriberの識別情報を含めます。 |
Server Managementデータベースは、ツリー内に複数保持することができ、NetWareおよびWindowsサーバの両方にインストールできます。
データベースは、Server PoliciesまたはTiered Electronic Distributionコンポーネントの成功と失敗をログに記録するために、Policy and Distribution Servicesによって使用されます。Policy and Distribution Servicesは、データベースを使用しなくても正常に機能します。これは、レポート用の情報を記録するためにのみzfslog.dbファイルを使用するからです。Policy and Distribution Servicesのzfslog.dbには、環境設定情報は含まれていません。
各Distributorで専用のデータベースを使用するか、またはすべてのDistributorで同じデータベースを共有するかどうかを決定するには、情報のレポート方法を決定する必要があります。ツリー内にいくつのデータベースが必要であるかを判断するには、次の点を検討します。
WANトラフィック: Tiered Electronic Distributionは大量のデータベースの更新を実行しないので、システムリソースに対する実際の影響は最小限です。最も大きな影響は、トランザクションの実行にかかる時間です。ただし、WAN接続が低速である場合、WANを介してデータベースのログの記録を実行しないことも可能です。
複数のDistributor: ツリー内に複数のDistributorがある場合、それぞれに1つのデータベースを使用することも、1つ以上のデータベースを共有させることもできます。必要なDistributorのレポーティングのタイプによって、それぞれに個別のデータベースを使用するかどうかが決まります。たとえば、Distributorが、送信するDistributionのタイプ専用であるかどうかなどです。
統合されたレポーティング: すべてのTiered Electronic Distribution情報についてレポートを1つだけ生成する場合は、WANトラフィックの注意事項に関係なく、データベースオブジェクトとファイルを1つだけインストールし、すべてのTiered Electronic DistributionのDistributorログをそのファイルに記録します。ZENworksデータベースポリシー(Service Location Package)を使用して、すべてのDistributorがそのデータベースファイルを使用するように指定します。
特殊なレポーティング: サーバの特定の領域やグループに固有のレポートが必要になる場合があります。データベースオブジェクトとファイルを各領域にインストールし、Distributorでその領域またはサーバグループのログをそのデータベースに記録することができます。個別のZENworksデータベースポリシー(Service Location Package)を使用して、各Distributorが適切なデータベースファイルを使用するように指定します。
詳細については、ZENworks Databaseを参照してください。
重要: ［Subscriber/Policies］オプションをインストールしているデータベースのサーバを選択していることを確認します。ZENworks Server Managementポリシー(Distributed Server Package)の［Purge Database］オプションが機能するのは、Policy/Package Agentソフトウェアとzfslog.dbファイルが同じサーバ上にある場合だけです。
| 設定計画ワークシート |
|---|
作成する各データベースオブジェクトについて、次の情報を指定してください。 |
Server Managementは、混在eDirectory環境で実行できます。たとえば、ネットワークにeDirectory 8.xとNDS(R) 6.xまたは7.xの両方がインストールされている場合があります。
ただし、Server Managementでは、製品のインストール時にツリーにオブジェクトを配置できるように、eDirectory 8.x (8.6.2、8.7.1、または8.7.3以降のみ)が必要です。eDirectoryはマスタレプリカと共にネットワーク内の任意の場所にインストールされている必要がありますが、Server Managementソフトウェアをインストールするサーバにインストールする必要はありません。
また、ZENworks 6.5 DistributorサーバでeDirectory 8.xが実行されている必要があります。
Server Managementサーバの要件は、(NCPサーバオブジェクトが存在するパーティションの)eDirectoryマスタレプリカがインストールされているサーバと通信できることだけです。したがって、Server Managementをインストールする各サーバにeDirectoryをインストールする必要はありません。
eDirectory 8.xを使用しているツリー内のサーバのIPアドレスを選択してください。サーバでeDirectory 8.xが実行されている場合は、Distributorサーバ自体のIPアドレスになる可能性があります。
| 設定計画ワークシート |
|---|
項目12で、eDirectory 8.xを使用しているサーバのIPアドレスを指定します。 |
Policy and Distribution Servicesをはじめてインストールした場合、このソフトウェアはすべてのサーバにはインストールされていません。Subscriberソフトウェアをサーバに徐々に追加してインストールする場合は、この時点で次の段階を完了できます。
インストール時に、Subscriberプロパティをデフォルトから次のように変更できます。
［Object Name］: Subscriberオブジェクトの名前を変更する場合は、そのサーバがSubscriberであることなど、サーバの識別情報を名前に保持することをお勧めします。
［Container］: Subscriberオブジェクトがインストールされているコンテナの使用について計画します。
Subscriberサーバオブジェクトは、オペレーティングシステムと一致するコンテナに配置する必要があります。たとえば、NetWareサーバの場合はNetWareコンテナに、Windowsサーバの場合はWindowsコンテナに配置します。
Subscriberとして使用するWindows 2000/2003サーバにeDirectoryがインストールされていない場合、そのサーバのデフォルトのコンテナオブジェクトはインストール中に表示されません。したがって、そのSubscriberオブジェクトのコンテナを決定します。
［Working Directory］: Subscriberの作業ファイルには、デフォルトのパス以外のボリューム、ドライブ、またはディレクトリパスを使用できます。
作業ディレクトリは、Distributionのサイズに応じてかなり大きくなる可能性があるため、十分なディスク容量を確保しておく必要があります。NetWareサーバのデフォルトのボリュームはsys:です。NetWareサーバでは、別のボリュームを指定することを強くお勧めします。
Subscriberサーバで別のパスを指定する必要がある場合があります。たとえば、NetWareサーバではsys:を、WindowsサーバではD:を指定します。パスデータには、ボリューム/ドライブ指定などの変数を使用できます。詳細については、変数を参照してください。
NetWareおよびWindowsサーバのデフォルトの作業ディレクトリパスは、次のとおりです。
\zenworks\pds\ted\sub
LinuxおよびSolarisサーバのパスは、次のとおりです。
/var/opt/novell/zenworks/zfs/pds/ted/sub
作業ディレクトリの詳細については、作業ディレクトリを参照してください。
| 設定計画ワークシート |
|---|
項目3で、今回Subscriberソフトウェアをインストールするサーバ名を指定します。 項目8で、デフォルトから変更するプロパティ情報を、インストールするSubscriberごとに指定します。これには、オブジェクト名、オブジェクトのコンテナ、および作業ディレクトリが含まれます。 |
次の節では、配布ルートの決定に関する情報について説明します。
詳細については、配布ルーティングの理解を参照してください。
各Distributorには、Distributionを送信するための階層型のパスを提供するルーティング階層があります。ルーティング階層は、Subscriberのリストで構成されます。Subscriberの階層は、多レベルの深い階層にすることができます。
また、Distributorのルーティング階層内のSubscriberを、そのDistributorからのDistributionの受信先にする必要はありません。Subscriberは、DistributorがDistributionを他のSubscriberに渡すためのプロキシの役割を果たすに過ぎません。
必ずしもすべてのSubscriberがルーティング階層内に存在する必要はありません。ルーティング階層内に存在する必要があるのは、Distributionを他のSubscriberサーバに渡すために使用されるSubscriberのみです。ネットワークのSubscriberサーバのほとんどは、Distributionを受信して抽出するだけのエンドノードSubscriberです。
Distributorは、特定のSubscriberへの最も効率的なルートを次のように判断します。
言い換えると、Distributorがルーティング階層を使用したDistributionの送信ルートを検出した場合は、その階層内のパスを使用してDistributionをSubscriberに送信し、それ以外の場合は、Subscriber(またはその親Subscriber)に直接Distributionを送信します。
このため、Distributorから定期的にDistributionを受信するSubscriberはすべて、Distributorのルーティング階層と何らかの形で接続している必要があります。この接続は、Subscriberを階層のリストに加えたり、階層内のSubscriberの1つを親Subscriberにすることで確立できます。
ルーティング階層の第1層にあるSubscriberに対してDistributionを送信するとき以外、Distributorは通常、WANリンクを介してDistributionを送信することはできません。
Distributorのルーティング階層を設計する場合は、次の点を考慮してください。
エンドノードSubscriber: ルーティング階層に追加する必要があるSubscriberは、Distributionを渡す際に使用するSubscriberのみです。Distributionを受信するだけで渡すことがないエンドノードSubscriberは、ルーティング階層に追加する必要はありません。
配布ルートの設定: 配布ルートを作成するには、ネットワークの設計と各LAN上のSubscriber数を考慮してください。その後、ネットワークトポロジに似たルーティング階層を設計します。
複数のSubscriberの選択: 階層の作成時に、1つのDistributorまたはSubscriberの下の同じ層に、複数のSubscriberを配置できます。
重要: 各層に多数のSubscriberを配置して層数を少なく抑えるよりも、Subscriberが少ない層を多数作成した方がルーティング階層としては効率的です。したがって、各層で多数のSubscriberを選択しないようにしてください。これにより、Distributionを他のSubscriberサーバに送信するDistributorまたはSubscriberサーバの負荷が最小限に抑えられます。階層を作成すると、ネットワーク内でのDistributionの送信によって生じる負荷が共有されます。
複数のDistributorの使用: 複数のDistributorで同じSubscriberのルーティング階層を使用すれば、各Distributorで同じ配布ルートを使用できます。
Subscriberの再利用: ルーティング階層内の1つの親Subscriberサーバで複数のDistributorを処理する場合、Subscriberサーバに過重負荷が生じないかどうかを考慮してください。
Distributorのルーティング階層の目的は、Subscriberへの最も効率的な配布方法を作成することです。ルーティング階層内のSubscriberに最も適したサーバと、その階層内に含むサーバ数を決定する必要があります。
物理的設定において堅牢なサーバを選択してください。たとえば、高速なCPU、十分なRAM、十分なハードディスクの空き容量(特にNetWareサーバのsys:以外のボリューム)を持つサーバです。
次の条件を使用して、Distributorのルーティング階層に含めるSubscriberを決定してください。
Distributorのルーティング階層で使用するSubscriberサーバを識別するには、Distributorのルーティング階層内で親Subscriberとして使用するサーバのリストを作成します。
ネットワークトラフィックを最小限にするには、各LANで最低1つのサーバを選択してください。
Distributorのルーティング階層内で親Subscriberとして使用するサーバオブジェクトを識別してください。
| 設定計画ワークシート |
|---|
項目16で、親Subscriberサーバの名前(完全なコンテキスト)を指定します。 |
ネットワーク図に次の情報を指定してください。
ネットワーク図の情報を使用して、選択したSubscriberを使ったDistributorのルーティング階層を設計してください。
| 設定計画ワークシート |
|---|
項目15で、Distributorの各ルーティング階層の階層を作成します。異なるDistributorの階層のSubscriberサーバを再利用できます。 |
Server Managementでは、セキュリティで保護されているネットワーク内で送信されるDistributionに対して、証明書を使用して適切なセキュリティ機能を提供します。ただし、Server Managementで利用可能な追加のセキュリティ処理が必要になる場合があります。
セキュリティの詳細については、Policy and Distribution Servicesのセキュリティを参照してください。
次の説を参照して、Distributionに追加のセキュリティが必要かどうか判断してください。
Policy and Distribution Servicesでは、通常のサーバ間通信にXMLRPC (Extensible Markup Language Remote Procedure Call)を使用します。XMLRPCは、オプションで、セキュリティ保護されていない接続での通信に対してセキュリティを提供します。
Policy and Distribution Servicesでは、セキュリティ保護されていない接続でのサーバ間の通信や、セキュリティ保護されていない接続での管理ワークステーションとサーバの間の通信に、このセキュリティを使用します。たとえば、ファイアウォール、イントラネット、NAT設定などです。
このサーバ間通信のセキュリティによって、セキュリティで保護されていない接続を介して受信したデータが信頼されるソースから送信されたものであり、途中で改ざんされておらず、受信したデータは他のコンピュータでも信頼できることが保証されます。これは、署名付きのセキュリティ証明書とデジタル署名を使用することによって実現されます。
このセキュリティでは特定のテキストファイルを編集する必要があり、Server Managementウィザードを使用してインストールされます。
サーバ間通信のセキュリティが必要になるのは、次のような場合です。
ConsoleOneの管理: ワークステーションを使用して、セキュリティで保護されていない接続を介してDistributorサーバを管理する場合。
パラメータ: SET ParameterポリシーやSETパラメータのソフトウェアパッケージを作成する場合、ターゲットサーバのSETパラメータ情報を提供するためにサーバ間通信が行われます。この通信は、セキュリティで保護されていない接続を介する場合があります。
Server Down Policy: このポリシーを使用してサーバを停止する場合、停止するサーバとそのサーバが再び稼動するのを監視する別のサーバとの間の通信がセキュリティで保護されていない接続を介することがあります。
詳細については、セキュリティ保護されていない接続でのサーバ間通信のセキュリティを参照してください。
| 設定計画ワークシート |
|---|
項目13で、サーバ間通信セキュリティソフトウェアをインストールするNetWareおよびWindowsサーバ名を指定します。 |
通常、セキュリティで保護されているネットワーク内で送信されるDistributionを暗号化する必要はありません。ただし、ネットワーク外にDistributionを送信する場合は、暗号化を使用してセキュリティを強化することができます。Distributionの暗号化には、NICIソフトウェアが使用されます。
NetWareサーバによっては、オペレーティングシステムと共にNICI 2.6が自動的にインストールされます。ただし、ZENworks 6.5 Server Managementでサポートされているのはバージョン2.6.4です。NetWareバージョンのNICIは、アップグレードする必要があります。バージョン2.6.4は、ZENworks 6.5に同梱されており、ZENworks for Servers 3.0.2(バージョン3 SP2を含む)にも同梱されています。
Windows、Linux、およびSolarisサーバでは、暗号化されたDistributionを構築するDistributorおよび抽出するSubscriberサーバに、NICI 2.6.4をインストールする必要があります。
重要: ネットワークでNICI 2.4.6を実行している場合は、NICI 2.6.4へのアップグレードは省略可能です。両バージョン間には互換性があります。
Windows、Linux、およびSolarisサーバにNICIソフトウェアをインストールする場合は、ネットワーク内のすべてのDistributorおよびSubscriberサーバにも同じバージョンをインストールする必要があります。ネットワーク内に異なるバージョンのNICIがインストールされていると、暗号化が正常に機能しません。
Distributionの暗号化については、暗号化を使用したDistributionのセキュリティを参照してください。
| 設定計画ワークシート |
|---|
項目14で、NICIソフトウェアをインストールする必要があるWindows、Linux、およびSolarisサーバ名を指定します。 |
Channelは、Distributionをグループ化する場合、DistributorのDistributionをSubscriberへ渡すスケジュールを確立する場合、およびDistributorがDistributionファイルの物理的な送信先を判断できるように、Channelに登録するSubscriberのリストを作成する場合に使用されます。
特定のDistributionの使用目的(ウィルスパターンファイル、オペレーティングシステムのサポートパック、またはポリシーパッケージなど)用、または特定のDistribution時間(オフピーク時のDistribution)用のChannelを作成することができます。
複数のDistributorのDistributionを1つのChannelに関連付けることができます。1つのChannelに複数のSubscriberを登録できます。
特定のDistributionを受信するようSubscriberをChannelに登録します。DistributorのDistributionをChannelに関連付けて、登録されたSubscriberがそのDistributionを受信できるようにします。
複数のDistributorをインストールしている場合は、それらのDistributorでDistributionのChannelを共有できます。たとえば、Distributor AとDistributor Bから同じSubscriberのセットにDistributionを送信する場合、両方のDistributorで同じChannelを共有できます。
Channelは、SubscriberにDistributionを送信するときに使用されます。次の点を考慮してください。
Channelに名前を付けるときは、わかりやすい名前を使用してください。たとえば、次のように入力します。
VirusProtect
VProtectPatterns
VirusProtection
NW51patch4
NW6patch1
AUTOEXECNCF000326
次のように名前を決めると、Channelをより簡単に管理できます。
| 設定計画ワークシート |
|---|
項目21で、Channel名を指定します。関連付けられているDistributionが識別しやすいように、一意の名前を付けてください。 |
通常、作成したChannelには1つ以上のDistributionが関連付けられます。ただし、配布を柔軟に行うために、配布するアプリケーションごとにChannelを1つ作成することもできます。
| 設定計画ワークシート |
|---|
項目22で、各Channelが所有するDistributionを指定します。 |
管理を容易にするために、他のTiered Electronic Distributionオブジェクト(特にDistributionオブジェクト)と同じコンテキストにChannelオブジェクトを作成することを計画してください。
| 設定計画ワークシート |
|---|
項目20で、Channelオブジェクトを作成するeDirectoryコンテキストを指定します。 |
SubscriberでDistributionを受信する前に、SubscriberをChannelに登録する必要があります。これは、SubscriberまたはSubscriber Groupを、必要なDistributionが関連付けられたChannelに登録することによって行います。
SubscriberはeDirectoryにアクセスしないため、Subscriberオブジェクトのプロパティ内の設定情報はすべて、設定元のDistributorから必要に応じて転送されます。これには、作業ディレクトリ、ログファイルのレベルと場所、コンソールのメッセージレベル、変数などの情報が含まれます。
Subscriberオブジェクトのプロパティに加えられた変更は、Distributorが再度eDirectoryを読み込み、新しいDistributionと設定情報をSubscriberに転送するまで有効になりません。
Channelごとに、特定のDistributionを必要とするSubscriberを決定してください。
| 設定計画ワークシート |
|---|
Under 項目24で、DistributionのChannel名(項目22)を指定し、そのDistributionを必要とするSubscriberのリストを作成します。項目21で指定したChannelごとにこれを繰り返します。 |
Subscriber Groupは、同じDistributionを必要とするSubscriberのグループ化に使用されます。
Subscriber Groupは、異なる複数のDistributionを同じSubscriberのグループに送信する場合に役立ちます。Subscriberが1つのChannelにだけ関連付けられている場合は、Subscriber Groupを作成する必要はありません。
たとえば、Channel AはDistribution Aを含み、Channel BはDistribution Bを含むという構成の複数のChannelがあるとします。この場合、Subscriber Groupを使用しないと、各SubscriberをChannel Aに登録し、さらにChannel Bにも登録するというように、長いプロセスが必要になります。Subscriber Groupを使用すると、グループを作成して複数のSubscriberを追加し、そのグループを各Channelに登録するだけで済みます。
Subscriber Groupの別の使用法として、グループが複数のChannelに関連付けられている場合は、グループのメンバーシップを編集すると、より簡単に複数のChannelに同じ変更を加えることができます。たとえば、Subscriber GroupからSubscriberを削除するには、グループのプロパティを編集するだけです。複数のChannelから同じSubscriberを削除するには、各Channelのプロパティを編集する必要があります。
| 設定計画ワークシート |
|---|
項目17で、Subscriber Groupの一意の名前を指定します。 項目18で、そのグループが登録されるChannelのDistribution (項目21および項目22)を必要とするSubscriberの一覧を指定します。 項目24で、グループ内のすべてのSubscriberが受信するDistributionのChannel名を指定します。 |
多様な配布プロセスに対応できるように、Tiered Electronic Distributionには複数のスケジュールが用意されています。詳細については、スケジュール設定を参照してください。
Tiered Electronic Distributionのスケジュールを計画するには、次の節を参照してください。
Tiered Electronic Distributionオブジェクトと個別のServer Policiesの両方のスケジュールを作成できます。
Tiered Electronic Distributionでは、Distributorを更新、およびDistributionを構築、送信、抽出するタイミングを制御するスケジュールを使用します。スケジュールはDistributionで使用されるリソース全体には影響しませんが、リソースがいつ使用されるかに影響します。
一部のポリシーでは、ポリシーが有効になる前にスケジュールを作成する必要があります。有効にしたポリシーに対してまだスケジュールを設定していない場合は、デフォルトのスケジュールを提供するDefault Package Scheduleで指定されているスケジュールに応じて、ポリシーが実行されます。デフォルトのスケジュールは、［Run At System Startup］です。
複数のポリシーに同じスケジュールを設定した場合、実行される順序はポリシーを作成した時点のタイムスタンプによって決まります。したがって、ポリシーのリストを表示したときの順序が実行される順序になります。
特定のポリシーを実行する順序を制御する場合は、実行のタイミングを決めるタイムスタンプに頼るのではなく、そのスケジュールを変更します。したがって、ポリシーのスケジュールを設定する場合は、選択するTiered Electronic Distributionスケジュールを十分に考慮し、不要な重複や、スケジュール設定した項目で失敗を引き起こす可能性のある順序外のイベントなどがないように注意します。
次の問題について理解しておく必要があります。
更新スケジュールによって、DistributorがeDirectoryから設定の変更を読み込むタイミングが決定します。
これにより、Distributionの構築要求に対するDistributorの応答が可能になります。Distributorは、eDirectory内の設定の変更を検出するとDistributionを再構築します。
また、このスケジュールはデフォルトでは［Never］に設定されているため、Distributorを手動で更新して配布プロセスを開始するよう要求されます。このスケジュールは、必要に応じて、後で変更できます。
構築スケジュールによって、Distributionの各構成要素の構築をDistributorに対して要求するタイミングが決定します。
Distributionが構築後直ちに送信されるよう、設定時に各Distributionの構築スケジュールを設定するよう要求されます。
送信スケジュールによって、DistributorがDistributionをSubscriberに送信する時間帯が決定します。
設定時に、各Channelの送信スケジュールを5分間隔に設定すると、スケジュール開始後、DistributionはDistributorから5分間隔で送信されます。
抽出スケジュールによって、Subscriberが受信したDistributionを抽出するタイミングが決定します。
Subscriberでは、受信したDistributionを使用する前に抽出する必要があります。したがって、Distributionを送信する前に、Subscriberの抽出スケジュールを設定する必要があります。
各SubscriberサーバについてDistributionを抽出するスケジュールを決定してください。Distributionのサイズによっては、オフピーク時の抽出が最適な場合があります。スケジュール設定に関するタイムゾーンの問題については、スケジュール設定に関する問題、および時差の計算を参照してください。
| 設定計画ワークシート |
|---|
項目23で、Subscriberの抽出スケジュールを指定します。 |