I have six Windows 2000 Terminal Servers at SP4 running with approximately 40-50 users on each server. Many times during the day, the terminal server hangs up for 30-90 seconds. Often, the delay seems to be associated with accessing files on a mapped network drive. During the delay, I can access the same network files from a regular W2K PC without any problem. I already have applied fixes 324446 and 828326 which are supposed to resolve many post SP4 terminal services performance problems. Is there another fix which may be specifically related to accessing network files? Should I consider applying Q813130 or Q817446? Thanks, -Kristine

Perhaps the NIC on the the TS is saturated. Have you checked to see how much bandwidth is being consumed on the TS NIC during these times

Patrick Rous
Microsoft MVP - Terminal Serve
http://www.workthin.com

We have a Broadcom NetXtreme Gigabit ethernet card. When I run the performance monitor for bandwidth, I just see a steady 1GB bandwidth available. When I run the performance monitor for NIC Bytes Total/Sec, the most I've ever seen is 908,040 which I think calculates out to only about 7% utilization on a Gigabit card (if I'm calculating right). Is there another performance statistic you can recommend I capture? Thanks!

I have been seeing a lot of Broadcom Gigabit adapters
lately, mostly on Dell servers, but also on some
Supermicro servers, etc. After dealing with Broadcom, the
first thing I tell people when they say they are having a
problem with a Dell server is to disable the onboard NIC
and put in something else. The Broadcom's seem to have a
lot of problems. As long as they are talking to Broadcom
Gigabit, they are fine, but if they have to communicate
with anything running at 10/100, their transfer rate goes
WAY down. I have seen 1 GB file transfers take 3 hours
between a Broadcom Gigabit and an Intel 10/100, with no
other load on the server, but if we made the same transfer
from a 3Com Gigabit NIC to the same Intel 10/100, it was a
matter of a minute or so. Seriously, try putting a
different NIC in there, I think that will solve your
problem.
>-----Original Message-----
>We have a Broadcom NetXtreme Gigabit ethernet card.
When I run the performance monitor for bandwidth, I just
see a steady 1GB bandwidth available. When I run the
performance monitor for NIC Bytes Total/Sec, the most I've
ever seen is 908,040 which I think calculates out to only
about 7% utilization on a Gigabit card (if I'm calculating
right). Is there another performance statistic you can
recommend I capture? Thanks!
>.
>

The symptoms of this problem are interesting. I have come up with a test to see if the problem is occurring or not. I try to re-copy a small file to a folder on the network file server where the target file already exists. When there is no problem I am immediately confronted with a message that the file already exists and asking if I want to replace it. When I'm having the problem, it takes 45 seconds or more for this confirmation message to occur. During this 45 seconds, CPU and network utilization on the terminal server is very low (as if I'm in some sort of wait state), but no one can access any files on this particular network file server. Users on other terminal servers continue to access network files on the same network file server without any problem. Users on the affected terminal server can access other network resources without any problem. After 45 seconds or so, the problem clears up for a few minutes, then occurs again. It may happen on the same terminal server or on another one. Does anyone have any ideas what performance stats I should be looking at to find and resolve this problem? Thanks!

Is there anything in the EventLog on the TS?
Check if this applies to you:

You Experience Slow File Server Performance and Delays Occur When
You Work With Files That Are Located on a File Server
http://support.microsoft.com/?kbid=822219

--
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
http://hem.fyristorg.com/vera/IT
--- please respond in newsgroup ---

"=?Utf-8?B?S3Jpc3RpbmU=?=" <(E-Mail Removed)>
wrote in news:4CA4A037-1C96-4E78-A8B3-(E-Mail Removed):

> The symptoms of this problem are interesting. I have come up
> with a test to see if the problem is occurring or not. I try to
> re-copy a small file to a folder on the network file server
> where the target file already exists. When there is no problem
> I am immediately confronted with a message that the file already
> exists and asking if I want to replace it. When I'm having the
> problem, it takes 45 seconds or more for this confirmation
> message to occur. During this 45 seconds, CPU and network
> utilization on the terminal server is very low (as if I'm in
> some sort of wait state), but no one can access any files on
> this particular network file server. Users on other terminal
> servers continue to access network files on the same network
> file server without any problem. Users on the affected terminal
> server can access other network resources without any problem.
> After 45 seconds or so, the problem clears up for a few minutes,
> then occurs again. It may happen on the same terminal server or
> on another one. Does anyone have any ideas what performance
> stats I should be looking at to find and resolve this problem?
> Thanks!

We do have Veritas Backup Exec with Advanced File Open on our file server. Even though we don't see any of those events in the log, I have put in a question to Veritas Support about whether KB822219 may apply to us.

I ran a Defragmentation report on the file server and saw that it needs to be defragmented. Does this sound like a possible cause of the problem?

A fragmented disk on the file server can also cause performance
problems, of course, but I would expect the problems to be more
consistent. But if you can schedule some downtime of the fileserver,
defragmenting it might help.

--
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
http://hem.fyristorg.com/vera/IT
--- please respond in newsgroup ---

"=?Utf-8?B?S3Jpc3RpbmU=?=" <(E-Mail Removed)>
wrote in news:8109F0C8-CE7E-4CBA-929D-(E-Mail Removed):

> We do have Veritas Backup Exec with Advanced File Open on our
> file server. Even though we don't see any of those events in
> the log, I have put in a question to Veritas Support about
> whether KB822219 may apply to us.
>
> I ran a Defragmentation report on the file server and saw that
> it needs to be defragmented. Does this sound like a possible
> cause of the problem?

I ran a defrag yesterday afternoon, but we're still having the problem this morning. I haven't heard back from Veritas yet about the possibility of KB822219. My file server is also a domain controller. Do you think KB321098 might apply? I don't only have the problem when copying files, but I'm willing to consider any possibility at this point. Thanks!

I defragmented the disk drive on the file server yesterday, but we are still having the problem. I have not heard back yet from Veritas support about KB article 822219. My file server is also a domain controller. Do you think KB article 321098 may apply to my situation? The pauses don't only happen when copying files, but at this point, I'm willing to try anything that might work. Thanks!