Troubleshooting

Subscriber Access message inventory is slow

The more messages there are in the subscriber's inbox, and the larger they are, the slower the message inventory process will be. Suggest that subscribers delete messages or save them locally on their PC.

Inventory functions will be slow during a broadcast message distribution (Messaging Server CPU limitation).

Any CPU intensive operations on any service used by the subscriber's uOne session will also slow down functions (CPU limitation).

Message delivered late or not at all

Step 1 Was the message a broadcast message? If so, the MWI notification will occur. When another message is delivered turning on the MWI indicator, the earlier broadcast message may appear as if it were delayed.

Step 2 Check the time of day on different servers. Their time of day clocks may be out of synch, giving a false delivery times.

Step 3 Gather details to analyze log files. Ask the subscriber:

• How do you know the message was sent?
• Who sent it?
• When was it sent?

During Caller Access, caller does not hear called subscriber's greeting or spoken name

The subscriber must record and activate an All Calls greeting, or both a Busy greeting and No Answer greeting, or activate one system greeting.

The subscriber must record a spoken name

Quota exceeded

The subscriber should either delete messages or save messages locally on their PC.

The quota for an individual subscriber can be expanded through UMSA.

MWI doesn't turn on when a message is received

Step 1 Was the message a broadcast message? If so, MWI will not come on.

Step 2 See if the MWI_Notify and MWI_OnOff application agents are running on the GateServer on which they are configured. Log on to the machine that you want to check; from the command line type:

Step 3 On either the messaging server or the MWI_Notify host, use netstat to check for an established TCP connection (usually port 4077) between the MWI_Notify host and the messaging server host.

Step 4 If no connection exists, on the MWI_Notify host use netstat -a to check that the TCP port number for MWI_Notify (usually 4077) is in the LISTEN state.

Step 5 If port is in the LISTEN state, it is likely that MWI_PassOff is either not running, misconfigured, or malfunctioning. Reconfigure and/or restart MWI_PassOff.

Saved message no longer there

Check the Event Log to verify that message was actually saved, and not inadvertently deleted.

Was the message a broadcast message? Broadcast messages can deliberately expire after a period set by the sender.

MWI doesn't turn off

Step 1 Ensure that all new messages of the type and severity for which the subscriber has configured MWI notification (e.g., normal and urgent voice and fax messages) are saved or deleted. uOne requires an explicit save or delete command to move a message out of the "new" state. Have the subscriber save or delete the messages as appropriate.

Step 2 Reading such messages with an e-mail client will not turn off MWI. You must use and exit the uOne application to turn off MWI.

Blank message are received

The most common cause of blank messages is callers attempting to leave a message through a speaker phone. Due to background noise, callers often do not hear the beep indicating that uOne is recording. To verify that a "blank" message is simply background noise, examine the .wav attachment to the message that is in the subscriber's mailbox.

Calls are not answered

The CMA agent may be down.

Step 1 Use the umcli or UCM to view the status of CMA agent

Step 2 Start CMA agent if it is down.

Subscriber hears "dead air" when dialing the access number

Step 1 If complaint is from multiple subscribers, check directory server.

Step 2 Check the CMA Sof logs to find call allocation failures.

Step 3 Disable any VoIP dial peers on your Gateway that refer to the CMA host.

Step 4 After the channels have been busied out, cycle CMA to clear all calls.

Caution: This step will impact services, and should be done only during "off" hours.

Step 5 Re-enable the disabled VoIP dial peers.

Paging not working

Step 1 Ensure that the paging server processes are running and its modem pool is functional.

Step 2 Determine:

• Has subscriber ever received pages?
• If yes, has subscriber ever received pages from uOne?
• If no to either of first two questions, which paging provider is used by the subscriber?
• When was the paging notification sent? By whom?
• Where was the subscriber when the page was sent?
• Is the subscriber at same location?
• What is the PIN?

Step 3 Dial end-user pager from a telephone and send a page. If page does not go through, end-user could be in a location that blocks pages, or the paging provider may be having problems.

