Mailing List Archive: Cisco: VOIP

CUCM Bridge Upgrade Question 7.1 to 8.6

Index | Next | Previous | View Threaded

ryanhitch at yahoo

May 4, 2012, 1:54 PM

Post #1 of 7 (1637 views)
Permalink

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

gwenzel at conres

May 4, 2012, 2:02 PM

Post #2 of 7 (1592 views)
Permalink

Re: CUCM Bridge Upgrade Question 7.1 to 8.6 [In reply to]

That's how we do it. During your import of your lab ucs build you should change the ip address so you can do a parallel install. This is our path usually if it can be done over a weekend and depending on how many remote locations on the cluster you could make the changes on each gw one at a time. This way you can have a back-out plan with little downtime.

Check the firmware upgrade path but you should be fine at your current level os.

Gregory Wenzel
Solution Engineer, CCNP Voice
Continental Resources Inc

From: cisco-voip-bounces [at] puck [mailto:cisco-voip-bounces [at] puck] On Behalf Of Ryan Hitch
Sent: Friday, May 04, 2012 4:54 PM
To: cisco-voip [at] puck
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

This message w/attachments (message) is solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any products.

mikeeo at msn

May 4, 2012, 2:10 PM

Post #3 of 7 (1591 views)
Permalink

Re: CUCM Bridge Upgrade Question 7.1 to 8.6 [In reply to]

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
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Ryan Hitch
Sent: Friday, May 04, 2012 4:54 PM
To: cisco-voip [at] puck
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

cisco-voip at ibh

May 7, 2012, 8:24 AM

Post #4 of 7 (1559 views)
Permalink

Re: CUCM Bridge Upgrade Question 7.1 to 8.6 [In reply to]

Hi Ryan,

On Fri, May 04, 2012 at 01:54:26PM -0700, Ryan Hitch wrote:
>
> 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)

Apart from other considerations, keep in mind that after (2), your shiny
replicated PUB on the 7845-H2 will be in the vile "upgrades ar not allowed
in license grace period" state of affairs. Even though you aren't planning
to use it for anything but to upgrade and export again, you are forced to
deal with licensing and get the PUB licensed on this hardware. Plan more
or less a week for that step of engineer time wasted to applied control
freakery...

Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

wsisk at cisco

May 7, 2012, 8:27 AM

Post #5 of 7 (1579 views)
Permalink

Re: CUCM Bridge Upgrade Question 7.1 to 8.6 [In reply to]

I believe you are referring to:
CSCtb86875 Upgrades are prohibited during License Grace Period

Consult Bug Toolkit on Cisco.com for more information.

Regards,
Wes

On May 7, 2012, at 11:24 AM, Beck, Andre wrote:

Hi Ryan,

On Fri, May 04, 2012 at 01:54:26PM -0700, Ryan Hitch wrote:
>
> 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)

Apart from other considerations, keep in mind that after (2), your shiny
replicated PUB on the 7845-H2 will be in the vile "upgrades ar not allowed
in license grace period" state of affairs. Even though you aren't planning
to use it for anything but to upgrade and export again, you are forced to
deal with licensing and get the PUB licensed on this hardware. Plan more
or less a week for that step of engineer time wasted to applied control
freakery...

Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

cisco-voip at ibh

May 8, 2012, 7:31 AM

Post #6 of 7 (1569 views)
Permalink

Re: CUCM Bridge Upgrade Question 7.1 to 8.6 [In reply to]

Hi Wes,

On Mon, May 07, 2012 at 11:27:29AM -0400, Wes Sisk wrote:
> I believe you are referring to:
> CSCtb86875 Upgrades are prohibited during License Grace Period

Well, not exactly. This bug makes things even more complicated (I didn't
run into it due to documentation glitches, but after re-restoring a newer
DRF backup to a cluster that was already moved to new licenses - it needed
removal of the old ones that were reintroduced by DRF as well as the new
ones that already worked, followed by re-uploading only the new ones), but
what I complain about is the very fact that I'm expected to license an
installation that I don't actually need, but was just forced to make due
to upgrade path limitations. If upgrading in license grace mode would be
possible, one could install a swing server, import DRF there, upgrade
that install (maybe in several steps as needed), export DRF and finally
import that backup on the true destination, which then needs to be
licensed correctly of course. But licensing just for the sake of being
allowed the next step in a potentially long chain of time consuming and
difficult upgrades makes no sense, it just feels like being pulled through
burning hoops by the nose. Specifically as there is no automation (like,
say, a web interface to get an instant license move or a temporary lic
for the time of the upgrade), but the need to interact with licensing/TAC.

There's also the interesting question of getting licenses moved to
a VMware license MAC on an unsupported platform (like, say, 7.1.x).

BTW, regarding CSCtb86875, it could document that you can actually
do "file delete license *" followed by some compulsive hitting of CR.
I've just upgraded an installation that had 82 .lic files, and I'm sure
that's on the smaller side...

Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

wsisk at cisco

May 8, 2012, 7:36 AM

Post #7 of 7 (1592 views)
Permalink

Re: CUCM Bridge Upgrade Question 7.1 to 8.6 [In reply to]

Andre,

Fully agreed the licensing model and practices make this unnecessarily complicated. You should see improvements in this are in coming versions.

Regards,
Wes

On May 8, 2012, at 10:31 AM, Beck, Andre wrote:

Hi Wes,

On Mon, May 07, 2012 at 11:27:29AM -0400, Wes Sisk wrote:
> I believe you are referring to:
> CSCtb86875 Upgrades are prohibited during License Grace Period

Well, not exactly. This bug makes things even more complicated (I didn't
run into it due to documentation glitches, but after re-restoring a newer
DRF backup to a cluster that was already moved to new licenses - it needed
removal of the old ones that were reintroduced by DRF as well as the new
ones that already worked, followed by re-uploading only the new ones), but
what I complain about is the very fact that I'm expected to license an
installation that I don't actually need, but was just forced to make due
to upgrade path limitations. If upgrading in license grace mode would be
possible, one could install a swing server, import DRF there, upgrade
that install (maybe in several steps as needed), export DRF and finally
import that backup on the true destination, which then needs to be
licensed correctly of course. But licensing just for the sake of being
allowed the next step in a potentially long chain of time consuming and
difficult upgrades makes no sense, it just feels like being pulled through
burning hoops by the nose. Specifically as there is no automation (like,
say, a web interface to get an instant license move or a temporary lic
for the time of the upgrade), but the need to interact with licensing/TAC.

There's also the interesting question of getting licenses moved to
a VMware license MAC on an unsupported platform (like, say, 7.1.x).

BTW, regarding CSCtb86875, it could document that you can actually
do "file delete license *" followed by some compulsive hitting of CR.
I've just upgraded an installation that had 82 .lic files, and I'm sure
that's on the smaller side...

Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads