cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
743
Views
0
Helpful
4
Replies

appadmin page inaccessable after 8.5.1 upgrade

Clifford McGlamry
Spotlight
Spotlight

Just did two step upgrade on two IP IVR's from v5 to v8.5.1.  This is a two step upgrade.

The upgrade to 8.0 (first step) worked just fine.  However, when upgrading to 8.5.1, BOTH IVR's come back up on the new version, and the appadmin pages are inaccessible.  The Cisco Unified CCX Administration service isn't running, so I started it off the CLI.  It starts, and then stops again. 

I rolled back one of them and did the upgrade a second time.  Exact same behavior. 

I'm kind of baffled here.  Haven't seen this before. 

Any suggestions?

-Cliff

4 Replies 4

anchoudh
Level 9
Level 9

Hi Clifford,

Please check the below points.

1. AXL service in CUCM is running.

2. CUCM version is compatiable with the UCCX upgraded version.

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_compatibility/matrix/crscomtx.pdf

3. UCCX 8.5 licenses are valid.

Thanks,

Anand

Pls rate helpful posts !!

1.  AXL service activated and running - Check

2.  CUCM Version is compatible with upgraded IP IVR version 8.5.1 SU3 -> CUCM 8.6.2.22900 - Check

3.  UCCX 8.5 licenses are valid - Since I can't get the appadmin interface up, I cannot LOAD the licenses.

Turns out, I've hit a bug.  The bug ID is CSCtr99662.  Not sure what triggers it as it works fine in my lab with the same images, but I'm not on UCS in my lab. 

If I get more info, I'll post it.  The key to identifying this seems to be pulling the Tomcat logs and looking for an error where the Catalina service complains that it's missing a configuration file.

The vix is apparently rolled into the 8.5.1 SU4 patch (not on CCO yet as of the date of this note). 

Installation of the available patch from TAC requires full root access.  It's two small jar files, but the CRS engine and Tomcat have to be shut down before installation.  Installation involves copying the new files into the directory and overwriting the existing ones, and then restarting the services.  Manual restart of the CCX Cluster View Daemon was also required after this in order to get my system fully up.

Still waiting on the causal triggers for this bug.