User Guide for Cisco Prime Unified Operations Manager
Administering Operations Manager
Downloads: This chapterpdf (PDF - 0.96MB) The complete bookPDF (PDF - 17.41MB) | Feedback

Administering Operations Manager

Table Of Contents

Administering Operations Manager

Overview—Operations Manager Administration Tasks

Scheduling Operations Manager Tasks

Configuring SNMP Trap Receiving and Forwarding

Enabling Devices to Send Traps to Operations Manager

Enabling Cisco IOS-Based Devices to Send Traps to Operations Manager

Enabling Catalyst Devices to Send SNMP Traps to Operations Manager

Forwarding Windows Events as SNMP Traps

Integrating SNMP Trap Receiving with Other Trap Daemons or NMSs

Ports and Protocols that Operations Manager and other CUCM Applications Use

Ensuring that E-Mail Notifications Are Not Blocked

Viewing Purge Scheduler Status

Updating System Settings

Generating and Understanding the System Status Report

Performing Software Updates in Common Services

Viewing and Updating License Information

Configuring Cluster Trunk Utilization

Setting Miscellaneous System Settings

Setting System-Wide Parameters Using System Preferences

Using Logging to Enable and Disable Debugging

Security Considerations

File Ownership and Protection

SSL

Enabling SSL Between the Browser and the Server

SNMPv3

Changing the Password for Operations Manager Databases

Device Support

Performing System Administration Tasks

Configuring Users (ACS and Local RBAC)

Configuring Users In Local RBAC Mode

Configuring User Roles in Local RBAC Mode

Configuring Users Using ACS Mode

Creating Self-Signed Security Certificates Yearly

Backing Up and Restoring Operations Manager Data

Backing Up and Restoring Detailed Device View Configurations Using Operations Manager Utilities

Backing Up and Restoring Using CiscoWorks

Handling Sybase Database Issues Before Backing Up

Fixing DB Fragmentation

Starting and Stopping Operations Manager Processes

Maintaining Log Files

Maintaining the DFM Log File

Maintaining Log Files in CSCOPX\log

Viewing Software Version or License Information

Finding the Build ID for an Installed Operations Manager (or Service Monitor)

Using SNMP to Monitor Operations Manager

Configuring Your System for SNMP Queries

Determining the Status of Windows SNMP Service

Installing and Uninstalling Windows SNMP Service

Enabling and Disabling Windows SNMP Service

Configuring Security for SNMP Queries

Viewing the System Application MIB Log File

Changing the Hostname on the Operations Manager Server

Changing the IP Address on the Operations Manager Server

Monitoring Operations Manager Process Health

Editing Health Monitor Configuration Files

Viewing Backed Up Process Logs

What Happens After an Operations Manager Restart

Multiple End-Customer Authorization/Authentication


Administering Operations Manager


This chapter includes the following topics:

Overview—Operations Manager Administration Tasks

Configuring SNMP Trap Receiving and Forwarding

Updating System Settings

Security Considerations

Device Support

Performing System Administration Tasks

Using SNMP to Monitor Operations Manager

Changing the Hostname on the Operations Manager Server

Changing the IP Address on the Operations Manager Server

Monitoring Operations Manager Process Health

What Happens After an Operations Manager Restart

Multiple End-Customer Authorization/Authentication

Overview—Operations Manager Administration Tasks

From the Cisco Prime Unified Operations Manager (Operations Manager) Administration tab, you can perform the tasks listed in Table 20-1.

This section contains Scheduling Operations Manager Tasks.

Table 20-1 Operations Manager Administration Tasks 

Tasks
Description

Device Management

See Getting Started with Device Management.

From Device Management you can perform device configuration, inventory collection, and set up auto discovery. See additional task details below.

Device Configuration

See Configuring Device Management.

From Device Configurations you can:

View device summary information that includes device states, device and phone counts, and discovery settings.

Add, import, modify, delete, and export devices.

Use DCR device selection to manually devices and control the synchronization between the Device and Credentials Repository (DCR) and the Operations Manager inventory.

View the IP Address Report.

Enter or modify device credentials.

Create device groups.

Inventory Collection

See Performing Manual Inventory Collection on Devices.

From Inventory Collection you can:

Create, view, or update schedules for collection of devices, IP phones, or clusters.

View the discovery status of the XML phones that are being ed or change the schedule of phone discovery.

Edit SNMP timeout and retry configuration.

Configure LDAP so that Operations Manager connects to a Lightweight Directory Access Protocol (LDAP) and can access user information stored there.

Auto Discovery Configuration

See Setting Up Auto Discovery Configuration in Cisco Prime UOM.

From Auto Discovery Configuration, you can:

Add, edit, delete, and apply a set of credentials for SNMP, HTTP (required only for Cisco Unified Communications Manager), and Windows (required only for Windows-based MCS application servers).

Select the type of discovery (CDP, logical cluster discovery, or ping sweep).

Select a scheduled time to run the discovery or filter devices (using include or exclude criteria).

Configuring System Settings

See Updating System Settings.

From System Settings, you can:

View the system status on Operations Manager. See Generating and Understanding the System Status Report.

Update license information in Operations Manager. SeePerforming Software Updates in Common Services.

Perform event customization. See Events Processed.

Configure trunk utilization for clusters. See Configuring Cluster Trunk Utilization.

Set up logging and system preferences. See Updating System Settings

Setting Up UC Management Suite applications

See Setting Up Cisco Unified Communications Management Application Links.

From UC Management Suite, you can set links to Operations Manager to launch other Cisco Unified Communications Management Suite applications.

Polling and Thresholds

See Configuring Polling and Thresholds.

From Polling and Thresholds, you can:

Change polling intervals, timeouts, and retries by device group

Enable and disable polling settings

Change thresholds, resetting the limits against which polled data will be compared

Customize threshold settings for Operations Manager, RTMT, or PhoneUnregistration/Service Quality

Reprioritize groups for polling and thresholds

Apply polling and threshold changes to the system—After you apply changes, Operations Manager configures data collectors to:

Start using updated polling parameters and threshold values

Resume polling for devices or device elements that were previously suspended

Synchronize and view thresholds for Cisco Unified Communications Manager clusters.

SRST Poll Settings

See Maintaining SRST Poll Settings.

From the SRST Poll Settings page, you can configure SRST monitoring.

SRST Operations

See Viewing SRST Poll Setting Status

From the SRST Poll Settings page, you can view status of the SRST poll settings.

System Status

See Generating and Understanding the System Status Report.

From the System Status page, you can generate a System Status report.

Logging

See Using Logging to Enable and Disable Debugging.

From the Logging page, you can change the type—and quantity—of messages written to log files, enabling and disabling debugging, for example.

System Preferences

See Setting System-Wide Parameters Using System Preferences.

From the System Preferences page, you can configure the following:

SNMP trap forwarding—(Optional) Set a host and port number as a recipient for traps

CiscoWorks Servers—Enter remote servers running other CiscoWorks products, such as:

Resource Manager Essentials (RME)

Campus Manager (Campus)

CiscoView

SNMP trap community string—Enter the read community string

SNMP trap receiving—Change the port on which Operations Manager listens for SNMP traps

Default SMTP server—Change or enter a default server to use for e-mail notifications.

Purging schedule—Select the time when database purging occurs daily.

Static NAT environment—Select to enable Network Address Translation (NAT)-enabled device support in Operations Manager. In order to monitor NAT-enabled devices, you must set this preference.

Add Users

See Configuring Users (ACS and Local RBAC).

Launches a Common Services window that opens the Local User Setup page. This enables administrators to add users and assign group privileges.

Back Up and Restore

See Backing Up and Restoring Operations Manager Data

Provides available options to back up and restore Operations Manager.


For more information, see the following additional topics:

Scheduling Operations Manager Tasks

Configuring SNMP Trap Receiving and Forwarding

Viewing Purge Scheduler Status

Scheduling Operations Manager Tasks

When Operations Manager is first installed, most tasks listed in Table 20-2 are scheduled by default to ensure that they do not run concurrently. You can configure the schedules for these tasks to meet the requirements of your site. However, you should still avoid running them concurrently.

Table 20-2 Scheduling Considerations 

Scheduling Task
Default Schedule
Comments and Notes
Database purging

Run daily at midnight.

Amount of time it takes to purge the database depends on the size of the database. We recommend that you manually delete database backups.

Phone discovery

Run daily at midnight, 04:00, 08:00, 12:00, 16:00, and 20:00.

You should determine how long the last phone discovery took to complete by comparing at the start and end times for the last collection on the IP Phone Discovery Schedule page.

See Working with IP Phone Discovery. Knowing how long phone discovery normally takes to complete, helps you to schedule discovery time.

CDT cluster discovery

Run daily at midnight.

This can also be started manually by selecting the Run Now option.

Inventory collection

Run weekly on Monday at 2:00 a.m.

By default, inventory collection starts 2 hours after database purging.


In addition to configuring schedules with Operations Manager, a system administrator can schedule database backups. You should coordinate the database backup schedule to avoid running concurrently with the tasks listed in Table 20-2.

We recommend that you perform database backups on a weekly or monthly basis, manually delete old backup files, and store backups on a separate disk or server.

For more information about schedules, see the following topics:

Viewing Purge Scheduler Status

Backing Up and Restoring Operations Manager Data

Configuring SNMP Trap Receiving and Forwarding

Operations Manager can receive traps on any available port and forward them to a list of devices and ports. This capability enables Operations Manager to easily work with other trap processing applications. However, you must enable SNMP on your devices and you must do one of the following:

Configure SNMP to send traps directly to Operations Manager

Integrate SNMP trap receiving with an NMS or a trap daemon

To send traps directly to Operations Manager, perform the tasks in the Enabling Devices to Send Traps to Operations Manager. To integrate SNMP trap receiving with an NMS or a trap daemon, follow the instructions in Integrating SNMP Trap Receiving with Other Trap Daemons or NMSs.

For details on ports that Operations Manager uses, see Ports and Protocols that Operations Manager and other CUCM Applications Use.

This section contains:

Enabling Devices to Send Traps to Operations Manager

Ports and Protocols that Operations Manager and other CUCM Applications Use

Ensuring that E-Mail Notifications Are Not Blocked

Viewing Purge Scheduler Status

Generating and Understanding the System Status Report

Setting System-Wide Parameters Using System Preferences

Using Logging to Enable and Disable Debugging

Accessing and Deleting Log Files

Enabling Devices to Send Traps to Operations Manager


Note If your devices send SNMP traps to a Network Management System (NMS) or a trap daemon, see Integrating SNMP Trap Receiving with Other Trap Daemons or NMSs.


Because Operations Manager uses s variables and traps to determine device health, you must configure your devices to provide this information. For any Cisco devices that you want Operations Manager to monitor, SNMP must be enabled and the device must be configured to send SNMP traps to the Operations Manager server.

