Avaya Integrated Management R3.0 Field Support Tools, Tips, and Tricks …support.avaya.com › elmodocs2 › intmgmt › 14_600823_1.pdf · 2005-12-15 · Important: VNC sessions

Avaya Integrated Management Release 3.0 Field Support Tools, Tips, and Tricks for the Linux Server

14-600823Issue 1

December 2005

Table of Contents

Introduction................................................................................................ 5

Acronyms and abbreviations.................................................................... 5

Integrated Management supported platforms......................................... 7

Troubleshooting with and without remote access ................................. 7

Remote dial-up access to Linux servers....................................... 7

VNC remote desktop access.......................................................... 8

Using a TAR file to troubleshoot without remote access.......... 11

Other remote troubleshooting tools for Windows-based PCs.. 13

Troubleshooting the Integrated Management installation ................... 15

Installation logs............................................................................. 16

Installation tools............................................................................ 17

Suite-level tools............................................................................. 18

Integrated Management Database.......................................................... 19

IMD database schema................................................................... 20

IMD tools....................................................................................... 21

MultiSite Administration.......................................................................... 23

MSA software process management........................................... 23

MSA configuration settings file – bob.ini ................................ 25

MSA voice system configuration settings file – switch.ini... 26

MSA syslog event and debug logging ........................................ 27

2 Avaya IM Release 3.0 Field Support Tools, Tips, and Tricks for the Linux Server

MSA database tools.......................................................................28

Fault and Performance Manager.............................................................30

Third-party software packages.....................................................30

FPM load balancing and multiple collection servers..................30

FPM environment variables and tunable parameters.................31

FPM software process management............................................34

Database query tools ....................................................................43

Database modification tools.........................................................48

FPM data collector tools ...............................................................49

Native Configuration Manager ................................................................53

Proxy Agent ..............................................................................................54

Alarm trap testing..........................................................................54

Monitoring traps that are sent from the Proxy Agent.................56

Communication Manager Sub Agent......................................................56

Common problems with CMSA implementations.......................56

Watchdog status of CMSA............................................................57

Stopping, starting, and restarting the MVSubAgent...................58

NMSI Master Server..................................................................................59

HP OpenView - System View...................................................................59

Checking FPM objects in the HP OpenView database ...............59

Validating SNMP access to data on a proxy................................60

Issue 1 December 2005 3

HP OpenView IP Telephony Smart Plug In ................................. 62

Appendix A, Time zone conversion table .............................................. 63


Introduction This document describes the tools that are available to Avaya technical support representatives for remote and on-site support of the Integrated Management (IM) Linux Server 3.0. These tools include:

• MultiSite Administration (MSA)

• Fault and Performance Manager (FPM)

• Proxy Agent (PA)

• Network Management System Integration (NMSI) Components for Solaris, Windows 2000, and Windows 2003.

• IM Linux Server Maintenance Package (MVMAINT)

• Network Management System Integration Master Server (NMSI-SERVER)

• Native Configuration Manager (NCM)

The following documents define the network protocols, ports, directions, and so on for all applications within Integrated Management. These documents can help you to identify what ports and protocols must be allowed to pass through the routers and firewalls of the customer network to be able to use the various applications within Integrated Management.

• Avaya Integrated Management Application Notes: IM R3.0 Linux Installation Properties

• Avaya Integrated Management Application Notes: IM R3.0 Windows Installation Properties

These documents are available at the Avaya Support Web site http://support.avaya.com.

Acronyms and abbreviations This document uses the following acronyms and abbreviations.

Abbreviation Meaning

ARS Automatic Route Selection

CLAN Controlled local area network

CMS Call Management System

CSV Comma-separated value

DCS Distributed Communications System

DNM DEFINITY Network Management

DNS Domain name server

DSP Digital signal processing

ES Enterprise Server

FPM Fault and Performance Manager

FQDN Fully qualified domain name

IM Integrated Management

IMD Integrated Management database


http://support.avaya.com/japple/css/japple?PAGE=ProductArea&temp.productID=233296&temp.releaseID=233297&temp.bucketID=135826




http://support.avaya.com/

Abbreviation Meaning

IP Internet Protocol

IVR Avaya Interactive Voice Response

JAR Java archive

JDBC Java Database Connectivity

JVM Java virtual machine

MCM MultiVantage Configuration Manager

MCU Multi Conferencing Units

MFPM MultiVantage Fault and Performance Manager

MIB Management information database

MSA MultiSite Administration

NCM Native Configuration Manager

NMSI Network Management Systems Integration

NNM OpenView Network Node Manager

NMS Network Management System

OS Operating system

OSSI Operations Support System Interface

PA Proxy Agent

PID Process ID

PHP Hypertext preprocessor

PPP Point-to-Pont Protocol

RAS Remote access services

RPM RedHat Package Manager

SAT System access terminal

SQL Structured Query language

SNMP Simple Network Management Protocol

SSG Secure services gateway

SSH Secure Shell

SSL Secure Sockets Layer

TAR Tape archive

TCP Transmission Control Protocol

UDP Uniform Dial Plan

UI User interface

VNC Virtual Network Computing

VPN Virtual private network

.


Integrated Management supported platforms Integrated Management provides a suite of applications that run on Windows, RedHat Enterprise Linux, and Solaris platforms. For the hardware platform requirements, see Integrated Management 3.0 Overview (14-300615), which is available at the Avaya Support Web site http://support.avaya.com.

Note: Avaya Services supports only those Integrated Management applications that the Service and Support Plan specifies.

Troubleshooting with and without remote access Avaya provides two ways to troubleshoot with remote access:

• Dial-up access to Linux servers

• Virtual Network Computing (VNC) software

Where no remote access is possible, the customer can create a TAR file and send that file to Avaya to troubleshoot. This section describes each of those methods in detail.

Remote dial-up access to Linux servers By default, when the Integrated Management Linux server software is installed, the MVMAINT package, which in RPM is called mvmaint-server, is installed first. The MVMAINT package performs the following functions, regardless of which Integrated Management applications are installed on the Linux server:

1. Verifies the network configuration, such as static IP, functioning DNS, and so on.

2. Sets up COM1 for dial-up remote access by way of a modem at 33.6 kbps.

3. Adds the ncsc and the root2 logins.

4. Configures the system for Point-to-Point Protocol (PPP) dial-up networking access by way of the ncsc login.

5. Installs and starts the MVMAINT audit, which cleans up log files, and so on.

6. Installs status download capabilities by way of http://<IP Address of Linux Server>/status.html.

7. Installs the VNC server setup scripts to allow for remote Linux desktop access to the system.

Dial-up modem settings The suggested modem for remote dial-up access is an external US Robotics Sportster 56-K fax modem. To initialize the modem from the factory defaults and set up the modem for Smart access (AT Command set) and to display verbal result codes, set the DIP switches as follows:

• Switches 3, 5, and 8 down

• Switches 1, 2, 4, 6, and 7 up

Enabling and disabling remote dial-up access Some customers who are concerned about the security of the Linux server do not allow extra logins or dial-up modems to be connected to the server. A new tool is available to enable and disable dial-up access and services logins for those


http://support.avaya.com/

customers. If the MVMAINT 3.0-26 or later RPM is installed, you can use the “ims-support” tool to enable and disable the remote access to the system.

Usage:

/opt/avaya/mvmaint/bin/ims-support [status |off |on]

where:

status displays the current remote maintenance status, which is either enabled or disabled.

off disables the dial-up modem getty on ttyS0 and disables the ncsc and the root2 logins.

on enables the dial-up modem getty on ttyS0 and enables the ncsc and the root2 logins.

VNC remote desktop access Virtual Network Computing (VNC) is a freeware package that is incorporated into Linux as the standard for remote desktop access. Avaya recommends that you use the TightVNC Software package. TightVNC does a better job of compression and so on when you display graphical applications over dial-up connections. To download the VNC software, see:

• www.tightvnc.com to download both Windows and Linux client and server packages without charge

• http://<IP Address of Linux Server>/mvmaint/tightvnc.exe to download the Windows TightVNC client/server self-extracting executable file from any IM Linux server (by way of the mvmaint package)

• http://<IP Address of Linux Server>/mvmaint/tightvnc.rpm to download the Linux TightVNC client/server RPM to the local IM Linux server of the customer

Configuring and starting the VNC server To configure and start the VNC server, use a valid Linux login on the system, as shown below. Run /usr/ncsc/bin/configVNC to configure the VNC server instance. Enter the {login} password twice below:

Password: xxxxxxxx

Verify: xxxxxxx

Killing VNC Server display {login}VNC

Starting VNC Server for {login}

xauth: creating new authority file $HOME/.Xauthority

New '{login}VNC' desktop is nodename:2

Starting applications specified in $HOME/.vnc/xstartup

Log file is $HOME/.vnc/nodename:2.log

Configuration and Startup of VNC Successful


http://www.tightvnc.com/

Displaying the VNC desktop To display the VNC desktop:

1. You must first install a VNC client on your Windows-based PC. To download the Tight VNC Windows server/client, see www.tightvnc.com.

2. After you install the VNC client, select Start > Programs >Tight VNC >Tight VNC Viewer to start the viewer (Figure 1).

Figure 1 – The VNC Connection details window

If the VNC server is configured properly on the Linux server, and the VNC server service is running, the system prompts you for the password (Figure 2).

Figure 2 – The VNC Authentication window

3. Enter the password.

If the password is correct, the system displays the Linux Gnome desktop (Figure 3).


http://www.tightvnc.com/

Figure 3 – A Linux Gnome desktop session by way of VNC

4. If the system does not display the Linux Gnome desktop:

a. Go to the $HOME directory of the login (/usr/ncsc). Remove the passwd file from the /usr/ncsc/.vnc directory.

b. Use the vi editor to open the xstartup file.

c. Change the existing command to gnome-session&.

d. Start and stop the VNC server. To do so, you must reconfigure VNC access through the ncsc login menu. For the procedure, see “Configuring and starting the VNC server.”

Note: If you ever need to use the root login instead of the ncsc login to start a VNC server, you can run the vncserver command to start a VNC server for that login.

e. When you finish troubleshooting, stop the VNC session. To do so, run vncserver –kill nodename:X where X is the display that the VNC started running on.

Important: VNC sessions use processor power. Do not leave a VNC session running if you are not actively debugging or troubleshooting.


Using a TAR file to troubleshoot without remote access Note: Avaya support of troubleshooting without remote access is a billable expense to the customer regardless of contractual maintenance agreements. The Service and Support Plan documents this billable expense.

Some customers do not allow Avaya to access the Linux server on their network or provide Avaya a RAS/VPN account on their LAN. In these cases, the customer can still get troubleshooting help by creating a compressed TAR archive file. You can create a TAR file from a status html page on the VMS server or manually from the Linux command line. The customer then sends this file by way of e-mail to an Avaya technical support representative for troubleshooting.

Important: Using a TAR file is the least acceptable method of troubleshooting. The results are often slow and unreliable.

Using IM to create the TAR file To create a TAR file with IM:

1. Go to http://<IP Address of Linux server>/status.html. The system displays the Avaya Integrated Management Server Status screen (Figure 4).

Figure 4 – The Avaya Integrated Management Server Status screen

2. Read the instructions on the screen and click the name of the product for which you want to generate a status file.

The system starts to collect the data and archive the data into a TAR file. Note that this process can require several minutes, and no status bar or progress meter is present to show the status. Once the file is created, the system displays a screen that describes where to download the resulting file (Figure 5).


Figure 5 – The Avaya Integrated Management Server Status Download screen

3. Right-click the product link and select Save Target As or Save As to save the file to the desired location.

Use any desktop e-mail client to attach the zipped file to an e-mail message and send the file to Avaya for investigation.

Creating the TAR file manually You can use any of the following tools to create the TAR file manually from the Linux command line:

FPM: /opt/avaya/mvmaint/bin/MFPMstatusrep filename

PA: /opt/avaya/mvmaint/bin/MPAstatusrep filename

MSA: /opt/avaya/msa/bin/mcmdebug [-s switchname|-a ]

For MSA, the file name is fixed to /opt/avaya/msa/timestamp_mcmdebug.tgz. Use the –s option to specify a single switch to include. Use the –a option to include all switch data. If you do not specify an option, no switch-specific data is included. The TAR file includes only MSA system-related files and databases.

Once you create the file, use any desktop e-mail client to attach the file to an e-mail message and send to Avaya for investigation.

Opening the TAR file Note: You must use WinZip 7 or later to open the file.

1. Click the WinZip icon.

The system displays a dialog box that asks you if you want to decompress the archive and open the file (Figure 6).


Figure 6 – A WinZip dialog box

2. Click Yes in the dialog box to open the compressed file archive.

The system displays a window that shows the individual files that the archive contains (Figure 7). The archived file contains different files for each application.

Figure 7 – A WinZip decompressed archive

3. Navigate to the directory in which you want to save the files and click Extract.

WinZip extracts the files from the archive and places the files in the directory that you select.

Other remote troubleshooting tools for Windows-based PCs This section describes the following additional tools that you can use on a Windows-based PC to connect to and troubleshoot problems on an IM server:

• PuTTY

• PSCP

PuTTY PuTTY is a simple Windows-based Telnet or secure shell (SSH) application that you or the customer can use to get a terminal window login to a Linux server.

To use PuTTY:

1. Download the putty.exe file from the external Web site http://www.chiark.greenend.org.uk/~sgtatham/putty/. Place the file on your desktop for easy access.

2. Click the icon to display the PuTTY Configuration screen (Figure 8).


http://www.chiark.greenend.org.uk/%7Esgtatham/putty/

