Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recently switched out a 10 year old server for a brand new server in a small office and upgraded from Windows Server 2000 to Windows Server 2008 R2. After the switch was complete and some configurations were changed around we are running into what appear to be some bottlenecks in the network speed. Accessing programs on the server is slower (resulting in long loading times, slower report generation, etc.) than it was on the old server hardware.

I am wondering what options or tools I have, if there are any at all, to find out exactly where these hang ups might be coming from.

share|improve this question
are there any relevant alerts in event logs? also, i would like to suggest microsoft's performance monitor called "Performance monitor". It helped me to debug a few issues i had. – Paul Jul 21 '11 at 17:39
Nothing I have seen of interest in the event log. I am a bit confused as to how the performance monitor could help debug. I see that there are many options but maybe I'm just not understanding the actual usage of the application. – Phil Koury Jul 21 '11 at 20:05
Perfmon - if you know your network can transfer 100MBytes/second and Perfmon shows only 2MBytes/second on the NIC, you know the network is not your bottleneck. That's how you use it - measure CPU, memory, paging, network, disk IO. See which numbers seem to correspond to the slowdown, then work out why. – EightBitTony Jul 21 '11 at 20:48

Perfmon counters and a tool called PAL (Performance Analysis of Logs) which includes a set of thresholds for various counters. It also generates a report which points out which counters exceeded the thresholds.

share|improve this answer

Along with what EightBitTony has pointed out, you can "net out" the network aspects by hard coding the NIC line settings (vs. the default "autodetect") and copying CD or DVD sized transfers for clocking (i.e. with a stopwatch). The multiple timing of the same transfers will help determine any speed fluctuations.

It will also stress the various points/elements that can be monitored via perfmon for variations as well.

share|improve this answer

Running a tracert between your computer and the server, would be useful for discovering if a network node between your computer and the server is the source of network slowdowns. Also, I would recommend establishing a baseline configuration of the new server for monitoring the server's performance.

share|improve this answer

I'd always start with two Microsoft SysInternals tools: Process Explorer and Process Monitor. Plus, in this instance, I'd add Disk View.

Using these you can:

Process Explorer : View CPU, memory and I/O stats (more clearly than the built-in tools)

Process Monitor : Actually watch what the machine is doing. One of the default filters is to drop anything from the "System" process. Turn this filter off when diagnosing a file server issue. However, do turn on "drop filtered events".

Disk View : Watch disk load.

Being a file server, I'm guessing you have Anti-Virus on-access scanning enabled? Plus, you may have volume shadow copy snapshots running? Could you confirm whether this is the case?

Generally, with x64 file servers, I'd recommend setting the page file to "system managed" and keep it on a separate volume. Plus I'd keep a close eye on the "peak commit charge". Having monitored this for a while, you should be able to judge whether more memory is required.

Also, can you post details of the clients (i.e: what os version/edition)?

I've seen issues with XP clients running against Win2008R2. When I remember the specifics, and more importantly, the solution, I'll update this post...

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.