Call Manager System Upgrade 4.x - 6.x / 7.x Known Issues:

[Planetmaker]

Could people post suggestions of things to check and and things to look out for when upgrading Call Manager from 4.x - 6/7.x.
My organisation plans to do this over the coming months and I want us to be prepared.

I thought this thread could be a good reference point having just read the thread about the Attendant Console slowness issue following the upgrade.

http://www.tek-tips.com/viewthread.cfm?qid=1457202&page=3

 

[pndscm]

I just did a 1000 phone CCM 4.1.3 upgrade to UCM 6.1.2 this week. Here's a couple tips I'd like to share.
If possible, delete all the CAR/CDR data before running the Data Migration Assistant. The first time I ran it on the system, my DMA file was around 500 Meg so my import into the new server was around 10 hours. I then deleted all the CAR/CDR, the DMA file wa 30 Meg and took 30 minutes to import.
I have done several of these upgrades and there always seems to be some issue that comes up. The one this week was VMail ports that were one way. Unity could dial out for MWI but when we tried to access mail boxes, we got a fast busy. Everything was registered and looked correct but... We finally deleted all the Vmail ports and re-ran the wizard and it fixed the issue. I truly beleive the issue was with the Hunt Group but we rebuilt everything just to be sure.

 

[Planetmaker]

Top tips pndscm thanks! Keep em coming guys.

 

[dreamdiver]

Planetmaker: We are also in the same situation, where the company needs to upgrade from CM 4.1 to 6.x. and unity 4.x to 5.x (500 phones).
Is the upgrade of the software something that your IT people are going to attempt given good documentation. It has been suggested to us to get a consultant do the upgrade.


pndscm: I see where you have done a couple of these upgrades. Is this something that can be done over a weekend or will there be down time during business hours during the week? Also would appreciate your commnets on the performing the upgade by consultants or our self.

 

[pndscm]

If you are changing server hardware, there should be minimal downtime. Build the new servers in an isolated environment then swap ethernet cables to cut over. If you do this, add the NTP, DNS, SMTP server info after you finish the upgrade. The installation verifies it can get to these resoucres and if it can't, it fails. Same with Default Gateway.
But if you are upgrading on the same server and it is the only server, Publisher no Subscriber, expect a lot of downtime. Depending on database and CDR/CAR size it can take over 12 hours to do.
Unity 4.x to 5.x isn't bad unless you are upgrading ther mailstore to Exchange 2003. Then there are difficulties, the same as any Exchange upgrade.

 

[Planetmaker]

We plan to use our maintenance company for the upgrade (so we can point fingers if it goes poorly) however we are on our 2nd maintenance contractor and neither have impressed us at all.
This may prompt us to have purely inhouse maintenance (me!!) in future.

We have 2500 phones and also an IPCCX to upgrade from v4-7.

On all upgrades we tend to pull a backup disk from each server (cluster of 3)and upgrade those disks on our test server and test in the test environment) if we have it nailed down and all seems ok we will swap the disks on the live server over a weekend and test various things to make sure all is ok.

WHile we are upgrading the disks we may put a notice out that all admin changes will be put on hold for the week as when we go live on the new version any changes would need to be carried out again on the upgraded server.

 

[pndscm]

Planetmaker, you'll have one issue with your 'pull the disk' method. Licensing. You'll be able to build it and import it but you won't be able to test it. The licensing is tied to the MAC address now. So pulling a drive and putting it in a different server won't work like it has in the past. And when you order the new software, you have to indicate if you'll be upgrading on the same hardware, called Server Migration, no server license included, or if you are upgrading to a new server you'll get a new PAK code. If you are keeping the same hardware, remember you'll need 2 Gig/146 Gig HD for UCM 7, you take a copy of the license report and send it to Cisco and then they'll send you the new license with the right numbers of DLU's. But if you change hardware, you do the same with the license report AND you have to get a new server license for all your servers before the CCM service will stay running.
Another Tip: Make sure you build all your spare phones that you have on the shelf in the server BEFORE you do the DMA or you'll have to buy your Device Licenses for those phones all over again. DLU's are $50 each List Price and each phone takes 3-4 DLU's.

 

[Planetmaker]

Thanks pndscm, I knew about the way the handset liceses were handled but not the servers.
Looks to me like the best way would be to get new servers and CM installed and import the config taken from the existing CM via the software tool that I believe is used when upgrading.
Hope this doesn't sound too neanderthal!

 

[pndscm]

The way to do it is get new servers. Install the DMA tool on the old Publisher server (requires a reboot). Run the DMA tool to get the database, then when you run the install on the new servers it will ask if you want to import the database from a Windows-Based platform, select 'Yes'. The only way to upload the DMA file is FTP or SFTP So you want the DMA file as small as possible.(See above) You HAVE to import the DMA file during installation. It can't be added later.
Then once the Publisher is done, get your licenses (use the MAC of the Publisher for all 3), upload them to the Pub, do all the testing and then build the Subscribers.

 

[Planetmaker]

OK thanks hopefully our maintenance company will know all this but I will be able to follow the process better (rather than advise them!)

 

[pndscm]

One thing I forgot. BACK UP EVERYTHING before you start.

 

[MiloMindBender]

We just completed a migration from 4.1.3 to 6.1.2 and I was shocked by how smooth it all went. our shop consists of a pub and a sub. upgraded pub then the licenses then bounced sub. the phones all registered to pub and sub was then available to complete the upgrade. very little down time.

I would highly recommend that you ensure the current phone firmware is supported under 6. if not upgrade to a supported version prior to the ccm4->6 upgrade. \

The only issues that we encounterd had to do with cisco's upgrade\installation documentation. The bit about upgrading and updating the licenses is very poorly written. Specifically the section that instructs you to copy som informatino out of a text windo and paste to a windo on cisco's web site. you are specifically instructed to leave off the html tags. there are no html tags to leave off (at least that was our experience). Also do not bother upon ugrading the licenses to restart the calmanager service. wait until you complete the udate step then restart the service.

lastly when sub completed its upgrade we needed to access the services administration pages and activate all the appropriate services as for us none of the services on sub had started

 

[whykap]

The vast amount of failed upgrades are due to DMA. make sure your DMA back up with zero errors or it will fail to restore. If errors occur, read them, clean the database/configuration and rerun the DMA. Once it comes back with no errors proceed with the upgrade.
Also as pndscm suggested do not include CDR records as it can double or even triple the amount of time the back up and restore can take. For exammple I did a restore of an 800+ user db with no CDR and it took approx. 2 hrs to restore the db on the pub. A different upgrade with 200 users and full CDR records took 8+ hrs to back up and as many to restore. And the back up failed twice originally.

The second issue is with licensing. Make sure all your licensing is in order or you will be in trouble. Don't rely on TAC as they have been notorious on providing the wrong licenses on 6.X upgrades. Upon receipt of your licenses review them and make sure MAC addresses match, DLU and nodes are correct and the licenses are not temporary.