01-03-2008 06:11 AM - edited 03-15-2019 08:01 AM
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.
01-03-2008 06:19 AM
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;
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801e7ddf.shtml
And this good doc;
Cisco CallManager Issues with Call Forward All
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801b3f4b.shtml
Hope this helps!
Rob
01-03-2008 08:04 AM
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.
01-09-2008 02:07 PM
Kirstein,
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 replication...do 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...
01-11-2008 01:20 PM
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.
01-11-2008 10:34 PM
It doesnt
when you run adminutility it stop starts all Cisco Services and SQL services which are using our accounts
01-11-2008 10:35 PM
Replication at CCM level was you problem since CCM has internal tables in cache which interacts with SQL via DBL DLLs.
01-09-2008 06:35 AM
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.
01-09-2008 07:51 AM
This is probably a stupid question, but how do you stop and start the DBL? CTI have been stopped and started with no help.
01-09-2008 09:10 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide