[cisco-voip] CUCM Bridge Upgrade Question 7.1 to 8.6

[Mike]

I would use the LAB server for all servers moving them one by one "swinging"
them over to VM. Most partners and customers think they can install versions
prior to 8.0 on VMWARE this is an UNSUPPORTED configuration even if you move
to VMWARE on 8+.

 

Now you have a production copy running in VMWARE and you can switch
everything over by swapping  switchports.

 

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Hitch
Sent: Friday, May 04, 2012 4:54 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] CUCM Bridge Upgrade Question 7.1 to 8.6

 

I am planning an upgrade for a (3) node 7835-H1 cluster running 7.1(5)SU2 to
a (3) node cluster running 8.6(2)a on VMs.

Since these servers only support a bridged upgrade I was wondering if I
could do the following to reduce the risk and amount of downtime required
for the extended "refresh" upgrade.

 

1. Install 7.1(5)SU2 on a 7845-H2 lab server

2. Perform a DRS restore on this lab server from the production 7.1(5)
publisher

3. Upgrade the lab server to 8.6(2)

4. Perform a DRS backup of 8.6(2)

5. Restore the DRS backup on 8.6(2) Publisher VM (pre-built in an isolated
environment using the same IP address).

6. Build Subscriber VMs in isolated lab environment using the same IP
addresses.

7. Switch routing from the production environment to the pre-built lab
environment.

 

I find this very appealing since our original cluster will still be running
untouched in case we have to switch back.

 

Any concerns with this "modified bridge" approach?

The only concern that I see is that the subscribers will not be connected to
the lab publisher server when I do the upgrade from 7.1 to 8.6.

Is that going to be an issue?  Any other concerns?

 

I see a few posts with similar questions, but I just want to be clear about
the subscriber portion.

I do not think that the disconnected subscribers should matter, but would
love to hear from someone who has used this method.

 

Thanks,

Ryan

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