Table Of Contents
Troubleshooting QPM
Obtaining System Status Information for Troubleshooting
Obtaining Additional Debug Information for Cisco Technical Support
Problems Starting QoS Policy Manager
Troubleshooting Problems Starting Common Services
Troubleshooting Problems Starting QPM
Troubleshooting User Interface Problems
Troubleshooting Policy Configuration Problems
Troubleshooting Device Management Problems
Troubleshooting Deployment Problems
Troubleshooting QoS Analysis Problems
Monitoring Error Messages
Troubleshooting Display Problems
Troubleshooting Threshold Analysis Problems
Troubleshooting the IP Telephony Network
Troubleshooting Database Backup Problems
Troubleshooting QPM
The following topics can help you troubleshoot problems you might encounter when using QPM:
•
Obtaining System Status Information for Troubleshooting
•Obtaining Additional Debug Information for Cisco Technical Support
•Problems Starting QoS Policy Manager
•Troubleshooting User Interface Problems
•Troubleshooting Policy Configuration Problems
•Troubleshooting Device Management Problems
•Troubleshooting Deployment Problems
•Troubleshooting QoS Analysis Problems
•Troubleshooting the IP Telephony Network
•Troubleshooting Database Backup Problems
Obtaining System Status Information for Troubleshooting
If unusual exceptions occur or error windows are displayed while running QPM, you can obtain system status information by running the pdshow command on the QPM server. This tool provides the status of the QPM or EMS process.
You can run the pdshow command only from the QPM server.
In general, if you come across troubleshooting problems that do not have an obvious solution, you should try logging out of QPM and CiscoWorks, and restarting the QPM server. If the problem persists, run the pdshow command on the QPM server, and consult your system administrator.
If you want to send the diagnostics results to a TAC representative, you can run the MDCSupport.exe (for Windows) or ./mdcsupport (for Solaris) command-line utility, which collects configuration and system information in a zip file (for Windows) or a tar.Z file (for Solaris), called MDCSupportInformation. This zip (or tar.Z) file includes any problems that occurred during the installation or the running of QPM. You can send this file to the Cisco Technical Assistance Center (TAC) support staff to assist in diagnosing the problems.
To obtain system status information for QPM installed on Windows machine:
Step 1 At the command line, enter MDCSupport.exe and press Enter.
A zip file named MDCSupportInformation.zip is created in installation-directory\CSCOpx\MDC\etc, where installation-directory is the directory in which you installed the program, typically C:\Program Files.
a. Email this file to the TAC representative.
To obtain system status information for QPM installed on Solaris machine:
Step 1 At the command line, enter ./mdcsupport and press Enter.
A tar.Z file named MDCSupportInformation.tar.Z is created in installation-directory/CSCOpx/MDC/etc, where installation-directory is the directory in which you installed the program.
b. Email this file to the TAC representative.
Related Topics
•Obtaining Additional Debug Information for Cisco Technical Support
Obtaining Additional Debug Information for Cisco Technical Support
If Cisco Technical Support requests that you gather additional debug information in the trace files, you can set the QPM trace logging mode to collect the information. Because collecting debug information will reduce the performance of your server, and the collected data can only be interpreted by Cisco, do not collect debug information unless requested. After you have collected the information, reset the logging mode to only collect informational messages.
To do this:
Step 1 Go to the QPM-install-directory\CSCOpx\MDC\qpm\bin directory (where QPM-install-directory is the directory in which you installed QPM), enter this command to begin collecting debug information:
setqpmloggermode -debug
Wait for five minutes before proceeding to the next step. This is to allow time for the system to prepare for collecting debug messages.
Step 2 Repeat the activities you were doing in QPM that led to the problems you encountered.
Step 3 When sufficient debug information has been collected under CSCOpx\MDC\log\, compress the log folder (to .zip or .tar), and email it to your Cisco Technical Support representative.
Step 4 Enter the following command to reset the logging mode so that only informational messages are collected (the default behavior):
setqpmloggermode -info
Related Topics
•Obtaining System Status Information for Troubleshooting
Problems Starting QoS Policy Manager
The following topics describe causes and solutions for problems you might encounter when trying to start QoS Policy Manager:
•Troubleshooting Problems Starting Common Services
•Troubleshooting Problems Starting QPM
Troubleshooting Problems Starting Common Services
Common Services might not start for any of the following reasons:
•Port Conflict
Port Conflict
Problem You cannot start Common Services because port 1741, which is used by Common Services, is in use by another application.
Solution Try the following:
•Restart the QPM server.
•To run CiscoWorks, enter http://QPMinstall:1741/login.html, where QPMinstall is the name or IP address of the QPM server.
If ports are still in use, open the JbossStdout.log file and look for the error "java.rmi.server.ExportException:Port already in use:port-number".
Check whether the listed port is in use by another application. If so, stop the other application or change the port it is using. See the Installation Guides for QoS Policy Manager 4.0 on Solaris and Windows for details.
Troubleshooting Problems Starting QPM
QPM might not start for any of the following reasons:
•QPM Server Does Not Meet System Requirements
•Changed Database Password
•Unknown Cause
QPM Server Does Not Meet System Requirements
Problem QPM startup and performance might be slow, or QPM might not work at all.
Solution Install QPM on a server that meets system requirements.
Changed Database Password
Problem If you changed the QPM database password, and then try to start QPM without restarting the QPM server or Daemon Manager, the connection to the database is lost.
Solution . Please restart the QPM server if you change the QPM database password (refer to correct daemon processes for solaris and windows). The connection to the database would be lost if QPM UI is started without restarting QPM server daemon processes
Unknown Cause
Problem QPM does not start due to an unknown cause.
Solution Restart the QPM server.
Troubleshooting User Interface Problems
These topics describe causes and solutions for your user interface problems:
•Many buttons in the user interface are grayed out
•Options for QoS features do not appear in the user interface
Many buttons in the user interface are grayed out
Problem You might not have the correct user permissions to perform the tasks associated with the grayed out buttons.
Solution Verify your user permissions in the CiscoWorks desktop (Server > Security), or in ACS (depending on the method you are using for user authentication). For more information about user permissions, and working with ACS user permissions, see the Installation Guide for QoS Policy Manager.
Troubleshooting Policy Configuration Problems
These topics describe causes and solutions for your policy configuration problems:
•Options for QoS features do not appear in the user interface
•You remove a network element from a policy, but the traffic rules are not removed from the network element
Options for QoS features do not appear in the user interface
Problem You cannot see options for QoS features that are not valid for the defined device constraints.
Solution When you define policies, properties, and traffic rules, QPM presents you with only those QoS properties and traffic rule options that are valid for the defined device constraints. Verify that you have chosen the correct network element and defined the device constraints correctly.
You remove a network element from a policy, but the traffic rules are not removed from the network element
Problem You remove a network element from a policy, then redeploy the policy. However, the policy's traffic rules are not removed from the deleted network element.
Solution QPM does not remove QoS configurations from network elements when the network element is removed from a policy.
If you want to remove the QoS configuration on a network element, you must create a policy that does not have any QoS configuration defined (an "empty" policy), assign the network element to the empty policy, and deploy the empty policy.
Troubleshooting Device Management Problems
The following sections help you troubleshoot problems with QPM device management:
•QPM cannot log into a device
•A device is not added to the expected device group when imported into QPM
•A device has a status that indicates an error
•QPM does not detect the correct card type
QPM cannot log into a device
Problem QPM can connect to a device, but cannot log into it for any of the following reasons:
•The device access parameters in the QPM inventory do not match those configured on the device.
•The standard device prompts have been customized.
Solution Verify that the device access parameters in the QPM inventory match those configured on the device. If the device access parameters are correct but QPM still cannot log into the device, enable the blind login option.
This causes QPM to send login information to the device (including access parameters) without waiting for or evaluating return prompts from the device.
For instructions for enabling blind login, see Viewing and Editing Device Properties, page 4-8. You can also configure blind login as the default for all devices in a device group; see Editing Device Group Properties, page 4-22.
Determine whether the device prompts have been customized using the prompt (Cisco IOS software) or set prompt (Catalyst OS) commands.
•Cisco IOS software devices—These are the standard prompts for Cisco IOS software devices:
•Catalyst OS devices—These are the standard prompts for Catalyst OS devices:
For example, if the prompt was changed to "my_prompt" using the CLI command set prompt, the following prompts will appear when you log into the device:
If the device prompts have been customized, you must configure QPM to recognize the customized device prompts, and enable blind login for the device.
Use a text editor such as WordPad or Notepad to add command lines to the qpm.cfg file in the mdc\shared\config folder in the Common Services installation folder on the QPM server. Enter this line for each device whose prompt is customized:
devicename.login_prompt=custom_prompt
where devicename is the IP address or host name of the device, and custom_prompt is the customized prompt. For example, if the customized prompt for device 10.10.2.4 is "my_prompt," enter this line in qpm.cfg:
10.10.2.4.login_prompt=my_prompt
•If all devices have the same prompt, you can use an asterisk (*) instead of a specific device name, to denote all devices.
•You can use any characters for the prompt, but it cannot end in $, ^, or \.
After you update qpm.cfg, you must restart the QPM server before the changes take effect.
A device is not added to the expected device group when imported into QPM
Problem The device might be defined in ACS as an AAA server and an AAA client, which is supported in ACS but not in QPM. In this case, the device is added to only the QPM AAA client device group in QPM.
Solution Remove the device from the ACS AAA server device group.
A device has a status that indicates an error
The device statuses described in Table 14-1 indicate that the device is in an error state. You cannot deploy to devices with these statuses.
Table 14-1 Device Status Errors
Device Status
|
Description
|
Explanation
|
Unreachable
|
The QPM server cannot establish basic network connectivity to the device.
|
Establish basic network connectivity to the device.
|
SNMP Error
|
The device has an SNMP error that is preventing QPM from gathering the data it needs to work with the device.
|
These are the common causes:
•The device public community string entered in QPM is incorrect. Correct the community string in QPM.
•QPM can't read all of the necessary SNMP information from the device, possibly because there are corrupted or missing MIBs.
•The device does not have a functioning SNMP engine.
•The SNMP request timed out, typically because the device or network was too congested to respond before the timeout limit. The possible resolutions are to retry the SNMP connection, or increase the SNMP timeout value.
|
Telnet Error
|
QPM cannot connect to the device using Telnet.
|
These are the common causes:
•The device Telnet password entered in QPM is incorrect. Correct the Telnet password in QPM.
•SSH is enabled but SSH login failed because SSH is not configured correctly on the device. Fix the SSH configuration on the device.
•The login to the device failed.
•There is no Telnet connection to the device.
|
QPM does not detect the correct card type
Problem In rare cases, QPM does not recognize the type of card on which an interface resides. Because the card type influences what types of QoS can be configured on an interface, an incorrect card type can prevent you from deploying the desired QoS configuration to the interface.
Solution If you cannot get QPM to correctly recognize the card type for an interface, update the qpm.local.cfg file on the QPM server with the following line, then restart all QPM services:
This line will turn the Card Type display field on the Interface Properties page into a list box (see Device Summary Page, page A-2). You can then select the correct card type for the interface. Make sure you do not select an incorrect card type, or QPM will probably generate errors if you try to deploy policies to the interface.
QPM License Device Limit exceeded
Problem If you try to add more devices to QPM, an error message appears stating that the device limit has exceeded.
Solution Check whether the number of devices in the QPM inventory exceeds the limit specified by the license(s) you obtained for QPM. Go to Administration > License page, and see the device limit for the license(s) you obtained for QPM.
If you find that the device limit is not exceeded even by adding the new devices, restart the CiscoWorks Deamon and try adding the new devices again.
Troubleshooting Deployment Problems
Policies can only be deployed to devices if QPM can correctly contact and connect to the device. QPM can usually provide a specific error message that clearly indicates the problem. However, sometimes providing a clear error message is not possible.
If QPM cannot configure a device, and the error is not clear in the device log for the device, this might be due to any of the following reasons:
•Incorrect software version or device type
•Deployment fails because QPM could not connect to a device
•Configuration messages from the device indicate that distributed Cisco Express Forwarding (dCEF) is not configured on VIP cards
•Configuration messages from the device indicate that Cisco Express Forwarding (CEF) is not configured on the device
•Deployment fails on virtual interface because "CB QoS not supported on device" when the device supports Class Based QoS
•Queuing policies that were defined for ATM PVC interfaces in QPM are not deployed or monitored
Incorrect software version or device type
Problem QPM does not support an imported device's Cisco IOS version. The device is assigned the status "Unsupported", and no mapped OS version is assigned to it. You cannot perform any tasks on a device that has been assigned this status.
Solution If the device model is supported by QPM but the Cisco IOS version is not, you can upgrade the device to a supported Cisco IOS version, and then rediscover the device to make it available in QPM. Click Rediscover in the Device Table to have QPM query the device for the correct information.
Alternatively, if the Cisco IOS version is not supported, but you know that the IOS version's QoS features are the same as in a supported version, you can use the following workaround:
Step 1 After you have added the device, in the Device Properties page, change the Mapped OS version to the supported OS version, and save the change.
Step 2 Rediscover the device.
The device status changes to OK.
Deployment fails because QPM could not connect to a device
There are several possible explanations for this problem:
•Problem—Unable to log into the device due to an incorrect access passwords.
Solution—Check in the Device Properties page that the correct Telnet, TACACS, and Enable passwords are defined. QPM does not display the passwords (to maintain security), so carefully retype the passwords.
•Problem—There is no connectivity between QPM and the device—the device status is "Unreachable."
Solution—Check the device to ensure that it is powered on and that it is connected to the network. Log into the server and telnet to the device to see if you can connect to it (from the Device Properties page).
•Problem—There might be a problem with the login prompts returned by the device.
Solution—Enable the Blind Login check box in the Access Parameters area of the Device Properties page. This feature lets you bypass the login prompts (such as, user name and password) that wait for a response when the device returns a string. Then try to log in again.
In the system configuration file of the QPM installation directory (CSCOpx\MDC\share\config\qpm.cfg), you can configure blind login for all devices, by setting devcomm.blind_login=on.
To use blind login for a specific device, set hostname.blind_login=On,where hostname is the IP address or host name of the device. This will override the global blind login setting. If required, you can also increase the login timeout delay parameter for the devices (devcomm/hostname.blind_login_timeout).
Configuration messages from the device indicate that distributed Cisco Express Forwarding (dCEF) is not configured on VIP cards
Problem Some types of QoS configurations require that dCEF is configured on VIP cards and QPM cannot detect this.
Solution Before distributing policies to VIP interfaces, configure dCEF on the device's VIP card interfaces through the device's commands.
Configuration messages from the device indicate that Cisco Express Forwarding (CEF) is not configured on the device
Problem Some QoS features, such as DWFQ and NBAR, require CEF to be configured on the devices (not on the VIP cards) and QPM cannot detect this.
Solution Before distributing policies to devices, configure CEF on the device through the device's commands.
Deployment fails on virtual interface because "CB QoS not supported on device" when the device supports Class Based QoS
Problem Deployment of policies to a virtual interface (such as subinterfaces or tunnel interfaces) fails with the indication that Class Based QoS is not supported on the device, whereas you know that this specific device does support this type of QoS.
Solution In general, on virtual interfaces, if you want to configure class based queuing, you must configure modular shaping. If you have not configured modular shaping with class based queuing on a virtual interface, deployment might fail with the above message. Check that you have configured the virtual interface correctly.
Queuing policies that were defined for ATM PVC interfaces in QPM are not deployed or monitored
Problem Queuing policies are defined for ATM PVC interfaces in QPM, but cannot be seen on the "Show run", and cannot be monitored. The queuing policy has not been deployed to the ATM PVC, and hence cannot be monitored.
With the newer IOS and port-adapters, the service-policy command can only be deployed to the PVC if the vbr-nrt command is configured on the PVC. "vbr-nrt" is an ATM hardware command, and is used for configuring QoS shaping. QPM does not automatically configure this command, and no error is displayed on deployment.
Solution Configure the vbr-nrt command manually on the ATM PVC before configuring QoS through QPM.
Related Topics
•Viewing and Editing Device Properties, page 4-8
•Connecting to a Device Using Telnet, page 4-10
•Rediscovering Device Information, page 4-11
•Device Summary Page, page A-2
Troubleshooting QoS Analysis Problems
The following sections help you troubleshoot problems with QoS analysis:
•Monitoring Error Messages
•Troubleshooting Display Problems
•Troubleshooting Threshold Analysis Problems
•Queuing policies that were defined for ATM PVC interfaces in QPM are not deployed or monitored
Monitoring Error Messages
The following sections describe monitoring error messages and their fixes or workarounds:
•Monitoring system error
•Collection service error
•Cannot run task
•The task does not contain a device from the current device group
Error Message Monitoring system error
Explanation This error message indicates that an unspecified error occurred when attempting to run
a report.
Recommended Action Restarting the QPM server might resolve the problem.
Error Message Collection service error
Explanation This error message indicates that there was a collection service error when trying to run
a real-time report or complete the definition of a historical analysis task. The error message contains
additional explanation of the error. Each variation of the error is described in Table 14-2.
Table 14-2 Collection Service Error Troubleshooting
Error Variation
|
Description
|
Fix or Workaround
|
Connection to collector refused
|
The QPM collector service is not working properly.
|
Restarting the QPM Collector service might resolve the problem.
|
Failed to load task to the collector
|
The QPM collector service is not working properly.
|
Restarting the QPM Collector service might resolve the problem.
|
Failed to get settings from the collector
|
The QPM collector service is not working properly.
|
Restarting the QPM Collector service might resolve the problem.
|
Failed to get data from the collector
|
The QPM collector service is not working properly.
|
Restarting the QPM Collector service might resolve the problem.
|
SNMP request timeout
|
SNMP requests sent to the device timed out.
|
Try the following fixes in this order:
1. Verify basic device connectivity using ping or Telnet.
2. Verify that the device access parameters stored in QPM inventory agree with those configured on the device.
3. Check device CPU load. If it's abnormally high, SNMP requests might not get processed. Lower the CPU load to restore monitoring.
|
The device: IP address is not configured with the policy: Policy on interface with MIB index y
|
The device does not contain the policy or MIB index that QPM needs to monitor a policy.
This happens when the device is changed in certain ways after the monitoring task was created.
|
These are possible causes of this error. To resolve the error, fix the applicable problem, then either rerun the real-time analysis report, or redefine the historical analysis task.
•The interface is shut down. Enable the interface.
•There was an undetected deployment error. Redeploying the policies to the device might resolve the problem.
•You deployed policies to a file rather than to the network.
QPM cannot detect that policies are deployed to a file, so it updates monitoring tasks that are affected by a policy deployment. This occurs even if the changes were not deployed to the actual device. There is no workaround.
•You changed the device hardware configuration or created subinterfaces on the device, but did not rediscover the device. Rediscover the device.
•You selected a CAR policy with the Mark and Transmit option configured. QPM cannot monitor this QoS configuration.
Remove the CAR policy with the Mark and Transmit option from the monitoring task definition.
|
Error Message Cannot run task
Explanation The device is not responding because the QPM SNMP timeout was changed to larger
than two minutes. It is recommended that you use the default QPM SNMP timeout value.
Recommended Action Try the following fixes in this order:
a. Verify basic device connectivity using ping or Telnet.
b. Verify that the device access parameters stored in QPM inventory agree with those configured on the device.
c. Check device CPU load. If it's abnormally high, SNMP requests might not get processed. Lower the CPU load to restore monitoring.
Error Message The task does not contain a device from the current device group
Explanation The analysis report cannot run because none of the devices that it is assigned to monitor
are still in the current device group. The likely cause is that the devices were removed from the
current device group. This error will also occur if you move a device that is being monitored from
the Default device group to another device group.
If any of the devices assigned to the monitoring task are still in the current device group, you can run the report, which will contain data only for the devices that are still in the current device group.
Recommended Action To fix this, add at least one of the devices that are assigned to the monitoring
task back into the current device group.
Troubleshooting Display Problems
The following sections describe display problems and their fixes or workarounds:
•Graphs Are Difficult to Analyze
•Graphs Appear in Analysis Report, but They Are Empty
•Graphs Do Not Appear in Analysis Reports
•Subinterface Graphs Display Incorrect Bandwidth Percentages
Graphs Are Difficult to Analyze
Problem You are not able to infer any data from the graphs because they are difficult to analyze. The color display is not proper.
Solution Make sure you set the color setting of the desktop to High Color (16 Bit). You can set the color depth under Display Properties > Settings on your desktop.
Graphs Appear in Analysis Report, but They Are Empty
Problem You can view an historical analysis report, but the graphs do not show any information.
Solution You will not see data on the historical graphs immediately after the task starts. Depending on when you start the task, the length of the polling interval, and how many other tasks are being run concurrently, it can take several hours to see graphed data. This is because of how QPM collects the data and writes it to the QPM database.
To see any data in the graphs, your task must include at least three polling periods. For example, if you use a polling period of 30 minutes, and run the task for only one hour, you will not see any graphed data for the task.
Even if you define a task whose duration is three times the polling interval, QPM might not have collected data three times during the task. Ensure that you create analysis tasks that will collect data a sufficient number of times to create a meaningful graph for your purposes (for example, at least 10 or more times).
Graphs Do Not Appear in Analysis Reports
Problem The browser's missing graphic icon appears where graphs should appear in analysis reports. The likely cause is that the Common Services session has expired.
Solution Log out of QPM and log back into Common Services using the Login dialog box in the desktop.
Subinterface Graphs Display Incorrect Bandwidth Percentages
Problem When a subinterface is displayed in monitoring graphs with the units of display set to percentage, the graph will display incorrect values for the subinterface in the following cases:
•The subinterface has CIR or Minimum CIR configured on it and the value assigned to these Qos features is different than the actual rate configured on the parent interface of the subinterface.
•The bandwidth of the parent interface was changed on the device but the device was not rediscovered by QPM.
Solution To fix this, rediscover the device. See Rediscovering Device Information, page 4-11.
Troubleshooting Threshold Analysis Problems
This section describes the following problem related to threshold analysis in QoS monitoring, and its solution.
Problem You are not able to open the Threshold Sets page (under Monitoring > Threshold Configuration) even after multiple attempts. QPM throws an unknown error while loading the page. This problem also affects the assignment of threshold sets to the devices (in the Threshold Assignment page).
Solution Restart Apache Tomcat on the QPM server. This resets the retry count that has reached the maximum value, and Tomcat can then load the threshold sets from the database during initialization.
Note You must pause any running Historical Monitoring jobs before you restart Tomcat. You can resume those Historical Monitoring jobs after the restart.
To restart Tomcat on the QPM server, go to Control Panel >
Administrative Tools > Component Services > Services, right click Apache Tomcat and select Restart.
Troubleshooting the IP Telephony Network
The following topics help you troubleshoot problems with the IP telephony network:
•Deployment fails because interface does not support "mls qos vlan-based" command
•Shaping interval is 0 milliseconds. Intervals below 4 milliseconds rejected
•Deployment fails for a serial PPP interface
•Selected interfaces were not assigned
•Voice policy group templates are missing or are from a previous templates version set
Deployment fails because interface does not support "mls qos vlan-based" command
Problem This occurs while trying to configure VLAN-based QoS on a Catalyst 6000 device running IOS. The reason it occurs is because you must first configure the switchport command on the interface to configure the VLAN-based QoS command.
Solution Configure the switchport command (switchport<cr>) manually on the interface before configuring VLAN-based QoS (mls qos vlan-based).
Shaping interval is 0 milliseconds. Intervals below 4 milliseconds rejected
Problem This message displays while trying to deploy policies to a Frame Relay interface on a VIP card. The reason it occurs is because Modular shaping on VIP cards requires the BC/CIR interval to be in units of 4 milliseconds.
Solution Adjust the shaping parameters according to the link speed. If you have several rates, you can create a group for each rate. Note that the IP Telephony wizard will assign the interfaces to only one of the groups, and you will have to move the others manually.
Deployment fails for a serial PPP interface
Problem After assigning a serial Point-to-Point interface with a rate equal to or less than 768kbs, this error occurs on deployment. The reason it occurs is that serial Point-to-Point cannot support LFI, which is applied on interfaces with link speeds below 768kbs.
Solution Select a multilink interface instead of a serial one. The following provides an example of a Multilink configuration:
•interface Multilink20
– bandwidth 256
– ppp multilink
– multilink-group 20
•interface Serial5/2
– bandwidth 256
– encapsulation ppp
– multilink-group 20
Selected interfaces were not assigned
Problem After selecting an interface in a configuration step of the IP Telephony wizard, it was not assigned to any voice policy group. It appears in the "Selected but not assigned" counter. The reason could be that the interface has no policies for the current voice role.
Solution There is no recommended action since this is expected behavior for an interface with no policies for the current voice role. See Assignment Summary, page 7-6 for more details about interface assignments.
Voice policy group templates are missing or are from a previous templates version set
Problem This occurs if you deleted templates from the QPM template library, or if you imported a QPM database from QPM 3.2.x.
Solution When you run the IP Telephony wizard, any required voice policy group templates that are missing are generated. If you have voice templates from a previous templates version set, you should disconnect any attached policy groups and delete the templates before you run the IP Telephony wizard.
If you need to regenerate the entire set of voice policy group templates, do the following:
Step 1 Delete all the system voice policy group templates in the templates library (or delete only the ones you want to replace).
Step 2 Verify that all attached policy groups have been disconnected before deleting the templates. See Disconnecting Policies from Policy Templates, page 6-8 and Deleting Policy Templates, page 6-10.
Step 3 Open the qpm.local.cfg file in the CSCOpx\MDC\qpm\config folder.
Step 4 Change the line:
com.cisco.nm.qpm.server.framework.services.QpmVoiceService.createdTemplates=true
to:
com.cisco.nm.qpm.server.framework.services.QpmVoiceService.createdTemplates=false
Step 5 Restart the QPM server.
The latest voice policy group templates will be in the templates library.
Troubleshooting Database Backup Problems
This topic describes causes and solutions for problems you might encounter when trying to backup the QPM database:
•Scheduled Incremental Backup Fails
Scheduled Incremental Backup Fails
Problem If the time or date was changed on the QPM server, and the server was not restarted, the scheduled incremental backups following the time/date change fail.
Solution Restart the QPM server.
