Hello Everyone<br><br>Is there a way to move a currently install Unity server to another exchange server in the same site. <br><br>Initially I install Unity on the server that hosts my mailboxes and now realize that that was a bad idea. <br><br>Any other suggestions would be welcomed.<br><br>
The only officially supported way to do this is to uninstall Unity from the server its on now (which will remove our custom properties and objects from the directory) and reinstall on the other server you want it to be on. This would, of course, involve importing all the Exchange users again on the new box and recreating your audio text applications.
Not ideal, but its safe and it works every time and its how weve tested just such a scenario.
Another method thats a little faster (though again, support will give you complimentary dial tone if you call with a problem doing this) is to run Unity setup on another server in the Exchange site that you want to home it on. During setup instead of choosing Create New Location select Choose an Existing Location. When you do this itll show you a list of all primary location objects in the directory (which should only be one in your case). Pick that and do the setup as normal. This will cause us not to create new default objects and the like, instead well use those already in the directory. As such youll have all your mail users and call handlers etc accessible on the SA and available when you call into that box.
Of course youd have to reconfigure your switch settings, any special routing rules youve made and the like on the new box, but everything else should be cool EXCEPT all the greetings for call handlers and subscribers are stored on the original box. These are much too large to stuff into the directory, obviously, so we store them on the local hard drive. Unfortunately theres no easy way in 2.4.0 or earlier to just grab them and haul them over to the new box. In 2.4.5 this should be possible but not on the current versions out there.
As such youll have to have subscribers rerecord their greetings (their voice names are in the directory already) and youll have to copy greetings for your call handlers off the SA on the original box and paste them in on the SA of the new box. Once youve done that you can retire the original Unity box.
Kind of a pain I realize, but I am working on a call handler import/export utility that handles greetings and links and the like for at least grabbing all your audio text configuration and greetings etc and getting them onto a new box (among other things). Itll be available on my web page soon stay tuned.
Youll want to try this out in a test environment first, obviously be safe. In 2.4.5 this will be a little easier since we revamped how greetings are dealt with so this should be pretty easy.
As a follow up to this question as I have a customer asking the same questions
Does this mean then two Unity systems could run, answer calls, and send receive messages from the same message store? Would this not be an ok solution for a site that wanted full redundancy? (I know not supported!)
A site wants to reinstall Unity on to a new Server, Exchange message store not changing. They want users to access old system till new one is up and running and tested. Could they use this method for a few weeks accessing the same Exchange message store, till the new Unity Server was configured the way they want. Then they can remove the old Unity/Exchange server.
OK lets see if I can make this understandable in two pages or less
Short answer: yes, if your mail users are home on Exchange servers off the Unity box, both Unity servers in a site can have access to the same subscribers. This gets you mighty close to a truly redundant setup, with one exception:
The greetings wont be synced up between the two boxes. This would mean every time a subscriber changed their greeting or you changed a greeting on a call handler, youd have to manually sync that over to the new box. Not real practical.
Understanding why is important. Currently (i.e. in Unity 2.4.0 or earlier) we store the greetings on the hard drive of the Unity server and we reference it using a path that includes the machine name of that server (a UNC in other words). So if you had two boxes installed in the same site that were installed into the same location (as described earlier in this thread) when a call comes in on the primary box (i.e. the one you recorded the greetings on) everything is fine. If, however, the call comes in on the secondary box, we actually cruise across the network, drag the greeting off the primary box across the network and play it that way.
Which isnt so bad (aside from the totally unnecessary network hit) other than the fact that if the primary box goes down (the whole reason you want a redundant configuration in the first place) you have no greeting. Not good. Youd have to manually record all the greetings on the second box to be sure outside callers didnt hear silence or the fail safe conversation (i.e. Im sorry, I cant talk to you right now ) when the primary box went down.
In general a pretty bad idea as a fail-over configuration.
However, with 2.4.5 (releasing in mere weeks I'm told) weve changed the greeting reference to only look in the local greetings directory. As such you can have the two Unity servers setup such that their respective greeting directories synchronize with one another (leveraging NT for this) and you can effectively have a fail over config that works reasonably well. Voice names and all other handler and mail user data is stored in the Exchange directory so changes made to them on either box are available to the other box. Theres only a couple of hoops you need to jump through (other than setting up the directory replication). Obviously you need to configure the switch integration on both boxes, setup your routing rules (which are stored in the local registry, not the Exchange directory) and you need to be sure to disable MWIs and notifications on one of the boxes since both will try to dialout since both are monitoring everyones inbox. The details of this will be in the README file on the 2.4.5 CD.
In regards to your second question, yes indeed, you can leave the original server around when youre replacing it for a period of time and then just retire it off the network when youre satisfied that everything is cool. This is, in fact, what we just did at a site this week. They installed the new Unity server into the same Exchange site and during setup they chose to become a member of the existing Unity location. Since all their users were homed on other Exchange servers in the site, all they needed to do was configure their switch integration, a couple routing rules they had modified and port over their opening greeting and a few other handler greetings. They used one of the scripts off my web page to set everyone back to first time enrollment and over the next week or so theyll make sure everyone has recorded their greeting and then remove the original Unity server. Very cool. Once 2.4.5 is out this will be even slicker since you can just copy the greetings directory from the old box to the new one and youre done. No fuss, no muss.
If youre interested in at least getting your call handler greetings over to a new box (or all your call handler definitions in their entirety) on versions prior to 2.4.5, I am working on finishing up testing of a call handler import/export utility that will, among other things, allow you to snag all your handler greetings off one Unity box and dump them onto another Unity server. It wont, however, handle subscriber greetings and definitions at this point one step at a time.... For retiring servers off the network this would work out fine. It should be out there within the week
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...