We are currently running the following UC applications on physical MCS hardware: CUCM: 184.108.40.206900-8 UCCX: 220.127.116.1103-32 CUC: 18.104.22.16800-18 WFO/AQM: 22.214.171.124
Our current plan is to upgrade all of the above to the latest 9.x versions and go virtual at the same time. We would like to go with 10.x but there are some specific features of CAD that we use that are not fully implemented in the Finesse client yet. Our VAR has sent along the following link showing that the suggested upgrade path is to create the virtual servers running the current applications versions, backup the physical servers using DRS, restore to the new virtual environment and then do an in place upgrade to the desired version.
Like many administrators the UC apps have grown organically over time with many items in the configs that are no longer in use, don't match best practices, don't following consistent naming conventions etc. We are also migrating to an entirely new IP range for these systems. Our original thought was to build the new 9.x virtual systems in parallel and only apply (using BAT files or by hand) the pieces of configuration we wish to carry over, leaving the junk behind. The final step of the process would be to change the registration of our gateways and phones once we are confident of the rest of the system.
Does anyone out there have any experience they could share about doing this type of upgrade rather than the p2v-then-upgrade-in-place model?
There are multiple customers who have done the same thing - usually if its an old 4.x customer who has the older dial-plan. Its very much possible to do so. This way, you can build the new cluster side by side, change your dial plan configurations and other integrations, and do BAT to import phones. Its a little more time to do it this way compared to the p2v-then-upgrade-in-place model.
Couple of considerations: make sure you choose the service parameter "prepare cluster to rollback to pre 7.0" to remove the ITL files before moving phones.
UCCX reporting and recording will be lost ie, there is no way to move reporting DB to the new UCCX cluster assuming you are going to build that new as well. (You kinda have to give you are going to UCM 10.x)
You could potentially use COBRAS/Connection message shuttle to move messages. Ideally i would start fresh but it all depends if its ok for you to loose VMs.
Other than that its the normal process of changing DHCP scopes to point to new TFTP servers and also point gateways and other 3rd party system to these new CUCM servers.
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...
[toc:faq]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 discusse...