Document ID: 22432
This document identifies Cisco Unity troubleshooting steps for subscribers who experience delays logging in, retrieving, forwarding, and deleting messages over the Telephone User Interface (TUI). These delays may be intermittent or consistent, and may apply to one or more users. Delays in the subscriber conversation can persist for a few seconds or for a significant amount of time, and may impact the functionality of the Cisco Unity system.
This document assumes that Cisco Unity has a partner server (also known as the mailstore or home server) located on a different server than the Unity installation. This document contains information on Microsoft Exchange versions 5.5, 2000 and 2003.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Some or all Cisco Unity subscribers experience delays when logging into their mailbox, or while retrieving, forwarding, or deleting messages over the TUI. This problem may happen in any version of Cisco Unity where the mailstore is located apart from the Unity server (common in Unity versions 3.0(x) or greater).
For further information on "Network Considerations" when deploying Cisco Unity, see this chapter of the Cisco Unity Design Guide. The steps included verify common configurations between Cisco Unity and the Microsoft Exchange partner server.
If there is any delay answering a call in Cisco Unity (for instance, no prompts are heard at all or only ringtone is heard), check these documents for verification of the Unity telephony integration:
The "CallManager Leaves Voice Mail Ports in a Transfer State, Ports are Busied Out—CSCdw94340, CSCdw70477, CSCdw36431, CSCdw19730, CSCdw47532, CSCdw55180" section of Troubleshooting Port Lock Ups in Cisco Unity
MbxSuite.exe is a utility provided with the Cisco Unity installation package to determine if delays are related to software or network performance.
This is a utility written to make the same requests Cisco Unity does to Microsoft’s Messaging Application Programmer’s Interface (MAPI). After you enter some information, MbxSuite.exe attempts a login to a mailbox.
If you do not find this utility with your current version of Cisco Unity Software (versions prior to Cisco Unity 4.0(2)), continue with the steps below regarding network settings and Exchange monitoring. If problems persist, contact Cisco Technical Support to determine if MbxSuite.exe isolates this issue for the Cisco Unity version installed.
If you experience delays while using MbxSuite.exe, it is likely the network configuration settings or Exchange performance requires further verification.
Ping can sometimes be used to reveal problems with network throughput (data transfer rate). Latency is the time it takes for a packet to reach its destination. Examine the latency while sending a large packet through ping. If it takes a long time to send a sizeable packet, you may have throughput problems.
To use ping to test network connectivity between Cisco Unity and Microsoft Exchange, for problems with latency (round trip time) and lost packets, perform these steps:
From a command prompt on the Cisco Unity server, ping the Microsoft Exchange server by entering ping <exchange> -l 1048 -n 999, where l is the send buffer size, and n is the number of echo requests to send.
Examine the ping requests and confirm that the response time stays around less than ten milliseconds (ms). If the time fluctuates, or if packets are lost, you can assume that the problem is either with bandwidth or that Microsoft Exchange is responding to the ping requests slowly.
Note: If the delay problem is intermittent, execute this procedure several times to see if your results vary. Try this procedure again during peak usage times.
If you did not notice a delay or packet loss, try sending a larger packet. From a command prompt on the Cisco Unity server, ping the Microsoft Exchange server by entering ping <exchange> –l 65500, where l is the send buffer size.
If the average round-trip time is given as a large number (for instance, more than 30 ms), this may be an indication of problems with network throughput. This test, however, may result in the ping timing out because the router is able to restrict ping packet size. If that is the case, the test does not tell you anything about throughput. Be cautious if you are going through a router because most restrict the ping packet size to around 1400 bytes.
If the ping response times fluctuate, a comparison should be made between the Cisco Unity server and Microsoft Exchange, and the Unity server and another Exchange server (or any other server on the network) that is in the same subnet as the Exchange server. From the Cisco Unity server, ping the other server by entering ping <exchange> -l 1048 -n 999.
If you observe latency or packet loss, the problem is most likely within the network. If there are no delays or packet loss, the problem is most likely with the Microsoft Exchange server.
You can also test throughput by copying a large file from the Cisco Unity server to another PC through the network, and noting the number of Mbps you are receiving. If data is not transferred at the expected rate, check the Server Network Interface Card (NIC) settings on the Cisco Unity Server, Microsoft Exchange server(s) Unity subscribers are homed to, and the switch ports where each server connects to the network. If network interface duplexing mismatches are found, correct these as described below.
To view the number of Kbps being transferred, open the network interface’s local area connection status to view the packets sent and received. Windows performance monitor counters can also provide a longer-term view of network bandwidth throughput and usage.
NICs that are set to Auto Detect Line Speed and Duplex on the Cisco Unity server (as well as any Exchange server or switch Unity connects to) can cause delays when the card is negotiating less than 100 Mbps full duplex. Set the NIC to 100 Mbps full duplex, as shown here, even if the local area connection status says 100 Mbps. You cannot rely on the local area connection status, shown in this example, to indicate the actual throughput.
To check your LAN settings, from the Windows Start menu choose Control Panel > Network and Dial Up Connections > Local Area Connection > Properties > Configure > Advanced > Link Speed and Duplex.
Note: NICs or switches set to Auto Negotiate may cause duplexing and alignment errors on the switch.
On the Ethernet switch, check the ports occupied by Cisco Unity, Microsoft Exchange, and Cisco CallManager for any errors. Switch errors may point to an issue with a NIC.
Determine whether there is a router device between Cisco Unity and Microsoft Exchange. If a router device exists, confirm that there are no errors on the ports for the router and verify the programming on the router. Determine whether trunking is enabled on the ports and what the duplex settings are. These settings should match the server’s NIC settings. If there are no errors on the device and programming is accurate, determine the priority of packet traffic going through the router. For more information, refer to Troubleshooting Switch Port and Interface Problems.
If a router device connects Cisco Unity and Microsoft Exchange, and the voice traffic is prioritized higher than Exchange traffic, two options may resolve the delay issue:
Move Cisco Unity to the same subnet as Microsoft Exchange. This takes the router out of the picture and allows Exchange (Remote Procedure Call (RPC)) traffic to flow directly between the servers without the delay caused by router prioritization.
Change the configuration of the router such that packets from the Cisco Unity server to Microsoft Exchange have equal or higher priority than voice traffic. As with any Quality of Service change, monitor utilization to determine any impact to voice quality.
These known causes of delay may result in hearing problems for a subscriber calling Cisco Unity. Additionally, some causes may be compounded by the timing of network requests and network or partner server response times.
A subscriber reports a delay after entering their password or during message retrieval, delivery, forwarding or replying.
MAPI accepts requests from Unity in a serialized manner. If a single MAPI request is delayed for any reason, subsequent requests are also delayed until the first request is completed. Reasons for the initial delay of any request through MAPI to a Microsoft Exchange server include:
Network connectivity and latency between the Cisco Unity and Microsoft Exchange server(s) or between two or more Exchange servers.
Microsoft Exchange message indexing activity.
For instance, when Exchange services count the number of messages in the inbox of a subscriber and categorize them as particular types to present to one or more client applications (for example, new versus read messages, urgent priority versus normal priority messages or voicemail, email, fax, receipt counts). For more information, see the Mailbox Index Creation Delays – CSCdy36517 description within this document.
Microsoft Exchange Performance degradation due to improper Exchange disk configuration or high utilization (for more information, refer to Microsoft Knowledge Base Article - 188676 and MS Exchange Performance Monitoring white papers).
Correct any of the above conditions that may be responsible for the increased MAPI request response time.
Upgrade to Cisco Unity 4.0(4) or later versions. With this version, simultaneous requests are made for as many Microsoft Exchange servers as exist in the environment. For example, instead of five MAPI requests sequentially queued for five different Exchange servers, a single request is sent to each of the five Exchange servers at the same time.
A subscriber reports a delay after entering their password.
When the Cisco Unity partner server is a Microsoft Exchange mailstore (versions 5.5, 2000 or 2003), the index creation process for a subscriber’s inbox may cause a delay after the subscriber enters their password.
An index of read or unread messages as well as the type of message (such as voice, email, fax, receipts) is created when the user completes their first login. The number of messages in the inbox of the subscriber affects how quickly Microsoft Exchange is capable of returning the message counts to Cisco Unity. For example, a few thousand messages in the inbox may result in a 10-15 second delay, whereas tens of thousands of messages may delay the subscriber’s request a few minutes.
If this index expires (more likely in Microsoft Exchange 5.5) or is overwritten (most likely with Exchange 2000 or 2003 due to multiple Exchange clients), the re-creation of the index causes users to experience a similar delay.
Decrease the number of messages in the inbox of the affected subscriber(s).
Upgrade to Cisco Unity 4.0(4) or later versions.
A subscriber reports a delay when replying to a message.
When the Cisco Unity partner server is a Microsoft Exchange mailstore (versions 5.5, 2000 or 2003) and a subscriber replies to a voicemail message, there is the potential for some delay between conversation prompts as the original message is copied. This results in a delay before the message recipient’s name or extension playback, or after the recorded reply message.
Upgrade to Cisco Unity 4.0(4) or later versions.
A subscriber reports a delay when forwarding a message.
When the Cisco Unity partner server is a Microsoft Exchange mailstore (versions 5.5, 2000 or 2003) and a subscriber forwards a voicemail message, there is the potential for some delay between conversation prompts as the original message is copied. This results in a delay before the message recipient’s name or extension playback.
Upgrade to Cisco Unity 3.0(5), 3.1(3), 4.0(1) or later versions.
A subscriber reports a delay when deleting a message.
When the Cisco Unity partner server is a Microsoft Exchange mailstore (versions 5.5, 2000 or 2003) and a subscriber deletes a voicemail message, there is the potential for some delay between conversation prompts as the original message is deleted.
The defect occurs when both of these conditions are present:
The Class of Service (COS) setting "Deleted messages are copied to the deleted items folder" is enabled for the subscriber who is deletes the message.
Note: The COS setting is available on the Cisco Unity Administrator | Class of Service | Messages page.
The subscriber is deleting a very large message over the TUI.
Disable the COS setting “Deleted messages are copied to the deleted items folder”.
There is no current software solution to this issue as of the latest version (Cisco Unity 4.0(4)).
If Microsoft Exchange version 5.5 is used, run Microsoft Exchange Optimizer as directed in MS KB 266051. For more information, refer to XADM: The "Understanding the Microsoft Exchange Server Performance Optimizer" .
Note: If you run Microsoft Exchange Optimizer and it does not improve response times in the subscriber conversation, or if Exchange 2000 is used, refer to 3 Basics of Exchange Server Performance .
Mailboxes with a large number of messages may experience intermittent login delays if Microsoft Exchange re-indexes the mailbox. For more information, refer to these articles:
- Voice Technology Support
- Voice and Unified Communications Product Support
- Troubleshooting Cisco IP Telephony
- Technical Support - Cisco Systems
|Updated: Apr 03, 2008||Document ID: 22432|