Cisco Unified Operations Manager ユーザ ガイド ソフトウェア リリース 8.6 Cisco Unified Communications Management Suite
Operations Manager の管理
Operations Manager の管理
発行日;2012/05/09 | 英語版ドキュメント(2011/08/08 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 8MB) | フィードバック

目次

Operations Manager の管理

概要: の管理タスク

のタスクのスケジュール

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

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

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

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

SNMP トラップとしての Windows イベントの転送

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

および他の CUCM アプリケーションが使用するポートとプロトコル

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

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

システム設定の更新

System Status Report の生成と説明

Common Services でのソフトウェア更新の実行

ライセンス情報の表示と更新

クラスタ トランク使用率の設定

その他のシステム設定

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

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

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

ファイルの所有権と保護

SSL

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

SNMPv3

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

デバイス サポート

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

ユーザの設定(ACS およびローカル RBAC)

ローカル RBAC モードでのユーザの設定

ローカル RBAC モードでのユーザ ロールの設定

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

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

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

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

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

バックアップ前の Sybase データベース問題の処理

DB フラグメンテーションの修正

プロセスの起動と停止

ログ ファイルの保持

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 に示しているタスクを実行できます。

ここでは、「Operations Manager のタスクのスケジュール」について説明します。

 

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

タスク
説明

Device Management

「Device Management を使用する前に」 を参照してください。

[Device Management] から、デバイス構成、インベントリ収集、および自動検出のセットアップを実行できます。次の追加タスクの詳細情報を参照してください。

デバイス設定

 

「Device Management の設定」 を参照してください。

 

[Device Configurations] から、次のタスクを実行できます。

デバイスの状態、デバイスと電話機の数、および検出設定を含むデバイス サマリー情報を表示します。

デバイスを追加、インポート、修正、削除、およびエクスポートできます。

DCR デバイス選択を使用して、Device and Credentials Repository(DCR)と Operations Manager のインベントリの同期を手動で制御します。

[IP Address Report] を表示します。

デバイス クレデンシャルを入力または修正します。

デバイス グループを作成します。

インベントリ収集

「デバイスのインベントリ収集の手動実行」 を参照してください。

[Inventory Collection] から、次のタスクを実行できます。

デバイス、IP Phone、またはクラスタの収集のためのスケジュールを作成、表示、または更新します。

追加されている XML 電話機の検出ステータスを表示するか、または電話機の検出のスケジュールを変更します。

SNMP タイムアウトとリトライ設定を編集します。

Operations Manager が Lightweight Directory Access Protocol(LDAP)に接続され、そこに保存されたユーザ情報にアクセスできるように LDAP を設定します。

自動検出の設定

「Operations Manager での Auto Discovery Configuration のセットアップ」 を参照してください。

[Auto Discovery Configuration] から、次のタスクを実行できます。

SNMP、HTTP(Cisco Unified Communications Manager でだけ必要)、および Windows(Windows ベースの MCS アプリケーション サーバでだけ必要)のクレデンシャルのセットを追加、編集、削除、および適用します。

検出のタイプ(CDP、論理クラスタの検出、または ping スイープ)を選択します。

検出を実行するかデバイスをフィルタリングするスケジュール済みの時間を選択します(含めるか含めないかの基準を使用する)。

[System Settings] の設定

「システム設定の更新」 を参照してください。

[System Settings] から、次のタスクを実行できます。

Operations Manager にシステム ステータスを表示します。「System Status Report の生成と説明」 を参照してください。

Operations Manager のライセンス情報を更新します。「Common Services でのソフトウェア更新の実行」 を参照してください。

イベントのカスタマイズを行います。「処理されるイベント」 を参照してください。

クラスタにトランク使用率を設定します。「クラスタ トランク使用率の設定」 を参照してください。

ロギングとシステム プリファレンスをセットアップします。「システム設定の更新」を参照してください。

UC Management Suite アプリケーションのセットアップ

「Cisco Unified Communications 管理アプリケーション リンクの設定」 を参照してください。

[UC Management Suite] から、他の Cisco Unified Communications Management Suite アプリケーションを起動するための Operations Manager へのリンクを設定できます。

Polling and Thresholds

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

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

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

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

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

Operations Manager、RTMT、または PhoneUnregistration/Service Quality のしきい値の設定をカスタマイズする。

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

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

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

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

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

SRST Poll Settings

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

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

SRST 操作

「SRST ポール設定のステータスの表示」を参照してください。

[SRST Poll Settings] ページから、SRST ポール設定のステータスを表示できます。

System Status

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

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

Logging

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

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

System Preferences

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

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

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

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

Resource Manager Essentials(RME)

Campus Manager(Campus)

CiscoView

SNMP トラップ コミュニティ ストリング:read コミュニティ ストリングを入力します。

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

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

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

スタティック NAT 環境:Operations Manager で、Network Address Translation(NAT; ネットワーク アドレス変換)-enabled デバイスのサポートをイネーブルにするかどうかを選択します。NAT-enabled デバイスを監視するには、このプリファレンスを設定する必要があります。

Add Users

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

[Local User Setup] ページを開く Common Services のウィンドウを起動します。これにより、管理者はユーザを追加したり、グループの特権を割り当てることができます。

Back Up and Restore

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

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

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

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

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

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

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

CDT クラスタの検出

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

[Run Now] オプションを選択することによって、手動で開始することもできます。

インベントリ収集

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

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

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

データベースのバックアップを週 1 回または月 1 回実行し、古いバックアップ ファイルを手動で削除し、別のディスクまたはサーバにバックアップを保存することを推奨します。

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

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

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

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

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

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

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

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

Operations Manager が使用するポートの詳細については、「Operations Manager および他の CUCM アプリケーションが使用するポートとプロトコル」 を参照してください。

ここでは、次の内容について説明します。

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

「Operations Manager および他の CUCM アプリケーションが使用するポートとプロトコル」

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

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

「System Status Report の生成と説明」

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

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

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

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


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


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

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

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

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

