Cisco Unified Operations Manager ユーザ ガイド
Operations Manager の管理
Operations Manager の管理
発行日;2012/02/01 | 英語版ドキュメント(2010/01/22 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 13MB) | フィードバック

目次

Operations Manager の管理

の管理タスクの実行

のタスクのスケジュール

SNMP トラップの受信とフォワーディングの設定

にトラップを送信できるようにするためのデバイスの設定

SNMP トラップの受信と他のトラップ デーモンまたは NMS との統合

が使用するポートとプロトコル

Service Quality Event Settings の設定

System Status Report の生成と説明

[System Preferences] を使用したシステム全体のパラメータの設定

電子メール通知がブロックされていないことの確認

パージング スケジューラのステータスの表示

ロギングを使用したデバッグのイネーブル化およびディセーブル化

ログ ファイルへのアクセスと削除

セキュリティ上の考慮事項

ファイルの所有権と保護

SSL

ブラウザとサーバ間の SSL のイネーブル化

SNMPv3

データベースのパスワードの変更

デバイス サポート

システム管理タスクの実行

CiscoWorks ホームページの起動

ユーザの設定(ACS および非 ACS)

CiscoWorks ローカル モードを使用したユーザの設定

ACS モードを使用したユーザの設定

自己署名セキュリティ証明書の年次作成

データのバックアップと復元

ユーティリティを使用した Detailed Device View 設定のバックアップと復元

CiscoWorks を使用したバックアップと復元

2.0.2 のインストール前の Sybase データベースの問題への対応

プロセスの起動と停止

ログ ファイルの保持

DFM ログ ファイルの保持

CSCOPX\\log のログ ファイルの保持

ソフトウェア バージョンまたはライセンス情報の表示

インストールされている Operations Manager(または Service Monitor)のビルド ID の検出

を監視するための SNMP の使用

SNMP 照会用のシステムの設定

Windows SNMP サービスのステータスの確認

Windows SNMP サービスのインストールとアンインストール

Windows SNMP サービスのイネーブル化とディセーブル化

SNMP 照会用のセキュリティの設定

システム アプリケーション MIB のログ ファイルの表示

サーバのホスト名の変更

サーバの IP アドレスの変更

プロセス状態の監視

Health Monitor コンフィギュレーション ファイルの編集

バックアップされたプロセス ログの表示

再起動後に起こること

Operations Manager の管理タスクの実行

Cisco Unified Operations Manager(Operations Manager)の [Administration] タブから、 表 20-1 に示しているタスクを実行できます。

 

表 20-1 Operations Manager の管理タスク

タスク
説明

Polling and Thresholds

「ポーリングとしきい値の設定」 を参照してください。

Polling and Thresholds から、次のタスクを実行できます。

デバイス グループ別にポーリング間隔、タイムアウト、およびリトライを変更する。

ポーリング設定をイネーブルおよびディセーブルにする。

しきい値を変更して、ポーリングされたデータの比較対象となる制限を再設定する。

しきい値設定をカスタマイズする。

ポーリングとしきい値に関するグループのプライオリティを再設定する。

ポーリングとしきい値の変更をシステムに適用する。変更を適用すると、Operations Manager によって、データ コレクタが次のように設定されます。

アップデートされたポーリング パラメータとしきい値の使用を開始する。

以前に一時停止されていたデバイスまたはデバイス要素のポーリングを再開する。

Cisco Unified Communications Manager クラスタのしきい値を同期および表示する。

SRST Poll Settings

「SRST ポール設定の保守」 を参照してください。

SRST Poll Settings ページから、SRST モニタリングを設定できます。

Service Quality Settings

「Service Quality Event Settings の設定」 を参照してください。

Service Quality Settings ページから、MOS しきい値を設定できます。

にするとともに、Service Monitor を使用して Operations Manager をトラップ レシーバとして設定する必要があります。

Operations Manager に Service Monitor を追加するには、「Operations Manager から Service Monitor へのリンクの追加」 を参照してください。

System Status

「System Status Report の生成と説明」 を参照してください。

System Status ページから、System Status Report を生成できます。

Logging

「ロギングを使用したデバッグのイネーブル化およびディセーブル化」 を参照してください。

Logging ページから、ログ ファイルに書き込まれるメッセージのタイプ(および数量)を変更したり、デバッグをイネーブルまたはディセーブルにしたりできます。

System Preferences

「[System Preferences] を使用したシステム全体のパラメータの設定」 を参照してください。

System Preferences ページから、次の情報を設定できます。

SNMP トラップの受信:Operations Manager が SNMP トラップをリッスンするポートを変更します。

SNMP トラップのフォワーディング:(オプション)トラップの受信側として、ホストおよびポート番号を設定します。

デフォルトの SMTP サーバ:電子メール通知用のデフォルト サーバを変更または入力します。

パージング スケジュール:日次のデータベース パージングの時刻を選択します。

Common Services サーバ:次のような他の CiscoWorks 製品を実行するリモート サーバを入力します。

Resource Manager Essentials(RME)

Campus Manager

CiscoView

Add Users

「ユーザの設定(ACS および非 ACS)」 を参照してください。

Common Services の [Local User Setup] ウィンドウを開きます。

Back Up and Restore

「Operations Manager データのバックアップと復元」を参照してください。

Operations Manager をバックアップおよび復元するのに使用可能なオプションを提供します。

詳細については、さらに次のトピックを参照してください。

Operations Manager のタスクのスケジュール

Operations Manager を最初にインストールしたときには、デフォルトで、 表 20-2 に示しているほとんどのタスクが同時に実行されないようにスケジュールされています。サイトの要件を満たすように、これらのタスクのスケジュールを設定できます。ただし、その場合でも、これらのタスクを同時に実行することは避ける必要があります。

 

表 20-2 スケジュールの考慮事項

スケジュールするタスク
デフォルトのスケジュール
コメントと注意事項
データベース パージング

毎日午前 0 時に実行する。

データベースのパージにかかる時間は、データベースのサイズによって異なります。

電話機のディスカバリ

毎日、00:00(午前 0 時)、04:00、08:00、12:00、16:00、および 20:00 に実行する。

IP Phone Discovery Schedule ページで最後の収集の開始時刻と終了時刻を比較して、最後の電話機ディスカバリが完了するまでにかかった時間を調べる必要があります。

「IP 電話検出の使用」 を参照してください。電話機ディスカバリが完了するまでに通常かかる時間を認識しておくと、スケジュールするときに役立ちます。

インベントリ収集

毎週月曜日の午前 2:00 に実行する。

デフォルトでは、インベントリ収集はデータベース パージングの 2 時間後に開始されます。

システム管理者は、Operations Manager でのスケジュール設定の他に、データベースのバックアップをスケジュールできます。 表 20-2 に示しているタスクと同時に実行しないように、データベース バックアップ スケジュールを慎重に調整する必要があります。

スケジュールの詳細については、次のトピックを参照してください。

「パージング スケジューラのステータスの表示」

「Operations Manager データのバックアップと復元」

SNMP トラップの受信とフォワーディングの設定

Operations Manager は、使用可能な任意のポートでトラップを受信し、そのトラップをデバイスおよびポートのリストに転送できます。この機能により、Operations Manager は、他のトラップ処理アプリケーションと簡単に連携できます。ただし、デバイス上で SNMP をイネーブルにして、次のいずれかを実行する必要があります。

トラップを直接 Operations Manager に送信するよう SNMP を設定する。

SNMP トラップの受信を NMS またはトラップ デーモンと統合する。

トラップを直接 Operations Manager に送信するには、「Operations Manager にトラップを送信できるようにするためのデバイスの設定」のタスクを実行します。SNMP トラップの受信を NMS またはトラップ デーモンと統合するには、「SNMP トラップの受信と他のトラップ デーモンまたは NMS との統合」の手順に従います。

Operations Manager にトラップを送信できるようにするためのデバイスの設定


) デバイスが SNMP トラップを Network Management System(NMS; ネットワーク管理システム)またはトラップ デーモンに送信する場合は、「SNMP トラップの受信と他のトラップ デーモンまたは NMS との統合」を参照してください。


Operations Manager は SNMP の MIB 変数とトラップを使用してデバイスの状態を調べるため、その情報を提供するようにデバイスを設定する必要があります。Operations Manager の監視対象とするすべてのシスコ デバイスで SNMP をイネーブルにし、Operations Manager サーバに SNMP トラップを送信するようそのデバイスを設定する必要があります。

デバイスに適切なコマンドライン インターフェイスまたは GUI インターフェイスを使用して、デバイスが Operations Manager にトラップを送信できるようにします。

「Cisco IOS ベースのデバイスが Operations Manager にトラップを送信できるようにするための設定」

「Catalyst デバイスが Operations Manager に SNMP トラップを送信できるようにするための設定」

Cisco IOS ベースのデバイスが Operations Manager にトラップを送信できるようにするための設定

Cisco IOS ソフトウェアを実行するデバイスの場合、次のコマンドを入力します。

(config)# snmp-server [community string] ro
(config)# snmp-server enable traps
(config)# snmp-server host [a.b.c.d] traps [community string]
 

ここで、[community string] は SNMP リードオンリー(read-only)コミュニティ ストリングを示し、[a.b.c.d] は SNMP トラップの受信ホスト(Operations Manager サーバ)を示しています。

詳細については、適切なコマンド リファレンス ガイドを参照してください。


ステップ 1 Cisco.com にログインします。

ステップ 2 [Products & Services] > [Cisco IOS Software] を選択します。

ステップ 3 Cisco IOS ベースのデバイスによって使用されている Cisco IOS ソフトウェア リリースのバージョンを選択します。

ステップ 4 [Technical Documentation] を選択し、適切なコマンド リファレンス ガイドを選択します。


 

Catalyst デバイスが Operations Manager に SNMP トラップを送信できるようにするための設定

Catalyst ソフトウェアを実行するデバイスの場合、次のコマンドを入力します。

(enable)# set snmp community read-only [community string]
(enable)# set snmp trap enable all
(enable)# set snmp trap [a.b.c.d] [community string]
 

ここで、[community string] は SNMP リードオンリー(read-only)コミュニティ ストリングを示し、[a.b.c.d] は SNMP トラップの受信ホスト(Operations Manager サーバ)を示しています。

詳細については、適切なコマンド リファレンス ガイドを参照してください。


ステップ 1 Cisco.com にログインします。

ステップ 2 [Products & Services] > [Cisco Switches] を選択します。

ステップ 3 適切な Cisco Catalyst シリーズ スイッチを選択します。

ステップ 4 [Technical Documentation] を選択し、適切なコマンド リファレンス ガイドを選択します。


 

SNMP トラップの受信と他のトラップ デーモンまたは NMS との統合

SNMP トラップの受信を他のトラップ デーモンおよび他のネットワーク管理システム(NMS)と統合するには、次の作業を 1 つ以上完了する必要がある場合があります。

Operations Manager を実行しているホストを、ネットワーク デバイスのトラップ宛先のリストに追加する 「Operations Manager にトラップを送信できるようにするためのデバイスの設定」 を参照してください。宛先トラップ ポートとしてポート 162 を指定します。

別の NMS が標準 UDP トラップ ポート(162)上ですでにトラップをリッスンしている場合は、別のポート(ポート 9000 など)を使用するように Operations Manager を設定する必要があります。「[System Preferences] を使用したシステム全体のパラメータの設定」 を参照してください。

