In our company we have a callmanager 6.1 cluster. I needed the server for something else and I did a powerdown of the subscriber. The subscriber was the primary callmanager for the phone's/gateways and CTI ports.
The subscriber drive I put on my desk and used a new drive to make a LAB test.
The system was running on publisher for 1 month, and during this time I made several changes like speed dials/BLF, changes in directory numbers, hunt group configuration etc.
So we can be sure that data on pub and sub are not the same anymore.
When I switched on the subscriber, very weird things were happening, suddenly people were logged in or out (Extension Mobility) some BLF and speedials dissapeared, in short is was messy. I solved it by making the pub the primary callmanager for the cluster and after a reset all became stable. I did a cluster reset and when the database was synchronized, I changed callmanager order again.
So it seems to me that you should never do this, and if a subscriber is defect, but not the drive of the sub, but powersupply or motherboard, you should not simply switch on the sub and think that everything will be OK. Doesn't callmanager have a sort mechanism to prevent this?
The sub was disconnected from the newtork, we only had the pub up and running. And I can make changes on the pub (which I did)
Only when the sub was brought back online (with the drive and data from one month ago) we saw that phone's took the "old" data from the subscriber. The primary callmanager was the subscriber, and backup the publisher.
This caused some strange behaviors, like people suddenly logged out or logged in and missing speed dials. Basically they got the status and configuration from one month ago.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...