CUCM 10.5 Subcriber cant make changes

[Roberto Alvarez Perez]

Hello,

We have a client with a deployment of two Call Managers. We just realize that we cannot make changes from the subscriber portal. We receive the following error:

"Error occurred while retrieving information from database. No DELETE permission for numplan".

We have checked the synchronization of the database and everything looks OK.

The status is (2) in all servers.

Any change we make on the Publisher is seen by the subscriber.

Any ideas why this is happening?

Thanks in advance.

[HARIS_HUSSAIN]

Seems like DBReplication is broken.

Follow Below post to drill down the issue

https://supportforums.cisco.com/document/52421/troubleshooting-cucm-database-replication-linux-appliance-model

[Jitender Bhandari]

Hi,

from the PUb do "utils dbreplication status" wait for about 5 min and then do below

utils dbreplication runtimestate

show network cluster

and provide the output to us

JB

[Roberto Alvarez Perez]

Here is the outputs.

admin:utils dbreplication status

Replication status check is now running in background.
Use command 'utils dbreplication runtimestate' to check its progress

The final output will be in file cm/trace/dbl/sdi/ReplicationStatus.2017_05_05_14_48_46.out

Please use "file view activelog cm/trace/dbl/sdi/ReplicationStatus.2017_05_05_14_48_46.out " command to see the output

admin:file view activelog cm/trace/dbl/sdi/ReplicationStatus.2017_05_05_14_48_46.out

Fri May 5 14:48:46 2017 main() DEBUG: -->
Fri May 5 14:48:54 2017 main() DEBUG: Replication cluster summary:
SERVER ID STATE STATUS QUEUE CONNECTION CHANGED
-----------------------------------------------------------------------
g_2_ccm10_5_1_10000_7 2 Active Local 0
g_3_ccm10_5_1_10000_7 3 Active Connected 0 Dec 29 17:56:21
Fri May 5 14:49:06 2017 main() DEBUG: <--

end of the file reached
options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 - 7 of 7) :

admin:utils dbreplication runtimestate

Server Time: Fri May 5 14:53:54 CEST 2017

Cluster Replication State: Replication status command started at: 2017-05-05-14-48
Replication status command COMPLETED 680 tables checked out of 680
Last Completed Table: devicenumplanmapremdestmap
No Errors or Mismatches found.

Use 'file view activelog cm/trace/dbl/sdi/ReplicationStatus.2017_05_05_14_48_46.out' to see the details

DB Version: ccm10_5_1_10000_7
Repltimeout set to: 300s
PROCESS option set to: 1

Cluster Detailed View from nefertari (2 Servers):

PING DB/RPC/ REPL. Replication REPLICATION SETUP
SERVER-NAME IP ADDRESS (msec) DbMon? QUEUE Group ID (RTMT) & Details
----------- ---------- ------ ------- ----- ----------- ------------------
euridice 10.252.100.28 0.295 Y/Y/Y 0 (g_3) (2) Setup Completed
nefertari 10.252.100.27 0.017 Y/Y/Y 0 (g_2) (2) Setup Completed

admin:show net
admin:show network clus
admin:show network cluster
10.252.100.28 euridice Subscriber callmanager DBSub authenticated using TCP since Thu Dec 29 17:46:55 2016
10.252.100.27 nefertari.cnio.es nefertari Publisher callmanager DBPub authenticated

Server Table (processnode) Entries
----------------------------------
10.252.100.28
10.252.100.27

Successful

[Jitender Bhandari]

Your cluster looks good, no replication issue. Can you provide the detail steps of what you are doing when you see this error.

JB

[Roberto Alvarez Perez]

Sure,

Actually is very simple.

We log into the SUB, go to Device --> Phone --> Select one endpoint

Then I tried to modify something. In these case I add "1" to de description. And when I save it I get the error. I attach the pic.

If I make the change in the PUB everything is OK and I see the change also in the SUB.

[Jitender Bhandari]

So you are saying i you login with the same username\password on PUB it would work?

JB

[Jitender Bhandari]

Also Has this Publisher recently experienced a DRS restore operation, as part of a migration or disaster recovery action?  What recent changes have been made to this cluster (upgrade, migration, adding new Subscribers, etc.)?

JB

[Roberto Alvarez Perez]

Here is a nice history.

More or less around the end of December `16 we had a very extrange problem .

The replication of the database stop working, after some troubleshooting the problem we discovered was that the secret password had been changed, but nobody did that change. We didnt do it and the client itself has no idea how to do it.

More interesenting, this cluster was before a version 6.1.3 with a secret pass " X ". We made the update to 10.5 like 2 years ago, in that process we change the secret password (prime collaboration deployment tool) to " Y". The secret password that we found in the server was the secret password the server had before, in the version 6.1.3. So we dont know how, but somehow the secret password was reverted to the old one.

After that we update again the secret password "X" to "Y" and the replication started to work again.

[Jitender Bhandari]

But no DRS restore or rebuild correct?

JB

[Roberto Alvarez Perez]

Correct. We did not perform an restore or rebuild.

[Roberto Alvarez Perez]

Any idea?

[Roberto Alvarez Perez]

Correct!

If I log in the PUB with the same user everything works OK.