ネットワーク デバイスがすでにトラップを別の管理アプリケーションに送信している場合は、トラップを Operations Manager に転送するようそのアプリケーションを設定する。

表 20-3 は、SNMP トラップ受信のシナリオを示し、それぞれの利点を挙げています。

 

表 20-3 トラップ受信の設定シナリオ

シナリオ
利点

ネットワーク デバイスが、Operations Manager を実行しているホストのポート 162 にトラップを送信する。Operations Manager はトラップを受信し、そのトラップを NMS に転送します。

NMS の再設定が不要。

ネットワーク デバイスの再設定が不要。

Operations Manager が信頼性の高いトラップ受信、ストレージ、およびフォワーディング メカニズムを提供。

NMS が引き続きポート 162 でトラップを受信。

ネットワーク デバイスが引き続きポート 162 にトラップを送信。

NMS がデフォルト ポート 162 でトラップを受信し、Operations Manager を実行しているホストのポート 162 にそのトラップを転送する。

NMS の再設定が不要。

ネットワーク デバイスの再設定が不要。

Operations Manager は、NMS によってドロップされたトラップを受信しない。

Operations Manager が使用するポートとプロトコル

Operations Manager は、次のプロトコルを使用します。

SNMPsnmp

ICMP

TCP/IP

SMTP

RMI

HTTP

Operations Manager は、 表 20-4 に示している TCP ポートと UDP ポートを使用します。

 

表 20-4 Operations Manager の着信ポート

ポート番号
使用方法

162

トラップを受信するために Operations Manager によって使用されるデフォルトのポート番号。

1024-4999

一時的なポートとして Operations Manager によって使用される。

40000-41000

内部アプリケーション メッセージングのために Common Transport Mechanism によって使用される。

42344

Synthetic Testing Web サービスによって使用される。

42350-42353

メッセージング ソフトウェアによって使用される。

43441-43459

データベース ポートとして使用される。

Operations Manager は、次のポートを使用します。

43445:Alert History データベース エンジンによって使用される。

43446:インベントリ サービス データベース エンジンによって使用される。

43447:イベント処理データベース エンジンによって使用される。

43449:IP Phone Information Facility データベース エンジンによって使用される。

43459:Service Monitor データベース エンジンによって使用される。

9002

IP テレフォニー サーバとデバイス障害サーバの両方をリッスンするためにブローカによって使用される。

9009

デバイス障害サーバからのトラップを受信するために IP テレフォニー サーバによって使用されるデフォルトのポート番号。

Service Quality Event Settings の設定


) Service Quality イベントは、[Service Quality Alerts] 画面に表示されます。「Service Quality Alerts の監視」 を参照してください。


後述の手順を使用して、次の情報を設定します。

CriticalServiceQualityIssue イベントをトリガーする MOS レベル。

MOS が Service Monitor に設定されているしきい値を下回る場合、Service Monitor はトラップを送信します。Service Monitor に設定されている MOS しきい値よりも低い MOS しきい値を指定するイベント設定値を Operations Manager に設定できます。MOS がそのイベント設定以下であるトラップを Operations Manager が受信すると、Operations Manager は CriticalServiceQualityIssue イベントを生成します。MOS がそのイベント設定を上回るトラップを Operations Manager が受信すると、Operations Manager は ServiceQualityIssue イベントを生成します。


) Service Monitor からのトラップが Operations Manager によって処理されるようにするには、Service Monitor を Operations Manager に追加するとともに、Service Monitor を使用して Operations Manager をトラップ レシーバとして設定する必要があります。Operations Manager に Service Monitor を追加するには、「Operations Manager から Service Monitor へのリンクの追加」 を参照してください。



ステップ 1 [Administration] > [Service Quality Settings] > [Event Settings] を選択します。[Service Quality Event Settings] ページが表示されます。

ステップ 2 次のフィールドに値を入力します。

Mark the Service Quality Issue event critical when MOS drops below :重大な ServiceQualityIssue イベントをトリガーする MOS スコアを入力します。デフォルトは 3.5 です (MOS 値の範囲は 0.1 ~ 4.9 です)。


) この MOS スコアは、Service Monitor に設定されている MOS しきい値よりも低くなるようにしてください。


Generate a Multiple Service Quality Issues event when more than [ a ] Service Quality Issue events occur in [ b ] minutes : 次の数値を入力します。

[a]:Service Quality Issue イベントの数。

[b]:指定した数の Service Quality Issue イベントがこの時間(分)内に発生すると、Operations Manager によって Multiple Service Quality Issues イベントが生成されます。


) デフォルトでは、Operations Manager は 8 時間後に Service Quality イベントをクリアします。イベントのクリア後 31 日間は、Service Quality Event History で引き続きそのイベントを表示できます。「Service Quality History レポートを使用する前に」 を参照してください。


ステップ 3 [Save] をクリックします。


 

関連トピック

「Service Monitor サーバへのアクセス」

「Operations Manager から Service Monitor へのリンクの追加」

System Status Report の生成と説明

System Status Report にアクセスするには、[Administration] > [System Status] を選択します。System Status Report が開きます。

System Status Report はデータをすぐに示し、サーバのスタートアップから、または過去 24 時間のデータを含む場合があります。模擬テストの条件は現在表示されています。失敗したテストは次のエラーを受け取ります。

The test cannot run because the CPU has been busy.The test will run when the CPU becomes available.

System Status Report をナビゲートするには、次の項目を使用します。

[Go to] フィールド:リストからレポートのセクションを選択します。どのセクションの末尾でも、[Back to Top] リンクをクリックできます。

Summary:次のいずれかのリンクをクリックして、レポートのセクションを選択します。

Failed Processes:次のメッセージが表示されます。

(Unable to contact SNMP Service. Please check if Windows SNMP Service is installed and running.)

詳細については、「Operations Manager を監視するための SNMP の使用」を参照してください。

Inventory

Data Purging

Diagnostics: Synthetic Tests


) 失敗した模擬テストは、実行時にシステム CPU の使用率が 80 パーセントを超えたために、テストが実行されなかったことを示します。


Diagnostics: Phone Status Tests

Diagnostics: Node-to-Node Tests

Notifications

System Limits


) Summary で [View Details] リンクをクリックして、レポートのセクションを選択することもできます。


System Status Report には、次のセクションが含まれています。

Failed Processes :失敗したプロセスの名前。

Inventory :次のタイプのデータ収集について、名前、最後の実行時刻、ステータス、および次にスケジュールされている時刻を表示します。

Discovery:新しいデバイスを識別し、DCR に追加します (オプション。スケジュールすることも、必要に応じて実行することもできます)。

DCR Domain Status:Operations Manager が(Isolated モードで動作するのではなく)デバイスおよびクレデンシャルを同期させるように設定されている場合、他の CiscoWorks サーバから DCR にデバイスを追加します。

Device Selection:(DCR に追加されたときに)自動的に、またはユーザが DCR から手動で選択したときに、デバイスを Operations Manager の監視対象に追加します。Status:Automatic または Manual。

Device Inventory Collection:Operations Manager の監視対象であるデバイスを調査して、デバイス コンポーネントとそのステータスをアップデートします。デバイスの検出は行いません。

Phone Inventory Collection:Operations Manager の監視対象であるすべてのスイッチおよび Cisco Unified Communications Manager をチェックすることにより、ネットワーク内のすべての IP 電話に関する情報を検出および収集します。デバイスの検出は行いません。

Data Purgin g:最新のデータベース パージング タスクの開始時刻、終了時刻、およびステータス。

Diagnostics: Synthetic Tests :失敗したテストのテスト名、テスト タイプ、発信元(IP アドレスまたは DNS 名)、宛先(IP アドレスまたは DNS 名)、失敗した時刻、原因。

Diagnostics: Phone Status Tests :失敗したテストのテスト名、発信元ルータ、内線番号、MAC アドレス、IP アドレス、失敗した時刻、原因。

Diagnostics: Node-to-Node Tests :失敗したテストのテスト名、テスト タイプ、エンドポイント、失敗した時刻、原因。

Notifications :デバイスのイベント説明、イベント ID、宛先、失敗した時刻、原因。


) Trap および Syslog の通知失敗は、Trap/Syslog 通知が送られた際、Trap/Syslog Receiver の未解決の完全修飾ドメイン名のために通知が失敗したことを示します。


System Limits :次のパラメータに対する現在の(Current)値、制限(Limit)値、および制限するもの(ライセンスまたはシステムのリソース)。

Devices:Current:Operations Manager の監視対象インベントリ内のデバイス数。Limit:ライセンスによって許可されているデバイス数。

Phones:Current:Operations Manager の監視対象インベントリ内の電話機数。Limit:ライセンスによって許可されている電話機数。

Ports:Current:Operations Manager の監視対象インベントリ内のポート数。Limit:ライセンスによって許可されているインターフェイス数。

Interfaces:Current:Operations Manager の監視対象インベントリ内のインターフェイス数。Limit:ライセンスによって許可されているインターフェイス数。

Synthetic Tests。

Phone Status Tests。

Node-to-Node Tests。

Devices monitored for performance and capacity。

Devices monitored for SRST。

[System Preferences] を使用したシステム全体のパラメータの設定


ステップ 1 [Administration] > [Preferences] を選択します。[System Preferences] ページが表示されます。

ステップ 2 次の表に示すデータを入力します。

 

GUI 要素
説明/処理

[Trap Forwarding Parameters] テーブル

(オプション)トラップの受信側を最大 3 つ入力します。

Trap Server n n は 1 ~ 3 の数値):IP アドレスまたは DNS 名を入力します。

Port:ホストがトラップを受信できるポート番号を入力します。

(注) デフォルトでは、Operations Manager はトラップを転送しません。

詳細については、次の付録および項を参照してください。

「処理される SNMP トラップ」

「SNMP トラップの受信とフォワーディングの設定」

[CiscoWorks Servers] テーブル

(オプション)各 CiscoWorks サーバ(RME、Campus、および CiscoView)に対して、次の操作を行います。

Protocol:http(サーバ上で SSL がイネーブルである場合は https)を選択します。

Server:IP アドレスまたは DNS 名を入力します。

Port:サーバ上で CiscoWorks を起動するときに使用するポート番号を入力します。通常、プロトコルが http である場合のポート番号は 1741 で、プロトコルが https である場合のポート番号は 443 です。

(注) Operations Manager は、この情報を使用して、CiscoWorks 製品を起動します。

[SNMP Trap Community] フィールド

リード(read)コミュニティ ストリングを入力します。

[Trap Receiving Port] フィールド

Operations Manager が SNMP トラップをリッスンするポートを変更するには、ポートを入力します。デフォルトは 162 です。詳細については、「SNMP トラップの受信とフォワーディングの設定」を参照してください。

(注) すでに使用されているポートのリストについては、「Operations Manager が使用するポートとプロトコル」を参照してください。

[SMTP Server] フィールド

電子メール通知を送信するときに使用する、Operations Manager の完全修飾 SMTP サーバ名を入力します。詳細については、「通知の使用方法」を参照してください。

(注) 「電子メール通知がブロックされていないことの確認」 を参照してください。

Purging Scheduler

Alert History データベースのパージングを開始する時刻を選択します。

Hour:0 ~ 23

Minute:0 ~ 50(10 分間隔)

デフォルトは 00:00 です。パージングすると、31 日分のデータがデータベースに保持されます。

(注) 「Operations Manager のタスクのスケジュール」の情報を確認して、そこに示されている他のスケジュール済みジョブと日次パージングが競合しないようにしてください。

