Voice Health Monitor User Guide, 1.1 - Basic VHM Configuration [CiscoWorks Voice Health Monitor]

Table Of Contents

Basic VHM Configuration

Overview of VHM Configuration Tasks

Using the Administration Console

Managing and Unmanaging Voice Devices in VHM

Adding Individual Devices

Importing Devices from a Seed File

Deleting Devices from VHM

Unmanaging Devices

Managing Ethernet Voice Ports

Managing/Unmanaging Ethernet Voice Ports

Configuring Polling and Thresholds

Configuring Polling

Setting Thresholds

Setting Up Phone Monitoring

Adding a Phone

Importing Phones from a Seed File

Scheduling Inventory Collection

Impact of Scheduling on VHM Inventory Collection

How VHM Inventory Collection Works

Ensuring Accurate VHM Inventory Collection

Changing Inventory Collection Schedule

Viewing the Status of Inventory Collection

Deleting Devices from the Inventory

Configuring the Timeout Interval and Retries for Device Discovery

Configuring the Fault History Report Duration

Configuring Trap Receiving

Configuring Fault Notification

Using the GUI to Configure Adapters

Using the Command Line to Configure Adapters

Changing Subscriptions for Notification Adapters

Configuring the File Notifier Adapter

Using the GUI to Configure the File Notifier Adapter

Using the Command Line to Configure the File Notifier Adapter

Configuring the Mail Notifier Adapter

Using the GUI to Configure the Mail Notifier Adapter

Using the Command Line to Configure the Mail Notifier Adapter

Configuring the Trap Notifier Adapter

Using the GUI to Configure the Trap Notifier Adapter

Using the Command Line to Configure the Trap Notifier Adapter

Configuring ICS 7750 for Use with VHM

Configuring Cisco CallManager for Use with VHM

Enabling Minimal Trace on Cisco CallManager

Storing the Cisco CallManager Username and Password in VHM

Deleting a Stored Cisco CallManager Username and Password from VHM

Basic VHM Configuration

The Administration folder within the Voice Health Monitor folder contains the tools you need to configure VHM. A user in a CiscoWorks2000 Network Admin role can or the Network Operator role can view the configuration data. Users in all other roles have no access to the Administration folder.

The following topics explain how to use the applications in the Administration folder to effectively configure VHM:

•Overview of VHM Configuration Tasks

•Using the Administration Console

•Setting Up Phone Monitoring

•Scheduling Inventory Collection

•Configuring the Timeout Interval and Retries for Device Discovery

•Configuring the Fault History Report Duration

•Configuring Trap Receiving

•Configuring Fault Notification

•Configuring ICS 7750 for Use with VHM

•Configuring Cisco CallManager for Use with VHM

Overview of VHM Configuration Tasks

Within the Administration folder, the following allow you to configure the VHM system:

•Administration Console—Import device into VHM; change the default polling and threshold parameters that VHM provides; manage and unmanage devices.

•Phone Monitoring—Add and import IP Phones into VHM.

•Inventory Collection Scheduling—Schedule regular inventory collection that synchronizes VHM inventory with DFM and probes devices.

•Inventory Collection Status—View status of devices being added/imported into VHM.

•Change SNMP Settings—Modify the SNMP Timeout value for device discovery.

•Change Log Level—Change the logging level for VHM processes.

•Fault History Report Duration—Adjust the length of time for which VHM monitors Fault History reports.

•Trap Configuration folder—Specify the port VHM uses for receiving traps.

•Synthetic Transaction folder—Configure test transactions to run against Cisco CallManagers. The related instructions are in "Synthetic Transaction Configuration."

•EtherVoicePort Management—Manage or unmanage Ethernet ports of phone access switches to which IP phones can be connected.

•Fault Notification folder—Configure notifications to send email, send trap messages, and log events to the alarm log.

Note You must configure any SPE on ICS 7750, enabling trace and SNMP. See the "Configuring ICS 7750 for Use with VHM" section for instructions.

Note Cisco CallManager must be configured for use with VHM. See the "Configuring Cisco CallManager for Use with VHM" section.

Using the Administration Console

This topic explains how to start the Administration Console and describes the kind of information included in the console.

To start the Administration Console:

Step 1 Use one of the following procedures:

•From the Voice Health Monitor drawer, select Administration > Administration Console. The Administration Console is displayed in its own window.

•From any Summary View or Status View in the Real-Time Dashboard, select Tools > Administration Console. The Administration Console is displayed in its own window.

The Administration Console contains two panels. The left panel displays an Inventory Browser that lists the system classes. Each type of managed element is represented by a system class, which consists of properties that describe a managed element. Properties include description, attributes, groups, and events.

Classes for VHM include PhoneAccessSwitch, MediaServer, Monitored Phone, InProgress, DiscoveryFailed, DigitalVoiceGateway, VoiceGateway, VoiceServices, WorkFlowApp, Voice Cluster, Unsupported, and Undiscovered. When a class is selected, the right panel displays the properties of the class in three separate tabs. Table 5-1 lists the available properties of the class.

Caution When the VHM domain is manually attached in DFM using the DFM Administration Console, classes are not displayed by default under VHM Domain in the DFM Administration Console. Use the VHM Administration Console to see the correct class list under VHM Domain.

Table 5-1 VHM System Class Properties

Tab

Description

Attributes

Lists the attributes of the class. Note that the attributes do not contain values.

Events

Events that occur in instances of the class, or events that can affect instances of the class.

Description

Description of the class.

The Administration Console layout and how to customize it are more fully described in the User Guide for Device Fault Manager.

This section contains the following topics:

•Managing and Unmanaging Voice Devices in VHM

•Managing Ethernet Voice Ports

•Configuring Polling and Thresholds

Managing and Unmanaging Voice Devices in VHM

You must add voice devices to VHM. You may also unmanage or delete devices from VHM. The voice devices that you import into VHM are used as the basis of discovery for the voice network.

This section contains the following topics:

•Adding Individual Devices

•Importing Devices from a Seed File

•Deleting Devices from VHM

•Unmanaging Devices

Adding Individual Devices

You can add individual voice devices for VHM to manage by adding an agent.

Note For adding IP phones, see the "Adding a Phone" section.

To add an agent:

Step 1 On the Administration Console, select Inventory > Add Agent. The Add Agent window appears.

Step 2 Select VHM and click OK.

Step 3 Enter the Agent Name and Read Community strings for the device. If a Read Community string is not specified, a default value of public is used.

Step 4 Click OK.

To view the devices that are being added, click Inventory Collection Status under Administration.

Importing Devices from a Seed File

You can import an initial voice network topology into the VHM server from a seed file. The the seed file containing your phones, must be a separate seed file from the one containing all your other devices.

Note For importing monitored phones using a seed file, see the "Importing Phones from a Seed File" section.

Note If you are importing Cisco CallManager Release 3.0 devices, and there are voice gateways registered with the CallManagers, the Media Servers running those CallManagers must be discovered (or rediscovered if connectivity is lost) before the voice gateways. The Media Servers must be discovered first so that VHM can capture the registration relationship between the entities. This is not required for Cisco CallManager 3.1 or later.

A seed file consists of:

•Lines containing one or two columns

•Any combination of spaces and tab characters separating the columns.

The first column identifies the network device. You can specify either a name or an IP address. The second column defines the read community string (by default it is "public"). To make your seed file more readable, you can include blank lines and comment lines. A comment line is one whose first character is "#."

Note The voice network discovery will not try to access any devices whose names are included on comment lines.

The following is an example of the contents of a seed file.
# Sample seed file
192.168.121.25 
example.cisco.com public
192.168.1.200 private
access-router-1 private
IP Address or DNS Name

Community String

192.168.121.25

example.cisco.com

public

192.168.1.200

private

access-router-1

Note If a community string is not specified, VHM will use the default value (public).

The default read community string (public, unless changed) is used for the devices at IP address 192.168.121.25 and access-router-1, because an alternate string is not specified. The read community string for 192.168.1.200 is private, and the read community string for example.cisco.com is public.

To import devices from a seed file:

Step 1 On the Administration Console, select Inventory > Import from seed file. The Import from seed file window appears.

Step 2 From the list of domain managers, select VHM and click OK.

Step 3 Enter the path where the seed file resides (for example, NMSROOT\conf\seedfile).

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

Step 4 Click OK.

Note When devices are imported using the seed file option, they are added to the device list. If a device in the seed file already exists, the community string of the device is overridden with the community string value from the seed file.

Note Do not add a device to VHM if it already exists in DFM. To update the inventory, you should rediscover the device. If the credentials (SNMP read community string) are changed for a device, you should delete the device from DFM and VHM and then re-add it.

Deleting Devices from VHM

See the "Deleting Devices from the Inventory" section for instructions on deleting devices from VHM.

Unmanaging Devices

The manage and unmanage operations enable you to control whether a domain manager monitors a particular device or element. It is useful to unmanage a device when, for example, a switch or a card is taken offline for maintenance and you do not want to receive error or performance notifications regarding that device.

The general procedures for managing and unmanaging objects are described in the User Guide for Device Fault Manager.

Note If a device is unmanaged and then managed again from the Administration Console, the instrumentation for that device is not recreated until VHM is manually reconfigured from the Administration Console.

Managing Ethernet Voice Ports

By default, VHM manages Ethernet ports with IP phones connected to them. If an IP phone is disconnected from an Ethernet port that is in Auto state, the port then becomes unmanaged during the next discovery cycle. If you want to manage an Ethernet port that does not have any phones connected to it, you have to manage the port manually.

Note If a phone is removed, a PhoneRemoved event is sent to the Monitoring Console. During the next discovery (either a manual discovery or nightly rediscovery), the event is removed.

You can configure VHM to manage Ethernet voice ports in two ways:

•Through the Voice Port Management window (see the "Managing/Unmanaging Ethernet Voice Ports" section).

