Guest

Cisco Unified Communications Manager (CallManager)

Upgrading a Cisco CallManager Cluster

Document ID: 7426

Updated: Apr 12, 2007

   Print

Introduction

This document is intended to provide some high level suggestions for how to upgrade a Cisco CallManager cluster. The installation notes that accompany the Cisco CallManager software give all of the detailed information regarding installation steps. This document, however, addresses some of the other issues that a cluster upgrade presents.

Prerequisites

Requirements

Verify these items before you begin the upgrade:

  • Run the latest OS/BIOS patches.

    Refer to Cisco IP Telephony BIOS and Operating System Version Roadmap for information on how to keep your Cisco IP Telephony servers up to date.

  • Verify that the MSSQL service runs. If not, verify the SQLSvc password.

    Refer to Recovering an SQLSvc Account Password.

  • View the Cisco Unified Communications Manager Software Compatibility Matrix for IP Telephony solutions compatibility information.

  • Verify that all servers in your cluster use the same DB under START > RUN > REGEDIT > HKEY_LOCAL_MACHINE\Software\Cisco systems, inc\DBL.

    Verify that DBConnection 0 (under SERVER=Publisher name and DATABASE=CCM030X) is the latest one on the publisher server, whereas DBConnection 1 should point to the subscriber name and to the latest Cisco CallManager database.

  • Verify that replication is ok on all servers that use Microsoft SQL Enterprise Manager. This is located at Start > Programs > Microsoft SQL Server 7.0 > Enterprise Manager.

  • Disable all Cisco approved anti virus and intrusion detection services.

  • You have more than 1 Gig of free space. This is recommended.

    Note: Make sure to disable the CallManager traces and delete the unused files such as trace files in order to free up the space.

  • Do not use Terminal services, as it is not supported. Instead, use Virtual Network Computing (VNC) which is supported.

Note: If you have a raid controller, take one disk out before you upgrade and make sure you have a backup of the last version. This enables you to go back to the previous working configuration in case the upgrade fails.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Upgrade the Publisher

Since the Cisco CallManager cluster is based around a publisher/subscriber database relationship, it is important to upgrade the publisher first. When an upgrade occurs, a new database is created on the publisher and data from the old database is migrated to it. This enables any new changes to the database schema to be easily handled. When subscribers are added, they subscribe to the new database on the publisher. That is why the publisher must be upgraded first. A subscriber cannot subscribe to a database that does not exist yet. This diagram illustrates the publisher/subscriber relationship, as well as the call signaling relationship.

Note: The CallManager Server that has CTI ID = 1 can be identified as the Publisher Server. In order to find the CTI ID, go to CCM Admin Webpage > System > Cisco CallManager, from the search result click on the server and check the CTI ID.

40784.gif

Do I Have to Bring All of the Cisco CallManagers Down for an Upgrade?

No. In a large campus, it can be taxing on a Dynamic Host Configuration Protocol (DHCP) server to receive IP address requests from thousands of phones for a couple of hours. Or, it might be undesirable for all phone services to be down for an extended upgrade time. While upgrades should be performed after hours, it is possible in many cases to keep a part of the cluster running during an upgrade. This can be done by utilizing the Cisco CallManager redundancy groups. Essentially, while one server is upgraded, the backup supports all of the phones. This document discusses three standard deployment models.

Recommended Cluster Configurations

2,500 Phones - Three Servers Total

Cisco CallManager cluster for up to 2500 users:

  • Server A is a dedicated database publisher and Trivial File Transfer Protocol (TFTP) server.

  • Server B is the primary Cisco CallManager for all registered devices.

  • Server C is the backup Cisco CallManager for all registered devices.

In this configuration, only a single Cisco CallManager redundancy group is required for servers B and C.

  1. Since the publisher is the first to be upgraded, this is where the process begins. Publisher A is only the database server, so it can be upgraded and rebooted.

  2. The upgrade can begin for Cisco CallManager C. Since Cisco CallManager C is the backup and has no devices registered to it, call processing is not interrupted. Additionally, if you upgrade the backup Cisco CallManager before the primary Cisco CallManager, this ensures that devices only need to upgrade their firmware one time.

  3. The primary Cisco CallManager B can be upgraded. When the upgrade starts, the Cisco CallManager service is stopped and the devices failover to the backup Cisco CallManager C. There is a slight interruption in service while the devices register and receive firmware updates.

  4. The final step of the upgrade process is to reboot all of the servers in the cluster. Start by rebooting Publisher A. Once the reboot is complete, reboot Cisco CallManager B. When the server comes back on line, wait 5 to 10 minutes to allow the devices to begin the failback process. Finally, reboot Cisco CallManager C. The cluster upgrade is now complete.

5,000 Phones - Four Servers Total

Cisco CallManager cluster for up to 5000 users:

  • Server A is a dedicated database publisher and TFTP server.

  • Server B is the primary Cisco CallManager for IP phones 1 through 2500.

  • Server C is the primary Cisco CallManager for IP phones 2501 through 5000.

  • Server D is the backup Cisco CallManager for all registered devices.

In this configuration, two Cisco CallManager redundancy groups are required. One is for servers B and D and the other is for servers C and D.