ステップ 3 [Apply] をクリックします。


 

電子メール通知がブロックされていないことの確認

[SMTP Server] フィールド上にアンチウイルス アプリケーションが存在する場合は、ポートブロッキング ルールによって通知電子メールの送信が停止されていないことを確認します。アンチウイルス アプリケーションの中には、マスメーリング ワームをブロックするためにポートブロッキングを使用するものもあります。必要に応じて、ポートブロッキング ルールを削除します。

通知電子メールの詳細については、「通知の設定」を参照してください。

パージング スケジューラのステータスの表示

毎日、Operations Manager データ パージ ジョブの実行後、Job Browser からそのジョブのステータスを確認できます。


) System Status Report で日次パージングのステータスを確認することもできます。「System Status Report の生成と説明」を参照してください。



ステップ 1 Operations Manager ホームページの右上隅にある [CiscoWorks] リンクをクリックして、CiscoWorks ホームページを起動します。

ステップ 2 CiscoWorks ホームページから、[Common Services] > [Server] > [Admin] > [Job Browser] を選択します。Job Browser ページが表示され、スケジュール済みジョブのテーブルが示されます。

ステップ 3 Type カラムで Operations Manager:DataPurge ジョブを探し、Status カラム内の情報を確認します。


 


) Job Browser を使用して Operations Manager:DataPurge ジョブを削除すると、デーモン マネージャを再起動するか、サーバをリブートするか、日次パージング スケジュールを再設定するまで、パージングは再開されません。


ロギングを使用したデバッグのイネーブル化およびディセーブル化

Operations Manager は、すべての主要な機能モジュールのアプリケーション ログ ファイルを記述します。デフォルトでは、Operations Manager は、これらのログ ファイルにエラー メッセージと重大なメッセージだけを書き込みます。ロギングをディセーブルにはできません。ただし、次の作業を実行できます。

必要に応じて、ログレベルを上げ、さらに多くのデータを収集する。

標準としてのデフォルト ログレベルに戻す。


ステップ 1 [Administration] > [Logging] を選択します。[Logging Configuration] ページが表示されます。


) ロギングをディセーブルにはできません。Operations Manager は、必ずエラー メッセージと重大なメッセージをアプリケーション ログ ファイルに書き込みます。


ステップ 2 各 Operations Manager 機能モジュールの [Error] チェックボックスは、常にオンになっています。これをオフにはできません。

すべてのモジュールを [Error](デフォルトのログレベル)に設定するには、次の手順に従います。

a. [Default] ボタンをクリックします。確認のページが表示されます。

b. [OK] をクリックします。

個々のモジュールのログレベルを変更するには、次の手順に従います。

a. 変更するモジュールごとに、次のログレベルのいずれかを選択します(またはすべてを選択解除します)。

Warning:エラー メッセージと警告メッセージをロギングします。

Info:エラー メッセージ、警告メッセージ、および情報メッセージをロギングします。

Debug:エラー メッセージ、警告メッセージ、情報メッセージ、およびデバッグ メッセージをロギングします。


) モジュールのすべてのチェックボックスをオフにすると、そのモジュールが [Error](デフォルトのログレベル)に戻ります。


b. 変更を確認します。変更をキャンセルするには、[Cancel] ボタンをクリックします。キャンセルしない場合は、[Apply] ボタンをクリックします。[Apply] ボタンをクリックすると、ただちに、Operations Manager の機能モジュールが、変更したログレベルに再設定されます。


 


ヒント SM_BACKUP_FILE_LIMIT 設定を変更することによって、Operations Manager に存在できるログ ファイル数を調整できます。デフォルトは 1,000 ファイルで、存在できるファイル サイズに対するパラメータはありません。

dmctl コマンドを使用して起動する roll_log ユーティリティを使用することによって、新しいログ ファイルを開始できます。次のコマンドを実行します。

C:¥>cd PROGRA~1¥CSCOpx¥Unified Communications s¥smarts¥bin
C:¥Program Files¥CSCOpx¥Unified Communications s¥smarts¥bin> dmctl -s <DM_NAME> exec roll_log <filename>
 

コマンドで、C:¥Program Files¥CSCOpx は Operations Manager がサーバにインストールされているパスを示します。インストール時にデフォルト ディレクトリを選択した場合は C:¥Program Files¥CSCOpx または C:¥PROGRA~1¥CSCOpx になります。インストール時にデフォルト ディレクトリを選択しなかった場合、C:¥Program Files を正しいパスで置き換えてください。

このコマンドが呼び出されると、現在のログ ファイルの最後に情報メッセージが書き込まれ、ファイル名は変更されて、新しいログ ファイルが作成されます。最良の方法は、毎日ログ ファイルのサイズを調べて dmctl roll_log へのコールを行うスクリプトを作成することです。


 

システム アプリケーション MIB のログレベルを変更する方法については、「システム アプリケーション MIB のログ ファイルの表示」を参照してください。

ログ ファイルへのアクセスと削除

各 Operations Manager モジュールは、 <NMSROOT> \log\CUOM フォルダ内の独自のフォルダにログ ファイルを書き込みます。表 20-5 は、各 Operations Manager モジュール、ログ ファイルが格納されるフォルダの名前、関連ログ ファイル、およびファイルが自動的に保存または削除される(循環されるとも呼ばれます)かどうかを示しています。


) NMSROOT は、Operations Manager がインストールされているサーバ上のフォルダです。インストール時にデフォルト ディレクトリを選択した場合は C:¥Program Files¥CSCOpx または C:¥PROGRA~1¥CSCOpx になります。


ログ ファイルが、プリセットされている最大サイズに達すると、モジュールによってそのファイルがバックアップされ、新しいログ ファイルへの書き込みが開始されます。ログ ファイルの最大サイズは、モジュールによって異なります。モジュールが保持するバックアップ ログ ファイルの最大数も異なります。バックアップ ファイルがプリセットされている最大数に達すると、Operations Manager は古いファイルを削除し始めます。


ヒント ログ ファイルが循環されない場合、ログ循環ユーティリティ、logrot、を実行する必要があります。これはこれらのファイルを管理するため、Cisco.com の CiscoWorks Common Services マニュアルに記述されています。



) Operations Manager は、DFMServer ログ ファイル(DFM.log)を自動的にリセットしません。良好なシステム パフォーマンスを保つために、このファイルが 30 MB を超えた場合はファイルをバックアップしてください。「DFM ログ ファイルの保持」 を参照してください。


デフォルトでは、Operations Manager はログ ファイルにエラー メッセージだけを書き込みます。ログレベルを変更することにより、ログ ファイルに格納される情報量に影響を及ぼすことができます。この方法については、「ロギングを使用したデバッグのイネーブル化およびディセーブル化」を参照してください。

 

表 20-5 モジュール別の Operations Manager ログ ファイル

機能/モジュール
< NMSROOT > 内のフォルダ
ログ ファイル
ファイルの循環1

Alert and Event History

\log\cuom\FH

FHUI.log

FHCollector.log

FHServer.log

はい

Alerts and Events Display

\log\cuom\AAD

AAD.log

はい

Application and Connectivity Poller

\log\cuom\VHM

Poller.log

TISPollerLogger.log

はい

Detaild Device View

\log\cuom\DDV

DDV.log

はい

Device Management

\log\cuom\tis

DCRAdapter.log

DeviceManagement.log

TISServer.logtisserverlog

はい

Event Processing Adapters

\log\cuom\epa

adapterServer.log

dfmEvents.log

vhmEvents.log

はい

Event Promulgation Module(EPM)

\log\cuom\EPM

ClearedDroppedEvents.log

EPM.log

EPMDroppedEvents.log

EPMServer.log

EventPlugin.log

FloodDroppedEvents.log

はい

はい

いいえ

Graphics Utility

\log\cuom\TGU

TGU.log

TGU_DataProcessor.log

はい

IP Phone Information Facility

\log\ipiu

ipiuapp.log

はい

IP Phone Information Facility Server

\log

pif.log

いいえ2

IP Phone Outage Status

\log\cuom\PR

PhoneEvent.log

PhoneReachability.log

いいえ

はい

IP Phone Status Display

\log\cuom\PAD

PAD.log

はい

IP SLA Library

\log\cuom\IPSLA

STL.log

はい

IPC Discovery

\log\cuom\discovery

discovery.log

NGD1.log

NGD2.log

はい

IPT Health Report

log\cuom\ipthr

ipthr.log

はい

Inventory Collection Schedule

\log\cuom\Rediscovery

Rediscovery.log

はい

Inventory Collector

\log\cuom\vhm

 

abstractpoller.log

connectivityProgress.log

DataStore.log

DataStoreGSUJms.log

DFMCollector.log

InchargeAccess.log

InventoryCollector.log

InventoryCollector_stdout.log

InventoryCollector_stderr.log

InvokePoller.log

NodesinCluster_MediaServer_colccmpublin.cisco.com.log

OnDemand_SnmpResponsivePoller.log

OnDemand_VoiceClusterPoller.log

Poller.log

RisPortAXLSOAPWrapper.log

RisPortAXLSOAPWrapperArguments.log

SMARTSATTRIBUTECHANGE.log

SMARTSEVENTNOTIFY.log

Store.log

TISPollerLogger.log

VHMGSUPoller.log

VHMIntegrator.log

VHMIntegrator_stdout.log

VHMIntegrator_sterr.log

VICDFMADD.log

VICHTTP.log

VICTIS.log

VoiceClusterPoller_VoiceCluster_VE-StandAloneCluster.log

はい

Inventory Interactor

\log\cuom\vhm

CiscoCommunicationsManagerOrClusterGrouping.log

Interactor.log

はい

Inventory Service

\log\cuom\tis

DCRAdapter.log

TISServer.logtisserverlog

はい

Logging

ils

ItemLogService.log

MultiProc-Logger.log

はい(サイズが 500 KB に到達後)

Node-to-Node Tests Common Utilities

\log\cuom\IPSLA

DAL.log

plib.log

はい

Node-to-Node Tests Data Poller

\log\cuom\IPSLA

WPUSS.log

WPU_DataPoller.log

WPUDcache.log

はい

Node-to-Node Tests Device Management

\log\cuom\IPSLA

DMAudit.log

WPUDM.log

いいえ

はい

Node-to-Node Tests Management

\log\cuom\IPSLA

SM.log

SMAudit.log

はい

いいえ

Notification Services

\log\cuom\nots

nots.log

nots_dropped_events.log

notifications_audit.log

notifications_failures.log

notifications_success.log

はい

Personalized Reports

\log\cuom\ipthr

ipthr.log

はい

PTM Adapter for Data Settings

\log\cuom\cfi

PollingThresholdAdapter.log

はい

PTM Adapter for Voice Settings

\log\cuom\vhm

VHMPollingThresholdAdapter.log

はい

Polling and Threshold Manager

\log\cuom\PTM

PTMClient.log

PTMDB.log

PTMOGS.log

PTMPTA.log

PTMServer.log

はい

Purging Scheduler

\log\cuom\DPS

DPS.log

はい

SRST Monitoring

\log\cuom\srst

srst_audit.log

srst_import_errors.log

srst_test_creation_results.log

srst_import.log

srst_ui.log

srst_server.log

いいえ

いいえ

いいえ

はい

はい

はい

Self Diagnostic Report

\log\cuom\sdr

sdr.log

はい

Service Level View Server

\log\cuom\topo

Topology_Client.log

