The Cisco Unity Message Repository (UMR), built into Cisco Unity 3.x and later, allows outside callers to leave messages for users when their primary Exchange server is offline. Messages are temporarily stored on the Cisco Unity server in the \CommServer\unityMta directory and can be accessed through a special UMR conversation. When the primary Exchange server comes back online, Cisco Unity begins to pass the messages as normal into the correct message store.
Readers of this document should have a general understanding of how Cisco Unity works. For further information, refer to White Paper: Cisco Unity Data Architecture and How Cisco Unity Works (Version 3.x) Overview.
The information in this document is based on these 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.
The UMR feature allows Cisco Unity to take outside caller messages while there is a problem with an Exchange server. UMR handles changes depending on which Exchange server goes offline:
If Cisco Unity's primary Exchange server goes offline, all subscribers hear the UMR conversation.
If an Exchange server with off-server subscribers goes offline, only those subscribers with mailboxes on the off-line Exchange server hear the UMR conversation, while subscribers on other servers have regular message access.
Note: Subscribers that have regular access, those not affected by an outage, can leave a message for a subscriber whose Exchange server is offline by calling voicemail, logging in, and pressing #2. However, these messages are handled exclusively by Exchange and not the UMR. Therefore, subscribers are not able to access these messages until Exchange comes back online.
If a subscriber calls into Cisco Unity while an Exchange server is offline and they hear the UMR conversation, they are only able to listen to outside caller messages that they have received during the server outage. These messages are stored temporarily on the Cisco Unity server in the \CommServer\UnityMTA directory and not Exchange, therefore, only messages in the temporary area are accessible while the user's primary Exchange server is offline. The user hears the message and a timestamp but is not able to delete, reply to, forward, or leave messages for other subscribers. Since Exchange is offline, subscribers are not able to access any messages that existed on the Exchange server before the outage.
While Exchange is offline, if a subscriber directly dials another subscriber's extension and is then forwarded to Cisco Unity, Cisco Unity handles this call the same as an outside caller. Once forwarded to Cisco Unity, subscribers are able to leave messages for other subscribers, but these messages are only available in the UMR. These messages are not identified as subscriber-to-subscriber messages, and there is not an option to reply to the message, even after Exchange comes back online and the message is in the regular voice mailbox. Depending on the phone system and its integration after the outage, these calls may have the subscriber's extension as the caller ID information in the subject line when viewed in ViewMail for Outlook (VMO).
Cisco Unity quickly detects when a server goes down but takes longer to determine when a server comes back online. This is partly due to the Exchange services having long startup times, which delay the server from coming back online. During this in-between time, subscribers may hear the failsafe conversation instead of the UMR conversation, or the regular conversation when they call Cisco Unity (noted in Cisco bug ID CSCdu13936 (registered customers only) ). Similarly, subscribers may hear the failsafe conversation if they are listening to a message in the UMR as their Exchange server comes back online (noted in Cisco bug ID CSCdu25943 (registered customers only) ). Subscribers have to wait until Cisco Unity can access their regular mailbox before hearing the regular conversation. Also, since there may be a backlog of messages in the UMR, Cisco Unity may take several minutes to move the messages from the local UMR to the appropriate Exchange server, even though subscribers can call in and get the regular conversation.
When Cisco Unity moves messages from the UMR to the Exchange server, all messages show up as new even if they were listened to using the UMR conversation, and trigger Message Waiting Indicators (MWIs). Messages contain a new timestamp with the time they were delivered by Exchange. This can result in a message having two different timestamps; one while it's in the UMR and another one after delivery by Exchange (noted in Bug ID CSCdu04991 (registered customers only) )
MWIs may not correctly indicate message status when Exchange is offline. MWIs may be lit from messages that arrived while the Exchange server was up, however, with Exchange down, subscribers are not able to access them. Also, Cisco Unity does not light MWIs for messages that arrived during an outage and are in the UMR. Subscribers must call in and check to see if they have messages waiting for them.
The number of UMR messages that Cisco Unity handles during an Exchange outage is limited by available hard disk space. Specifically, the space available in the C:\Commserver\UnityMTA directory. This directory is controlled by a registry setting, which can be found here:
During an Exchange outage messages to distribution lists, such as the Unaddressed Messages distribution list, appear in the UMR but are addressed to the distribution list and not to the members of the distribution list, since lists are not expanded while in the UMR. Therefore, subscribers are not able to access them until they are expanded and delivered by Exchange.
Before Cisco Unity delivers messages from the UMR, the Exchange server that the messages are destined for must be back online and ready to receive messages. There are times when messages may continue to accumulate in the UMR, even after all of the Exchange-related issues appear to be worked out.
If administrators notice that messages are not being delivered from the local UMR directory, usually C:\Commserver\UnityMTA, even after the Exchange servers are all back online, troubleshoot the problem by restarting the UMR service to trigger the message delivery. This is accomplished by accessing AvUMRSyncSvr from the Services Control Panel. The UMR message delivery may take about three minutes to start after the server comes back online.
Check the Event Log for messages that confirm the Exchange server is back online. You should see messages listed in the Windows Event Viewer similar to the two examples shown below. If these messages are not in the Event Log, there are still problems with the Exchange server that are preventing Cisco Unity from sending messages to it.
Event Type: Information
Event Source: AvWM_MC
Event Category: Warning
Event ID: 29002
Description: MCH-UNITY has come back online
Event Type: Warning Event Source: AvExchangeMonitor_MC
Event Category: Run Event ID: 1020 Computer: MCH-UNITY
Description: Server MCH-UNITY is back on-line. Resyncing mailboxes.
If there is an invalid message file or a message for a subscriber with an invalid account (for example, an invalid homeserver in SQL) in the UMR, it blocks delivery of all other messages. The AvUMRSyncSvr service delivers messages in first-in, first-out (FIFO) order. If the recipient of an earlier message has an invalid configuration, or the home server is online but is not accepting messages, the remaining messages are not delivered. Outlook is useful to use in checking to see if a subscriber's address is configured properly. If an Outlook message cannot be delivered to the subscriber, then the UMR is not able to deliver the message either. Either remove the message from the UMR, or correct the problem with the subscriber's account.
For messages that are delivered from the UMR but are not appearing in subscribers' voice mailboxes, use Exchange's Message Transfer Agent (MTA) tools to check for messages that are stuck in Exchange's queue. The steps below explain how to use the MTA tools for Exchange 2000 and Exchange 5.5.
Use this procedure to use the MTA tool for Exchange 2000:
Start the System Manager by selecting Start > Programs > Microsoft Exchange > System Manager.
From the Console tree, double-click Server.
Right-click on a server of your choosing and select Properties.
From the General tab, select Enable message tracking to log information about the sender, the time the message was sent or received, message size, priority, and recipients.
From the General tab, select Enable subject logging to record the subject of any message sent to, from, or through the server.
Note: This is only available for Exchange 2000 servers.
Use this procedure to track messages on Exchange 2000:
Open the Exchange System Manager.
From the Console tree, double-click Tools and select Message Tracking Center.
Right click in the right pane and then click Track Message.
Use the Search tool to help diagnose messaging problems and find any messages that Cisco Unity may have sent to Exchange but Exchange was unable to deliver. Once you find a message, get more information about the message by clicking the Details and Message History buttons.
Use this procedure to use the MTA tool for Exchange 5.5:
Start the Exchange Administrator by selecting Start > Programs > Exchange > Microsoft Exchange Administrator.
From the Console tree, double-click the site which contains the Cisco Unity server.
Click on the server where you want to monitor messages.
From the right side of the window, double-click Message Transfer Agent and click the Queues tab.
The Message Transfer Agent properties page lists all of the messages waiting in Exchange's queue. Look for messages that Cisco Unity has sent to Exchange but Exchange has not delivered.
You may notice that messages are getting delivered to the "unaddressedmessages" alias. This happens when either the message is addressed to an alias that no longer exists, or has an invalid configuration. Use Outlook and Exchange tools to troubleshoot any problematic address within Exchange and to determine the root cause.
For most UMR issues, especially if the UMR is not delivering messages from the local UMR directory, usually C:\Commserver\UnityMTA, and even after the Exchange servers are all back online, restart the UMR service to trigger the message delivery. This can be accomplished by accessing AvUMRSyncSvr from the Services Control Panel. Cisco Unity and Exchange may delay up to five minutes before message delivery from the UMR begins.
As the Exchange server comes back online and Cisco Unity resynchronizes with the server, subscribers may hear a failsafe conversation instead of either the UMR or the regular conversation when calling into Cisco Unity (noted in Cisco bug ID CSCdu13936 (registered customers only) ). Subscribers may hear the failsafe conversation if they are listening to a message in the UMR as their Exchange server comes back online (noted in Cisco bug ID CSCdu25943 (registered customers only) ). The subscriber must wait until Cisco Unity is able to access their message store again in order to hear the regular conversation.