My name is Abhiram Kramadhati. I am an engineer with the Contact Center backbone TAC team and work in the APAC timezone.
This techtalk is about the latest UCCX version, 10.0(1). The latest release has a lot of new features such as CUIC, Finesse, Media Sense integration and also architectural changes which might not be noticed by the customer directly, but is aimed at improving the product stability.
In this tech talk, we discuss about these features in brief along with changes in hardware requirement and support, upgrade scenarios and migration options.
Let us start from the beginning and look at some information about upgreades.
Is there anything different about this version in terms of upgrade?
UCCX 10.0 supports only Linux to Linux upgrades. This means that if you are on a Windows version of UCCX (example 7.x), you will have to upograde to an intermediate linux version of UCCX (say, 9.x) and only then move to 10.x. Here are some examples of upgarde paths, but you can chose one that suits your requirements:
One important point to keep in mind is that when you upgrade to the linux version, or if you already on a linux version, ensure that you are on the latest SU (Service Update). For example if you are on the 8.5(1), you need to be on latest SU which is SU4. You can upgrade to 10.0(1) only from the latest SU. Please note that as and when newer SUs are released, the support for upgrade will be aggregated. Say, SU5 is released 2 months down the line. You will then be able to upgarde to 10.0 from both 8.5(1)SU4 and 8.5(1)SU5.
When you are performing a refresh upgrade, from 8.x, ensure that you are using the right cop file based on the version you are in. The COP installation will be possible only on the latest SU and that is how the version control is done currently.
This, according to me, is the biggest change in terms of install/upgrade when compared to the previous versions. Unlike the previous versions of UCCX, 10.0(1) is supported ONLY on a virtual machine. Starting 10.0(1), UCCX can no longer be installed on bare-metal servers. Therefore, you will have to plan the hardware too in case you are upgrading from a lower version and that too an MCS. So the big question is "how do I migrate?". We have put together two possible ways of migration. The following steps need to be taken:
From here, we have two options:
Method 1 (left hand side):
4. Reinstall the subscriber with the same version, ip address, hostname and credentials
5. Add it to the cluster
6. Restore the subscriber from the DRF backup
7. Upgrade the cluster to 10.0(1)
Metod 2 (right hand side):
4. Delete the subscriber from the configuration
5. Upgrade the publisher to 10.0(1)
6. Install the subscriber with version 10.0(1)
7. Add it to the cluster
Advantages and disadvantages of the methods:
Method 2 will take considerably lesser amount of time since you will do only 1 Upgarde and 1 Switch-version (on Node 1 only) whereas you will be doing 2 upgrades and 2 switch-versions in the first method.
But with the second method, all recording data present on Node 2 will be lost. The recording works in such a way that the recording files are stored on the UCCX cluster in a round-robin fashion. These files are not replicated. Therefore, the recording files on Node 2 will be lost because we are not restoring from the DRF backup. Based on these considerations, you can take a call on which path to follow.
Memory requirement in UCCX 10.0:
Now that we have upgraded the system and are on 10.x, let us look at the change in memory requirements. If you would have noticed, the UCCX 10.0 has not just the UCCX but also CUIC and Finesse co-resident on the same box. These are fully blown applications and therefore you would need additional memory so that all the applications can perform at the same level as expected. The new memory requirements are:
If you are installing the 10.0 using the OVF template available on cisco.com, the requirement is automatically taken care of. If you are upgrading from an older version, ensure that you add the additional memory and are in conformance with the standards. Non-confromance might not only affect system performance but also give a warning on the AppAdmin page:
While we are on the same topic, there is another important issue about "Partition realignment". Please go through the issue described in the pre-FCS communication which has been published on Cisco.com:
Let us now move on to the most anticipated part of the UCCX 10.0 release. This release has perhaps the highest number of changes in terms of the features in the time I have worked on UCCX. Some of the major updates are:
The output will be similar to:
Note: It is MUST that ALL agents use ONLY ONE time of agent desktop. If you have 200 agents, all of them should use either CAD or Finesse only. 100 using CAD and 100 using Finesse is not supported. Also, please note to shutdown the Finesse services if you are not using Finesse. The Finesse service remaining started when a log of CAD operations are underway is known to cause performance issues.
Media Sense Recording:
Extend and Connect:
As mentioned in the beginning of the blog, there are some architectural changes introduced too. This one in particular due to feedback from the partner/customer community.
Traditonally, the UCCX engine accessed the Engine keystore. This was always accessible from the root only. The keystore which was accessible by the user was the platform Tomcat keystore. This was however not used by the UCCX Engine. So if you are using a step like getUrlDocument and trying to establish a secure connection to the server, you had to upload the certificate and the certificate chain to the UCCX engine keystore. This was possible only via the root. This was a little inconvinent and was tracked under the defect: CSCue13884
The enhancement now is that the UCCX engine accesses the Platform Tomcat keystore instead of the UCCX engine keystore. So, you can now upload the certifcates meant for the UCCX application from the OS administration page.
IMPORTANT: If you had opened a TAC case earlier and had your certificates uploaded from the root, please note that these have to be reuploaded from the OS Administration page since the UCCX engine is no longer looking into the Engine keystore.
Here is a presentation which will give much more information on the certificate management and the concepts behind it.
Things to look out for:
CSCtz34126: DRF reports backup as "SUCCESSFUL" even when LDAP backup script fails
2012/04/16 10:25: Done executing Backup LDAP Script
CSCul99618: Wrong license package causes LDAP restore to be skipped
--> Symptoms are agents unable to login after restore and CDA is blank
2013/12/06 15:46: Checking the IPIVR license flag before initiating CAD Restore
2013/12/06 15:46: IPIVR package.Skipping CAD Restore
Although the system has a non-IPIVR license (Standard, Enhanced of Premium) the license is still read as IPIVR and the LDAP database is not restored.
-->Reboot the server
-->Ensure the Cluster View Daemon (CVD) service is started
-->Perform the restore again
Out of personal experience, I would recommend that the MCS server is not decomissioned until the UCS is completely validated and tested for production. Sometimes, we do have to manually migrate the LDAP database manually and for that the MCS server access is helpful.
Enhancements in terms of serviciability:
utils uccx dbreplication dump configfiles --> gives out out of files resonsible for replication setup
utils uccx database healthcheck --> performs healthcheck of database and gives recommended actions
utils uccx database dbpref ---> used for monitoring CPU utilization of server and the database utilization too
run uccx hrdataexport --> used to collect the database dump of config and historical tables
Please go through the pre-release communication for UCCX for more information:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.