CUCM failover to subscriber failure!

Question

Hi everyone!
I have a CUCM cluster of one publisher and one subscriber, active version 7.0 and inactive version 5.1.3
The pubslisher failed due to a power failure, the Cisco DB wasn't  starting at all, and there was no DRS backup.  Anyway, I did an upgrade  from 5.1 to 7.0 again on the publisher while the telephony was  operational normally on the subscriber node.
After the  upgrade, I uploaded the Publisher's and Subscriber's licenses, I added  back all the changes done to the CUCM between the databases of 5 and 7  (manually added by comparing to the subscriber's) and I replicated to  the subscriber when I was done and the replication state was good '2'. And I took an immediate DRS backup.
However, the problem appeared when I restarted the  CUCM's publisher node and none of the phones registered with the  subscriber node. I thought it was a network problem or server going  slow. I turned the publisher off for around 20 mins and nothing changed.
The  configuration of the Call Manager group is correct, the licenses are  correct, everything seem to be ok. When the phones are registered with  the publisher, I can see them registered from the subscriber's phone  page but when I stop the publisher, they turn to 'unknown'.
Does  anyone have any clue why this is happening? Do I have to upgrade the  subscriber again from 5 to 7? I just had this clue in mind, it doesn't  make sense to me since replication is working fine between the servers.
One  more thing, I use FreeSshd to do the DRS backup on an XP machine, it  wasn't connecting on my laptop with Windows 7. What are you guys using  on Windows 7? Tried a search result on Google but nothing worked.
Thank you for reading and for tips!
Regards,
Mazen

Answer 1

Hi Mazen,
I think you are on the right track with your thought of re-building
the Subscriber
You would be hitting this CUCM 5.x restriction;
Replacing the Publisher Node
Complete the following tasks to replace the Cisco Unified CallManager publisher server. If you are replacing a single server that is not part of a cluster, follow this procedure to replace your server.
Caution     If you are replacing a publisher node in a cluster, you must also reinstall all the subscriber nodes and dedicated TFTP servers in the cluster, after replacing the publisher node. For instructions on reinstalling these other nodes types, see the "Replacing a Subscriber or Dedicated TFTP Server Node" section
Follow the references in the For More Information column to get more information about a step.
Table 4     Replacing the Publisher Node Process Overview
Description For More Information
Step 1
Perform the tasks in the "Server or Cluster Replacement Preparation Checklist" section.
"Server or Cluster Replacement Preparation Checklist" section
Step 2
Gather the necessary information about the old publisher server.
"Gathering System Configuration Information to Replace or Reinstall a Server" section
Step 3
Back up the publisher server to a remote SFTP server by using the Disaster Recovery System (DRS) and verify that you have a good backup.
"Creating a Backup File" section
Step 4
Get the new license and verify it before system replacement.
You only need a new license if you are replacing the publisher node.
See the "Obtaining a License File" section.
Step 5
Shut down and turn off the old server.
Step 6
Connect the new server.
Step 7
Install the same Cisco Unified CallManager release on the new server that was installed on the old server, including any Engineering Special releases.
Configure the server as the publisher server for the cluster.
"Installing Cisco Unified CallManager on the New Publisher Server" section
Step 8
Upload the new license file to the publisher server.
"Uploading a License File" section
Step 9
Restore backed up data to the publisher server by using DRS.
"Restoring a Backup File" section
Step 10
Reboot the publisher server.
Step 11
Perform the post-replacement tasks in the "Post-Replacement Checklist" section.
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/5_1/clstr513.html#wp87717
Cheers!
Rob