First and foremost, I'm by no means an Exchange admin/guru. Lately we've been experiencing some peculiarities with our Unity/Exchange email environment I'm hoping someone out there has run into before...<br><br>Environment:<br>- Unity 2.4 Build 188.8.131.52<br>- Call Manager 3.1.2(c) integration<br>- Exchange 5.5<br>- Unified messaging not yet enabled (to prevent vmail messages from appearing in user's Outlook, duplicate hidden mailboxes exist on Unity servers solely for vmail msgs)<br><br>Last weekend, our organization made the bold move of migrating from the traditional NT domain environment to a Win2K active directory environment. Although the following Monday was a rather painful day, everything seems to have settled down, so we thought. What we've been noticing lately is with SOME users, vmail delivery can talk up to 2-3hr before a message is delivered. It's not a MWI issue. To test, we left a vmail message with the particular user experiencing the delays. The user checked his messages, despite no MWI, and he did not receive it till several hours later. After further troubleshooting, we noticed emails as well as vmails are starting to queue up on the Unity servers-- +500 messages last night. We verified network connectivity, the Exchange admin verified the configurations and Exchange connectivity among all the servers via rpc-pings. We're stumped.<br><br>Strange thing we noticed was, when the Unity server is rebooted, messages start sending--as if it briefly re-establishes it connection to the Exchange mail environment--but eventually hoses up and begins queuing the messages.<br><br>
What you're describing is a classic example of an Exchange MTA failure. Just so you understand how Unity works let me explain a couple things.
When an outside caller leaves a message; Unity logs in via MAPI and sends the message from the Unity Messaging System mailbox. That mailbox in homed on the Exchange server that resides on the Unity server. At this point Unity has worked correctly and now its the job of Exchange to deliver the message. For that message to get to the other Exchange server it must be transferred by the Exchange MTA. If the MTA is down Exchange will queue the message. Often reboots clear the Exchange MTA.
You might also notice that users on the same Exchange server can send messages back and forth without delay. This is because Unity realized they are a system subscriber when they are leaving the message and logs in to their mailbox via MAPI to send the message as them to the other Subscriber that is on the same Exchange server. Since both mailboxes are on the same Exchange server the message never has to cross the MTA.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...