UCCX 5.0(2) to 7.0(1) upgrade. 2nd node install still remains at 5.0(2)?

Unanswered Question
Oct 18th, 2009

I have successfully upgraded a UCCX primary node in an HA cluster of 2 nodes from 5.0(2) to 7.0(1).

New 7.x license uploaded with HA successfully.

When I go to the 2nd node in cluster, I am able to successfully go through the process of installing the upgrade executable for 7.0(1), and it 'completes successfully', but after a reload, and I log into appadmin, it still show 5.0(2) and displays an error msg that the JTAPI is out of synch!

Any ideas?

Am I hooped?

Do I have to rebuild the 2nd node in the cluster from scratch?

ChrisO

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
WSonnylal Tue, 02/23/2010 - 08:15

Do you recall the call processing behavior during the upgrade of the two servers?  I'm interested in knowing if there will be any downtime.  So when you're upgrading the Publisher did any of the following happen:

  1. Calls were failed over to the Subscriber and the database was now the master on the Subscriber
  2. Calls were failed over to the Subscriber but the database was in the slave mode on the Subscriber
  3. Calls processing stopped on both the Pub and Sub during the upgrade of the Publisher and did not resume until the Publisher was at 7.x with a valid license

Thanks in advance.

cogden Tue, 02/23/2010 - 08:41

I think you have mistaken 'UCCX' for 'CM' here?

I was dealing with Unified Contact Centre Express upgrade issues, not Communications Manager (CM) which is the application that handles call control for IP phones.

UCCX is the application that handles the scripts (IVR) and agents(resources).

The CM was unaffected by the UCCX upgrade and phones worked as normal the entire time.

But I know that you need to upgrade the Publisher first on CM and upload the new license.

Usually phones are registered to the Subscriber, so no impact happens until you reload the Pub, and only then the services that are directly related to the Pub are affected if phones are registered to the Sub as the primary server.

Only after the Pub is upgraded can you upgrade the Sub and then only when you reload the Sub do the phones automatically failover to the Pub

(This is provided you configured your CM group properly/accordingly).

and at that point the fw upgrade takes place, so this is where phones are out of commission for a while.

You should enable peer sharing on the phones to speed this up btw.

WSonnylal Tue, 02/23/2010 - 09:25

No I'm interested in knowing the call processing behavior with UCCX and not Call Manager.  I should have been more specific.  Call Manager will routes calls intended for the UCCX Application Triggers to UCCX via CTI Ports that are registered in CCM and associated with the two UCCX servers.  This should be clear to folks familiar with UCCX.  With an HA UCCX setup both UCCX servers participate in Call Processing of the calls coming into the UCCX triggers.  When a UCCX server is offline Calls are not sent to the CTI ports that are registered to that UCCX server but instead to the CTI ports that are registered and online on the other UCCX server, this way there's fault tolerance and failover.  With that understood, we can focus on my original question.

What happened during the upgrade?  Did your HA UCCX cluster continue to handle calls coming in to the application triggers from Call Manager.  Which one of the three scenarios did you observe?

cogden Tue, 02/23/2010 - 09:36

Ah OK. Yes, understood and agree completely.

Yes, all calls were handled normally by the UCCX server that remained 'up'.

CTI ports had been created (contiguously) for the UCCX primary and secondary nodes (50 for each).

Incoming calls hit their RP triggers and were routed to the scripts and everything worked normally and agents answered calls without a problem.

The problem was originally caused by Cisco Security Agent not actually terminating properly and so it didn't allow the upgrade to proceed correctly on the UCCX 2nd node (Subscriber). From now on, I advise that for any upgrades, the CSA be completely removed (you probably need to upgrade it anyway) prior to the UCCX upgrade.

Chris

WSonnylal Tue, 02/23/2010 - 09:39

Thanks so much for confirming this Chris.  I couldn't find it documented anywhere.  5 stars for this one.

cogden Tue, 02/23/2010 - 09:53

One final point on this.

I was at another customer location testing CM failover with a UCCX with HA.

If either of the UCCX servers where switched off, everything worked as normal, as explained in my previous email.

However, depending on which the CM server was the primary server (1st server in the UCCX JTAPI list), then if this CM server was switch off (or NIC ports shutdown) so it was not available, then the CTI ports did NOT immediately failover.

We observed that if we just observed it for 20-30 minutes, then they eventually failed over to the other remaining CM server and inbound calls to RPs and the CTI ports worked as expected. (We also setup a Hunt Group for the CTI Route Points to get around this issue temporarily if the UCCX cluster was out of service for whatever reason).

Through troubleshooting we found that we could expedite the CTI ports failing over and registering on the 2ndry CM server by going to Serviceability on the CM and resetting the CTI Manager service.

We then just documented this in the customer's failover process after logging a call with Cisco TAC, who thought it was probably a bug in CM 6.1(4).

UCCX was 7.0(1)sr3.

Chriso

Actions

This Discussion