Topology_Server.log

はい

Service Quality Alerts Display

\log\cuom\QOVAD

QOVAD.log

はい

Service Quality Manager

\log\cuom\QoVM

QoVMServer.log

いいえ

Synthetic Testing Server

\log

STServer.log

いいえ

Synthetic Testing UI

\log

ct-ui.log

はい

View Manager

\log\cuom\VGM

vgm.log

はい

View Severity Manager

\log\cuom\vsm

AlertInfo.log

GroupHandler.log

UserInfo.log

vsmServer.log

はい

1.循環が必要なログを循環させる方法については、Cisco.com の CiscoWorks Common Services マニュアルで logrot ユーティリティに関する情報を参照してください。

2.大規模ネットワークでは、IP Phone Information Facility Server (pif.log)によってサポートされる監査エントリの最大サイズは 70,000 K です。


) Operations Manager アプリケーション ロギング サービスも、<NMSROOT>\log\cuom フォルダの下にログ ファイルを保持します。各モジュールのコンフィギュレーション ファイルは、<NMSROOT>\log\conf 内に格納されます。


セキュリティ上の考慮事項

次の各トピックでは、Operations Manager の重要なセキュリティ問題をいくつか説明します。

「ファイルの所有権と保護」

「SSL」

「SNMPv3」

「Operations Manager データベースのパスワードの変更」

ファイルの所有権と保護

Operations Manager ファイルのセキュリティは、CiscoWorks と同じ標準に基づいています。


注意 ファイルまたはディレクトリに対して、その保護を厳しくするような変更はしないでください。必要に応じて、保護をより緩くすることができます。

すべての Operations Manager ファイルは、所有者 CASUSER でインストールされます。CASUSER だけが、NMSROOT にインストールされるファイルを作成、削除、または編集できます。 NMSROOT は、Operations Manager がインストールされているシステム上のディレクトリです。インストール時にデフォルト ディレクトリを選択した場合は C:¥Program Files¥CSCOpx または C:¥PROGRA~1¥CSCOpx になります。


FAT パーティションにはファイル保護が適用されません。


SSL

Secure Socket Layer(SSL)は、プライバシー、認証、およびデータ整合性によってデータのセキュアなトランザクションを可能にするアプリケーション レベルのプロトコルです。SSL は、証明書、公開鍵、および秘密鍵に依存しています。セキュアなアクセスの必要性に応じて、SSL をイネーブルまたはディセーブルにすることができます。

Operations Manager は、クライアントとサーバの間の SSL をサポートしています。

ブラウザとサーバ間の SSL のイネーブル化

Operations Manager を開始する時は、常にセキュア モードでログイン ページが開き、クライアント ブラウザと Operations Manager サーバ間に安全なアクセスを提供します。セキュア モードでは、SSL がブラウザとサーバ間の伝送チャネルを暗号化するために使用されます。Operations Manager 全体でセキュア モードを使用するには、Common Services で SSL をイネーブルにします。


) Operations Manager と Service Monitor のシステムで SSL をイネーブルにする場合、SSL は両方のアプリケーションに対してイネーブルになります。



注意 メンテナンスを実行する場合、OMHealthMonitor Windows Service を手動で停止する必要があります。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。


ステップ 1 [CiscoWorks] > [Common Services] > [Server] > [Security] > [Browser-Server Security Mode Setup] を選択してください。[Browser-Server Security Mode Setup] ダイアログボックスが表示されます。

ステップ 2 チェックボックスをオンにします。

ステップ 3 [Apply] をクリックします。

ステップ 4 Operations Manager からログアウトして、すべてのブラウザ セッションを閉じます。

ステップ 5 次のコマンドを入力して、コマンドラインからデーモン マネージャを再起動します。

net stop crmdmgtd
net start crmdmgtd
 

ステップ 6 ブラウザを再起動し、セキュア URL を使用して Operations Manager を再起動します。

https://<servername>:443
 

) ブラウザに http://<servername>:1741 と入力して、SSL がイネーブルの場合、セキュア URL へ転送されます。



 

SNMPv3

Operations Manager は、機密情報の漏洩を防ぐために、サーバとデバイスの間で SNMPv3(認証とアクセス制御を行うが、データ暗号化は行わない)をサポートしています。これにより、パケットレベルのセキュリティ、完全性保護、およびリプレイ保護が実現されますが、パケットは暗号化されません。

Operations Manager データベースのパスワードの変更

始める前に

このトピックの手順では、次の Operations Manager データベースのパスワードを変更できます。

itemEPM:イベント公表

itemFH:Alert History

itemInv:Inventory

itemIpiu:IP 電話情報

qovr:Cisco Unified Service Monitor


注意 メンテナンスを実行する場合、OMHealthMonitor Windows Service を手動で停止する必要があります。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。


ステップ 1 Operations Manager サーバのコマンド プロンプトで、次のコマンドを入力してデーモン マネージャを停止します。

net stop crmdmgmt
 

ステップ 2 NMSROOT\ conf\itemDb\bin ディレクトリに移動します。次の例を参考にしてください。

cd C:¥PROGRA~1¥CSCOpx¥conf¥itemDb¥bin
 

) NMSROOT は、Operations Manager がインストールされているサーバ上のフォルダです。インストール時にデフォルト ディレクトリを選択した場合は C:¥Program Files¥CSCOpx または C:¥PROGRA~1¥CSCOpx になります。


ステップ 3 ChangeItemDbPasswd.pl と入力した後、新しいパスワードを指定します。次の例を参考にしてください。

ChangeItemDbPasswd.pl newpassword
 

ステップ 4 次のコマンドを入力してデーモン マネージャを再起動します。

net start crmdmgmt
 


 

デバイス サポート

Operations Manager で新しいデバイスのサポートが可能になると、Cisco.com の Operations Manager 用 planner ページで Incremental Device Updates(IDU)が公表されます。入手可能になった IDU の告知、ダウンロード、およびインストール手順については、planner ページを参照してください。

新しい IDU が入手可能になると、Cisco.com からその IDU をダウンロードできます。

http://www.cisco.com/en/US/products/ps6535/products_device_support_tables_list.html で デバイスのサポート情報については、Cisco.com の『 Supported Device Table for Cisco Unified Operations Manager 』( http://www.cisco.com/en/US/products/ps6535/products_device_support_tables_list.html )を参照してください。

システム管理タスクの実行

CiscoWorks を使用して、次のような多くのシステム管理タスクを実行できます。

「CiscoWorks ホームページの起動」

「ユーザの設定(ACS および非 ACS)」

「自己署名セキュリティ証明書の年次作成」

「Operations Manager データのバックアップと復元」

「Operations Manager プロセスの起動と停止」

「ログ ファイルの保持」

「ソフトウェア バージョンまたはライセンス情報の表示」

「インストールされている Operations Manager(または Service Monitor)のビルド ID の検出」

CiscoWorks ホームページの起動


ステップ 1 Operations Manager ホームページの右上隅で、[CiscoWorks] リンクをクリックします。CiscoWorks ホームページが開きます。


 

ユーザの設定(ACS および非 ACS)

CiscoWorks サーバは、CiscoWorks アプリケーションのユーザを認証および認可するためのメカニズムを提供します。ユーザが何を表示して何を実行できるかは、ユーザ ロールによって決まります。システム管理者は、CiscoWorks ホームページからユーザ ロールを設定できます。[Common Services] で、[Server] > [Security] > [Single-Server Management] > [Local User Setup] を選択します。ここから、ユーザを追加、編集、または削除できます。

CiscoWorks サーバは、CiscoWorks アプリケーションのユーザを認証するために、次の 2 つの異なるメカニズムつまり「モード」を提供します。

CiscoWorks ローカル モード:デフォルトでは、CiscoWorks サーバは CiscoWorks ローカル モードつまり「非 ACS モード」を使用します。CiscoWorks ローカル モードでは、CiscoWorks がロールおよびそのロールに関連付けられている特権を割り当てます。これらは、Common Services Permission Report に表示されます。(Permission Report を生成するには、Common Services ホームページから [Server] > [Reports] > [Permission Report] を選択し、[Help] をクリックします)。詳細については、「CiscoWorks ローカル モードを使用したユーザの設定」 を参照してください。

CiscoSecure Access Control Server(ACS)モード:ACS が、ロールに関連付けられる特権を指定します。ACS では、デバイスベースのフィルタリングも実行できるため、表示を許可したデバイスだけをユーザに表示できます。ACS の使用(「ACS モード」と呼ばれる)は、ネットワークに ACS がインストールされており、Operations Manager が ACS に登録されている場合にサポートされます。詳細については、「ACS モードを使用したユーザの設定」を参照してください。

Common Services が ACS モードを使用している場合は、Operations Manager も ACS モードを使用する必要があります。ACS モードを使用しないと、Operations Manager のユーザが何も権限を持たなくなります。ただし、別の Operations Manager インスタンスがすでに ACS と統合されている場合、新しい Operations Manager も ACS に統合されます。

CiscoWorks ローカル モードを使用したユーザの設定

CiscoWorks ローカル モードを使用して、ユーザを追加し、ユーザ ロールを指定するには、次の手順を使用します。


ステップ 1 [Administration] > [Add Users] を選択します。Common Services の [Local User Setup] ウィンドウが開きます。

ステップ 2 [Local User Setup] ウィンドウで [Help] ボタンをクリックし、設定手順の詳細を参照します。


 

各ユーザ ロールが Operations Manager のタスクにどのように関連付けられているかを理解するには、CiscoWorks Permission Report を使用します。Common Services ホームページから [Server] > [Reports] > [Permission Report] > [Generate Report] を選択し、Cisco Unified Operations Manager を見つけるまで下にスクロールします。

ACS モードを使用したユーザの設定

Operations Manager でこのモードを使用するには、ネットワークに Cisco Secure ACS がインストールされており、Operations Manager が ACS に登録されている必要があります。


ステップ 1 CiscoWorks サーバが使用しているモードを確認します。Common Services ホームページから [Server] > [Security] > [AAA Mode Setup] を選択し、ACS と Non-ACS のどちらの [Type] オプション ボタンが選択されているかを調べます。

ステップ 2 ACS サーバを調べて、Operations Manager が ACS に登録されているかどうかを確認します(ACS が選択されている場合)。

ステップ 3 ACS のロールを編集するには、次の作業を行います。

ACS のオンライン ヘルプ(ACS サーバ上)を参照し、ロールを編集する方法を調べます。

Common Services のオンライン ヘルプを参照し、DCR(特にロールの依存関係)に対する ACS の影響を調べます。


) ACS を使用して Operations Manager のロールを編集すると、同じ ACS サーバに登録されている Common Services サーバを使用している他のすべての Operations Manager インスタンスにその変更が伝搬されます。



 

ACS モードでの Operations Manager の使用方法

ここで述べるタスクを実行する前に、Cisco Secure ACS に Operations Manager サーバを正常に設定したことを確認する必要があります。CiscoWorks ログイン モジュールを ACS モードに設定した後で Operations Manager をインストールすると、Operations Manager のユーザには何も権限が付与されません。ただし、Operations Manager アプリケーションは Cisco Secure ACS に登録されます。


) CiscoWorks サーバに定義されている System Identity Setup ユーザを Cisco Secure ACS に追加する必要があります。このユーザにはネットワーク管理者特権が必要です。


CiscoWorks ログイン モジュールを使用して、CiscoWorks サーバのネイティブ メカニズム(CiscoWorks Local ログイン モジュール)以外の認証ソースで新しいユーザを追加できます。この目的で、Cisco Secure ACS サービスを使用できます。

ACS モードの場合は、デフォルトで、CiscoWorks サーバの認証スキームに 5 つのロールがあります。ここでは、これらのロールを特権が小さなものから順に示します。

 

ヘルプ デスク

このロールのユーザは、固定的なデータからネットワーク ステータス情報にアクセスできます。デバイスと通信することも、ネットワークに到達するジョブをスケジュールすることもできません。

例:Service Level View の起動。

アプルーバ

このロールのユーザは、すべての Operations Manager タスクを承認できます。また、ヘルプ デスクのすべてのタスクを実行できます。

例:Alerts and Events の起動。

ネットワーク オペレータ

このロールのユーザは、ネットワークからのデータ収集に関連するすべてのタスクを実行できます。ネットワークに対する書き込みアクセス権は持ちません。また、アプルーバのすべてのタスクを実行できます。

例:模擬テストの追加。

ネットワーク管理者

このロールのユーザは、ネットワークを変更できます。また、ネットワーク オペレータのタスクを実行できます。

例:Service Level View のデフォルト ビューの設定。

システム管理者

このロールのユーザは、CiscoWorks のすべてのシステム管理タスクを実行できます。CiscoWorks ホームページから Permission Report を参照してください([Common Services] > [Server] > [Reports] > [Permission Report])。

例:LDAP の設定。

Cisco Secure ACS を使用して、これらのロールの特権を編集できます。カスタム ロールおよびカスタム特権を作成することで、独自のビジネス ワークフローやニーズに合せて Common Services クライアント アプリケーションをカスタマイズできます。

デフォルトの CiscoWorks 特権を編集する方法については、Cisco Secure ACS のオンライン ヘルプを参照してください (Cisco Secure ACS で、[Online Documentation] > [Shared Profile Components] > [Command Authorization Sets] をクリックします)。

Cisco Secure ACS での CiscoWorks のロールと特権の編集

別の Operations Manager インスタンスが同じ Cisco Secure ACS に登録されている場合、新しい Operations Manager インスタンスはそのロール設定を継承します。さらに、Operations Manager のロールに加えた変更は、Cisco Secure ACS によって他の Operations Manager インスタンスに伝搬されます。Operations Manager を再インストールすると、Operations Manager の再起動時に Cisco Secure ACS の設定が自動的に適用されます。


ステップ 1 [Shared Profile Components] > [Operations Manager] を選択し、編集する Operations Manager ロールをクリックします。

ステップ 2 独自のビジネス ワークフローやニーズに合せて任意の Operations Manager タスクを選択または選択解除します。

ステップ 3 [Submit] をクリックします。


 

デバイスベース フィルタリング

すべての Operations Manager 画面へのアクセスを制限するように ACS を設定できます。デバイスおよびアプリケーションへのアクセスを制限するように ACS を設定することもできます。デバイスベースおよびアプリケーションベースのフィルタリングは、次のものに影響を及ぼします。

デバイス:デバイスに関する情報の表示、デバイスの設定、およびデバイスに関連する診断テストの設定を行うには、そのデバイスにアクセスできる必要があります。

電話機:電話機に関する情報を表示するには、その電話機に接続されているスイッチ、またはその電話機が登録されている Cisco Unified Communications Manager にアクセスできる必要があります。


) ACS は、VLAN に対するフィルタリングを実行しません。



) デバイスベース フィルタリングは、Cisco Unified Communications Manager クラスタ レベルで実行されません。すべてのユーザが、クラスタレベルのアラートおよび Alert History を表示できます。


デバイスベース フィルタリングは、次の Operations Manager 画面に対してだけ実行できます。

Monitoring Dashboards :すべての画面

Diagnostics :すべての画面

Device Management :すべての画面


) ユーザがインベントリ収集プロセスを起動すると、(そのユーザがアクセスできるデバイスだけでなく)Operations Manager によって管理されているすべてのデバイスが調査されます。


[Notifications] > [Notification Criteria]


) ACS でデバイス アクセスをアップデートしても、Operations Manager は実行中の通知をアップデートしません。


Reports

Alert and Event History :すべての画面

Service Quality History :すべての画面

[Administration] > [Polling and Thresholds]


) Polling Parameters Summary ページと Thresholds Parameters Summary ページだけがフィルタリングされます。


ほとんどの Operations Manager タスクはデバイス中心です。Operations Manager タスクの実行時に表示されるデバイスは、Cisco Secure ACS に定義されているロールおよび関連付けられている特権に基づきます。


) ACS のカスタム ロールが DCR およびデバイスベース フィルタリングに及ぼす影響に関する重要な情報については、Common Services のオンライン ヘルプを参照してください。


ACS モードの CiscoWorks ローカル モードへの変更

ACS を使用して設定されているシステムを CiscoWorks ローカル モードへ変更したい場合、次の手順を実行する必要があります。


注意 メンテナンスを実行する場合、OMHealthMonitor Windows Service を手動で停止する必要があります。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。


ステップ 1 次のコマンドを入力して CiscoWorks デーモン マネージャを停止します。

net stop CRMDmgtd
 

ステップ 2 Operations Manager のインストール ディレクトリ(デフォルトは C:¥PROGRA~1¥CSCOpx)へ移動します。

ステップ 3 bin ディレクトリへ移動します。

ステップ 4 次のコマンドを実行します。

perl ResetLoginModule.pl
 

次のメッセージが表示されます。

Changing mode from ACS to CMF.... Please restart the Daemon Manager for changes to take effect.
 

ステップ 5 次のコマンドを入力して CiscoWorks デーモン マネージャを再起動します。

net start CRMDmgtd
 

システムは非 ACS モードである必要があります。


 

自己署名セキュリティ証明書の年次作成

Operations Manager をインストールすると、Operations Manager によってサーバ上に自己署名セキュリティ証明書が作成されます。クライアント システムの中には、ユーザが証明書をインストールする必要があるものもあります。「Security Alerts への応答」を参照してください。自己署名セキュリティ証明書は、作成日から 1 年で期限切れになります。

毎年、自己署名セキュリティ証明書が期限切れになる前に、新しい証明書を作成してください。証明書が期限切れになった後でも、新しい証明書を作成できます。ただし、次のタスクを完了するまで、ユーザが Operations Manager にアクセスできないことがあります。


ステップ 1 [Common Services] > [Server] > [Admin] > [Security Management] > [Create Self Signed Certificates] を選択します。Create Certificates ページが表示されます。

ステップ 2 次の表に示すフィールドに値を入力します。

 

フィールド
説明
使用方法

Country Name

国の名前

2 文字の国番号を使用します。

State or Province

州または地域の名前

2 文字の州コードまたは地域コード、あるいは州または地域の完全な名前を使用します。

Locality

市または町の名前

2 文字の市コードまたは町コード、あるいは市または町の完全な名前を使用します。

Organization Name

組織の名前

組織の完全な名前または省略形を使用します。

Organization Unit Name

組織内の部署の名前

部署の完全な名前または省略形を使用します。

Host Name

Operations Manager がインストールされているサーバの名前

サーバの DNS 名を使用します。

(注) 正しいドメイン名を使用してください。これは、[Host Name] フィールドにすでに表示されています。

Email Address

自分の電子メール アドレス

--

ステップ 3 [Submit] をクリックします。または、[Restore to Default] をクリックしてすべてのフィールドをクリアし、情報を再入力します。


 

Operations Manager データのバックアップと復元

Operations Manager を完全にバックアップおよび復元するには、次の両方の手続きを実行する必要があります。

「Operations Manager ユーティリティを使用した Detailed Device View 設定のバックアップと復元」

「CiscoWorks を使用したバックアップと復元」

Operations Manager 2.2 データベースが 10 GB を超える場合、インストールまたはアップグレード前にアンロードおよびリロードする必要がある場合があります。実行手順の詳細については、「Operations Manager 2.0.2 のインストール前の Sybase データベースの問題への対応」を参照してください。

データベースのバックアップと復元は、同じバージョンの Operations Manager(すべての Operations Manager モジュールのユーザ設定データおよびデータベースを含む)でだけサポートされます。

インストールまたはアップグレードのバックアップと復元の追加情報については、『Installation Guide for Cisco Unified Operations Manager』を参照してください。既知の問題の詳細については、Cisco.com のオンライン リリース ノートを参照してください。

Operations Manager ユーティリティを使用した Detailed Device View 設定のバックアップと復元

バックアップ ユーティリティは、Detailed Device View(DDV)で監視または一部監視されていたすべてのタイプのデバイスのすべてのコンポーネント(次のものを除く)の状態のバックアップを行います。一時停止中のデバイスは含まれません。データベースのバックアップと復元は、同じバージョンの Operations Manager(すべての Operations Manager モジュールのユーザ設定データおよびデータベースを含む)でだけサポートされます。


) Operations Manager は、Cisco Unified Communications Manager マシンに対する音声サービス、システム プロセッサ、ハードディスク、仮想メモリ、および RAM コンポーネントに関する DDV 設定を復元しません。Operations Manager は上記コンポーネントを作成するのにデバイス MIB ポーリングではなく、RTMT ポーリングを使用します。したがって、Operations Manager 2.0.3 から 2.2 へアップグレードする場合、2.2 では Operations Manager DDV の上記データを表示しません。



注意 データ バックアップを可能にするため、このシステムのデーモン プロセスが実行中であることを確認してください。

復元ユーティリティは、Detailed Device View の一時停止中でないデバイスの管理状態を復元します。


ステップ 1 バックアップ ユーティリティを実行するには、DOS プロンプトを開いて次のように入力します。

% PROGRA~1\CSCOpx\objects\vhm\utilities\inventoryBackup default

ここで default は、すべての監視または一部監視されているデバイスの管理状態を inventoryBackup ファイルへ保存します。スクリプト実行中は、ユーザ入力は必要ありません。


注意 ネットワーク デバイスのバックアップはサポートされていません。CLI が機能している場合でも、ネットワークの接続性の問題のため、その使用は推奨されません。結果的に、サーバにマップされたネットワーク ドライブは、ドライブ選択のユーザ インターフェイスからは見られません。

特定のファイル名やリスト固定のデバイス IP アドレスを入力する場合、次のように入力します。

% PROGRA~1\CSCOpx\objects\vhm\utilities\inventoryBackup

スクリプトによって、ファイル名およびデバイス情報を入力するように求められます。


注意 Operations Manager 2.2 のアップグレード後、Operations Manager Device Management インターフェイスからすべてのデバイスを再検出した後にだけ、inventoryRestore スクリプトを実行できます。デバイス再検出の間、システムは高負荷状態となるため、ユーザ インターフェイスの反応が遅くなる場合があります。この間、ダッシュボードはリフレッシュされない可能性があります。デバイス検出が完了するまで、ユーザ インターフェイスの処理を待機するようお勧めします。

ステップ 2 復元ユーティリティを実行するには、DOS プロンプトを開いて次のように入力します。

% PROGRA~1\CSCOpx\objects\vhm\utilities\inventoryRestore default

ここで default は、inventoryBackup.xml ファイルに保存されたデータを復元します。スクリプト実行中は、ユーザ入力は必要ありません。

独自のファイル名を入力する場合、次のように入力します。

% PROGRA~1\CSCOpx\objects\vhm\utilities\inventoryRestore

スクリプトによって、以前にバックアップ ユーティリティを使用して作成したファイル名を入力するように求められます。


 

CiscoWorks を使用したバックアップと復元

ここでは、バックアップ アプリケーション(Back Up Data Now や Schedule Backup など)にアクセスする方法について説明します。また、オンライン ヘルプでデータの復元手順を見つける方法についても説明します。

この手順は、Common Services および Operations Manager のデータベースのバックアップを行います。次のものはバックアップされません。

Detailed Device View(DDV)のコンポーネントの状態:「Operations Manager ユーティリティを使用した Detailed Device View 設定のバックアップと復元」を使用してバックアップを行う必要があります。

Service Monitor のデータベース:Service Monitor データベースは手動でバックアップを行う必要があります。『User Guide for Cisco Unified Service Monitor』を参照してください。


注意 ネットワーク デバイスのバックアップはサポートされていません。CLI が機能している場合でも、ネットワークの接続性の問題のため、その使用は推奨されません。結果的に、サーバにマップされたネットワーク ドライブは、ドライブ選択のユーザ インターフェイスからは見られません。


ステップ 1 Operations Manager ホームページで、ウィンドウの右上隅にある [CiscoWorks] をクリックします。CiscoWorks ホームページが開きます。

ステップ 2 [Common Services] の下で、[Server] > [Admin] > [Backup] を選択します。Backup Job ページが表示されます。

ステップ 3 [Help] ボタンをクリックし、データのバックアップ手順および復元手順に従います。


 

データベース ファイルは、 表 20-6 に示しているバックアップ ディレクトリ構造を使用して格納されます。

形式:/generation_number/suite/directory/filename

例:/1/itemFh/database/itemFh.db

 

表 20-6 Operations Manager のバックアップ ディレクトリ構造

オプション
説明
使用方法

generationNumber

バックアップ番号

たとえば、1、2、3(3 が最新のデータベース バックアップ)。

suite

アプリケーション、機能、またはモジュール

バックアップを実行すると、すべてのスイートのデータがバックアップされます。CiscoWorks サーバ スイートは cmf です。Operations Manager アプリケーション スイートは、次のとおりです。

dfm:IP インフラストラクチャ内のデバイスのデータ収集および分析

itemEpm:イベント公表

itemFh:Alert history

itemInv:デバイス インベントリ

itemIPIU:IP 電話情報

vhm:音声対応デバイスのデータ収集および分析

wpu:Node-to-Node tests.

directory

何が格納されているか

一覧表示されている各アプリケーションまたはスイート。ディレクトリには、データベースおよび任意のスイート アプリケーションが含まれます。

filename

バックアップされたファイル

ファイルには、データベース(.db)、ログ(.log)、バージョン(DbVersion.txt)、マニフェスト(.txt)、tar(.tar)、およびデータ ファイル(datafiles.txt)が含まれます。

Operations Manager 2.0.2 のインストール前の Sybase データベースの問題への対応

Operations Manager 2.2 データベースが 10 GB を超える場合、インストールまたはアップグレード前にアンロードおよびリロードする必要がある場合があります。データベースが破損、検証に失敗、または肥大化する(10 GB 以上でバックアップ手続きに長時間かかる)という、Sybase データベースの障害の問題が存在します。データベースがこのような問題を示す場合、データベースをアンロードおよびリロードするため次の手順を使用します。この手順を実行するには、データベースのパスワードが必要です。データベースのパスワードが不明な場合、カスタマー サポートに連絡してください。


注意 メンテナンスを実行する場合、OMHealthMonitor Windows Service を手動で停止する必要があります。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。


ステップ 1 デーモン マネージャを停止します。

%net stop crmdmgtd


ヒント すべてのデータベース プロセスが実行停止するまで待機してください。プロセス探索ツール使用して、dbeng9 または dbsrv9 プロセスの実行を確認できます。


ステップ 2 データベースをアンロードします。

%dbunload -c "uid=<username>;pwd=<pwd>;dbf=<db name>" <Directory to unload data >

次の例を参考にしてください。

%dbunload -c "uid=itemFhUser;pwd=<pwd>;dbf=itemFh.db" c:¥unload
 

ステップ 3 itemFh.db を別のディレクトリへ移動して保存します。

ステップ 4 新しいデータベースを初期化します。

%dbinit -p 4096 itemFh.db

ステップ 5 新しいデータベースをリロードします。

%dbisqlc -c "uid=<default username;pwd=<default passwd>;dbf=<db name>" reload.sql

次の例を参考にしてください。

%dbisqlc -c "uid=dba;pwd=sql;dbf=itemFh.db" reload.sql
 

ステップ 6 新しく作成された *.DAT および *.SQL ファイルを削除し、デーモン マネージャを再起動します。

%rm *.dat *.sql
net start crmdmgtd
 


 

Operations Manager プロセスの起動と停止


) 実行中の従属プロセスを持つプロセスは、停止することも登録解除することもできません。まず、すべての従属プロセスを停止または登録解除してから、プロセスを停止または登録解除する必要があります。



ステップ 1 システム管理者として Operations Manager にログインします。

ステップ 2 Operations Manager ホームページで、ウィンドウの右上隅にある [CiscoWorks] をクリックします。CiscoWorks ホームページが開きます。

ステップ 3 [Common Services] の下で、[Server] > [Admin] > [Processes] を選択します。[Process Management] ページが表示されます。


) プロセスが表示されない場合、そのプロセスはまだ起動されていません。


ステップ 4 次のどちらかを実行します。

実行しているプロセスの横にあるチェックボックスをオンにして、[Stop] をクリックします。

停止しているプロセスの横にあるチェックボックスをオンにして、[Start] をクリックします。


 

表 20-7 は、Operations Manager 関連の CiscoWorks プロセスの完全なリストを示しています。

 

表 20-7 Operations Manager 関連の CiscoWorks プロセス

名前
説明
依存関係

AdapterServer

イベント アダプタがバックエンド サーバからイベントを取得します。

なし

DataPurge

データベースおよびデータ ファイルのパージング。

jrm

DfmBroker

DFM Broker は、VHM および DFM のドメイン マネージャに関するレジストリを保守します。ドメイン マネージャは、その初期化が完了するときに、次の情報をブローカに登録します。

ドメイン マネージャのアプリケーション名

ドメイン マネージャが動作しているホスト名

HTTP サーバがリッスンしている TCP ポート

クライアントは、ドメイン マネージャにアクセスする必要がある場合、まずブローカに接続して、ホスト名、およびそのサーバの HTTP サービスがリッスンしている TCP ポートを調べます。次に、ブローカから接続解除し、ドメイン マネージャへの接続を確立します。

なし

DfmServer

インフラストラクチャ デバイス ドメイン マネージャ、つまり Operations Manager にバックエンド サービスを提供するプログラム。サービスには、SNMP データの取得やイベント分析が含まれます。DfmServer ログは NMSROOT /Unified Communications s/smarts/logs/DFM.log です。詳細については、「DFM ログ ファイルの保持」を参照してください。

DfmBroker

EPMDbEngine

Event Promulgation Module(EPM)データベース エンジン:EPM モジュールのリポジトリ。

なし

EPMDbMonitor

EPM データベース モニタ。

EPMDbEngine

EPMServer

通知サービスにイベントを送信します。

EPMDbEngine

FHDbEngine

Alert History データベース エンジン:アラートとイベントのリポジトリ。

なし

FHDbMonitor

Alert History データベース モニタ。

FHDbEngine

FHPurgeTask

Alert History パージ タスク。

なし

FHServer

Alert History サーバ。

FHDbMonitor、FHDbEngine、EPMDbEngine、EPMServer

GPFgpf

パフォーマンスおよびキャパシティのモニタリング データの収集。

ITMOGSServer、INVDbEngine

GpfPurgeTask

パフォーマンス ポーリング レコードをパージします。

なし

INVDbEngine

デバイス インベントリ データベース エンジン。

なし

INVDbMonitor

デバイス インベントリ データベース モニタ。

INVDbEngine

InventoryCollector

電話インベントリ コレクタ。

EssMonitor

IPCDiscovery

物理デバイスのディスカバリ。

なし

IPIUDataServer

IP 電話に関する情報を提供します。

ESS

IPIUDbEngine

電話インベントリ データベース エンジン。

なし

IPIUDbMonitor

電話インベントリ データベース モニタ。

IPIUDbEngine

IPSLAPurgeTask

ノード間テストのレコードをパージします。

なし

IPSLAServer

ノード間テストのサーバ。

INVDbMonitor、InventoryCollector

ITMCTMStartup

内部通信プロセス。

なし

ITMDiagServer

診断サーバ。

INVDbEngine、ESS

ITMOGSServer

Operations Manager Object Grouping Service サーバが、グループ メンバシップを評価します。

CmfDbEngine、ESS、DCRServer

IVRivr

内部プロセス。

なし

NOTSServer

通知サーバがアラートを監視し、登録に基づいて通知を送信します。

EPMDbEngine、
EPMServer、
INVDbEngine、
ITMOGSServer

OMHealthMonitor

Operations Manager プロセスを監視し、それらが予期せずシャットダウンした、またはメモリ不足で不安定な状態の場合、プロセスを再起動します。プロセスがメモリ不足の場合、ログはバックアップが行われ、プロセスは再起動されます。

なし、システムのメンテナンスまたはデバッグを実行する際にシャットダウンする必要がある場合を除く。

PIFServer

電話機のディスカバリ、CDP 近隣探索、および電話到達可能性のモニタリングを実行します。

PIFDbEngine、ESS

PTMServer

ポーリングとしきい値のサーバ。

ITMOGSServer

QoVMServer

Service Monitor サーバ。

ESS

QOVRqovr

Service Quality Alerts プロセス。

QOVRDbMonitor

QOVRDbEngine

Service Monitor データベース エンジン。

なし

QOVRDbMonitor

Service Monitor データベース モニタ。

QOVRDbEngine

QOVRMultiProcLogger

Service Monitor ロギング。

なし

SDRPurgeTask

自己診断レポートをパージします。

なし

SIRServer

音声モデルおよびルールベース エンジン。

EPMDbEngine、ESS

SRSTServer

SRST テストを設定および実行します。

PIFServer、PMServer、ESS、TISServer

STServer

Cisco Unified Communications Manager に対して定期的に模擬テストを実行し、Operations Manager にリアルタイムのステータス アップデートを提供します。

INVDbEngine、ESS

TISServer

インベントリ サーバ。

INVDbEngine、EssMonitor

TopoServer

Service Level View サーバ。

SIRServer、ITMOGSServer

VHMIntegrator

音声データとインフラストラクチャ データを統合します。

ESS

VHMServer

音声データを保持します。

DfmBroker

VsmServer

ビューを保持し、評価します。

ITMOGSServer

ログ ファイルの保持

ログ ファイルを保持するには、次を含むいくつかの方法があります。

「DFM ログ ファイルの保持」

「CSCOPX\log のログ ファイルの保持」


注意 メンテナンスを実行する場合、OMHealthMonitor Windows Service を手動で停止する必要があります。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。

DFM ログ ファイルの保持

DFM.log ログ ファイルが 30 MB を超えると、Operations Manager にパフォーマンスの問題が生じる恐れがあります。そのような問題を避けるため、ログ ファイルをバックアップして、新しいログ ファイルを開始する必要があります。


注意 メンテナンスを実行する場合、OMHealthMonitor Windows Service を手動で停止する必要があります。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。


ステップ 1 次のコマンドを入力して CiscoWorks デーモン マネージャを停止します。