「SNMP トラップとしての Windows イベントの転送」

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

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 トラップとしての Windows イベントの転送

Windows ベースのデバイスから SNMP トラップとして転送された Windows イベントを Operations Manager で表示するには、そのイベントがフォワーダ ユーティリティ( evntwin.exe )をトラップするように設定する必要があります。Evntwin は、イベントの変換を Evntwin コンフィギュレーション ファイル内の情報に基づいたトラップに設定します。

これは、Windows SNMP サービスをインストールするとインストールされます。SNMP トラップとして転送するイベント番号を選択する必要があります。

転送するイベントを選択し、evntwin コンフィギュレーション ファイルを更新するには、次の手順に従います。


ステップ 1 [Start] > [Run] に移動し、 evntwin.exe を入力します。

[Event to Trap Translator] ウィンドウが開きます。

 

ステップ 2 [Custom] オプション ボタンを選択し、[Edit] をクリックします。

 

ステップ 3 [Event sources] ペインでイベント ソースを選択します。

ステップ 4 [Events] ペインでイベントを選択して [Add] をクリックし、ポップアップが開いたら、[OK] をクリックします。

選択されたイベントが上部ペイン [Events to be translated to traps] に表示されます。

ステップ 5 変換するすべてのイベントが選択されるまで、ステップ 4 を繰り返します。

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

ステップ 7 [Export] をクリックし、ファイルを events.cnf としてディスク上に保存します。

ステップ 8 次のコマンドを入力します。

# NMSROOT¥ evntcmd events.cnf

ここで、NMSROOT は、マシンに events.cnf を保存したパスです。


 

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 および他の CUCM アプリケーションが使用するポートとプロトコル

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

SNMPsnmp

ICMP

TCP/IP

SMTP

RMI

HTTP

XML

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


) Service Monitor、Provisioning Manager、または Service Statistics Manager が Operations Manager と同じインスタンス上で動作している場合、ポートが使用できるようにする必要があります。ポートの詳細については、これらのアプリケーションのユーザ ガイドを参照してください。


 

表 20-4 使用する Operations Manager 着信ポート

ポート番号
使用方法

80

電話機情報(Discovery によって収集されたシリアル番号やロード ID など)のための XML ベースのデータ収集

162

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

1024-4999

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

40000-41000

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

42344

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

42350-42353

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

43445-43459

Operations Manager は、次のポートをデータベース ポートとして使用します。

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

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

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

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

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

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

8080

Cisco Unified Communications Manager 5.0 Web サービスがアップ状態であるかどうかを判別するために使用される

このポートは、Operations Manager に対して使用可能にする必要があります。

9000

トラップを受信する CSListener(ポート 162 が使用中の場合は Operations Manager サーバ)

9002

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

9009

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

 

表 20-5 使用する Service Monitor ポート

ポート番号
使用方法

22

SFTP:Unified CM バージョン 5.x 以降からのデータを取得する。

53

DNS 用です。

67 および 68

CHCP 用です。

2000

SCCP:Cisco 1040 と通信する。

43459

データベース用です。

5666

Syslog:Cisco 1040 から syslog メッセージを受信する。

5665 ~ 5680

ユーザ インターフェイスとバックエンド プロセスとのプロセス間通信用です。

これらのポートは空いている必要があります。

 

表 20-6 使用する Provisioning Manager ポート

ポート番号
プロトコル
プロセス
説明
ファイアウォールで開く必要がある着信 TCP ポート

80

HTTP

Apache Web サーバ

詳細インストール プロセスで設定可能です。

5432

JDBC

PostregSQL データベース サーバ

詳細インストール プロセスで設定可能です。

(注) 分散インストール(アプリケーションとデータベースを個別のシステムに置く)を実行する場合、このポートは Provisioning Manager データベース サーバで着信通信用に開いている必要があります。これにより、Provisioning Manager アプリケーション サーバはデータベースにアクセスできます。シングル サーバ インストールの場合、このポートは外部アクセスのために開いておく必要はありません。

46443

HTTPS

Apache Web サーバ

デフォルトでこのポートは使用するように設定されていません。

SSL を設定するには、Provisioning Manager のユーザ マニュアルを参照してください。

使用する TCP ポート

46001

RMI

CUPM NICE エンジン

詳細インストール プロセスで設定可能です。

46008

HTTP

JBoss アプリケーション サーバ

詳細インストール プロセスで設定可能です。

46009

AJP

JBoss アプリケーション サーバ

デフォルトでこのポートは使用するように設定されていません。

SSL を設定するには、Provisioning Manager のユーザ マニュアルを参照してください。

46083

Web サービス

JBoss アプリケーション サーバ

-

46098

RMI

JBoss アプリケーション サーバ

-

46099

JNP Service

JBoss アプリケーション サーバ

-

46444

JRMP

JBoss アプリケーション サーバ

-

他のデバイスとの通信に使用される発信 TCP ポート

80

HTTP

ApacheWeb サーバ

Cisco Unified Communications Manager

8443

HTTPS

-

Cisco Unity Connection および Cisco Unified Communications Manager 5.0 以降

1433

JDBC

-

Cisco Unity

22

SSH

-

Cisco Unified Communications Manager Express および Cisco Unity Express

23

Telnet

-

Cisco Unified Communications Manager Express および Cisco Unity Express

8443

HTTPS

-

Cisco Unified Presence

 

表 20-7 使用する Service Statistics Manager ポート

ポート番号
使用方法

8007

Apache JServ

800

トンネル プロキシ

800

Tomcat

800

JMS サーバ

9139

JServer イベント

48099

Remote Method Invocation

Service Statistics Manager で 48099 以外のポートを使用するように設定するには、Service Statistics Manager のユーザ マニュアルを参照してください。

48100

Jboss

Service Statistics Manager で 48100 以外のポートを使用するように設定するには、Service Statistics Manager のユーザ マニュアルを参照してください。

48101

HTTP:WebServer

48102

データベース

12123

エージェント コントローラ リスナー

12124

SSM Agent が SSM サーバからのメッセージをリッスン

12125

エージェント コントローラとデータベースがやり取りするためのデータベース アクセス ポート

12126

エージェント コントローラ コールバック:データを Service Statistics Manager サーバに返送するためにリモート SSM エージェントが使用

12130

チェックポイント モニタ(ログ メッセージを受信するため)

12140

CLServer

12141

ログ サーバ

18000

レート

40402

ライセンス

45000

メッセージ サーバ

48443

HTTPS:セキュア Web サーバ

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

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

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

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

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


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


パージング スケジューラのステータスを表示するには、次の手順に従います。


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

ステップ 2 [Administration] > [Server Administration (Common Services)] > [Server] > [Job Browser] を選択します。

[Job Browser] ページが表示され、スケジュール済みジョブのテーブルが示されます。

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


 


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


システム設定の更新

次のツールを使用して、Operations Manager のシステム設定へのさまざまな更新を実行できます。

「System Status Report の生成と説明」

「ライセンス情報の表示と更新」

「通知の設定」

「クラスタ トランク使用率の設定」

「その他のシステム設定」

System Status Report の生成と説明

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

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

Failed Process Information is not available. (Unable to contact SNMP Service on Operations Manager System. Please check if Windows SNMP Service is installed and running on Operations Manager.)
 

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

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

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

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

Unable to contact SNMP Service on Operations Manager System. Please check if Windows SNMP Service is installed and running on Operations Manager.
 

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

Inventory

Data Purging

Diagnostics: Synthetic Tests


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


Diagnostics: Phone Status Tests

Diagnostics: Node-to-Node Tests

Notifications

Phone Licensing Summary:次のメッセージが表示された場合

Phone License has exceeded the system limit. 23019 phones were not managed. Please purchase a license to manage all the phones in the network.
 

[Administration] > [Server Administration (Common Services)] > [Administration] > [Licensing] の順に選択し、Operations Manager でライセンスを追加または更新します。

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 :失敗したテストのテスト名、テスト タイプ、アプリケーション インスタンス、失敗した時刻、原因

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

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

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

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

Phone Licensing Summary :ハード フォン、ソフト フォン、およびフォン全体のライセンス数。

補助的なソフト IP Phone(ハード フォンと同じ内線を共有する電話機)、Suspect Phone(スイッチに接続されているが Unified CM に登録されていない電話機)、および複数の増分回線は、ライセンス数では無視されます。

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

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

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

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

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

System Limits では、次のパラメータに対する現在(Current)の定義または制限(Limit)の定義はありません。

Synthetic Tests。

Phone Status Tests。

Node-to-Node Tests。

Devices monitored for performance and capacity。

Devices monitored for SRST。

Common Services でのソフトウェア更新の実行

このオプションを使用して、システムに現在インストールされているすべての CiscoWorks 関連のバンドルおよび製品のリストを表示できます。ソフトウェアの更新の場合、デフォルト サイトは Cisco.com です。

詳細については、[Administration] > [Software Center (Common Services)] > [Software Update] を選択し、オンライン ヘルプを表示します。

ライセンス情報の表示と更新

Operations Manager と Service Monitor の両方のライセンス ステータスを確認するには、[Administration] > [Server Administration (Common Services)] > [Administration] > [Licensing] を選択します。詳細な説明については、[Help] をクリックし、Common Services のヘルプを表示します。


) Operations Manager 8.0 ライセンスは Operations Manager 8.6 もサポートします。Service Monitor 8.0 ライセンスは、Service Monitor 2.2 もサポートしています。


クラスタ トランク使用率の設定

トランクの最大容量(最大同時コール数)およびゲートウェイの最大容量(最大チャネル数)を設定できます。特定のトランクまたはゲートウェイに最大容量を設定することも、CSV ファイルを使用してすべてのクラスタのトランク利用率設定データをインポートすることもできます。

Operations Manager を設定後、次のロケーションでトランク使用率データを使用できます。

最後の 24 時間の着信および発信使用率と Route Group 詳細ビューでの各トランクのコール量

Fault Monitor Event Details Actions リンクからの最大 72 時間のトランク使用率およびコール統計のグラフ

[Diagnostics] ビュー([Cluster View] > [UCM Cluster Route Pattern Summary] > [Utilization or Call Volume] アイコン リンク)からの特定のクラスタ デバイスのトランク使用率およびコール統計のグラフ

Operations Manager が Unified CM トランク使用率を監視できるようにするには、次のタスクも実行する必要があります。

1. Unified CM が CDR ベースのデータを転送できるように設定します。「Cisco Unified CM での CDR の転送の設定」を参照してください。

2. Service Monitor が Operations Manager とデータを共有できるようにします。「Service Monitor サーバへのアクセス」を参照してください。

3. 要求されたポーリング パラメータをイネーブルにします。「ポーリング パラメータの編集」を参照してください。

Unified CM クラスタでトランク使用率を設定し、データを収集するには、次の手順に従います。


ステップ 1 [Administration] > [Configuration] > [Trunk Utilization Configuration] を選択します。

[Trunk Utilization Configuration Service Monitor] ページが表示されます。

ステップ 2 ドロップダウンから、設定するクラスタ名を選択します。

ステップ 3 オプション ボタンをクリックし、このクラスタで次のいずれかのゲートウェイまたはトランク タイプを選択します。次のオプションがあります。

MGCP Gateway:デフォルト設定を使用して自動的に設定されます。

H.323 Gateway:自動的には設定されません。

H.225 Trunk:自動的には設定されません。

SIP Trunk:自動的には設定されません。

Inter-Cluster Trunk:自動的には設定されません。


ヒント 設定ファイルを作成する最も簡単な方法は、エクスポート機能を使用してファイルにエクスポートすることです。続いて、必要に応じてファイルのデータを変更します。すべてのゲートウェイおよびトランクがファイルに示されているため、ファイルに値を入力するだけです。

ステップ 4 トランク使用率データをすべてのクラスタにインポートまたはエクスポートするには、次の手順に従います。

a. 選択したクラスタのトランク設定をエクスポートするには、[Bulk Export] をクリックしてから、次のウィンドウで [Export] をクリックし、デフォルト名のエクスポート CSV ファイルを許可します。異なる場所にブラウズして、エクスポート ファイルを保存することもできます。

b. クラスタ トランク使用率設定データを CSV ファイルからインポートするには、[Bulk Import] をクリックしてから、[Browse] をクリックし、CSV ファイルの場所を指定します。[Import] をクリックします。

ステップ 5 [Configure Maximum Capacity] をクリックし、このクラスタに最大数のコールを設定します。

[Maximum Capacity Configuration Service Monitor] ウィンドウが表示されます。

a. [Configure Channels](または [Configure Concurrent Calls])フィールドに最大容量を入力します。

b. 設定を適用するゲートウェイまたはトランクのチェックボックスを選択します。

c. [Apply] をクリックします。

d. [Close] をクリックします。


 

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

システム プリファレンスを使用して、システム全体のパラメータを設定するには、次の手順を従います。


ステップ 1 [Administration] > [System Settings] > [Miscellaneous] > [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 および他の CUCM アプリケーションが使用するポートとプロトコル」を参照してください。

[SMTP Server] フィールド

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

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

Purging Scheduler

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

Hour:0 ~ 23

Minute:0 ~ 50(10 分間隔)

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

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

Static NAT Environment

NAT-enabled デバイスのオプションをネットワーク全体でイネーブルにします。このオプションを使用すると、NAT デバイスを Operations Manager によって監視できます。このチェックボックスが選択されていない場合、デバイスの編集と表示のページには、ローカル IP や DNS 名などの NAT 特有のデータ入力が含まれません。

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


 

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

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

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

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

ログ ファイルへのアクセスと削除。 「ログ ファイルへのアクセスと削除」 を参照してください。

[Logging Configuration] ページを表示するには、[Administration] > [System Settings] > [Miscellaneous] > [Logging] を選択します。

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

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

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


ステップ 1 [Default] ボタンをクリックします。

確認のページが表示されます。

ステップ 2 [OK] をクリックします。


 

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


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

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

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

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


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


ステップ 2 変更を確認します。

変更をキャンセルするには、[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-8 は、各 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-8 モジュール別の Operations Manager ログ ファイル

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

Application and Connectivity Poller

¥log¥cuom¥VHM

Poller.log

TISPollerLogger.log

はい

DataPurge

¥log

DataPurge.log

はい

Detaild Device View

¥log¥cuom¥DDV

DDV.log

はい

Device Pool

¥log¥cuom¥

DevicePoolServer.log

はい

Device Management

¥log¥cuom¥TIS

DCRAdapter.log

DeviceManagement.log

TISDBLog.log

TISServer.logtisserverlog

TISServer_stdout.log

TISServer_sterr.log

はい

Event Customization

¥log¥cuom¥EPM

EventCustomizationsAudit.log

はい

Events Display

¥log¥cuom¥AAD

AAD.log

はい

Event History

¥log¥cuom¥FH

FHUI.log

FHCollector.log

FHServer.log

はい

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 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

¥log

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

VICDFM.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

はい

portal

¥log¥cuom¥portal

cwportal.log

はい

Purging Scheduler

¥log¥cuom¥DPS

DPS.log

はい

SRST Monitoring

¥log¥cuom¥srst

srstgc.log

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

Topogc.log

Topology_Client.log

Topology_Server.log

はい

Service Quality Events Display

¥log¥cuom¥QOVAD

QOVAD.log

はい

Service Quality Manager

¥log¥cuom¥QoVM

QoVMServer.log

いいえ

SQTRAPS

¥log¥cuom¥SQTraps

Traps.log

はい

Synthetic Testing Server

¥log¥cuom¥

STServer.log

ama-ani.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 サービスを手動で停止してください。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。OMHealthMonitor の詳細については、「Operations Manager プロセス状態の監視」 を参照してください。

ブラウザとサーバ間で SSL をイネーブルにするには、次の手順に従います。


ステップ 1 [Administration] > [Server Administration (Common Services)] > [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:イベント履歴

itemInv:Inventory

itemIpiu:IP 電話情報

qovr:Cisco Unified Service Monitor


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

Operations Manager データベースのパスワードを変更するには、次の手順に従います。


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

net stop crmdmgtd
 

ステップ 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 crmdmgtd
 


 

デバイス サポート

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

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

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

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

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

「ユーザの設定(ACS およびローカル RBAC)」

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

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

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

「ログ ファイルの保持」

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

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

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

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

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

ユーザの設定(ACS およびローカル RBAC)

Common Services は、ユーザの認証と認可のメカニズムを提供します。ユーザが何を表示して何を実行できるかは、ユーザ ロールによって決まります。システム管理者は次のタスクを実行できます。

ユーザを作成し、ユーザにユーザ ロールを割り当てる。

新しいユーザ ロールを作成し、ロールに特定のタスクを割り当てる。

デバイス グループを表示する権限をユーザに与える(デバイス レベルの権限)。ユーザは表示する権限のあるデバイスだけを表示できます。

Common Services は、ユーザの認証のための 2 つの異なるメカニズムまたは モード を提供します。両方のモードは同じ機能を提供します。

ユーザを認証するための 2 つのモードは次のとおりです。

ローカル RBAC モード(デフォルトのモード):ユーザの認証と認可のための Common Services に組み込まれた機能です。ローカル RBAC モードでは、ロールに関連づけられた権限とともに、ロールを割り当てます。

各ユーザ ロールが Operations Manager のタスクとどのように関連しているかを理解するには、[Administration] > [Server Administration (Common Services)] > [Security] > [Role Management Setup] を選択し、タスクの権限を表示するロールを選択します。ロールをクリックすると、ロールに与えられた権限を確認するために横断できるタスク ツリーが開きます。

CiscoSecure Access Control Server(ACS)モード:ACS がネットワークにインストールされ、Operations Manager が ACS に登録されている必要があります。ACS はロールに関連づけられた特権を指定します。詳細については、「ACS モードを使用したユーザの設定」を参照してください。

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

ローカル RBAC モードでのユーザの設定

ローカル RBAC モードで、ユーザを追加、編集、または削除できます。

ローカル RBAC モードを使用してユーザを設定するには、次の手順に従います。


ステップ 1 Operations Manager がローカル RBAC モードを使用していることを確認します。

a. [Administration] > [Server Administration (Common Services)] > [Security] > [AAA Mode Setup] の順に選択します。

b. [Local RBAC] が選択されていることを確認します。

ステップ 2 ユーザを設定します。

a. [Administration] > [Server Administration (Common Services)] > [Security] > [Local User Setup] の順に選択します。Common Services の [Local User Setup] ウィンドウが開きます。

設定手順の詳細を確認するには、[Local User Setup] ウィンドウの [Help] ボタンをクリックします。


 

ローカル RBAC モードでのユーザ ロールの設定

ローカル RBAC モードで、ユーザ ロールを追加、編集、コピー、または削除できます。


) [Fault Monitoring] ダッシュボードと [Diagnostic Views] ダッシュボードは、デフォルトではすべてのユーザがアクセス可能で、アクセス制限はデバイス レベルの認可(ユーザが表示する必要があるデバイスへのアクセス権をユーザに与えることによって行われる)によってだけ管理されます。
カスタム ロールを作成する場合、Events Subsystems のアクセスがユーザにとって必須であることを確認する必要があります。


 

ローカル RBAC モードでは、デフォルトのユーザ ロールを提供します。 表 20-9 に、特権が小さなロールから大きなロールへと並べた一覧を示します。

ローカル RBAC モードを使用してユーザ ロールを設定するには、次の手順に従います。


ステップ 1 [Administration] > [Server Administration (Common Services)] > [Security] > [Role Management Setup] の順に選択します。[Role Management Setup] ウィンドウが開きます。

ステップ 2 ロールを設定します。設定手順の詳細を確認するには、[Role Management Setup] ウィンドウの [Help] ボタンをクリックします。


 

 

表 20-9 ローカル RBAC のユーザ ロール

ユーザ ロール
説明

Help Desk

ネットワーク ステータス情報にだけアクセスできます。システム上の永続的なデータにアクセスできますが、デバイスでアクションを実行することも、ネットワークに到達するジョブをスケジュールすることもできません。

Network Operator

ヘルプ デスクのすべてのタスクを実行できます。ネットワーク データの収集に関連するタスクを実行できます。ネットワークでの書き込みアクセス権を必要とするタスクを実行できません。

Network Administrator

ネットワーク オペレータのすべてのタスクを実行できます。ネットワークの設定が変更されるようなタスクを実行できます。

System Administrator

CiscoWorks のすべてのシステム管理タスクを実行できます。

ユーザ ロールのカスタマイズ

すべての Operations Manager 画面へのアクセスを制限するようにユーザ ロールを設定できます。デバイスおよびアプリケーションへのアクセスを制限することもできます。

管理者は、既存のユーザ ロールを使用するか独自のロールを作成できます。すべてのカスタム ロールを削除し、あらかじめ定義されたロールだけを保持することもできます。Common Services のオンライン ヘルプの「Removing Custom Roles Using CLI」を参照してください。

デバイス ベースのカスタム ユーザ ロールのシナリオ例

会社 X は、異なる建物にある特定のデバイスのグループ(またはマネージド サービス プロバイダーの異なるカスタマー)を管理するために、ユーザのグループを設定する必要があります。会社 X は、1 つまたは複数の内部または外部のカスタマー(たとえば、会社 Z と会社 Y)を管理するために、ヘルプ デスク ユーザのカスタマイズを希望しています。このユーザは、Cisco Unified Communications Manager の関連情報を含むカスタマーのエンドポイントにアクセスする必要があります。

このニーズを満たすには、次の手順に従います。

[Administration] > [Server Administration (Common Services)] > [Security] > [Role Management Setup] を使用して、ヘルプ デスク ユーザ ロールをコピーします。ユーザ ロールをコピーした後、特定のタイプのデバイスを表示できるようにロールをカスタマイズできます。設定手順の詳細については、Common Services オンライン ヘルプ([Role Management Setup] ページの [Help] ボタンをクリック)を参照してください。

ユーザがデバイス グループを表示する権限をもつように設定します(必要な場合、新しいユーザを作成する)。[Administration] > [Server Administration (Common Services)] > [Security] > [Local User Setup] を使用します。設定手順の詳細については、Common Services オンライン ヘルプ([Local User Setup] ページの [Help] ボタンをクリック)を参照してください。


) ユーザが特定のグループのデバイスを使用できるようにするには、そのユーザに対してデバイス レベルの権限がイネーブルであることを確認する必要があります。マルチ エンドカスタマー バージョンの Operations Manager を使用している場合、これによって、ユーザは特定のカスタマー デバイスを表示することもできます。


 

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

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

ACS モードを使用してユーザを設定するには、次の手順に従います。


ステップ 1 CiscoWorks サーバが使用しているモードを確認します。

確認するには、[Common Services] ホームページから、[Administration] > [Server Administration (Common Services)] > [Security] > [AAA Mode Setup] を選択し、選択されているオプション ボタンのタイプ(ACS またはローカル RBAC)を確認します。

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

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

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

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

クラスタへのアクセス権を任意のユーザに提供する場合、クラスタ内のすべてのデバイスは、そのユーザの ACS の設定に明示的に追加する必要があります。Unified CM ノード、ゲートウェイ、Unity デバイス、ゲートキーパーなどを含める必要があります。

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 モードの場合は、デフォルトで、ローカル RBAC(CS サーバ)の認証スキームに 5 つのロールがあります。ここでは、これらのロールを特権が小さなものから順に示します。

 

Help Desk

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

例:Fault Monitor と Diagnostics ビューを起動します。

Approver

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

例:Fault Monitor を起動します。

Network Operator

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

例:模擬テストの追加。

Network Administrator

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

例:Fault Monitor のデフォルト ビューを設定します。

System Administrator

このロールのユーザは、CiscoWorks のすべてのシステム管理タスクを実行できます。CiscoWorks ホームページから [Permission Report] を表示します([Administration] > [Server Administration (Common Services)] > [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 の設定が自動的に適用されます。


) [Fault Monitoring] ダッシュボードと [Diagnostic Views] ダッシュボードは、デフォルトではすべてのユーザがアクセス可能で、アクセス制限はデバイス レベルの認可(ユーザが表示する必要があるデバイスへのアクセス権をユーザに与えることによって行われる)によってだけ管理されます。
カスタム ロールを作成する場合、Events Subsystems のアクセスがユーザにとって必須であることを確認する必要があります。


 

CiscoSecure ACS で CiscoWorks のロールと特権を編集するには、次の手順に従います。


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

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

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


 

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

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

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

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

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

デバイスベース フィルタリングは、Cisco Unified Communications Manager クラスタ レベルで実行されません。各クラスタへのアクセス権を提供した場合、すべてのユーザは Event History レポートにクラスタ レベルを表示できます。すべてのユーザの場合、クラスタ内のすべてのデバイスは、そのユーザの ACS の設定に明示的に追加する必要があります。Unified CM ノード、ゲートウェイ、Unity デバイス、ゲートキーパーなどを含める必要があります。

Publisher は、デバイス クラスタが Diagnostics ビューに表示できるように、ACS 内のユーザに追加する必要があります。

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

[Fault Monitor]:すべての画面

Diagnostics:すべての画面

Reports:

[IP Phones]:すべての画面

[Video Phones]:すべての画面

[Service Quality History]:すべての画面

[Personalized Report]:すべての画面

[Event History]:すべての画面

[Administration]:すべての画面

[Administration] > [Device Management]:すべての画面

[Administration] > [Device Management] > [Device Configuration]:すべての画面

[Administration] > [Device Management] > [Inventory Collection]:すべての画面

[Administration] > [Device Management] > [Auto Discovery Configuration]:すべての画面

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

[Administration] > [System Settings]:すべての画面

[Administration] > [Diagnostic Tests]:すべての画面

[Administration] > [UC Management Suite]:すべての画面

[Administration] > [Polling and Thresholds]:すべての画面

[Administration] > [Notifications]:すべての画面

[Administration] > [Notifications] > [Event Sets]

[Administration] > [Notifications] > [Notification Criteria]

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

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

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

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

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

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


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

ACS モードをローカル RBAC モードに変更するには、次の手順に従います。


ステップ 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 モードである必要があります。


 

 

ローカル RBAC でのグループベースのフィルタリング

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

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

電話機:電話機に関する情報を表示するには、その電話機が登録されている Cisco Unified Communications Manager にアクセスでき、アクセスできるグループ内にいる必要があります。


) マルチ エンドカスタマー バージョンの場合、異なるユーザによって管理される異なるカスタマー グループを割り当てることができます。


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

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

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

自己署名セキュリティ証明書を作成するには、次の手順に従います。


ステップ 1 [Administration] > [Server Administration (Common Services)] > [Security] > [Certificate Setup] の順に選択します。

[Certificate Setup] ページが表示されます。

ステップ 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 データのバックアップと復元

ここでは、データを定期的に(たとえば、週 1 回)バックアップする方法と、エラーまたは破損が発生した場合にそのデータを復元する方法について説明します。

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

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

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

「DB フラグメンテーションの修正」

Operations Manager のデータベースが 10 GB を超えた場合、バックアップする前にアンロードおよびリロードしなければならない場合があります。実行手順の詳細については、「バックアップ前の Sybase データベース問題の処理」を参照してください。Event History のデータベースが 2 GB を超えた場合、予防措置として Perl dbreload ユーティリティを実行することを検討してください(「DB フラグメンテーションの修正」 を参照)。

バックアップと復元(データベースのバックアップとユーザ設定データのバックアップを含む)は、バージョン 8.0 および 8.5 ~ 8.6 だけでサポートされています。バックアップと復元は、同じマシン上で行う 必要があります 。同じバージョンにバックアップして復元することが可能です。バックアップしたデータベースは、異なるハード ディスクまたは Operations Manager 以外のサーバに保存する必要があります。


注意 データベースのバックアップが既存の Operations Manager サーバとは異なる管理パスワードをもっている場合、管理パスワードは、アップグレード後に復元された管理パスワードに戻ります。

スケジュール バックアップは、毎日ではなく、毎週または毎月行う必要があります。バックアップした古いバージョンのファイルは、手動で削除する必要があります。


) CMT ツールを使用したデータ マイグレーションおよび Service Monitor 8.0 から 8.6 へのアップグレードを行うと、以前のコールのグレーディングは、アップグレード後に常に Unknown として表示されます。これはすべての CDR、CVTQ、および Sensor レポートで発生します。グレーディングは、アップグレード後に実行される新しいコールに対して適切に行われます。8.5 から 8.6 へのアップグレードには問題がありません。


