I have a client that is looking to migrate from a stand-alone 3.1(1) installation to a 4.0(5) installation with fail-over on totally new hardware platforms. The client has agreed that old message retension is not mandatory, however, they would like to retain the existing greetings and call handlers. My initial thought would be to build a new 4.0(5) with fail-over system on the new hardware platform, then import all subscriber accounts, and then copy the wav files for the greetings from the old server to the new, and use the copy from file option to re-link the greetings to the subscriber accounts. Does this seem like a reasonable approach? Is there a more efficient/effective method for maintaining all greetings? I was hoping to avoid building a 3.1(1) system on one new server, then doing a DiRT backup of the existing system, restoring to the new 3.1(1) system, then doing an upgrade to 4.0(5), and then a conversion to a fail-over configuration. Maybe I should lean more towards the upgrade approach? Any thoughts that you folks may have from your experience would be much appreciated.
My opinion is that you do a backup of the server (assuming unity, Windows Ad, Exchange is on the same machine) using Dirt and that you have the unity 3.1(1) CDs available.
You intend to do failover so you will need at least two servers to start. The first server will run both Windows AD, and Exchange. The second server will be the new Unity 4.0(5) member server that will become the primary server when you are ready to do failover. The 3rd server should be the same as the second as it will run the secondary unity server. The 3rd server does not need to exists immediately.
You can then upgrade the old server to Unity 4.0(5). Do a DiRT backup of the current server, with or without messages, and restore DiRT to the new server.
The new server does not need to use the same name or domain name. If the old server was running exch 5.5, you should use exchange 2000 on the new server.
My only concern is the upgrade from 3.1(1) to 4.0(5). I don't anticipate any problems but you should have some sort of recovery plan such as removing one of the raid-1 drives along.
Thank you for your response. I appreciate the input. I left out a few details in my explanation that may have changed your response. The old 3.1(1) server is going to go away. The client has (3) new hardware platforms that they intend to install the new system on. The old server will continue to run in production while the (3) new servers are being built, configured, and tested. Once the new servers have been tested with the 4.0(5) with fail-over, they will be cut-over to the production side. Once this happens the existing 3.1(1) server will be decommissioned.
With this information, would you recommend building one of the new server platforms as a 3.1(1), doing a DiRT backup and restore from the existing 3.1(1) server to the new 3.1(1) server, and then step through the upgrade to 4.0(5) and fail-over configuration on the new server platform? Or, would you recommend that I build the (3) new server platforms as a straight 4.0(5) with fail-over design, and then import in all subscriber accounts, and reassociate their wav file greetings from the existing 3.1(1) box to the new 4.0(5) system?
I know that there is a lot of "missing" information that I am asking you to take into account, but this is really all of the information that I have to work with as well.
Prebuild the AD/Exch (diff domain, diff svr names) on 1st svr, unity 3.1(1) on the 2nd server.
Dirt restore to Unity.
Upgrade 2nd svr to 4.0(5)
I presume that you are going to build a new set of ports on CCM for testing.
Build Unity 4.0(5) on 3rd svr with demo-license, and run failover wizards on primary, then secondary.
Importing wav files instead upgrade is possible but you will not be able to "import" settings such as passwords, transfers and so on. If you have 10 users, that should be no problem to recreate but I can't imagine doing hundreds by hand.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...