Make sure your devices are enabled to send traps to Operations Manager by using the command line or GUI interface appropriate for your device:

Enabling Cisco IOS-Based Devices to Send Traps to Operations Manager

Enabling Catalyst Devices to Send SNMP Traps to Operations Manager

Forwarding Windows Events as SNMP Traps

Integrating SNMP Trap Receiving with Other Trap Daemons or NMSs

Enabling Cisco IOS-Based Devices to Send Traps to Operations Manager

For devices running Cisco IOS software, provide the following commands:

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

Where [community string] indicates an SNMP read-only community string and [a.b.c.d] indicates the SNMP trap receiving host (the Operations Manager server).

For more information, see the appropriate command reference guide.


Step 1 Log into Cisco.com.

Step 2 Select Products & Services > Cisco IOS Software.

Step 3 Select the Cisco IOS software release version used by your Cisco IOS-based devices.

Step 4 Select Technical Documentation and select the appropriate command reference guide.


Enabling Catalyst Devices to Send SNMP Traps to Operations Manager

For devices running Catalyst software, provide the following commands:

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

Where [community string] indicates an SNMP read-only community string and [a.b.c.d] indicates the SNMP trap receiving host (the Operations Manager server).

For more information, see the appropriate command reference guide.


Step 1 Log into Cisco.com.

Step 2 Select Products & Services > Cisco Switches.

Step 3 Select the appropriate Cisco Catalyst series switch.

Step 4 Select Technical Documentation and select the appropriate command reference guide.


Forwarding Windows Events as SNMP Traps

In order for Operations Manager to view forwarded Windows events from Windows-based devices as SNMP traps, you must configure the event to trap forwarder utility (evntwin.exe). Evntwin configures the translation of events to traps based on information in the Evntwin configuration file.

It is installed when the Windows SNMP service is installed. You need to select the event numbers that you want to forward as SNMP traps.

To select the events you want forwarded and update the evntwin configuration file:


Step 1 Go to Start > Run and enter evntwin.exe.

The Event to Trap Translator window opens.

Step 2 Select the Custom radio button, then click Edit.

Step 3 Select the event source in the Event sources pane.

Step 4 Select the event in the Events pane, click Add, and when the pop-up opens, click OK.

The selected event is now in the upper pane, Events to be translated to traps.

Step 5 Repeat step 4 until all events to be converted are selected.

Step 6 Click Apply.

Step 7 Click Export and save the file as events.cnf on your disk.

Step 8 Enter the following command:

# NMSROOT\evntcmd events.cnf

where NMSROOT is the path where you saved the events.cnf on your machine.


Integrating SNMP Trap Receiving with Other Trap Daemons or NMSs

You might need to complete one or more of the following steps to integrate SNMP trap receiving with other trap daemons and other Network Management Systems (NMSs):

If the host where Operations Manager is running to the list of trap destinations in your network devices. See Enabling Devices to Send Traps to Operations Manager. Specify port 162 as the destination trap port.

If another NMS is already listening for traps on the standard UDP trap port (162), you must configure Operations Manager to use another port, such as port 9000. See Setting System-Wide Parameters Using System Preferences.

If your network devices are already sending traps to another management application, configure that application to forward traps to Operations Manager.

Table 20-3 describes scenarios for SNMP trap receiving and lists the advantages of each.

Table 20-3 Configuration Scenarios for Trap Receiving 

Scenario
Advantages

Network devices send traps to port 162 of the host where Operations Manager is running.

Operations Manager receives the traps and forwards them to the NMS.

No reconfiguration of the NMS is required.

No reconfiguration of network devices is required.

Operations Manager provides a reliable trap reception, storage, and forwarding mechanism.

NMS continues to receive traps on port 162.

Network devices continue to send traps to port 162.

The NMS receives traps on default port 162 and forwards them to port 162 on the host where Operations Manager is running.

No reconfiguration of the NMS is required.

No reconfiguration of network devices is required.

Operations Manager does not receive traps dropped by the NMS.


Ports and Protocols that Operations Manager and other CUCM Applications Use

Operations Manager uses the following protocols:

SNMP

ICMP

TCP/IP

SMTP

RMI

HTTP

XML

Operations Manager uses the TCP and UDP ports described in Table 20-4.


Note If Service Monitor, Provisioning Manager, or Service Statistics Manager are running on the same instance as Operations Manager, you must ensure that the ports are available. See the user guides for these applications for more details on ports.


Table 20-4 Operations Manager Incoming Ports Used 

Port Number
Usage

80

XML-based data collection for phone information (such as serial numbers and load ID collected through Discovery).

162

Default port number used by Operations Manager for receiving traps.

1024-4999

Used by Operations Manager as temporary ports.

40000-41000

Used by Common Transport Mechanism for internal application messaging.

42344

Used by Synthetic Testing Web Service.

42350-42353

Used by messaging software.

43445-43459

Operations Manager uses the following as database ports:

43445—Used by Event History database engine

43446—Used by inventory service database engine

43447—Used by event processing database engine

43449—Used by IP Phone Information Facility database engine

43459—Used by Service Monitor database engine

48102—Used by Service Statistics Manager database engine

8080

Used to determine whether the Cisco Unified Communications Manager 5.0 web service is up

This port must be made available to Operations Manager.

9000

Trap receiving CSListener (Operations Manager server if port 162 is occupied)

9002

Used by the Broker to listen to both the IP telephony server and the device fault server

9009

Default port number used by the IP telephony server for receiving traps from the device fault server


Table 20-5 Service Monitor Ports Used

Port Number
Usage

22

SFTP—Obtain data from Unified CM versions 5.x or later.

53

DNS.

67 and 68

CHCP.

2000

SCCP—Communicates with Cisco 1040s.

43459

Database.

5666

Syslog—Receives syslog messages from Cisco 1040s.

5665-5680

Interprocess communication between the user interface and back-end processes.

These ports must be free.


Table 20-6 Provisioning Manager Ports Used

Port Number
Protocol
Process
Description
Inbound TCP Ports that Need to be Open on the Firewall

80

HTTP

Apache Web Server

Configurable during the advanced installation process.

5432

JDBC

PostregSQL Database Server

Configurable during the advanced installation process.

Note If you are performing a distributed installation (where the application and database are on separate systems), this port must be open for inbound communication on the Provisioning Manager database server. This enables the Provisioning Manager application server to access the database. For a single server installation, this port does not need to be open for external access.

46443

HTTPS

Apache Web Server

By default, this port is not configured for use.

To configure SSL, see the Provisioning Manager user documentation.

TCP Ports Used

46001

RMI

CUPM NICE Engine

Configurable during the advanced installation process.

46008

HTTP

Jboss Application Server

Configurable during the advanced installation process.

46009

AJP

Jboss Application Server

By default, this port is not configured for use.

To configure SSL, see the Provisioning Manager user documentation.

46083

Web Service

Jboss Application Server

46098

RMI

Jboss Application Server

46099

JNP Service

Jboss Application Server

46444

JRMP

Jboss Application Server

Outbound TCP Ports Used to Communicate with Other Devices

80

HTTP

ApacheWeb Server

Cisco Unified Communications Manager

8443

HTTPS

Cisco Unity Connection and Cisco Unified Communications Manager 5.0 or later

1433

JDBC

Cisco Unity

22

SSH

Cisco Unified Communications Manager Express and Cisco Unity Express

23

Telnet

Cisco Unified Communications Manager Express and Cisco Unity Express

8443

HTTPS

Cisco Unified Presence.


Table 20-7 Service Statistics Manager Ports Used 

Port Number
Usage

8007

Apache JServ

800

Tunnel Proxy

800

Tomcat

800

JMS Server

9139

JServer Event

48099

Remote Method Invocation

To configure Service Statistics Manager to use a port other than 48099, see the Service Statistics Manager user documentation.

48100

Jboss

To configure Service Statistics Manager to use a port other than 48100, see the Service Statistics Manager user documentation.

48101

HTTP—WebServer

48102

Database

12123

Agent Controller Listener

12124

SSM Agent listens to messages from the SSM server

12125

Database access port that interacts between the agent controller and the database

12126

Agent Controller Callback—This port is used by remote SSM agents to send data back to the Service Statistics Manager server.

12130

Checkpoint monitor for receiving log messages.

12140

CLServer

12141

Log Server

18000

Rate

40402

Licensing

45000

Message server

48443

HTTPS—Secure web server


Ensuring that E-Mail Notifications Are Not Blocked

If you have an antivirus application on the default SMTP server, verify that a port-blocking rule does not stop notification e-mail from being sent. Some antivirus applications use port-blocking to block mass-mailing worms. Delete the port-blocking rule, if necessary.

For more information about notification e-mail, see Configuring Notifications.

Viewing Purge Scheduler Status

You can check the status of the Operations Manager data purge job from the Job Browser each day after the job runs.


Note You can also check the status of daily purging on the System Status report; see Generating and Understanding the System Status Report.


To view the purge scheduler status:


Step 1 Launch the CiscoWorks home page by clicking the CiscoWorks link in the upper right-hand corner of the Operations Manager home page.

Step 2 Select Administration > Server Administration (Common Services) > Server > Job Browser.

The Job Browser page appears, displaying a table of scheduled jobs.

Step 3 Look for the Operations Manager:DataPurge job in the Type column and check for information in the Status column.



Note If you delete the Operations Manager:DataPurge job using the Job Browser, purging will not resume until you restart the daemon manager, reboot the server, or reconfigure the daily purging schedule.


Updating System Settings

You can perform various updates to system settings in Operations Manager by using the following tools:

Generating and Understanding the System Status Report

Viewing and Updating License Information

Configuring Notifications

Configuring Cluster Trunk Utilization

Setting Miscellaneous System Settings

Generating and Understanding the System Status Report

To access a System Status report, select Administration > System Settings > System Status. The System Status report opens.

The System Status report represents data immediately and may include data from the server startup or the last 24 hours. Conditions for Synthetic Test are currently displayed. Any failed tests will receive the following error:

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

To navigate through the System Status report, use the following:

Go to field—Select a section of the report from the list. At the end of any section, you can click a Back to Top link.

Summary—Select a section of the report by clicking any of the following links:

Failed Processes—If this message is displayed:

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

see Using SNMP to Monitor Operations Manager for more information.

Inventory

Data Purging

Diagnostics: Synthetic Tests


Note A failed synthetic test indicates that the test did not run, because at the time of execution the systems CPU utilization was greater than 80 percent.


Diagnostics: Phone Status Tests

Diagnostics: Node-to-Node Tests

Notifications

Phone Licensing Summary—If this message is displayed:

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

Select Administration > Server Administration (Common Services) >  Administration > Licensing to add or update licenses on Operations Manager.

System Limits


Note You can also select a section of the report by clicking a View Details link in the summary.


The System Status report contains the following sections:

Failed Processes—Names of processes that failed.

Inventory—Displays the name, last execution time, status, and next scheduled time for the following types of data collection:

Discovery—Identifies new devices and s them to the DCR. (Optional. Can be scheduled or run as needed.)

DCR Domain Status—s devices to the DCR from other CiscoWorks servers if Operations Manager is configured to synchronize devices and credentials (rather than working in standalone mode).

Device Selection—s devices to those that Operations Manager monitors either automatically—as they are ed to the DCR— or when a user manually selects them from the DCR. Status: Automatic or Manual.

Device Inventory Collection—Probes devices that Operations Manager monitors to update device components and their status; does not discover devices.

Phone Inventory Collection—Discovers and collects information about all IP phones in the network by checking all switches and Cisco Unified Communications Managers monitored by Operations Manager; does not discover devices.

Data Purging—Start time, end time, and status for most recent database purging task.

Diagnostics: Synthetic Tests—Tests that failed: Test Name, Test Type, Application Instance, Failure Time, Reason.

Diagnostics: Phone Status Tests—Tests that failed: Test Name, Source Router, Extension, MAC Address, IP Address, Failure Time, Reason.

Diagnostics: Node-to-Node Tests—Tests that failed: Test Name, Test Type, Endpoints, Failure Time, Reason.

Notifications—Device Event Description/Associated Event(s), Event ID, Destination(s), Failure Time, Reason.

A failed notification for Trap and Syslog indicates that the notification has failed due to an unresolved Fully-Qualified Domain Name of the Trap/Syslog Receiver when Trap/Syslog notifications are sent.

Phone Licensing Summary—License counts for Hard Phone, Soft Phones and Total Phones.

Adjunct Soft IP phones (phones that share the same extension as that of a hard phone), Suspect Phones (phones that are connected to a switch but not registered to any Unified CM), and multiple incremental lines are ignored in the license count.

System Limits—Current value, Limit value, and Limited By (License or System Resources) for the following parameters:

Devices—Current: Number of devices in Operations Manager monitored inventory. Limit: Number of devices allowed by license.

Phones—Current: Number of phones in Operations Manager monitored inventory. Limit: Number of phones allowed by license.

Ports—Current: Number of ports in Operations Manager monitored inventory. Limit: Number of interfaces allowed by license.

Interfaces—Current: Number of interfaces in Operations Manager monitored inventory. Limit: Number of interfaces allowed by license.

No current or limit definitions for the following in the System Limits:

Synthetic Tests.

Phone Status Tests.

Node-to-Node Tests.

Devices monitored for performance and capacity.

Devices monitored for SRST.

Performing Software Updates in Common Services

You can view a list of all CiscoWorks related bundles and products currently installed on your system using this option. For software updates the default site is Cisco.com.

For more details, select Administration > Software Center (Common Services) >  Software Update and view the online help.

Viewing and Updating License Information

To verify both Operations Manager and Service Monitor license status select Administration > Server Administration (Common Services) >  Administration > Licensing. For detailed instructions, click Help to view the Common Services help.


Note The Operations Manager 8.0 license also supports Operations Manager 8.7. The Service Monitor 8.0 license also supports Service Monitor 2.2.


Configuring Cluster Trunk Utilization

You can configure the maximum capacity for trunks (maximum concurrent calls) and gateways (maximum channels). You can either configure the maximum capacity for a particular trunk or gateway, or you can use a CSV file to import the trunk utilization configuration data for all clusters.

After you configure Operations Manager, trunk utilization data is available in these locations:

Inbound and outbound utilization for the last 24 hours and call volume for each trunk in a Route Group details view.

Trunk utilization and call statistics charts for a maximum 72 hours from Fault Monitor Event Details Actions link.

Trunk utilization and call statistics charts for a specific cluster device from the Diagnostics view (Cluster View > UCM Cluster Route Pattern Summary > Utilization or Call Volume icon links).

You must also perform the following tasks to ensure Operations Manager can monitor your Unified CM trunk utilization:

1. Configure the Unified CM so that it can forward CDR-based data. See Configuring CDR Forwarding on Cisco Unified CMs

2. Ensure the Service Monitor is sharing data with Operations Manager. See Accessing a Service Monitor Server

3. Enable any polling parameters required. See Editing Polling Parameters

To configure trunk utilization and collect data on your Unified CM clusters:


Step 1 Select Administration > Configuration > Trunk Utilization Configuration.

The Trunk Utilization Configuration Service Monitor page appears.

Step 2 From the drop-down, select the cluster name you want to configure.

Step 3 Select one of the following gateway or trunk types on this cluster by clicking the radio button. Options include:

MGCP Gateway—Automatically configured with a default setting.

H.323 Gateway—Not automatically configured.

H.225 Trunk—Not automatically configured.

SIP Trunk—Not automatically configured.

Inter-Cluster Trunk—Not automatically configured.


Tip The easiest way to create the configuration file is to first use the export function and export to a file. Then modify the data in the file as needed. Since all gateways and trunks are listed in the file, you need only enter values into the file.


Step 4 To import or export trunk utilization data to all clusters:

a. To export the selected cluster's trunk configuration, click Bulk Export, then click Export in the following window to accept the default named export CSVfile. You may also browse to a different location to store the export file.

b. Click Bulk Import to import cluster trunk utilization configuration data from a CSV file, then click Browse to locate the CSV file. Click Import.

Step 5 Click Configure Maximum Capacity to set the maximum number of calls on this cluster.

The Maximum Capacity Configuration Service Monitor window displays.

a. In the Configure Channels (or Configure Concurrent Calls) field, enter the maximum capacity.

b. Select the check box for the gateways or trunks that you want the setting to apply to.

c. Click Apply.

d. Click Close.


Setting Miscellaneous System Settings

This topic covers the following:

Setting System-Wide Parameters Using System Preferences

Using Logging to Enable and Disable Debugging

Setting System-Wide Parameters Using System Preferences

To set system-wide parameters using system preferences:


Step 1 Select Administration > System Settings > Miscellaneous > Preferences.

The System Preferences page appears.

Step 2 Enter data described in the following table.

GUI Element
Description/Action

Trap Forwarding Parameters table

(Optional) Enter up to three recipients for traps:

Trap Server n (where n is a number from 1 to 3)—Enter an IP address or DNS name.

Port—Enter a port number on which the host can receive traps.

By default, Operations Manager does not forward traps.

For more information see:

Processed SNMP Traps.

Configuring SNMP Trap Receiving and Forwarding.

CiscoWorks Servers table

(Optional) For each CiscoWorks server (RME, Campus, and CiscoView), do the following:

Protocol—Select http (or https if SSL is enabled on the server).

Server—Enter the IP address or DNS name.

Port—Enter the port number used to start CiscoWorks on the server; the port number is usually 1741 when the protocol is http and 443 when the protocol https.

Operations Manager can use this information to launch these CiscoWorks products.

SNMP Trap Community field

Enter a read community string.

Trap Receiving Port field

Enter a port to change the port on which Operations Manager listens for SNMP traps. The default is 162. For more information, see Configuring SNMP Trap Receiving and Forwarding.

For a list of ports that are already in use, see Ports and Protocols that Operations Manager and other CUCM Applications Use.

SMTP Server field

Enter a fully qualified SMTP server name for Operations Manager to use when sending e-mail notifications. For more information, see Using Notifications.

See Ensuring that E-Mail Notifications Are Not Blocked.

Purging Scheduler

Select the time of day to start purging the Event History database:

Hour—From 0 to 23

Minute—From 0 to 50 in 10-minute intervals

The default is 00:00. Purging maintains 31 days of data in the database.

Review the information in Scheduling Operations Manager Tasks to ensure that daily purging does not conflict with the other scheduled jobs listed there.

Static NAT Environment

Enables the option for NAT-enabled devices throughout your network. This allows NAT devices to be monitored by Operations Manager. If this check box is not selected, the edit and view device pages do not include NAT-specific data input such as Local IP or DNS Name.


Step 3 Click Apply.


Using Logging to Enable and Disable Debugging

Operations Manager writes application log files for all major functional modules. By default, Operations Manager writes only error and fatal messages to these log files. You cannot disable logging. However, you can:

Collect more data when needed by increasing the logging level

Return to the default logging level as the norm

Access and delete log files. See Accessing and Deleting Log Files.

To view the Logging Configuration page, select Administration > System Settings > Miscellaneous > Logging.

You cannot disable logging. Operations Manager will always write error and fatal messages to application log files.

For each Operations Manager functional module, the Error check box is always selected; you cannot deselect it.

To set all modules to Error, the default logging level:


Step 1 Click the Default button.

A confirmation page is displayed.

Step 2 Click OK.


To change the logging level for individual modules:


Step 1 For each module that you want to change, select one (or deselect all) of the following logging levels:

Warning—Log error messages and warning messages

Info—Log error, warning, and informational messages

Debug—Log error, warning, informational, and debug message


Note Deselecting all check boxes for a module returns it to Error, the default logging level.


Step 2 Review your changes.

To cancel your changes, click the Cancel button. Otherwise, click the Apply button.

If you click the Apply button, it starts resetting the changed logging levels for the Operations Manager functional modules.


You can adjust the number of log files that can exist in Operations Manager by changing the SM_BACKUP_FILE_LIMIT setting. The default is 1,000 files, and there is no parameter for existing file size.

You can start a new log file by using the roll_log utility, which you invoke using the dmctl command. Run the following commands:

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>
 
   

In the command, C:\Program Files\CSCOpx refers to the path where Operations Manager is installed on the server. If you selected the default directory during installation, it can be entered as "C:\Program Files\CSCOpx" or C:\PROGRA~1\CSCOpx. If you did not select the default directory during installation, replace C:\Program Files with the exact path.

When this command is invoked, an informational message is written to the end of the current log file, the file is renamed, and a new log file is created. Best practice is to create a script that will test the log file size and make a call to dmctl roll_log on a daily basis.


For information about changing the logging level for the system application MIB, see Viewing the System Application MIB Log File.

Accessing and Deleting Log Files

Each Operations Manager module writes log files to its own folder within the <NMSROOT>\log\CUOM folder. Table 20-8 lists each Operations Manager module, the name of the folder where the log files are stored, the related log files, and whether the files are automatically saved or deleted (also referred to as rotated).

NMSROOT is the folder where Operations Manager is installed on the server. If you selected the default directory during installation, it can be entered as "C:\Program Files\CSCOpx" or C:\PROGRA~1\CSCOpx.

When a log file reaches a preset maximum size, the module backs up the file and starts writing to a new log file. The maximum size for a log file varies by module. The maximum number of backed up log files that a module keeps also varies. When the preset maximum number of backup files stored is reached, Operations Manager deletes the old files.


