Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Telephony Server slows down, and down and down....

33 views
Skip to first unread message

Simon

unread,
Jan 25, 2006, 9:21:03 AM1/25/06
to
Hi folks

At my wits end. I have 2 production servers. Each one is Windows 2000
Server SP4 with all updates. One of these servers was my TAPI server.
Yesterday, our TAPI clients started receiving events up to a minute after the
event occurred. This is true of our client and also Julmar phone. I
restarted the server and, for a couple of hours, it was working again. Then
it slowed to a crawl - sometimes the delay was minutes!

I disabled every possible additional service so I have no virus scanner, no
network packet stuff - just a vanilla box. Still happens.

To keep our production environment running, I moved TAPI to the other
server. Completely different box with no common hardware, again Windows 2000
Server SP with all updates. The same thing is happening! I tried Julmar
phone on the server, selected a line, opened a session then lifted the phone.
About 30 seconds later, I saw the events!

I don't know where the problem might be or even how to start troubleshooting
this. Any suggestions? I can't understand why this has suddenly started
on 2 different servers. The only common link I can find is the OS and patch
levels. Might this be caused by a recent Microsoft update?

Extremely grateful for any clues as the boss is busting my hump...

Cheers

Andreas Marschall [MVP TAPI]

unread,
Jan 25, 2006, 11:03:53 AM1/25/06
to
"Simon" <Si...@discussions.microsoft.com> schrieb im Newsbeitrag
news:F4567296-9838-495E...@microsoft.com...

Simon,
what TSP are you using on the Telephony server?

We encountered serious delays (upto 3minutes) with a 3rd party TSP when
using it via MS RemoteSP.TSP at various customer sites and in the my lab.

Common to all affected sites is the usage of XP/SP2 clients (other client OS
are sometimes used in parallel and are affected by the delay too).
Further testing showed that the XP/SP2 Windows-Firewall is causing this!
If you disable the firewall on all XP/SP2 clients then there is no delay.
Attention: if the firewall is enabled on only one XP/SP2 client then all
clients and the server are encountering these delays!!!

For analysis I've built a Virtual Server environment with these VMs (all fully
patched via Windows-Update):
- WS2k3 Std. SP1 english as DC
- XP Pro SP2 english as 1.Client
- XP Pro SP2 english as 2.Client

The XP/SP2 Windows-Firewall has been left configured like it is installed by
XP-Setup, i.e. turned on.
As soon as the 1st client did a lineOpen via Remote TSP the delays started to
occur.

After some more testing it turned out that it is sufficient to just enable
File and Printer Sharing as a Windows-Firewall Exception rule via control
panel to get rid of the delays.
But any single PC in the domain that doesn't do so is messing up the whole
domain!
So I worked out a Group Policy to enforce this Windows-Firewall Exception:
- Administrative Tools / Active Directory Users and Computers
- Properties <your DOMAIN>
- Tab "Group Policy"
- New: "New Group Policy Object"
- Options "New Group Policy Object": No Override
- Properties "New Group Policy Object": Disable User Configuration settings
- Edit " New Group Policy Object": Computer Configuration / Administrative
Templates / Network / Network Connections / Windows Firewall / Domain Profile
- Setting "Windows Firewall: Allow file and printer sharing exception":
Enable, localsubnet
After enrollment of this group policy on reboot of all clients the issue is
reliable solved because no client can accidently change the setting.

Some additional links on XP/SP2 firewall from KB / TechNet:
-
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/depfwset/wfsp2apa.mspx#EJAA
-
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/02e1b4dc-00a7-41b1-8610-38d43d5e5d5d.mspx#BKMK_AdminPack
-
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/depfwset/wfsp2apa.mspx
-
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngdepgp.mspx#ECAA
- http://www.microsoft.com/technet/prodtechnol/winxppro/support/wftshoot.mspx
- http://support.microsoft.com/kb/886264/en-us
- http://support.microsoft.com/kb/842242/en-us
- http://support.microsoft.com/kb/875357/en-us

--
Best Regards
Andreas Marschall
Microsoft MVP for TAPI / Windows SDK
TAPI / TSP Developer and Tester
My TAPI and TSPI FAQ:
http://www.I-B-A-M.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm
My Toto® Tools (a collection of free, mostly TAPI related tools):
http://www.i-b-a-m.de/Andreas_Marschall's_Toto_Tools.htm
TAPI development around the world (Frappr! map):
http://www.frappr.com/TAPIaroundTheWorld
* Please post all messages and replies to the newsgroup so all may
* benefit from the discussion. Private mail is usually not replied to.
* This posting is provided "AS IS" with no warranties, and confers no rights.

Simon

unread,
Jan 25, 2006, 5:42:03 PM1/25/06
to
Hi Andreas. Thank you very much for the response. I do know about the SP2
firewall issue including the File/Print sharing exception but I was not aware
about the catch of this problem of ANY client in the domain tripping you up.
That would explain the sudden appearance of the problem. You asked about the
TSP, it's Cisco Call Manager 4.1 and has performed perfectly for several
months so I suspect your testing and suggestions are more likely. I'll check
this out tomorrow and post back a result. In the meantime, thanks again for
your assistance.

Best regards

Simon

Andreas Marschall [MVP TAPI]

unread,
Jan 25, 2006, 6:14:56 PM1/25/06
to
"Simon" <Si...@discussions.microsoft.com> schrieb im Newsbeitrag
news:C4091C9F-7A69-49FC...@microsoft.com...

> Hi Andreas. Thank you very much for the response. I do know about the SP2
> firewall issue including the File/Print sharing exception but I was not
aware
> about the catch of this problem of ANY client in the domain tripping you up.
> That would explain the sudden appearance of the problem. You asked about
the
> TSP, it's Cisco Call Manager 4.1 and has performed perfectly for several
> months so I suspect your testing and suggestions are more likely. I'll
check
> this out tomorrow and post back a result. In the meantime, thanks again for
> your assistance.

Simon, you are welcome.
Thanks for the feedback.

0 new messages