net stop CRMDmgtd
 

ステップ 2 DFM.log ファイルの名前を変更するか、または DFM.log ファイルを別の場所にコピーして Operations Manager サーバから削除します。DFM.log ファイルは、 NMSROOT /Unified Communications s/smarts/logs/ ディレクトリにあります。


) NMSROOT は、Operations Manager がインストールされているサーバ上のフォルダです。インストール時にデフォルト ディレクトリを選択した場合は C:¥Program Files¥CSCOpx または C:¥PROGRA~1¥CSCOpx になります。


ステップ 3 ステップ 1 を完了してから 15 分待ち、次のコマンドを入力して CiscoWorks デーモン マネージャを再起動します。

net start CRMDmgtd
 

新しい DFM.log ファイルが作成されます。


 

CSCOPX\log のログ ファイルの保持

ほとんどのプロセス ログ(通常 CSCOPx\log\*.log のファイル)は自動循環ではありません。いくつかのファイルは自動循環の場合があります。表 20-5 「モジュール別の Operations Manager ログ ファイル」 には、どのログ ファイルが循環されるかに関する情報が含まれています。

自動的に循環されないログ ファイルの保持方法の詳細については、『User Guide for CiscoWorks Common Services』の「Configuring Log Files Rotation」を参照してください。


注意 メンテナンスを実行する場合、OMHealthMonitor Windows Service を手動で停止する必要があります。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。

ソフトウェア バージョンまたはライセンス情報の表示

Operations Manager のソフトウェア バージョンを表示するには、Operations Manager ユーザ インターフェイスの右上隅の [About] ボタンをクリックします。このウィンドウは、いくらかのライセンスおよび著作権情報も表示しています。

CiscoWorks Common Services からのソフトウェア バージョン情報を表示するには、Operations Manager ユーザ インターフェイスの右上隅の [CiscoWorks] ボタンをクリックします。[Common Services] > [Software Center] > [Software Update] を選択します。[Products Installed] の下に Operations Manager ライセンス バージョンを表示します。

CiscoWorks Common Services からのライセンス情報を表示するには、Operations Manager ユーザ インターフェイスの右上隅の [CiscoWorks] ボタンをクリックします。[Common Services] > [Server] > [Admin] > [Processes] を選択します。


) License Information ページは、サポートされるバージョンとして 2.0 を表示します。ライセンス バージョンとソフトウェア バージョンは、同じである必要はありません。Operations Manager 2.0 ライセンスは、2.2 もサポートします。


インストールされている Operations Manager(または Service Monitor)のビルド ID の検出

時折トラブルシューティングのため、どのバージョンの Operations Manager または Service Monitor がインストールされているかを知る必要がある場合があります。次のようにしてビルド ID を検出できます。

1. Operations Manager ホームページの右上隅の [CiscoWorks] をクリックします。新しいウィンドウが開きます。

2. [Common Services] の下の [Software Center] > [Software Update] を選択します。新しいウィンドウが開きます。

3. [Products Installed] の下の適切なリンク([Cisco Unified Operations Manager n.n] または [Cisco Unified Service Monitor n.n]、ここで「n.n」はソフトウェアのリリース番号です)をクリックします。新しいウィンドウが開きます。

4. ページ上部の「Build Id」ラベルの値を参照します。例:Build Id: NT_OM22CS32_20090930_1223


) NT_OM22CS32_20090930_1223 は、ビルド ID 形式を示す例です。


Operations Manager を監視するための SNMP の使用

Operations Manager は、ホスト リソース MIB とシステム アプリケーション MIB をサポートしています。このサポートにより、サードパーティ製の SNMP 管理ツールを使用して Operations Manager を監視できます。したがって、次のことが可能になります。

複数のプラットフォーム(Operations Manager が存在する 1 つのプラットフォーム、および IP Telephony Environment Monitor(ITEM)スイートのアプリケーションが存在する 1 つまたは複数のプラットフォーム)を常に監視する。

ホスト リソース MIB を使用して、完全なハードウェア情報およびオペレーティング システム情報にアクセスする。

システム アプリケーション MIB を使用して、アプリケーションの状態にアクセスする。これにより、次の情報が提供されます。

Operations Manager によってインストールされたアプリケーション。

アプリケーションに関連付けられているプロセス、およびプロセスの現在のステータス。

以前に実行したプロセス、およびアプリケーションの終了状態。

MIB 実装の詳細および MIB ウォークのサンプルについては、 付録 I「Operations Manager による SNMP MIB サポート」 を参照してください。


) MIB サポートをアンインストールできません。ただし、Windows SNMP サービスを停止して、スタートアップの種類を Manual または Disabled に設定できます。「Windows SNMP サービスのイネーブル化とディセーブル化」 を参照してください。


 

このトピックには、次の事項が含まれます。

「SNMP 照会用のシステムの設定」

「SNMP 照会用のセキュリティの設定」

「システム アプリケーション MIB のログ ファイルの表示」

SNMP 照会用のシステムの設定

Operations Manager のインストールによって、サーバ上に SNMP サービスがインストールされ、イネーブルになります。メディア サーバ上の SNMP サービス コミュニティ ストリング権限を設定するには、 「メディア サーバの SNMP サービス コミュニティ ストリング権限の設定」 を参照してください。

このトピックには、次の事項が含まれます。

「Windows SNMP サービスのステータスの確認」

「Windows SNMP サービスのインストールとアンインストール」

「Windows SNMP サービスのイネーブル化とディセーブル化」

Windows SNMP サービスのステータスの確認

Windows SNMP サービスは、必要に応じて追加または削除できる Windows コンポーネントです。Operations Manager によってサポートされている MIB に対する SNMP 照会をイネーブルにするには、SNMP サービスがインストールされてイネーブルである必要があります。次の手順に従って、Windows SNMP サービスのステータスを確認できます。


ステップ 1 Windows 管理ツールの [Services] ウィンドウを開きます。

ステップ 2 次の点を確認します。

Windows 管理ツールの [Services] ウィンドウに [SNMP Service] が表示される。その場合は、Windows SNMP サービスがインストールされています。


) Windows SNMP サービスをインストールする方法については、「Windows SNMP サービスのインストールとアンインストール」を参照してください。


SNMP Service のスタートアップの種類が [Automatic] または [Manual] である。その場合は、Windows SNMP サービスがイネーブルになっています。


) Windows SNMP サービスをイネーブルにする方法については、「Windows SNMP サービスのイネーブル化とディセーブル化」を参照してください。



 

Windows SNMP サービスのインストールとアンインストール

Windows のオンライン ヘルプに、Windows SNMP サービスなどの Windows コンポーネントを追加および削除する手順が記載されています。その手順を見つけるには、Windows のオンライン ヘルプで [Index] タブを選択し、 installing SNMP service などのキーワードまたはフレーズを入力します。

Windows SNMP サービスをアンインストールするには、Windows ヘルプを参照し、Windows コンポーネントを削除する手順に従います。


) Operations Manager がインストールされているサーバから Windows SNMP サービスをアンインストールすると、ホスト リソース MIB およびシステム アプリケーション MIB のサポートも削除されます。サポートを再びインストールする場合は、「SNMP 照会用のシステムの設定」 を参照してください。


Windows SNMP サービスのイネーブル化とディセーブル化

Windows 管理ツールの Services を使用して、Windows SNMP サービスをイネーブルまたはディセーブルにできます。[Services] ウィンドウを開く方法については、Windows のオンライン ヘルプを参照してください。


ステップ 1 [Services] ウィンドウで [SNMP Service] を確認します。ステータスとスタートアップの種類が表示されています。


) [SNMP Service] が表示されていない場合、Windows SNMP サービスはインストールされていません。「Windows SNMP サービスのインストールとアンインストール」を参照してください。


ステップ 2 [SNMP Service] を右クリックして [Properties] を選択します。[SNMP Service Properties] ウィンドウが開きます。

SNMP サービスをディセーブルにするには、[Startup Type] を [Disable] に設定し、[OK] をクリックします。

SNMP サービスをイネーブルにするには、[Startup Type] を [Automatic] または [Manual] に設定し、[OK] をクリックします。


) イネーブルにした後に SNMP サービスを開始するには、[SNMP Service] を右クリックし、[Start] を選択してください。



 

SNMP 照会用のセキュリティの設定

セキュリティを向上させるため、どのオブジェクト ID(OID)でも SNMP set 操作は許可されていません。また、SNMP サービスのクレデンシャルを編集して、デフォルトのコミュニティ ストリングやよく知られているコミュニティ ストリングを使用しないようにする必要があります。


) SNMP サービスのクレデンシャルを編集するために SNMP サービスを再開する必要はありません。


Windows 管理ツールの [Services] を使用して、SNMP サービスのクレデンシャルを編集できます。


ステップ 1 [Services] ウィンドウで [SNMP Service] を確認します。

ステップ 2 [SNMP Service] を右クリックして [Properties] を選択します。[SNMP Service Properties] ウィンドウが開きます。

ステップ 3 [Security] タブを選択します。

ステップ 4 受け付けるコミュニティ名を編集し、[OK] をクリックします。


 

システム アプリケーション MIB のログ ファイルの表示

システム アプリケーション MIB のログ ファイル SysAppl.log は、Operations Manager がインストールされているサーバ上の NMSROOT/ log にあります。


) NMSROOT は、Operations Manager がインストールされているシステム上のディレクトリです。インストール時にデフォルト ディレクトリを選択した場合は C:¥Program Files¥CSCOpx または C:¥PROGRA~1¥CSCOpx になります。


Operations Manager サーバのホスト名の変更

Operations Manager サーバのホスト名を変更する場合は、いくつかのファイルをアップデートし、サーバをリブートし、自己署名セキュリティ証明書を再生成する必要があります。その後、ライセンスされている Service Monitor を保有している場合は、その設定をアップデートする必要があります。


注意 メンテナンスを実行する場合、OMHealthMonitor Windows Service を手動で停止する必要があります。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。


ステップ 1 cmf データベースのパスワードがわからない場合は、次の手順に従ってパスワードを再設定します。

a. コマンド プロンプトを開き、NMSROOT\bin に移動します。

b. 次のコマンドを入力します。

perl dbpasswd.pl dsn=cmf npwd=newpassword
 

ここで、newpassword は新しいパスワードです。


) このパスワードを覚えておいてください。ステップ 8 でこのパスワードが必要になります。


ステップ 2 次の手順に従って、サーバのホスト名を変更します。

a. [My Computer] > [Properties] > [Computer Name] > [Change] でホスト名を変更します。

デーモン マネージャ サービスがリブート後に再起動するのを防ぎます。[Control Panel] または [Start] から [Services] を開き、[CW2000 Daemon Manager] サービスのスタートアップ モードを [Manual] に変更します。

b. サーバをリブートします。

ステップ 3 md.properties ファイル( NMSROOT \lib\classpath\md.properties)でホスト名を変更します。


) NMSROOT は Operations Manager をインストールしたディレクトリです。デフォルトを選択した場合、C:¥Program Files¥CSCOpx または C:¥PROGRA~1¥CSCOpx になります。


ステップ 4 次のレジストリ エントリでホスト名を変更します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\Resource Manager


) これらのレジストリ エントリの下で古いホスト名のインスタンスをすべて検索し、それらを新規ホスト名に置き換えてください。


ステップ 5 次の各ファイルでホスト名を変更します。

