Maintenance features

Maintenance features for an Avaya Modular Messaging system include:

• System maintenance — describes the organization and function of the maintenance utilities
• Logs — describes the different types of logs in which the system records information about its activities
• Alarms — describes the types of alarms supported on the system, how problems are recorded in the maintenance log, and how they are corrected
• Database audits — describes the types of database audits that run automatically or on demand to ensure the integrity of system data
• System backups — covers the importance and scope of automatic backups

System maintenance

An Avaya Modular Messaging system detects and reports problems depending on the type of server:

• The Messaging Application Server (MAS) records its own set of alarms, errors, and events. See Event, Error, and Alarm Logs for more information.
• The Message Storage Server (MSS) tracks system-wide status and problems using a set of maintenance utilities. These entries are recorded in system logs as described in this section.

Logs

The Message Storage Server uses a series of logs as the central collection point for information flowing from the messaging features and feature packages in a Modular Messaging system. These logs provide a systemwide view of activities, errors, and alarms. Reviewing the logs allows a system administrator to reach a quick understanding of overall system status, leading to efficient and effective maintenance and troubleshooting.

Messages in the logs range in importance from informational to critical. The logs vary based on audience (login type) and information type. The current system uses the following logs:

• Activity log: Records a list of mailbox-related events (for example, logins and message creation, receipt, and deletion). This log is useful for responding to subscriber-reported problems. See Activity log for more information.
  

  Note: Only events on the Message Storage Server are recorded in the activity or administrator's logs on the MSS. Events on the Messaging Application Server (MAS) are recorded in their own set of alarm, error, and event logs. See Event, Error, and Alarm Logs for more information.

• Administration history log: Identifies administrative events that occur on your system such as logins, command line entries, reports that were run, or changes to software. See Administration history log for more information.
• Administrator's log: Records informational messages and administration-related alarms that could require some action by the system administrator. These messages might simply log a successful nightly backup, or they could alert the system administrator that the system is low on disk space. See Administrator's log for more information.
• Alarm log: Signals a service-affecting or potentially service-affecting problem with the system. The alarm log records major, minor, and warning alarms generated by the system. The system automatically notifies a designated services support agency of all major and minor alarms by using the modem if the system is registered with a remote service center. The customer is responsible for resolving all warning alarms. See Alarm log for more information.
• Backup and restore logs: These logs contain a list of all the files that were backed up or restored, information about any errors that occurred during the operation, and whether or not the backup or restore operation completed successfully. See Backup and restore for more information.
• Enhanced-list delivery failure log: Contains entries for all Enhanced-List Application (ELA) failed deliveries, along with descriptive data regarding the cause for the failure and other information. Check this log to monitor ELA and system performance and if a subscriber complains that messages are not being delivered. See Enhanced list maintenance for more information.
• Internet messaging logs: Shows events related to the Internet messaging (email) feature. See Email (Internet Messaging) administration for more information.
• Maintenance log: Records error occurrences, error resolutions, and informational events that can help services personnel troubleshoot an alarm. See Maintenance log for more information.
• Software installation and removal log: Contains information about the installation, update, and removal of software packages. See Viewing software installation and removal logs for more information.

Alarms

An Avaya Modular Messaging system supports two types of alarming:

• Avaya's Initialization and Administration System (INADS). This type of alarming requires a modem connection to a remote service center.
• A corporation's Simple Network Management Protocol (SNMP) system. If SNMP alarming is used, it is the customer's responsibility to provide and provision the corporate SNMP network management system (NMS) that will monitor the Modular Messaging system for alarm notifications (traps), and to configure it to receive (and optionally acknowledge) the traps generated by the Modular Messaging system.

For each type of alarming, the customer can specify:

• The conditions for sending an alarm notification
• The alarm level at which notification will be sent (minor or major)
• The system behavior for stopping Modular Messaging service

Alarm operation

The MSS records problems it detects in the maintenance log. The system then attempts to diagnose and isolate those problems and can send an alarm to the alarm log if it cannot correct the error automatically.

The contents of the alarm log represent all of the significant problems the system detects. Therefore, it is the starting point for troubleshooting the system. The alarm log contains two types of entries:

