Solved: CUCM 7.0 subscriber rejecting phone registration

Amjad Hashim · ‎09-03-2010

Hello,

I have recently rebuild my CUCM subscriber, it was installed normally but now the device pool with that subscriber as their first node is not getting registered.

I am getting Error message Registration Rejected: Error DBconn..

I know it is only this call manager because when i move my phone to other device pool which is using seperate call manager it get registered.

The call manager in question is not showing any problem. when i login to that call manager and search for any particular phone it just brings that phone.

it has exactly the same configuration as other subscribers but this one is having issue with it.

I personally think it is a database replication problem but can any body tell me how to make sure that it is database issue and how to fix it?

Note. I am not using auto-registration for phones so don't consider it while answering.

Thanks in advance.

William Bell · ‎09-03-2010

Amjad,

No, you don't need to re-install. Here is a link to the CUCM troubleshooting guide for 7.1 (reference link to DB Replication issues):

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/trouble/7_1_2/tbsystem.html#wp1172876

You have already established you have an issue so I am providing the link for future reference. To resolve the issue I would first try the procedures in Step 6 (http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/trouble/7_1_2/tbsystem.html#wp1184419).

Only do Step 6 if one of the servers showed an RTMT status of 4, or had a status of 0 for more than four hours.

(NOTE: I think you have a subscriber with the "status of 0 for more than four hours")

Step 6 Generate and view the Unified CM Database Status report, which provides debugging information for database replication. For each subscriber server that has a bad RTMT status, check that the hosts, rhosts, sqlhosts, and services files have the appropriate information.

Generate and view the Unified CM Cluster Overview report. Verify that the subscriber servers have the same version, verify that connectivity is good, and verify that time delay is within tolerances.

If the preceding conditions are acceptable, do the following to reset replication on that subscriber server:

a. At the subscriber server, perform the CLI command utils dbreplication stop
Do this for all subscriber servers that have an RTMT value of 4

b. At the publisher server, perform the CLI command utils dbreplication stop

c. At the publisher server, perform the CLI command utils dbreplication reset
where is the hostname of the subscriber server that needs to be reset. If all subscriber servers need to be reset, use command utils dbreplication reset all

HTH.

Regards,

Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

View solution in original post

William Bell · ‎09-03-2010

That most definitely sounds like a replication issue to me.

Do the following on each node in the cluster:

1. ssh to the node

2. Execute commands:

*example*

admin:show network cluster

10.3.4.24 iecups01.cnclab.com iecups01 Subscriber

10.3.4.20 iecucm01.cnclab.com iecucm01 Publisher

10.3.4.21 iecucm02.cnclab.com iecucm02 Subscriber

admin:utils diagnose module validate_network

Log file: platform/log/diag2.log

Starting diagnostic test(s)

===========================

test - validate_network : Pass

Diagnostics Completed

admin:*show perf query class "Number of Replicates Created and State of

Replication"*

==>query class :

- Perf class (Number of Replicates Created and State of Replication) has

instances and values:

ReplicateCount -> Number of Replicates Created = 427

ReplicateCount -> Replicate_State = 2

admin:

For the "show network cluster" command you are looking at the output to

ensure that names and addresses are correct for your environment and

consistent on each cluster node.

The "utils diagnose" command is actually running the validation routine

which a cluster node runs before starting services and coming on line.

Resets to the db replication will fail if there are any problems reported by

this validation module. Just an extra/easy check.

The "show perf" command is giving you a replication state. Ensure that the

replicates created are the same on each node and that the replicate state is

2. If it is something other than 2 you have a replication problem.

It is also prudent to do the following:

1. Create a device (or pick one of your devices that isn't registering)

2. on each node:

2a. Ssh to the cluster node

2b. Execute command:

admin:*run sql select name,description from device where name =

'SEPAAAABBBBCCCC'*

(note: substitute AAAABBBBCCCC with the correct mac of phone or test phone)

Do this on the publisher first and then the subscribers. If you have a

subscriber that isn't showing the info then you have a replication issue.

On the appliance model I have yet to see an inconsistent result with the

"show perf query class" command and the "create a device and check" method.

But on the Windows platforms I have seen where the replication test tools

are happy while db replication is busted. So, that is why I use the last

method.

There are other ways to check replication. You can do this instead or in

addition to the above:

1. You can use the "utils dbreplication status" on the publisher node. This

runs for a few minutes and creates a log file that you would need to view

(with the "file view" command). This can be handy if you see something wrong

in previous steps and want to get a table-by-table view.

2. Cisco Unified Reporting. This is a web portal (like ccmadmin) that you

can use to access reports on your system. Pretty handy. I document it

here:

http://www.netcraftsmen.net/resources/blogs/cucm-checking-replication-status

.html

HTH.

Regards,

Bill

Please remember to rate helpful posts.

On 9/3/10 7:56 AM, "Amjadhashim"

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Amjad Hashim · ‎09-03-2010

Hello William,

Really appreciate your reply, it is really very helpful in finding out the problem. The problem is with database replication as u stated, following is the information of the perf query class command for publisher and affected subscriber.

Publisher

admin:show perf query class "Number of Replicates Created and State of Replicati==>query class :

- Perf class (Number of Replicates Created and State of Replication) has instances and values:
ReplicateCount -> Number of Replicates Created = 412
ReplicateCount -> Replicate_State = 3

Subscriber

admin:show perf query class "Number of Replicates Created and State of Replication"
==>query class :

- Perf class (Number of Replicates Created and State of Replication) has instances and values:
ReplicateCount -> Number of Replicates Created = 412
ReplicateCount -> Replicate_State = 0

Above mentioned subscriber has the problem as visible now, but all other working subscriber and publisher has replicate_state of 3. I am not sure what it is, will you be able to give me any solution or reinstall is the only way?

Regards,

William Bell · ‎09-03-2010

Amjad,

No, you don't need to re-install. Here is a link to the CUCM troubleshooting guide for 7.1 (reference link to DB Replication issues):

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/trouble/7_1_2/tbsystem.html#wp1172876

You have already established you have an issue so I am providing the link for future reference. To resolve the issue I would first try the procedures in Step 6 (http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/trouble/7_1_2/tbsystem.html#wp1184419).

Only do Step 6 if one of the servers showed an RTMT status of 4, or had a status of 0 for more than four hours.

(NOTE: I think you have a subscriber with the "status of 0 for more than four hours")

Step 6 Generate and view the Unified CM Database Status report, which provides debugging information for database replication. For each subscriber server that has a bad RTMT status, check that the hosts, rhosts, sqlhosts, and services files have the appropriate information.

Generate and view the Unified CM Cluster Overview report. Verify that the subscriber servers have the same version, verify that connectivity is good, and verify that time delay is within tolerances.

If the preceding conditions are acceptable, do the following to reset replication on that subscriber server:

a. At the subscriber server, perform the CLI command utils dbreplication stop
Do this for all subscriber servers that have an RTMT value of 4

b. At the publisher server, perform the CLI command utils dbreplication stop

c. At the publisher server, perform the CLI command utils dbreplication reset
where is the hostname of the subscriber server that needs to be reset. If all subscriber servers need to be reset, use command utils dbreplication reset all

HTH.

Regards,

Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Amjad Hashim · ‎09-04-2010

Hello William,

Thanks for reply and help, this is great information. i don't know what was the problem but as it was friday afternoon and after replying to your post with Replication status value from my call managers i thought it might be worth shutting down the interface of the faulty call manager so i did it. After an hour i checked the status of my other call managers it was still 3 so i thought this problem might be there for long but i only noticed it after this problem so i un shut the port of the faulty server.

Today after checking your reply to post i logged in remotely to do the remedy but surprisingly when i checked the status it was all turned to 2. it was just amazing so i tested it by moving my own desk phone to different device pool with faulty call manager as first node and it got registered with that faulty unit.

Really it was surprising to me, is it possible that disabling and enabling an interface has resolved the problem?

I am really thankful for the help and all the information you provided is a new chunk of knowledge for me. i hope u will keep the good work up.

Regards,

Amjad Hashim.