We have a client who has a Unity set up with approximately 700 Users. The Unity is actually part of an Exchange Resource Domain. The Users are homed on about 9 different Exchange servers. Today two Exchange servers were down. The Unity continued to take messages, but they could not access the messages at all (we understand the reason. BUT, is it normal that Users who are NOT on the downed exchange servers to experience outages, (accessing mail, and long delays retrieving) Is there any maintenance procedure we should perform once the downed servers are back up?<br>Any insight ? <br><br>
Ideally you are correct Unity subscribers homed on other servers in the site that are still up should still be able to get in and snag their messages while other servers are off line. Unity 2.4.5 does a reasonable job of this using a MAPI Traffic Cop model that keeps track of which servers are up/down and will not allow subscriber to try and connect to their mailstore on a box we know is down the reason for this is the MAPI threading model in SP3 and earlier leaves a bit to be desired and more or less all the users on the box at any given time are sharing the same thread. If one subscriber gets stuck trying to get their messages, it chews up the thread for everyone else on the box regardless of which Exchange server theyre on. The really bad part is Exchange has a time out of somewhere around 10 minutes for the attempt to access the mailbox to fail and return control to us ugly.
Outside callers have their own MAPI thread such that we can always process calls and take messages regardless of if any or all of the other Exchange servers in the site are up or down since outside callers never log into their mailbox, this thread is always cool. The MTA on our local box queues these messages up and will get them to the appropriate home store when they're back in action.
Naturally there is a small window where subscribers can slip in to get their messages before we know the exchange server theyre homed on is down (we arent polling every second thatd be a pretty bit hit). Problem. In this case we will kill that thread and start a new one after we realize its hosed, however this timeout could still be a few minutes which will back up everything for all users behind that guy.
All in all, kind of a pain. One of the reasons we require SP4 for the upcoming 2.4.6 release of Unity is to resolve just this problem. As you noted in another post out here, Microsoft suggested you upgrade to SP4 theyve cleaned up some of their MAPI threading stuff such that we can now have a separate MAPI thread for each user in the system without it having a resource lockup situation. In this case only the one subscriber can slip in under the radar and get stuck trying to check for messages on a down system it will not affect the other callers in the system. As such if theyre homed on servers that are still up, they should have unrestricted access to their messages.
In short, 2.4.6 with SP4 on the box should completely resolve this issue (finally!).
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...