• Active alarms: Indicate a current problem in the system.
• Resolved alarms: Show alarms that have been corrected either automatically or through a repair procedure.

Three alarm levels indicate the severity of an alarm:

• Major alarms: Indicate problems that could affect key system components or features. For example, if more than 25% of the voice ports are out of service, a major alarm is generated. Major alarms are repairable by technicians.
• Minor alarms: Indicate problems that could affect full service but are not critical to system operation. For example, if a network connection occurs, a warning alarm appears. Minor alarms are repairable by technicians.
• Warning alarms: Indicate problems that could potentially affect system service if not resolved. For example, if the customer system administrator does not create a trusted server password and a trusted server tries to log in, a warning alarm is generated. Warning alarms are repairable by the customer.

When an active alarm is corrected, its status changes from "active" to "resolved."

Alarm notification

Viewing the administrator's log and the alarm log on a daily basis is the best way to be informed of new entries. Active alarms (alarms that have not been resolved) and new entries to the administrator's log are noted on the Status web page.

The Status web page shows multiple levels of alarms. The alarm level is important because it classifies problems within the system so that the most severe are worked on first. In most cases, the alarm level also marks the area between the responsibility of the system administrator (warning alarms) and the responsibility of the remote service center (major and minor alarms).

Alarm resolution (INADS only)

If the customer purchases a maintenance service contract and activates the alarm origination feature for INADS service, the system automatically sends major and minor alarms to a remote service center for correction. Warning alarms are not sent to a remote service center. Warning alarms must be corrected by the system administrator by using the procedures detailed in Alarms.

Remote service center (INADS only)

The Remote Maintenance Board (RMB) on the Message Storage Server uses a modem to establish a point-to-point protocol (PPP) connection between the messaging system and an Avaya remote service center, or an alternative services support agency. The modem is internal for domestic (United States) systems, or external in other countries. The RMB's modem requires an external, direct telephone line or a direct inward dialing (DID) line through the telephony system. The RMB uses this line to report alarms to the services support agency. The remote service center establishes a dialup connection to the RMB over this same line to help maintain and troubleshoot the system.

Caution! The only dialup access to the message server is through the same line that is used for alarm notification. The server cannot report any new alarms while this line is in use. The dialup connection should be used only for services support of the server, not for routine administration.

See the Remote Maintenance Board (RMB) CYN23AP and CYN24AP PCI Version Release 1.0 Reference (585-310-263, 3 MB pdf) for more information. This document is available to certified personnel through the Avaya web site.

Database audits

During normal operation, the system's databases work independently of each other under the direction of a set of software and hardware processes. These processes coordinate the files, databases, and system hardware.

Since databases are handled separately, it is possible for one database to contain information that conflicts with another database. For example, if a subscriber is removed from one database, other databases could still contain messages addressed to that subscriber or mailing lists that include that deleted subscriber's name.

To reconcile possible conflicts among databases, software programs called audits run automatically (or can be performed on demand) to check for inconsistencies and, when possible, update information in databases to correct problems. For example, audits remove all references to a deleted subscriber, which includes deleting the subscriber's name from mailing lists and canceling message deliveries to that subscriber.

Voice messaging audits

The messaging feature package performs many regular internal audits on the databases of information it maintains. These databases include:

• Mailboxes
• Mailing lists
• Network data
• Personal directories
• Subscriber data
• Voice files

Networking database audits

The networking database audit consists of a series of internal checks. For example, these checks verify that files are not corrupted and that values within the files are within the proper ranges. The networking database consists of two parts, the networking administration database and the remote subscriber update status database.

System backups

The nightly unattended (automatic) backup that the messaging system performs might not have enough information to restore the system completely. However, the backup does contain enough information to return the system back to working order should a problem occur. This capability offers customers the security of always having the previous day's messaging and system information available.

At a minimum, the customer should enough read/writable DVD disks to complete seven backups (one for each night of the week). Depending on the needs of the business, these read/writable disks can be archived for a longer length of time or can be swapped out daily. This process ensures that the previous day's messaging and system information is available at any time.

Top of page