regdaemon.xml(NMSROOT\MDC\etc\regdaemon.xml)

古いホスト名を書き留めます。ステップ 6 でこのパスワードが必要になります。

大文字で新しいホスト名を入力します。

web.xml(NMSROOT\MDC\tomcat\webapps\classic\WEB-INF\web.xml)

ステップ 6 ファイル NMSROOT\conf\cmic\changehostname.info を作成します。このファイルには、次の形式で古いホスト名と新しいホスト名を大文字で入力します。

OLDHOSTNAME:NEWHOSTNAME
 

) このファイル内のホスト名は大文字と小文字が区別されます。ホスト名は大文字で入力する必要があります。新しいホスト名は、regdaemon.xml に入力したホスト名と正確に一致する必要があります。


ステップ 7 次の各ファイルで古いホスト名をすべて変更します。

NMSROOT\objects\vhmsmarts\local\conf\runcmd_env.sh

NMSROOT \conf\dfm\Broker.info

ステップ 8 ホスト名の変更前に追加されたデバイスが Device Center で正しく分類されることを保証するために、次のコマンドを入力します。

dbisqlc -c "uid=cmfDBA;pwd=dbpassword;eng=cmfEng;dsn=cmf;dbf=NMSROOT\databases\cmf\cmf.db" -q update PIDM_app_device_map SET app_hostname='NewhostName' where app_hostname='OldhostName'
 
 

それぞれの説明は次のとおりです。

dbpassword は Common Services のデータベースのパスワードです。

NMSROOT は Operations Manager をインストールしたディレクトリです。

NewhostName は新しいホスト名です。

OldhostName は古いホスト名です。

ステップ 9 [Control Panel] または [Start] から [Services] を開き、[CW2000 Daemon Manager] サービスのスタートアップ モードを [Automatic] に変更します。

ステップ 10 サーバをリブートします。

ステップ 11 自己署名セキュリティ証明書の古いホスト名を新しいホスト名に置き換え、再生成します。

a. [Common Services] > [Server] > [Security] > [Certificate Setup] を選択します。

a. 詳細については、[Help] をクリックしてください。

ステップ 12 Service Monitor のライセンスを持っている場合は、そのライセンスを再設定します。

a. Service Monitor ホームページを開きます (「Service Monitor の起動」を参照)。

b. [Help] をクリックし、「 Reconfiguring Service Monitor after a Hostname Change 」というトピックに記載されている手順に従います。


 


) Service Monitor のオンライン ヘルプには、次のタスクを実行するための詳細な手順が記載されています。

次の各コンフィギュレーション ファイルで IP アドレスまたはホスト名を変更する。

デフォルトのコンフィギュレーション ファイル

Service Monitor によって管理されている各 Cisco 1040 の特定のコンフィギュレーション ファイル

アップデートしたコンフィギュレーション ファイルを Service Monitor サーバから TFTP サーバにコピーする。

Cisco 1040 をリセットする。

Operations Manager にトラップを送信するよう Service Monitor が設定されている場合:

Operations Manager が Service Monitor と同じサーバにインストールされている場合は、新しいホスト名または IP アドレスにトラップを送信するよう Service Monitor を設定する。

Operations Manager が別のサーバにインストールされている場合は、Operations Manager で Service Monitor を削除してから再び追加する。


 

Operations Manager サーバの IP アドレスの変更


注意 メンテナンスを実行する場合、OMHealthMonitor Windows Service を手動で停止する必要があります。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。

Operations Manager サーバの IP アドレスを変更するには次の手順を実行します。


ステップ 1 次のコマンドを入力して CiscoWorks デーモン マネージャを停止します。

net stop CRMDmgtd
 

ステップ 2 Operations Manager サーバの IP アドレスを変更します。

ステップ 3 ステップ 1 を完了してから 15 分待ち、次のコマンドを入力して CiscoWorks デーモン マネージャを再起動します。

net start CRMDmgtd


 

Operations Manager プロセス状態の監視

OMHealthMonitor は、Operations Manager プロセスを監視し、それらが予期せずシャットダウンした、またはメモリ不足で不安定な状態の場合、プロセスを再起動する Windows サービスです。プロセスがメモリ不足の場合、ログはバックアップが行われ、プロセスは再起動されます。これは CSCOpx\HealthMonitor ディレクトリにあります。


注意 メンテナンスまたはデバッグ タスクを実行する場合、意図的にシャットダウンされるプロセスが不意に再起動されないように、OMHealthMonitor Windows サービスは停止される必要があります。次のコマンドを実行します。

net stop OMHealthMonitor
net start OMHealthMonitor

OMHealthMonitor は次のタスクを実行します。

中断されたプロセスが再起動される前に、それらに属するログのバックアップを保存します。

ユーザによって設定されたすべてのプロセスを無視して、残りのプロセスが実行していない場合にそれらを再起動します。

Operations Manager および CiscoWorks Common Services(CWCS) プロセスだけを監視します。

CSCOpx\HealthMonitor\log にある HealthMonitor.log という名のログ ファイルに、デバッグ情報を記録します。

CSCOpx\HealthMonitor\audit にある監査ログに、再起動されたすべてのプロセスの監査情報を記録します。

監査ログが更新されると、管理者に電子メールを送ります(設定されている場合)。

HealthMonitor によるデータ保存の詳細については、 表 20-8 を参照してください。

 

表 20-8 Health Monitor ディレクトリ

ディレクトリ名
内容

Audit

監査ファイル HealthMonitor.audit が含まれます。

Backup

再起動されたプロセスのバックアップ ログ ファイルが含まれます。

Conf

必要なコンフィギュレーション ファイルが含まれます。

\log

デバッグ ログ ファイル HealthMonitor.log が含まれます。

scripts

HealthMonitor.pl Perl スクリプトおよびモジュールが含まれます。

Health Monitor コンフィギュレーション ファイルの編集

Health Monitor には、ログ マッピング ファイル、特定の設定可能なパラメータ、ロギング、およびプロセスの再試行カウント状態を設定できるようにする、いくつかのコンフィギュレーション ファイルが含まれます。

Health Monitor の動作を変更するには、次の手順を実行します。


ステップ 1 電子メール関連のパラメータを追加または設定可能な設定を変更するには、CSCOpx\conf ディレクトリの次のファイル( 表 20-9 を参照)にアクセスします。

表 20-9 Health Monitor コンフィギュレーション ファイル

コンフィギュレーション ファイル名
説明

HealthMonitor.logConf

ログおよび監査関連の設定が含まれます。

RetryAttempts.txt

すべてのプロセスに対してゼロのカウントが含まれます。プロセスの開始に失敗した場合、プロセスのカウントを増やします。

ファイル内容の例は次のとおりです。

AdapterServer=0
FHServer=0
IPSLAServer=2
PIFServer=0
SRSTServer=1

Processes.cfg

監視されるプロセスおよび、予期しない障害が発生した場合に備えて各プロセスのバックアップを取るため、プロセス名のログ ファイルへのマッピングを含みます。

プロセスを無視するには、エントリをコメント アウトすると、プロセスはこのツールによって監視されません。

フォーマットの例を示します。

#ProcessName>=<Logfile1>,<Logfile2>,....
STServer=log/ama-ani.log.*, stserver.log, ct-ui.log
 

Operations Manager は、プロセスが再起動すると、このファイルに示されているログのバックアップを取ります。Operations Manager 関連の CiscoWorks プロセスのリストについては、 表 20-7 を参照してください。Health Monitor バックアップの情報については、「バックアップされたプロセス ログの表示」を参照してください。

HealthMonitor.cfg

このファイルは下記の設定可能なパラメータを含みます。

Max Retries:プロセス開始の最大試行数。

Initial_Delay:サービス開始時の初期遅延秒数。

Max Wait Time:プロセス実行を確認する最大待機秒数。

Monitoring_Frequency:監視を実行する頻度(分単位)。

Max_Backups:プロセス毎に保持する最大バックアップ数。

SMTP_Server:SMTP メール サーバのアドレス。

Receiver_Email_ID:管理者の電子メール ID。

Sender_Email_ID:送信者の識別に使用される電子メール ID。

上記電子メール関連パラメータ(SMTP_Server、Receiver _Email_ID、Sender_Email_ID)は値を含みません。監査ログの更新時に電子メール情報を受け取るには、電子メール関連パラメータに値を追加します。

ファイル内容の例は次のとおりです。

Max_Retries=3
Initial_Delay=1800
Max_Wait_time=10
Monitoring_Frequency =300
Max_Backups=3
SMTP_Server=server.domain.com
Receiver _Email_ID=admin@domain.com
Sender_Email_ID=system@cuom.com

ステップ 2 好みのエディタを使用してファイルを編集し、終了したら変更を保存します。

ステップ 3 OMHealthMonitor サービスを停止および再起動して、変更を有効にします。

net stop OMHealthMonitor
net start OMHealthMonitor


 

バックアップされたプロセス ログの表示

プロセスの再起動時、Health Monitor は Processes.cfg ファイルに示されたログのバックアップを作成します。バックアップ フォルダには各プロセスのサブディレクトリが含まれ、バックアップが作成されます。各サブディレクトリには、Max_Backups の設定で決められた zip ファイルが存在します。最も古いバックアップは、新しいバックアップを作成する必要があり、プロセスが最大限に達している場合に消去されます。zip ファイルは適宜循環されます。zip ファイルを開き、エディタを使用してログを見ることができます。

Operations Manager 再起動後に起こること

いくつかの管理タスクは、Operations Manager の再起動を必要とします。再起動後、Operations Manager のモニタリングには多くの変更が発生しています。次の項には、これらの変更がどのようにモニタリングに影響する可能性があるかに関する情報が含まれます。

デバイス管理:デバイスのステータスおよびインベントリ情報はデータベースに保存され、デーモン マネージャの再起動後に使用可能となります。

電話情報:電話情報はデータベースに格納され、再起動後に使用可能となります。たとえば、電話レポートは再起動後に使用可能となります。新しい電話検出は、Operations Manager の再起動後に開始されます。

デバイス ポーリング:新しいポーリング サイクルが開始されます。たとえば、再起動のためにデバイスの半数だけがポーリング サイクルでポーリングされ、ポーリング サイクルが途中で再開されない場合、新しいサイクルが開始します。

イベント:すでに処理されたイベントは再起動後に使用可能になります。デーモン マネージャが停止した時に発生したイベントは、ログに記録されません。

Operations Manager によって自動的にクリアされたポーリングに基づくイベントは再生成されます。これはイベントの状態がアクティブのままであっても、固定された時間間隔の後に AutoClear が生成されるためです。

デーモン マネージャが停止している間に Cleared イベントが発生する場合、イベントはユーザ インターフェイスでアクティブのままとなります。デーモン マネージャの再起動後、何かイベントが失われたと示されることはありません。問題が引き続き存在する場合、ポーリングに基づくイベントは生成されますが、トラップに基づくイベントは問題が存続しても処理されません。

Service Level View:データはデータベースに保存されません。Operations Manager の再起動後、およそ 30 分で論理検出は再起動し、Service Level View は使用可能になります。

DiagnosticTests:Operations Manager の再起動後、およそ 30 分でテストは再起動します。

パフォーマンス データ収集:ネットワーク トポロジ ビルダー(または SIRServer プロセス)は、パフォーマンス ポーリングが再起動する前に(再起動前にイネーブル化されている場合)、再起動するのにおよそ 15 分かかります(遅れはネットワークのサイズによって異なる場合あり)。