When trying to do same server recovery from 3.2.2c to 3.3, the installation is always interrupted if I select Yes when asked "The Same System Recovery flag was detected. Is this server being configured as a Call Manager Publisher?"
If I select No, the installation will continue, but I can't successfully restore a backup to it then either.
Has anyone seen this?
When doing a backup/restore you MUST be on the same version of CM, thats why the restore is failing.
I'm not sure what you mean by a same server recovery from 3.2.2c to 3.3....
The upgrade process to CM 3.3 requires this. It should ask for MCS.sti during installation, but doesn't so that's why I've been trying to run the restore manually after the fact.
Have you had any resolution to this? I'm having the same problems. I've also tried a new Server install with all the same ip information and hostname. Try to restore from the 3.2.2c mcs.sti file after ccm 3.3 is installed and the box craps itself bigtime... Have to reload the box to even attempt anything again.
From the Cisco documentation, you can load the new stiback 3.5 or higher, backup your 3.2.2c box, install ccm 3.3 fresh and then use the stirestore on the 3.2.2c mcs.sti file and it will pull your data into the new 3.3 database.
Be careful on the versions of backup, Cisco released version 3.18 of the backup utility however the CM 3.3.2 disks only ship with 3.6, so if you do what I did, install 3.18 on the old server - backup - install 3.3.2 - attempt restore then yes the box "craps itself bigtime".
Make sure you install the 3.6 version of the backup that ships with CM 3.3.2 on the CM3.2 machine first, then upgrade the box, then restore using the backup installed with 3.3.2, then upgrade the backup to 3.18.
Also as a little tip, you will have moved the backup file to another location on the network, but once you get past the OS install for 3.3.2 you can copy the file back to a location (<> for example) on the box before the CM install starts, just to save having to restore accross the network.>
Fortunately for me I was using a 7835 so I'd already pulled the drives and was able to just revert back, god help anyone trying this on a 7825.
Even with the correct versions of stibackup, you cannot restore different versions of CallManager backups. The only time you can is during an upgrade installation of CallManager. Instead of performing upgrade on the same physical hardware, I've been trying it on a brand new, identical server. However, the docs don't tell you how to do that.
Here's what you need to do:
Follow the instrux for upgrading stibackup to at least 3.5.6. Then on the original server, there's a folder on D:\ called Recover with two ini files...backup.ini and dbname.ini. After building new server OS, when it prompts you to start installing CallManager, copy over this directory onto the D:\ on the new server. Then, when you run the CallManager 3.3(2) upgrade installation, it will work properly. I've done it a few times now...works like a charm!
Okay, I'm doing the same thing. I have two 7825's. One with 3.2.2(c) on it and the other my upgrade 3.3 box. I've installed the OS as "New" server install on the 3.3 box with the 3.3 discs. Backed up the 3.2.2c box with stiback 3.5.6. copied the "Recover" Directory to the d:\ with the two .ini files and the mcs.sti to c:\ (where it was on 3.2.2 box).
Now You say run the upgrade install of 3.3? Is there anything different I have to do other than just sticking in the CCM 3.3 Install disc?
We tried this in several ways.
When upgradingd you must do it on the same hardware. (on the same box)
When going from one box to another box, you have to install exactly the same software version (and patches)
So if you are gong to upgrade and want to do it peacefully (away from production), you must install the new server to the exact same softwarerelease as the production server.
Then you can upgrade the new server with a backup from the existing and with backupsoftware 3-5-6 (or bether)
When you have done this ,you replace the old with the new server.
This is not the case if you have the same spec hardware on another box.
Perform the backup using the 3-5-6 version that ships with 3.3. make sure you also take a copy of the restore directory.
Then when you do the 3.3 install you simply point it at the backup location, and it will restore and upgrade config.
Addmittedly yes the box you now have is exactly the same as the old server (name and everything) but you don't have to start with all the service packs on it because the box gets wiped in the install proccess anyway, the restore simply picks up all the settings.
just remember when you do the OS part to name the box exactly the same as the production server.
I'm in the following situation:
an old Publisher + Subscriber, with version 3.1(3a) that we want to migrate to 3.3(2) on 2 new servers (different hw).
I've installed stiback 3.5.18 on 3.1(3a) Publisher, made backup, saved recovery directory + MSC.sti file, installed OS on the new server, installed 3.3 Publisher and, after copied recovery directory + MCS.sti, tried to recover: the procedure stops because is unable to stop SQL service.
Question is: the procedure is correct? Could be the problem related to have installed stibackup 3.5.18 on 3.1(3a) and the default version (3.5.6) on 3.3?
Any other suggestions?
Did you install full CM 3.3, then try to do a restore? Or did you select to do a server recovery, rather than a new installation? I believe you have to select a server recovery.
After you install the OS, you need to copy recovery directory to the new server, then run the CM installation.
Let me know if that works for you. I did this from 3.2.2c to 3.3.2 on new hardware, using the 3.5.6 stibackup. I don't think using 3.5.18 would cause the problem.
CM 3.3 upgrade - same server recovery
base system was CM 3.2(2c) spC
shut down power to 2nd drive (used for ghost images)
1) disable HIDS - reboot
2) uninstall stiback 3.4 - reboot
3) install stiback 3.5.6 - get the previous version detected message
4) configure stiback - backup server, cm3.2
5) configure stiback settings - add CHICSLTR1A as a server to CallManager backup
6) run stiback
7) backup c:\stibackup\mcs.sti (local directory) to my workstation
8) backup d:\recover\dbname.ini and d:\recover\backup.ini tomy workstation
9) hardware detection CD 1
* Welcome screen - Next
did not detect the Type of Installation screen (new installation or same server)
shut down and restarted the install
this time the same server recovery screen was presented
"Welcome to cisco ip telephony application server configuration wizard"
all information was filled in - user name, organization, IP address configuration, ...
10) CD 5 - disk imaging process
11) reboot server
12) writing system configuration information
13) "config file isn't found. Please supply config information again" - error message
14) welcome to cisco ip telephony application serverconfiguration wizard
user name - cisco
Organization - cisco
Computer name - CHICSLTR1A
DNS Domain suffix - cisco.com
Workgroup - CALLMANAGER
Date and time zone
IP address configuration
Set Terminal Services - on
15) "writing system configuration information" & server reboots
16) automatic Windows 2000 server install & configuration
17) "please wait while the compaq utilities are updated on your system.
this process may take up to 5 minutes"
18) Set windows Administrator password
19) automatic reboot
20) logon to server - get prompted to insert "Cisco CallManager CD"
21) before starting CM install checked the registry for
HKLM\Software\Cisco Systems Inc\CallManager\IHC - not there
D:\Recover directory is there (dbname.ini, backup.ini)
22) publisher - same server flag detected
23) preparing to install screen (cd rom drive on - wait 5 minutes)
24) welcome to the installshield wizard for CallManager
25) Complete install, password screens
HKLM\Software\Cisco Systems Inc\CallManager\IHC - is there
26) starts CM install (SQL 2000, SQL 2000 SP2, CallManager)
27) reboot server prompt
28) login, windows installer - preparing to install
29) installing Cisco CallManager (stopping services, copying new files, restoring database from backup
30) restore utility screen
31) copied mcs.sti file from my workstation to c:\stibackup on CM server
local directory - c:\stibackup\mcs.sti
click on chicsltr1a - authentication successful message
warning - if you proceed you will overwrite the target server, and all existing data will be lost.
Are you sure you want to proceed?
step 3 of 3 - start and stopping of services
"restoring ccm0302 database chicsltr1a with recovery option"
"Installing Cisco CallManager" - main installation 35 - 45 minutes
"Removing temporary Cisco CallManager files"
32) "You must restart your system for configuration changes made to Cisco CallManager to take effect.
Click Yes to restart now or now if you plan to restart later."
33) logon to CallManager server
34) updating software on phones
I was looking at step 21. At what stage did U copy the recover directory files back to the system....like you did in step 31 with the MCS.STI. As it says "d:\recovery directory is there"
Also in step 10...Using CD5, is this the same CD# if installing on a MCS7825. Thanks
I installed full 3.3 (new installation) and then tried to restore; I'm going to try to have a "same server recovery" OS installation.
I'll let you know the results.
I'm able to restore all the db on Publisher, and I've the last question: during restore process Publisher tries to contact Subscriber, but obviously I wasn't able to contact it (in fact Subscriber was still with version 3.1).
Do you have a situation like mine (Publisher + 1 Subscriber)? If yes, installing Subscriber after the restore didn't cause you any problem? (in my case the installation of Subscriber brings to the creation of another Call Manager Server in web page and the deletion of it cause problems with forwarding calls etc)
What do you think could be the correct procedure after restoring Publisher?
Thanks again for your help.
If you succesfully perfomed an upgrade of the publisher, and the subscriber was known to the publisher before the upgrade, then it should be known to the publisher after the upgrade. It should then be a simple case of upgrading the subscriber. If you have a new server appear then you must have changed the name of the subscriber.
Remember this is SQL based and SQL does not like it if you change the name of a server. Check the name of the name of the subscriber is EXACTLY the same as it was before the upgrade.
Information on Upgrading to CCM 3.3 is available here:
including replacing MCS server with NEW hardware during upgrade.