We do have a similar configuration as far as distance is concerned, 2 of the subs are not local. Near as I can tell though the problem yesterday was cluster wide, or at least it was occuring both at the "remote" site and also affecting phones registered to subs sitting right beside the publisher. We were seeing #3 I guess, there were no error messages on the phones. Not using any third party apps on the servers other than AV.
<br><br>Some users were complaining that they could not set forwarding at all (i experienced this on my desk phone as well). Others were able to but the animated forwarding icon would not go away.<br><br><div><span class="gmail_quote">
On 4/7/06, <b class="gmail_sendername">Wes Sisk</b> <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="direction: ltr;">
Ed,<br>
<br>
we have seen a strong correlation between CFA failures and CM servers
separated by some distance of network rather than CM's being connected
to immediately adjacent switches.<br>
<br>
there are 3 primary steps to setting CFA:<br>
1. phone tells primary CM it wants to set CFA<br>
2. primary CM tells publisher to set CFA<br>
3. publisher tells all CMs in the cluster CFA has been set.<br>
<br>
if 2 fails you get a database error on the ipphone<br>
if 3 fails you set CFA and receive no error but phone does not fwd.<br>
<br>
#2 is performed through DCOM - DBLHelper does not test this. dtcping
and rpcping from microsoft can test DCOM RPC's but that's about it.
Being RPC based the communication uses multiple random ephemereal ports
and connects are established dynamically.<br>
#3 is performed through a TCP session from aupair.exe on a random port
on the publisher to ccm.exe on port TCP:7727 of some random server in
the cluster. Usually when we see CFA failures we find out the random
server is remote from the rest of the servers in the cluster. Note if
aupair.exe does not detect any change notifications pending it may not
establish this session to port 7727. I have seen this problem only once
when someone used a 3rd party (not MS or Cisco) database management app
on the SQL instance running on the CM publisher and it removed all
triggers from the CCM database.<br>
<br>
/Wes<br>
<br>
Ed Leatherman wrote:
<blockquote cite="http://mid94a1afde0604061134g7ad39093ye4ae61ee508f5f16@mail.gmail.com" type="cite"></blockquote></div><div style="direction: ltr;"><span class="e" id="q_10a7468d3a202ef6_1">Anyone having problems with CFWDAll not working every now
and then? I've been having trouble with it ever since we upgraded to
4.0.. albeit they are getting less frequent as I apply various SR's. We
just had a burp this morning with it and I had to reload DBL Mon this
morning to fix it.. was relatively painless but kinda annoying to still
be having these problems. So wondering if anyone else is having it
happen. We're running 4.1(3)SR3a now.<br clear="all">
<br>
-- <br>
Ed Leatherman<br>
IP Telephony Coordinator<br>
West Virginia University<br>
Telecommunications and Network Operations
</span></div><div style="direction: ltr;"><pre><hr size="4" width="90%">
_______________________________________________<br>cisco-voip mailing list<br></pre></div><div style="direction: ltr;"><span class="q"><a href="mailto:cisco-voip@puck.nether.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
cisco-voip@puck.nether.net</a>
</span></div><div style="direction: ltr;"><span class="q"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://puck.nether.net/mailman/listinfo/cisco-voip
</a>
</span></div><div style="direction: ltr;">
</div></blockquote></div><br><br clear="all"><br>-- <br>Ed Leatherman<br>IP Telephony Coordinator<br>West Virginia University<br>Telecommunications and Network Operations