Understanding the Upgrade Process
Types of upgrades
There are two types of upgrades:
The server automatically determines whether you need to perform a standard upgrade or a refresh upgrade.
Standard upgrades
Standard upgrades are upgrades that do not require upgrades to the operating system. You can install upgrade software on your server while the system continues to operate.
For standard upgrades, you install the upgrade software as an inactive version. The system continues to function normally while you are installing the software. When the upgrade is complete, you can choose to automatically reboot the system to the upgraded software or you can manually switch to the new software at a later time. When you reboot to the new software, the old software version remains on the system. This allows you to switch back to the old version in the unlikely event of issues with the new software. During an upgrade your configuration information migrates automatically to the upgraded version.
 Note | You can only make changes to the database on the active software. The database for the inactive software is not updated. If you make changes to the database after an upgrade, you must repeat those changes after switching to the new software. |
Refresh upgrades
Refresh upgrades are required in situations where incompatibilities exist between the old and new software releases. For example, a refresh upgrade is required when the major version of the operating system changes between the version you are upgrading from and the version that you are upgrading to. Refresh upgrades require multiple reboots during installation to upgrade the underlying operating system, causing a temporary server outage while the software is installed. The duration of this outage will depend on your configuration and the size of the database. A typical refresh upgrade takes between 1 and 4 hours per node.
Note | You must perform all refresh upgrades during a maintenance window because the system will not be available during the upgrade. |
For refresh upgrades, the upgrade wizard allows you to choose whether or not to automatically run the new upgrade software when the upgrade completes. If you select not to run the new software, the system will reboot to the old software version when the upgrade is complete and you can manually switch to the new software at a later time.
If for any reason you decide to revert to the prior software version, you can switch versions to the older version of the software. This switch version requires a reboot. Be aware that any configuration changes that you made after upgrading the software will be lost.
Activating the New Software Version
When you upgrade a node, the new software is installed as an inactive version. To activate the new software, you must switch the node to the new software version. There are two ways to switch to the new software version:
- automatic switching—the system switches the version automatically as part of the upgrade process
- manual switching—you switch the version using the OS Administration interface after the upgrade process is complete
The method that you choose depends on the type of upgrade that you are doing. During the upgrade process, the wizard prompts you to choose whether to switch the software version automatically by rebooting to the upgraded partition, or whether to switch the version manually at a later time. The table below lists the switching method to use for each type of upgrade.
Upgrade type |
Switching type |
When prompted, choose . . . |
Result |
|---|---|---|---|
Standard upgrade |
Automatic |
Reboot to upgraded partition |
When you choose this option, the system reboots to the new software version. |
Manual |
Do not reboot after upgrade | When you choose this option, the system continues to run the old software version when the upgrade is complete. You can manually switch to the new software at a later time. |
|
Refresh upgrade |
Manual |
Do not switch to new version after upgrade |
Use this option only if you are performing a refresh upgrade in stages. When you choose this option the system reboots to the old software version when the upgrade is complete and you manually switch to the new software at a later time. When you use this upgrade method, you must switch your publisher node to the new software version before you upgrade your subscriber nodes. |
Automatic |
Switch to new version after upgrade |
Choose this option to use the new software version immediately following the upgrade. When you use this upgrade method, you must switch your publisher node to the new software version before you upgrade your subscriber nodes. |
When you switch versions, your configuration information migrates automatically to the upgraded version on the active partition.
If for any reason you decide to back out of the upgrade, you can restart the system to the inactive partition that contains the older version of the software. However, any configuration changes that you made since you upgraded the software will be lost.
For a short period of time after you install Cisco Unified Communications Manager or switch over after upgrading to a different product version, any changes made by phone users may be lost. Examples of phone user settings include call forwarding and message waiting indication light settings. This can occur because Cisco Unified Communications Manager synchronizes the database after an installation or upgrade, which can overwrite phone user settings changes.
Publisher Nodes and Subscriber Nodes
Within a cluster, there is a database publisher for each type of node that you install.
When you install Unified Communications Manager, the installation wizard prompts you to specify whether the node you are installing is the first node in the cluster. The first Unified Communications Manager node that you install becomes the publisher node, because it publishes the voice and video database to the other Unified Communications Manager nodes in the cluster. All subsequent nodes in the cluster are called subscriber nodes. Each subscriber node must be associated with the publisher node. You must set up all subscriber nodes in the system topology on the publisher node before you install the software on the subscriber nodes.
When you install IM and Presence nodes, the first node that you install functions as the server for the IM and Presence database. Because this node publishes the database for all of the IM and Presence nodes in the cluster, it is referred to as the IM and Presence database publisher; however, you must install this and all other IM and Presence nodes as subscribers of the Unified Communications Manager publisher node. As with other subscriber nodes, you must add these in the system topology before you install the software.
Export Unrestricted
This release of Cisco Unified Communications Manager and IM and Presence Service supports an export unrestricted (XU) version.
Note | Unrestricted versions of software are intended only for a very specific set of customers who do not want various security capabilities; unrestricted versions are not intended for general deployments. |
Export unrestricted versions differs from restricted versions as follows:
- Encryption of user payload (information exchange) is not supported.
- External SIP interdomain federation with Microsoft OCS/Lync or AOL is not supported.
- After you install an unrestricted release, you can never upgrade to a restricted version. A fresh install of a restricted version on a system that contains an unrestricted version is also not supported.
- All nodes within a single cluster must be in the same mode. For example, Cisco Unified Communications Manager and IM and Presence nodes in the same cluster must either all be in unrestricted mode or all be in restricted mode.
- IP phone security configurations will be modified to disable signaling and media encryption (including encryption provided by the VPN phone feature)
Note | Be aware that after you install an unrestricted release, you can never upgrade to a restricted version. You are not allowed to perform a fresh installation of a restricted version on a system that contains an unrestricted version. |
For all Graphical User Interfaces (GUIs) and Command Line Interfaces (CLIs), the Administrator can view the product version (restricted or export unrestricted).
The following table describes the GUI items that are not available for the export unrestricted version of IM and Presence.
|
Export unrestricted GUI item location |
Description |
|
Cisco Unified CM IM and Presence Administration |
|
|
You cannot check the Enable XMPP Client to IM/P Service Secure Mode setting. |
|
|
You cannot check the Enable XMPP Router-to-Router Secure Mode setting. |
|
|
You cannot check the Enable Web Client to IM/P Service Secure Mode setting. |
|
|
The option to set SIP intra-cluster Proxy-to-Proxy Transport Protocol to TLS has been removed. |
|
|
All TLS options have been removed for the Transport Preferred Order parameter. |
|
|
The TLS option has been removed from the SIP Route Header Transport Type parameter. |
|
|
When you configure interdomain federation to OCS/Lync, you will receive warning popup to indicate that it is only possible to directly federate with another OCS/Lync within the enterprise. Interdomain federation to OCS/Lync outside the enterprise is not supported in unrestricted mode. |
|
|
You cannot configure the security mode; It is set to "NO TLS". |
|
|
You cannot set any TLS or HTTPS listeners as the preferred proxy listener. |
|
Feedback