Step 4 If the page from step 2 was received, try paging from uOne message notification.

Step 5 If page from step 3 was not received, call the paging provider to verify the paging information required for provisioning; update it if necessary.

Step 6 If the page is not received, then ask the paging provider technical support service for a modem dial-in number (IXO/TAP) and the required modem settings to use it. Call this number to verify that it is a modem line.

Step 7 Check the paging server configurables and modem settings; update as necessary.

Step 8 Try sending a page directly from the paging server.

Step 9 Check network connectivity between the GateServer and paging server.

Subscriber login fails

For a single subscriber:

Step 1 Use UMSA to change the subscriber's voice mail password, and/or reset the subscriber's bad login counter to zero. Ask the subscriber to log in.

For more than one subscriber:

Step 1 Test the messaging server directly to ensure that it is accessible over the network.

• Bypass the GateServer using any IMAP client (such as Netscape Communicator) to log in with a subscriber's e-mail login and password.
• Ensure that the messaging server processes (e.g., imapd) are running.
• If necessary, restart the messaging server processes.

Step 2 Test the directory server directly to ensure that it is accessible over the network.

• Bypass the GateServer using any LDAP search tool, such as those provided in Netscape Communicator.
• Ensure that the directory server processes (e.g., ns_slapd) are running on the directory server.
• If necessary, restart the directory server processes.

UM gives upper-level menu all the time

Step 1 Test from a phone known to give the correct menu.

Step 2 Ensure that SMSI Expected is set to Yes in the UM.ini file of each GateServer.

Step 3 Use watch h323 states to view the caller information for all calls.

An attempt to send a fax to a mailbox fails

Ensure that the on ramp MM.IP fax Gateway is configured properly and that the subscriber has a proper inbound fax number alias.

Server agents won't start up after a failure

There may be no more space free in the /home2 file system.

Step 1 Remove the log files in stderrout.

Step 2 Remove Sof log files.

Step 3 Ensure that the LogRemover application is configured properly.

Subscriber Access inventory says "no new messages" when MWI is on

Message may have been marked as "read" on PC when the subscriber checked e-mail. uOne will treat this as a "saved" message and add it to the Saved Messages list. Exit uOne to turn off the MWI.

a hardware problem.

Check for failed components on all machines in your system configuration.

Check all physical connections, e.g., power and data cables.

a network problem.

Do spot checks, e.g., test name service, ping network nodes, send e-mail, telnet to ports.

a software problem.

• Check for operating system errors.

• Check for errors in 3rd party software (Netscape Directory Server, Netscape Messaging Server, Tcl, Paging Server.

• On the Messaging and Directory servers, check the syslog file for any errors. This file may be large on an Messaging host with MWI errors.

• Check for errors in Cisco software (all agents, the UM, MWI_Notify, MWI_OnOff, FaxPrint, LogRemover, and MWI_PassOff processes, and the MWI_PlugIn, notifier, RA_Link plugin libraries). To do so, use your SNMP Manager to view the SNMP trap messages. View the log files.

• Check the configuration files on the GateServer(s).

• Run the following command on the GateServer(s):
  umcli
  watch acb entries
  Report any UM processes running longer than 2 hours.

• Run the following command on the GateServer(s):
  ls -l /home2/spmaster | grep core.  Report any core files.

• Check  root and spmaster mail on the GateServer(s). Ensure that no items exist in the root or spmaster dead_letter file.

• Use the umcli watch command to view the real-time status of uOne resources.

• Use vmstat, mpstat, tostat, top, and df to view operating system resources.

The symptoms that you observed. Please be precise.

Which processes are down (server agents, application agents, Messaging and Directory servers, etc.).

Messages from the Sof log files for the last week (especially the E- messages).

Messages from the Eve log files for the last week.

Messages from the stderrout files for the last week.

Messages from the  OS log files (e.g., /var/adm/messages) for the last week.

Messages from the Messaging and Directory server log files for the last week.

SNMP trap messages.

The last successful action for the most recent UM session before that session stopped.

Copies of all core files from the last week.