Tip If the log files are not rotated, you should run the log rotation utility, logrot, described in the CiscoWorks Common Services documentation on Cisco.com to manage these files.


Operations Manager does not automatically reset the DFMServer log file (DFM.log). To maintain good system performance, back up this file when it grows larger than 30 MB. See Maintaining the DFM Log File.

By default, Operations Manager writes error messages only to log files. You can change the logging level and thereby affect the amount of information stored in log files. To do so, see Using Logging to Enable and Disable Debugging.

Table 20-8 Operations Manager Log Files by Module 

Function/Module
Folder in NMSROOT
Log Files
Files Rotated? 1

Application and Connectivity Poller

\log\cuom\VHM

Poller.log

TISPollerLogger.log

Yes

DataPurge

\log

DataPurge.log

Yes

Detailed Device View

\log\cuom\DDV

DDV.log

Yes

Device Pool

\log\cuom\

DevicePoolServer.log

Yes

Device Management

\log\cuom\TIS

DCRAdapter.log

DeviceManagement.log

TISDBLog.log

TISServer.log

TISServer_stdout.log

TISServer_sterr.log

Yes

Event Customization

\log\cuom\EPM

EventCustomizationsAudit.log

Yes

Events Display

\log\cuom\AAD

AAD.log

Yes

Event History

\log\cuom\FH

FHUI.log

FHCollector.log

FHServer.log

Yes

Event Processing Adapters

\log\cuom\epa

adapterServer.log

dfmEvents.log

vhmEvents.log

Yes

Event Promulgation Module (EPM)

\log\cuom\EPM

ClearedDroppedEvents.log

EPM.log

EPMDroppedEvents.log

EPMServer.log

EventPlugin.log

FloodDroppedEvents.log

Yes

Yes

No

Graphics Utility

\log\cuom\TGU

TGU.log

TGU_DataProcessor.log

Yes

IP Phone Information Facility

\log\ipiu

ipiuapp.log

Yes

IP Phone Information Facility Server

\log

pif.log

No2

IP Phone Outage Status

\log\cuom\PR

PhoneEvent.log

PhoneReachability.log

No

Yes

IP SLA Library

\log\cuom\IPSLA

STL.log

Yes

IPC Discovery

\log\cuom\discovery

discovery.log

NGD1.log

NGD2.log

Yes

IPT Health Report

log\cuom\ipthr

ipthr.log

Yes

Inventory Collection Schedule

\log\cuom\Rediscovery

Rediscovery.log

Yes

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

Yes

Inventory Interactor

\log\cuom\vhm

CiscoCommunicationsManagerOrClusterGrouping.log

Interactor.log

Yes

Inventory Service

\log\cuom\tis

DCRAdapter.log

TISServer.log

Yes

Logging

ils

ItemLogService.log

MultiProc-Logger.log

Yes (after size reaches 500 KB).

Node-to-Node Tests Common Utilities

\log\cuom\IPSLA

DAL.log

plib.log

Yes

Node-to-Node Tests Data Poller

\log\cuom\IPSLA

WPUSS.log

WPU_DataPoller.log

WPUDcache.log

Yes

Node-to-Node Tests Device Management

\log\cuom\IPSLA

DMAudit.log

WPUDM.log

No

Yes

Node-to-Node Tests Management

\log\cuom\IPSLA

SM.log

SMAudit.log

Yes

No

Notification Services

\log\cuom\nots

nots.log

nots_dropped_events.log

notifications_audit.log

notifications_failures.log

notifications_success.log

Yes

Personalized Reports

\log\cuom\ipthr

ipthr.log

Yes

PTM Adapter for Data Settings

\log\cuom\cfi

PollingThresholdAdapter.log

Yes

PTM Adapter for Voice Settings

\log\cuom\vhm

VHMPollingThresholdAdapter.log

Yes

Polling and Threshold Manager

\log\cuom\PTM

PTMClient.log

PTMDB.log

PTMOGS.log

PTMPTA.log

PTMServer.log

Yes

portal

\log\cuom\portal

cwportal.log

Yes

Purging Scheduler

\log\cuom\DPS

DPS.log

Yes

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

No

No

No

Yes

Yes

Yes

Self-Diagnostic Report

\log\cuom\sdr

sdr.log

Yes

Service Level View Server

\log\cuom\topo

Topogc.log

Topology_Client.log

Topology_Server.log

Yes

Service Quality Events Display

\log\cuom\QOVAD

QOVAD.log

Yes

Service Quality Manager

\log\cuom\QoVM

QoVMServer.log

No

SQTRAPS

\log\cuom\SQTraps

Traps.log

Yes

Synthetic Testing Server

\log\cuom\

STServer.log

ama-ani.log

No

Yes

Synthetic Testing UI

\log

ct-ui.log

Yes

View Manager

\log\cuom\VGM

vgm.log

Yes

View Severity Manager

\log\cuom\vsm

AlertInfo.log

GroupHandler.log

UserInfo.log

vsmServer.log

Yes

1 For information on how to rotate logs that may require rotation, see Cisco.com for the CiscoWorks Common Services product documentation for information on the logrot utility.

2 For very large networks, the maximum audit entry size supported by the IP Phone Information Facility Server (pif.log) is 70,000 K.


The Operations Manager application logging service also maintains log files under the NMSROOT\log\cuom folder. The configuration files for each module are located in NMSROOT\log\conf.

Security Considerations

These topics address some important Operations Manager security issues:

File Ownership and Protection

SSL

SNMPv3

Changing the Password for Operations Manager Databases

File Ownership and Protection

Security for Operations Manager files is based on the same standards used for CiscoWorks.


Caution Do not change the protection of any file or directory to be more restrictive. You may, if you wish, make the protections less restrictive.

All Operations Manager files are installed with owner CASUSER. Only CASUSER can create, delete, or edit the files installed in NMSROOT. NMSROOT is the directory where Operations Manager is installed on your system. If you selected the default directory during installation, it can be entered as C:\Program Files\CSCOpx or C:\PROGRA~1\CSCOpx.


Note File protections are not enforced on FAT partitions.


SSL

Secure Socket Layer (SSL) is an application-level protocol that enables secure transactions of data through privacy, authentication, and data integrity. It relies upon certificates, public keys, and private keys. You can enable or disable SSL depending on the need to use secure access.

Operations Manager supports SSL between clients and the server.

Enabling SSL Between the Browser and the Server

When you start Operations Manager, the login page always opens in secure mode, providing secure access between the client browser and the Operations Manager server. In secure mode, SSL is used to encrypt the transmission channel between the browser and the server. To use secure mode throughout Operations Manager, enable SSL in Common Services.

If you enable SSL on a system with Operations Manager and Service Monitor, SSL is enabled for both applications.


Caution Remember to manually stop the OMHealthMonitor Windows Service when you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.

To enable SSL between the browser and the server:


Step 1 Select Administration > Server Administration (Common Services) >  Security > Browser-Server Security Mode Setup.

The Browser-Server Security Mode Setup dialog box appears.

Step 2 Select the Enable check box.

Step 3 Click Apply.

Step 4 Log out from Operations Manager, and close all browser sessions.

Step 5 Restart the daemon manager from the command line by entering these commands:

net stop crmdmgtd 
net start crmdmgtd 
 
   

Step 6 Restart the browser and use the secure URL to restart Operations Manager:

https://<servername>:443
 
   

If you enter http://<servername>:1741 in your browser and SSL is enabled, you will be directed to the secure URL.


SNMPv3

Operations Manager supports SNMPv3 (authentication and access control but no data encryption) between server and devices to eliminate leakage of confidential information. This provides packet-level security, integrity protection, and replay protection, but does not encrypt the packets.

Changing the Password for Operations Manager Databases

Before You Begin

The procedure in this topic enables you to change the password for the following Operations Manager databases:

itemEPM—Event promulgation

itemFH—Event History

itemInv—Inventory

itemIpiu—IP phone information

qovr—Cisco Unified Service Monitor


Caution Remember to manually stop the OMHealthMonitor Windows Service when you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.

To change the password for the Operations Manager database:


Step 1 At the command prompt on the Operations Manager server, stop the daemon manager by entering the following command:

net stop crmdmgtd
 
   

Step 2 Change directory to NMSROOT\conf\itemDb\bin. For example:

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

NMSROOT is the folder where Operations Manager is installed on the server. If you selected the default directory during installation, it can be entered as "C:\Program Files\CSCOpx" or C:\PROGRA~1\CSCOpx.

Step 3 Enter ChangeItemDbPasswd.pl, providing a new password as input. For example:

ChangeItemDbPasswd.pl newpassword
 
   

Step 4 Restart the daemon manager by entering the following command:

net start crmdmgtd
 
   

Device Support

When support for new devices becomes available for Operations Manager, Incremental Device Updates (IDUs) will be announced on the planner page for Operations Manager on Cisco.com. Visit the planner page for announcements, downloads, and installation instructions for IDUs as they become available.

When a new IDU becomes available, you can download it from Cisco.com.

For device support information, see Supported Device Table for Cisco Prime Unified Operations Manager on Cisco.com at http://www.cisco.com/en/US/products/ps6535/products_device_support_tables_list.html.

Performing System Administration Tasks

You can use Common Services to perform many system administration tasks, including the following:

Configuring Users (ACS and Local RBAC)

Creating Self-Signed Security Certificates Yearly

Backing Up and Restoring Operations Manager Data

Starting and Stopping Operations Manager Processes

Maintaining Log Files

Viewing Software Version or License Information

Finding the Build ID for an Installed Operations Manager (or Service Monitor)

Configuring Your System for SNMP Queries

Configuring Security for SNMP Queries

Viewing the System Application MIB Log File

Configuring Users (ACS and Local RBAC)

Common Services provides the mechanism for authenticating and authorizing users. What users can see and do is determined by their user role. System Administrators can perform the following tasks:

Create users and assign user roles to the user.

Create new user roles and assign specific tasks to the role.

Authorize users to view device groups (device level authorization). Users can only see devices that they are authorized to see.

Common Services provides two different mechanisms or modes for authenticating users. Both modes provide you with the same capabilities.

Following are the two modes for authenticating users:

Local RBAC Mode (default mode)—This is the built-in capability of Common Services for authenticating and authorizing users. Local RBAC mode assigns roles, along with privileges associated with the roles.

To understand how each user role relates to tasks in Operations Manager, select Administration > Server Administration (Common Services) > Security > Role Management Setup and select the role for which you want to see task permissions. Clicking the role opens a task tree that you can traverse to check what permissions the role has been given.

CiscoSecure Access Control Server (ACS) Mode—Requires ACS to be installed on your network and Operations Manager must be registered with the ACS. ACS specifies the privileges associated with roles. For more information, refer to Configuring Users Using ACS Mode.

If Common Services is using ACS mode, Operations Manager must also use ACS mode; otherwise, Operations Manager users will not have any permissions. However, if another instance of Operations Manager is already integrated with ACS, the new Operations Manager will also be integrated with ACS.

Configuring Users In Local RBAC Mode

You can add, edit, or delete users in Local RBAC mode.

To configure users, using Local RBAC mode:


Step 1 Verify that Operations Manager is using Local RBAC mode:

a. Select Administration > Server Administration (Common Services) > Security > AAA Mode Setup.

b. Verify that Local RBAC is selected.

Step 2 Configure users:

a. Select Administration > Server Administration (Common Services) >  Security > Local User Setup. The Common Services Local User Setup window opens.

Click the Help button on the Local User Setup window for configuration step details.



Note For a user to administer Cisco Prime UOM, the user needs to be added into the Local RBAC database in Common Services. To allow a user that is part of any other Common Services database, for example, LAN Management Solution, to administer Cisco Prime UOM, you need to export the user from that Common Services database, and then import into the Common Services database that is part of the local Cisco Prime UOM installation


Configuring User Roles in Local RBAC Mode

You can add, edit, copy, or delete user roles in Local RBAC mode.


Note The Fault Monitoring dashboard and the Diagnostic Views dashboard are accessible by all users by default, access restrictions are controlled only by device level authorization, which is done by giving users access to the devices that they need to view.
If you are creating custom roles, you must make sure that Events Subsystems access is mandatory for the users.


Local RBAC mode provides default user roles. They are listed in Table 20-9 from least privileged to most privileged.

To configure user roles, using Local RBAC mode:


Step 1 Select Administration > Server Administration (Common Services) > Security > Role Management Setup. The Role Management Setup window opens.

Step 2 Configure Roles. Click the Help button on the Role Management Setup window for configuration step details.


Table 20-9 Local RBAC User Roles

User Role
Description

Help Desk

Can access network status information only. Can access persisted data on the system and cannot perform any action on a device or schedule a job which will reach the network.

Network Operator

Can perform all Help Desk tasks. Can perform tasks related to network data collection. Cannot perform any task that requires write access on the network.

Network Administrator

Can perform all Network Operators tasks. Can perform tasks that result in a network configuration change.

System Administrator

Can perform all CiscoWorks system administration tasks.


Customizing User Roles

You can configure user roles to restrict access to all Operations Manager displays. You can also restrict access to devices and applications.

Administrators can use existing user roles or create their own roles. You can also remove all the custom roles and retain only the predefined roles, see Removing Custom Roles Using CLI in the Common Services online help.

Example Scenario for Device-Based Custom User Role

Company X needs to set up a group of users to manage specific groups of devices in different buildings (or different customers for a managed services provider). Company X wants to customize their help desk user to manage one or more internal or external customers (for example, Company Z and Company Y). This user needs access to the customers endpoints including its associated Cisco Unified Communications Manager information.

Follow these overview steps to fulfill this need:

Use Administration > Server Administration (Common Services) >  Security > Role Management Setup to copy the Help Desk user role. After copying the user role, you can then customize the role so that it is authorized to view specific types of devices. For configuration step details, see the Common Services Online Help (click the Help button on the Role Management Setup page).

Configure the user so that he has authorization to view the device group (create a new user if needed). Use Administration > Server Administration (Common Services) >  Security > Local User Setup. For configuration step details, see the Common Services Online Help (click the Help button on the Local User Setup page).


Note For a user to be able to work with a specific group of devices, you must make sure that Device level Authorization is enabled for the user. If you are using the multiple end-customer version of Operations Manager, this also enables the user to see specific customer devices.


Configuring Users Using ACS Mode

To use this mode for Operations Manager, Cisco Secure ACS must be installed on your network, and Operations Manager must be registered with ACS. You need to use the HTTP ACS Administrator login to allow Operations Manager to register with the ACS.

To configure users, using the ACS mode:


Step 1 Verify which mode the your server is using.

To do this, from the Common Services home page, select Administration > Server Administration (Common Services) > Security > AAA Mode Setup and check which Type radio button is selected: ACS or Local RBAC.

Step 2 Verify whether Operations Manager is registered with ACS (if ACS is selected) by checking the ACS server.

Step 3 To edit ACS roles:

Refer to the ACS online help (on the ACS server) for information on editing roles.

Refer to the Common Services online help for information on the implications of ACS on the DCR (specifically, role dependencies).

If you want to provide access to a cluster for any user, all the devices in the cluster must be explicitly ed into the ACS configuration for that user. It should include Unified CM nodes, gateways, Unity devices, gatekeepers, and so on.

If you edit Operations Manager roles using ACS, your changes will be propagated to all other instances of Operations Manager that are using Common Services servers that are registered with the same ACS server.


Using Operations Manager in ACS Mode

Before performing any tasks that are mentioned here, you must ensure that you have successfully completed configuring Cisco Secure ACS with the Operations Manager server.

If you have installed Operations Manager after configuring the CiscoWorks Login Module to ACS mode, then Operations Manager users are not granted any permissions. However, the Operations Manager application is registered to Cisco Secure ACS.


Note The System Identity Setup user that is defined in the CiscoWorks server must be ed to the Cisco Secure ACS, and this user must have Network Administrator privileges.


CiscoWorks login modules allow you to add new users using a source of authentication other than the native CiscoWorks server mechanism (that is, the CiscoWorks Local login module). You can use the Cisco Secure ACS services for this purpose.

By default, the Local RBAC (CS server) authentication scheme has five roles in ACS mode. They are listed here from least privileged to most privileged:

Help Desk

User with this role has the privilege to access network status information from the persisted data. User does not have the privilege to contact any device or schedule a job that will reach the network.

Example: Launch Fault Monitor and Diagnostics view.

Approver

User with this role has the privilege to approve all Operations Manager tasks. User can also perform all the Help Desk tasks.

Example: Launch Fault Monitor.

Network Operator

User with this role has the privilege to perform all tasks that involve collecting data from the network. User does not have write access on the network. User can also perform all the Approver tasks.

Example: Add a synthetic test.

Network Administrator

User with this role has the privilege to change the network. User can also perform Network Operator tasks.

Example: Set the default view for Fault Monitor.

System Administrator

User with this role has the privilege to perform all CiscoWorks system administration tasks. See the Permission Report from CiscoWorks home page (Administration > Server Administration (Common Services) > Reports > Permission Report).

Example: Configure LDAP.


Cisco Secure ACS allows you to edit the privileges for these roles. You can also create custom roles and privileges that help you customize Common Services client applications to best suit your business workflow and needs.

To edit the default CiscoWorks privileges, see Cisco Secure ACS online help. (On Cisco Secure ACS, click Online Documentation > Shared Profile Components > Command Authorization Sets.)

Editing CiscoWorks Roles and Privileges in Cisco Secure ACS

If another instance of Operations Manager is registered with the same Cisco Secure ACS, your instance of Operations Manager will inherit those role settings. Furthermore, any changes you make to Operations Manager roles will be propagated to other instances of Operations Manager through Cisco Secure ACS.

If you reinstall Operations Manager, your Cisco Secure ACS settings will automatically be applied upon Operations Manager restart.


Note The Fault Monitoring dashboard and the Diagnostic Views dashboard are accessible by all users by default, access restrictions are controlled only by device level authorization, which is done by giving users access to the devices that they need to view.
If you are creating custom roles, you must make sure that Events Subsystems access is mandatory for the users.


To edit CiscoWorks roles and privileges in CiscoSecure ACS:


Step 1 Select Shared Profile Components > Operations Manager and click on the Operations Manager roles that you want to edit.

Step 2 Select or deselect any of the Operations Manager tasks that suit your business workflow and needs.

Step 3 Click Submit.


Device-Based Filtering in ACS

You can configure ACS to restrict access to all Operations Manager displays. You can also configure ACS to restrict access to devices and applications. Device-based and application-based filtering affects:

Devices—To be able to view information for a device, configure the device, and configure diagnostic tests that involve the device, you must have access to it.

Phones—To be able to view information for a phone, you must have access to either the switch connected to the phone or to the Cisco Unified Communications Manager, to which the phone is registered.

ACS does not perform any filtering on VLANs.

Device-based filtering is not performed at the Cisco Unified Communications Manager cluster level. All users can see cluster-level in the Event History report as long as you have provided access to each cluster. For any user, all devices in a cluster must be explicitly ed into the ACS configuration for that user. It should include Unified CM nodes, gateways, Unity devices, gatekeepers, and so on.

Publishers must be ed to the user in ACS so that device clusters can be viewed in the Diagnostics view.

Device-based filtering can only be performed on the following Operations Manager displays:

Fault Monitor—All displays.

Diagnostics—All displays.

Reports:

IP Phones—All displays.

Video Phones—All displays.

Service Quality History—All displays.

Personalized Report—All displays.

Event History—All displays.

Administration—All displays.

Administration > Device Management—All displays.

Administration > Device Management > Device Configuration—All displays.

Administration > Device Management > Inventory Collection—All displays.

Administration > Device Management > Auto Discovery Configuration—All displays.

If any user starts the inventory collection process, all devices managed by Operations Manager are probed (not just those for which the user has access).

Administration > System Settings—All displays.

Administration > Diagnostic Tests—All displays.

Administration > UC Management Suite—All displays.

Administration > Polling and Thresholds—All displays.

Administration > Notifications—All displays.

Administration > Notifications > Event Sets.

Administration > Notifications > Notification Criteria.

If you update device access in ACS, Operations Manager does not update running notifications.

Only the Polling Parameters Summary and the Thresholds Parameters Summary pages are filtered.

Most Operations Manager tasks are device-centric. The devices listed for you while performing the Operations Manager tasks are based on your role and associated privileges, defined in Cisco Secure ACS.

Refer to the Common Services online help for important information on how ACS custom roles affect the DCR and device-based filtering.

Changing ACS Mode to CiscoWorks Local RBAC Mode

If your system is configured to use ACS, but you want to change it to CiscoWorks Local RBAC mode, do the following:


Caution Remember to manually stop the OMHealthMonitor Windows Service when you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.

To change ACS mode to Local RBAC mode:


Step 1 Stop the CiscoWorks daemon manager by entering the following command:

net stop crmdmgtd
 
   

Step 2 Go to Operations Manager install Directory (the default is C:\PROGRA~1\CSCOpx)

Step 3 Change the directory to bin.

Step 4 Run the following command:

perl ResetLoginModule.pl 
 
   

You should see the following message:

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

Step 5 Restart the CiscoWorks daemon manager by entering the following command:

net start crmdmgtd
 
   

The system should be in non-ACS mode.


Group-Based Filtering in Local RBAC

You can configure Local RBAC to restrict access to all Operations Manager displays. You can also configure Local RBAC to restrict access to groups. Group-based and application-based filtering affects:

Devices—To be able to view information for a device, configure the device belonging to a group, and configure diagnostic tests that involve the device, within a group you must have access to that group.

Phones—To be able to view information for a phone, you must have access to the Cisco Unified Communications Manager to which the phone is registered and is within a group to which you have access.


Note For multiple end-customer users, you can assign different customer groups to be managed by different users.


Creating Self-Signed Security Certificates Yearly

When you install Operations Manager, Operations Manager creates a self-signed security certificate on the server. Users on some client systems must install the certificate; see Responding to Security Alerts. Self-signed security certificates expire one year from the date of creation.

Create a new self-signed security certificate yearly before the certificate expires. You can also do so after the certificate expires. However, users might not be able to access Operations Manager until you complete this task.

To create self-signed security certificates:


Step 1 Select Administration > Server Administration (Common Services) > Security > Certificate Setup.

The Certificate Setup page appears.

Step 2 Enter the values for the fields described in the following table.

Field
Description
Usage Notes

Country Name

Name of your country

Use two-character country code.

State or Province

Name of your state or province

Use two-character state or province code or complete name of state or province.

Locality

Name of your city or town

Use two-character city or town code or complete name of city or town.

Organization Name

Name of your organization

Use complete name or abbreviation for your organization.

Organization Unit Name

Name of department in your organization

Use complete name or abbreviation for your department.

Host Name

Name of server on which Operations Manager is installed

Use the DNS name of the server.

Use the proper domain name, which should already be displayed in the Host Name field.

Email Address

Your e-mail address


Step 3 Click Submit.

Alternatively, click Restore to Default to clear all fields and re-enter information.)


Backing Up and Restoring Operations Manager Data

This topic covers how to backup your data on a regular basis (for example, weekly) and how to restore that data if a failure or corruption occurs.

To completely back up and restore Operations Manager, you must perform both of these procedures:

Backing Up and Restoring Detailed Device View Configurations Using Operations Manager Utilities

Backing Up and Restoring Using CiscoWorks

Fixing DB Fragmentation

If your Operations Manager database is over 10 GB, it may need to be unloaded and reloaded before backing up. For details on the steps to perform, see Handling Sybase Database Issues Before Backing Up. If your Event History database grows to more than 2 GB, consider running the Perl dbreload utility as a preventative measure (see Fixing DB Fragmentation).

Backup and restore (including database backup and user configuration data backup) is supported only from version 8.0 and 8.5 to 8.7. Backup and restore must be done on the same machine. It is possible to backup and restore to the same version. You should store your backed up database on a different hard disk or a server other than Operations Manager.


Caution If your database backup has a different admin password than the existing Operations Manager server, the admin password reverts to the restored admin password after an upgrade.

Scheduled backups should occur weekly or monthly; not daily. You must delete the old versions of the backed up files manually.


Note Whenever you perform data migration using the CMT tool and an upgrade from Service Monitor 8.0 to 8.6, the previous calls grading will display as Unknown after the upgrade. This occurs in all CDR, CVTQ, and Sensor reports. Grading occur properly for the new calls that are made after the upgrade. No problems exist for the 8.5 to 8.6 upgrade.


For details on known issues, see the online release notes on Cisco.com.

Backing Up and Restoring Detailed Device View Configurations Using Operations Manager Utilities

The backup utility backs up the states of all components of all types of monitored or partially monitored devices (except for those mentioned in the following note) in the Detailed Device View. It does not cover suspended devices.

Database backup and restore (which includes the database and user configuration data of all Operations Manager modules) is supported only from version 8.0 to 8.5 and 8.6. Backup and restore must be done on the same machine.

We recommend that you perform database backups on a weekly or monthly basis, manually delete old backup files, and store backups on a separate disk or server.

Operations Manager does not restore Detailed Device View configurations on voice services, system processor, hard disk, virtual memory, and RAM components for Cisco Unified Communications Manager machines.

Operations Manager uses RTMT polling, not device MIB polling, to create the above components and therefore does not display the above data in the Operations Manager Detailed Device View in 8.7 when you do an upgrade from Operations Manager releases prior to 8.0.


Caution Ensure that the daemon processes for this system are up and running to allow for data backup.

The restore utility restores the managed states of non suspended devices in the Detailed Device View.

To run the backup utility:


Step 1 Open a DOS prompt and enter:

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

Where default saves the managed states of all monitored and partially monitored devices to the inventoryBackup file. No user input is needed while the script is running.


Caution Backup on a network drive is not supported. Even though the CLI is functional, its use is not recommended due network connectivity issues. As a result, the mapped network drive on the server will not be available for selection in the user interface.

If you prefer to enter a specific filename or a list specific device IP addresses, enter:

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

The script prompts you to enter the filename and device information.


Caution After an Operations Manager 8.7 upgrade, you can run the inventoryRestore script only after rediscovering all devices from the Operations Manager Device Management interface. During device rediscovery, the system may be under a heavy load, resulting in the user interface becoming unresponsive. The dashboards may not refresh during this time. We recommend that you wait to perform any user interface actions until device discovery is complete.

Step 2 To run the restore utility after a failure or database corruption, open a DOS prompt and enter:

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

Where default restores the data saved in the inventoryBackup.xml file. No user input is needed while the script is running.

If you want to input your own filename enter:

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

The script prompts you to enter the filename you previously created using the backup utility.


Backing Up and Restoring Using CiscoWorks

This topic explains how to access the backup applications, such as Back Up Data Now and Schedule Backup. This topic also explains how to locate the online help procedures for restoring data.

This procedure backs up the databases for Common Services and Operations Manager. It does not back up:

The state of components in the Detailed Device View (DDV)—You must back them up using Backing Up and Restoring Detailed Device View Configurations Using Operations Manager Utilities.

The database for Service Monitor—You must back up the Service Monitor database manually; see User Guide for Cisco Unified Service Monitor.


Caution Backup on a network drive is not supported. Even though the CLI is functional, its use is not recommended due network connectivity issues. As a result, the mapped network drive on the server will not be seen from the user interface for drive selection.

To back up and restore data using CiscoWorks:


Step 1 Select Administration > Server Administration (Common Services) > Administration > Backup.

The Backup Job page appears.

Step 2 Click the Help button and follow the instructions for backing up and restoring data.


Database files are stored using the backup directory structure described in Table 20-10.

Format—/generation_number/suite/directory/filename

Example—/1/itemFh/database/itemFh.db

Table 20-10 Operations Manager Backup Directory Structure 

Option
Description
Usage Notes

generationNumber

Backup number

For example, 1, 2, and 3, with 3 being the latest database backup.

suite

Application, function, or module

When you perform a backup, data for all suites is backed up. The CiscoWorks server suite is cmf. The Operations Manager application suites are:

dfm—Data collection and analysis for devices in IP infrastructure

itemEpm—Event promulgation

itemFh—Event history

itemInv—Device inventory

itemIPIU—Phone information

vhm—Data collection and analysis for voice-enabled devices

wpu—Node-to-Node tests.

directory

What is being stored

Each application or suite listed. Directories include database and any suite applications.

filename

File that has been backed up

Files include database (.db), log (.log), version (DbVersion.txt), manifest (.txt), tar (.tar), and data files (datafiles.txt).


Handling Sybase Database Issues Before Backing Up

If your Operations Manager database is over 10 GB, it may need to be unloaded and reloaded before you perform a backup. A Sybase database failure problem can occur, wherein the database can become corrupt, fail to validate, or grow too large (to over 10 GB, causing the backup procedure to take a long time).

If your database displays any of these problems, use the following procedure to unload and reload the database. You must know your database password to perform this procedure. If you do not know your database password, contact your customer support representative.


Caution Remember to manually stop the OMHealthMonitor Windows Service when you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.


Step 1 Stop the daemon manager:

% net stop crmdmgtd


Tip Ensure you wait until all database processes have stopped running. You can check for running dbeng9 or dbsrv9 processes using the process explorer tool.


Step 2 Unload the database:

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

For example:

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

Step 3 Remove and save the itemFh.db to another directory.

Step 4 Initialize the new database:

% dbinit -p 4096 itemFh.db

Step 5 Reload the new database:

% dbisqlc -c "uid= default username;pwd=default passwd

;dbf=db name" reload.sql

For example:

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

Step 6 Delete the newly created *.DAT and *.SQL files, and restart the daemon manager.

%rm *.dat *.sql
net start crmdmgtd

Fixing DB Fragmentation

To clean up fragmentation (unwanted allocated space) in the Operations Manager FHDB database without losing data:


Step 1 Ensure you know the password of FH db.

Step 2 Create a backup of the file CSCOpx\databases\itemEpm\itemFh.db by copying it to another location.

If you cannot copy this file, stop the daemon manager and then try again.

Step 3 Stop the daemon manager:

net stop crmdmgtd
 
   

Step 4 Unload the database:

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

For example:

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

Step 5 Enter: perl dbRestoreOrig.pl dsn=itemfh dmprefix=FH

Step 6 Reload the database:

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

Step 7 Start daemon manager:

net start crmdmgtd
 
   

Step 8 At the command line, enter: NMSROOT/conf/itemDb/bin/dbreload.pl.

After you invoke the utility, command line options walk you through the steps. This utility reloads all Operations Manager databases given the password. If you do not know the database password, the utility prompts you for a new one, resets it on all the databases, and then executes the reload.


Starting and Stopping Operations Manager Processes

You cannot stop or unregister a process if any process that depends on it is running. You must first stop or unregister all dependent processes, and then stop or unregister the process.


Step 1 Log into Operations Manager as a system administrator.


Caution Remember to manually stop the OMHealthMonitor Windows Service when you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.

Step 2 Select Administration > Server Administration (Common Services)  >  Administration > Process Management.

The Process Management page appears.


Note If a process is not listed, it has not yet been started.


Step 3 Do one of the following:

Select check boxes next to processes that are running and click Stop.

Select check boxes next to processes that are stopped and click Start.


Table 20-11 provides a complete list of Operations Manager-related CiscoWorks processes.

Table 20-11 Operations Manager Related CiscoWorks Processes

Name
Description
Dependency

AdapterServer

Event adapter takes events from backend servers.

None

CDTServer

Collects device inventory and registration information from Unified CM clusters into a single repository.

None

CrossLaunchFramework

Library used by other components for cross launching.

None

DataPurge

Database and data file purging.

jrm

DfmBroker

DFM Broker maintains a registry about VHM and DFM domain managers. A domain manager registers the following information with the broker when its initialization is complete:

Application name of the domain manager

Hostname where the domain manager is running

TCP port at which the HTTP server is listening

When a client needs to connect to the domain manager, it first connects to the broker to determine the hostname and TCP port where that server's HTTP service is listening.

It then disconnects from the broker and establishes a connection to the domain manager.

None

DfmServer

Infrastructure device domain manager, a program that provides backend services for Operations Manager. Services include SNMP data retrieval and event analysis.

The DfmServer log is NMSROOT/Unified Communications s/smarts/logs/DFM.log. For more information, see Maintaining the DFM Log File.

DfmBroker

DevicePoolCollector

The Device Pool data collection module collects data for each monitored Cisco Unified CM cluster. The collection starts once the Publisher is ed or rediscovered in Operations Manager.

Adding or rediscovering subscriber nodes will not trigger device pool collection. This module listens to events in the Inventory Collector module.

InventoryCollector

DevicePoolIntegrator

Provides common APIs to access device pool data to other modules that use this information.

Consumers of device pool data.

DevicePoolCollector

DevicePoolEventMonitor

Uses device pool level information and thresholds to generate events.

DevicePoolIntegrator

EPMDbEngine

Event Promulgation Module (EPM) database engine—Repository for the EPM module.

None

EPMDbMonitor

EPM database monitor.

EPMDbEngine

EPMServer

Sends events to notification services.

EPMDbEngine

FHDbEngine

Event History database engine—Repository for events.

None

FHDbMonitor

Event History database monitor.

FHDbEngine

FHPurgeTask

Event History purge task.

None

FHServer

Event History server.

FHDbMonitor, FHDbEngine, EPMDbEngine, EPMServer

GPF

Performance and capacity monitoring data collection.

ITMOGSServer, INVDbEngine

GpfPurgeTask

Purges performance polling records.

None

INVDbEngine

Device inventory database engine.

None

INVDbMonitor

Device inventory database monitor.

INVDbEngine

InventoryCollector

Phone inventory collector.

EssMonitor

IPCDiscovery

Physical device discovery.

None

IPIUDataServer

Provides information about IP phones.

ESS

IPIUDbEngine

Phone inventory database engine.

None

IPIUDbMonitor

Phone inventory database monitor.

IPIUDbEngine

IPSLAPurgeTask

Purges node-to-node test records.

None

IPSLAServer

Node-to-node test server.

INVDbMonitor, InventoryCollector

ITMCTMStartup

Internal communication process.

None

ITMDiagServer

Diagnostics server.

INVDbEngine, ESS

ITMOGSServer

Operations Manager Object Grouping Service server evaluates group membership.

CmfDbEngine, ESS, DCRServer

IVR

Internal process.

None

NOTSServer

Notification server monitors events and sends notifications based on subscriptions.

EPMDbEngine,
EPMServer,
INVDbEngine,
ITMOGSServer

OMHealthMonitor

Monitors Operations Manager processes and restarts the processes if they have shutdown unexpectedly or are out of memory and are in unstable state.

If a process is out of memory, the logs are backed up and the process is restarted. Administrators should routinely check the FH DB size and run the dbreload utility when the database reaches certain size.

None, except for requirement to be shutdown when performing system maintenance or debugging.

PIFServer

Performs phone discovery, CDP neighbor discovery, monitoring, and phone reachability.

PIFDbEngine, ESS

PTMServer

Polling and thresholds server.

ITMOGSServer

QoVMServer

Service Monitor server.

ESS

QOVR

Service Quality events process.

QOVRDbMonitor

QOVRDbEngine

Service Monitor database engine.

None

QOVRDbMonitor

Service Monitor database monitor.

QOVRDbEngine

QOVRMultiProcLogger

Service Monitor logging.

None

SDRPurgeTask

Purges Self-Diagnostic Reports.

None

SIRServer

Voice model and rule-based engine.

EPMDbEngine, ESS.

SRSTServer

Configures and runs SRST tests.

PIFServer, PMServer, ESS, TISServer

STServer

Periodically runs synthetic tests against Cisco Unified Communications Managers and provides real-time status updates to Operations Manager.

INVDbEngine, ESS

TISServer

Inventory server.

INVDbEngine, EssMonitor

TopoServer

Service level view server.

SIRServer, ITMOGSServer

VHMIntegrator

Integrates voice and infrastructure data.

ESS

VHMServer

Maintains voice data.

DfmBroker

VsmServer

Maintains and evaluates views.

ITMOGSServer


s

Maintaining Log Files

There are two ways to maintain your log files including:

Maintaining the DFM Log File

Maintaining Log Files in CSCOPX\log


Caution Remember to manually stop the OMHealthMonitor Windows Service when you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.

Maintaining the DFM Log File

If the DFM.log file grows larger than 30 MB, there is a risk of Operations Manager performance problems. To prevent such problems, you should back up the log file and start a new one.


Caution Remember to manually stop the OMHealthMonitor Windows Service when you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.

To maintain DFM log files:


Step 1 Stop the CiscoWorks daemon manager by entering the following command:

net stop crmdmgtd
 
   

Step 2 Rename the DFM.log file or copy it to a new location and delete it from the Operations Manager server. You can find the DFM.log file in the NMSROOT/Unified Communications s/smarts/logs/ directory.

NMSROOT is the folder where Operations Manager is installed on the server. If you selected the default directory during installation, it can be entered as "C:\Program Files\CSCOpx" or C:\PROGRA~1\CSCOpx.

Step 3 Allow 15 minutes to elapse from the time you completed step 1, then restart the CiscoWorks daemon manager by entering the following command:

net start crmdmgtd
 
   

A new DFM.log file will be created.


Maintaining Log Files in CSCOPX\log

Most process logs (generally, files under CSCOPx\log\*.log) are not autorotated; however, some files may have autorotation. Table 20-8, "Operations Manager Log Files by Module" includes information on which log files are rotated.

For details on how to maintain log files that are not automatically rotated, see "Configuring Log File Rotation" in the Common Services online help or the User Guide for CiscoWorks Common Services.


Caution Remember to manually stop the OMHealthMonitor Windows Service before you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.

Viewing Software Version or License Information

To view the software version of your Operations Manager, click the About button in the top- right corner of the Operations Manager user interface. This window also displays some license and copyright information.

To view the software version information select Administration > Software Center (Common Services) > Software Update. View the Operations Manager license version under Products Installed.

To view the license information select Administration > Server Administration (Common Services) >  Administration > Licensing.

Finding the Build ID for an Installed Operations Manager (or Service Monitor)

Occasionally for troubleshooting purposes, you may need to know which build of Operations Manager or Service Monitor is installed. You can find the build ID as follows:


Step 1 Select Administration > Software Center (Common Services) > Software Update.

A new window opens.

Step 2 Click the appropriate link (Cisco Unified Operations Manager n.n or Cisco Unified Service Monitor n.n, where n.n is the software release number) under Products Installed.

A new window opens.

Step 3 See the value labeled, Build ID at the top of the page.

For example, Build Id: NT_OM22CS32_20090930_1223.


Note NT_OM22CS32_20090930_1223 is an example that illustrates the build ID format.



Using SNMP to Monitor Operations Manager

Operations Manager supports the host resources and system application MIBs. This support enables you to monitor Operations Manager using a third-party SNMP management tool, so that you can:

Consistently monitor multiple platforms—One platform on which Operations Manager resides and one or more on which applications in the IP Telephony Environment Monitor (ITEM) suite reside.

Access complete hardware and operating system information using the host resources MIB.

Assess application health using the system application MIB, which provides the following information:

Applications that Operations Manager installed.

Processes associated with applications and current process status.

Processes that ran previously and application exit state.

For MIB implementation details and sample MIB walk, see Cisco Prime UOM Support for SNMP MIBs.

This section contains:

Configuring Your System for SNMP Queries

Configuring Security for SNMP Queries

Viewing the System Application MIB Log File


Note You cannot uninstall MIB support; however, you can stop Windows SNMP service and set the startup type to either Manual or Disabled. See Enabling and Disabling Windows SNMP Service.


Configuring Your System for SNMP Queries

Operations Manager installation ensures that the Windows SNMP service is installed and enabled on the server. To set a media server's Windows SNMP services community string rights, see Setting a Media Server's SNMP Services Community String Rights.

This topic includes the following sections:

Determining the Status of Windows SNMP Service

Installing and Uninstalling Windows SNMP Service

Enabling and Disabling Windows SNMP Service

Determining the Status of Windows SNMP Service

Windows SNMP service is a Windows component that you can add or remove when you want to. To enable SNMP queries against the MIBs that Operations Manager supports, SNMP service must be installed and enabled. You can verify the status of Windows SNMP service as follows.

To verify the status of Windows SNMP service:


Step 1 Open the Windows administrative tool Services window.

Step 2 Verify that the following:

SNMP Service is displayed on the Windows administrative tool Services window; if so, Windows SNMP service is installed.

To install Windows SNMP service, see Installing and Uninstalling Windows SNMP Service.

SNMP Service startup type is Automatic or Manual; if so, Windows SNMP service is enabled.

To enable Windows SNMP service, see Enabling and Disabling Windows SNMP Service.


Installing and Uninstalling Windows SNMP Service

Windows online help provides instructions for adding and removing Windows components, such as Windows SNMP service. To locate the instructions, try selecting the Index tab in Windows online help and entering a keyword or phrase, such as installing SNMP service.

To uninstall Windows SNMP service, follow instructions in Windows help for removing Windows components.

When you uninstall Windows SNMP service from the server where Operations Manager is installed, you also remove support for the host resources and system application MIBs. If you want to install support again, see Configuring Your System for SNMP Queries.

Enabling and Disabling Windows SNMP Service

You can enable or disable Windows SNMP service using the Windows administrative tool Services. For instructions to open the Services window, see Windows online help.

To enable and disable Windows SNMP service:


Step 1 Locate SNMP Service in the Services window.

The status and startup type are displayed.

If SNMP Service is not displayed, Windows SNMP service is not installed; see Installing and Uninstalling Windows SNMP Service.

Step 2 Right-click SNMP Service and select Properties.

The SNMP Service Properties window opens:

To disable SNMP service, set Startup Type to Disable and click OK.

To enable SNMP service, set Startup Type to Automatic or Manual and click OK.

To start SNMP service after you enable it, right-click SNMP Service and select Start.


Configuring Security for SNMP Queries

To improve security, the SNMP set operation is not allowed on any Object ID (OID). You should also edit the credentials for SNMP service to not use a default or well-known community string.


Note You do not need to restart SNMP service to edit credentials for it.


To edit SNMP service credentials using the Windows administrative tool Services:


Step 1 Locate SNMP Service in the Services window.

Step 2 Right-click SNMP Service and select Properties.

The SNMP Service Properties window opens.

Step 3 Select the Security tab.

Step 4 Edit the accepted community names and click OK.


Viewing the System Application MIB Log File

The system application MIB log file, SysAppl.log, is located on the server where Operations Manager is installed in NMSROOT/log.