既知の問題の詳細については、Cisco.com のオンライン リリース ノートを参照してください。

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

バックアップ ユーティリティは、Detailed Device View で監視または一部監視されていたすべてのタイプのデバイスのすべてのコンポーネント(次のものを除く)の状態のバックアップを行います。一時停止中のデバイスは含まれません。

データベースのバックアップと復元(すべての Operations Manager モジュールのデータベースとユーザ設定データを含む)は、バージョン 8.0 ~ 8.5 および 8.6 だけでサポートされています。バックアップと復元は、同じマシン上で行う 必要があります

データベースのバックアップを週 1 回または月 1 回実行し、古いバックアップ ファイルを手動で削除し、別のディスクまたはサーバにバックアップを保存することを推奨します。

Operations Manager は、Cisco Unified Communications Manager マシンに対する音声サービス、システム プロセッサ、ハードディスク、仮想メモリ、および RAM コンポーネントに関する Detailed Device View の設定を復元しません。

Operations Manager は上記コンポーネントを作成するのにデバイス MIB ポーリングではなく、RTMT ポーリングを使用します。したがって、8.0 よりも前の Operations Manager リリースからアップグレードする場合、8.6 では Operations Manager Detailed Device View の上記データを表示しません。


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

復元ユーティリティは、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 8.6 のアップグレード後は、必ず 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 が機能している場合でも、ネットワークの接続性の問題のため、その使用は推奨されません。結果的に、サーバにマップされたネットワーク ドライブは、ドライブ選択のユーザ インターフェイスからは見られません。

