If I were you, I'd upgrade your existing server to 4.0(5). Install the new server fresh as 7.x and the latest ES. COBRAS supports 4.0(5) and higher only. From there, you could use COBRAS to migrate the majority of your data from the old server to the new system. You would need to do an alias mapping with the COBRAS data viewer to match old user alias to new user alias in AD for Unified Messaging. There is still some manual work but it's much better than essentially doing multiple rebuilds and upgrades. This would also allow you to (outside of the upgrade to 4.0.5) leave the existing environment in place and indepedent of 7x until you're ready to cutover. Check out www.ciscounitytools.com and look at the COBRAS help guide. If you have more questions, feel free to PM me. I can go into further detail without crushing out a HUGE forum response on the intricacies of the various migration methods.
You can do it that way. I would add in though a backup plan if Unity fails during the upgrade. In this case, either have spare drives or pull a drive on the mirror, then do the upgrade.
But before you start the uggrade, pull a drive and test the mirror works on both drives.
The other issue is that you will have to be Unity 4.04 UM after the DIRT restore. You can bring the messages with you from DIRT, but it can be long. COBRAS does it also, but again, its a longer process with messages.
When you reinstall Unity 4.04 on the new hardware, it will be in the production domain with Exchange already. After its configured, run a DIRT restore and it will dump everything in for you. Great thing is that you can leave your old 4.04 server running. Simply change the Voicemail Profiles on CUCM to point from Old Unity to New Unity.
Once it runs in UM for a couple days with DIRT Restored, go ahead run your inplace upgrade.
The other option to use is COBRAS as mentioned. There a few things that do not come over, please read the COBRAS help file on what comes over and what does not. You will have to recreate the Subscriber Templates, etc.
If the system is running good, has a clean track record... DIRT will be a good call. If the system has had issues, repairs, TAC case after TAC case opened on it... maybe COBRAS is better choice. DIRT will bring over the problems..... COBRAS just brings over the data, no DB.
TCat always gives good advice so you can pick your poison. It's almost 6 in one hand, half dozen in the other. I would pull the spare drive in either scenario personally. Having done this a number of times, COBRAS will save you time. In addition, sometimes you will find that moving over your old messages from a VM only system to a UM system is not something all too desirable as many users hardly ever clean up VM messages. So, your Exchange Administrator may not be accounting for User X or User Y who never got rid of 2100 messages over the last several years of being at the company. Since your current system is VM only, you can still leave it online for a period of time - you would just need to configure a new number for users to have dial in access for X number of days or provide a new pilot number for the UM system (option 1 is typically preferred). Just remember, the term "upgrade" in Unity is a misnomer...it's more rebuild than anything else.
Either way you choose, good luck and let us know if you need some help.
That is correct. I cringe everytime i see a Statement of Work that says "Unity Upgrade" when in reality... its a rebuild. The only upgrade would technically be an inplace upgrade. Anything else of changing OS, hardware, etc is a rebuild.
Pick your poison is correct. Just have a rollback plan.
Plan on time to remap alias names also. Whether you use DIRT or use COBRAS, if you have many users it will take some time remap all those out. On the VM system, it might be John Doe or JDOE. In the UM Exchange, they may have John Doe, but John.Doe as the alias. IF you do not match these from Unity old to Unity new, DIRT or COBRAS will create new accounts. Fun stuff when you have 1000+ users
Yep, the user mapping is always fun. Last thing from me and I'm sure TCat would agree. Whichever way you go, make sure you read up on the DB Walker tool and run it as one of the first prep tasks. Clean up as much of the "junk" on the system as you can. If you aren't comfortable running all the various tasks, at least let it run the basic check and do any auto clean-up tasks that are applicable.
Remember, when you use DiRT - garbage in = garbage out.
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...