We are running Unity 2.4, build 126.96.36.199. 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>
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 youre going to be taking Exchange servers on/off line.
If youre sure folks are not going to be calling in over the phone to check messages on that server youre taking off line and youre 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 its back up and reconnect when its available again.
If, on the other hand, theres a chance users may be calling into Unity to check messages and their home store is one of the servers youre 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 its 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 (its toasted at the Dialoigic driver level, we cant 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 Im sorry, I cant talk to you now, please try your call again later). When its back on line, itll allow the calls to go through again.
Unfortunately theres 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). Theres always going to be that little window of opportunity where we dont 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 didnt do it, we did it for you
Dont know if thats what your CIO is looking for or not. If this doesnt make sense, let me know and Ill take another run at it.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.