Cisco Support Community
Community Member

Reason for stopping Unity

We are running Unity 2.4, build I also have three Exchange 5.5 servers, one of which is running SP4, the others SP3. When Unity was installed we were advised to stop Unity should any of our servers need rebooting. Obviously this disables all voicemail during the period that the server is rebooting. We are starting to run a 24 hour operation here, and soon stopping Unity at any hour of the day is going to be difficult. Is there a legitimate reason for stopping Unity, or is it just "best practice" to do so? I need a reasonable explanation to present to our CIO.<br><br>


Re: Reason for stopping Unity

While it is, in general, a “best practice” item, there actually is a legitimate reason for wanting to take us down if you can when you’re going to be taking Exchange servers on/off line.

If you’re sure folks are not going to be calling in over the phone to check messages on that server you’re taking off line and you’re running 2.4.5 or later (as you are) then you should be OK with this. 2.4.5 will note that the Exchange server is off line within a couple minutes of it actually going off line and will detect it’s back up and reconnect when it’s available again.

If, on the other hand, there’s a chance users may be calling into Unity to check messages and their home store is one of the servers you’re taking off line, there could be a problem. In the window of time between when you take your server off line and when we realize it’s not available, if a user tries to get at their message store the MAPI thread will time out waiting for it to return (real long time out). This can “burn” the voice port they are on and it wont be recovered until you restart (it’s toasted at the Dialoigic driver level, we can’t force it to reset). This should only happen for the first caller (possibly two if they come in right at the same time) and after that we will have taken the link to that Exchange server off line and wont allow folks to attempt to check messages if they are homed on that server. We call this the “MAPI Traffic Cop” design… it keeps track of which Exchange servers it knows are off line and wont allow subscribers homed on those servers to check messages (callers hear “I’m sorry, I can’t talk to you now, please try your call again later”). When it’s back on line, it’ll allow the calls to go through again.

Unfortunately there’s no way to lock this down entirely other than ensuring no calls are coming in during this time (i.e. route calls to an operator instead of voice mail) or taking Unity off line (ports will be RNA). There’s always going to be that little window of opportunity where we don’t yet know the Exchange server is off line and a caller attempts to check messages on the box.

We've had a few Exchange crashes here and Unity's normally weathered them OK but we have lost a couple of ports for the reasons outlined above. To be clear, the rest of the ports are fine and the system continues to function fine other than those ports are RNA. Our hunt group just skips over them and routes the call to the next available port... not a big deal in our configuration. We schedule a reboot of the Unity server in the evening or early morning and it clears the ports up.

In earlier versions (i.e. 2.3.6) the behavior with external exchange servers going up and down was much worse so taking Unity off line in this scenario was really a must no matter what. More or less if you didn’t do it, we did it for you…

Don’t know if that’s what your CIO is looking for or not. If this doesn’t make sense, let me know and I’ll take another run at it.

Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems (new page for Unity support tools and scripts)

CreatePlease to create content