Where did UCCX 7.0(1) SR2 go?

Answered Question
Jun 25th, 2009

Anybody know why they pulled 7.0(1)SR2 from UCCX download page and compatibility sheet?

Thanks,

Dan

I have this problem too.
0 votes
Correct Answer by joesnyde about 7 years 5 months ago

SR2 was pulled from CCO due to two bugs that were identified. The CCBU will be replacing the SR2 with SR3 which has an estimated delivery of two weeks.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Correct Answer
joesnyde Thu, 06/25/2009 - 07:35

SR2 was pulled from CCO due to two bugs that were identified. The CCBU will be replacing the SR2 with SR3 which has an estimated delivery of two weeks.

jasyoung Thu, 06/25/2009 - 08:23

Any chance we can get the bug IDs? We have multiple customers up on 7.0(1)SR2 and it would be nice to know what we're dealing with.

joesnyde Thu, 06/25/2009 - 11:04

BU should be sending out an email with all the information to the customers that have downloaded the SR 2.

Steven Griffin Fri, 06/26/2009 - 07:49

Any idea when that communication will be issued? I am about to cut over a customer this weekend on SR2.

joesnyde Fri, 06/26/2009 - 07:52

Do not install SR2, the notice should be coming out soon.

Chris Deren Sun, 06/28/2009 - 19:32

Here are the 2 bugs referenced:

1. CSCsz47854

Symptom: There is a defect in the underlying third-party database driver (jtds driver).This defect may result in increased CPU usage over time and may bring the system down after some weeks, depending on the load on the system.

Conditions: Appears on systems with high call volumes and sustained agent traffic for more than 2-3 weeks.

Workaround: Customers on 7.0(1)SR2 are recommended to monitor CPU usage for the overall system and the CiscoUnifiedCCXEngine process using perfmon and proactively reboot the system during maintenance hours if the system shows a steady increase.

2. CSCta33316

Symptom: A deadlock in the engine may occur that may cause the engine to be automatically restarted. In High Availability deployments a failover will occur.

Conditions: An intermittent race condition that may occur in scenarios involving multiple call-legs, such as agent transfers.

Workaround: No manual workaround needed. The system detects the deadlock and restarts the engine automatically.

HTH,

Chris

ecornwell Tue, 07/07/2009 - 12:21

Were there any other bugs fixed between the two versions? We're currently running SR2 and I've had to disable the automatic update ability because of the "Automatically Detect Settings" bug. If I need to push out a new version to our clients it will take some work.

ecornwell Wed, 07/08/2009 - 07:46

I have downloaded it but I'm concerned about the affect that patching will have on our clients.

Chris Deren Wed, 07/08/2009 - 07:48

I patched one HA system this morning without any issues for what it's worth.

Chris

ecornwell Wed, 07/08/2009 - 08:06

What SP were you running before the patch? If you were running SP2 did the client software update for SP3?

Thanks!

ecornwell Wed, 07/08/2009 - 08:39

Did your clients receive an upgrade when they logged in the next time?

Chris Deren Wed, 07/08/2009 - 11:33

The CAD version remains the same so no need for an upgrade there.

The version is 6.6.1.100 which remains the same since SR1.

HTH,

Chris

gsidhu Fri, 07/10/2009 - 10:19

Hi

I looked through the release notes one of the limitations for SR3- limitation 2:

Problem

When there are a large number of applications configured, the engine runs out memory at or soon after startup. This is likely when there is a configuration such as the same script being used with many different applications, each with a separate trigger. This is due to the script being loaded into memory for each application configured.

What is considered to be a large number of applications?

My client has 120 applications.

gsidhu Fri, 07/10/2009 - 10:20

Hi

I looked through the release notes one of the limitations for SR3- limitation 2:

Problem

When there are a large number of applications configured, the engine runs out memory at or soon after startup. This is likely when there is a configuration such as the same script being used with many different applications, each with a separate trigger. This is due to the script being loaded into memory for each application configured.

What is considered to be a large number of applications?

My client has 120 applications.

joesnyde Fri, 07/10/2009 - 10:27

We ran into a problem when the script referenced was loaded to 130 applications. I would assume that you may see the same issue.

gsidhu Fri, 07/10/2009 - 10:30

Thanks for sharing that with me - haven't upgraded yet! (still on SR2 installed in April).

Actions

This Discussion