Figure 8 – The PuTTY configuration screen

3. Type the host name or the IP address of the server and the port to which to connect. Click Open.

The system displays a terminal emulation window and connects you to the remote server.

PSCP PSCP is a secure (SSL) MS-DOS-based copy application that you or the customer can use to copy files between your Windows-based PC and a Linux server.

To use PSCP:

1. Download the pscp.exe file from the external Web site http://www.chiark.greenend.org.uk/~sgtatham/putty/.

2. From the command line within an MS-DOS window, enter the appropriate command.

If you type only the command name pscp, you see the usage as shown in the top two-thirds of the screen in Figure 9. The bottom of this the screen shows an example of a command that uses the ncsc login to copy the file c:\freemem to a Linux server and place the file in the /usr/ncsc directory. The screen indicates progress as the system transfers the file. To copy the file in this example from the Linux server back to the PC, you reverse the order of the operands. In other words, use the command pscp [email protected]:/usr/ncsc/freemem c:\freemem).


http://www.chiark.greenend.org.uk/%7Esgtatham/putty/

Figure 9 – An MS-DOS screen with examples of PSCP commands

Troubleshooting the Integrated Management installation InstallShield 10 is used to package and install the Avaya IM Linux applications. This section describes some tools and troubleshooting techniques that can help you detect and resolve problems that are related to the actual software installation. During this installation, the “master installer” performs the following functions:

• Puts backup-and-restore functionality in place

• Handles prerequisite checks of the operating system

• Installs required third-party RPMs such as Apache, PostgreSQL, PHP, and so on

• Installs the IM Linux maintenance package RPM mvmaint-server and the following application RPMs:

- mfpm-server

- msa-server, mpa-server

- avaya-imd

- nmsi-master-server

- ncm

After the installation, the master installer performs the following functions:

• Starts the postinstallation configuration scripts

• Once again puts backup-and-restore functionality in place

InstallShield creates a properties file in the home directory (root) of the installing user. This file, the /root/vpd.properties file, contains information that relates to what the master installer installed. If a discrepancy exists between what the master installer


detects is installed and what you know is installed, you must edit this file and delete the line that is associated with the missing application.

Installation logs The base directory for the installation log file is /var/avaya/install. This directory contains several logs and subdirectories for subproduct installation logs.

Master installer tracing log - /var/avaya/install/IM3.0_install.log This log contains standard output and error messages and some debug tracing information that is related to the actions of the master installer. Each execution of the master installer is appended to this log file. The start of the installation run is delimited by a header with the date. The date is followed by the message Environment Set. This log shows what RPMs are being removed and installed. In some cases, this log also explains why the master installer did or did not take certain actions.

FPM install logs - /var/avaya/install/MFPM This directory contains log files that are associated with the FPM installation and remove operations.

mfpminstall.log – Contains the output of the “mfpmconfig install” execution that was run by the FPM RPM installer. Shows status messages and error messages that relate to the initial FPM RPM installation.

mfpmconfig.log – Contains the output from the execution of the mfpmconfig script. Includes prompts, user responses, and various status messages and error messages that relate to mfpmconfig running.

showconfig.log – Contains the output of the showconfig execution that was run after the installation and mfpmconfig finished running. This log is a kind of “final checkpoint” after the FPM services were restarted.

mfpm-rpm.log – Contains the results of the user and group creation by the FPM RPM installer.

NMSI install logs - /var/avaya/install/NMSI This directory contains log files that are related to the NMSI master server installation and remove operations.

nmsiconfig.log – Contains the output from the execution of the /opt/avaya/nmsi/bin/nmsiconfig script. Includes prompts, user responses, and various status messages and error messages that relate to nmsiconfig running.

IMD install logs - /var/avaya/imd/logs This directory contains log files that are associated with the IMD installation and remove operations.

• imdcreatelog – Contains the output from the execution of the /opt/avaya/imd/bin/IMDCreate script. Includes various status messages and error messages that are related to IMDCreate running, including SQL errors. In this file, you might see errors that relate to objects that could not be created in the database because the objects already exist in the database. These errors are acceptable. Duplicate key messages are also acceptable because we are trying to create records with indexes that already exist. Usually, the errors that occur most frequently are those errors in the first 10 or 20 lines of this file that relate to the inability to connect to the PostgreSQL database server.


Installation tools Tools to troubleshoot the IM installation include the IM Linux RPM inventory command vmsrpms.

IM Linux RPM inventory command - vmsrpms This command shows a list of all:

• Avaya Integrated Management RPMs that are installed

• Related or third-party RPMs that are required or that the master installer installed during the installation.

The following output represents an execution of this command for IM R3.0 on a RedHat Enterprise Linux 3.0 ES server:

# vmsrpms

Finding the versions of Integrated Management 3.0-16 products ...

avaya-imd-3.0-86

mcm-server-3.0-171

mfpm-server-3.0-240

mpa-server-3.0-10

mvmaint-server-3.0-24

ncm-3.0-76

nmsi-master-server-3.0-240

Finding the versions of Integrated Management 3.0-16 supporting components ...

avaya-imd-3.0-86

avaya-web_page-3.0-16

cyrus-sasl-2.1.15-10

cyrus-sasl-gssapi-2.1.15-10

cyrus-sasl-md5-2.1.15-10

cyrus-sasl-plain-2.1.15-10

httpd-2.0.46-44.ent

j2sdk-1.4.2_06-fcs

j2sdk-1.4.2-fcs

mgetty-1.1.30-3

openldap-2.0.27-17

openldap-clients-2.0.27-17

openldap-servers-2.0.27-17

openssl096b-0.9.6b-16

openssl-0.9.7a-33.12

php-4.3.2-14.ent

php-pgsql-4.3.2-14.ent

postgresql-7.4.6-2PGDG

postgresql-contrib-7.4.6-2PGDG

postgresql-devel-7.4.6-2PGDG

postgresql-docs-7.4.6-2PGDG

postgresql-jdbc-7.4.6-2PGDG

postgresql-libs-7.4.6-2PGDG

postgresql-pl-7.4.6-2PGDG

postgresql-server-7.4.6-2PGDG

uucp-1.06.1-47

vnc-server-4.0-0.beta4.1.4


Suite-level tools The following suite-level tools are available to help you troubleshoot the IM installation:

• Suite-level backup - IMbackup

• Suite-level restore - IMrestore

• Suite-level backup and restore with FTP - IMftp.sh

Suite-level backup - IMbackup Use this command to back up one or more of the IM Linux applications.

Caution: This command affects service. The IM Linux Server processes are stopped before the backup starts and restarted when the backup is complete.

Usage: /usr/sbin/IMbackup backup_file [all|app1 [app2]..[appx]]

where app# is FPM, MSA, IMD, or PA.

The backup_file is created, or if a block device (a tape backup device is specified as the backup file) is entered, the output is written straight to the block device or file. Each application that is specified on the command line is backed up and included in the resulting backup compressed TAR file (tgz). For instance, to back up only IMD and FPM to a backup file at /home/dvac/imbk_051105.tgz, enter: # /usr/sbin/IMbackup /home/dvac/imbk_051105.tgz IMD FPM

Or, to back up all installed IM applications on this IM Linux server, enter: # /usr/sbin/IMbackup /home/dvac/imbk_051105.tgz all

Suite-level restore - IMrestore Use this command to restore one or more of the IM Linux applications from a backup file that was previously made with the IMbackup tool.

Caution: This command affects service. The IM Linux server processes are stopped before the backup starts and restarted when the backup is complete.

Usage: /usr/sbin/IMrestore backup_file [all|app1 [app2]..[appx]]

where app# is FPM, MSA, IMD, or PA.

The backup_file file or the block device is read, and each application that is specified on the command line is restored from the backup compressed TAR file (tgz). For instance, to restore only IMD and FPM from a backup file at /home/dvac/imbk_051105.tgz, enter: # /usr/sbin/IMrestore /home/dvac/imbk_051105.tgz IMD FPM

Or, to restore all installed IM applications on this IM Linux server from files within the specified tgz file, enter: # /usr/sbin/IMbackup /home/dvac/imbk_051105.tgz all

If the tgz file does not contain an installed application backup file, this command does not restore anything. Conversely, if a tgz file contains a backup for an application for which a restore was not requested on the command line, the application is not restored.


Suite-level backup and restore with FTP - IMftp.sh Use this command to back up one or more of the IM Linux applications.

Usage: /usr/sbin/IMftp.sh [ip] [userid] [password] [remote folder] [get|put]

[filename]

Depending upon the get/put parameter, the filename is either sent to or received from an FTP server. You can use this tool in conjunction with the IMbackup and IMrestore commands to FTP a backup file to a secondary storage FTP server, and then bring the file back for a restore operation. You can create simple shell scripts to create a CRON job to schedule periodic backup of an IM Linux server. For example, if you made the backup file in the above section, you can use IMftp.sh to offload the file with the following command: # /usr/sbin/IMftp.sh 135.9.1.2 dvac PassWoRd

/pub/backups/IMLinuxServer put /home/dvac/imbk_051105.tgz

You can then bring the file back for a restore operation with the following command: # /usr/sbin/IMftp.sh 135.9.1.2 dvac PassWoRd

/pub/backups/IMLinuxServer get /home/dvac/imbk_051105.tgz

You can also create a basic automated backup script that might look similar to the following script: #!/bin/bash

/usr/sbin/IMbackup /var/IMbackup.tgz all

/usr/sbin/IMftp.sh 135.9.1.2 dvac PassWoRd /pub/backups/IMLinuxServer put /var/IMbackup.tgz

