[cisco-voip] UCCX 5.01 upgrade to 7.01

Ed Leatherman ealeatherman at gmail.com
Sat Dec 4 16:15:37 EST 2010


On Sat, Dec 4, 2010 at 1:14 PM, Bill Riley <bill at hitechconnection.net> wrote:
> Thanks Ed. A few follow up questions.
>
>
>
>
>
> ·         When I fail over from the primary to the secondary what will the
> CAD see? Will they see an error?

Perhaps someone else can verify but I think there might be a pop-up
message that they click through. Sorry I don't recall the exact
behavior

>
> ·         Is there a way to stop new calls from connecting to the primary
> server and move to the secondary while the calls remaining on the primary
> are handled. In other words no dropped calls?

I've never tried this myself.
You could redirect your JTAPI triggers with a translation pattern to
some other system, and then perhaps do something creative on that
system so you don't drop any calls in progress and provide some sort
of minimal 'treatment' for new calls while you're monkeying with
things. I don't know of anyway to direct calls to the secondary server
or if it would even pick them up while the primary node was "up"..
maybe someone else on the list has a clever way to do it.

When I need to switch servers, I just pick a window where there is
minimal call volume (Sunday Mornings for us) and wait for no calls in
queue/IVR and make the switch. I don't have strict 24x7 SLA's for
those call centers that are open at the time, and very unlikely to get
a phone call in brief time it takes for the other server to pick up.
ymmv.



>
> ·         I want to make sure that the upgrade does not affect call
> processing on the secondary HA server. So as long as I can force the
> switchover from the primary to the secondary, and perform the upgrade on the
> primary without interrupting the active secondary server then I will not
> need to put it on an isolated server. I don’t have a maintenance window and
> we are 24x7.
>
> ·         So once I force the failover from the primary to the secondary the
> primary will not take back over unless the secondary is stopped correct?

Correct, they don't fail back so you are somewhat in control of this.


>
> ·         I am going to delete the update program on the client PC’s so it
> will not auto update CAD when it connects to the new server. I know this is
> not supported but I did test it. I have about 200 PC’s I need to get to and
> update and they are not allowed to have local admin rights even to perform
> the upgrade.

Getting CAD updated is the biggest pain.

Since you're a 24x7, I would definitely try to replicate everything in
lab if you have the opportunity. I'm not sure if you can accomplish
this without some brief interruption though - interested to hear if
you find a good solution.

>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Ed Leatherman [mailto:ealeatherman at gmail.com]
> Sent: Friday, December 03, 2010 6:05 PM
> To: Bill Riley
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] UCCX 5.01 upgrade to 7.01
>
>
>
> Inline below:
>
>
>
> On Fri, Dec 3, 2010 at 5:44 PM, Bill Riley <bill at hitechconnection.net>
> wrote:
>
>> We are planning an upgrade from UCCX 5.01 SR2 to 7.01 SR5. We will
>
>> take the primary server offline to perform the upgrade
>
>>
>
>> in an isolated network to minimize the downtime involved. We currently
>
>> have two servers in
>
>>
>
>> an HA configuration. I have the following questions:
>
>>
>
>>
>
>>
>
>> •       How can I force the failover from the primary node to the
>
>> secondary node
>
>
>
> I always just stop the CRS engine from the control center in appadmin when i
> need to switch them
>
>
>
>>
>
>> •       How long does it take to switch from the primary to the backup
>
>
>
> Pretty much instantly if its setup right. NOTE: any calls in queue or in IVR
> will be dropped.
>
>
>
>>
>
>> •       Do the CAD clients automatically failover to the secondary
>
>> server
>
>
>
> Yes
>
>
>
>>
>
>> •       How long can the primary server be offline?
>
>
>
> I do not believe there is a time limit.
>
>
>
>
>
>>
>
>> •       Does the secondary server maintain a copy of all of the call
>
>> statistics while the
>
>>
>
>> primary server is offline?
>
>
>
> yes. In fact usually when you run the historical reports client, it is
> connecting to which ever server is NOT currently the active node (to avoid
> performance impact)
>
>
>
>>
>
>> •       If the primary server is offline and a new CAD client is
>
>> started, will it automatically
>
>>
>
>> connect to the secondary?
>
>
>
> Yes.
>
>
>
>
>
>>
>
>> •       If I upgrade the primary server on an isolated network where
>
>> it cannot communicate with
>
>>
>
>> the secondary server will the upgrade complete
>
>
>
> Never tried it. Is there a particular reason you want to do that? It's
> intended to upgrade with the other node in service.
>
>
>
>
>
>>
>
>> •       What will happen when I start the primary server after the
>
>> upgrade to 7.01 and the
>
>>
>
>> secondary server is still at 5.0? Will the client continue to operate
>
>> on the secondary
>
>>
>
>> server?
>
>
>
> I believe the CAD clients will run on the secondary server until you run the
> upgrade or otherwise shut off the CRS engine. Note that the CAD clients will
> need to update before they will work on the new version. I'm lucky in that
> we have a non-production window when I can do maintenance like this, so I
> haven't monitored them too closely in that specific situation.
>
>
>
>
>
>>
>
>> •       Will I then be able to upgrade the secondary server to 7.01?
>
>
>
> When you run the upgrade program on the secondary node, it checks the
> primary node to make sure it has upgraded successfully. If it has, it
> permits you to continue the secondary node upgrade.
>
>
>
>
>
>>
>
>>
>
>>
>
>> Thanks for any help or experience you can provide.
>
>>
>
>> _______________________________________________
>
>> cisco-voip mailing list
>
>> cisco-voip at puck.nether.net
>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>>
>
>>
>
>
>
> hope that helps.
>
>
>
> --
>
> Ed Leatherman



-- 
Ed Leatherman



More information about the cisco-voip mailing list