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.
Verify these items before you begin the upgrade:
Run the latest OS/BIOS patches.
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
an SQLSvc Account Password.
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
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
Disable all Cisco approved anti virus and intrusion detection
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.
This document is not restricted to specific software and hardware
Technical Tips Conventions for more information on document
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
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
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
Server C is the backup Cisco CallManager for all registered
In this configuration, only a single Cisco CallManager redundancy group
is required for servers B and C.
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
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.
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.
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
Cisco CallManager cluster for up to 5000 users:
Server A is a dedicated database publisher and TFTP
Server B is the primary Cisco CallManager for IP phones 1 through
Server C is the primary Cisco CallManager for IP phones 2501 through
Server D is the backup Cisco CallManager for all registered
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
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.
Publisher A is upgraded first. Then, Cisco CallManager D should be
upgraded. Up to this point, call processing has not been
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.
Upgrade Cisco CallManager C. There is a slight interruption of
service as the devices register with Cisco CallManager D and receive firmware
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
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
Server D is the primary Cisco CallManager for IP phones 2501 through
Server E is the backup Cisco CallManager for IP phones 1 through
Server F is the primary Cisco CallManager for IP phones 5001 through
Server G is the primary Cisco CallManager for IP phones 7501 through
Server H is the backup Cisco CallManager for IP phones 5001 through
In this configuration, four Cisco CallManager redundancy groups are
required for servers CE, DE, FH and GH. This diagram illustrates this
Upgrade the publisher.
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.
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
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
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.
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
Follow these rules when you upgrade Cisco CallManager:
Always upgrade the publisher and standalone TFTP server (if exists)
Upgrade the backup Cisco CallManagers second.
Upgrade the primary Cisco CallManagers last.
After all Cisco CallManagers are upgraded, all servers must be
Make sure that when the SA and Administrator passwords are set they
are the same for all servers in the cluster.
Gather these logs:
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.
Gather these logs:
All *.txt & *.log files in the root directory
All files in the C: \Program Files\Common Files\Cisco\Logs
All files in the STI_DATA partition
All files in the C:\DCDSrvr\log (if issues are with DCD)
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.
Obtain and review all log files (*.log and *.txt) from these
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.
Cisco CallManager 4.x for more information.
Note: Use Admin Utility only in Publisher in order to solve password
Note: Not all errors relate to real problems. Always verify before you open
a case with Cisco Technical Support.
Event Logs for more information. This document is updated
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.