Integrated Management Database Integrated Management Database (IMD) is the administrative front end to the MSA, FPM, NMSI, and PA applications on the RedHat Linux server. IMD is used to administer connectivity information for communication with managed devices such as Communication Manager, INTUITY, CMS, and so on. IMD is also used for SMTP e-mail configuration, IM Linux application configurations, and user administration. The IMD access method is by way of a Web browser interface under the Apache Web server that is running on the Linux server (http://<IP Address of Linux server>/imdadmin/). The IMD database itself is a PostgreSQL database that is also on the Linux server. An enterprise must include one IMD server, which can be used to administer and manage any number of IM Linux servers and applications.


IMD database schema Figure 10 shows the schema of the IM R3.0 IMD database.

Figure 10 – The IMD database schema


IMD tools This section describes how to use the following IMD tools:

• IMD location tool – IMDLocation • IMD application instance add tool – IMDAddApp

• IMD application instance delete tool – IMDDelApp

• IMD import tool - IMDUpdate

• IMD user import tool - IMDUserImport

• IMD delete tool - IMDDelete

• IMD notification testing tool – TestNotify

IMD location tool - IMDLocation Use the IMD /opt/avaya/imd/bin/IMDLocation tool to change or update the location of the IMD.

If the name or the IP address of the IMD for an IM Linux server changes, you can use the IMDLocation tool to “point” the IM Linux applications on this server to another IMD server. To check the current location of the IMD from the perspective of the local server, enter: # IMDLocation –c

//localhost

Or, if that IMD happens to be on a different server, you see the IP address or the FQDN of that server: # IMDLocation –c

//135.9.23.203

To change the location of the IMD for the current server, enter: # IMDLocation 135.9.23.203

If you change the IMD location in this manner, you must add application instances to the new IMD location for this server. For example, if you have FPM and PA on the dnmfs2 server and want to change the IMD location, you must run the IMDLocation command and then run the IMDAddApp command, as the next section describes, for the FPM-dnmfs2 and the APA-dnmfs2 application instances. You must also run the mfpmconfig, nmsiconfig, and mpaconfig commands to ensure that the applications also pick up the new IMD location. The alternative is to use the master installer to uninstall and then reinstall IM Linux server software on the server, and enter the new IMD location during the installation.

IMD application instance add tool - IMDAddApp Use the IMD /opt/avaya/imd/bin/IMDAddApp tool to add or update an existing application instance in the IMD database.

Usage: /opt/avaya/imd/bin/IMDAddApp [Application Type] [Application Instance Name] [FQDN] [Host name]

To add a new NMSI application instance: # IMDAddApp NMS NMS-dnmfs1 dnmfs1.dr.avaya.com dnmfs1

where a valid Application Type is IMD, MSA, FPM, APA, NMS, or SSG.


IMD application instance delete tool - IMDDelApp Use the IMD /opt/avaya/imd/bin/IMDDelApp tool to delete an existing application instance from the IMD database.

Usage: /opt/avaya/imd/bin/IMDDelApp [Application Instance Name] [Host name]

To add a new NMSI application instance: # IMDDelApp NMS-dnmfs1 dnmfs1

IMD import tool - IMDUpdate Use the IMD /opt/avaya/imd/bin/IMDUpdate tool to import elements into the IMD. This tool provides an easy way to provision IMD before you go on site to do an installation. The IMDUpdate tool takes a comma-separated value (CSV) file as input and populates the IMD database accordingly. You can also use the Import menu item in the left menu bar of the IMD Web Interface to import a CSV file.

Usage: /opt/avaya/imd/bin/IMDUpdate [CSV Filename]

where CSV filename is the full path to the file that contains the CSV data that you want to import.

IMD user import tool - IMDUserImport Use the IMD /opt/avaya/imd/bin/IMDUserImport tool to import elements into the IMD database. This tool provides an easy way to provision IMD before you go on site to do an installation. The IMDUserImport tool takes a comma-separated value (CSV) file as input and populates the IMD user database accordingly. Unlike the IMD database import tool, you cannot use the Import menu item in the left menu bar of the IMD Web Interface to import a CSV file.

Usage: /opt/avaya/imd/bin/IMDUserImport [CSV Filename]

where CSV Filename is the full path to the file that contains the CSV data that you want to import.

IMD delete tool - IMDDelete Use the IMD /opt/avaya/imd/bin/IMDDelete tool to delete the entire contents of the IMD. Use this command with caution. Local applications are stopped before the delete takes place and do not restart after the delete is complete because no IMD is in place. IMDDelete has no command line parameters.


IMD test notification - TestNotify Use the IMD /opt/avaya/imd/tools/.fs/TestNotify tool to verify whether PostgreSQL notifications are working correctly. PostgreSQL notifications are used to notify the MSA, PA, and FPM applications of changes in the IMD to the element, users, and application_properties tables. The following table lists the notification types.

Table name Notification type

Description

users_ins A user record was added.

users_del A user record was deleted. users

users_upd An existing user record was modified.

element_ins A new element record was added.

element_del An existing element record was deleted. element

element_upd An existing element record was modified.

app_prop_ins A new application_ properties record was added.

app_prop_del An existing application_properties record was deleted. application_properties

app_prop_upd An existing application_properties record was modified.

Usage: /opt/avaya/imd/tools/.fs/TestNotify tablename

where tablename is either users, element, or app_prop.

MultiSite Administration MultiSite Administration (MSA) is the successor application to the MCM product. MSA replaces the DEFINITY Network Administration application for environments with multiple administrators and multiple voice systems. MSA uses Web-based clients that talk to an HTTP-based backend server that is running RedHat Linux OS. This section provides some troubleshooting information with respect to MSA.

Note: In the following sections, anywhere that the path /opt/avaya/msa is used, you can substitute ~mcm, such as ~mcm/bin/prffd, and so on.

MSA software process management This section describes several tools that you can use to monitor the current status of the background processes on the MSA server. The Linux server configuration scripts system starts the MSA server background process manager. You can use the RedHat Linux /usr/sbin/service command to start, stop, and display the status of the MSA background server processes. The MSA server background process manager is called “msa-server.”

Usage: /usr/sbin/service msa-server [status|start|stop|restart]


MSA queue control and processes When a user starts a queue within the MSA user interface System Resources tab, the following processes are started with respect to the specified voice system:

check – Process monitor; stops and starts pq, ucron, and any other MSA processes. ucron – Executes scheduled tasks. pq – Queue mechanism for voice systems and messaging servers.

When a database initialization is started on a voice system, the dbupdate task begins execution for the specified voice system. The dbupdate task also executes the jobs that are scheduled out of ucron. Once the MSA server is started, the following processes may begin to run as needed:

bcastmsg - Send broadcast messages to all users bsconfig - Server manager logvwr - View log files sysres - System resource taskman - Task scheduler udataman - Data manager udpcfg - UDP manager urg - Report manager usa - Station administration/station manager usaclr - System locks usched - View scheduler usermgr - User manager

MSA directory structure The following table contains a directory tree that identifies the key locations of files and directories that are installed or created by the MSA application.

File and directory path Description /opt/avaya/msa The main MSA installation

root directory

/opt/avaya/msa/bin The primary location of the MSA executable and server-side programs

/opt/avaya/msa/bin/bob.ini The startup configuration settings file

/var/avaya/msa/database The location of the MSA system-level database file

/var/avaya/msa/logs The MSA syslog and other dynamic log files

/var/avaya/msa/switch The root directory for voice-system-related directories and databases

/var/avaya/msa/switch/VSname The root directory for MSA files that relate to the voice system that is named VSname


File and directory path Description

/var/avaya/msa/switch/VSname/

Username/translations/current.trl

The file that contains all the saved and pending switch changes for the voice system named VSname for the user Username

MSA configuration settings file – bob.ini The bob.ini file contains all server-specific and custom configuration settings for this MSA application instance. The format of this file is similar to a Windows-based .ini file in that sections are delimited by bracketed titles, and parameters are set by way of name-value pairings on lines in between. An equals sign (=) separates the name and the value. The following table lists the common values in a bob.ini file.

Section Parameter name

Default Notes

ServerName MSA-nodename

The IMD Application name that is associated with this MSA server.

ServerType 1 OBSOLETE. Previously used to reference whether this server was a primary or a secondary MSA server.

PrimaryIP 127.0.0.1 The server IP Address, which is the IP address that the server uses to talk to itself. The address is usually the looparound IP address.

LocalIP 127.0.0.1 The local IP address, which is usually the same as the primary IP address.

EtfTimeOut -1 The timeout value for ETF commands from the MSA server to the client (-1 means no timeout).

LogFilesMaxAge 30 The number of days to keep log files on the system.

DataFilesMaxAge 60 The number of days to keep data files on the system.

DatabaseVersion 38 The database schema version, used to determine whether database upgrades might be required during upgrades, and so on.

BOB

SysInitMode 0 If set to 1 (enabled), this value causes an initialization to occur on a new system that was just added into IMD and MSA.

PQLineMonitor 0 PQ line monitoring to syslog (1 = enabled).

DEBUG EtfLineMonitor 0 ETF line monitoring to syslog

(1 = enabled).

CustomPermission

CustomName Custom privilege

OBSOLETE. Before 3.0, the name of the Custom Privilege. This parameter is automatically removed on upgrade and populated into the custom permissions configuration database file.


MSA voice system configuration settings file – switch.ini The switch.ini file contains all server-specific and custom configuration settings for MSA as MSA relates to the specific voice system. The switch.ini file is located in the /var/avaya/msa/switch/VSname/bin directory. The format of this file is similar to a Windows-based .ini file in that sections are delimited by bracketed titles, and parameters are set by way of name-value pairings on lines in between. An equals sign (=) separates the name and the value. The following table lists the common values in a switch.ini file.


Default Notes

CutThruTimeout 300 sec The timeout for waiting for the login prompt from the cut-through connection

EcsTimeOut 1800 The timeout for waiting for a successful SAT connection to a voice system

EtfTimeOut -1 (never times out)

The timeout for communications between the MSA server and the client

Class1 n/a OBSOLETE Class2 n/a OBSOLETE Class3 n/a OBSOLETE Class4 n/a OBSOLETE Class2B n/a OBSOLETE Class5 n/a OBSOLETE Class6 n/a OBSOLETE DedEcstTimeOut 300 The timeout for establishing a dedicated

SAT session to a voice system DedVmTimeOut 300 The timeout for establishing a dedicated

SAT session to a messaging system EcsPorts 2 The maximum number of SAT connections

to make to a voice system QueueStarted 1 An indicator for whether the queue is

running for a voice system

OStuff

PrintCommand n/a

Programs ProgramList pq, ucron Programs that are started by the MSA server background process manager

Dbupdate

Dbinitiate 0 0-Never initialized 1-Initialized 2-Undergoing full initialization (dbupdate -i) 3-Initialization failed 4-A value of 4 might indicate that a cache rebuild must be run. 5-Undergoing a cache rebuild (dbupdate -I)

Platform n/a Server type: S8700, S8300, S8500 G3, G3SI, S8100 S8100

SwitchType n/a Communication Manager software type: Linux, G3R,G3SI, NT

SwitchTRS

Release n/a Major Communication Manager version, such as R11, R12, and so on



Default Notes

Software n/a Complete Communication Manager release string

DispCharSet 03 Whether a voice system supports ACSII characters or Unicode

SysFeat AbbrEnhLength 03 Abbreviated Dialing Enhanced dial access length

MSA syslog event and debug logging The Linux syslog facility is the primary mechanism for MSA to log system events and facilitate debug tracing. The syslog facility manages and rotates the logs when the logs get large, and provides a means by which to enable or disable tracing levels.

The MSA logs are located in /var/avaya/msa/logs. Previous syslogs in this directory have a numerical suffix. The current log does not have a numerical suffix. The best way to see what is going on as things happen is to tail the log.To tail the log, you might run, for example, tail –f /var/avaya/msa/logs/syslog.

MSA client/server debugging To see client/server MSA messaging and debug information, select Help > Monitor on the MSA user interface. When you select either Monitor or Trace, additional debug messages are written to the Java console. If the Java console is not displayed by default, to start the console you can right-click the Java icon in the taskbar of the Windows-based PC and then select Open Console. Then select Monitor to write the trace information to a file. The file location is in the Java console, although the file is usually in the temp directory of the PC with the file name MCMETFX.txt, such as: C:\DOCUME~1\NKAUFM~1.GLO\LOCALS~1\Temp\MCMETF0.txt

Voice-system-level logs These logs contain information that relates to voice-system-specific processing. Logs that are specific to voice systems are located in the /var/avaya/msa/switch/VSname/logs directory. Transaction logs that are specific to individual voice systems and users are located in the /var/avaya/msa/switch/VSname/Users/Username/logs directory.

MSA process-based tracing - mcmtrace The /opt/avaya/msa/bin/mcmtrace tool provides an easy way to view the logs that are associated with a single specified MSA process. To obtain a list of valid MSA processes, run the ps U mcm command. The process ID (PID) that is associated with the process can then be passed to the mcmtrace tool to give a tracing report that is specific to that process. This is not a real-time tool. Instead, the tool gives a snapshot report of what is currently in the syslogs.

Usage:

/opt/avaya/msa/bin/mcmtrace process_id

where process_id is the PID of an MSA process. Tracing 21039 /opt/avaya/msa/bin/imdmgr

==== ps output

UID PID PPID C STIME TTY TIME CMD

mcm 21046 1 0 11:13 ? 00:00:00 /opt/avaya/msa/bin/check -astorm


mcm 21048 21046 0 11:13 ? 00:00:00 /opt/avaya/msa/bin/pq -astorm

mcm 21050 21046 0 11:13 ? 00:00:00 /opt/avaya/msa/bin/ucron -astorm

mcm 21039 1 0 11:13 ? 00:00:00 /opt/avaya/msa/bin/imdmgr

==== gdb output. GDB is a development tool and will not be on most customers

==== installed systems

/opt/avaya/msa/bin/mcmtrace: line 48: gdb: command not found

==== syslog output

syslog:May 31 11:13:19 dnmfs2 imdmgr[21039]: imdBldBobIniFile: server.db0 svr_na

me=MSA-dnmfs2 appl_name=MSA-dnmfs2

syslog:May 31 11:13:19 dnmfs2 imdmgr[21039]: imdSwitchAdded: run

syslog:May 31 11:13:19 dnmfs2 imdmgr[21039]: IMDtrace(ElementNameList)-init(3,Vo

ice System) OK numberOfElements = 1

syslog:May 31 11:13:19 dnmfs2 imdmgr[21039]: imdSwitchAdded: add vsName=[storm]

syslog:May 31 11:13:19 dnmfs2 imdmgr[21039]: imdMsgAdded: B_NODE_DBASE does not

exist

syslog:May 31 11:13:19 dnmfs2 imdmgr[21039]: WriteToBobUserDB(): db_op=2, userID

=admin

MSA database tools This section describes some of the MSA tools that you can use to modify or query the MSA databases. The following table lists the database files and locations.

MSA database file

Full path of the database file Notes

custpriv.db0 Avaya/opt/avaya/msa/database/ custpriv.db0

Custom privileges profile names

ecsusr.db0 /opt/avaya/msa/database/ecsusr.db0 User ID access to voice systems and permission levels

edsdb.db0 /opt/avaya/msa/database/edsdb.db0 Scheduled task database

server.db0 /opt/avaya/msa/database/server.db0 IMD server information

users.db0 /opt/avaya/msa/database/users.db0 User IDs and user-specific information

initdb.db0 /opt/avaya/msa/initdb/initdb assorted /opt/avaya/msa/switch/VSname/* Voice-system-

related database directories

Print MSA database records - prffd Use the /opt/avaya/msa/utils/prffd tool to print an entire MSA database file to standard output in ASCII format. On the command line, you must include the name of the MSA database file to be dumped.

Usage:


/opt/avaya/msa/utils/prffd dbfile_fullpath

where dbfile_fullpath is the full Linux path to the database file to be dumped.

Print a single database record – rdffd Use the /opt/avaya/msa/utils/rdffd tool to print a single record from an MSA database file to standard output in ASCII format. On the command line, you must include the name of the MSA database file to be dumped.

Usage: /opt/avaya/msa/utils/rdffd dbfile_fullpath record_key

where:

dbfile_fullpath is the full Linux path to the database file to be read.

record_key is the unique database key that identifies a single database record.

For example, to query the users.db0 database file and show the record in the users file for the “admin” user, enter: # /opt/avaya/msa/utils/rdffd /opt/avaya/msa/database/users.db0 admin

admin|1|

Print next database record - nxtffd Use the /opt/avaya/msa/utils/nxtffd tool to print a single record from an MSA database file to standard output in ASCII format. On the command line, you must include the name of the MSA database file to be dumped, along with the search key for a specific record. This tool is like the prffd tool that is described above, except that this tool skips the record that was identified by the specified key, and displays the next sequential record in the database file.

Usage: /opt/avaya/msa/utils/nxtffd dbfile_fullpath record_key

where:

dbfile_fullpath is the full Linux path name to the database file to be read.

record_key is the unique database key that identifies a single database record.

Read translation file for user - rdtrans Use the /var/avaya/msa/utils/rdtrans tool to print all pending and saved translation changes that a user made on a specific voice system. To do so, you display the contents of the current scheduler file (current.trl) that each user creates when the user schedules transactions to run. These files are located in /opt/avaya/msa/VSname/UserName/translations/.

Usage: /opt/avaya/msa/utils/rdtrans switch_name user_id

where:

switch_name is the name of the voice system as defined in IMD and MSA.

user_id is the login ID of the user for which to dump the translation file.


Fault and Performance Manager The JAVA programming language was used to develop most of the Fault and Performance Manager (FPM) software. This section describes some of the components of the Java environment and some helpful tips and tools.

Third-party software packages The FPM package is comprised of both programs that Avaya created and third-party software packages. Avaya used these third-party packages to accelerate development intervals and allow the FPM developers to concentrate on functionality instead of operating system and GUI controls. The FPM installation scripts install all these third-party components automatically. The following table lists these components, the suppliers, and the current versions.

Third- party package

Primary purpose or function

URL Vendor

Advent SNMP Interface

Java-based SNMP library package v1.3.1

http://www.adventnet.com/ Advent

Jclass Package Graphing and reporting package v3.6.1

http://www.quest.com/jclass_desktopviews/index.asp

KL Group

Acme GIF package

Creation of GIF reports for the Web

http://www.acme.com/java/software/ Acme.JPM.Encoders.GifEncoder. html

Acme

HP OpenView API

NMSI system view by way of OV-NNM

http://openview.hp.com/ Hewlett-Packard

J2SSH Secure shell access of managed devices, such as Communication Manager

http://sourceforge.net/projects/sshtools Open Source

Java Help Online documentation support for context-sensitive help within the FPM UI

http://java.sun.com/products/javahelp/

Sun

PostgreSQL PostgreSQL JDBC – Java Postgres interface

http://jdbc.postgresql.org/ PostgreSQL (Open Source)

Log4 Tracing, logging, and debug log facility

http://logging.apache.org/log4j/ docs/index.html

Log4j

E-mail Provides for SMT e-mail transmission, attachments, and so on

Unknown E-mail

The following sections provide information on several tools that can help when you use the FPM application to troubleshoot and diagnose system problems.

FPM load balancing and multiple collection servers Release IM R2.0 of FPM introduced the concept of a secondary data collection server. In IM R3.0, this capability stabilized and became a more robust and reliable


http://www.adventnet.com/



http://www.acme.com/java/software/Acme.JPM.Encoders.GifEncoder.html



http://openview.hp.com/

http://sourceforge.net/projects/sshtools

http://java.sun.com/products/javahelp/

http://jdbc.postgresql.org/

http://logging.apache.org/log4j/docs/index.html

http://logging.apache.org/log4j/docs/index.html

configuration. When you install an FPM system that includes a large number of Communication Managers from which you must collect data, you want to offload the primary data collection server as much as possible. The primary server is responsible for all database storage, report scheduling, and UI processing. You can use the data in the following table as a guideline to determine how many servers to use in a given installation and how to distribute the Communication Managers among the servers.

Number of Communication

Managers

Primary server

Secondary server 1

Secondary server 2

Secondary server 3

1 to 50 All n/a n/a n/a 51 to 80 25% 75% n/a n/a 81to 120 10% 45% 45% n/a 121+ 1 Distributed evenly across the secondary servers

FPM environment variables and tunable parameters This section provides the names and the default values of the FPM environment variables and tunable parameters.

FPM environment variables The following table lists the names and the default values of several useful environmental variables. These variable are also used throughout the document for command line references.

Unix variable Unix default value Description $MFPM_MAIN_DIR /opt/avaya/mfpm The FPM application root directory $MFPM_BIN_DIR /opt/avaya/mfpm/bin The location of the FPM application

executables and commands $MFPM_LOG_DIR /var/avaya/mfpm/logs The location of the FPM transaction,

history, and error logs $MFPM_DOC_DIR /opt/avaya/mfpm/doc The location of the FPM online Help,

and Helper (Communication Manager documentation)

$JAVA_HOME /usr/java/j2sdk1.4.2 The Java runtime environment base directory

$DEF_RMI_PORT 5000 The FPM Java RMI port $DEF_TRAP_PORT 5019 The FPM trap service port $DEF_ALERT_PORT 5018 The FPM alert status service port $DEF_NMSI_PORT 5021 The FPM NMSI service port $MFPM_COLL_SVC Primary The FPM collector service name for

this server $MFPM_DB_SERVER Localhost The PostgreSQL database server

name $MFPM_DB_PORT 5432 The PostgreSQL database server port $JAVA_CMD $JAVA_HOME/bin/java

–Xmx512m –Xincgc The Java virtual machine executable

$MFPM_CLASSPATH N/A The Java runtime class path for any FPM-related application.

$JAVA_EXEC $JAVA_CMD

-classpath $MFPM_CLASSPATH

Used to execute FPM-related JAVA programs on the Linux server


FPM tunable parameters (PM properties) The file /opt/avaya/mfpm/data/PMProp contains a list of properties that you can customize on a per-system basis.

Whenever you make manual changes to the PMProp file, you must execute the /usr/sbin/mfpmconfig tool to propagate these changes into the FPM Web client JAR files.

The following table lists the properties in the PMProp file, the default values for these properties, and some notes or suggested ranges for the values.

Property name Default value Notes or suggested ranges MFPM.dbName MFPM The name of the FPM database

within the PostgreSQL server. MFPM.dbSize 1500M The maximum size of the FPM

database. MFPM.dbTransaction 100 The number of simultaneous

database transactions that are allowed.

MFPM.nmsProxyPort 5001 The JAVA proxy server RMI communication TCP/IP port.

MFPM.dbServer IP The IP address of the local PostgreSQL database server that is used by the FPM application (allows for remote databases).

MFPM.dbPort 5432 The PostgreSQL database server service listening TCP port. FPM database connections connect to MFPM.dbServer:MFPM.dbPort.

MFPM.dbUser mfpmadm The database user name for the MFPM database.

MFPM.MultipleCollectors true Allows for a configuration of FPM servers with primary and secondary servers. This property is usually enabled.

MFPM.nmsAlertStatusPort 5002 The JAVA alert status server RMI communication TCP/IP port.

MFPM.nmsTrapPort 5003 The JAVA trap server RMI communication TCP/IP port.

MFPM.nmsATMTrapPort 5004 The JAVA ATM trap server RMI communication TCP/IP port.

MFPM.RmiRegistryPort 5000 The JAVA RMI server communication TCP/IP port.

MFPM.RmiRegistryHost Server FQDN/IP The JAVA RMI server node or system name.

MFPM.snmpRetries 2 The number of SNMP Get retries that the system makes before a read failure is returned.

MFPM.snmpTimeout 15000 The timeout in milliseconds for a single SNMP Get request.

MFPM.TextEditorCommand /usr/bin/X11/ xterm –e vi %file

The command that is used to run an ASCII text editor to view or modify a text-based report.

MFPM.telnetCommand /usr/bin/X11/ xterm –e telnet

The command that is used to start a Telnet session.


Property name Default value Notes or suggested ranges MFPM.defaultPageWidth 66 Not used. MFPM.htmlSubDir data/html_setup The HTML report Java plug-in

setup directory. MFPM.connectionStatusTimeout 10 The number of seconds that the

FPM application waits for a response from a connection status request.

MFPM.snmpTrapPort N/A The UDP port number on which FPM Java looks for SNMP traps. This number is usually 162. However, if a Windows-based NMS is loaded on the same computer, it might already be using 162 and must then forward traps to a different UDP port where FPM can look for the traps.

MFPM.ChartWidth 800 The default width of a chart report window in pixels.

MFPM.ChartHeight 600 The default height of a chart report window in pixels.

MFPM.ArsScriptPath /opt/avaya/mfpm/bin/Definity_ARS

OBSOLETE. This property was made obsolete by the alarm filtering and notification features of FPM 2.1 and 3.0.

MFPM.collectorThreads 10 The number of Communication Managers from which data can be collected simultaneously for scheduled or periodic collections.

MFPM.maintenanceThreads 6 The number of Communication Managers from which data can be collected simultaneously by way of background maintenance or audits of the FPM system.

MFPM.demandThreads 10 The number of Communication Managers from which data can be collected simultaneously by way of user UI requests.

MFPM.defaultPrintCommand /usr/bin/lp %file

The command that is used to print an ASCII file from within the FPM application UI (non-Web client).

MFPM.lockWait 200 The number of seconds required for a database lock request to time out.

MFPM.standalone True OBSOLETE. FPM always operates in a standalone mode.

MFPM.idleConnAfterUse False Causes dynamic connections to be idled after a data collection is complete.

MFPM.MsgLogLimit 5000 The number of lines per message log file. Once the active MsgLog reaches this many lines, a new message log is created.

MFPM.DefSharedMsgLogVersionLimit

30 The number of MsgLog files to keep on the system. When the /var/avaya/mfpm/logs directory accumulates this many


Property name Default value Notes or suggested ranges historical logs, the logger starts over, wipes out log 0, and begins to count up again.

MFPM.Version 3.0.XXX The FPM software version to display in UI and Help About screens.

IMD.dbhost IMD Server The IP address or the FQDN of the IMD server.

IMD.fpmAppName FPM-nodename The application name by which this FPM server registered with the IMD server. Usually, this name is “FPM” followed by the system node name.

IMD.useSSL false A flag that indicates whether FPM uses SSL to query the IMD database.

MFPM.useRmiSSL false A flag that indicates whether SSL is used when making RMI calls within or between FPM servers.

MFPM.useJdbcSSL false A flag that indicates whether SSL is used when doing JDBC access of the PostgreSQL database.

MFPM.ossiTimeout 5000 The timeout in milliseconds for waiting for a response to an OSSI command that was sent to a Communication Manager.

MFPM.synchronizeCounts false A Boolean flag to enable a daily audit of the exception counts within FPM (FixCounts tool).

MFPM.showAllExceptions false Enables all exceptions to show as part of the default exception report (allows showinfg of error exceptions as part of the default exception reports).

MFPM.idleConnAfterUse false A flag that forces the idling of a connection after all items that are currently queued are collected from the system.

MFPM.TimeZone Linux TimeZone The Java time zone string. In some cases, the time zone code for Java does not match the time zone code for RedHat Linux. In other words, Linux CET is Middle European Time (GMT+1:00) while in Java, MET is Middle East Time-Iran (GMT+3:30). The correct Java code for Middle European Time is ECT for European Central Time. For more information, see Appendix A, “Time zone conversion table.”

FPM software process management Several tools exist that you can use to monitor the current status of background processes of the FPM applications. This section describes some of these tools and, where applicable, explains how to customize the logging capabilities of the tools.


The Linux server configuration scripts system starts the FPM background services. You can use the RedHat Linux /usr/sbin/service command to start, stop, and display the status of’ the FPM background service processes. The FPM service is called “mfpm-server.”

Different processes might be running on a given FPM server, depending on whether the server is configured as a primary or a secondary data collection server.

Process management To verify that the FPM server processes are installed and configured to start when the system boots, use the chkconfig command from the root Linux prompt: # chkconfig --list | grep mfpm

mfpm-server 0:off 1:off 2:on 3:on 4:on 5:on 6:off

This output indicates that the FPM services will start when the system is booted into initialization level 2 through 5. This is the correct standard setting. If this is the setting is not as shown above, you can use the following command to enable it: # chkconfig --level 2345 mfpm-server on

Conversely, you can use the following command to disable the FPM services when the system boots: # chkconfig --level 2345 mfpm-server off

Use the service command to start, stop, restart, and display the status of the FPM background processes:

Usage: /usr/sbin/service mfpm-server [start|stop|restart|status]

where: start starts the FPM background services if the services are not already running.

stop stops the FPM background services if the services are currently running.

restart stops (if needed) the FPM background services and then restarts the services once the services are shut down.

status shows the current status of each process.

FPM system-level process status Use the following command to display the current status of all Java-based DEFINITY network management processes: LINUX: # service mfpm-server status

Avaya Fault and Performance Manager Version 3.0.239 Status

MFPM E*Watch status: active - PID is 20079

E*Watch process management status

RmiURL = rmi://135.9.49.14:5000/ProcMgrServer

State Alias ID Retry Restart ||First Crash Launch ||Module

Active TrapServices 9 5 0

05/09/05 13:55:31 ****** ****** 05/09/05 13:55:31

com.avaya.dnm.trap.MFPMTrapServices

Active DataViewServer 8 5 0


05/09/05 13:55:17 ****** ****** 05/09/05 13:55:17

com.avaya.dnm.DataView.DataViewServer

Active NmsiServices 7 5 0

05/09/05 13:55:04 ****** ****** 05/09/05 13:55:04

com.avaya.dnm.collector.nmsifc.NmsiServices

Active AlertStatusServer 6 5 0

05/09/05 13:54:48 ****** ****** 05/09/05 13:54:48

com.avaya.dnm.collector.guiifc.alertstatus.AlertStatusServer

Active DnmServices 5 5 0

05/09/05 13:54:28 ****** ****** 05/09/05 13:54:28

com.avaya.dnm.collector.DnmServicesProcess

Active Collector 4 5 0

05/09/05 13:54:13 ****** ****** 05/09/05 13:54:13

com.avaya.dnm.collector.CollectorProcess

Active ReportScheduler 3 5 0

05/09/05 13:53:55 ****** ****** 05/09/05 13:53:55

com.avaya.dnm.reportscheduler.ReportScheduler

Active MsgLogServer 2 5 0

05/09/05 13:53:40 ****** ****** 05/09/05 13:53:40

com.avaya.dnm.MsgLogServer.MsgLogServer_

Dummy MFPM 1 1 0

****** ****** ****** ****** ****** ******

com.avaya.dnm.EWatch.dummy

PMControl: disconnected...

The format of the status lines is: State Alias ID Retry Restart

First Crash Launch

Module

where:

State is the current state of the process. Valid states are Active (everything is OK), Dead (the process was restarted too many times and has been marked dead), or Dummy (this node is a dummy node in the process tree).

Alias is the alias name used when starting and stopping the individual process with the E*Watch process manager. In most cases, the alias name is the root process name or the base name of the command that is being executed.

ID is the internal process number that the E*Watch process manager assigns to the process.

Retry is the number of times that the process can die and a restart can be attempted within a specific time before the process state is set to Dead. The time


interval is not displayed here, but is defined on a per-process basis. For the interval, see the /opt/avaya/mfpm/ProcMgr file.

Restart is the number of times that the process was restarted after a failure.

First is the date and the timestamp that indicates when the E*Watch process management system first attempted to start this process. This value should correspond to the time that the FPM system was last restarted.

Crash is the date and the timestamp that indicates when this process last crashed or exited unexpectedly.

Launch is the date and the timestamp that indicates when this process was last launched or restarted.

Module is the complete path of an executable. Or in the case of a Java process, module is the complete class name that the Java virtual machine uses to execute the Java process.

The first few lines of the output show the current status, the process ID, or both the current status and the process ID of the inittab ProcStartup background process, and the process ID of the E*Watch Process Manager. E*Watch is the process that actually controls all the background processes that FPM uses.

E*Watch GUI You can use the FPM process monitor to view a graphical representation of the FPM process tree (Figure 11). If the FPM configuration includes primary and secondary data collection servers, a separate window opens for each server that is within a collection server cluster. On secondary collection servers, however, only the MsgLogServer, the DataViewServer, and the Collector processes are running. All other processes are specific to the primary data collection server only.

To view a graphical representation of the FPM process tree:

• From the FPM User Interface Tools menu, click Admin GUI Tools > PM Monitor

• From the Linux command Linux, enter /opt/avaya/mfpm/bin/mfpm gui.


Figure 11 – The FPM process monitor

Java process tracing and logging The main FPM Log directory is located in $MFPM_LOG_DIR. Aside from the ProcMgr.log file that was discussed in the previous section, this directory contains two other sets of logs. These logs are the E*Watch log files and the Java Application MsgLog files. The following sections contain more information about these logs.

E*Watch logging In IM R3.0 of FPM, the logging process was changed to prevent runaway logs if a Java RMI service gets into an unwanted state. To accomplish this, the E*Watch log facility was modified and is now facilitated by the Linux syslog facility. Along with this, the MVMAINT mv_audit task of the Linux logrotate facility rotates the logs on an hourly basis. There are 24 historical E*Watch logs kept on a system. The current and one previous log are not compressed, while all other historical E*Watch log files are compressed by way of the gzip command to save disk space. In some cases, the MsgLog facility that the following section describes might fail to write to its own logs, and the E*Watch log begins to see all the MsgLog message. When this occurs, the logrotate facility ensures that the system does not run out of disk space because of log overrun. Another change in IM R3.0 of FPM is that all GUI-related log messages are also logged into this syslog facility. This change avoids the need to also manage and roll UI logs.

Under normal operation, the E*Watch log contains information that relates to starting and stopping Java processes and general logging information. For example: May 20 16:12:14 lavayaitims gui[13400]: TimeZone = sun.util.calendar.ZoneInfo[id="MST",offset=-25200000,dstSavings=3600000,useDaylight=true,transitions=157,lastRule=java.util.SimpleTimeZone[id=MST,offset=-25200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,s


tartMonth=3,startDay=1,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]

May 20 16:12:14 lavayaitims gui[13400]: TZ/Time=Fri May 20 16:12:14 MDT 2005

May 20 16:13:28 lavayaitims pmsvr: 05/20/05 16:13:28 ProcMgrServer registerProcFriend: EWM490

May 20 16:13:54 lavayaitims pmsvr: 05/20/05 16:13:54 ProcMgrServer registerProcFriend: EWM8789

Each line in the log is a new log entry. Each log entry includes the following elements in the following order:

• A timestamp

• The node name

• The process identifier that is logging the error

• For GUI log messages only, the PID that is associated with that UI process

• The log message itself

MsgLog Logging The MsgLog log files contain the primary information that you need to debug and troubleshoot FPM application problems. All error messages and status events are logged to the MsgLog files by the process that is doing the actual work in the FPM system. Varying levels of status messages, error messages, and debugging messages exist that can be turned on or off. As with the E*Watch log, instances of the word “Exception” in this file usually indicate a problem. Avaya recommends that the customer investigate these exceptions and, in most cases, request troubleshooting assistance.

To help identify which of the MsgLog_# files is the active log, you can run the ls –lt command in the /var/avaya/mfpm/logs directory. By default, this directory includes 30 logs. These 30 logs are rotated as the log files increase in size to a specified threshold. This threshold is specified by the value that you set for the MFPM.MsgLogLimit property in the PMProp file.

The following table lists the valid processes for which you can use these tools to manage tracing.

Application ID Main function of the process MFPM{userid}@{ip} Graphical user interface for DEFINITY network management.

(Changes made to this application ID affect the specific GUI process only.)

DnmServices Handles periodic tasks such as audits and scheduled tasks. DataViewServer Used to generate report output files within FPM. Collector Handles all data collection for the DEFINITY servers. This data

includes configuration, fault, and performance data. ReportScheduler The FPM report scheduler process that runs reports and allows for

the scheduling of reports. AlertStatusServer Handles updates of user interfaces and notifications of events by

way of e-mail, ARS, and so on.


Application ID Main function of the process NmsiServices Facilitates the HP OpenView System View session, mapping,

status updates, and so on. TrapServices Handles all incoming SNMP traps from managed elements, such

as Communication Managers and Intuity systems. MFPMServlet Handles Web client-based launch requests.

The trace-level masks shown are binary bitmaps. Bit 0 is level 0, bit 1 is level 1, and so on through bit 8 and level 8. The higher the trace level that is enabled, the more detailed debugging and tracing information is recorded in the MsgLog files.

Tip: Remember that if you enable too much debug logging at the same time, the logs roll too fast and you might miss your event.

LvlUtil is the primary Java tool used to manage trace levels. You can run LvlUtil without options to show the usage of the command: # LvlUtil

Usage: LvlUtil status

Usage: LvlUtil default <level> [<app>] ... ]

<mask> = sets default mask for new processes

Usage: LvlUtil max <level> [<app>] ...

<level> = activates tracing for levels 0 through <level>

<app> = target application ID (all if not specified)

Usage: LvlUtil mask <mask> [<app>]

<mask> = new level mask (i.e. "0x1B" traces levels 4,3,1, and 0)

<app> = target application ID (all if not specified)

MsgLog process trace-level status display Use the following command to display the current trace levels of the DNM Java processes, as the following example shows: # LvlUtil status

RmiURL = rmi://135.9.49.14:5000/MsgLogServer

Level Mask Application ID

=========== ==============

0x7 ReportScheduler

0x1 NmsiServices

0x1 [email protected]

0x3 DataViewServer

0x1 AlertStatusServer

0x1ff Collector

0x1 TrapServices

0x1 MFPMServlet/opt/avaya/mfpm/webapps/

0x1 DnmServices


Default level = 0x1

In this example:

• Levels 0 and 1 are enabled on the DataViewServer

• Levels 0, 1, and 2 are enabled on the ReportScheduler

• All levels are enabled on the Collector

Setting a MsgLog trace level Use the LvlUtil command to set the trace level of an application ID to a specific value. For example, to set the trace level of the collector to enable levels 0 and 3 (in other words, b00001001 or 0x05), use the following command: # LvlUtil mask 0x05 Collector

No response is given to this command, but if you rerun the status command in the previous section, you see that the collector process is now running with a trace level mask of 0x5: RmiURL = rmi://135.9.49.14:5000/MsgLogServer


=========== ==============

0x7 ReportScheduler

0x1 NmsiServices

0x1ff [email protected]

0x3 DataViewServer


0x5 Collector

0x1 TrapServices


0x1 DnmServices

Default level = 0x1

To set the default trace level for new processes, use the following syntax. This syntax can help you to trace FPM GUI processes. # LvlUtil default 0x07

No response is given to this command, but if you rerun the status command in the previous section, you see that the default mask level is now set to 0x7 for all new processes as the processes are started: RmiURL = rmi://135.9.49.14:5000/MsgLogServer


=========== ==============

0x7 ReportScheduler

0x1 NmsiServices

0x1ff [email protected]

0x3 DataViewServer


0x5 Collector

0x1 TrapServices



0x1 DnmServices

Default level = 0x7

No exact rules exist to specify what kind of information is associated with what trace levels. The following table provides a basic description of the kind of information that you might see at each trace level.

Level Type of information for this level 0 True errors. This level shows problems that were encountered during normal

processing. Detailed messages are displayed that can point you to the right area to fix the problem.

1 Warning-level messages. This level shows potential problems that might develop into true errors, depending on the circumstances in which the problems occur.

2 Standard process-level tracing. This level shows the entry and exit points of a function to illustrate the basic flow of logic.

3 Algorithm-level tracing. This level shows more detail within a given function, such as intermediate points, if-then branch results, and detailed logic flow within the function.

4 Low-level tracing of FPM Java code. This level shows all intermediate steps, variable changes, logic path changes, and the most detail with respect to the execution of the FPM code.

5 Database transaction-level tracing. This level shows the SQL commands and responses that are sent between the FPM code and the FPM and IMD databases.

8 Protocol-level tracing. This level shows the commands and the responses that are sent to and received from the Communication Managers. This information is helpful when you troubleshoot unusual data collection failures with respect to a Communication Manager.

IM R3.0 of FPM narrowed the scope of each trace level. The trace levels are now more useful when you must troubleshoot Communication Manager-to-FPM communication and collection problems. In general, when you troubleshoot collection problems, a trace level of 0x103 on the Collector process is an excellent place to start.

Important: When you use LvlUtil to change the debug levels, you affect the amount of data that is sent to the E*watch and MsgLog files. This action can cause these files to archive rapidly and thus interfere with troubleshooting. Do not place any process, especially the Collector process, at a level that is too high.

FPM Java process controller

You can also use the PMControl interface to E*watch, the process manager, to control the FPM Java background processes.

You can run this command without options to show all command line parameters and arguments.

Note: You must run the following commands from the $[MFPM_MAIN_DIR] directory.

# $[JAVA_EXEC] com.avaya.dnm.Ewatch.PMControl [keyword] [argument]

where keyword can be:

start – Start a specific process as specified by the alias argument.

stop –Stop a specific process as specified by the alias argument.


restart – Restart a specific process (stop followed by start) as specified by the alias argument.

status – Show the status of all processes or a single process if you also specify argument.

shutdown – Stop all FPM background Java processes.

Database query tools

Several JAVA-based tools can help you to troubleshoot FPM problems. You can use these tools to view certain kinds of data in the MFPM database.

Display OSSI/SNMP proxy information for nodes – ShowProxies

Use this command to display the proxy information, whether the OSSI socket (IP address and TCP port number) or an SNMP proxy (IP address and UDP port) is used to collect data from each voice system in FPM.

# ShowProxies

Getting list of DEFTYs

Getting SNMP/OSSI proxies:

Node: test8100 proxy: 135.9.19.88-23

Node: S8700 proxy: 135.11.90.72-5023

Node: Neptune proxy: 135.9.12.247-9000

Node: oldsnmp proxy: 135.9.2.27-161

In this example:

• test8100 uses the standard Telnet port (23) into the IP600/S8100 to log in.

• The S8700 uses the SAT service on a Linux S8700 to log in.

• Neptune uses port 9000 SAT service on a CLAN card.

• The oldsnmp switch uses a Proxy Agent system at 135.9.2.27.

Note: As of IM R2.0 of FPM, SNMP is no longer supported for voice system access. After IM R2.0 of FPM, this list does not include the SNMP agent.

Display FPM system configuration (high level) – MFPMdb GetDefties

Use this command to display basic or high-level FPM configuration information, as that information is stored in the MFPM database. # MFPMdb GetDefties [option]

where option is one of the values in the first column of the following table:

Option Description Sample output or description (No value) Display the names of

all Communication Managers in the MFPM database.

Mercury / IP-Port: 135.9.10.11-5023 / Vintage:R012x.02.0.111.4 / Type=16

Galaxy1 / IP-Port: 135.9.10.10-5023 / Vintage:R012x.02.0.114.0 / Type=13


Option Description Sample output or description Status Display the collection

status for each Communication Manager.

Mercury / ConStat=OSSI_UP / Config=true / CollStatus=true / AlarmColl=true

Galaxy1 / ConStat=OSSI_UP / Config=true / CollStatus=true / AlarmColl=true

Time Display the time difference between the FPM server and the Communication Manager server.

PM time (current): Mon May 23 11:03:50 MDT 2005

Mercury time (estimated): Mon May 23 11:26:50 MDT 2005

Config Display the FPM configuration for each Communication Manager.

The output includes time, collection configuration, and high-level configuration of the system, including cabinets, carriers, gateways, boards, and so on.

Db Dump the MFPM database for each Communication Manager.

The output includes all data that is in the FPM database for all Communication Managers. Note: Basically, this command dumps the entire MFPM database to a text file and thus produces a large amount of data. Use this command in conjunction with the grep utility, or redirect the output to a file that has a sufficient amount of free space in the file system.

Exc Display the exception counts per Communication Manager.

Mercury / Critical=3 / Major=0 / Minor=3 / Warn=73

Galaxy1 / Critical=5 / Major=8 / Minor=60 / Warn=77

This tool uses the next seven tools in this section to create its output. If after you run the tool, you want to see information about a specific DEFINITY, use one or more of the following seven tools as appropriate:

• Display FPM system configuration (high level) – MFPMdb GetManagedNodes

• Enable/disable collection for all nodes – MFPMdb ModCollection

• Display FPM configuration for all managed nodes – MFPMdb ShowConfig

• Display FPM configuration data for a managed node – MFPMdb GetConfig

• Display exception counts by managed node – GetCounts

• Display MFPM database for a managed node – MFPMdb GetDB

• Display Communication Manager server time difference – MFPMdb GetDeftyTime

Display FPM system configuration (high level) – MFPMdb GetManagedNodes Use this command to display a list of the ManagedNodes (non-voice-system elements) that FPM manages. # MFPMdb GetManagedNodes

Enable/disable collection for all nodes – MFPMdb ModCollection Use this command to enable or disable data collection for all voice systems in the MFPM database.


Caution: If you change these parameters, you can affect all aspects of reports and fault determination. Use this command with caution.

# MFPMdb ModCollection [off|on]

where:

off turns off all data collection for all voice systems that this FPM server manages.

on turns on all data collection for all voice systems that this FPM server manages.

Display FPM configuration for all managed nodes – MFPMdb ShowConfig Use this command to show the current data collection configuration for each Communication Manager in the database, along with the times for the next scheduled collection of each data type. # MFPMdb ShowConfig

Definity Vintage Cfg -------Collection Parameters--------

(Proxy Agent) Done Perf Config TrkExc Alarms

======= =============== === ======== ======== ======== ========

snmplab1 ecs N Y/Deflt Y/Deflt Y/Deflt Y/Deflt

(agent1) H@07/D@01 D@01:30 D@01:07 D@02:30

ecs1 ecs N Y/Deflt Y/Deflt Y/Deflt Y/Deflt

(agent1) H@07/D@01 D@01:30 D@01:07 D@02:30

asg1 ecs N Y/Deflt Y/Deflt Y/Deflt Y/Deflt

(agent1) H@07/D@01 D@01:30 D@01:07 D@02:30

dc ecs N Y/Deflt Y/Deflt Y/Deflt Y/Deflt

(agent1) H@07/D@01 D@01:30 D@01:07 D@02:30

In this example, snmplab1 has data collection on for all types (Ys), using Default Parameters (Deflt). Collections occur at 7 minutes after the hour for hourly data, and at 1:00 a.m. for daily performance collection.

Display FPM configuration data for a managed node – MFPMdb GetConfig Use this command to display the FPM configuration information for the specified Communication Manager in the MFPM database: # MFPMdb GetConfig [ManagedNodeName]

where ManagedNodeName is the name of a Communication Manager as the name is defined in the IMD and FPM databases.

Display exception counts by managed node - GetCounts Use this command to display the FPM exception counts (that is, the total number of exceptions) per managed node in the MFPM database: # GetCounts

Getting Voice Systems


Getting Adjuncts

Exception Counts:

NAME: test8100 - 100

NAME: S8700MtAiry - 659

NAME: sputnik-icc - 367

You can also run this command with the option ManagedNodeName, where ManagedNodeName is the name of a Communication Manager as the name is defined in the IMD and FPM databases.

Display MFPM database for a managed node – MFPMdb GetDB Use this command to display the complete database with respect to a specified managed node in the MFPM database. This command actually runs many of the individual commands in this section, and displays all applicable information for the specified Communication Manager. Use the following syntax with this command: # MFPMdb GetDB [ManagedNodeName]

where ManagedNodeName is the name of a Communication Manager as the name is defined in the IMD and FPM databases.

Note: This command produces a large amount of data. Use this command in conjunction with the grep utility, or redirect the output to a file that has a sufficient amount of free space in the file system.


Display Communication Manager server time difference – MFPMdb GetDeftyTime Use this command to display the time difference between the FPM server and the Communication Manager server itself. The Communication Manager time is retrieved at the beginning of each collection cycle, and the time difference is logged into the database. # MFPMdb GetDeftyTime [ManagedNodeName]

where ManagedNodeName is the name of a Communication Manager as the name is defined in the IMD and FPM databases. The following output is a sample of the output from this command: PM time (current): Thu Oct 29 09:22:02 MST 1998

SwitchName time (estimated): Thu Oct 29 09:22:02 MST 1998

Display CM performance data – MFPMdb GetRecs Use this command to display Communication Manager performance data that was collected by FPM and stored in the MFPM database. # MFPMdb GetRecs [ManagedNodeName] [type] [time] [id]

where:

ManagedNodeName is the name of a Communication Manager as the name is defined in the IMD and FPM databases.

type is the type of data to retrieve, as listed in the first column of the following table.

id is an optional argument that specifies a specific group or an item within a data type, as listed in the third column of the following table.

Type Description ID AT Attendant group N/A HG Hunt group Hunt group # IT ISDN call by call trunk group Trunk group # LT Light-use trunks Trunk group # PN Port networks N/A PO Processor occupancy Hour of the day RP Routing patterns Routing pattern # SN Switch node link Pair of nodes (for example, a link

between nodes 1 and 2 would be [id]=12)

SV Security violations N/A TG Trunk group Trunk group # TO Trunk outage Trunk group # TR Tone receivers 1 through 5 WT Wideband trunk groups Trunk group #


time is either [h]ourly, [d]aily, or [w]eekly.

Note that when you use the following types, you must omit the time and the id parameters.

Type Description EA Active events

EI Inactive events

HC Hunt group configuration

TC Trunk group configuration

This tool was not developed as a reporting tool, but as a tool to verify that data exists in the database for a specific data type. The output can be difficult to read, but allows for the display of data in the database without the need for a Linux X window session. This tool can help you to check out things like active or inactive events against a specific DEFINITY. For example, to look at the active events on the “mercury” switch, you can use the following command: # MFPMdb GetRecs mercury EA

a DBEventRec for mercury

dateAsInt start_date Node id desc

930597190 Mon Jun 28 13:13:10 MDT 1999 COLL 0 unavailable proxy or Definity connection blocked data collection

This command yields all active event log entries for the specified switch, such as collection failures, failed scheduled reports, trunk violations, and so on.

Database modification tools In some cases, you might have to make changes to the MFPM database. The following sections provide information on tools that can help you customize database configurations or correct a problem with the MFPM database.

Reinitialize the MFPM database - InitMFPMdb Caution: This tool deletes and reformats the MFPM database on the IM Linux server. Do not use this command until you try all other options to fix the database.

# InitMFPMdb remove

If you suspect that after an upgrade the database was not properly updated with the new database schema, run the following command. This command is not destructive to the database. You can run this command any number of times on the database with no adverse effects: # InitMFPMdb noremove

Remove a node from the database - RemoveNode Use this tool to remove a single Communication Manager from the MFPM database. If a Communication Manager is removed from a network and the customer wants to also remove the database entries that that switch used, you can run the following command. Note that before you remove the node from FPM, you must first remove the node from IMD or at least mark the node as inactive. If you do not remove the node or mark the node as inactive, the node is added back in when the FPM IMDtask runs. # RemoveNode [-f] [-d] [NodeName1 [NodeName2…NodeNameX]]


where:

NodeName is the name of the Communication Manager as the name is defined in the IMD and FPM databases.

–f is an option that forces the removal of a node. In common practice, Avaya recommends that you specify the –f option with this command.

–d is a debug option, and all debug information is sent to the standard output of the RemoveNode command. This option can help you to troubleshoot situations where RemoveNode does not remove a node from the database cleanly. # RemoveNode –f –d Ename > /tmp/remove.log 2>&1 &

Tip: The –d option can generate a large amount of data, so you might want to run this command in the background and use tail to monitor the status.

Cleanup (vacuumdb) the MFPM database - CleanMFPMdb Use this tool to clean up the MFPM database, reclaim unused disk space, and optimize the database for searches. This tool stops the FPM background processes, cleans up the MFPM database, and then restarts the FPM background services. This tool does a PostgreSQL vacuum full analyze of the MFPM database. The database size is displayed before and after the cleanup to show how much unused space was reclaimed. # CleanMFPMdb

CleanMFPMdb start at Thu May 26 09:54:18 MDT 2005

Shutting down FPM Server services: [ OK ]

Starting FPM Database size: 1529 Megabytes

Cleaning...

Ending FPM Database size: 1520 Megabytes

Starting FPM Server services: [ OK ]

CleanMFPMdb finish at Thu May 26 09:58:13 MDT 2005.

See /var/avaya/mfpm/logs/CleanMFPMdb.log for details.

FPM data collector tools Several tools are available that you can use to monitor the status of the data collector processes. You can also request that certain types of data for certain switches be collected. This section describes these data collector tools.

FPM collector status - CollStatus Use this tool to display collector work threads and collector work queues. # CollStatus [cmd]

where cmd is:

status – Dumps a display of collector threads and collector work queues. The collector threads display shows what type of data each collector thread is currently retrieving. The queue display indicates what work items are queued for each switch that is waiting for access to a collector thread.

schedule – Dumps a display of the collector activity that is currently scheduled. Separate lists exist for performance, fault, configuration, and trunk exception collection. In this display, you see when the next scheduled collection for each type of data will occur for each switch. You also see an "AUDIT" task which runs at the top of every hour, which is when any administrative changes made in the GUI take effect.


recover – If one of the collection drone threads gets into a dead state, you can use this option to attempt to recover the dead collection thread and restart data collection.

cache – Displays the contents of the DBHelper cache for data collections. This cache is basically a memory cache of database objects to help increase the speed of database access on frequently used objects in the database.

cleancache [nodename] – An option that cleans up the DBHelper cache that is associated with a specific managed node.

There are three types of collection work queues:

• Collector – These work queues begin with “D-#Collection” and are the standard scheduled collection work queues. Data collection items that are associated with scheduled data collection are processed in these queues.

• Demand – These work queues begin with “D-#Demand” and are used by data collection requests from user interfaces (GUIs) when data must be retrieved from a managed device.

• Maintenance – These work queues begin with “D-#Maintenance” and are used by audits and other background maintenance tasks.

The following output is an example of the output from a CollStatus command: COLLECTOR WORK QUEUES:

D-0Collection : null




D-4Collection : CollectAllPerfData(Saturn):20/27:ClEtherCollection(Saturn)






Current/Maximum items queued = 1/33

Queues waiting assignment = 1

Individual Queue Statistics: (current/max/total)

Queue(Saturn) = 1/4/1403

CollectAllFaultData(Saturn)

Queue(Neptune) = 0/4/1419

Queue(S8700MtAiry) = 0/2/139

Queue(Pluto) = 0/2/517

Queue(linsray) = 0/3/1476

In this example, performance data is being collected from the Saturn voice system in the D-4Collection thread. By looking at the queued items, you can see that a Fault collection is waiting for Saturn to finish collecting the performance data (CollectAllPerfData) before it allows the next item (CollectAllFaultData) to collect. Once the performance data is collected, the Fault data item goes into the D-4Collection thread and is processed. On the Queue (Saturn) line, you can see from the queue statistics (1/4/1403) that one item is currently queued. The largest number of items that were queued on this Communication Manager since FPM services were started was four items. The total number of work items that passed through the collection work queues since FPM started is 1403.


FPM data collection work scheduler - CollWork Use this tool to request that a specific type of data be collected for a specific voice system. This tool can help you to troubleshoot data collection failures with certain kinds of data on a switch. # CollWork [-c|m|d] class VoiceSystem [subclass]

where:

VoiceSystem is the name of a voice system that is administered in IMD to be managed by this FPM application instance.

class is the type of data to collect, in the form of a value from the following table:

Class Description Class Description CollectAllConfig Collect all

configuration data. CollectAllPerfData Collect all

administered performance data. Note that you must specify the full path for the class.

CollectAllFaultData Collect all alarms, errors, and restarts.

CollectPerfData

Important: For the CollectPerfData class, you must also specify a subclass to allow for collection of an individual performance related group. The following table lists the subclasses.

Collect an individual performance datasubgroup that is identified by subclass.

CollectAllTrunkExc Collect all trunk exception data.

CollectAtmCircuits Collect ATM PNC and tTrunk circuit configuration data.

CollectAca Collect Automatic Circuit Assurance data.

CollectBoards Collect board-level Information.

CollectBulletinBoard Collect bulletin board data.

CollectCabinets Collect DEFINITY cabinet configuration data.

CollectDataModules Collect data module configuration data.

CollectDcsLinks Collect DCS link configuration data.

CollectDefinityAlarms Collect alarm data. CollectDefinityErrors Collect error data.

CollectDefinityRestarts Collect restart data (warm, cold, and so on).

CollectExtDevices Collect external device configuration data.

CollectHuntGroups Collect hunt group configuration data.

CollectLightTrunks Collect data on lightly used trunk groups.


Class Description Class Description CollectSwitchTime Collect the

DEFINITY system date and time.

CollectTrunkGroups Collect trunk group configuration data.

CollectTrunkOutages Collect trunk outages from DEFINITY.

CollectVintage Collect software and hardware vintages.

CollectAtmBoards Collect ATM board configuration information.

Subclass specifies the collection of a specified type of data from an individual performance-related group, in the form of a value from the following table:

Subclass Description Subclass Description AnncCollection Announcement data InterPnCollection Inter-port network

data

AttndCollection Attendant group data ISCollection IP signaling group data

CacBlCollection CAC/BL data MMICollection Multimedia interface data

CallRateCollection Call rate data PDCollection Principle measurements

CBCCollection ISDN call by call data PortNetCollection Port network data

ClEtherCollection CLAN Ethernet data ProcOccCollection Processor occupancy data

ClPppCollection CLAN PPP data RemoveOldPmData Remove old performance data

ClSocCollection CLAN socket data RouteCollection Routing pattern data

CPCollection Coverage path data SNCollection Switch node link data

DenialCollection Denial events data SVCollection Security violations data

DRCollection DSP resource data TGCollection Trunk group data

ESMCollection Expansion services module data

TRCollection Tone receiver data

HGCollection Hunt group data VoiceCollection Voice conditioner data

ICCollection IP codec summary data WideTGCollection Wideband trunk group data

–c is an option to queue the work item in a collector work queue.

–m is an option to queue the work item in a maintenance work queue.

–d is an option to queue the work item in a demand work queue.


When you specify a dash option, only progress status is displayed (percentage complete) until the task is complete or ends because of an error. If you do not specify a dash option with CollWork, the work item is collected outside the collector process itself, and debug information is sent to the screen. In this case, you might want to redirect the output and the standard error of this command to a file because the output can include a large amount of data. You can this view this file when you must determine why a specific data collection work item is failing.

For example, to request a Configuration data collection to be queued in the collection work queue for the snmplab1 switch, enter: CollWork –c CollectAllConfig snmplab1

To request a data collection of the Communication Manager vintage information for the switch snmplab1, which in most cases tells you that basic connectivity to a switch is working, enter: CollWork CollectVintage snmplab1

FPM report scheduler status - SchedStatus Use this tool to display a list of background report schedules and when the schedules will run next. # SchedStatus [-d ] [status|hold|release]

where:

status displays the report scheduler that tells you what reports are currently scheduled to run.

hold puts a hold on the processing of scheduled reports.

resume resumes processing of the report schedule.

–d is an option that enables debug output as the command runs.

Native Configuration Manager Native Configuration Manager (NCM) is a Web-based Java applet that provides the terminal emulation for cut-through in FPM and MSA. All files that are associated with this package are installed in the /opt/avaya/ncm/jar directory.

You can start the NCM user interface manually from a bash shell window of an IM Linux server. If FPM is loaded on the same system, you can use the $JAVA_EXEC environment variable to start the JVM to bring up NCM: # $JAVA_EXEC com.avaya.jedi.Jedi [ip_address] [port]

If FPM is not installed on the same server, the command line is more complex: # /usr/java/j2sdk1.4.2_06/bin/java –classpath

/opt/avaya/ncm/jar/jedi.jar;/opt/avaya/ncm/jar/pctt.jar;/opt/avaya/ncm/jar/login.jar;/usr/java/j2sdk1.4.2_06/jre/lib/rt.jar;/usr/java/j2sdk1.4.2_06/jre/lib/i18n.jar com.avaya.jedi.Jedi [ip_address] [port]

When you start NCM in this manner, some debug messages are displayed to the standard output and standard error. Once the window closes, you might have to press Control+C to break out of the thread that is still executing. The entire session (data that was sent from NCM to the server or Communication Manager, and all data that was sent from the server back to NCM) is logged to a file in the current working directory, which is called login.txt. When NCM is executed as an applet, for


instance from an FPM or MSA Web client, the login.txt file is created on the Windows-based client PC on the desktop of the user. One problem with this file is that the Communication Manager login and password are displayed in plain text, which makes the login.txt file somewhat of a security risk. Avaya is currently addressing this issue.

Proxy Agent The Proxy Agent (PA) includes a few different tools that help you to the support and troubleshoot the PA and the nodes that the PA manages. The following section describes the tools that you can run on the PA Linux server. As of IM R2.0 PA, the SNMP subagent capability is disabled by default and only the SNMP master and the G3 subagent are running. The PA provides for SNMP trapping capabilities for existing DEFINITY switches and the supported adjuncts.

Alarm trap testing Several scripts on the Proxy Agent (PA) allow the transmission of test alarm traps to the NMSs or FPM. You can use these scripts to test the NMS event configurations and the Definity_ARS script. These scripts are located in the /opt/avaya/mpa/bin directory. Run these scripts as root on the PA. The following table lists the script names and functions.

Script file name Product Functions and trap types TrapTest DEFINITY and

MCU Major, Ext Major, Minor, Ext Minor, Alarm Cleared, TSC Dispatch, TSC Close, Restart

ADXTrapTest DEFINITY Audix

Major, Minor, Alarm Cleared, TSC Dispatch, TSC Close

CMSTrapTest CMS


CVSTrapTest Conversant or IVR


IADTrapTest Intuity Audix Major, Minor, Alarm Cleared, TSC Dispatch, TSC Close

INTTrapTest Intuity Interchange


When you run the script for the first time, you must set the managed node name and the alarm ID. These values must be valid values for the PA and managed node for which you are doing the test. The following example shows the TrapTest script, but all the scripts work in much the same way. Underlined red text indicates the user input. # /opt/avaya/mpa/bin/TrapTest

Avaya Proxy Agent Alarm Trap Test Tool

Current Voice System Node Name: Not Initialized

Current Voice System Alarm ID: Not Initialized

0) Alarm Clear Trap [alarmClear:0]

2) Major Alarm Trap [alarmMajor:2]

3) Minor Alarm Trap [alarmMinor:3]

5) Major External Alarm Trap [extalarmMajor:5]

6) Minor External Alarm Trap [extalarmMinor:6]

7) TSC Dispatch Alarm Trap [alarmDispatch:7]


8) TSC Close Alarm Trap [alarmClose:8]

9) Restart Notification Trap [alarmRestart:9]

C) Change Voice System alarming from

H) Help

Q) Quit

Send which trap?: C

Changing Voice System that the Alarms will be coming

from.... You must set the Node Name and the

Alarm ID for the Voice System you wish alarms to be

associated with. The Name and ID must match those

specified in the managed node form of the Proxy Agent

for the switch you wish to send the traps for.

Enter new Voice System Node Name: NewYork (must match Managed Nodes Form)

Enter new Voice System Alarm ID: 1005672730 (must match Managed Nodes Form)

Avaya Proxy Agent Alarm Trap Test Tool

Current Voice System Node Name: NewYork

Current Voice System Alarm ID: 1005672730

0) Alarm Clear Trap [alarmClear:0]

2) Major Alarm Trap [alarmMajor:2]

3) Minor Alarm Trap [alarmMinor:3]

5) Major External Alarm Trap [extalarmMajor:5]

6) Minor External Alarm Trap [extalarmMinor:6]

7) TSC Dispatch Alarm Trap [alarmDispatch:7]

8) TSC Close Alarm Trap [alarmClose:8]

9) Restart Notification Trap [alarmRestart:9]

C) Change Voice System alarming from

H) Help

Q) Quit

Send which trap?: 2

Enter alarm trap information for Major trap

MIB oid names are shown in brackets

Switch [g3clientExternalName] : NewYork

Proxy Alarm Sequence Number [g3alarmsAlarmNumber] : 12345

Maintenance Object [g3alarmsMaintName] : CO-TRK

Switch Port Location [g3alarmsPort] : 01C1203

On-Board Alarm Flag [g3alarmsOnBrd] : y

Alarm Trap Emulation Successful.

#


Monitoring traps that are sent from the Proxy Agent In some cases, you might want to see the traps that the Proxy Agent (PA) sends to the IP addresses that are administered in the Network Managers screen of the PA. From the PA, you can now use the traptrace tool to see these traps as the traps are sent. # /opt/avaya/mpa/tools/traptrace

G3SNMP.EXE pid=14836

Backing up snmpd.cnf to snmpd.cnf.sav

Adding loopback port 5150 for trap reception

Killing g3snmp.exe

starting traprcv on port 5150 to display on /dev/tty00

# Waiting for traps

Received SNMPV1 Trap:

Community: public

Enterprise: definity_proxy

Agent-addr: 135.9.142.54

Cold Start trap.

Time Ticks: 7

This example shows that the UDP port 5150 on the loopback address 127.0.0.1 was added as a “network manager.” Then the traprcv process was started in the background to show traps as the traps are sent out. When the g3snmp.exe process restarts, you see the SNMPV1 cold start trap as shown above. Traps continue to be sent to your screen as the traps are sent out of the PA. To turn off the display of traps, run the traptrace tool with the –k option: # /opt/avaya/mpa/tools/traptrace –k

Killing traprcv process

If the traptrace is started and then stopped with the –k option, the next time that the traptrace is started, you see the messages about making the configuration changes and restarting g3snmp.exe. Only the traprcv process is restarted.

Communication Manager Sub Agent Communication Manager Sub Agent (CMSA) is the native SNMP agent that is part of Communication Manager. This includes the S83XX, the S85XX, and the S87XX Linux platforms. The native SNMP agent is actually a co-resident SNMP agent because the native agent still uses OSSI to communicate between the SNMP agent and the Communication Manager itself with a local network socket connection on the Communication Manager.

In IM R3.0 of CMSA, the alarm and trap filtering capabilities of FPM were added to the alarming agent of the CMSA.

Common problems with CMSA implementations Avaya finds that almost all problems that are related to the CMSA are caused when the setup directions are not followed when the system is installed. If you have a CMSA that does not respond to SNMP queries, perform the following steps to troubleshoot the problem:

1. Log in to the Communication Manager Web interface and then launch the Maintenance Web Interface.

2. Under Security in the left navigation bar, click Firewall > Advanced Settings at the bottom of that page.


3. Verify that the checkboxes for ports 161 and 162 (UDP and TCP) are selected (enabled) for incoming and outgoing traffic.

4. Under Alarms in the left navigation bar, click SNMP Traps. Ensure that your Network Management System IP address is listed on this page and that the entry is enabled for v1/v2 or v3 traps.

5. Under Alarms in the left navigation bar, click SNMP Agents. This is where a lot of mistakes can be made if you are not careful.

6. In the Agent ACP Login fields, enter a password and then reenter the password. The password that you choose for the acpsnmp login is arbitrary because only the MVSubAgent can use that login locally on the voice system to talk to the switch. When you experience a CMSA problem, set the password on the SNMP Agents form and save the form. In most cases, this action solves the problem.

7. Set the SNMP v1 community string to match the community string on your NMS. Whether you also set v2 and v3 is optional. The community string is similar to a password that the SNMP agent uses to decide if the requesting application has permission to access the MIB.

8. If Any IP Address is not selected on this page and individual IP addresses are being specified for access, ensure that the IP address of your NMS is also in this list.

9. When you finish making changes, save the form. Go back to the same SNMP Agents screen. Click STOP at the top to stop the Sub Agent, and then click START to restart the Sub Agent.

Watchdog status of CMSA The CMSA runs as a controlled process under the Communication Manager watchdog process manager.You can use the statapp tool to view the status of the watchdog and the processes that are running under the watchdog. # statapp

Watchdog 20/20 UP

TraceLogger 4/ 4 UP

ENV 1/ 1 UP

LicenseServer 4/ 4 UP

INADSAlarmAgen 1/ 1 UP

G3AlarmAgent 1/ 1 UP

GMM 5/ 5 UP

SNMPManager 1/ 1 UP

arbiter 3/ 3 UP

filesyncd 9/ 9 UP

dupmgr 1/ 1 UP

MasterAgent 11/11 UP

MIB2Agent 1/ 1 UP

MVSubAgent 1/ 1 UP

SME 9/ 9 UP

MCD 1/ 1 UP

CommunicaMgr 90/90 UP

The above output shows that the MasterAgent, the MIB2Agent, and the MVSubAgent are all running. These three processes make up the SNMP agent for the Communication Manager. The Master Agent receives all requests and then determines which Sub Agent should handle a given request. Communication


Manager 3.0 includes a new G3AlarmAgent that handles the alarm filtering and alarm refinement features. INADSAlarmAgent is responsible for sending out the INADS-based alarm notifications.

Usage: statapp [-c# [-D|-U]] [-d] [-l#] [-p] [-w] [-s app1[,app2,...]] statapp -v

statapp -?

-c#: continuous update; update every # seconds; range: 1-9 seconds

-d: list only applications which are down (but expected up)

-D: exit continuous update when all processes are DOWN

-l#: list status of all applications and services; show applications

at level # and below; range: 0-9; default: 0

-p: list names & status of processes associated with applications

-s: only show the status of the named applications (-l gives all

possible names)

-U: exit continuous update when all processes are UP

-w: also show WATCHED status (by watchdog) of application

-v: show command version

-?: show this help

Stopping, starting, and restarting the MVSubAgent The primary executable associated with the Sub Agent is the MVSubAgent. This process is responsible for responding to requests of the g3mib itself and deals with the OSSI interface to the Communication Manager. To stop and start the MVSubAgent only, use the following commands. You must be logged in as sroot to use these commands. # stop –f -s MVSubAgent << Stop the sub agent

# start –s MVSubAgent << Start the sub agent

If you are working with an older version of Communication Manager that does not support the stop or start commands, you can use the following shutdownproc and addproc commands. You must be logged in as sroot to use these commands. # shutdownproc MVSubAgent << Stop the sub agent

# addproc MVSubAgent << Start the sub agent

You can also start the MVSubAgent by way of the command line to look at the debug output of the process itself.

Important: When you trace the MVSubAgent process, the Sub Agent itself outputs a significant amount of debug information during execution. Much of this information is detailed information about the activity of the Emanate SNMP Agent code and its generated segments. The size of the log output can be large. Do not leave this log on in the Communication Manager system of a customer for any length of time.

You must run the commands in this section as the sroot user on the Communication Manager itself.

First, you must stop the MVSubAgent. Run the stop -f -s MVSubAgent command as shown above, or on older versions of Communication Manger, run the shutdownproc MVSubAgent command.


Second, you must start the MVSubAgent by way of the command line: # /usr/local/bin/mvmgt -d -apall

NMSI Master Server The NMSI Master Server (NMSI-SERVER) component allows both a single NMSI to manage multiple FPM servers and multiple NMS servers to manage a single FPM server. The files for NMSI are installed in the /opt/avaya/nmsi directory tree. These files include a servlet component and the configuration script /opt/avaya/nmsi/bin/nmsiconfig. These tools are the only tools that are available to troubleshoot this component specifically.

The NMSI Master Server queries the IMD database to determine which NMSs are managing which FPM servers. The NMS talks to the Master Server. The Master Server then redirects the communication to another FPM server depending upon which voice system or adjunct is being queried by the NMSI.

HP OpenView - System View This section contains information that is related to troubleshooting the interface between Integrated Management System View and HP OpenView Network Node Manager (NNM).

Checking FPM objects in the HP OpenView database To display the configuration of an MFPM object inside the HP OpenView database, use the following NMS command: $OV_BIN/ovobjprint –s [DEVICE] (for UNIX)

c:> ovobjprint –s [DEVICE] (for Win2K)

where DEVICE is the FPM-OVdatabase object name. This object name is comprised of a few different pieces. Each piece is separated by a field delimiter, which by default is the tilde (~). The first parameter is a tag identifier (by default this is “MFPM”) which identifies the object as something that was created by FPM. In the case of a Proxy Agent (PA), the second parameter is the IP address of the PA followed by a dash and then the SNMP port number (161). In the case of a managed node such as DEFINITY, Audix, MCU, and so on, the second field is still the IP of the PA, and the third field is the managed node name. The following example is a sample of a record dump for a PA. # /opt/OV/bin/ovobjprint -s MFPM~135.9.70.238-161

OBJECT: 2139

FIELD ID FIELD NAME FIELD VALUE

10 Selection Name "MFPM~135.9.70.238-161"

14 OVW Maps Exists 1

15 OVW Maps Managed 1

17 vendor Avaya(33)

561 isSNMPSupported TRUE

562 isSNMPProxied FALSE

568 SNMPAgent DEFINITY G3 Proxy Agent(144)

1514 mfpmStatus 0

1517 mfpmProxyName "135.9.70.238-161"

1519 mfpmType "proxy"

1520 mfpmIp "135.9.70.238"

1523 isMFPMobj TRUE


1525 isICC FALSE

1526 isLSP FALSE

1528 isDEFINITY FALSE

1530 isG3Proxy TRUE

1531 isG3Conn FALSE

1537 isDEFADX FALSE

1538 isINTADX FALSE

1539 isINCHADX FALSE

1540 isCMS FALSE

1541 isCONVERSANT FALSE

1544 isG700 FALSE

1545 isDEFendpt FALSE

1546 isDEFINITYOne FALSE

1547 isDEFINITYclan FALSE

1548 isDEFINITYval FALSE

1549 isDEFINITYmapd FALSE

1550 isDEFINITYvoipmm FALSE

1551 isDEFINITYmedpro FALSE

1553 isMediaServer FALSE

#

Certain fields are important depending on the database entry. For PAs, the isG3Proxy field should always be TRUE, and the isSNMPSupported field should be TRUE. For all objects within the SystemView (Integrated Management Maps), the database field isMFPMobj should also always be TRUE. If these fields do not appear in the PA record, the OpenView fields probably did not register completely during the installation. To correct this, take one of the following actions:

• On Solaris, rerun the NMSI config tool manually (/opt/avaya/VisAbility/nmsi/bin/configNMSI)

• On Windows 2000 and Windows 2003 platforms, run the following commands in this order:

ovstop

ovstart ovwdb

ovw –fields

ovstart

Validating SNMP access to data on a proxy Sometimes you might need to determine if the NMS and the PA are configured properly to allow access to the data that the agent has. Avaya uses the snmpwalk tool to validate that SNMP data can be retrieved correctly.This tool starts to walk through the entire MIB of a specific managed device. In the case of the PA or CMSA, the tool walks through all the IP interfaces, the OS information, and then the G3/ECS Managed Nodes (client) tables and connection information.

Tip: This tool can produce a large amount of information. To avoid hanging a connection that has a low data rate, redirect the output into a file.

You must use the –c option to specify the GET community string on the command line. The output of the command when run on a PA looks similar to the following output. The output includes managed node names, types, connection types, status, and so on. # $OV_BIN/snmpwalk -c public 135.9.43.126


system.sysDescr.0 : DISPLAY STRING- (ascii): Definity G3 Proxy Agent

system.sysDescr.0 : DISPLAY STRING- (ascii): MultiVantage Proxy Agent

system.sysObjectID.0 : OBJECT IDENTIFIER: .iso.org.dod.internet.private.e

terprises.avaya.products.def-products.g3-products.definity-proxy

system.sysUpTime.0 : Timeticks: (22888) 0:03:48.88

system.sysContact.0 : DISPLAY STRING- (ascii): Contact

system.sysName.0 : DISPLAY STRING- (ascii): dnmfs2

system.sysLocation.0 : DISPLAY STRING- (ascii): Location

system.sysServices.0 : INTEGER: 72

system.sysORLastChange.0 : Timeticks: (0) 0:00:00.00

interfaces.ifNumber.0 : INTEGER: 2

interfaces.ifTable.ifEntry.ifIndex.1 : INTEGER: 1

interfaces.ifTable.ifEntry.ifIndex.2 : INTEGER: 2

interfaces.ifTable.ifEntry.ifDescr.1 : DISPLAY STRING- (ascii): lo

interfaces.ifTable.ifEntry.ifDescr.2 : DISPLAY STRING- (ascii): eth0

interfaces.ifTable.ifEntry.ifType.1 : INTEGER: softwareLoopback

interfaces.ifTable.ifEntry.ifType.2 : INTEGER: ethernetCsmacd

……

……

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientCommunity.0 : DISPLAY STRING- (ascii): test1

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientCustomerId.0 : DISPLAY STRING- (ascii): test1

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientDescription.0 : DISPLAY STRING- (ascii): ECS

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientExternalName.0 : DISPLAY STRING- (ascii): test1

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientConnectStatus.0 : DISPLAY STRING- (ascii): off

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientSubmapType.0 : INTEGER: 0

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientState.0 : INTEGER: 0

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientSubmapName.0 : DISPLAY STRING- (ascii):

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientConnectType.0 : DISPLAY STRING- (ascii): static

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientDynamicTimeout.0 : INTEGER: 0

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientEnumType.0 : INTEGER: generic

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientEnumState.0 : INTEGER: alabama

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientDialString1.0 : DISPLAY STRING- (ascii): 135.9.70.140

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientDialString2.0 : DISPLAY STRING- (ascii):

avaya.mibs.definity.g3proxmib.g3client.g3clientTable.g3clientEntry.g3clientTableIndex.0 : OCTET STRING- (ascii): 1

avaya.mibs.definity.g3proxmib.g3agent.g3agentSubmapType.0 : DISPLAY STRING- (ascii): 0


avaya.mibs.definity.g3proxmib.g3agent.g3agentState.0 : DISPLAY STRING- (ascii): 0

avaya.mibs.definity.g3proxmib.g3agent.g3agentSubmapName.0 : DISPLAY STRING- (ascii):

avaya.mibs.definity.g3proxmib.g3agent.g3agentRelease.0 : DISPLAY STRING- (ascii): 1.3.8

avaya.mibs.definity.g3proxmib.g3agent.g3agentDomainName.0 : DISPLAY STRING- (ascii): dr.avaya.com

avaya.mibs.definity.g3proxmib.g3agent.g3agentSnmpPolling.0 : INTEGER: on

avaya.mibs.definity.g3proxmib.g3agent.g3agentSnmpTraps.0 : INTEGER: on

avaya.mibs.definity.g3proxmib.g3agent.g3agentSnmpSet.0 : INTEGER: on

…….

…….

End of MIB View

HP OpenView IP Telephony Smart Plug In The HP OpenView division of Hewlett-Packard developed and supports the HP OpenView IP Telephony Smart Plug In (IPT-SPI). IPT-SPI shares some common components with NMSI, Avaya Network Manager, and HP OpenView Network Node Manager. In the long term, Avaya expects IPT-SPI to take over most of what the current NMSI does. As Hewlett-Packard develops more useful capabilities and makes the IPT-SPI a more complete offer, NMSI might become obsolete. In the mean time, however, NMSI continues to be an option for customers who want to manage Avaya voice-related elements on the HP OpenView Network Node Manager platform.

The IPT-SPI is currently supported only on HP OpenView NNM Enterprise 7.5 version and later.


Appendix A, Time zone conversion table

The following table contains a list of all known time zones between Java, PostgreSQL, and Linux.

GMT offset

Java Postgres Linux Description

+13:00 NZDT NZ New Zealand Daylight Time

+12:00 IDLE International Date Line, East

+12:00 NST NZST NST New Zealand Standard Time

+12:00 NZT New Zealand Time

+11:00 SST AESST SST Eastern Australian Summer Std Time

+10:30 ACSST Central Australian Summer Std Time

+10:30 CADT Central Australian Daylight Time

+10:30 SADT South Australian Daylight Time

+10:00 AET AEST AET East Australia Std Time

+10:00 EAST East Australia Std Time

+10:00 GST Guam Std Time, USSR Zone 9

+10:00 LIGT Melbourne, Australia

+9:30 ACT ACST ACT Central Australia Std Time

+9:30 CAST Central Australia Std Time

+9:30 SAT South Australia Std Time

+9:00 AWSST Australia Western Summer Std Time

+9:00 JST JST JST Japan Std Time, USSR Zone 8

+9:00 KST Korea Standard Time

+9:00 WDT West Australia Daylight Time

+8:30 MT Moluccas Time

+8:00 AWST Australia Western Std Time

+8:00 CTT CCT CTT China Coastal Time

+8:00 WADT Western Australia Daylight Time

+8:00 WST Western Australian Std Time

+7:30 JT Java Time

+7:00 VST WAST VST West Australian Std Time

+6:00 BST BST Central Asia Standard Time

+5:30 IST IST India Std Time

+5:00 PLT PLT West Asia Std Time

+4:30 MET MET Iran Std Time

+4:00 NET NET Arabian Std Time


GMT offset


+3:30 IT MET Iran Time

+3:30 IT MET Iran Time

+3:00 ART Egypt Standard Time

+3:00 EET EETDST Eastern European Daylight Savings Time

+3:00 EAT East African Time /

+2:00 CEST CETDST Central European Daylight Savings Time

+2:00 EET EET Eastern Europe, USSR Zone 1

+2:00 FWT French Winter Time

+2:00 IST Israel Std Time

+2:00 MEST Middle Europe Summer Time

+2:00 METDST Middle Europe Daylight Savings Time

+2:00 SST Swedish Summer Time

+1:00 BST British Summer Time

+1:00 ECT CET ECT Central European Time

+1:00 DNT Dansk Normal Tid

+1:00 FST French Summer Time

+1:00 MET Middle European Time

+1:00 MEWT Middle Europe Winter Time

+1:00 MEZ Middle Europe Zone

+1:00 NOR Norway Standard Time

+1:00 SET Seychelles Time

+1:00 SWT Swedish Winter Time

+1:00 WETDST Western Europe Daylight Savings Time

0:00 GMT Greenwich Mean Time

0:00 UTC Universal Time Code (GMT+0:00)

0:00 WET Western European Time

-1:00 CAT Central Africa Time

-1:00 WAT WAT West Africa Time

-2:30 NDT NDT NDT Newfoundland Daylight Time

-3:00 ADT ADT Atlantic Daylight Time

-3:00 BET BET Brazil Eastern Time

-3:00 AGT Argentina Std Time

-3:30 CNT NFT Newfoundland Std Time

-3:30 NST NST Newfoundland Std Time


GMT offset


-4:00 PRT AST AST Atlantic Std Time

-4:00 EDT EDT EDT Eastern Daylight Time

-4:00 ZP4 GMT+4 Hours

-5:00 CDT CDT CDT Central Daylight Time

-5:00 EST EST EST Eastern Std Time


-6:00 CST CST CST Central Standard Time

-6:00 MDT MDT MDT Mountain Daylight Time


-7:00 MST MST MST Mountain Standard Time

-7:00 PDT PDT PDT Pacific Daylight Time

-8:00 PST PST PST Pacific Savings Time

-8:00 YDT Yukon Daylight Time

-9:00 AKDT HDT AST Hawaii/Alaska Daylight Time

-9:00 YST Yukon Savings Time

-10:00 HST AHST HST Alaska/Hawaii Std Time

-10:00 CAT Central Alaska Time

-11:00 MIT NMT MIT Nome Time / Samoa Std Time

-12:00 IDLW International Date Line, West


Table of Figures

Figure 1 – The VNC Connection details window .................................................................. 9 Figure 2 – The VNC Authentication window ......................................................................... 9 Figure 3 – A Linux Gnome desktop session by way of VNC ............................................. 10 Figure 4 – The Avaya Integrated Management Server Status screen ............................... 11 Figure 5 – The Avaya Integrated Management Server Status Download screen .............. 12 Figure 6 – A WinZip dialog box ........................................................................................... 13 Figure 7 – A WinZip decompressed archive ....................................................................... 13 Figure 8 – The PuTTY configuration screen ....................................................................... 14 Figure 9 – An MS-DOS screen with examples of PSCP commands.................................. 15 Figure 10 – The IMD database schema.............................................................................. 20 Figure 11 – The FPM process monitor ............................................................................... 38


Documents

Avaya Integrated Management R3.0 Field Support Tools, Tips, and Tricks …support.avaya.com › elmodocs2 › intmgmt › 14_600823_1.pdf · 2005-12-15 · Important: VNC sessions