CiscoWorks を使用してデータをバックアップおよび復元するには、次の手順に従います。


ステップ 1 [Administration] > [Server Administration (Common Services)] > [Administration] > [Backup] の順にクリックします。

[Backup Job] ページが表示されます。

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


 

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

形式:/generation_number/suite/directory/filename

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

 

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

オプション
説明
使用方法

generationNumber

バックアップ番号

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

suite

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

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

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

itemEpm:イベント公表

itemFh:イベント履歴

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

itemIPIU:IP 電話情報

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

wpu:Node-to-Node tests

directory

何が格納されているか

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

filename

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

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

バックアップ前の Sybase データベース問題の処理

Operations Manager のデータベースが 10 GB を超えた場合、バックアップする前にアンロードおよびリロードしなければならない場合があります。Sybase データベースの故障問題が発生する可能性があります。この場合、データベースが破損し、有効にならず、大きくなりすぎる(10 GB を超えると、バックアップ手順に時間がかかる)可能性があります。

データベースでこれらの問題が発生した場合、次の手順を使用して、データベースをアンロードおよびリロードします。この手順を実行するには、データベースのパスワードが必要です。データベースのパスワードが不明な場合、カスタマー サポートに連絡してください。


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


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

% net stop crmdmgtd


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

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

% dbunload -c "uid=ユーザ名;pwd=<パスワード>;dbf=<db 名>" データ をアンロードするディレクトリ

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

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

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

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

% dbinit -p 4096 itemFh.db

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

% dbisqlc -c "uid= デフォルト ユーザ名;pwd=デフォルト パスワード

;dbf=db 名" reload.sql

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

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

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

%rm *.dat *.sql
net start crmdmgtd
 


 

DB フラグメンテーションの修正

データを失うことなく、Operations Manager FHDB データベース内のフラグメンテーション(望ましくない割り当てスペース)をクリーンアップするには、次の手順に従います。


ステップ 1 FH db のパスワードを知っていることを確認します。

ステップ 2 ファイル CSCOpx¥databases¥itemEpm¥itemFh.db を別の場所にコピーして、そのバックアップを作成します。

このファイルをコピーできない場合、デーモン マネージャを停止し、再度試みます。

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

net stop crmdmgtd
 

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

% dbunload -c "uid= ユーザ名 ;pwd= パスワード ;dbf= db 名 " データをアンロードするディレクトリ

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

%dbunload -c "uid=itemFhUser;pwd=<pwd>;dbf=C:¥Program Files¥CSCOpx¥databases¥itemFh¥itemFh.db" c:¥unload
 

ステップ 5 次のように入力します。 perl dbRestoreOrig.pl dsn=itemfh dmprefix=FH

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

% dbisqlc -c "uid=itemFhUser;pwd=XXX;dbf=C:¥Program Files¥CSCOpx¥databases¥itemFh¥itemFh.db" reload.sql

ステップ 7 デーモン マネージャを開始します。

net start crmdmgtd
 

ステップ 8 コマンド ラインで次のように入力します。 NMSROOT/ conf/itemDb/bin/dbreload.pl .

ユーティリティを起動すると、コマンド ライン オプションにより手順が提示されます。このユーティリティでは、パスワードを指定すると、すべての Operations Manager データベースがリロードされます。データベースのパスワードがわからない場合は、新しいデータベース パスワードの入力を求めるプロンプトが表示されるので、すべてのデータベースに対してパスワードをリセットし、リロードを実行します。


 

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

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


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


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

ステップ 2 [Administration] > [Server Administration (Common Services)] > [Administration] > [Process Management] を選択します。

[Process Management] ページが表示されます。


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


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

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

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


 

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

 

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

名前
説明
依存関係

AdapterServer

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

なし

CDTServer

デバイス インベントリと登録情報を Unified CM クラスタから 1 つのリポジトリに収集します。

なし

CrossLaunchFramework

相互起動のために他のコンポーネントによって使用されるライブラリ。

なし

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

DevicePoolCollector

Device Pool データ収集モジュールは、監視された各 Cisco Unified CM クラスタのデータを収集します。収集は Publisher が追加されるか Operations Manager で再検出されると開始されます。

加入者ノードの追加または再検出によって、デバイス プールの収集はトリガーされません。このモジュールは、Inventory Collector モジュール内のイベントをリッスンします。

InventoryCollector

DevicePoolIntegrator

この情報を使用する他のモジュールに、デバイス プール データにアクセスするための共通の API を提供します。

デバイス プール データの消費者。

DevicePoolCollector

DevicePoolEventMonitor

デバイス プール レベルの情報としきい値を使用して、イベントを生成します。

DevicePoolIntegrator

EPMDbEngine

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

なし

EPMDbMonitor

EPM データベース モニタ。

EPMDbEngine

EPMServer

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

EPMDbEngine

FHDbEngine

Event History データベース エンジン:イベントのリポジトリ。

なし

FHDbMonitor

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

FHDbEngine

FHPurgeTask

Event History パージング タスク。

なし

FHServer

Event 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 プロセスを監視し、それらが予期せずシャットダウンした、またはメモリ不足で不安定な状態の場合、プロセスを再起動します。

プロセスがメモリ不足の場合、ログはバックアップが行われ、プロセスは再起動されます。管理者は定期的に FH DB のサイズをチェックし、データベースが特定のサイズになった場合に dbreload ユーティリティを実行する必要があります。

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