•Using the Administration Console (see the User Guide for Device Fault Manager for a complete description on managing and unmanaging devices).

Note If you want to continue managing the Ethernet ports with IP phones connected to them even if the IP phones are removed, select the Keep ports managed even after phones are removed check box in the Voice Port Management window (Voice Health Monitor > Administration > EtherVoicePort Management > Manage Ports).

Managing/Unmanaging Ethernet Voice Ports

To configure VHM to manage/unmanage Ethernet voice ports:

Step 1 From the CiscoWorks2000 desktop, select Voice Health Monitor > Administration > EtherVoicePort Management > Manage Ports. The Voiceport Management window opens.

Step 2 Select the phone access switch from the PhoneAccessSwitch drop-down list. A list of the Ethernet voice ports on the switch appears in the selection box.

Step 3 Select the Ethernet voice ports you want to manage/unmanage. To select multiple ports, use the Shift and Ctrl keys.

Note If you have ports you want to set to manage and ports you want to set to unmanage, perform each action separately.

Step 4 Select Manage or Unmanage.

If you want to continue managing the Ethernet ports with IP phones connected to them even if the IP phones are removed, select the Keep ports managed even after phones are removed check box.

Note If you apply Auto to an Ethernet voice port, its settings are reset to the default settings, according to the CDP table.

Step 5 Click Done.

Step 6 If you are managing a port, in the Voice Port Management window, click the Reconfigure VHM button. If you are unmanaging a port, this is not required.

Configuring Polling and Thresholds

Voice network health depends upon the performance of voice-enabled devices. VHM polls these devices on a regular basis at user-configured polling intervals. During polling, if VHM determines that the thresholds you have set have been violated, alarms are generated to notify you of these events.

VHM is preconfigured with default polling intervals and threshold parameters. You can change these default values to suit your needs.

Note After changing polling or threshold settings, you should save inventory and reconfigure VHM.

Note To ensure reliable correlation between VHM and DFM, synchronize the polling intervals in VHM with those in DFM.

For additional information about interdependencies, see Table 1-1.

Threshold and polling parameters are applied to a group of devices.

The following are default polling groups for VHM:

•Media Servers

•VoiceGateways

•PhoneAccessSwitches

•Integrated Communication System (ICS)

•SPE

•DigitalVoiceGateways

•MRP

•VoiceMailGateways

•Gatekeepers

•VoiceCluster

•DigitalVoiceInterfaces

•VoiceServices

•WorkFlowApp

•CiscoCallManager

•MonitoredPhoneGroup

•MonitoredPhones

•VoiceClusterGroup

•Others

The following are default threshold groups for VHM:

•Media Servers

•SPE

•VoiceMailGateways

•CiscoCallManagers

•VoiceCluster

•Others

Thresholds for voice-enabled routers (Voice Gateways) and switches (Phone Access Switches) must be set using DFM.

Note To ensure that the changes take effect, always reconfigure the VHM (or DFM) domain after changing the polling or threshold values.

Instructions for updating polling and threshold groups are included in the User Guide for Device Fault Manager.

To start the Polling and Thresholds window:

Step 1 From the Administration Console, select Edit > Polling and Thresholds.

The Polling and Thresholds window appears.

Step 2 Select either the Polling or Threshold tab at the bottom of the window.

Configuration groups are displayed in the left panel of the window.

Step 3 Click a configuration group to display that group's settings. At this point, you can also display the description, priorities, and matching criteria for the group.

Step 4 Review the default information for the groups of the domain.

Step 5 After making changes, reconfigure the domain so that the changes will take effect.

•Select Inventory > Reconfigure > VHM/DFM, and click OK.

Or

•Click the Reconfigure icon on the toolbar.

Note Changes to the polling intervals take effect after the current polling cycle is completed. For example, if the current polling cycle of 10 minutes is changed to 30 seconds, you will have to wait for the current polling cycle to complete before the new setting of 30 seconds takes effect.

Note The Polling and Thresholds window and its menus, buttons, and functions are described in the User Guide for Device Fault Manager.

Configuring Polling

You can access or change the settings on the Polling tab of the Polling and Thresholds window. This window and its menus, buttons, and functions are described in the User Guide for Device Fault Manager. For instructions on starting the Polling and Thresholds window, see the "Configuring Polling and Thresholds" section.

This section contains the following topics:

•Environment Polling—Power Supply, Fan, and Temperature Sensor

•Environment Polling—RIB Card

•Environment Polling—Voice Cluster

•External Polling

•Performance Polling—Cisco CallManager Application

•Performance Polling—Disk Usage and Virtual Memory

•Performance Polling—CPU and Physical Memory (RAM)

•Performance Polling—DS1 Voice Port

•Performance Polling—E1 Voice Port

•Performance Polling—FXS Voice Port

•Performance Polling—Phone Access Switch Ethernet Port

•Performance Polling—Power Supply, Fan

•Performance Polling—Interface

•Voice Port to Cisco CallManager Connectivity Polling

•DPA Port to Cisco CallManager Connectivity Polling

Environment Polling—Power Supply, Fan, and Temperature Sensor

Environment Polling settings configure polling intervals used to monitor the environmental conditions of a system. System components such as the power supply, fan, voltage sensor, and temperature sensor elements are monitored. Table 5-2 lists the parameters included in the Environment Polling settings.

Table 5-2 Environment Polling—Power Supply, Fan, and Temperature Sensor Settings

Parameters

Default Value

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive connectivity polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Environment Polling—RIB Card

Environment Polling settings configure polling intervals used to monitor the environmental conditions of a system. System components such as the RIB card are monitored. Table 5-3 lists the parameters included in the Environment Polling settings.

Table 5-3 Environment Polling—RIB Card Settings

Parameters

Default Value

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive connectivity polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Environment Polling—Voice Cluster

Environment Polling settings configure polling intervals used to monitor the environmental conditions of a system. Table 5-4 lists the parameters included in the Environment Polling settings for a voice cluster.

Table 5-4 Environment Polling—Voice Cluster Settings

Parameters

Default Value

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive connectivity polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

External Polling

External Polling settings configure polling intervals used to monitor notifications from a server. Table 5-5 lists the parameters included in the External Polling settings.

Table 5-5 External Polling Settings

Parameters

Default Value

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive connectivity polls. The default value varies depending on the polling group.

Server Name

Name of the server that clients contact for polling notifications. The default value is PollingServer. Do not change this value.

Table 5-6 lists the polling groups that use external polling.

Table 5-6 Polling Groups that Use External Polling

Polling Group

Description

Media Servers

Applies to suspect phone external polling

VoiceGateways

Applies to polling the connectivity status of ports/cards of voice gateways with Cisco CallManager

SPE

Applies to polling suspect phones in Cisco CallManager hosted by SPE.

DigitalVoiceGateways

Applies to polling the connectivity of digital voice gateways with Cisco CallManager.

MRP

Applies to polling the connectivity of MRP with Cisco CallManager.

Gatekeepers

Applies to polling the connectivity status of gatekeeper with Cisco CallManager

DigitalVoiceInterfaces

Applies to digital voice interface external polling

VoiceServices

Applies to polling voice services such as TFTP.

WorkFlowApp

Applies to polling WorkFlow Applications

CiscoCallManager

Applies to polling Cisco CallManager services

Monitored Phone Group

Applies to polling phone monitoring

VoiceClusterGroup

Applies to polling cluster level information.

Performance Polling—Cisco CallManager Application

Table 5-7 lists the parameters included in the Performance Polling—Cisco CallManager Application settings.

Table 5-7 Performance Polling—Cisco CallManager Application

Parameter

Default Value

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 5.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 3000 milliseconds.

Performance Polling—Disk Usage and Virtual Memory

Performance Polling—Disk Usage and Virtual Memory settings configure polling for monitoring disk usage and virtual memory. Table 5-8 lists the parameters included in the Performance Polling—Disk Usage and Virtual Memory settings.

Table 5-8 Performance Polling—Disk Usage and Virtual Memory Settings

Parameter

Default Value

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Performance Polling—CPU and Physical Memory (RAM)

Table 5-9 lists the parameters included in the Performance Polling—CPU and Physical Memory settings.

Table 5-9 Performance Polling—CPU and Physical Memory Settings

Parameter

Default

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Performance Polling—DS1 Voice Port

Table 5-10 lists the parameters included in the Performance Polling—DS1 Voice Port settings.

Table 5-10 Performance Polling—DS1 Voice Port Settings

Parameter

Default

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Performance Polling—E1 Voice Port

Table 5-11 lists the parameters included in the Performance Polling—E1 Voice Port settings.

Table 5-11 Performance Polling—E1 Voice Port Settings

Parameter

Default

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Performance Polling—FXS Voice Port

Table 5-12 lists the parameters included in the Performance Polling—FXS Voice Port settings.

Table 5-12 Performance Polling—FXS Voice Port Settings

Parameter

Default

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Performance Polling—Phone Access Switch Ethernet Port

Table 5-13 lists the parameters included in the Performance Polling—Phone Access Switch Ethernet Port settings.

Table 5-13 Performance Polling—Phone Access Switch Ethernet Port Settings

Parameter

Default

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Performance Polling—Power Supply, Fan

Table 5-14 lists the parameters included in the Performance Polling—Power Supply, Fan settings.

Table 5-14 Performance Polling—Power Supply, Fan Settings

Parameter

Default

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Performance Polling—Interface

Table 5-15 lists the parameters included in the Performance Polling—Interface settings.

Table 5-15 Performance Polling—Interface Settings

Parameter

Default

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 3.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 700 milliseconds.

Voice Port to Cisco CallManager Connectivity Polling

Table 5-16 lists the parameters included in the Voice Port to Cisco CallManager Connectivity settings.

Table 5-16 Voice Port to Cisco CallManager Connectivity Polling Settings

Parameter

Default

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 5.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 3000 milliseconds.

DPA Port to Cisco CallManager Connectivity Polling

Table 5-17 lists the parameters included in the DPA Port to Cisco CallManager Connectivity settings.

Table 5-17 DPA Port to Cisco CallManager Connectivity Polling Settings

Parameter

Default

Analysis Mode

Enable or disable connectivity or availability polling. The default is Enabled.

Polling Interval

The time between successive performance polls. The default value is 240 seconds.

Retries

The number of times to retry a failed poll request. The default value is 5.

Timeout

The amount of time allowed for the first poll request before it times out. The default value is 3000 milliseconds.

Setting Thresholds

You can set thresholds for media servers and SPE only using VHM. Thresholds for voice-enabled routers (Voice Gateways) and switches (Phone Access Switches) must be set using DFM. See the User Guide for Device Fault Manager for instructions.

You can access or change the threshold settings on the Threshold tab of the Polling and Thresholds window. This window and its menus, buttons, and functions are all described in the User Guide for Device Fault Manager. For instructions on starting the Polling and Thresholds window, see the "Configuring Polling and Thresholds" section.

These topics describe available threshold settings:

•Threshold Setting—Suspect Phones

•Threshold Setting—Voice Cluster

•Threshold Setting—Synthetic Transaction Failure

•Threshold Setting—CPU and Physical Memory (RAM)

•Threshold Setting—Disk Usage and Virtual Memory

•Threshold Setting—Environment: RIB Card

•Threshold Setting—Environment: Temperature Sensor

Threshold Setting—Suspect Phones

The Suspect Phones setting monitors the percentage of suspect phones that tried to connect to the CallManager. The available parameter setting is:

•SuspectPhoneThreshold—Represents the upper threshold for suspect phones that fail to register with Cisco CallManager. The default Value is 10.

Threshold Setting—Voice Cluster

The Voice Cluster settings monitor the number of inactive phones connected to the Cisco CallManager. The available parameter settings are:

•InActivePhoneThreshold—Represents the upper threshold for inactive phones. It is expressed as a percentage of the total number of phones connected to the Cisco CallManager cluster. The default value is 10.

Threshold Setting—Synthetic Transaction Failure

The Synthetic Transaction Failure setting monitors the failure rate of the synthetic transactions. The available parameter setting is:

•TransactionFailureThreshold—Represents the higher threshold for the failure rate of the synthetic transaction. It is expressed as a percentage of the total number of synthetic transactions. The default value is 50.

Threshold Setting—CPU and Physical Memory (RAM)

CPU and Physical Memory settings configure the performance monitoring of a system's CPU and its associated memory elements. The available parameter settings are:

•FreePhysicalMemoryThreshold—Contains minimum acceptable free physical memory expressed as a percentage of the total amount of physical memory. The default value is 15.

•ProcessUtilizationThreshold—The upper threshold for processor utilization expressed as a percentage of the total capacity of the processor. The default value is 90.

Threshold Setting—Disk Usage and Virtual Memory

Disk Usage and Virtual Memory settings monitor the performance of disk usage and virtual memory elements. Events such as high disk utilization and high virtual memory utilization are controlled by the following parameters:

•FreeHardDiskThreshold—Threshold for minimum amount of hard disk space expressed as a percentage of the total hard disk memory. The default value is 15.

•FreeVirtualMemoryThreshold—Threshold for minimum amount of free virtual memory expressed as a percentage of total virtual memory. The default value is 15.

Threshold Setting—Environment: RIB Card

•BatteryPercentChargedThreshold—Low threshold setting, expressed as a percent of battery charge. The default value is 20.

Threshold Setting—Environment: Temperature Sensor

•TemperatureCelsiusThreshold—Temperature threshold in degrees Celsius. The default value is 30.

Setting Up Phone Monitoring

With phone monitoring, you can monitor the health of important phones in your network. Through the Real-Time Dashboard, you can view information about the phones, such as the total number of monitored phones, a phone's reachability, and its registration with a Cisco CallManager.

Note You can only monitor IP phones registered with Cisco CallManager Release 3.1 or Release 3.2.

To enable VHM to monitor IP phones, you need to store the username and password of the Cisco CallManager on the VHM system. See "Storing the Cisco CallManager Username and Password in VHM" section.

The VHM server must be able to perform DNS resolution of the Cisco CallManager hostname and successfully resolve it to its IP address. Otherwise, the information shown in the Real-Time Dashboard may be incorrect. See the Release Notes for Voice Health Monitor Release 1.1 on Windows 2000 for any known problems with DNS resolution.

Following are caveats to note when working with monitored phones:

•In the Device Detail View for a monitored phone registered to a Cisco CallManager cluster, the Connectivity tab does not indicate a critical status (red rows or columns) until the phone has lost contact with all Cisco CallManagers in the cluster.

•In the Device Detail View for a monitored phone, the switch port connection may indicate that it is not available even though the voice port is managed by VHM. To show the switch port information correctly in the Device Detail View and the Administration Console, discover the switch before discovering the IP phone, or rediscover the IP phone after the switch is discovered.

Adding a Phone

To monitor a phone, you must first add it to VHM. You can add a single phone or multiple phones at one time.

To add a monitored phone:

Step 1 From the CiscoWorks2000 desktop, select Voice Health Monitor > Administration > Phone Monitoring. The Phone Monitoring window opens.

Step 2 Enter the Extension Number and MAC Address.

Note The MAC address can be entered in either of the following formats: 898989898989 or 89-89-89-89-89-89.

Step 3 Click Add.

If the phone is already in the VHM Repository, a dialog box opens, asking if you want to rediscover the phone. Click Yes.

Importing Phones from a Seed File

The the seed file containing your phones, must be a separate seed file from the one containing all your other devices.

To add multiple monitored phones:

Step 1 From the CiscoWorks2000 desktop, select Voice Health Monitor > Administration > Phone Monitoring. The Phone Monitoring window opens.

Step 2 Enter the location of the seed file in the Seed File field. (For example, enter NMSROOT\conf\seedfile). If you do not know the location, you can click the Browse button and navigate to the file location. The file must be located on the system where VHM is installed.

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

The format of the seed file consists of the extension number followed by the MAC address, with a colon (:) separating them; for example, 5001:898989898989 or 5001:89-89-89-89-89-89.

The MAC address can be formatted with or without a hyphen (-) between every two digits. The seed file can have comment lines. Comment lines must be preceded by a pound (#) symbol.

The following is a sample seed file:
#Extn:MAC Address 
37013:000000050012 
37014:000000050013 
37023:000000050014 
#CCM 3.2 phones 
37022:000000050015 
37026:000000050016 
37012:000000050017 
37027:00-00-00-05-00-18
Step 3 Click Import.

If the phone is already in the VHM Repository, a dialog box opens, asking if you want to rediscover the phone. Click Yes.

Scheduling Inventory Collection

You can schedule periodic inventory collection for VHM.

These topics explain the process:

•Impact of Scheduling on VHM Inventory Collection

•How VHM Inventory Collection Works

•Ensuring Accurate VHM Inventory Collection

•Changing Inventory Collection Schedule

•Deleting Devices from the Inventory

Impact of Scheduling on VHM Inventory Collection

During a scheduled VHM inventory collection, VHM synchronizes its inventory with DFM inventory. During synchronization only, new voice-enabled devices in DFM are imported in VHM.

Note For VHM to synchronize with the most up-to-date DFM inventory, Network Administrators must set the DFM Rediscovery Schedule so that DFM rediscovery completes before VHM inventory collection starts.

How VHM Inventory Collection Works

During VHM inventory rediscovery, a device is checked to see if it is reachable. Any new components (for example, voice cards) on the device are discovered by VHM. Inventory rediscovery also deletes any components from VHM that are no longer needed.

Ensuring Accurate VHM Inventory Collection

VHM inventory collection depends on data from DFM inventory collection. Schedule and run DFM inventory collection to determine how long it takes. Use this time period to determine when to schedule VHM inventory collection. It should be scheduled to begin shortly after DFM inventory collection has completed. This ensures that all the newest devices are available in the DFM inventory before VHM synchronizes its inventory with DFM.

Changing Inventory Collection Schedule

By default, inventory collection runs at 3:00 a.m every day.

To change the inventory collection schedule:

Step 1 From the CiscoWorks2000 desktop, select Voice Health Monitor > Administration > Inventory Collection Scheduling. The Inventory Collection Schedule window is displayed.

Step 2 From the Inventory Collection Scheduling window, select values for the following parameters to change the current settings.

Table 5-18 Inventory Collection Scheduling Settings

Parameter

Description

Start Date

Specifies the day, month, and year on which the first inventory collection will be scheduled.

Time

Specifies the hour and minute at which inventory collection will be triggered.

Frequency

Specifies the intervals at which inventory collection happens. The options are Weekly and Daily.

Step 3 Click OK.

Viewing the Status of Inventory Collection

When a device is added, Inventory Collection discovers the device and determines its type. You can view a snapshot of the status of Inventory Collection.

To view the status of Inventory Collection—In-Progress Devices:

Step 1 From the CiscoWorks2000 desktop, select Voice Health Monitor > Administration > Inventory Collection Status. The Current Status of Inventory Collection window appears.

Table 5-19 shows the information you can view in the Current Status of Inventory Collection window.

Table 5-19 Current Status of Inventory Collection—In Progress Devices

Parameter

Description

Snapshot view

Contains the following options:

•In Progress Devices (devices being discovered).

•Discovery Failed Devices (devices that could not be discovered).

S. No

Status number.

Hostname

Name or IP address of device.

Discovery Status

Status of discovery.

Type

Reason for discovery/rediscovery.

Discovery started at

Date and time discovery started.

Refresh

Updates the window with the latest discovery status information.

To view the status of Inventory Collection—Discovery Failed Devices:

Step 1 From the CiscoWorks2000 desktop, select Voice Health Monitor > Administration > Inventory Collection Status. The Current Status of Inventory Collection window appears.

Step 2 Select the Discover failed Devices radio button.

Table 5-20 shows the information you can view in the Current Status of Inventory Collection window.

Table 5-20 Status of Inventory Collection Window—Discovery Failed Devices

Parameter

Description

Snapshot view

Contains the following options:

•In Progress Devices (devices currently being discovered).

•Discovery Failed Devices (devices that could not be discovered).

Timeout

The duration of time VHM waits before trying to contact the device again. The duration is doubled each time, until the maximum retry count is reached. See the "Configuring the Timeout Interval and Retries for Device Discovery" section.

Retry count

The number of times VHM will try to contact the device (SNMP retries).

S. No

Status number.

Hostname

Name or IP address of device.

Discovery Status

Reason for failed discovery.

Discovery failed at

The date, time, and at what stage the discovery failed.

Read community

Read community string.

Refresh

Updates the window with the latest discovery status information.

Deleting Devices from the Inventory

You can delete a device from the inventory using the inventory view in the Administration Console. The general procedures for managing and unmanaging objects are described in the User Guide for Device Fault Manager.

To delete a device from the VHM inventory:

Step 1 Select a system-level object from one of the following classes:

•MediaServer

•VoiceGateway

•ICS

•Phone Access Switch

•Monitored Phone

•VoiceMailGateway

A system-level object is the top-level object within a class.

Note Do not select devices from the Composed Of list for any system-level object.

Caution Do not delete devices from the following classes: Voice Cluster, Voice Services, WorkFlowApp, CiscoCallManager, DigitalVoiceGateway, ClusterProxy, VoicePort, VoiceCard, Voice Interface, DPAPort, and InProgress.

Step 2 Right-click the object you want to delete, and select Delete from the menu.

Configuring the Timeout Interval and Retries for Device Discovery

If an SNMP query does not respond in time, VHM will timeout. It will then retry contacting the device for as many times as listed under the snmpretries attribute in the configuration file. The timeout period is doubled for every subsequent retry. For example, if the timeout value is 4 seconds and the retries value is 3 seconds (the default values), VHM waits for 4 seconds before the first retry, 8 seconds before the second retry, and 16 seconds before the third retry.

To configure the SNMP timeout interval:

Step 1 Click Voice Health Monitor > Administration > Change SNMP Settings. The SNMP Settings window appears.

Step 2 Enter the Timeout value.

If you want to reset the Timeout value to the default, click the Default button.

Step 3 Click Apply.

Step 4 In the confirmation dialog box click OK.

To configure the SNMP timeout interval and the number of retries:

Step 1 Using Windows Explorer on your VHM system, open the folder cscopx\objects\vhm\inventorycollector folder.

Step 2 Using a text editor (notepad), open the InventoryConfig.conf file.

Step 3 Edit the value of the properties for snmptimeout (in seconds) and snmpretries.

Step 4 Save the file.

Step 5 Stop and restart the CiscoWorks2000 Daemon Manager through the Services window from the Windows 2000 desktop. This is required for the changes to take effect.

Configuring the Fault History Report Duration

Fault History stores reports up to a maximum of fifteen days, and can be configured in Fault History Administration. In VHM, you can set the duration of time you want the report to cover.

Note The Fault History Report Duration does not appear if Fault History is not installed. Fault History is installed separately from VHM.

To configure the Fault History report duration:

Step 1 From the CiscoWorks2000 desktop, select Voice Health Monitor > Administration > Fault History Report Duration. The Fault History Report Duration window opens.

Step 2 Select the duration (in hours) from the drop-down menu. If you want to reset the default duration (8 hours), click Default.

Step 3 Click OK.

Configuring Trap Receiving

This topic explains how to change the default port number that VHM uses to receive traps. VHM is completely dependent on DFM to receive traps from voice-enabled devices. When you configure VHM trap receiving, you must also configure the DFM trapd.conf file to reflect the new port number so that VHM continues to receive traps from DFM.

Note The default value for the VHM trap port is 9009. The default value for the DFM trap port is 162. For trap port configuration scenarios in which both DFM and a Network Management System are in use, please refer to User Guide for Device Fault Manager. See the "Ports and Protocols Used by VHM and DFM" section for a complete list of ports used by both products.

To configure the trap port number:

Step 1 Click Voice Health Monitor > Administration > Trap Configuration > Trap Receiving. The VHM Trap Receiving window appears.

Step 2 Modify the Listening Port number.

Step 3 Modify the DFM trapd.conf file with the new VHM trap receiving port number:

•If DFM is installed on the same system:

–You can select Yes for Update the DFM trapd.conf file automatically? and click OK

or

–You can select No, click OK, and then manually update the DFM trapd.conf file

Note After you click OK, the DFM server and VHM server shut down and restart automatically.

•If DFM is installed on another system, you must manually update the trapd.conf file.

Note When DFM is on another system, only the VHM server will shutdown and restart.

Note The User Guide for Device Fault Manager contains complete instructions for updating the DFM trapd.conf file.

Configuring Fault Notification

You can configure fault notification adapters to forward event information to recipients on the network. VHM provides three types of fault notification adapters:

•File Notifier Adapter—Logs alarms detected by the VHM server and forwards them to a file. A file is the only valid recipient for this adapter. Use this adapter to create a historical file containing all alarms generated by VHM.

•Mail Notifier Adapter—Uses SMTP to send mail notifications to recipients. Like the Trap Notifier Adapter, you can specify the recipients—in this case, an email address. Use this adapter to generate asynchronous email notifications when one or more alarm conditions occur. For example, you could use the Mail Notifier Adapter to send an epage to a specified list of recipients. For less serious faults, you might want to forward the notifications to a list of email addresses.

•Trap Notifier Adapter—Converts alarms into SNMP trap messages and forwards the traps to recipients. You can specify the recipients, such as network management systems or other domain managers, using an IP address or a system name. Use this adapter to send alarms to another application or NMS for additional processing or display. The format of the converted SNMP trap messages is provided in the User Guide for Device Fault Manager.

Note If you use the command line to configure the adapter while it is running, you must then stop and restart the adapter, so that the new configuration file can take effect. You can do this by using the GUI to disable (stop) and enable (restart) the adapter.

Using the GUI to Configure Adapters

Configuring an adapter using the GUI automatically restarts the CiscoWorks2000 process associated with the adapter.

Adapter

VHM GUI Choice

For more information, refer to...

File Notifier Adapter

Voice Health Monitor > Administration > Fault Notification  > File Notifier

Configuring the File Notifier Adapter

Mail Notifier Adapter

Voice Health Monitor > Administration > Fault Notification  > Mail Notifier

Configuring the Mail Notifier Adapter

Trap Notifier Adapter

Voice Health Monitor > Administration > Fault Notification  > Trap Notifier

Configuring the Trap Notifier Adapter

A VHM adapter process starts when you enable the adapter from its GUI and stops when you disable it from the GUI.

When an adapter starts, its configuration information is loaded from a file. The configuration files have the extension .conf and are located in directories under the directory NMSROOT\objects\smarts\vhm-conf.

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

Caution Do not rename the configuration files or move them. Adapters that cannot find the required configuration file will not run.

Using the Command Line to Configure Adapters

To change the configuration of an adapter using the command line:

Step 1 Locate the configuration file for the given adapter. The configuration files are located in the NMSROOT\objects\smarts\vhm-conf directory; the file names are listed in the sections that provide detailed information about the adapters.

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

Note Save a copy of any configuration file you intend to change, and mark it as a backup file.

Step 2 Use any text editor to change the parameters. Change only the parameters listed. To change notification adapter subscriptions, follow the instructions in the "Changing Subscriptions for Notification Adapters" section.

Step 3 Save the edited configuration file.

Step 4 Stop and restart the CiscoWorks2000 process that runs the adapter by disabling and enabling the adapter using the GUI.

Changing Subscriptions for Notification Adapters

The File Notifier, Mail Notifier, and Adapter Trap Notifier configuration files contain a SubscribesTo parameter that specifies the devices and notifications the adapter should monitor. This allows you to tailor the adapters to track only the information you want.

The following topics describe how to use subscriptions with notification adapters.

Specifying a Notification Adapter's Subscription Profile

You can directly edit a notification adapter configuration file to specify a particular subscription profile (profileName), which identifies the events the adapter will track. (Creating subscription profiles is described in the User Guide for Device Fault Manager.)

Note The profileName must match an existing VHM subscription profile.
SubscribesTo =
{
	GA_ProfileSubscription::Filelog-Default-Profile-Subscriptions
	{
		profileName = "default"
	}
}
Specifying Particular Events to Be Tracked by a Notification Adapter

You can directly edit a notification adapter configuration file to specify the events to which a notification adapter will subscribe. The device parameters for subscriptions include:

className

Type of managed element (for example, Cisco CallManager).

instanceName

Objects that describe the managed element (for example, CCM—routers.cisco.com).

eventName

Name of compound or symptom to be reported for the managed element (for example, Power Supply Down).

aggregates

Compound events. If set to TRUE, sends a notification when the selected compound events occur.

symptoms

Symptomatic events. If set to TRUE, sends a notification when the selected symptomatic events occur.

A complete list of valid classes and events is provided in Table 5-21. This method is normally used with the Mail Notifier Adapter and Trap Notifier Adapter. The File Notifier Adapter is ready to use; normally, you will want to enable only the File Notifier Adapter to create one repository for all generated alarms.

Table 5-21 lists the classes, instances, and events supported by DFM.

Table 5-21 Supported Subscription Classes and Events

Class

Event (Symptom/Compound)

CiscoCallManager

ApplicationMonitoringException

CallManagerDown

TooManySuspectPhones

ClusterProxy

LostContactWithCluster

DeviceInterface

InterfaceAdministrativelyDown

InterfaceOperationallyDown

DeviceMemory

InsufficientFreeMemory (S)

DeviceTemperatureSensor

TemperatureSensorDown (S)

TemperatureSensorDegraded (S)

DigitalVoiceGateway

ConnectivityException (C)

GatewayLostContactWithCluster

OperationalException

Unmanaged

DigitalVoiceInterface

InterfaceOperationallyDown

DiscoveryFailed

CCMDiscoveryFailed

Fan

FanDegraded

FanDown

Gatekeeper

ConnectivityException

Unmanaged

HardDisk

InsufficientFreeHardDisk (S)

ICS

ApplicationException

OperationalException

PowerSupplyException

ResourceException

Unmanaged

Unresponsive

ICSFan

FanDown

ICSPowerSupply

PowerSupplyDown

MediaServer

ApplicationException

OperationalException

PowerSupplyException

ResourceException

TemperatureException

Unmanaged

Unresponsive

MonitoredPhone

ConnectivityException

MonitoredPhoneLostContactWithCluster

Unmanaged

Unresponsive

MRP

HighUtilization (S)

InsufficientFreeMemory (S)

OperationalException

ResourceException

Unresponsive (S)

PhoneAccessSwitch

GatewayLostContactWithCluster

OperationalException

PowerSupplyException

ResourceException

TemperatureException

Unmanaged

Unresponsive (S)

PowerSupply

PowerSupplyDown (S)

PowerSupplyDegraded (S)

Processor

HighUtilization

RAM

InsufficientFreePhysicalMemory (S)

SNMPAgent

Unresponsive (S)

SPE

ApplicationException

OperationalException

ResourceException

Unresponsive (S)

HighUtilization (S)

InsufficientFreeMemory (S)

SSP

OperationalException

ResourceException

Unresponsive (S)

SuspectPhone

SuspectPhoneDetected

SystemFan

FanDegraded

FanDown

SystemInterface

InterfaceOperationallyDown (S)

InterfaceAdministrativelyDown (S)

SystemPowerSupply

PowerSupplyDegraded

PowerSupplyDown

SystemProcessor

HighProcessorUtilization

SystemTemperatureSensor

TemperatureHigh

TemperatureSensorDegraded

TemperatureSensorDown

TransactionResult

TooManyUnsuccessfulSyntheticTransactions

TransactionFailed

Undiscovered

DiscoveryError

Unmanaged

Unsupported

Unmanaged

VHMSystem

ESSConnectivityLost

VHMDomainConnectivityLost

VirtualMemory

InsufficientFreeVirtualMemory (S)

VoiceCard

CardDown (S)

VoiceCardLostContactWithCluster

VoiceCluster

CCMHttpServiceDown

OperationalException

TooManyInActiveGateways

TooManyInActivePhones

VoiceGateway

ConnectivityException (C)

GatewayLostContactWithCluster

OperationException

PowerSupplyException

ResourceException

TemperatureException

Unmanaged

Unresponsive

VoiceClusterDeleted

VoiceInterface

InterfaceAdministrativelyDown

InterfaceOperationallyDown

VoiceInterfaceLostContactWithCluster

VoicePort

PhoneRemoved

PortLostContactWithCluster

Unmanaged

VoicePortOperationallyDown (S)

VoicePortAdministrativelyDown (S)

VoiceServices

ApplicationDown

ApplicationMonitoringException

WorkFlowApp

ApplicationDown (S)

RIBCard

BatteryDisconnected (S)

BatteryFailed (S)

BatteryLow (S)

In the following example, the Mail Notifier Adapter will report all Operational Exception aggregates (compound events) that occur on any voice gateway managed by VHM:
SubscribesTo =
{
        	GA_ChoiceSubscription::Mail-All-Subscriptions
	{
	# Subscribe to events whose class, instance, and event
	# names match the given pattern.
		 className = "VoiceGateway"
	      instanceName = ".*"
		 eventName = "OperationalException"
		aggregates = TRUE
		  symptoms = FALSE
	}
}
According to the following example, the Mail Notifier Adapter will send a report when the state of any MediaServer class or VoiceCluster class managed by VHM is not normal:
SubscribesTo =
{
             
	GA_ChoiceSubscription::MediaServer-All-Subscriptions
	{
		 className = "MediaServer"
	      instanceName = ".*"
		 eventName = ".*"
		aggregates = TRUE
		  symptoms = TRUE
	},
GA_ChoiceSubscription::VoiceCluster-All-Subscriptions
	{
		 className = "VoiceCluster"
	      instanceName = ".*"
		 eventName = ".*"
		aggregates = TRUE
		  symptoms = TRUE
	}
}
In the following example, the Mail Notifier Adapter will report all high utilization events that occur on any interface managed by VHM:
SubscribesTo =
{
             
	GA_ChoiceSubscription::Mail-All-Subscriptions
	{
	# Subscribe to events whose class, instance, and event
	# names match the given pattern.
		 className = ".*"
	      instanceName = ".*IF-.*"
		 eventName = "HighUtilization"
		aggregates = TRUE
		  symptoms = TRUE
	}
}
Configuring the File Notifier Adapter

The File Notifier can log alarms detected by the VHM server and store them in a file. You can use either the GUI or the command line to configure this adapter. The GUI lets you do essential configuration, while the command line lets you fine-tune the adapter. For more information, see the "Using the Command Line to Configure the File Notifier Adapter" section.

Using the GUI to Configure the File Notifier Adapter

You can enable or disable logging alarms detected by VHM in a log file.

To configure the file notifier adapter:

Step 1 Click Voice Health Monitor > Fault Notification > File Notifier. The File Notifier window appears.

Step 2 In the Adapter field, select ENABLED or DISABLED to enable or disable event logging in the alarms file.

Step 3 Click OK.

This procedure does the following:

•Enables or disables the process with CiscoWorks2000.

•Creates a log file for the file notifier NMSROOT\objects\smarts\logs\vhm_filelog_notifier.log.

•Creates the alarm file NMSROOT\objects\smarts\logs\VHM-alarms.log.

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

You do not need to restart CiscoWorks2000 for your changes to take effect. The GUI does this for you automatically.

To specify the types of notifications that you want forwarded to the alarms file, use the command line (refer to the "Using the Command Line to Configure the File Notifier Adapter" section).

Using the Command Line to Configure the File Notifier Adapter

This topic shows the contents of the file notifier adapter configuration file (NMSROOT\objects\smarts\vhm-conf\notifier\vhm_filelog_notify.conf).

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

Table 5-22 lists the parameters that you can change using the command line. Additional configuration of this file is normally not required.
#
# This is a configuration file which contains objects for the
# file-log adapter.
#
# Based on GNA - the Generic Notification Adapter framework
#
# $Id: vhm_filelog_notify.conf,v 1.1 2000/11/30 22:14:19 sv1 Exp $
#
#
# The GNA notifier object.
#
GNA_Notifier::vhm-filelog-Notifier
{
     serverName = "VHM"
# How long to wait, in seconds, before beginning to send events. 
# Default is 1 sec., to prevent a flood of notifications 
# upon adapter startup.
     initialEventDelay = 1
     ProvidesAdditionalParams = 
Filelog_AdapterParams::file_Notifier-Parameters
     {
     }
     ReadsInputFrom = GA_SubscriberFE::Filelog_Subscriber-FrontEnd
     {
          # How long an event must remain active before the adapter 
          # sends a notification, in units of seconds.
          eventSmoothingInterval = 0
          # Notification threshold; discard notifications with a 
          # certainty below this value.
          minimumCertainty = 0.01
          SubscribesTo =
          {
GA_ProfileSubscription::Filelog-Default-Profile-Subscriptions
                 {
                         profileName = "default"
                 }
          }
     }
     # No user-serviceable parts below here.
     #
  start_stopRuleSet = "filelog/filelogInit.asl"
     adapterRuleSet = "filelog/filelogNotify.asl"
       PerformsSend = FilelogAction::filelog_Interface
}
According to the following example, the File Notifier Adapter will report, to an alarm log file, when the state of any VoiceGateway or MediaServer class managed by VHM is not normal:
SubscribesTo
{
      #GA_ProfileSubscription::Filelog-Default-Profile-Subscriptions
      #{
      #         profileName = "default
      #}
      GA_ChoiceSubscription::All-Subscriptions1
      {
             className = "VoiceGateway"
          instanceName = ".*"
             eventName = ".*"
        # Include problems, but omit symptoms and aggregates.
            problems = TRUE
          aggregates = TRUE
            symptoms = TRUE
       },
      GA_ChoiceSubscription::All-Subscriptions2
      {
             className = "MediaServer"
          instanceName = ".*"
             eventName = ".*"
          # Include problems, but omit symptoms and aggregates.
              problems = TRUE
            aggregates = TRUE
              symptoms = TRUE
       }
}
File Notifier Adapter Command Line Parameters

Table 5-22 lists the File Notifier Adapter parameters that you can change.

Table 5-22 File Notifier Adapter Parameters

Parameter

Description

serverName

Default name of the VHM server to connect to. Note that this is the name of the VHM server, not the name of the host it is running on. The default is VHM.

initialEventDelay

Time interval (in seconds) the adapter should wait before accepting events from the VHM server. The default value is 1.

eventSmoothingInterval

Time (in seconds) that an event must remain in its current state before the adapter sends a notification. If the event is cleared before the event smoothing interval expires, it is not sent. The default value is 0 seconds.

minimumCertainty

Threshold above which notifications are logged. Any notification with a certainty below the threshold is discarded. Values may range from 0.0 to 1.0. The default value is 0.01.

SubscribesTo

Devices and types of notifications an adapter subscribes to. The default is all notifications and devices. Refer to the "Changing Subscriptions for Notification Adapters" section.

After you change the File Notifier Adapter file, you must stop and restart the adapter process by using the GUI to disable and then enable the adapter. See the "Configuring the File Notifier Adapter" section for instructions.

Alarm Log Example

The following is an example of the VHM alarm log file, NMSROOT/objects/smarts/logs/VHM-alarms.log:
06-Mar-2001 10:45 AM NOTIFY 
RAM::RAM-vhm-ccm3.cisco.com::InsufficientFreePhysicalMemory 100% 
Physical Memory(RAM) is insufficient. 
06-Mar-2001 03:03 AM NOTIFY 
DigitalVoiceInterface::SVI-DigitalVG-SDA00908F003434::InterfaceOperati
onallyDown 100% Digital Voice Interface is operationally down. 
06-Mar-2001 12:37 PM NOTIFY 
DigitalVoiceInterface::SVI-DigitalVG-SDA0001C9D8DD3A::InterfaceOperati
onallyDown 100% Digital Voice Interface is operationally down. 
06-Mar-2001 10:56 AM NOTIFY 
CiscoCallManager::CCM-vhm-ccm4.cisco.com/1::SyntheticEmptyCallFailed 
100% The synthetic transaction to initiate a call failed. 
05-Mar-2001 05:51 PM NOTIFY 
CiscoCallManager::CCM-vhm-ccm4.cisco.com/1::SyntheticPhonetoGatewayCal
lFailed 100% The synthetic transaction to perform a Phone to Gateway 
call failed. 
05-Mar-2001 05:51 PM NOTIFY 
CiscoCallManager::CCM-vhm-ccm4.cisco.com/1::SyntheticPhonetoBridgeCall
Failed 100% The synthetic transaction to perform a Phone to Conference 
Bridge call failed. 
05-Mar-2001 05:51 PM NOTIFY 
CiscoCallManager::CCM-vhm-ccm4.cisco.com/1::SyntheticEndtoEndCallFaile
d 100% The synthetic transaction to perform an end to end call failed. 
Configuring the Mail Notifier Adapter

The Mail Notifier adapter sends email notifications to a specified list of recipients via SMTP. The email adapter is configured to subscribe to a list of notifications and to send those notifications to a specified mailbox or group of mailboxes.

You can configure the mail notifier using the GUI or the command line. The GUI lets you do essential configuration, while the command line lets you fine-tune the adapter.

Note If you do not use the command line to fine-tune the adapter, you will receive email for all events.

For more information see the "Using the Command Line to Configure the Mail Notifier Adapter" section.

Using the GUI to Configure the Mail Notifier Adapter

To notify other users of VHM alarms:

Step 1 Click Voice Health Monitor > Fault Notification > Mail Notifier. The Mail Notifier screen appears.

Step 2 In the Adapter field, select ENABLED or DISABLED to enable or disable mail notification.

Step 3 In the Add Recipient field, enter the username for the user you want to notify about VHM events and alarms.

Step 4 If you want to remove a recipient, select the recipient from the Remove Recipient field.

Step 5 In the SenderId field, enter the email address of the sender.

Step 6 In the MailServer field, enter the fully qualified domain name of the mail server.

Step 7 Click OK.

This procedure does the following:

•Enables or disables the process and registers or unregisters the process with CiscoWorks2000.

•Updates the Mail Notifier Adapter configuration file NMSROOT\objects\smarts\vhm-conf\notifier\vhm_mail_notify.conf.

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

You do not need to restart CiscoWorks2000 for your changes to take effect. The GUI does this for you automatically.

To log all mail messages or specify the types of notifications that you want to monitor, use the command line (see the "Using the Command Line to Configure the Mail Notifier Adapter" section).

Using the Command Line to Configure the Mail Notifier Adapter

You can subscribe to event notifications for the mail notifier adapter in either of the following ways:

•Specify a list of events you want to subscibe to (see Example 1).

•Subscribe to all events and specify which events you do not want to subscribe to (see Example 2).

Before editing the configuration file, disable the adapter. See the "Configuring the Mail Notifier Adapter" section for instructions.

Example 1

This example shows the contents of the mail notifier adapter configuration file (NMSROOT\objects\smarts\vhm-conf\notifier\vhm_mail_notify.conf).

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

Table 5-23 lists the parameters that you can change using the command line.
#
# This is a configuration file which contains objects for the
# mail notification adapter.
#
# Based on GNA - the Generic Notification Adapter framework
#
# $Id: vhm_mail_notify.conf,v 1.1 2000/11/30 22:14:19 sv1 Exp $
#
#
# The GNA notifier object.
#
GNA_Notifier::vhm-mail-Notifier
{
     serverName = "VHM"
# How long to wait, in seconds, before beginning to send events. 
# Default is 1 sec., to prevent a flood of notifications 
# upon adapter startup.
     initialEventDelay = 1
# Additional parameters:  A comma-separated list of recipients (who to
# send to); the email address of the sender; and the fully qualified
# domain name of the mail server.
     ProvidesAdditionalParams = 
MailAdapterParams::mail_Notifier-Parameters
     {
#   Recipients = "username@host.domain"
#     SenderId = "daemon@localhost"
#   MailServer = "mailhost.domain"
         Recipients = ""
           SenderId = ""
         MailServer = ""
     }
     ReadsInputFrom = 
GA_SubscriberFE::mail_Notifier-Subscriber-FrontEnd
     {
# How long an event must remain active before the adapter sends a
# notification, in units of seconds.
          eventSmoothingInterval = 0
# Notification threshold; discard notifications with a certainty
# below this value.
          minimumCertainty = 0.01
          SubscribesTo =
          {
              GA_ChoiceSubscription::Mail-All-Subscriptions
              {
                     className = ".*"
                  instanceName = ".*"
                     eventName = ".*"
                      problems = TRUE
                    aggregates = TRUE
                      symptoms = TRUE
              }
         }
     }
     PerformsSend = MailAction::mail_NotifierInterface
     {
# Trace all outgoing email messages to stderr
        trace = FALSE
     }
# No user-serviceable parts below here.
#
     filterRuleSet = "mail-notify/mailFilter_Notify.asl"
     adapterRuleSet = "mail-notify/mail_Notify.asl"
}
According to the following example, the Mail Notifier Adapter will send a report when the state of any MediaServer class or VoiceCluster class managed by VHM is not normal:
SubscribesTo =
{
             
	GA_ChoiceSubscription::MediaServer-All-Subscriptions
	{
		 className = "MediaServer"
	      instanceName = ".*"
		 eventName = ".*"
		aggregates = TRUE
		  symptoms = TRUE
	},
GA_ChoiceSubscription::VoiceCluster-All-Subscriptions
	{
		 className = "VoiceCluster"
	      instanceName = ".*"
		 eventName = ".*"
		aggregates = TRUE
		  symptoms = TRUE
	}
}
Mail Notifier Adapter Command Line Parameters

Table 5-23 lists the Mail Notifier Adapter parameters that you can change.

Table 5-23 Mail Notifier Adapter Parameters

Parameter

Description

serverName

Default name of the VHM server to connect to. Note that this is the name of the VHM server, not the name of the host it is running on. The default is VHM.

initialEventDelay

Time interval (in seconds) the adapter should wait before accepting events from the VHM domain manager. The default value is 1.

Recipients

Comma-separated list of the recipients. The default is null.

SenderId

Address associated with the adapter.

MailServer

Fully qualified domain name for the mail server.

eventSmoothingInterval

Time (in units of seconds) that an event must remain active before the adapter sends a notification. If the notification is cleared before the event smoothing interval expires, the notification is not sent. The smoothing interval also controls when notifications are changed. The default value is 0 seconds.

minimumCertainty

Threshold above which notifications are sent. Any notification with a certainty below the threshold is discarded. Values may range from 0.0 to 1.0. The default value is 0.01.

SubscribesTo

Devices and types of notifications an adapter subscribes to. The default is all devices and notifications. See the "Changing Subscriptions for Notification Adapters" section.

trace

Setting for logging mail messages. The default is FALSE. If set to TRUE, log file is created in NMSROOT\objects\smarts\log\sm_mail_notifier.log.

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

After you change the Mail Notifier Adapter file, you must stop and restart the adapter process by using the GUI to disable and then enable the adapter. See the "Configuring the Mail Notifier Adapter" section for instructions.

Example 2

This example shows how to use the VHM_bootstrap.conf file to configure the mail notifier adapter.

Step 1 Backup the VHM_bootstrap.conf file (NMSROOT\objects\smarts\vhm-conf\icf\VHM_bootstrap.conf).

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

Step 2 Create a second profile in the VHM_bootstrap.conf file. Copy all the events from the GA_SubscriberProfile::PROFILE-default profile, starting at subscriptions = { and paste it into the same VHM_bootstrap.conf file under the GA_SubscriberProfile::PROFILE-mail profile.

The following shows the contents of the GA_SubscriberProfile::PROFILE-mail profile section of the VHM_bootstrap.conf file.
GA_SubscriberProfile::PROFILE-mail
{
	 subscriptions = {
{ ".*", ".*", "ApplicationException", 94275 }, # 0x17053
		{ ".*", ".*", "ApplicationMonitorException", 94275 }, # 0x17053
{ ".*", ".*", "ConnectivityException", 94275 }, # 0x17053
		{ ".*", ".*", "DPACallManagerLinkException", 94275 }, # 0x17053
		{ ".*", ".*", "DPATelephonyLinkException", 94275 }, # 0x17053
		{ ".*", ".*", "OperationalException", 94275 }, # 0x17053
		{ ".*", ".*", "PowerSupplyException", 94275 }, # 0x17053
		{ ".*", ".*", "ResourceException", 94275 }, # 0x17053
		{ ".*", ".*", "TemperatureException", 94275 }, # 0x17053
		{ ".*", ".*", "VoicePortOperationallyDown", 94275 }, # 0x17053
		{ ".*", ".*", "CardDown", 94275 }, # 0x17053
		{ ".*", ".*", "TooManyInActivePhones", 94275 }, # 0x17053
		{ ".*", ".*", "SyntheticTransactionServerDown", 94275 }, # 
0x17053
		{ ".*", ".*", "DFMServerDown", 94275 }, # 0x17053									
		{ ".*", ".*", "DiscoveryError", 94275 }, # 0x17053									
		{ ".*", ".*", "ESSConnectivityLost", 94275 }, # 0x17053									
		{ ".*", ".*", "VHMDomainConnectivityLost", 94275 }, # 0x17053											
		{ ".*", ".*", "TransactionFailed", 94275 }, # 0x17053
		{".*", ".*", "TooManyFailedSyntheticTransactions", 94275 }, # 
0x17053
		{ ".*", ".*", "ApplicationMonitoringException", 94275 }, # 
0x17053
		{ ".*", ".*", "DPAPortTelephonyLinkDown", 94275 }, # 0x17053
		{ ".*", ".*", "DPAPortCallManagerLinkDown", 94275 }, # 0x17053
		{ ".*", ".*", "CCMGateWayFailedException", 94275 }, # 0x17053
		{ ".*", ".*", "CCMMediaResourceListExhaustedException", 94275 
}, # 0x17053
		{ ".*", ".*", "CCMCallManagerFailedException", 94275 }, # 
0x17053
		{ ".*", ".*", "CCMGatewayLayer2ChangeException", 94275 }, # 
0x17053
		{ ".*", ".*", "IBMFanEventException", 94275 }, # 0x17053
		{ ".*", ".*", "IBMVoltageEventException", 94275 }, # 0x17053
		{ ".*", ".*", "IBMTemperatureEventException", 94275 }, # 
0x17053
		{ ".*", ".*", "VoiceServiceModuleStopException", 94275 }, # 
0x17053											
		{ ".*", ".*", "VoiceServiceModuleStartException", 94275 }, # 
0x17053											
		{ ".*", ".*", "VoiceServiceRunTimeFailureException", 94275 }, # 
0x17053		
		{ ".*", ".*", "VoiceServiceProcessStartException", 94275 }, # 
0x17053										
		{ ".*", ".*", "VoiceServiceProcessStopException", 94275 }, # 
0x17053										
		{ ".*", ".*", "PhoneRemoved", 94275 }, # 0x17053
		{ ".*", ".*", "ConnectivityException", 94275 }, # 0x17053
		{ ".*", ".*", "Unresponsive", 94275 }, # 0x17053
		{ ".*", ".*", "ExtensionNumberRemoved", 94275 }, # 0x17053
		{ ".*", ".*", "PhoneDiscoveryError", 94275 }, # 0x17053
		{ ".*", ".*", "MonitoredPhoneLostContactWithCluster", 94275 }, 
# 0x17053
		{ ".*", ".*", "LostContactWithCluster", 94275 }, # 0x17053
		{ ".*", ".*", "SuspectPhoneDetected", 94275 }, # 0x17053
		{ ".*", ".*", "TooManySuspectPhones", 94275 }, # 0x17053
		{ ".*", ".*", "VoiceClusterDeleted", 94275 }, # 0x17053
		{ ".*", ".*", "CCMDiscoveryFailed", 94275 }, # 0x17053									
		{ ".*", ".*", "CCMHttpServiceDown", 94275 } # 0x17053										
	}
}
Step 3 If you do not want to subscribe to all the events, in the GA_SubscriberProfile::PROFILE-mail profile section of the VHM_bootstrap.conf file, either comment out the events you do not want to subscribe to by using the pound (#) symbol, or delete the events.

Note The last active (not commented out) line must not contain a comma (,) after the last bracket (}). For example:
{ ".*", ".*", "CCMHttpServiceDown", 94275 } # 0x17053

Step 4 Backup the vhm_mail_notify.conf file. See Example 1 for an example of this file.

Step 5 Edit the vhm_mail_notify.conf file by commenting out the GA_ChoiceSubscription lines, and adding GA_ProfileSubscription::mail-New-Profile-Subscriptions and profileName = "mail".

The following shows the section of the vhm_mail_notify.conf file that is changed:
Notification threshold; discard notifications with a certainty
# below this value.
          minimumCertainty = 0.01
          SubscribesTo =
          {
             # GA_ChoiceSubscription::Mail-All-Subscriptions
             # {
             #       className = ".*"
             #    instanceName = ".*"
             #       eventName = ".*"
             #        problems = TRUE
             #      aggregates = TRUE
             #        symptoms = TRUE
             #}
               GA_ProfileSubscription::mail-New-Profile-Subscriptions
              {
                    profileName="mail"
               }
     }
     PerformsSend = MailAction::mail_NotifierInterface
     {
# Trace all outgoing email messages to stderr
        trace = FALSE
     }
Step 6 Open a DOS command prompt on the VHM system.

Step 7 To show currently running profiles, enter the command
C:\PROGRA~1\CSCOpx\objects\smarts\bin>sm_profile -s VHM show.
Verify that the profiles are correct.

Step 8 To remove a profile, enter the command
C:\PROGRA~1\CSCOpx\objects\smarts\bin>sm_profile -s VHM delete 
default.
Note Enter this command for all profiles you want removed.

Step 9 To import the mail profile from the VHM_bootstrap.conf file, enter the command
C:\PROGRA~1\CSCOpx\objects\smarts\bin>sm_adapter -s 
VHM--file=C:\Progra~1\CSCOpx\objects\smarts\vhm-conf\icf\VHM_bootstrap
.conf import.asl.
Step 10 To show the modified list of currently running profiles, enter the command
C:\PROGRA~1\CSCOpx\objects\smarts\bin>sm_profile -s VHM show.
Verify that the default and mail profiles appear in the list.

Note Make sure to enable the Mail Notifier process after making these changes, either manually or through the VHM Mail Notifier window. See the "Configuring the Mail Notifier Adapter" section for instructions.

Configuring the Trap Notifier Adapter

You can use either the GUI or command line to configure the Trap Notifier Adapter. The GUI lets you do essential configuration, while the command line lets you fine-tune the adapter. For more information, see the "Using the Command Line to Configure Adapters" section.

Using the GUI to Configure the Trap Notifier Adapter

The Trap Notifier adapter converts all VHM notifications into SNMP trap messages. The Trap Notifier sends the trap messages to specific recipients on the network.

To notify other hosts of VHM events and alarms:

Step 1 Click Voice Health Monitor > Fault Notification > Trap Notifier. The Trap Notifier window appears.

Step 2 In the Adapter field, select ENABLED or DISABLED to enable or disable trap notification.

Step 3 In the Add Recipient field, enter the hostname and port number of the system you want to notify about VHM events and alarms.

Step 4 If you want to remove a recipient, select the recipient from the Remove Recipient field.

Step 5 Click OK.

This procedure does the following:

•Enables or disables the process and registers or unregisters the process with CiscoWorks2000.

•Updates the Trap Notifier Adapter configuration file NMSROOT\objects\smarts\vhm-conf\notifier\vhm_trap_notify.conf.

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

You do not need to restart CiscoWorks2000 for your changes to take effect. The GUI does this for you automatically.

To save information about all handled traps in a log file, or specify the type of notifications that you want to listen for, use the command line (see the "Using the Command Line to Configure the Trap Notifier Adapter" section).

Using the Command Line to Configure the Trap Notifier Adapter

This topic shows the contents of the Trap Notifier Adapter file (NMSROOT\objects\smarts\vhm-conf\notifier\vhm_trap_notify.conf).

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

Table 5-24 lists the parameters that you can change using the command line.

Note To create a log file for every trap handled by the adapter, set dumpTrap to TRUE. A log file is created in NMSROOT/objects/smarts/log/sm_trap_notifier.log.
#
# This is a configuration file which contains objects for the
# trap notification adapter.
#
# Based on GNA - the Generic Notification Adapter framework
#
# $Id: vhm_trap_notify.conf,v 1.1 2000/11/30 22:14:19 sv1 Exp $
#
#
# The GNA notifier object.
#
GNA_Notifier::vhm-trap-Notifier
{
     serverName = "VHM"
# How long to wait, in seconds, before beginning to send events. 
# Default is 1 sec., to prevent a flood of notifications 
# upon adapter startup.
     initialEventDelay = 1
# Additional parameters: a list of hosts (specified by host name,
# UDP ports and SNMP version ) to which the traps are sent.
# To add more hosts to the list, follow this format
# { {"host_name1", port_num1, "1"},
#   {"host_name2", port_num2, "2"} }
# Version number can only be 1 or 2. Currently only 1 is supported
     ProvidesAdditionalParams = 
Trap_AdapterParams::trap_Notifier-Parameters
     {
	recipients = { }
     }
     ReadsInputFrom = GA_SubscriberFE::trap_Subscriber-FrontEnd
     {
# How long an event must remain active before the adapter sends a
# notification, in units of seconds.
          eventSmoothingInterval = 0
# Notification threshold; discard notifications with a certainty
# below this value.
          minimumCertainty = 0.01
          SubscribesTo =
          {
                GA_ChoiceSubscription::Trap-All-Subscriptions
                {
# Subscribe to events whose class, instance, and event
# names match the givent pattern.
                       className = ".*"
                    instanceName = ".*"
                       eventName = ".*"
# Include problems, but omit symptoms and aggregates.
                        problems = TRUE
                      aggregates = TRUE
                        symptoms = TRUE
                 }
          }
     }
# No user-serviceable parts below here.
#
      filterRuleSet = "trap-notify/trapFilterNotify.asl"
     adapterRuleSet = "trap-notify/trapNotify.asl"
       PerformsSend = Trap_NotifierAction::trap_NotifierInterface {
                dumpTrap = FALSE
        }
}
According to the following example, the Trap Notifier Adapter will send a trap when the state of any MediaServer class or VoiceCluster class managed by VHM is not normal:
SubscribesTo =
{
             
	GA_ChoiceSubscription::MediaServer-All-Subscriptions
	{
		 className = "MediaServer"
	      instanceName = ".*"
		 eventName = ".*"
		aggregates = TRUE
		  symptoms = TRUE
	},
GA_ChoiceSubscription::VoiceCluster-All-Subscriptions
	{
		 className = "VoiceCluster"
	      instanceName = ".*"
		 eventName = ".*"
		aggregates = TRUE
		  symptoms = TRUE
	}
}
Trap Notifier Adapter Command Line Parameters

Table 5-24 lists the Trap Notifier Adapter parameters that you can change.

Table 5-24 Trap Notifier Adapter Parameters

Parameter

Description

serverName

Default name of the server to connect to. Note that this is the name of the VHM server, not the name of the host it is running on. The default is VHM.

initialEventDelay

Time interval (in seconds) the adapter should wait before accepting events from the VHM. The default value is 1.

recipients

Table of addresses to send the SNMP traps to. Each row consists of three different values: host or IP address, socket number, and SNMP version (usually equal to 1). The values are separated by commas and enclosed in curly braces. In turn, the rows are also separated by commas and enclosed in curly braces. The default is null.

eventSmoothingInterval

Time (in seconds) that an event must remain in its current state before the adapter sends a notification. If the event is cleared before the event smoothing interval expires, it is not sent. The default value is 0 seconds.

minimumCertainty

Threshold above which events are logged. Any notification with a certainty below the threshold is discarded. Values may range from 0.0 to 1.0. The default value is 0.01.

dumpTrap

If set to TRUE, causes information to be sent to the log file for every trap handled by the adapter. The default value is FALSE. If set to TRUE, log file is created in NMSROOT\objects\smarts\log\sm_trap_notifier.log.

SubscribesTo

Devices and types of notifications an adapter subscribes to. The default is all notifications and devices. See the "Changing Subscriptions for Notification Adapters" section.

After you change the Trap Notifier Adapter file, you must stop and restart the adapter process by using the GUI to disable and then enable the adapter. See the "Using the GUI to Configure the Trap Notifier Adapter" section for instructions.

Examples

These examples show how to configure the Trap Notifier Adapter so that VHM trap messages can be forwarded to a number of recipients (such as network management systems).

This code fragment shows you the format you should use:
# Additional parameters:a list of hosts (specified by host name,
# UDP ports and SNMP version ) to which the traps are sent.
# To add more hosts to the list, follow this format
# { {"host_name1", port_num1, "1"},
#   {"host_name2", port_num2, "2"} }
# Version number can only be 1 or 2. Currently only 1 is supported
ProvidesAdditionalParams = 
Trap_AdapterParams::trap_Notifier-Parameters
{
recipients = { }
}
This example forwards trap messages to the recipient host_name1:
#For case of one recipient: 
       	ProvidesAdditionalParams = 
Trap_AdapterParams::trap_Notifier-Parameters
       	 {
             		 recipients = {{"host_name1", 162, "1"}}
       	 }
This example forwards VHM trap messages to the recipients host_name1 and host_name2:
#For case of two recipients:
         		ProvidesAdditionalParams = 
   	Trap_AdapterParams::trap_Notifier-Parameters
   	{
   	recipients = {{"host_name1", 162, "1"},
   	{"host_name2", port_num, "1"} }
   	}
This example forwards VHM trap messages to the recipients host_name1, host_name2, and host_name3:
#For case of  three recipients:
         		ProvidesAdditionalParams = 
   	Trap_AdapterParams::trap_Notifier-Parameters
  	 {
	   recipients = {{"host_name1", 162, "1"},
               			{"host_name2", port_num2, "1"},
			               {"host_name3", port_num3, "1"} }
	}
Configuring ICS 7750 for Use with VHM

If you have an ICS 7750, you must enable minimal trace for each SPE Cisco CallManager following the procedure in this topic. If trace is not enabled, VHM cannot obtain adequate information from the ccm Table in the CCM-MIB to monitor the health of the Cisco CallManager.

To enable minimal trace on ICS 7750 SPE's Call Manager:

Step 1 From the Cisco CallManager Administration pages in the Trace Configuration window:

a. Select the Trace On check box to enable trace.

b. Configure SDI Trace settings with the following values.

Setting

Recommended Value

User Mask

11

Level

ERROR

Event

INFORMATION

Step 2 From the Cisco CallManager Administration pages, enable SNMP in the Service Parameter window (EnableSNMP).

Step 3 Restart the SPE through System Manager:

a. From a command prompt, start the System Manager.

For example:
\\<ip_address>\icsconfig
b. Click the shutdown/restart link.

c. Click the restart button for the SPE.

Configuring Cisco CallManager for Use with VHM

For VHM to manage a Cisco CallManager running on an Media Convergence Server (MCS), minimal trace must be enabled, and the username and password of the Cisco CallManager must be stored on the VHM system (for Cisco CallManager 3.1 or later).

Note Minimal trace should be enabled by default in all Cisco CallManagers running on an MCS.

For detailed instructions, see the following topics:

•Enabling Minimal Trace on Cisco CallManager

•Storing the Cisco CallManager Username and Password in VHM

Enabling Minimal Trace on Cisco CallManager

If trace is not enabled, VHM cannot obtain adequate information from ccmTable in the CCM-MIB to monitor the health of the Cisco CallManager.

To enable minimal trace on Cisco CallManager:

Step 1 Log into Cisco CallManager:

a. On your web browser's address line, enter the IP address or valid hostname of the Cisco CallManager Administration page.

For example, enter:
http://ipaddressofccm/ccmadmin.
b. Enter your username and password in the dialog box.

The Cisco CallManager Administration window opens.

Step 2 Select Service from the menu bar.

Step 3 Select Trace from the drop-down menu.

The Trace Configuration page opens.

Step 4 From the Cisco CallManager list on the left side of the page, click the IP address of the Cisco CallManager you are configuring.

The Configured Services dialog box opens.

Step 5 Select Cisco CallManager from the list.

The CallManager trace settings appear.

Step 6 Set the trace settings:

a. Verify that the Trace On check box is selected.

b. Set Level to ERROR.

c. Set User Mask to 11.

d. Set Event to INFORMATION.

Step 7 Select Service from the menu bar.

Step 8 Select Service Parameters from the drop-down menu.

The Service Parameters Configuration page opens, listing the Cisco CallManagers on the left side.

Step 9 Click the IP address of the Cisco CallManager you are configuring.

The Configured Services box opens.

Step 10 Select Cisco CallManager from the list.

A window appear `s, displaying the Configured Service Parameters selection box.

Step 11 Scroll down the list and select EnableSnmp.

Step 12 Verify that the value is set to T.

Step 13 Click Update.

The snmp service on your Cisco CallManager is updated.

Storing the Cisco CallManager Username and Password in VHM

For VHM to manage a Cisco CallManager (version 3.1 or later), you need to store the username and password of the Cisco CallManager on the VHM system. The username and password stored must have administrative privileges on the Cisco CallManager to enable VHM to do the following:

•Collect information on phones that are trying to register to a Cisco CallManager but are unable to (referred to as suspect phones)

•Monitor the number of active phones

•Collect connectivity information for Monitored Phones, Voice Gateway, Gatekeeper, and CallManager clusters

For VHM to monitor the registration of a gateway, gatekeeper, or digital voice gateway connected to a Cisco CallManager, the StoreNamePassCommunity command must be run.

If the StoreNamePassCommunity command is not run (or incorrect credentials are used), the CallManager cannot access the CallManager HTTP service. If this occurs for all CallManagers in a cluster, the CCMHttpServiceDown event appears in the Monitoring Console. Also, you will not be able to import any IP phones, and all existing IP phones will be moved to Undiscovered. This situation will remain until one of the CallManagers in the cluster can access the CallManager HTTP service.

If monitored phones are configured in VHM, and the StoreNamePassCommunity command is not run (or incorrect credentials are used), the monitored phones will become undiscovered.

As soon as the StoreNamePassCommunity command is run successfully, all associated Media Servers and ICS 7750s will be rediscovered.

VHM stores the username and password in a text file in encoded format.

To store the Cisco CallManager username and password on the VHM system:

Step 1 On the VHM system, open a DOS command prompt.

Step 2 Add NMSROOT\objects\vhm\bin to the PATH environment variable.

For example, enter:
set PATH=%PATH%;e:\progra~1\cscopx\objects\vhm\bin
Step 3 Enter the StoreNamePassCommunity command followed by these parameters: <-w Community String> <Username> <Password> <IP Address of Media Server>.

Parameter

Description

-w Community String

Write community string for the SNMP Agent on the Cisco CallManager.

Note This parameter is required only if you want to enable the suspect phones feature.

Username

Username of Cisco CallManager.

Password

Password for the username.

Community String

Write community string for the SNMP Agent on the Cisco CallManager.

IP Address of Media

List of Media Servers separated by a comma (,) or the word all (for all Media Servers).

For example, enter:
d:\> StoreNamePassCommunity -w admin admin admin 172.20.121.2
or:
d:\> StoreNamePassCommunity admin admin all
Caution Running the StoreNamePassCommunity command with the argument all overwrites the passwords stored for all Cisco CallManagers.

Note Only the username and the password are stored; the community string is not stored. The write community string is necessary for detecting suspect phones and enabling traps.

Step 4 Press Enter.

The encoded username and password are stored in the ccm.props file. The file is located in NMSROOT\objects\vhm.

Note NMSROOT is the directory where CiscoWorks2000 is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.

Deleting a Stored Cisco CallManager Username and Password from VHM

If you need to delete a stored Cisco CallManager username and password from VHM, you must run the StoreNamePassCommunity command.

To delete a stored Cisco CallManager username and password:

Step 1 On the VHM system, open a DOS command prompt.

Step 2 Enter the StoreNamePassCommunity command followed by these parameters: -d <IP Address of Media Server>.

For example, enter:
d:\> StoreNamePassCommunity -d 172.20.121.34
The username and password for the Media Server are deleted from VHM.