[cisco-voip] Callforward all keeps getting stuck

Tue Apr 3 11:12:08 EDT 2007

Make sure CSA is updated as a precaution.  Older CSA had a policy  
that would block certain registry access by LSASS that can lead to  
handle leaks and potentially BSOD.

The database layer monitor service (aupair) is not related to SQL  
replication but is very important for change notification (on the  
pub).  Among other things this service monitors the db for change  
notification and this is one place where CFA can fail.

-Ryan

On Apr 3, 2007, at 11:08 AM, Ed Leatherman wrote:

Sorry Ryan, I assumed that was a problem with replication (which in  
turn could be caused by a connectivity problem). I should have  
reviewed my information before posting. I'm seeing kDbConnection  
Failed errors from the DBLM service on the publisher node around the  
time we see saw the problem this morning, was making me think  
database replication problem.

I just wish I could find some indication of what the problem is, some  
of the subscriber nodes are on the same switch/VLAN as the pub, and  
they are seeing the problem also when it occurs.. but I dont see  
anything to indicated those interfaces went down or otherwise had  
problems. Perhaps something on the pub is breaking it... bout the  
only other thing I have running there is CSA and antivirus.

On 4/3/07, Ryan Ratliff <rratliff at cisco.com> wrote: /rant on
The ONLY time database replication will cause an issue is when your
publisher goes away and subs start using their local database.

AT NO OTHER POINT will it cause issues.  This is especially true for
CFA failures, since if your pub is down CFA is not going to work anyhow.

You may have connectivity issues where DB replication failure is a
symptom, but it is just that, a symptom (and a pretty minor one at
that).  If your subs cannot connect to the pub you've got much bigger
issues than replication.  DBLHelper is nice and all, but all it shows
you is if your SQL jobs are running (on the replication tab anyway).

I swear a part of my inner troubleshooter dies a little bit every
time I see somebody bust out DBLHelper as the first step in
troubleshooting a completely unrelated problem.  "My MOH is broken,
but DBLHelper says everything is fine!"...  "I put this firewall
between my CMs and now I can't make any calls between those servers,
but DBLHelper is all smileys!"

/rant off

If you go searching the archives for this list I've sent several
emails in the past on how to troubleshoot CFA failures in 4.x.  There
were some pretty big architectural changes that have exposed some
issues with change notification.  Thankfully they go away in 5.x.

-Ryan

On Apr 3, 2007, at 9:50 AM, Lelio Fulgenzi wrote:

I'm convinced that it has to do with the replication of databases and
nothing to do with CallManager version.

Even the dblhelper tool can't illustrate with any confidence that
your databases are in sync. It might work to show you that they are
out of sync, but if you see all smiley faces, don't trust your cat's
life on it.

------------------------------------------------------------------------
--------
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...there's no such thing as a bad timbit...
----- Original Message -----
From: Ed Leatherman
To: ciscovoip
Sent: Tuesday, April 03, 2007 9:46 AM
Subject: [cisco-voip] Callforward all keeps getting stuck

Hello,

We've had an ongoing problem with the callforward all feature on the
phones ever since we went from ccm 3.x for 4.x. usually it would only
happen maybe once every couple months... while still very annoying we
could live with it. I've probably opened 4 different TAC SR's on it,
with little success in actually fixing it.

Basically we have people who forward their lines to another number or
to voicemail, and then they cannot remove the forwarding, nor can we
do it from CCMadmin.

For some reason the past week i've had it happen almost everyday. The
work around is very easy, just restarting the DBL monitor service on
all the nodes in the cluster fixes the problem. But its still an
interuption of service for alot of departments. I'm going to open yet
another TAC case on it.. but does anyone have any suggestions on a
possible cause? I don't believe we're having a networking problem but
i'm open to suggestions. Currently running ccm 4.1.3sr4d.

-- 
Ed Leatherman
Senior Voice Engineer
West Virginia University
Telecommunications and Network Operations

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-- 
Ed Leatherman
Senior Voice Engineer
West Virginia University
Telecommunications and Network Operations