NMSROOT is the directory where Operations Manager is installed on your system. If you selected the default directory during installation, it can be entered as "C:\Program Files\CSCOpx" or C:\PROGRA~1\CSCOpx.

By default, only error messages are written to the log file. To change the logging level, use the following procedure.


Step 1 Log into the server where Operations Manager is installed.

Step 2 Go to the following directory:

NMSROOT\objects\subagent

Step 3 Edit the following file:

conf

Step 4 Look for Property LogFileName. Change the value of PropValue to any of the following:

Debug

Informational

Warning

Error


Changing the Hostname on the Operations Manager Server


Timesaver There are tools available to update the Operations Manager server hostname automatically, using scripts. To access the scripts, go to NMSROOT\bin\systemIdentityChange. To update the hostname, use SystemHostNameChange.pl first and then CUOMHostNameChange.pl.


The procedure below details how to perform the Operations Manager server hostname change manually.

To change the hostname on the Operations Manager server, you must update several files, reboot the server, and regenerate the self-signed security certificate. Afterward, if you have a licensed copy of Service Monitor, you must update the configuration for it.


Caution Remember to manually stop the OMHealthMonitor Windows Service when you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.

If you do not know the password for the cmf database, reset the password as follows:


Step 1 Open a command prompt and go to NMSROOT\bin.

Step 2 Enter the following command:

perl dbpasswd.pl dsn=cmf npwd=newpassword

where newpassword is the new password.

Remember this password. You will need it to complete Step 7.


To change the password:


Step 1 Change the hostname on the server as follows:

a. Change the hostname at My Computer > Properties > Computer Name > Change.

Prevent the daemon manager service from restarting after reboot. From Control Panel, or from Start, open Services and change the startup mode to Manual for the CW2000 Daemon Manager service.

b. Reboot the server.

Step 2 Change the hostname in the md.properties file (NMSROOT\lib\classpath\md.properties).

NMSROOT is the directory where you installed Operations Manager. If you selected the default, it can be entered as "C:\Program Files\CSCOpx" or C:\PROGRA~1\CSCOpx.

Step 3 Change the hostname in the following registry entries:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet.

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\Resource Manager.

Look for all instances of the old hostname under these registry entries, and replace them with the new hostname.

Step 4 Change the hostname in these files:

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

Note the old hostname. You will need it to complete this process.

Enter the new hostname in uppercase letters.

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

Step 5 Create a file, NMSROOT\conf\cmic\changehostname.info, containing the old hostname and new hostname in uppercase in the following format:

OLDHOSTNAME:NEWHOSTNAME
 
   

Note Hostnames in this file are case-sensitive; they must be entered in uppercase, and the new hostname must exactly match the hostname entered in regdaemon.xml.


Step 6 Change all occurrences of the old hostname in the following files:

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

NMSROOT\conf\dfm\Broker.info

Step 7 To ensure that devices ed before you changed the hostname are properly classified in Device Center, enter the following command:

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 is the Common Services database password.

NMSROOT is the directory where you installed Operations Manager.

NewhostName is the new hostname.

OldhostName is the old hostname.

Step 8 From the Control Panel, or from Start, open Services and change the startup mode to Automatic for the CW2000 Daemon Manager service.

Step 9 Reboot the server.

Step 10 Replace the old hostname with the new hostname in the self-signed security certificate and regenerate it:

a. Select Administration > Server Administration (Common Services) > Security > Certificate Setup.

a. For more information, click Help.

If you have a license for Service Monitor, reconfigure it:

a. Open the Service Monitor home page. (See Launching Service Monitor.)

b. Click Help and follow the instructions in the topic Reconfiguring Service Monitor after a Hostname Change.


Service Monitor online help provides detailed instructions for accomplishing the following tasks:

Change the IP address or hostname in each of the following configuration files:

The default configuration file.

The specific configuration file for each Cisco 1040 managed by the Service Monitor.

Copy the updated configuration files from the Service Monitor server to the TFTP server.

Reset the Cisco 1040s.

If Service Monitor is configured to send traps to Operations Manager:

If Operations Manager is installed on the same server as Service Monitor, set up Service Monitor to send traps to the new hostname or IP address.

If Operations Manager is installed on another server, on Operations Manager, delete the Service Monitor and it again.

Changing the IP Address on the Operations Manager Server


Timesaver There are tools available to update the Operations Manager server IP address automatically, using scripts. To access the script, go to NMSROOT\bin\systemIdentityChange. To update the IP address, use SystemIPAddressChange.pl.


The procedure below details how to perform the Operations Manager server IP address change manually.


Caution Remember to manually stop the OMHealthMonitor Windows Service when you perform maintenance activities. Not doing so may result in processes being restarted that have been intentionally stopped. For details on OMHealthMonitor, see Monitoring Operations Manager Process Health.

To change the IP address on the Operations Manager server:


Step 1 Stop the CiscoWorks daemon manager by entering the following command:

net stop crmdmgtd
 
   

Step 2 Change the IP address of the Operations Manager server.

Step 3 Allow 15 minutes to elapse from the time you completed step 1, then restart the CiscoWorks daemon manager by entering the following command:

net start crmdmgtd

Monitoring Operations Manager Process Health

OMHealthMonitor is a Windows Service that monitors Operations Manager processes and restarts them if they have shutdown unexpectedly or are out of memory and are in an unstable state. If a process is out of memory, the logs are backed up and the process is restarted.

Administrators should routinely check the FH DB size and run the dbreload utility when it reaches certain size. It is located in the CSCOpx\HealthMonitor directory.


Caution Whenever you have maintenance or debugging tasks to perform, you must stop the OMHealthMonitor Windows Service so that processes that are intentionally shut down are not inadvertently restarted. Run the following commands:

net stop OMHealthMonitor
net start OMHealthMonitor

This section contains:

Editing Health Monitor Configuration Files

Viewing Backed Up Process Logs

OMHealthMonitor performs the following tasks:

Stores a backup of logs belonging to terminated processes before attempting to restart them.

Ignores all the processes configured by the user and only restarts the remaining processes if they are not running.

Monitors only Operations Manager and CiscoWorks Common Services (CWCS) processes.

Logs debug information into a log file named HealthMonitor.log located in CSCOpx\HealthMonitor\log.

Logs audit information for all restarted processes into an audit log located in CSCOpx\HealthMonitor\audit.

Sends email to the administrator (if configured) when the Audit logs are updated.

For details on the where HealthMonitor stores data, see Table 20-12.

Table 20-12 Health Monitor Directories

Directory Name
Contents

Audit

Contains the audit file, HealthMonitor.audit.

Backup

Contains the backed up log files of restarted processes.

Conf

Contains the required configurations files.

Log

Contains the debug log file, HealthMonitor.log.

scripts

Contains the HealthMonitor.pl Perl script and modules.


Editing Health Monitor Configuration Files

Health Monitor contains several configuration files that allow you to configure log mapping files, certain configurable parameters, logging, and process retry count status settings.

To modify Health Monitor's behavior:


Step 1 Access the following files (see Table 20-13) in the CSCOpx\conf directory to add email-related parameters or change any of the configurable settings:

Table 20-13 Health Monitor Configuration Files

Configuration File Name
Description

HealthMonitor.logConf

Contains the log and audit-related configurations.

RetryAttempts.txt

Contains the count as 0 for all the processes. Increments the count for a process whenever an attempt to start a process has failed.

An example of the file contents follows:

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

Processes.cfg

Contains the processes to be monitored and the mapping of process names to log files to be backed up for each process, in case of an unexpected failure.

To ignore processes, comment out entries so processes are not monitored by this tool.

Example of Format:

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

Operations Manager backs up the logs mentioned in this file whenever a process restarts. For a list of Operations Manager-related CiscoWorks processes, see Table 20-11. For information on Health Monitor backups, see Viewing Backed Up Process Logs.

HealthMonitor.cfg

This file contains the below configurable parameters:

Max Retries—Maximum attempts to start a process.

Initial_Delay—Initial delay in seconds when service is started.

Max Wait Time—Maximum wait time in seconds to check if processes are up.

Monitoring_Frequency—The frequency at which monitoring is performed (in minutes).

Max_Backups—Maximum backups to maintain per process.

SMTP_Server—SMTP mail server address.

Receiver_Email_ID—Email ID of the administrator.

Sender_Email_ID—Email ID used as identity of the sender.

The email-related parameters above (SMTP_Server, Receiver _Email_ID, Sender_Email_ID) do not contain any values.

To receive email information when the audit logs are updated, you can add the values for the email-related parameters.

An example of file contents follows:

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

Step 2 Edit the file using your favorite editor and save the changes when you are finished.

Step 3 Stop and restart the OMHealthMonitor service, to ensure the changes take effect:

net stop OMHealthMonitor
net start OMHealthMonitor


Viewing Backed Up Process Logs

When a process restarts, Health Monitor creates a backup of the logs mentioned in the Processes.cfg file. The backup folder contains subdirectories for each process that it backed up. Within each subdirectory are the zip files which are determined by the setting in Max_Backups.

The oldest backup is purged when a new backup needs to be made and the process has reached the max limit. The zip files will be rotated accordingly. You can open the zip files and view the logs using your editor of choice.

What Happens After an Operations Manager Restart

Some administrative tasks require that you restart Operations Manager. After a restart, there are many changes that occur in Operations Manager monitoring. The following section contains information on how those changes may affect monitoring.

Device Management—Device status and inventory information is saved in the database and are available after the daemon manager restarts.

Phone Information—Phone information is stored in database and is available after a restart. For example, the Phone report will be available after the restart. A new phone discovery is initiated after an Operations Manager restart.

Device Polling—A new polling cycle is initiated. For example, if only half the number of devices are polled in a polling cycle due to a restart, that polling cycle is not resumed in the middle, a new cycle starts.

Events—Already processed events are available after the restart. Events that occurred when the daemon manager was down are not logged.

The poll-based events that were auto-cleared by Operations Manager get regenerated.This is because the AutoClear is generated after a fixed time interval, even if the event state remains active.

If Cleared events occur while the daemon manager is down, the event continues to remain active in the user interface. There is no indication after the daemon manager restarts that any events were missed. Poll-based events get generated if the issue continues to exist, whereas Trap- based events cannot be processed even if the issue persists.

Diagnostic Tests—Testing restarts approximately 30 minutes after an Operations Manager restart.

Performance Data Collection—The network topology builder (also known as the SIRServer process) may take approximately 15 minutes to restart (delay may vary based on the size of network) before performance polling can restart (if it was enabled before the restart).

Multiple End-Customer Authorization/Authentication

If you selected the multiple end-user deployment during installation, you can set up your users to have access to specific customer groups. For more details, see Configuring Users (ACS and Local RBAC).