2

Okay - the run-down:

INITIAL INSTALL

  • Brought a new Dell rack-mount server up, running Server 2008 Standard x64.
  • All Windows updates, File Services role added; everything completed without issue. Installed FS using 2003 and indexing option, not Windows Search Services.
  • Installed Symantec Endpoint Protection 11.0.6000.645 (AV only - no NTP or email or anything).
  • Robocopied all existing shares from the server (running 2003) and verified them on the 2008 rig (no issues).
  • Deallocated and switched off the 2003 server; renamed the 2008 server to the 2003 server's former network name.

Shortly after migration, users complained of epic slowness. I changed the 2008 server to use WSS instead of 2003/indexing, restarting afterward. Still no joy. I've worked at it all week, trying different options out on the Internet-at-large.

THINGS I'VE TRIED (to no avail)

  • Disabling SMB 2.0 on the server, leaving 1.0 active.
  • Disabling SMB 1.0 on the server, leaving 2.0 active.
  • Disabling SMB on the server, leaving neither version active (NetBIOS only, I guess?).
  • Updating SEP to latest (11.0.7000.975).
  • Uninstalling SEP altogether.
  • Enabling/disabling IPv6 binding.
  • Disabling TCP Offload at the NIC (both IPv4 and IPv6)
  • Pretty much anything I found while hunting the Internets for solutionbeasts.

We have a mixed bag of clients, mostly XP, with some Win7 thrown in (all standard versions, pretty sure all are x86). I can open everything without issue, both from my Win7 (x86) laptop (my standard work machine) and from my XP VM x86 test machine (out on an ESX server). The only difference I can find (that seems like it would matter) is that my stuff is all on one subnet, while the other client machines are on another (x.x.1.x versus x.x.2.x).

I don't understand where the slowness comes from. Certainly, the 2003 server didn't have this problem or the users would've already complained. Any ideas or direction from the one community I trust to actually solve problems would be awesome.

And - I'll apologize in advance if there's actually a thread somewhere that answers just this issue; I just couldn't find it (but not for lack of trying). Thanks, in advance, all.

4
  • This may seem elementary, but have you check to be certain the network card is running at full duplex? Sep 16, 2011 at 13:44
  • It appears that it's set to Auto, if I'm looking in the right place (properties --> configure --> advanced --> speed & duplex (value == auto)). Conferring with my boss, he had me reset that value to "1 Gb Full Auto."
    – Tonweight
    Sep 16, 2011 at 13:56
  • So, it turned out that setting it to "100MB/s Full Auto" "fixed" the problem, in the eyes of the users. I can't say I'm happy with that (since I still don't know why it "fixed" the problem), but - for now, anyway - it's being considered "resolved." Thanks for the comment, just the same, Best-Calvin-and-Hobbes-character-evar. ^_~
    – Tonweight
    Sep 17, 2011 at 13:50
  • 2
    The behavior just seemed characteristic of a half-duplex connection. I'd look into NIC firmware and driver updates, replace the cable, and double check the settings on the other side if it's a managed switch. They should always match, if one side is auto, so should the other. If one side is forced, the other side should have matched settings. Most NICs only do GB at auto-negotiation. Sep 18, 2011 at 14:20

2 Answers 2

2

So, while it's not a total solution, here's the end to this particular episode:

  • used netsh commands to disable all but the TCP chimney (including setting ctcp to "none")
  • enabled all of the options for the network card (QoS, Link-layer stuff, IPv6... most of which were previously disabled), installed latest driver for the same from DELL, and configured the throughput to 100MB/s Full (was previously "auto").
  • Restarted the box.

Most of the changes we made were in relation to another 2008 server we have on the network (my boss had forgotten that he added it) which we used for testing. We had no issues between that box to the user clients, so we did what we could to mirror the configuration on the problem box.

One thing we encountered with the problem box, seemingly at random, was a "BOOTMGR is missing" issue following one of the restarts (after an individual change with a netsh command). I resolved that in the "normal" way: I used the Server 2008 DVD and the recovery tools to resurrect the boot manager.

All things considered, the "solution" feels like a dirty hackjob, but the users feel like it's no longer crap-slow. Ridiculous.

Any other direction or answers are appreciated. I don't feel like this should be marked as an answer, since it really isn't an answer; however, it didn't really feel like an edit either (since I made changes outside of the original question).

0
1

I'm assuming you've already verified that the disk IO subsystem in the new server is capable of serving files at the speeds you're expecting. If you haven't, do that first.

Use something like wsttcp.exe (or an equivalent tool) from a problem client and the server computer to verify that network bandwidth between the machines is as you'd expect. If it isn't start working thru the network stack and gear between the machines to figure out where packets are being dropped on the floor.

If you're finding that the raw network throughput is as you'd expect then I'd sniff some traffic between the problem client and the server and compare it to the same operations conducted from a non-problem client and the server. That ought to give you some clues.

1
  • The network itself doesn't seem to be the issue. There's nothing in the logs from Ethereal that looks like something borked. Thanks for the ideas though, Mr. Anderson. It was worth a shot.
    – Tonweight
    Sep 17, 2011 at 13:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .