CFwdALL error database

Unanswered Question
Jan 3rd, 2008

We're getting "error database" whenever anyone tries to Cfwdall their line. I've gone through knowledge base solution K20424904, but none of the suggestions worked. Previously we reset our "Private Password phrase", but checking this it looks like everytning is in sync. The only event entry that may apply to this is an Application Informational message MSSQLSERVER - Login failed for user '[null'. Reason: Not associated with a trusted SQL server connection.

Not sure how to proceed.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
rob.huffman Thu, 01/03/2008 - 06:19

Hi Frank,

Hope all is well with you! Sounds like a Replication issue :( If the Pub is down or Replication between the Pub and Subs is broken no changes can be made to CFWD ALL. Here is a doc that speaks to this question;

This is a list of possible symptoms if the subscriber stops replicating from the publisher:

Changes that are made on the publisher are not reflected on phones that are registered with the subscriber.

Outbound calls fail on phones registered with the subscriber. As soon as you dial 9 you hear a re-order tone.

Call Forward All (CFwdALL) does not work.

IP phone displays Error Database.

From this doc;

And this good doc;

Cisco CallManager Issues with Call Forward All

Hope this helps!


f.kirstein Thu, 01/03/2008 - 08:04

Hi Rob,

I don't think replication is my problem. I followed the note09186a00801b3f4b instructions for both dblhelper and created a dummy record and verified it existed on the subscriber. I also verified Telephone call dispatcher is active on both publisher and subscriber. Right now I'm at loss.

Ayodeji oladipo... Wed, 01/09/2008 - 14:07


I have seen a case where changes made were seen on the sub as you have done with the dunny record and yet I still have replication problems...

I suggest to you to run dblhelper....and check the status of your not assume anything..check evrything...CFWALL is a sign of replication problem...certainly.

Also make sure you run dblhelper from the the bin directory.

You should also use the admin utility to check password sync across your cluster...

f.kirstein Fri, 01/11/2008 - 13:20

First, I'd like to thank everyone for their responses. In the end, on Cisco's advice, I rebooted the subscriber and it worked. It's likely setting the password phrase, although it's not specified to do so, requires a subscriber reboot.

Thank you again.

gogasca Fri, 01/11/2008 - 22:34

It doesnt

when you run adminutility it stop starts all Cisco Services and SQL services which are using our accounts

gogasca Fri, 01/11/2008 - 22:35

Replication at CCM level was you problem since CCM has internal tables in cache which interacts with SQL via DBL DLLs.

bwilmoth Wed, 01/09/2008 - 06:35

If call forwarding was working before and it stop working, you might have a SQL database replication issue between Publisher and Subscriber.

Please stop and start the DBL service on the Publisher and then subsequently on the Subscriber(s).Restart the DBL service on the Publisher and then on the subscriber(s). If that does not resolve theissue please stop and start the CTI Manager service in the same way. If things are still not working then please try to ping from the subscriber the phones are registered to to the Publisher's hostname. Is the name resolved right away ? Do you have a DNS server setup ? If so, please remove the DNS server config and configure your LMHOSTS file.

f.kirstein Wed, 01/09/2008 - 07:51

This is probably a stupid question, but how do you stop and start the DBL? CTI have been stopped and started with no help.

jbarcena Wed, 01/09/2008 - 09:10

On the server go to Start --> Run and type services.msc a page will open with all the services and just stop and start the Database Layer Monitor service


This Discussion