Frequently Asked Questions for Cisco Unified Service Monitor 2.0
Frequently Asked Questions for Cisco Unified Service Monitor 2.0
Downloads: This chapterpdf (PDF - 192.0KB) | Feedback

Cisco Unified Service Monitor 2.0 FAQ and Troubleshooting Scenarios

Table Of Contents

Cisco Unified Service Monitor 2.0 FAQ and Troubleshooting Scenarios

Frequently Asked Questions

General

Upgrade and License

Configuration

General Questions

Sensor Management

CallManager Credentials

Monitored Phones

Thresholds

Reports

Diagnostic Reports—Sensors

Diagnostic Reports—CVTQ

General

Most Impacted Report

Troubleshooting Scenarios


Cisco Unified Service Monitor 2.0 FAQ and Troubleshooting Scenarios



Note For additional information that applies exclusively to Service Monitor 2.0.1, see Frequently Asked Questions for Cisco Unified Service Monitor 2.0.1.


This document includes the following:

Frequently Asked Questions

Troubleshooting Scenarios

Frequently Asked Questions

General

Upgrade and License

Configuration

CallManager Credentials

Monitored Phones

Thresholds

Reports

General

What ports does Service Monitor use?

On Service Monitor server:

22—SSH (TCP)

25—SMTP(TCP)

5666—SyslogPort (UDP)

2000—SkinnyPort (TCP)

On Unified Communications Manager 3.3 and 4.x publisher:

1433—SQL Server(TCP)

Can the Service Monitor server be deployed in a Service Provider type of environment?

The Service Monitor server assumes that the following are unique:

IP addresses of devices and Unified Communications Managers (in Credential Management)

Cluster IDs (in Credential Management)

Upgrade and License

How do I upgrade from Service Monitor 1.0 to Service Monitor 2.0?

Uninstall Service Monitor 1.0 before installing Service Monitor 2.0. (Direct upgrade from 1.0 to 2.0 is not recommended.)

How do I upgrade from Service Monitor 1.1 to Service Monitor 2.0?

For complete instructions, see Quick Start Guide for Cisco Unified Service Monitor 2.0.

When I upgrade, will my sensor-related data be preserved?

Sensor configuration data is removed from the database.

Sensor call metrics archive files, if call metrics archiving was enabled, remain on the disk in the existing folder. However, after upgrade:

To continue generating call metrics archive files, enable call metrics archiving again.

To find newly generated call metrics archive files, look in NMSROOT/DataDir.


Note NMSROOT is the directory where Service Monitor is installed; its default location is C:\Program Files\CSCOpx.



Note Also, after upgrade, logging levels are reset to default.


What can I expect if I reinstall Service Monitor 2.0?

The database, sensor configuration files, and—if archiving is enabled—call metrics archive files are preserved. However, when reinstalling Service Monitor on a system with a large database, the backup operation can go on indefinitely. To work around this problem, skip the database backup during reinstallation (see step 2 in the following procedure). To also save the existing database, perform all of these steps:

1. Save the existing database to a temporary location outside of NMSROOT before reinstalling Service Monitor:

a. Stop the daemon manager using the following command:

net stop crmdmgtd

b. Change the qovr database password to something that you will remember. In this example, the new password is admin:

NMSROOT\C\bin\perl  dbpasswd.pl dsn=qovr npwd=admin

c. From NMSROOT\databases\qovr, copy these files—qovr.db and qovrx.log—to a location outside of NMSROOT.

2. Skip database backup while reinstalling Service Monitor:

a. From the command line, change directory to the drive with the product CD.

b. Issue this command:

Setup.exe nobackup 

To complete the reinstallation, follow the instructions online or consult Quick Start Guide for Cisco Unified Service Monitor.

3. After completing the reinstallation and rebooting your system, replace the newly created database with the database that you saved:

a. Stop the daemon manager using the following command:

net stop crmdmgtd

b. Set the password on the newly created database to match the password that you set on the database that you saved:

NMSROOT\C\bin\perl  dbpasswd.pl dsn=qovr npwd=admin

c. Copy the database files—qovr.db and qovrx.log—from the location outside of NMSROOT (see step 1.c.) to NMSROOT\databases\qovr.

d. Restart the daemon manager using the following command:

net start crmdmgtd

Configuration

General Questions

Sensor Management

General Questions

I know that Cisco Unified CallManagers must be configured correctly before Service Monitor can communicate with them, but Cisco Unified CallManager documentation is so extensive. How can I find out quickly what I need to do?

For brief, thorough instructions, see Cisco Unified CallManager Configuration in User Guide for Cisco Unified Service Monitor.

Is the Internet Explorer 7.0 browser supported?

