This Chalk Talk discusses the latest version of the Unified Contact Center Express 10.0. We will discuss topics around upgrade, migration, and new features.
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 upgrade to an intermediate Linux version of UCCX (say, 9.x) and only then move to 10.x. 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 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 upgrade 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.
There are changes in terms of hardware support too. The older versions of UCCX could have been installed on both MCS and UCS, but the UCCX 10.0 supports virtualized platforms only. This is a major change in the hardware support for the contact center. If you are performing a fresh install of UCCX 10.0, it should be straightforward since you can install it on the virtual machine directly using the bootable media. Even an upgrade from an older version to 10.0 is straight forward, provided the older version is already on a virtualized platform. What if you are upgrading from an older version which is on an MCS? Here are the steps you can follow for migration:
After this, you 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).
Method 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.
Method 2 will take considerably less time since you will do only 1 upgrade and 1 switch-version (on Node 1 only), whereas you will be doing 2 upgrades and 2 switch-versions in the Method 1.
However, 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 decide which path to follow.
Now that we have upgraded the server to 10.0, let us look at some of the new features.
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:
Apart from new features, there are architectural changes too which have been introduced in this version that are aimed at improving product stability and also customer experience. One such feature I would like to talk about is certificate management.
Traditionally, 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 inconvenient 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.
IMPORTANT: If you had opened a TAC case earlier and had your certificates uploaded from the root, please note that these have to be re-uploaded from the OS Administration page since the UCCX engine is no longer looking into the Engine keystore.
Abhiram Kramadhati is an engineer with the Contact Center Backbone group. He has been working with Cisco UCCX since he joined Cisco. During two years at Cisco, he has built his expertise around Cisco UCCX telephony applications, Java Telephony API (JTAPI) integration, Cisco UCCX system behavior, LDAP components, and Cisco UCCX as IP interactive voice response in Unified Contact Center Enterprise (UCCE) environments. He also works on other technologies, including Unified Communications Manager and UCCE. He has been inv olved in many technical escalations in the Asia Pacific region. Abhiram also holds a CCIE in voice (40065).