Maintenance Features

The messaging maintenance software offers a consistent set of tools for troubleshooting and maintaining the system.

This consistency provides the customer's system administrator with a single point of reference for maintenance and troubleshooting, regardless of configuration. For example, the configuration can include Voice Messaging, and Digital Networking. All of these applications use the same alarm log to report problems that occur within the feature or in its interaction with other feature packages. This log:

• Receives entries from all areas of the system
• Prioritizes alarms according to severity
• Is accessible in an easy-to-read report

The tools available to help maintain the messaging software are:

• Logs. Describes the different types of logs in which the system records information about its activities.
• Alarms. Describes the alarms recorded in the maintenance log and how they are corrected.
• Remote Service Center. Describes the role of the remote service center in maintaining the system.
• Database Audits. Describes the types of database audits that run automatically or on demand to ensure the integrity of system data.
• Security. Describes security features.

Logs

The system uses a series of logs as the central collection point for information flowing from all of the messaging features and feature packages. These logs provide a systemwide view of activities, errors, and alarms.

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 four logs:

• Activity Log

The activity log records a list of messaging mailbox-related events (for example, logins and message creation, receipt, and deletion). This log is useful for responding to subscriber-reported problems. The activity log is accessible to the vm, sa, and craft logins.

• Administrator's log

The administrator's log records informational messages that could require some action by the messaging 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. The administrator's log is accessible to the vm, sa, and craft logins.

• Alarm log

The alarms signal 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 remote service center of all major and minor alarms by using the modem if the system is registered with the Avaya Remote Service Center. The customer is responsible for resolving all warning alarms. The alarm log is accessible to the vm, sa, and craft logins.

• Maintenance log

The maintenance log records error occurrences, error resolutions, and informational events that can help Professional Services troubleshoot an alarm. The maintenance log is accessible to the vm, sa, and craft logins.

Alarms

Errors found by the system are recorded in the maintenance log. The messaging 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 system also send alarms to the Communication Manager server alarm log.

The contents in the messaging alarm log represent all the significant problems the system detects. Therefore, the Alarm Log is a good starting point for troubleshooting the system. However, you might also wish to use the Communication Manager server Alarm Log, which lists all alarms on the Communication Manager server, including messaging alarms. This log is available from the Server (Maintenance) Web page through the option Current Alarms. For details see the online Help system available from the Server (Maintenance) Web page, or the maintenance documentation on the Communication Manager documentation that can be downloaded from Avaya Support Site.

 

The messaging alarm log contains two types of entries:

• Active alarms

An active alarm indicates a current problem in the system.

• Resolved alarms

Resolved alarms have been corrected either automatically or through a repair procedure.

Three alarm levels indicate the severity of an alarm:

• Major Alarms

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

Minor alarms indicate problems that could affect full service but are not critical to system operation. For example, if a network connection occurs, a minor alarm is generated. Minor alarms are repairable by technicians.

• Warning alarms

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 Resolution

If the customer purchases a maintenance service contract and activates the alarm origination feature, 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.

Alarm Notification

Viewing the administrator's log and the alarm log on a daily basis, either from the messaging administration screens or from the alarm log on the Communication Manager server, 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 line.

The STATUS line can display multiple levels of alarms. The alarm level is important because it classifies problems within the system so that the most severe problems 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).

Remote Service Center

The Remote Service Center plays a key role in maintaining and troubleshooting the system. The Remote Service Center connects to the messaging software through an external modem connected to the Communication Manager server's USB port to perform administration and Linux commands on the system.

Database Audits

During normal operation, messaging 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 the messaging 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
   

Note: These audits can also be run on demand.

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.

Switch Integration Software Audits

The switch integration software in the system is part of a layer that is accessible to all the software applications. Therefore, the software maintains its own database of subscribers to execute the switch-related requests from the applications. Subscribers are added to the switch integration database automatically after being added to an application, such as messaging.

Because the switch integration software maintains its own database, it must be synchronized periodically with the other application databases. This synchronization is accomplished through several audits.

Security

The system is designed to be very secure. The following is a list of some of the security features:

Subscriber Passwords

Passwords protect all messaging mailboxes. The system offers password aging and password timeout mechanisms that can help restrict unauthorized subscribers.

Subscriber passwords must comply with the following guidelines:

• Passwords can be from 5 to 15 digits in length, although the system administrator can specify a minimum required length.
• A password cannot:
• Be the same number as the extension (for example, extension 34555 cannot use password 34555).
• Contain repeated digits (for example, 77777).
• Be consecutive digits (for example, 12345).

The system administrator can administer the system to age subscriber passwords, at which time subscribers must select a new password.

Callers are given three attempts per call to enter their mailbox correctly before they are automatically disconnected. An administrator can also specify how many consecutive invalid attempts are allowed before a voice mailbox is locked.

Administrative Logins and Passwords

You can create role based user logins. Each login has its own unique password and provides varying levels of access to the features and capabilities of the system. This layered approach limits access to particularly powerful features and is convenient when delegating system administrator responsibilities.

