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
Readers of this document should have a general understanding of how
Cisco Unity works. For further information, refer to
Paper: Cisco Unity Data Architecture and How Cisco Unity Works (Version 3.x)
The information in this document is based on these software and
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
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
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
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
(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
(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
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
(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
Right-click on a server of your choosing and select
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
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
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
Use this procedure to use the MTA tool for Exchange 5.5:
Start the Exchange Administrator by selecting
Start > Programs > Exchange > Microsoft Exchange
From the Console tree, double-click the site which contains the Cisco
Click on the server where you want to monitor
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
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
(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
(registered customers only)
). The subscriber must wait until Cisco
Unity is able to access their message store again in order to hear the regular