Oracle Enterprise Manager Configuration Change Consoleクイック・スタート・ガイド 10gリリース2(10.2.0.4) B53789-01 |
|
![]() 戻る |
Configuration Change Console(CCC)は、認可済のイベントと未認可のイベントに関してアプリケーションを監査するための機能を提供します。コンプライアンス監査の主な機能として、Configuration Change Consoleでは、変更管理システムを通じて承認されたITインフラストラクチャに対する計画済の変更と、Configuration Change Consoleによって検出された実際の変更を比較します。
このガイドでは、Configuration Change Console製品のテスト環境をインストールおよび構成するための手順について説明します。このガイドは、製品の機能と特長を短時間で理解できるようにすることを意図しています。
インストールの最初の手順では、Configuration Change Consoleリポジトリ用のデータベースを作成します。新規データベースを追加してすでに存在するOracleのサポート対象のデータベース・インストール環境を使用するか、新規システムにソフトウェアをインストールできます。このガイドでは、読者がすでに自分の環境にサポート対象のOracleデータベースをインストールしていると仮定しています。
サポート対象のデータベース構成に関する特殊な問題の詳細は、Configuration Change Consoleのインストレーション・ガイドを参照してください。
Oracle Database Configuration Assistantを起動して、新規データベースを作成するオプションを選択します。このガイドで作成する新規データベース用として、次の設定を行います。
他のすべての設定にはデフォルト設定を使用できます。または、現在のサーバーで使用可能な容量に応じてメモリー使用量を設定します。
Configuration Change Consoleでは、新規データベースに3つの表領域を作成する必要があります。次に、評価用として各表領域とその推奨サイズを示します。
表1-2 表領域
表領域 | サイズ | 説明 |
---|---|---|
GATEWAY |
500MB |
構成データを格納 |
GATEWAY_LGDATA |
2000MB |
RAW収集データを格納 |
GATEWAY_INDEX |
2000MB |
データベース索引を格納 |
より小さいサイズの表領域を作成し、前述の制限値に自動サイズ変更するよう設定することも可能です。または、関連データが大量に発生すると予想される場合は、これらの表領域の最大サイズをより大きくすることもできます。
Configuration Change Consoleのメディアに付属するoracle-install.zipファイルを検索します。このファイルをoracle-installディレクトリに解凍します。コマンド・プロンプトを起動し、ディレクトリを変更して次のフォルダに移動します。
{ORACLE-INSTALL}/scripts/dbstructure
次の手順を実行してsysユーザーとしてデータベースにログインします。
Prompt> sqlplus /nolog
SQL> connect sys@gateway as sysdba
Enter password:
<DBの作成時に使用したパスワードを入力>接続したら、次のスクリプトを実行してプロンプトに従います。プロンプトごとに値を入力する必要があります([Enter]を押しても動作しません)。この手順の各プロンプトで示されるサンプル値を使用できます。
@users.sql
このスクリプトの実行中にエラーが発生しなかったことを確認してください。
ディレクトリを変更して前の手順で作成したoracle-installディレクトリに戻り、次のバッチ・ファイルを実行します。これにより、データベースのすべての表にデータが移入され、結果がout.logファイルに出力されます。
dbcreateee.bat gateway gateway gateway > out.log
バッチ・ファイルの後に続くフィールドは、ユーザー名、データベースのgatewayユーザーのパスワード、および使用するデータベースのサービス名です。
out.logファイルを調査して、エラーが1つもないことを確認してください。後で製品の評価時に機能が中断される可能性があるため、これは非常に重要な手順です。
Configuration Change Consoleのメディアに含まれているserver.exeの場所を確認します。このアイコンをダブルクリックして、サーバーのインストールを開始します。
サーバー・ソフトウェアをインストールする場所を指定します。
サーバー・タイプとしてプライマリ(クラスタ・サポートなし)を選択します。
データベースのインストール時に取得したデータベースのIP、ポートおよび資格証明を指定します。インストーラがデータベースに接続できない場合、インストールは中断します。
自分の属する組織の名前を入力します(Corporate ITなど)。
使用する2つのキーストア・キーのパスフレーズを入力します。
Oracle WebLogic管理コンソールで使用するパスワードを指定します。ユーザー名は、weblogicです。
Configuration Change Consoleのデフォルトの管理者アカウントで使用するパスワードを指定します。これは、CCC UIにログインする際に必要なパスワードです。
ブラウザベースのUIへのアクセスと、エージェントによるサーバーとの通信で使用されるポートを指定します。エージェントは、HTTPSポートのみを使用するように構成されており、ブラウザベースのUIへのアクセスには、HTTPおよびHTTPSポートを指定できます。
インストールの終了時にサーバーを起動するオプションを選択します。
メモリー使用量を設定します。OSの拡張メモリー構成は使用されません。割当て可能な最大メモリーは、約1400MBです。
インストーラの手順がすべて終了すると、サービスが自動的に起動します。または、Windowsの「サービス」ユーティリティでOracle Configuration Change Console Serverサービスを起動できます。
サービスが起動したら(マシンの負荷によっては数分かかることもあります)、次のURLを使用してCCC UIにログインします。
インストールするエージェントのインストーラの場所を確認します。Windowsの場合、エージェント・インストーラはagent-win.exeと呼ばれます。このアイコンをダブルクリックして、エージェントのインストールを開始します。
コマンドラインでインストールを行う場合、次のように入力してインストールを開始します。
Prompt> agent-win.exe -i console
その後、次の手順に従ってエージェントをインストールします。
エージェント・ソフトウェアをインストールする場所を選択します。
プライマリ・サーバーに対するホスト・サーバー接続URLを入力します。プライマリ・サーバーがHOST1というホストに存在し、HTTPSポートが443の場合、次のように入力します。
t3s://HOST1:443
エージェントとサーバー間の通信を保護するには、インストール時にサーバーの認証を受ける必要があります。これを行うには、Configuration Change Console管理者のユーザー名(administratorなど)と、対応するパスワードを入力します。
一部のプラットフォームでは、監査を有効化するかどうかを尋ねられます。インストレーション・ガイドの指定どおりに監査を有効化している場合(SolarisでのBSMの使用など)、「はい」を選択します。有効化しない場合、ファイル監視はリアルタイムで実行されませんが、スナップショット・モジュールが使用されます。
このエージェントでファイル変更のOS監査を使用しないことが確実な場合を除き、常に「はい」を選択することをお薦めします。
インストールが終了すると、エージェントは自動的に起動します。または、次のいずれかのオプションを使用して手動でエージェントを起動できます。
Windowsの場合、Oracle Configuration Change Console Agentという新規サービスがあります。
UNIXの場合、/etc/init.dの下に新規デーモンが追加されます。このデーモンを起動するには、コマンド・プロンプトで次のように入力します。
cd /etc/init.d/
./arprobe start
エージェントが起動してサーバーと正しく通信しているかどうかを検証するには、サーバーUIにログインして「管理」→「デバイス」→「デバイス」の順に移動し、エージェントがインストールされている現在のマシンに対応する登録済デバイスのリストのエントリを確認します。
この項では、Configuration Change Consoleの基本的な使用例のいくつかについて簡単に説明します。この項は、読者が独自の構成を開発する方法と、独自の環境で製品を使用する方法を習得する際に役立ちます。
Configuration Change Consoleの新規アカウントは、「ユーザーの追加または更新」ページを使用して作成できます。CCCにログインできる人物は、個人と呼ばれます。CCCにもユーザーの概念は存在しますが、CCCのユーザーは管理対象デバイスにおける実際のアカウントを指します。個人は、特定のユーザーに関連する場合としない場合があります。
「管理者」→「人」→「人」の順に移動します。
「ユーザーの追加」を選択します。
すべての必須フィールド(「ログイン名」、「名」、「姓」、「パスワード」、「パスワード(検証)」、「電子メール・アドレス」など)を入力します。
オプションで、新規アカウントのプリファレンス設定(「組織」や「製品設定」など)を構成します。
終了したら、「保存」をクリックします。
「ユーザーの追加または更新」ページで、「組織設定」の下の「チーム」セクションにあるチェック・ボックスを使用して、必ず各アカウントを既存のチームに関連付けます。
変更の監視および監査の最初の手順では、コンポーネントとアプリケーションを構成します。このガイドでは、CCCサーバー・コンポーネントを例として使用し、特定の環境における変更監視要件に一致するコンポーネントを作成します。
「ポリシー」→「操作管理」→「コンポーネント」の順に移動します。
「ビュー」フィルタから「カスタム・コンポーネント」を選択します。
「コンポーネント・タイプ」フィルタの右側にある「コンポーネント・タイプの追加」リンクをクリックします。
「コンポーネント・タイプの追加」をクリックしてCCCサーバー・コンポーネントのタイプを追加します。
コンポーネント・タイプ名としてApplication Serverと入力します。オプションで説明を入力します。
コンポーネント・タイプを保存して、「コンポーネント・タイプ」ページで「完了」をクリックします。
「コンポーネント」ページで「カスタム・コンポーネントの追加」をクリックします。
次の値を入力します。
コンポーネント・タイプ: Application Server
OS: WINNT
名前: CCC Server
バージョン: 1.0
オプションの説明を入力
保存して、コンポーネント・リストにCCC Serverが表示されていることを確認します。
CCC Serverの行で、「ルール・セット」リンク(0)をクリックします。
「実行」をクリックしてファイル・イベント・ルール・セットを追加します。
「ファイル・ルール・セット」ヘッダーの「ルールの編集」リンクをクリックします。
次の値を入力します。
ファイル: <CCC server install directory>\deploy
パターン・タイプ: write
説明: Include main CCC server directory
バージョン: 1.0
オプションの説明を入力
終了したら、「保存」をクリックします。
「インスタンスの追加」をクリックし、「除外」ラジオ・ボタンを選択します。
次の値を入力します。
ファイル: <CCC server install directory>deploy\activereasoning.ear\gateway.war\temp
説明: Exclude temp directory
「実行」をクリックしてプロセス・イベント・ルール・セットを追加します。
「プロセス・ルール・セット」ヘッダーの「ルールの編集」リンクをクリックします。
次の値を入力します。
プロセスを含める: arocc.exe
パターン・タイプ: event
説明: Include main CCC server process
終了したら、「保存」をクリックします。
特定のユーザーにより加えられたファイルおよびプロセスの変更のみを監視する場合、ユーザー・イベント・ルール・セットを追加してそれらのユーザーを含め、ファイルおよびプロセス・イベント・ルール・セットで「コンポーネントに定義されているユーザーによる変更データのフィルタリング」チェック・ボックスを選択します。
「コンポーネント・ルール・セットの追加または更新」ページに戻ったら、「完了」をクリックしてEMCCC Serverコンポーネント・ルール・セットの構成を完了します。
変更の監視および監査の最初の手順では、コンポーネントとアプリケーションを構成します。このガイドでは、CCCサーバー・コンポーネントを例として使用します。特定の環境における変更監視要件に一致するコンポーネントを作成できます。
「ポリシー」→「操作管理」→「コンポーネント」の順に移動します。
一番上の「ビュー」フィルタから「カスタム・コンポーネント」を選択します。
「コンポーネント・タイプ」フィルタの右側にある「コンポーネント・タイプの追加」リンクをクリックします。
「コンポーネント・タイプの追加」をクリックしてCCCエージェント・コンポーネントのタイプを追加します。
コンポーネント・タイプ名としてAgentと入力します。オプションで説明を入力します。
コンポーネント・タイプを保存して、「コンポーネント・タイプ」ページで「完了」をクリックします。
「コンポーネント」ページで「カスタム・コンポーネントの追加」をクリックします。
次の値を入力します。
コンポーネント・タイプ: Agent
OS: WINNT
名前: CCC Agent
バージョン: 1.0
オプションの説明を入力
保存して、コンポーネント・リストにCCC Agentが表示されていることを確認します。
CCC Agentの行で、「ルール・セット」リンク(0)をクリックします。
「実行」をクリックしてファイル・イベント・ルール・セットを追加します。
「ファイル・ルール・セット」ヘッダーの「ルールの編集」リンクをクリックします。
次の値を入力します。
ファイル: <CCC agent install directory>\bin
パターン・タイプ: write
説明: Include main CCC server directory
「含む」ラジオ・ボタンはデフォルトで選択されています。
「インスタンスの追加」をクリックします。
終了したら、「保存」をクリックします。
「実行」をクリックしてプロセス・イベント・ルール・セットを追加します。
「プロセス・ルール・セット」ヘッダーの「ルールの編集」リンクをクリックします。
次の値を入力します。
プロセスを含める:
パターン・タイプ: event
説明: Include main CCC server process
終了したら、「保存」をクリックします。
「プロセス・ルール・セット」ヘッダーの「ルールの編集」リンクをクリックします。
次の値を入力します。
プロセスを含める: arocc.exe
パターン・タイプ: event
説明: Include main CCC server process
終了したら、「保存」をクリックします。
特定のユーザーにより加えられたファイルおよびプロセスの変更のみを監視する場合、ユーザー・イベント・ルール・セットを追加してそれらのユーザーを含め、ファイルおよびプロセス・イベント・ルール・セットで「コンポーネントに定義されているユーザーによる変更データのフィルタリング」チェック・ボックスを選択します。
「コンポーネント・ルール・セットの追加または更新」ページに戻ったら、「完了」をクリックします。これにより、EMCCC Serverコンポーネント・ルール・セットの構成を完了します。
コンポーネントを作成したら、監視が必要なデバイスをコンポーネントに割り当てる必要があります。デバイスを割り当てられたコンポーネントは、コンポーネント・インスタンスと呼ばれます。
「コンポーネント」ページで、CCC Serverの行内の「インスタンス」リンクをクリックします。
「デバイスの変更」をクリックします。
「デバイス・グループ」を開き、CCCサーバーが実行されているホストを選択します。
「保存」→「完了」をクリックします。
CCCエージェントでもこれらの手順を繰り返します。
コンポーネントを作成してデバイスを割り当てたら、コンポーネント・インスタンス・デバイス上で稼働する監視エージェントにコンポーネント定義を伝播する必要があります。
「エージェント の更新」をクリックします。
コンポーネントに割り当てられたデバイスを選択します。
「選択対象の更新」または「すべて更新」のいずれかをクリックして、コンソールのすべてのエージェントを更新します。
アプリケーションが複数のコンポーネントで構成される場合、すべてのコンポーネントを含む新規アプリケーションを作成する必要があります。例として、CCC Applicationを作成します。
「ポリシー」→「操作管理」→「アプリケーション」の順に移動します。
「アプリケーションの追加」をクリックします。
アプリケーション名としてCCC Applicationと入力します。オプションで説明を入力します。
「保存」をクリックします。
CCC Applicationの行で、「コンポーネント・インスタンスの数」リンクをクリックします。
「コンポーネント・インスタンス割当ての変更」をクリックします。
チェック・ボックスを開き、「CCCサーバー 1.0 WINNT」および「CCCエージェント 1.0 WINNT」を選択します。
「保存」をクリックします。CCC Applicationの「コンポーネント・インスタンスの数」の値が2に更新されていることを確認します。
アプリケーションを作成すると、そのアプリケーション内で発生したイベントを表示できます。
「視覚化」→「イベント視覚化」→「アプリケーション・イベント」の順に移動します。
「CCCアプリケーション」チェック・ボックスを選択します。「デバイス上のCCCサーバー1.0 WINNT」および「デバイス上のCCCエージェント1.0 WINNT」というオプションも同時に選択されます。
「選択内容を表示」をクリックします。
「CCCアプリケーション」リンクをドリルダウンします。
「デバイス」リンクをクリックして、WINNT上のCCC ServerコンポーネントとWINNT上のCCC Agentコンポーネントの変更を確認します。
「ファイル」または「プロセス」リンクをドリルダウンすると、タイムスタンプ、ファイルまたはプロセスの名前、イベント(ファイルの作成、削除または変更)などのイベントの詳細を確認できます。
開始日時やスケール(月、日、時間単位)を選択することで、さらに詳細にイベント・データをフィルタできます。
特定の監視対象デバイスで発生したイベントも表示できます。
「視覚化」→「イベント視覚化」→「サーバー・イベント」の順に移動します。
すべてのデバイス・グループを開き、「CCCサーバー」および「CCCエージェント」ホスト・デバイスを選択します。
「選択内容を表示」をクリックします。
デバイス名のリンクをドリルダウンします。
「ファイル」または「プロセス」リンクをドリルダウンすると、タイムスタンプ、ファイルまたはプロセスの名前、イベント(ファイルの作成、削除または変更)などのイベントの詳細を確認できます。
開始日時やスケール(月、日、時間単位)を選択することで、さらに詳細にイベント・データをフィルタできます。
特定のユーザーにより開始されたイベントも表示できます。
「視覚化」→「イベント視覚化」→「ユーザー・イベント」の順に移動します。
「ユーザー・タイプ」ドロップダウン・リストから「オペレーティング・システム・ユーザー」を選択します。
「次で始まるユーザーを検索」フィールドに、ユーザー名を入力します(すべてのユーザーを検索する場合は、*を入力します)。
表示するユーザー・アカウントをクリックします。
ユーザー・アカウントが存在する監視対象デバイスの名前をクリックします。
各タイプのユーザー・イベントを参照できます。イベントのタイプには、「ログイン/ログアウト」、「プロセス・アクティビティ」(ユーザーにより開始されたプロセス・イベント)、「ファイル・アクティビティ」(ユーザーにより開始されたファイル・イベント)および「CPU使用率%」(ユーザー・プロセスにより使用されたCPUリソース)があります。
Configuration Change Consoleにより検出された変更イベントは、Remedyなどの変更管理システムを使用して監査できます。未認可の変更は捕捉され、監視対象環境に対して定義されたポリシーと制御に基づいてコンプライアンスが直接評価されます。
次の手順では、例としてRemedy ARS 6.3.0を使用します。
「管理」→「サーバー構成」→「変更管理サーバー」の順に移動します。
チケット管理タイプとして「ARS 6.3.0 WINNTの処置」を選択します。
チケット・サーバーが実行されているホスト(デバイス)の名前を入力します。
次の接続パラメータを入力します。
サーバーIP: チケット・サーバーが稼働する場所のIPアドレス
ユーザー名/パスワード: CMサーバーに接続するためにCCCで使用するアカウント
CTIの統合: チケットをカテゴリおよびデバイスで統合するためのCT+D
「チケット相関基準入力」のすべてのチェック・ボックスを選択します。これにより、変更イベントが、チケットの時間枠、デバイス、ユーザーおよび承認タイムアウト(緊急チケットのステータス)に確実に関連付けられます。
「アウトバウンド・チケット構成」で、「カテゴリ」、「タイプ」および「アイテム」のすべてに「不正」を選択します。
変更管理サーバーでチケットを割り当てるスーパーバイザ名とグループ名を入力します。
チケット有効期限と緊急チケットを同じように構成しますが、「アイテム」を「有効」および「緊急」に変更します。
終了したら、「保存」をクリックします。
変更管理サーバーは、インストール後に一度だけ構成します。構成をエクスポートし、それを必要に応じて別のConfiguration Change Consoleにインポートして再利用できます。
「ポリシー」→「ポリシー管理」→「監査アクション」の順に移動します。
「新規監査アクションの追加」をクリックします。
監査アクション名としてCCC Application Audit Actionと入力します。
「コンポーネント割当て」で「アプリケーション」ラジオ・ボタンを選択し、CCC Applicationを選択します。
「検出するイベント」セクションで、「ファイル」、「プロセス」、「ユーザー」および「コンポーネント内部」の各チェック・ボックスを選択します。
「アクション」セクションで、「チケットの更新」および「チケットの作成」チェック・ボックスを選択します。
終了したら、「保存」をクリックします。
この時点で、CCC Applicationは、CCC ServerおよびCCC Agentコンポーネント・インスタンス内で検出されたすべてのイベントを監査するように構成されました。これは、各イベントとRemedyのチケットを関連付けることによって行われます。CCC ServerとCCC Agentが稼働するデバイスのすべての変更イベントにより、CMサーバーに未認可のイベントが作成され、対応する管理者が割り当てられます。
Configuration Change Consoleによる変更イベントの検出後は、電子メール通知を送信することや、レポートを生成して管理者に送信することも可能です。
これを行うには、「監査アクション」構成で「電子メール管理」を使用してCCCを構成し、「監査アクション」構成ページでの設定に応じて「通知を送信してレポートを作成」および「送信」を選択します。
Configuration Change Consoleでは、フレームワーク、ポリシーおよび制御のコンテキストで構成変更を管理および監査できます。ポリシー・コンプライアンスは、発生した変更の種類と、その変更が認可済の変更かどうかを監視することで簡単に管理および制御できます。
アプリケーション・コンポーネントにマップされた特定の制御で構成されるカスタムのフレームワークおよびポリシーを作成できます。CCCでは、カスタム・ポリシー作成の開始点として使用できる事前定義済のフレームワーク、ポリシーおよび制御のセットも提供しています。
「ポリシー」→「ポリシー管理」→「フレームワーク」の順に移動します。
「カスタム・フレームワークの作成」を選択します。
フレームワーク名としてApplication Change Management FWと入力します。
「保存」をクリックします。
「ポリシー」→「ポリシー管理」→「ポリシー」の順に移動します。
「カスタム・ポリシーの作成」をクリックします。
ポリシー名としてApplication Change Managementと入力します。
フレームワークとして「Application Change Management FW」を選択します。
説明として、Critical changes to application should be monitoredと入力します。
オプションで、ポリシー・テキスト、参照URLおよび所有者の値を入力し、「保存」をクリックします。
Application Change Managementが「カスタム・ポリシー」リストにあることを確認します。
Application Change Managementの「コントロール」列の下にある0(ゼロ)をクリックし、次に「コントロール割当ての変更」をクリックします。
「アプリケーション変更」および「アプリケーションの可用性」チェック・ボックスを選択します。
終了したら、「保存」をクリックします。
ここで、ポリシー・コンプライアンスを変更イベントに関連付けることができるように、適切なポリシーにアプリケーション・コンポーネントをマップする必要があります。「ポリシー」→「操作管理」→「コンポーネント」の順に選択します。
CCC AgentおよびCCC Serverコンポーネントの行で、「コントロール」列の下の0(ゼロ)リンクをクリックします。
「フレームワーク」を開き、2つのコンポーネントに対して「アプリケーション変更管理」ポリシーを選択します。これで、2つのコンポーネントの「コントロール」の下に2と表示されます。
コンポーネントとアプリケーションを使用して環境を定義し、ポリシーと制御を作成したら、ポリシー・コンプライアンスを簡単に管理できます。
フレームワークの各ポリシーのコンプライアンス・ステータスは、ダッシュボードに表示されます。変更管理システムを使用する場合、未認可のイベントの割合がコンプライアンスの測定に使用されます。変更管理システムを使用しない場合、ベースラインからの変更イベントの偏差がコンプライアンスの測定に使用されます。
各ポリシーをドリルダウンできます。取得された変更の数と、影響を受ける制御およびアプリケーションの詳細なビューを参照できます。また、変更を加えたユーザーと、それらの変更が発生したデバイスも参照できます。
次に、高度な使用例を示します。
Configuration Change Consoleでは、特定のユーザーにより加えられた変更を監視できます。
ファイル・イベント・ルール・セットを含むコンポーネントと同じコンポーネントにユーザー・ルール・セットを追加します。
「パターン」として「X」を、「パターン・タイプ」として「ユーザー」を含めます。
「ユーザーのログイン/ログアウト・イベントの包含/除外用ではなく、他のタイプのフィルタリング用のみのユーザー。」チェック・ボックスを選択して、ユーザーによるイベント変更をフィルタします。
このオプションを選択すると、ユーザーのログインおよびログアウト・イベントは検出されません。これらのイベントを取得する場合は、このオプションを選択しないでください。
「保存」をクリックします。
「ファイル・ルール・セット」ヘッダーの「ルールの編集」をクリックします。
「コンポーネントでユーザーが定義したフィルタ変更データ」チェック・ボックスを選択します。
共有ファイル・システム環境では、ファイル・システムの共有方法に応じてファイル変更を監視できます。
別のホストからの共有のマウント
ソース・マシンにエージェントをインストールします。これにより、ソース・マシンでのファイル変更のリアルタイム監視が行われます。これは、ファイルを共有していないシステムの通常のファイル変更監視と同じです。
NFS共有、NASおよびネットワーク・ストレージのマウント
エージェントをスナップショット・エージェントに切り替え、共有がマウントされている単一のマシンを監視します。この機能は、UNIXでのみ動作します。変更を加えたユーザーなどの一部のイベント詳細は提供されません。これは、インストール後に手動で行う必要があります。
たとえば、Windows XPのフォルダX:/がLinuxのホストLで共有されているとします。X:/でのファイル変更を監視するには、次の手順を実行します。
インストレーション・ガイドの記載に従って、ホストLにLinuxエージェントをインストールします。
{agent_install_dir}\bin\filwatchのシンボリック・リンクを{agent_install_dir}\bin\filewatchaから{agent_install_dir}\bin\filewatchpに変更します。
別の方法として、filewatchの名前をfilewatch.renamedに変更してから、filewatchpの名前をfilewatchに変更することも可能です。
エージェントを再起動します。
この作業が完了したら、サーバー上のコンポーネントを前と同じ方法で構成できます。ただし、このエージェントにおけるファイル監視は、リアルタイム・メソッドではなくスナップショット・メソッドを使用して実行されます。