I have a customer on Unity 2.4.6 where there are 2<br>exchange servers in the site. The non-unity exchange<br>server is the mail store for the company.<br>The company in question, lets call them TWG, was just<br>purchased. The new parent company wants to separate<br>the Unity from the other exchange server and use that<br>exchanger server in a new exchange server org. They<br>want to maintain the Unity VM as stand-alone for a<br>week. Then they want me to rebuild the Unity from<br>scratch into the new org.<br><br>I need to separate the two servers and keep unity<br>running.<br><br>Is there a way to do this?<br><br>Stage 1:<br>I need to break up the site and have the unity users<br>mail stores recreated on the unity server. Ideally i<br>would like not to have to recreate the entire unity<br>server. <br>The current unity server is a CDC. (NT4)<br><br>Stage 2:<br>I need to save all the Unity config, blow away NT and<br>rebuild it as a member server in the new domain and<br>rebuild unity into the new exchange org and then<br>reload the config.<br><br>Can you help?<br>Thanks<br><br><br>
So in stage one youll have TWO accounts for everyone one on the Unity server (their voice mail account) and one on the corporate Exchange server (their email account)? Why does this have to be done in two steps? It seems like a lot more work than it has to be
Unless Im misunderstanding the scenario here (totally possible) I would suggest exporting all the Unity 2.4.6 data off the Unity server using the Export utility found on the 2.x page of AnswerMonkey.net. then blow away your server, install it into the new organization/domain, install Unity 2.4.6 and run the companion import utility. This will save all your greetings, voice names, notification devices, audio text applications etc basically everything except your routing rules and subscriber passwords (see the help file or the web page for more details on how this works).
Sounds like you need to reuse the same hardware here, right? Thatll make this an all day operation if you could use a different platform you could get all the NT and Exchange fun out of the way, install Unity, do the export off the original box and import onto the new box all without any down time at all. If you have to use the same platform, Id budget a weekend for this.
How many users are we talking about? If its less than, say, 200 the import will take a couple hours by itself (depending on greetings and the like). If its more like 1,000 itll take a while longer (its no linear).
If Im misunderstanding your scenario, let me know
I do not have a choice in the time frames - The company that I am doing this for set the schedule.
So I have Server A, this is the Unity box and then I have Server B, this is the Exchange box. All the users reside on Server B. So, for example, if Server B went down, Unity would still answer calls and store the messages, but not deliver them. I need a way to seperate Server A and Server B and then allow Server A (Unity) to function standalone (for a week) until they have rebuilt there new Exchange environment. This means that i need to create a mailstore for each Unity user on Server A. 1) Is this possible? 2) If so, how?
After it is rebuilt then I can follow your steps above and export and imoport. (Which I will do)
But the first step is my biggest concerne right now. IS there a way to seperate the two servers and have Unity function in standalone mode with out having to recreate the entire Unity server?
Unity uses those messages boxes as it's message store. There is no priavate message store that then synchs it's messages over to Exchange (in 3.x there is a temporary repository on the local hard drive where we'll hold messages if we can't communicate to Exchange).
As such, you must create mailboxes on the local Unity server in this scenario for each subscriber. There's no way to get around that.
The absolute best method for this is to do this all in one step in one shot. There's no clean and easy way to create temporary secondary email accounts on the local Unity server for a week and then do the rebuild.
If you want to do some throw-away manual work you can create seperate email accounts for each subscriber on the local Unity server's exchange and then use the "move subscrber info" tool on the 2.x tools page of AnswerMonkey. This will move all their greetings, voice names, notification devices etc... from the Exchange accounts on the corporate Exchange server onto the new accounts you created on the local Unity server. This is about as good as it gets for this scenario I think.
It'll give you an idea of what the tool looks like and does.
No, it does not delete the mail user you're moving the information from, it only remove the Unity properties off that user and applies them to the mailbox you select. Basically you have a list of your Unity subscribers on the left and non subscriber mail users on the right and you click on a user on the left and one on the right and hit the "move" button. This takes a few seconds to move the data. You need to select the pair one at a time, however, since there's no easy and safe way for me to assume which mail accounts you want to move data from/to in this scenario. It goes pretty quickly the way I have it setup... I've had sites move a couple hundred users in an afternoon this way.
You don't need to remove the Unity server from the network at all for this. Just create the new accounts in Exchange for everyone on the Unity box (presumably you'll want a naming convetnion like VM so it'll be easy to match them up in the lists in my tool). Move the data and you're done. When you're ready to take the other Exchange server off line or move it or whatever, you can since all the Unity subscribers will now be on the local Exchange box.
You can't remove the Exchange box until AFTER you've moved the data. I do this directly in Exchange (remember, we use Exchange for our mail store AND our directory). So if you yanked the corporate Exchange server off line before moving the subscriber data off those accounts, I couldn't get at it. So do this AFTER you move the data.
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.