Cisco Unified Communications Manager (CallManager)

Tips for a Successful Upgrade to Cisco CallManager 3.3

Document ID: 40741

Updated: Oct 31, 2006



Technical Support has received an increase in the number of cases related to Cisco CallManager 3.3 upgrade issues. Most of these cases could be avoided if the proper upgrade procedure is followed. From the most repetitive issues, a list of tips is created that can help you to ensure a successful upgrade. Some useful logs are listed that show how the upgrade progresses, as well as whether if it is completed successfully. These logs can also be used to open a case with Technical Support if anything in the upgrade process fails. This document only applies to upgrade on the publisher, for the subscriber(s) consult the documentation.

Note: This document does not replace the upgrade document on It is absolutely necessary that you consult Upgrading Cisco CallManager Release 3.3(2) before you upgrade. Customers should be aware of these bugs before they attemptg the upgrade: Cisco bug ID CSCdy17885 (registered customers only) and Cisco bug ID CSCea32780 (registered customers only) .



Readers of this document should read these documents before they upgrade:

Components Used

The information in this document is based on the Cisco CallManager Release 3.3(2)

The information presented in this document is created from devices in a specific lab environment. All of the devices used in this document started with a clear (default) configuration. If you are to work in a live network, ensure that you understand the potential impact of any command before you use it.


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

Upgrade Tips

  • Consult the Cisco CallManager Compatibility Matrix to determine from which versions you can upgrade.

  • For the initial upgrade or installation to Cisco CallManager 3.3, you requir the CD-ROM kit. If you have a Software Support Contract, refer Product Upgrade Tool (registered customers only) and/or contact your Cisco sales representative. The upgrade cannot be downloaded from

  • The first step in the upgrade procedure is to take a backup of your current system. It is mandatory for the backup utility to be of version 3.5.6 or later. If an earlier version of the backup utility is used, you will not be able to restore from the backup. Version 3.5.6 creates a RECOVER directory in the STI_PARTITION with two files: dbname.ini and backup.ini. These two files are essential for a successful upgrade. Before you start the Operating System (OS) installation, verify that the RECOVER directory with the two files has been created. Also verify that the backup of the system is completed successfully.

  • If you are upgrading to 3.3.3, you may receive the message, "BkupFileCk: ERR: Please upgrade your backup program to version 3.5.44 or higher." Uninstall 3.5.6 and install 3.5.44 or later. Consult Using Cisco IP Telephony Applications Backup Utility, Version 3.5.44

  • Verify the backup of the system is completed successfully. Consult Using Cisco IP Telephony Applications Backup Utility, Version 3.5.6. This document explains if the backup was successful.

  • Before you start with the OS installation do these:

    • Write down the current database in use. Go to CCMADMIN > Help > About CallManager > Details. This is useful if the upgrade fails and there is a need to manually create the different ini files.

    • Collect the STIback.log and copy to a different location. This file is useful in case you experience any issues during the upgrade process.

    • Copy the hosts and lmhosts files to a different location. After the OS installation is complete, but before you start with the Cisco CallManager installation, these files need to be copied back to the server. After you have done this, execute the nbtstat –R command from the command prompt.

  • If you are to upgrade your Cisco CallManager, then during the OS installation, ensure that you select the option Same Server Recovery. If you select another option, the STI_DATA partition will be reformatted and the RECOVER directory will be deleted, which will lead to an upgrade failure.

  • During the OS installation you may be prompted with "I am recovering a system from backup".

    caution Caution: Do not select this option.

  • If you are to replace an existing CallManager with a new server (built with the same name and ip address), you must copy the RECOVER directory in the STI_PARTITION to the new server.

  • When the OS installation has finished you need to provide a password for the Windows Administrator account. This password cannot be blank, nor can it contain any of these characters: \ % “ ^. This is a DC Directory software restriction. If your password contains any of these special characters, the DC Directory installation fails and consequently, the Cisco CallManager installation. If you require a password with special characters, you need to first complete the installation on the entire cluster. Once completed, you can manually change the Windows Administrator password (with special characters if necessary). However, because of the DC Directory limitations, it is advisable for you to keep the Windows password as alphanumeric and not include any of the special characters mentioned above.

  • Do not place the server in a DOMAIN during the upgrade or installation. All Cisco CallManagers must be out of the domain until every server in the cluster is up.

  • When the backup is stored on a network drive, pay attention to these when you restore:

    • In the network path, specify the correct path. Ensure that the path you specify is a valid Universal Naming Convention (UNC) path, for example \\backupserver\backup\MCS.sti. Use the Browse option to locate the MCS.sti file. When you use Browse, ensure that the Network Directory is empty.

    • Click Verify to verify the specified account.

    • If you are to use names, make sure they are resolvable. Never skip this section, as the database needs to be restored before the actual CallManager 3.3 installation. If the server fails to resolve the names, the upgrade procedure will fail.

  • Apply Support Patch A after the installation of the complete cluster has finished.

Troubleshoot the Installation

CCMINST Date/Time Log

This is the first log file to look at when you experience any issue with the upgrade. Key points in the upgrade process are described here.

If you are to upgrade, you have to select "Same System Recovery." If you do this, you see these in the log file:

20:00:01: fnCheckRecoveryFlag:          Function started.
20:00:01: fnCheckRecoveryFlag:          The Same System Recovery flag was detected.  
Is this server being configured as a Cisco CallManager Publisher?
20:00:10: fnCheckRecoveryFlag:          User responded "Yes" to message box.
20:00:10: fnCheckRecoveryFlag:          Function ended.

If you do not select this, you see these in the log file:

14:25:25: fnCheckRecoveryFlag:          Function started.
14:25:25: fnCheckRecoveryFlag:          D:\stiRecover.flg was not found.
14:25:25: fnCheckRecoveryFlag:          Function ended.

The consequence is that the installation continues, but you are not able to restore the backup before the actual Cisco CallManager installation. Therefore, the database from the backup cannot be migrated to a 3.3 schema.

The OS version has to be 2000.2.3. If you run the correct version, you see these in the log file:

Action start 14:27:39: MSICheckOSVersion.
02/18/2003 14:27:40.515(W) --> MSICheckOSVersion()
02/18/2003 14:27:40.531(W) Getting 'MinOSVersion' MSI property
02/18/2003 14:27:40.531(W) Retrieved a valid string from MSI property
02/18/2003 14:27:40.531(W) Min OS version: [2000.2.3]
02/18/2003 14:27:40.531(W) MinOSMajor: [2000]
02/18/2003 14:27:40.546(W) MinOSMinor: [2]
02/18/2003 14:27:40.546(W) MinOSPoint: [3]
02/18/2003 14:27:40.546(W) Opened registry key
02/18/2003 14:27:40.546(W) Retrieved OSVersion string from registry
02/18/2003 14:27:40.546(W) Actual OS Major: [2000]
02/18/2003 14:27:40.546(W)Actual OS Minor: [2]
02/18/2003 14:27:40.546(W) Actual OS Point: [3]
02/18/2003 14:27:40.578(W) Current OS version meets minimum requirements
02/18/2003 14:27:40.593(W) <-- MSICheckOSVersion()
Action ended 14:27:40: MSICheckOSVersion. Return value 1.
Action start 14:27:40: MSICheckTSSession.

If you run a different version, you see these in the log file:

Action start 14:56:53: MSICheckOSVersion.
02/20/2003 14:56:57.339(W) --> MSICheckOSVersion()
02/20/2003 14:56:57.380(W) Getting 'MinOSVersion' MSI property
02/20/2003 14:56:57.410(W) Retrieved a valid string from MSI property
02/20/2003 14:56:57.410(W) Min OS version: [2000.2.3]
02/20/2003 14:56:57.410(W) MinOSMajor: [2000]
02/20/2003 14:56:57.420(W) MinOSMinor: [2]
02/20/2003 14:56:57.420(W) MinOSPoint: [3]
02/20/2003 14:56:57.420(W) Opened registry key
02/20/2003 14:56:57.420(W) Retrieved OSVersion string from registry
02/20/2003 14:56:57.420(W) Actual OS Major: [2000]
02/20/2003 14:56:57.420(W) Actual OS Minor: [1]
02/20/2003 14:56:57.420(W) Actual OS Point: [2]
02/20/2003 14:56:57.470(W) Current OS version does not meet minimum requirements

As a consequence, the upgrade stops and Cisco CallManager is not installed.

The upgrade process has to merge the dbname.ini back into the registry. If the backup is taken with the correct version and this file is created, you see these in the log file:

Action start 20:05:06: MergeToReg_dbname.ini.
Action ended 20:05:06: MergeToReg_dbname.ini. Return value 1.
20:06:31: MSIUtils.cpp: fnGetRegValue:           Function started
20:06:31: MSIUtils.cpp: fnGetRegValue:            
Inc.\CallManager\IHC\DBNAME = "CCM0304"
20:06:31: MSIUtils.cpp: fnGetRegValue:           Closed first registry key.
20:06:31: MSIUtils.cpp: fnGetRegValue:           Closed second registry key.
20:06:31: MSIUtils.cpp: fnGetRegValue:           Function ended
20:06:31: GetDBName.cpp: fnValidateDBNAME:        Function started
20:06:31: GetDBName.cpp: fnValidateDBNAME:        "CCM0304" is a valid database name format for a 
CallManager publisher.
20:06:31: GetDBName.cpp: fnValidateDBNAME:        Function ended
20:06:31: GetDBName.cpp: fnGetDBName:     Function ended

If the backup is taken with the incorrect version, you see following in the log file:

17:41:39: MSIUtils.cpp: fnGetRegValue:           Function started
17:41:39: MSIUtils.cpp: fnGetRegValue:           Unable to open registry key 
17:41:39: MSIUtils.cpp: fnGetRegValue:           RegOpenKeyEx failed.  Error 2: The system cannot find the 
file specified.
17:41:39: MSIUtils.cpp: fnGetRegValue:           Function ended
17:41:39: GetDBName.cpp: fnGetDBName:     Error: fnGetRegValue returned: 1603
17:41:39: GetDBName.cpp: fnGetDBName:     Function ended

As a consequence, the upgrade stops and Cisco CallManager is not installed.

Information for Opening a Technical Support Case

Should you need to open a Technical Support case, provide us with this information:

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

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

  • All files in the STI_DATA partition

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

  • All files in the directory C:\Install\DBInstall\*.*

  • All files in the directory C:\Winnt\sti*.*

  • The database name

  • The STIback.log

Related Information

Updated: Oct 31, 2006
Document ID: 40741