[cisco-voip] Questions regarding migration of CUCM 7.1.5.31900-3 to a UCS platform

[Haas, Neal]

We just updated our 7.1(5) environment to 8.? Then 3 weeks later we upgraded to 8.5.

Our first stage to 8. Run DRS when you leave from work or before you go into to the upgrades.

Our MCS servers needed bios/Raid updates and that took a while and it was unnerving because we knew NOTHING about those. Not in the docs, so that I think took us an additional hour per server. Rebooting several times and no timers to let us know what was going on really.

You can actually install the upgrade onto the servers, at the same time just don't reboot automatically.

If I remember right our 5 servers were about 7 hours, it was a learning curve really - a few mistakes on our side - such as running DRS when we got there in the morning.

If you can install the new image for the phones on to your existing TFTP before you do the upgrade - upgrading the image on the phones before the call manager upgrade saves you the hassle of waiting for the phones to upgrade when you do the new version.  That's up to you to save you some time while upgrading.

When going to 8.5 - please NOTE there are BAD DVDS's out there and cisco knows it! Seriously down load the ISO which is now available and burn your own copies.  If you have a bad DVD you will go 99% thru the upgrade process and fail! We had this.

If you get alerts and stuff from RTMT, you will get tons of warnings such as version mismatch when you upgrade to 8.5, you might want to turn off some of the monitors while upgrading to 8.5. Also you will get a new phone image for the phones again.

For us there were a few unknowns but really no problems, Unity Conn was upgraded to 8.5 after we went to 8.

We only had a couple of dozen phones that did not reregister so we power cycled them and they came back alive with no issues.

Hope my ramblings help you


Neal Haas


From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Matthew Saskin
Sent: Thursday, March 31, 2011 12:25 PM
To: Peter Slow
Cc: cisco voip
Subject: Re: [cisco-voip] Questions regarding migration of CUCM 7.1.5.31900-3 to a UCS platform

Fastest way to do it (per cluster) in my opinion:

1 - Acquire spare MCS server
2 - Implement change freeze on CUCM cluster in question, start cataloging "emergency changes" that are made
3 - Perform DRS backup of Publisher, DRS restore to spare MCS server
4 - Upgrade spare MCS server 7x to 8x
5 - DRS backup of spare MCS server
6 - DRS restore of 8x backup to MCS server
7 - Rebuild subscribers from scratch on UCS
8 - Migrate IP phones from 7x cluster to 8x cluster on UCS
9 - remove change freeze, re-implement any emergency changes that were required

There's some significant effort involved, in particular on the subscriber rebuilds, ensuring any custom TFTP files (wallpapers, etc.) are in place.  That said, it's less work overall than doing a double upgrade.

Matthew Saskin
msaskin at gmail.com<mailto:msaskin at gmail.com>
203-253-9571


On Thu, Mar 31, 2011 at 2:01 PM, Peter Slow <peter.slow at gmail.com<mailto:peter.slow at gmail.com>> wrote:
Hello Everyone,

I'd like your input on a project I'm working on. I have five clusters,
all of which are currently running 7.1.5.31900-3. My goal is to
upgrade each of them to 8.5 running in/on UCS.

My _understanding_ is that I need to get a cluster to at least 8.0(2c)
(which is what actual version, btw?), do a DRS backup, install the
same version in UCS and then restore the backup into the VM.

I was under the impression (until i read all of
http://tinyurl.com/5nuf25 ) that on most I2 servers a Bridged upgrade
is required and this would present an issue, because of time
constraints - The smallest cluster is 9 servers, the largest is 17 or
so and it can take upwards of 10 hours to upgrade a cluster, and about
that long  to actually get everything switched over _after_ upgrading
is complete. (I realize this doesn't need to be a serial process, but
it mostly is at the moment, aside from subs having their versions
switched in pairs.)

The main goal here is to get to UCS, and the team I'm working with
REALLY doesn't want to upgrade the MCS servers one weekend, then move
to UCS servers a week later. (Thus far, I've been telling them that
this is going to be necessary AND that there is NO way to install
7.1(5) in VMWare and _then_ upgrade to 8.x) Right now my only
alternative _seems_ to be getting a CUCM in the lab running 7.1(5),
doing a DRS export to that form the production cluster, upgrading
that, then doing a DRS backup from _that_ to the UCS cluster in order
to get the pre-staged environment up.

There's some additional background below.

Constraints:
The first cluster to be upgraded is composed exclusively of 7845-I2
IBM servers.
In some cases clusters might have  7845-I1's functioning as TFTP or
MoH servers, I am allowed to replace these with I2's prior to the
upgrade if I need to.
76 GB drives and 4 GB RAM in the I2s
The upgrades / reboots etc need to take place during a weekend outage
window that provides me with enough time to roll back if something
awful happens. (I'd like to get everything done in a day, so that I
can spend Sunday troubleshooting if I need to.)

Questions:
* If a bridged upgrade is required, do _all_ servers in the cluster
need to be upgraded, or can I just upgrade the publisher, export with
DRS and proceed from there?
* Can I run 8.5 on my existing cluster of 7845-I2's w/ 76 gig drives
and 4 gigs of RAM? http://tinyurl.com/5nuf25 seems to indicate that I
can, but if it's wrong, I get fired.
* Am I correct about an upgrade from 7.1(5) to 8.x within VMWare not
being supported / possible?

-Pete

Peter I. Slow
AIM: humboldtbgp
Email: peter.slow at gmail.com<mailto:peter.slow at gmail.com>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20110331/948c8e01/attachment.html>