Internet Explorer 6.0 is recommended. You can use Internet Explorer 7.0 to interact with Service Monitor when it is installed without Operations Manager (which supports Internet Explorer 6.0 only).

Can I install Service Monitor on a system with two network interface cards (NICs)?

Dual homing—using 2 NICs with 2 different IP addresses—is not supported on Service Monitor. Using 2 NICs with a single IP address (a fail-over configuration, in case one of the NIC cards fails) is supported.

Sensor Management

How do I register my new Cisco 1040 Sensors with Service Monitor?

See Managing Sensors in User Guide for Cisco Unified Service Monitor.

I deleted a sensor from Service Monitor. Will it automatically register to Service Monitor again?

No. Service Monitor does not allow this. To add this sensor to Service Monitor again, select Configuration > Sensors > Add.

Is it OK to use the Service Monitor system as a TFTP server for sensors?

Yes. Check Windows Services to confirm that the Common Services TFTP service (CWCS tftp service) is enabled (as it is by default).

I have a TFTP server but it does not have write access enabled. What should I do?

1. Add the TFTP server to Service Monitor and create a default sensor configuration file:

Configuration > Sensor > TFTP Servers

Configuration > Sensor > Setup—Enter the image filename and primary Service Monitor.

2. Copy these files from NMSROOT\CSCOpx\ImageDir to the TFTP root on the TFTP server:

QOVDefault.cnf—Default configuration file

SvcMonAA2_34.img—Sensor image file

Sensors register with Service Monitor using the default configuration file; Service Monitor then creates a MAC-specific configuration file (MACAddress.cnf) for the sensor also in NMSROOT\CSCOpx\ImageDir.

3. Copy the MAC-specific configuration files from NMSROOT\CSCOpx\ImageDir to the TFTP root on the TFTP server

I get traps from Service Monitor every minute for the same endpoint for sensor-reported MOS violations. It's too much. What should I do?

Increase the number of minutes during which Service Monitor does not send traps for an endpoint. Select Configuration > Sensors > Setup and increase the number of minutes in the Send traps every xx minutes field.

CallManager Credentials

What is `push' versus `pull' mechanism?

Push—Cisco Unified CallManagers 5.x sends (pushes) data to Service Monitor. (Before this can happen, Service Monitor must be configured as a billing server. For more information, see Cisco Unified CallManager Configuration section of User Guide for Cisco Unified Service Monitor.)

Pull—Service Monitor periodically connects to Cisco Unified CallManagers 3.x and 4.x to obtain (pull) Call Data Records (CDRs) and Call Management Records (CMRs).

What are CDR credentials?

Credentials to the SQL server database, a repository of CDRs and CMRs on Cisco Unified CallManager 3.x and 4.x. Minimum required privilege: administrative privileges.

What are Device DB credentials?

Credentials to the Cisco Unified CallManager 3.x device database, a repository with information that is not available from the CDR database. Minimum required privilege: administrative privileges.

What are HTTP/S credentials?

These credentials provide access for:

Cisco Unified CallManager 4.x—To information that is not available from the CDR database.

Cisco Unified CallManager 5.x—To data that Service Monitor can use to find the IP address of the node with the CDR repository.

This credential is the same as the one you use to connect to Cisco Unified CallManager Administration using the browser. Minimum required privilege: Read-only access.

Service Monitor lost contact with Unified Communications Manager 5.x (or later). After re-establishing the connection, the Last Contact Status continues to display Discarding Data. What is going on and how can I see current data in CVTQ reports?

Unified Communications Manager 5.x and later resends backlogged data to application billing servers after reconnecting to them. Service Monitor must process this data and discard old data. Depending on the size of the backlog, the processing can take days. To prevent this processing from occurring, from Unified Communications Manager do the following:

1. Remove the Service Monitor application billing server; (doing so removes the associated list of backlogged files). (Instructions are provided in Quick Start Guide for Cisco Unified Service Monitor 2.0.1.)

2. Restart the CDR Repository Manager service.

3. Add Service Monitor to Unified Communications Manager as an application billing server. (For more information, see User Guide for Cisco Unified Service Monitor 2.0.)

4. Restart the CDR Repository Manager service.

What does CDRM mean in the CDR/CDRM column title?

CDRM is a Cisco Unified CallManager 5.x database. For Cisco Unified CallManager 5.x, the entry in this column indicates whether Service Monitor successfully obtained the IP address, cluster name, and version from the CDRM database.

What is the most important credential for a Cisco Unified CallManager?

While all credentials are needed for Service Monitor to work completely, if the first credential that Service Monitor uses fails, it has the greatest impact.

Cisco Unified CallManager Version
First Credential that Service Monitor Uses
If this credential fails...