PIFServer

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

PIFDbEngine、ESS

PTMServer

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

ITMOGSServer

QoVMServer

Service Monitor サーバ。

ESS

QOVRqovr

Service Quality イベント プロセス。

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

サービス レベル ビュー サーバ。

SIRServer、ITMOGSServer

VHMIntegrator

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

ESS

VHMServer

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

DfmBroker

VsmServer

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

ITMOGSServer

ログ ファイルの保持

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

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

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


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

DFM ログ ファイルの保持

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


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

DFM ログ ファイルを保持するには、次の手順に従います。


ステップ 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-8 「モジュール別の Operations Manager ログ ファイル」 には、どのログ ファイルが循環されるかに関する情報が含まれています。

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


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

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

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

ソフトウェアのバージョン情報を表示するには、[Administration] > [Software Center (Common Services)] > [Software Update] を選択します。[Products Installed] の下に Operations Manager ライセンス バージョンを表示します。

ライセンス情報を表示するには、[Administration] > [Server Administration (Common Services)] > [Administration] > [Licensing] を選択します。

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

場合によってはトラブルシューティングのために、インストールされている Operations Manager または Service Monitor のビルドを確認する必要が生じる場合があります。次のようにしてビルド ID を検出できます。


ステップ 1 [Administration] > [Software Center (Common Services)] > [Software Update] を選択します。

新しいウィンドウが開きます。

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

新しいウィンドウが開きます。

ステップ 3 ページの上部にあるラベルの値(ビルド 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 ウォークのサンプルについては、「Operations Manager による SNMP MIB サポート」を参照してください。

ここでは、次の内容について説明します。

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

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

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


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


 

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

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

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

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

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

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

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

Windows SNMP サービスは、必要に応じて追加または削除できる Windows コンポーネントです。Operations Manager によってサポートされている MIB に対する SNMP 照会をイネーブルにするには、SNMP サービスがインストールされてイネーブルである必要があります。次の手順に従って、Windows 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 のオンライン ヘルプを参照してください。

Windows SNMP サービスをイネーブルおよびディセーブルにするには、次の手順に従います。


ステップ 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 設定操作は許可されていません。また、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 になります。

デフォルトでは、ログ ファイルにはエラー メッセージだけが書き込まれます。ログ レベルを変更するには、次の手順を使用します。


ステップ 1 Operations Manager がインストールされているサーバにログインします。

ステップ 2 次のディレクトリに移動します。

NMSROOT ¥objects¥subagent

ステップ 3 次のファイルを編集します。

conf

ステップ 4 Property LogFileName を探します。PropValue の値を次のいずれかに変更します。

Debug

Informational

Warning

Error


 

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


ワンポイント アドバイス スクリプトを使用して、Operations Manager サーバのホスト名を自動的に更新するために使用できるツールがあります。スクリプトにアクセスするには、NMSROOT¥bin¥systemIdentityChange に移動します。ホスト名を更新するには、最初に SystemHostNameChange.pl を使用してから CUOMHostNameChange.pl を使用します。


次に、Operations Manager サーバのホスト名の変更を手動で行う方法について示します。

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


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

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


ステップ 1 コマンド プロンプトを開いて、NMSROOT¥bin に移動します。

ステップ 2 次のコマンドを入力します。

perl dbpasswd.pl dsn=cmf npwd=newpassword

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

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


 

パスワードを変更するには、次の手順を実行します。


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

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

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

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

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

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

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

HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet

HKEY_LOCAL_MACHINE¥SOFTWARE¥Cisco¥Resource Manager

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

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

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

古いホスト名を書き留めます。このプロセスを完了するために、このホスト名が必要になります。

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

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

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

OLDHOSTNAME:NEWHOSTNAME
 

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


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

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

NMSROOT ¥conf¥dfm¥Broker.info

ステップ 7 ホスト名の変更前に追加されたデバイスが 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'
 

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

app_hostname='OldhostName'

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

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

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

OldhostName は古いホスト名です。

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

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

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

a. [Administration] > [Server Administration (Common Services)] > [Security] > [Certificate Setup] の順に選択します。

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

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 アドレスの変更


ワンポイント アドバイス スクリプトを使用して、Operations Manager サーバの IP アドレスを自動的に更新するために使用できるツールがあります。スクリプトにアクセスするには、NMSROOT¥bin¥systemIdentityChange に移動します。IP アドレスを更新するには、SystemIPAddressChange.pl を使用します。


次に、Operations Manager サーバの IP アドレスの変更を手動で行う方法について示します。


注意 メンテナンスを実行するときは、OMHealthMonitor Windows サービスを手動で停止してください。停止しない場合、意図的に停止されていたプロセスが再起動される場合があります。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 サービスです。プロセスがメモリ不足の場合、ログはバックアップが行われ、プロセスは再起動されます。

管理者は定期的に FH DB のサイズをチェックし、それが特定のサイズになった場合に dbreload ユーティリティを実行する必要があります。これは CSCOpx¥HealthMonitor ディレクトリにあります。


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

net stop OMHealthMonitor
net start OMHealthMonitor

ここでは、次の内容について説明します。

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

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

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

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

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

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

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

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

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

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

 

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

ディレクトリ名
内容

Audit

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

Backup

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

Conf

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

Log

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

scripts

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

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

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

ヘルス モニタの動作を修正するには、次の手順に従います。


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

表 20-13 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-11 を参照してください。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 イベントが発生する場合、イベントはユーザ インターフェイスでアクティブのままとなります。デーモン マネージャの再起動後、何かイベントが失われたと示されることはありません。問題が引き続き存在する場合、ポーリングに基づくイベントは生成されますが、トラップに基づくイベントは問題が存続しても処理されません。

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

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

マルチ エンドカスタマー バージョンの認可/認証

インストール時にマルチ エンドカスタマー バージョンの導入を選択した場合、ユーザが特定のカスタマー グループにアクセスできるように設定できます。詳細については、「ユーザの設定(ACS およびローカル RBAC)」を参照してください。