All the subscriber password compliance guidelines apply, including password aging, for both the system administrator (sa) and voice mail (vm) logins.

Disallows Voice Mail PINS Related to Mailbox Number

For example, a PIN of 4567 or 7654 is not allowed for a mailbox with number 123-4567. The smaller (fewer digits) of the mailbox number and the PIN cannot be a subset of the larger of the mailbox number and the PIN number. This applies to both the PIN number and to the sequence of digits obtained by reversing the order of the PIN digits.

Aging of Voice Mail PINs

Once a PIN has exceeded its maximum allowable age, it is no longer valid. If a PIN becomes invalid due to aging while a validated session is in progress the session is not affected.

Enabling Aging of Voice Mail PINs and Configuring Voice Mail PINs

You can enable or disable aging of voice mail PINs from the Administrative web pages. By default, the aging of voice mail PIN is enabled. This applies to all the voice mails.

You can configure the maximum age of a voice mail PIN. The maximum administrable range is from 1 to 999 days. However, the default maximum age of a voice mail PIN is 90 days.

Locking of Voice Mail After Invalid PIN Attempts

A subscriber's voice mail account is locked after the number of failed PIN attempts exceed the number set for failed attempts. An user with administrator privileges can enable the voice mail. You can also configure the number of failed attempts from the administrative web pages.

Allowed Invalid PIN Attempts in a Single TUI session

Only 3 invalid PIN attempts are allowed in a single TUI session.

Aggregation of Invalid PIN Attempts Across Interfaces

For instance, if the limit is 3 and 2 failed attempts are made while using TUI and one while using IMAP4, the mail is locked

Enhanced Call Transfer

With Enhanced Call Transfer, the system verifies that the requested destination is a valid extension in the dial plan. The system verifies that the entered digits contain the same number of digits as are administered on the messaging software for extension lengths. When callers request a name addressing transfer, the name must match the name of a messaging subscriber (either local or remote) whose extension number is in the dial plan.

Call transfers are subject to control by the customer system administrator. This administrative control is designed to encompass all of the numbers to which a caller can transfer.

Controlling Call Transfers by Using Allowed and Denied Numbers

To transfer to another extension, the subscriber presses * T, the digits of the extension to which he or she wants to transfer, and #. The system administrator can administer the messaging software to permit transfers to only certain allowed numbers or ranges of numbers. For example, the system administrator can administer the system to forbid call transfer to extensions that begin with 9, if dialing this number results in access to an outside line. See Creating Restricted Number Lists for additional information on establishing dialing restrictions.

If a caller enters an extension that is an allowed transfer, the switch completes the transfer, disconnects the messaging software, and sends a "disconnect - successful transfer" message to the system. If the number is not valid, the switch leaves the system connected to the caller and sends a "fail" message to the messaging software. Then the system plays an error message to the caller and prompts for further activity.

Controlling Call Transfers Using "Subscribers versus Digits"

Allowing * T transfers increases the risk of toll fraud. If the customer decides to allow * T transfers, the system can be set to allow transfers by either subscribers or digits.

• Transfer by subscriber. In a system administered to allow transfer by subscriber, callers can transfer only to an administered messaging subscriber.
• Transfer by digits. In a system administered to allow transfer by digits, the destination telephone number must correspond to a pattern administered in the Allowed and Denied Numbers menus. It must also have the same number of digits as extension numbers within the messaging software.

Restricting call transfers to administered subscribers is the more secure of the two options. Fraudulent use of call transfer is virtually eliminated when the messaging software verifies that the specified destination is an administered number and denied numbers are administered carefully to include such things as a phantom mailbox that begins with 9. However, you must also consider that if digits are specified, the caller might find a way to access the switch and to use switch features and functions to complete fraudulent long distance calls.

Switch Administration

The current messaging documentation set includes detailed instructions on how to administer switches to prevent toll fraud. For more information, see Switch Administration Tasks Checklist and the switch integration book for the specific switch at the customer's site.

Outcalling

Toll fraud can be minimized when outcalling to messaging subscribers who are off-site and often have their message notification forwarded to a call pager. To do so, the outcalling:

• Ports can be assigned to a toll restricted Class of Restriction (COR) that allows calling only within a local area.
• Numbers can be entered into an unrestricted calling list for either ARS or Toll Analysis.
• Numbers can be limited to 7 or 10 digits to restrict outcalling to, for example, international extensions.

Scheduled Backups

The nightly scheduled backup that the messaging software 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 needs to complete seven backups (one for each night of the week). Depending on the needs of the business, these backups can be archived for a longer length of time or can be swapped out weekly. This process ensures that the previous day's messaging and system information is available at any time. However, it is the customer's responsibility to manage the data storage on their FTP backup server.

 

Scheduled backups do not always store voice data. In the event of a system failure, all voice messages are lost unless you have also performed a Backup Now.

Top of page