I am in the process of migrating Unity 4.0(5) over to a new server. My customer currently has a separate Unity 4.0(5) server running and in place now. This one I am working on is a replacement Unity server. Here is my question: I have completed 3 of the 7 steps in the migration install on the new server, with the existing Unity server in place and running. Can I go through the rest of the Unity install without interrupting the existing Unity server (shutting down the Unity service) without any issue? I want to complete the install, but I want to make sure I dont interrupt the existing Unity server, OR I want to make sure I dont do anything to bring the custmer VM or UM down while Im in the process of installing.
So, will it be ok if I complete the install of the new, migrated Unity install without disrupting the existing Unity server? This will not be a failover install, this is going to be a replacement Unity server.
Also, my customer wants to know how long it will take me to complete the install Im on now (4.0(5) and Im on step 3 of 7) an appox guess?
What are you doing?
Are you staying on 4.0(5)? Just moving to new hardware? If so, you really want to use DiRT to make sure the databases "seamlessly" move to the new server hardware. Which will require a downtime, but not too long.
UM? Offbox exchange? Offbox Domino?
VM only? offbox or onbox exchange?
Time depends on the size of things and wether exchange is onbox for VM only install. How many subscribers?
The way I think you are thinking is walking a tightrope. We have bounced back and forth a couple of times between two Unity boxes when we were migrating one domain to another and joining domains of two companies that merged. We minimized downtime, but still had downtime.
What migration document were you using?
Give us some more information and we'll see if we can zero in a procedure that minimizes downtime for you.
Do you or are you an MCSE? This is the safety net for your tightrope.
I verified this in the lab. Your mileagemay vary. Sorry for the time in getting back to you.
I kept the old unity server running (and checked every once in a while) and installed a brand new Unity server (different name and IP address) into the existing AD and Exchange.
Permissions Wizard, existing Unityinstall, UnityAdmin, etc accounts, Message Store Configuration Wizard, Services Wizard all ran fine. SEEMS to be no conflicts. Oops. I can't seem to find the system mailbox for the new unity server. Hmmm. There are two unaddressed messages disti lists.
Integrated into CallManager as a second integration. Could bring up both saweb's with the same Unityadmin username and password.
Old system still works. New system works (but has no users.)
Now, I just have to re-read the DiRT documentation to see how to get the users over from the old server to the new server and see if anything breaks.
Maybe the global subscriber manager utility would work better? Not sure. Haven't used either in a couple years.
Can anyone else comment?
The way Cisco documentation wants you to do it is listed in the Unity Reconfiguration guide. I didn't follow that in my lab.
So I have more work to do that. I can't get to it for a couple of days. An interesting problem though that I will probably run across relatively soon with upcoming customer upgrades. So I will finish it.
Keep in touch. Curious to how things turn out or what path you took.
Wow, I need a lab. I have gone through 6 of the 7 steps up to this point. I didnt want to go through with the ingegration of CM yet, I didnt know what the end result would be with the old system on and the new system coming on. So, I waited. I have not done it yet, but Ill let you know how it goes afterward. Ill take down the old unity server, do step 7 of the install, do the DIRT restore on the new, then test it out. After knowing all is good, then Ill upgrade to 5.x.
Ill keep in touch on this and let you know. Thanks for the personal experience in the lab.
What document were you using? I don't think I am totally synched up to what you are doing and what you have done.
The CallManager integration piece is the low-risk piece.
Just create another set of voicemail ports and linegroup. You have have a new (temp) pilot number for testing, then just point the old pilot number to the new set of ports when ready to cut over.
ok, I went tonight to do finish the migration. I stopped the existing Unity server, then completed stop 7 on the server I migrated to (dont know why I stopped the services first on the old box, nervous I guess). Walked through step 7 (where you go through the integration manager) in a few minutes, then completed the install. At that point, I did a DIRT restore, got 3 errors. Im not sure why, but it complained about some IDs using the same number ( a number I didnt recognize). It recommended I do a dbwalk after the restore, so I did. Tested the voicemail, UM, etc for all users. Verified all users were imported in, they were. All worked fine, with no issues. I was surprised.
Next, I upgrade to the latest version of Unity on this migrated box. Thanks all for the help.
Thanks for posting back with your results here! This will help others in the future I'm sure. 5 points for this follow-up and 5 points to Michael for your great support here as well :)