Cisco Unified Contact Center Express (UCCX) Version 10.0 is due to be released soon. UCCX Version 10.0 will contain many new features, bug fixes, and serviceability improvements. Information on all of these new features will be documented in the Solution Reference Network Design (SRND) and Release Notes (RN) documents published with the release.
This document provides a sneak preview of some of the changes in UCCX Version 10.0 in order to raise awareness of important points on how a UCCX 10.0 system is designed, installed, and upgraded.
For more information, refer to the UCCX Version 10.0 Prerelease Field Communication discussion on the Cisco Support Community.
Virtual Installation Only and Virtual Template Changes
In UCCX Versions 9.0(2), 8.5(1), and 8.0(2), UCCX could be installed on a physical Media Convergence Server (MCS) or MCS-equivalent servers. In UCCX Version 10.0, only virtualized deployments are supported.
UCCX Version 10.0 will not install on physical server hardware without virtualization (bare metal), and a previous version of UCCX cannot be upgraded to Version 10.0 if it will continue to run on physical servers. Refer to these documents for the latest information on UCCX virtualization:
Linux-to-Linux Only Upgrade
UCCX Version 10.0 does not support Windows-to-Linux upgrades. This means that any UCCX version from Version 7.0(2)ES3 and earlier cannot be upgraded in a single step to UCCX Version 10.0. Windows UCCX installations must first be upgraded to the latest Service Update (SU) on Version 8.5(1), or to the latest SU on Version 9.0(2). Then, that version can be upgraded to UCCX Version10.0. As of November 15, 2013, the interim versions for Windows to Linux upgrade to UCCX 10.0 were 8.5(1)SU4 and 9.0(2)SU1.
Refer to Cisco Unified Contact Center Express (Cisco Unified CCX) Software and Hardware Compatibility Guide for the latest information on UCCX upgrade compatibility.
Installation & Upgrade Scenarios
This section describes some installation and upgrade scenarios you might encounter.
- You design a new UCCX Version 10.0 installation. Install UCCX as a virtual machine (VM) with the Cisco-provided Open Virtualization Format (OVF) template for UCCX 10.0 based on the guidelines in the link in the previous section.
- You upgrade UCCX from Version 8.5(1)SU4 running in a virtual environment to Version 10.0. Follow the standard Linux-to-Linux upgrade procedures outlined in the UCCX Version 8.5 documentation for this upgrade.
- You upgrade UCCX from Version 8.5(1)SU4 run on physical servers to Version 10.0.
- Migrate the Version 8.5(1)SU4 system to VMs as outlined in the previous links for migration from the MCS to the Unified Computing System (UCS).
- Upgrade the Version 8.5(1)SU4 system running as a VM to Version 10.0 with the standard Linux-to-Linux upgrade procedures outlined in the UCCX Version 8.5 documentation.
- You upgrade UCCX from Version 7.0(2) to Version 10.0.
- Upgrade the UCCX installation to Version 7.0(2)ES3.
- Use the Product Upgrade Tool (PUT) in order to back up the Windows UCCX data on an enterprise Secure FTP (SFTP) server.
- Build a new VM with the Cisco-provided (OVF) template, and install UCCX Version 8.5(1)SU4.
- Complete the Windows-to-Linux upgrade restore phase in order to restore the Windows UCCX data into the new Version 8.5(1)SU4 VM and verify functionality.
- Subsequently, upgrade the virtualized Version 8.5(1)SU4 system to UCCX Version 10.0 with the standard Linux-to-Linux upgrade procedure found in the Version 8.5(1) documentation.
Virtual Template (OVF) Changes
In UCCX Version 10.0, the resource requirements for VMs are increased in order to support the additional applications that run coresident on UCCX (Cisco Unified Intelligence Center (CUIC) and Cisco Finesse).
Here are the OVF template resource requirements used by UCCX Versions 9.0(2), 8.5(1), and 8.0(2):
||1 x 146gb
||2 x 146gb
||2 x 146gb
Here are the new OVF template resource requirements for UCCX Version 10.0 and above:
||1 x 146gb
||2 x 146gb
||2 x 146gb
It is highly recommended that you gracefully shut down the UCCX VMs, and update the memory allocation to the new values after you upgrade to UCCX Version 10.0. If memory allocation for the VM is left unchanged after the UCCX is upgraded to Version 10.0, this warning message displays:
Integration of a new version of the underlying Voice Operating System (VOS) in UCCX Version 10.0 now checks for partition alignment in the UCCX virtualized disks. If the partitions are misaligned, this warning displays on the Cisco Unified Operating System (OS) Administration screen:
The OVF templates used in order to create the UCCX VMs, starting in UCCX 8.0 OVF template Version 1.0, correctly align the disk partitions; however, in UCCX Versions 8.0(1) and 8.0(2) - 8.0(2)SU3, these prealigned partitions from the OVF template were overwritten by the UCCX install process. This issue was resolved in UCCX Version 8.5 and 8.0(2)SU4.
In these scenarios, when you upgrade to UCCX Version 10.0, the previous error displays on the OS Administration page:
- A UCCX system Version 8.0, 8.5, or 9.0 was installed without the use of the Cisco-provided OVF template for UCCX. Manual creation of UCCX VMs in vSphere does not correctly align disk partitions. Therefore, when the check is completed upon the upgrade to UCCX Version 10.0, the previous error is displayed.
- A UCCX system Version 8.0(1), 8.0(2), 8.0(2)SU1, 8.0(2)SU2, or 8.0(2)SU3 was installed with the Cisco-provided OVF template for UCCX. Although the Cisco-provided OVF template for UCCX Version 8.0 correctly aligns disk partitions, the UCCX Version 8.0 installation overwrites these partition alignments and configures misaligned partitions. After you upgrade to UCCX Version 10.0, the previous error is displayed.
In either of these scenarios, or with any scenario that results in the previous error message on the OS Administration page, the UCCX Version 10.0 system must be backed up with the Disaster Recovery System (DRS), reinstalled with the UCCX Version 10.0 OVF template, and restored from backup. The UCCX documentation will contain detailed steps that are used in order to perform these actions.
CUIC as the Standard and the Only Reporting Client
In UCCX Version 9.0, CUIC was introduced as an additional reporting client for historical reporting of UCCX data. In UCCX Version 10.0, the Historical Reporting Client (HRC) is retired, and CUIC must be used in order to access historical reporting data.
UCCX Version 9.0 provided the option to choose between CUIC and HRC as the system-wide reporting client. Only one reporting client, CUIC or HRC, could be active at a time. More information about CUIC integration with UCCX in Version 9.0 can be found in New Features in Unified CCX 9.0(1).
HRC will no longer be an option for the historical reporting client in UCCX Version 10.0. No migration path exists for schedules or other configuration in HRC to CUIC, so all schedules must be recreated manually within CUIC after you upgrade the system to UCCX Version 10.0. If CUIC was the configured reporting client in a UCCX Version 9.0 system that is upgraded to Version 10.0, the configuration will be migrated and retained. Additonally, all the historical reports for IP Interactive Voice Response (IVR) deployments are required in order to use CUIC in Versions 10.0 and later.
UCCX Engine Keystore
In UCCX Version 9.0(2) and earlier, the UCCX Engine used the default Java keystore in order to look for Secure Sockets Layer (SSL) certificates when required. In UCCX Version 10.0, the UCCX Engine's keystore will be repointed to the platform's Tomcat keystore.
Typically, the UCCX Engine's keystore would be invoked when script steps such as Get URL Document are connected to a HTTPS target. The default Java keystore contained preinstalled root certificates from well-known third party Certificate Authorities (CA). But, since the default Java keystore was protected by Remote Support Account/root access, customers and partners were not able to upload certificates to the keystore for SSL targets with self-signed certificates or other certificate chains that required manually-populating the keystore with a certificate.
The Tomcat keystore can be accessed through Unified OS Administration, and certificate/certificate chains can be uploaded through the web interface. Although this allows for easy and flexible administration of certificates, the Tomcat and Tomcat-trust keystores contain no preinstalled certificates. This means that all certificates and certificate chains for SSL targets accessed by the UCCX Engine must be manually uploaded to the Tomcat keystore for this functionality to continue to work after the upgrade to UCCX Version 10.0. Once upgraded to UCCX Version 10.0, install all certificate/certificate chains into the platform's Tomcat keystore with the instructions in the UCCX Version 10.0 documentation, and restart the UCCX servers before you test functionality that relies on a secure connection to external targets.
Cisco Agent Desktop (CAD) or Cisco Finesse
UCCX Version 10.0 introduces support for the Finesse Agent Desktop, a web-based agent desktop client. Finesse services run coresident on the UCCX server in parallel to CAD services in UCCX Version 10.0.
You must choose to use CAD or Finesse for all agent desktops when running UCCX Version 10.0. UCCX Version 10 does not support the use of both CAD and Finesse clients for concurrently logged-in agents. At any time, all concurrently logged-in agents must use either CAD or Finesse.
UCCX Version 10.0 does not provide a mechanism to disable CAD services, but does provide a method to disable Finesse services. Finesse is also disabled by default when you install or upgrade to UCCX Version 10.0. Currently, there is no mechanism to migrate configuration from CAD to Finesse including, but not limited to, team configuration, workflows, actions and reason codes.
Retirement of Other UCCX Features
Intelligent Contact Manager (ICM) Parent/Child deployment with UCCX as the child is no longer available in UCCX Version 10.0. There are no migration options available.
CTS 500 Support
UCCX Version 10.0 will no longer support Cisco Telepresence System (CTS) endpoints as agent devices.