3.x

Device DB

Service Monitor does not try to connect to the CDR database

4.x

HTTPS credential

Service Monitor does not try to connect to the CDR database

5.x

HTTPS credential

Service Monitor ignores the pushed data from this Cisco Unified CallManager


Why is the SFTP credential configured on a page (Other Settings) other than CallManager Credentials?

The SFTP credential is for the SFTP server that is hosted on the Service Monitor system. In the communication between Service Monitor and Cisco Unified CallManager 5.x, the latter is an SFTP client. The same credential needs to be configured in both:

Service Monitor—On the Other Settings page.

Cisco Unified CallManager 5.x—For Service Monitor as an applications billing server. For more information, see Cisco Unified CallManager Configuration in User Guide for Cisco Unified Service Monitor.

so that Service Monitor permits Cisco Unified CallManager to push the data.

Service Monitor uses only this single SFTP credential to verify incoming SFTP connections from any Cisco Unified CallManager 5.x system.

What happens if two Cisco Unified CallManagers have the same cluster ID?

Service Monitor behaves unpredictably; avoid problems by ensuring that cluster IDs are unique. To change a cluster ID:

1. From Cisco Unified CallManager Administration:

a. Select System > Enterprise Parameters. The Enterprise Parameters Configuration page appears.

b. Change the cluster ID (to a name that doesn't include a space).

c. Click Update.

2. Repeat this step for each Cisco Unified CallManager:

a. From Cisco Unified CallManager Serviceability select Tools > Control Center - Feature Services.

b. Select the Cisco Unified CallManager server.

c. Click the Restart button.

Monitored Phones

When I total the Known Phone Count for all sensors and Cisco Unified CallManagers, the sum does not always equal the "Total known phone count". Why is this so?

A Cisco Unified CallManager and a sensor might report on the same set of phones.

What is the purpose of suspending a cluster or sensor?

To refresh the total known phone count, removing phones that are no longer active because:

A cluster was set up for a pilot that has concluded—Suspending the cluster reduces the total known phone count, so that phones from another cluster can be monitored.

Phones were replaced—If the license limit has been reached, suspending and then resuming monitoring of the Cisco Unified CallManager to which the phone was registered allows new (replacement) phones to be accepted.

Sensors were relocated to a different switch or geographical location— If the license limit has been reached, suspending and then resuming monitoring of the sensor allows new phones seen by that sensor to be monitored by Service Monitor.

Does suspending a cluster or sensor wipe out report data for the corresponding cluster or sensor?

No. Report-related data is retained until daily purging removes it after 30 days.

Thresholds

Why is threshold configuration not on the Configuration tab?

To draw your attention immediately to the ability to:

Configure a MOS threshold value for each supported codec (globally).

Selectively override global thresholds by creating sensor threshold groups and Cisco Voice Transmission Quality (CVTQ) threshold groups.

Will the system generate traps for bad calls right out of the box without worrying me to create groups?

Yes. Service Monitor generates traps for MOS scores that fall below preset global thresholds that are reasonable industry default values. (Of course, you must configure recipients for the traps).

What are some important reasons for creating groups?

To suppress unnecessary traps from a "known problem" area of the network.

To set different thresholds for the same codec. Executive staff phones could be put in a group with higher than usual threshold values.

To assign different thresholds to lines that span different geographical areas. A G729 call between San Jose and New York could have higher threshold than a G729 call between San Jose and Bangalore.

Reports

Diagnostic Reports—Sensors

Diagnostic Reports—CVTQ

General

Most Impacted Report

Diagnostic Reports—Sensors

I just finished installing Service Monitor. I made a call that my sensor should see and I hung up. Why don't I see any data in the Cisco 1040 Sensor Report?

A call must last more than 20 seconds for a sensor to report it.

OK, I made a call that lasted three minutes. Why is there still no data?

It takes 10 minutes before data is available to sensor reports.


Note This is also true for CVTQ reports.


I made a call from a phone for the first time after Service Monitor was installed. I already added credentials to Service Monitor for the corresponding Cisco Unified CallManager. Why is the Directory Number field still empty in many of the report rows?

Directory Number is available only after a call completes. The corresponding Call Detail Record (CDR) is not available while a call is in progress.

I see the Unavailable as the Device Type in some rows. Why?

Could be due to one of the following:

Corresponding Cisco Unified CallManager not added to CallManager Credentials.

The endpoint was a non-MGCP gateway (on an off-net call).

Directory Number is available only after a call completes. Since this was the first call seen by Service Monitor, the corresponding Call Detail Record (CDR) was not available while the call was in progress.

Diagnostic Reports—CVTQ

I see Unavailable as the MOS value in some rows. Why?

One of the following:

Call duration was less than 20 seconds (short call).

Endpoint did not report MOS.

Cisco Unified CallManager version was earlier than 4.2.

I see Not Available or N/A for Severely Concealed Seconds, Concealment Ratio, or Concealment Seconds. Why?

This would happen for pre-4.2 Cisco Unified CallManagers or non-MGCP gateways.

I deleted a Cisco Unified CallManager from Service Monitor. Why can I still select it from the Cluster ID(s) filter?

So that you can still filter reports using that cluster. Data from a deleted cluster remains in the database until it is removed after the data is older than 30 days.

I made a call that lasted three minutes and then ran a CVTQ report. Why is there no data?

It takes 10 minutes before data is available to CVTQ reports.

General

Sensor Reports label endpoints as Listener and Speaker while the CVTQ Reports label them as Caller and Called. Why the discrepancy?

Sensors listen to RTP streams and do not process signaling traffic; therefore, sensors cannot distinguish the caller from the called party. When packets stream into a switch, the far end is the speaker and the near end is the listener and vice-versa. Cisco Unified CallManager is a call agent and recognizes Caller and Called endpoints.

Most Impacted Report

Why is there no Most Impacted Report?

On the first day of installation, since the information for the report is generated at 1AM the next day, there is no Most Impacted Report.

Most Impacted Reports are based on bad calls; if all calls are good, there is no report.

Can I run the Most Impacted Report automatically?

You can configure Service Monitor to automatically generate the report, save it to a specific location, and send it to one or more email addresses from Configuration > Export Settings.

Troubleshooting Scenarios

Sensor state remains `Waiting...'.

1. Verify that the sensor is registered to the correct Service Monitor server:

If you know the IP address of the sensor, type http://IP. The web interface on the sensor opens and shows the TFTP server name and the Service Monitor server name.

If you do not know the IP address of the sensor, go to the TFTP server and look at the MAC-specific cnf file for the sensor.

2. Perform the following procedure if the sensor is:

Registered to the correct Service Monitor server—To ensure that an old cnf file is not loaded on the sensor.

Not registered to the correct Service Monitor server—To ensure that the current cnf file exists on the Service Monitor server and the TFTP servers, and is loaded on the sensor.

a. From the TFTP server, delete the MAC-specific (QOVMACAddress.cnf) cnf file and the default cnf file, QOVDefault.cnf.

b. Generate and copy the default cnf file over from the current Service Monitor server to the TFTP servers as explained in the FAQ I have a TFTP server but it does not have write access enabled. What should I do?

c. Power cycle the sensor physically.

3. As a last resort, reset the switch.

To verify that Service Monitor is receiving sensor data, look at the  NMSROOT\log\syslog.log file.

I added a credential for a particular Cisco Unified CallManager and the Latest Contact Status is now Failure. I know the credentials are good and there are no network issues.

This can happen when the IP address is not resolvable to the DNS hostname. Service Monitor server needs the hostname to get the version number. Try editing the credentials and filling in the Host Name field.

I entered all CallManager Credentials and the Last Contact Status is Success. I know that calls are happening. Why don't I see CVTQ report data yet?

Wait for 10 minutes after the first call.

Verify that CDR is enabled in Cisco Unified CallManager. For Cisco Unified CallManager Configuration tasks that you must perform so that Service Monitor can obtain call data, see User Guide for Cisco Unified Service Monitor.

Cisco Unified CallManager 5.x is pushing data but, for the last few days, there is no report data.

On the CallManager Credentials page, click Success in the CDR/CDRM column. If the last contact time is two or more days old, Cisco Unified CallManager has stopped contacting Service Monitor. Confirm that Cisco Unified CallManager 5.x is still configured as required for Service Monitor. See Cisco Unified CallManager Configuration in User Guide for Cisco Unified Service Monitor.

Look for recent files in the SFTP root: NMSROOT\cscopx\qovr\preserve. If calls are occurring, but there are no files here, then Cisco Unified CallManager 5.x is not pushing data.

The global threshold for the G711codec is 4.4. I have two CVTQ groups, one of which overrides the G711 threshold, lowering it to 4. I don't see traps from Cisco Unified CallManager phones that I know are generating a MOS value of 3.8.

Check whether the other CVTQ group:

Overrides the G711 threshold, setting it to a value lower than 4

Has a higher priority (therefore taking precedence)

Ideally, you should not configure two groups to override the threshold for the same codec without ensuring that the same endpoints do not exist in both groups.

Cannot generate Most Impacted Report.

The process that prepares the most impacted endpoints data is still running. The process starts at 1AM and can take many hours on a system that is under a heavy load.