Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Database Unreachable on Call Forward

CM 3.1(4b)SPD. "Database Unreachable" and reorder tone any time you attempt to CFwdAll. This has been a problem for some time - I've read a few posts on this, pointing to bugs, and had a case open where we were able to identify a database pointer incorrect from the Sub to Pub. However even after fixing, checking db replication and various reboots the problem is still occurring constantly.

8 REPLIES

Re: Database Unreachable on Call Forward

Database unreachable means exactly what it says.

The phone you are trying to set call forward on is registered to a subscriber server, so when you try to set CF the subscriber must verify and write the information to the database on the publisher, however it can't because the subscription is broken somehow.

Try creating a new CM group with just the publisher and move that phone to the new CM group (device pool and all other settings need to be done as well). Then try setting call forward, I bet it works.

Also try logging onto the ccmadmin on the subscriber and making a change to the DB something simple like a dummy route pattern or translation, I think this will fail as well, again proving a broken subscription.

Try re-creating the subscription, though I've never had much luck doing this, the alternative is to re-build the subscriber which I find works every time. This is quite simple if you move all the phones to the publisher and re-build the sub the downtime is minimal, just the time it take to fail over the phones to the subscriber (though I would also advise removing the sub from the CM group until it's fully built).

Paul

New Member

Re: Database Unreachable on Call Forward

Well ... yes and no.

Working with TAC we tried the CM Group/Device Pool test and it did work. However, the problem was somewhat more complicated. I was a bit bleary-eyed by the time this problem was resolved, so some details may be left out:

First, the subscription was working, but apparently pointing to the old database after the upgrade to CM 3.1(4b). The fix is to open the registry to HKLM>Software>Cisco Systems, Inc.>DBL and validate the DBConnection0 and DBConnection1 string values. I recall one was missing, and one was pointing to the wrong database.

Second, Recreated the subscription. This was also wrong.

Still not working - "Database Unreachable" still an issue on all subscriber-homed phones attempting Call Forward. This is where the TAC engineer VPN'd in and went to work.

I vaguely recall the last step was a name resolution problem. He had to run nbtstat -R to reload the name cache table, then entered all the name info in the hosts file. I already had this info in the LMHosts file, but he claimed something with SQL name resolution was the problem. I recall something about a bug preventing certain communication between the SQL agents on the Pub and Sub.

Everything finally worked.

New Member

Re: Database Unreachable on Call Forward

hi

I have tried according to instruction to see the Registry. I found that the DBConnection0 is connection to Publisher and DBconnection1 is connection to Subscriber. No missing point is found.

Do you have any suggestion ???

Silver

Re: Database Unreachable on Call Forward

CSCdy57036 Bug Details

Database failback not always working

First Fixed-in Version 3.2(2.5), 3.4(0.19), 3.4(0.382), 3.3(1.30), 3.3(2.10), 3.4(0.92), 3.4(0.93), 3.2(2)ES46, 3.2(02C)SPG, 3.2(2)ES52

Release Notes

[Symptoms]

When I try to set CallForwardAll on the IP Phone by pushing

CFwdAll, "Database Unreachable" appears on a Phone's display

after entering a directory number.

But I can set CallForwardAll on the web.

A way to recover the CallForwardAll feature is to do

following procedure on the subscriber which IP Phone is registered to:

1)Start>Programs>Admin Tools>Services

2)Stop the Cisco Database Layer Monitor Service

3)Keep that window open

4)Start>Programs>Admin Tools>Component Services

5)On the left window, click Component Services>Computers>My Computer>Click to highlight COM+ Applications

6)Under that folder, right click on DBL, shutdown then start

7)Go back to "services window" and start Cisco Database Layer Monitor Service

[Condition]

I use Cisco CallManager 3.1(2c) patched Support Patch B.

The SQL subscription between the publisher and the subscriber is NOT broken.

There is IP reachability between the publisher and the subscriber.

The publisher isn't down.

[Workaround]

Restart Aupair.

New Member

Re: Database Unreachable on Call Forward

Hi guys,

This post reflects exactly what's going wrong with my system. I run CCM 3.1(3a). This problem however only started occuring after a recent upgarde of the system to the latest upgrade and patch for the CCM Windows 2000 OS and SQl Server. I have tried the suggestion in the post but I am still having the problem.

Any suggestion will be appreciated.

Thanks and best regards,

Ade

New Member

Re: Database Unreachable on Call Forward

HI

I also meet the problem, but it has some difference.

My cluster (PUB and SUB) has been installed the CCM ver 3.1(3a).

I have never upgraded any patch to CCM, But I met the forward problem in the Subscriber.

The subscriber could not update the phone configuration. The error is shown as follows

hkpvg04:80//CCMAdmin/_RemoteScripts/rs_numplan.asp?

_method=updateDirectoryNumber&_mytype=execute&pcount=27&p0=% 7B8ACD0933-1BB64D12-B4BB-99EEAF9.....

I try to reboot the two server but no effect occur.

I observe the SQL database Replication. The subscriber has pulled the data to Publisher. I observe the Publisher. The link Between Publisher is running.

I don't know what's happen ???

New Member

Re: Database Unreachable on Call Forward

Do you have any suggestion to do ???

Is it the Replication Problem ????

New Member

Re: Database Unreachable on Call Forward

Hopefully you all resolved this, but I ran into this today w/ a client running CCM 3.1.1 with plenty of issues from not taking care of an older callmanager install.

Anyway, I upgraded to 3.1.4b SPD, & thanks to the suggestions earlier in the post, this same issue was resolved in about 5 minutes.

Thanks to:

marinaibm - POST-SALE, IBM

Jul 16, 2003, 5:59am PST

CSCdy57036 Bug Details

Thx. BArry in TUcson

129
Views
2
Helpful
8
Replies
CreatePlease to create content