Migration and upgrade considerations
This section sets general upgrade guidelines that apply to all of the following upgrade paths.
Linux to Linux (L2) upgrade
There is very little server downtime during an L2 upgrade. An L2 upgrade is accomplished by installing the new software release in the inactive partition while the node continues to run and operate on the existing software in the active partition. The software releases are switched on reboot. The reboot can be either automatic, after the new software release is installed, or initiated manually at a later time through an administrator command. Some examples of an L2 upgrade are upgrades from Release 6.1(3) to 7.1(5), from 7.1(2) to 8.0(3), or from 8.6(1) to 9.1(1).
Because an L2 upgrade can install the new release in the inactive partition while the existing release is still running, the actual downtime for an L2 upgrade is only the reboot time for the node after the upgrade finishes and while switching releases.
A Refresh Upgrade is required in situations where incompatibilities exist between the old and new software releases. The new software installation is disallowed in the inactive partition while the node continues to run on the software in the active partition. This upgrade requires the node to reboot much earlier in the upgrade process, and the node will be off line while the new software release is installed. The only defined Refresh Upgrade path for Cisco Unified Communications Manager is from Release 8.5(x) and earlier releases to 8.6(1) or later. Some examples of Refresh Upgrades are upgrades from Release 8.0(3) to 8.6(1), from 8.5(1) to 8.6(2), from 7.1(5) to 8.6(1), or from 8.5(1) to 9.1(1).
When you perform a Refresh Upgrade, the downtime of the node is much longer than that of an L2 upgrade. A typical Refresh Upgrade takes between 1 and 4 hours, depending on the size of the database. During the upgrade, the Cisco Unified Communications Manager node is off line — plan accordingly.
Refresh upgrades on 7825H3 and 7828H3 servers
During a Refresh Upgrade, the installation process reconfigures RAID on the MCS 7825H3 and 7828H3 server. All data is exported to an external USB drive during the upgrade. After the RAID is reconfigured and the operating system is installed, the installation process uses the data on the USB drive to upgrade the server to the new release.
During the reconfiguration of the RAID, all data is erased from the hard drives.
In case of a failure during the Refresh Upgrade on these systems, there is no way to switch back to the previous release (as seen in upgrades on other server models). You must restore these servers from a DRS backup.
No other models require RAID reconfiguration.
Because of the risk of failure, Cisco recommends that you avoid refresh upgrades on the MCS 7825H3 and 7828H3 servers. While these platforms support Release 9.1(1), Cisco recommends that you virtualize at Release 8.0(3), rather than Release 9.1(1), to avoid a Refresh Upgrade on the MCS 7825H3 and 7828H3 servers.
Upgrade of all cluster nodes
Do not install subscribers as new.
Cisco recommends that you upgrade ALL servers in a cluster at the same time (with respect to the proper upgrade order within the cluster). Upgrading just the publisher node and then rebuilding the subscriber/utility nodes will result in a loss of node-specific data on the subscriber or utility node when that node is brought online. A brief list of features or data that is missing from nodes installed as new includes, but is not limited to:
Nonstandard or Cisco Options Package (COP) – installed phone firmware
Music on hold (MOH) files
Trace and Log Central Scheduling jobs
Production network upgrade
You must upgrade a Cisco Unified Communications Manager cluster on the production network. Cisco does not support installation of Cisco Unified Communications products in a lab or deadnet environment. When you install Cisco Unified Communications servers, the server must access network resources that may not be available in the lab network.
Network services such as DNS, LDAP, NTP and default gateways are critical to the successful deployment of a Cisco Unified Communications Manager server. Although the deployment may succeed in the lab, latent installation issues may arise later in the production environment that can adversely affect call processing. For this reason, Cisco does not support installation of a Cisco Unified Communications Manager in a lab or deadnet environment.
Some legacy MCS servers support only newer releases of Cisco Unified Communications Manager in Bridge Mode. Bridge Mode means that the server has not been certified to run that release but can be used to migrate from MCS hardware to a virtual deployment. While in Bridge Mode, the Cisco Unified Communications Manager services will not start and moves, adds, changes, or deletes are not allowed.
A cluster cannot operate in Bridge Mode for an extended period of time. A server in Bridge Mode allows only a DRS backup that is used to restore the server node onto a new virtual machine installation.
Enterprise License Manager
Enterprise License Manager provides simplified, enterprise-wide management of user-based licensing, including license fulfillment. Enterprise License Manager handles licensing fulfillment, supports allocation and reconciliation of licenses across supported products, and provides enterprise-level reporting of usage and entitlement.
The Enterprise License Manager application is installed coresident, by default, on any Cisco Unified Communications Manager or Cisco Unity Connection nodes that are upgraded (or fresh installed) to Release 9.x.
You can also install Enterprise License Manager as a standalone application on a separate MCS server or virtual machine. This document applies exclusively to the co-resident deployment.
For additional details on Enterprise License Manager and deployment options, refer to the Cisco Unified Communications System 9.x SRND. For additional information about using Enterprise License Manager, refer to the Enterprise License Manager User Guide on Cisco.com.
Before you begin any of the following upgrade paths, see Appendix A, which enables you to determine whether you require the “Direct-to-Release 9.x” or “Virtualize at Release 8.0” upgrade path.
Baseline release requirements for upgrades directly to Release 9.x
The release of Cisco Unified Communications Manager that you are running may influence your choice of upgrade path as much as the Cisco Media Convergence Server (MCS) hardware that Cisco Unified Communications Manager is running on. The “Direct to Release 9.1 Upgrade Path” is supported only from Release 6.1(4) to 6.1(5)SU3 and 7.1(3) and later. If you are running a release that is not listed here, such as Release 6.1(3) or 7.1(2), use the “Virtualize at Release 8.0 Upgrade Path.” If your Cisco Unified Communications Manager release is not on the list of supported releases that are upgradable to Release 8.0(3), the first step is to upgrade to a release that is compatible with either Release 8.0(3) or Release 9.1(1), depending on the MCS hardware support in either Release 8.0(3) or Release 9.1(1).
DRS backup requirements
Cisco strongly recommends that you perform a DRS backup up of the entire cluster before and at key stages of the upgrade process. Upgrading without a current backup can result in lost data, lost node configuration, or disruption in services if there are complications during the upgrade process.