In this scenario, there are two primary Cisco CallManagers with one backup. If each primary has 2,500 phones, you cannot stop both primary servers for upgrade purposes. The backup would end up with 5,000 devices, which would violate the 2,500 limit.

  1. Publisher A is upgraded first. Then, Cisco CallManager D should be upgraded. Up to this point, call processing has not been interrupted.

  2. Once Cisco CallManager D is up again, begin the upgrade on Cisco CallManager B. Once the upgrade starts, the devices failover to Cisco CallManager D. There is a slight interruption of service as the devices register and receive firmware updates. When Cisco CallManager B comes back on line, wait 5 to 10 minutes for the devices to failback.

  3. Upgrade Cisco CallManager C. There is a slight interruption of service as the devices register with Cisco CallManager D and receive firmware updates.

  4. In order to finish the upgrade process, all the servers in the cluster must be rebooted. Reboot Publisher A first. When the reboot completes, reboot Cisco CallManager B. When B comes back on line, wait 5 to 10 minutes for the devices to failback. Next, reboot Cisco CallManager C and wait until the server comes back on line. Finally, reboot Cisco CallManager D. The cluster upgrade is now complete. This situation causes half the phones to be down for the time of the second primary upgrade. While this is not ideal, it does minimize how many phones are down and how long they are down for.

10,000 Phones - Eight Servers Total

Cisco CallManager cluster for up to 10,000 users:

  • Server A is a dedicated database publisher.

  • Server B is a dedicated TFTP server.

  • Server C is the primary Cisco CallManager for IP phones 1 through 2500.

  • Server D is the primary Cisco CallManager for IP phones 2501 through 5000.

  • Server E is the backup Cisco CallManager for IP phones 1 through 5000.

  • Server F is the primary Cisco CallManager for IP phones 5001 through 7500.

  • Server G is the primary Cisco CallManager for IP phones 7501 through 10,000.

  • Server H is the backup Cisco CallManager for IP phones 5001 through 10,000.

In this configuration, four Cisco CallManager redundancy groups are required for servers CE, DE, FH and GH. This diagram illustrates this configuration:

42657.gif

  1. Upgrade the publisher.

  2. Upgrade the TFTP server.

    At this point, all six Cisco CallManager servers still run and have not been impacted by the upgrade. This scenario is just like the one described in the 5,000 Phones scenario. The only difference is that there are two sets of two primaries with a backup. The primary Cisco CallManagers are C, D, F, and G. The backups are E and H. Primary C and D fail to E. Primary F and G fail to H.

  3. The backup Cisco CallManagers E and H should be upgraded next. When the upgrade completes, wait for the servers to reboot and come back on line.

  4. Now Cisco CallManagers C and F are ready to be upgraded. When the upgrade begins, the devices registered to these Cisco CallManagers failover to the backups. There is a slight interruption of service while the devices register and receive firmware updates. Wait 5 to 10 minutes for the devices to failback.

  5. Next, Cisco CallManagers D and G are upgraded. As in step 4, there is a slight interruption in service. When the upgrade completes, wait for the servers to reboot and come back on line.

  6. In order to finish the upgrade, all of the servers in the cluster must be rebooted. Make sure that each reboot process is complete before you start the next group. Begin by rebooting Publisher A. Next, reboot TFTP B. When B is back on line, reboot Cisco CallManagers C and F. Wait 5 to 10 minutes for the devices to failback and then reboot Cisco CallManagers D and G. Finally, reboot Cisco CallManagers E and H. The cluster upgrade is now complete.

Review: The Rules of the Cisco CallManager Upgrade

Follow these rules when you upgrade Cisco CallManager:

  • Always upgrade the publisher and standalone TFTP server (if exists) first.

  • Upgrade the backup Cisco CallManagers second.

  • Upgrade the primary Cisco CallManagers last.

  • After all Cisco CallManagers are upgraded, all servers must be rebooted.

  • Make sure that when the SA and Administrator passwords are set they are the same for all servers in the cluster.

What to do When Installation/Upgrade Fails?

Cisco CallManager 3.1 and 3.2

Gather these logs:

  • C:\*.log

  • C:\*.txt

  • C:\Winnt\sti*.*

  • C:\dcdsrvr\log\*.* (if issue is with DCD)

  • C:\Install\DBInstall\*.*

The StiSetup.log provides an overview of the different stages during the installation/upgrade. The Dbinstall000.log provides an overview on what changes are done on the database level.

Cisco CallManager 3.3

Gather these logs:

  • All *.txt & *.log files in the root directory C:\

  • All files in the C: \Program Files\Common Files\Cisco\Logs directory

  • All files in the STI_DATA partition

  • All files in the C:\DCDSrvr\log (if issues are with DCD) directory)

The CCMInst<date><time>.log provides an overview of the different stages during the installation/upgrade. The CCMDBSetup<date><time>.log provides an overview on what changes are done on the database level.

Cisco CallManager 4.x

Obtain and review all log files (*.log and *.txt) from these directories:

  • All files in the C:\Program Files\Common Files\Cisco\Logs

  • All files in the C:\Program Files\Common Files\Cisco\Directory

  • All files in the C:\Install\DBInstall

  • All files in the C:\Dcdsrvr\log

Not all error messages that display in the log file are catastrophic. MSI generates error messages in the log file for many reasons. For example, attempts to access a service that Cisco CallManager does not use.

Refer to Upgrading Cisco CallManager 4.x for more information.

Note: Use Admin Utility only in Publisher in order to solve password synchronization problems.

Event Viewer: Application and System Logs in .evt Format

Note: Not all errors relate to real problems. Always verify before you open a case with Cisco Technical Support.

Refer to CallManager Event Logs for more information. This document is updated frequently.

The logs that you gather are useful for the TAC engineer to investigate your issue in depth. Therefore, always update the TAC case with these logs as this speeds up the resolution process.

Related Information

Updated: Apr 12, 2007
Document ID: 7426