Windows 2003 Server - Slow transfer To and From Mapped Drives

I have an issue with a relatively straightforward client-server arrangement.
We have one server (configured as a DC, Exchange 2003 Server, and as the
principle file server).

There are approximately 30 to 40 workstations (all running XP Professional),
so th along on the infrastructure (100 Mbps switched) is relatively light.

All clients connect to a number of mapped drives on the server, which are
used for departmental and user file sharing. The problem appears to be a
very slow transfer between the client and the server (and vice-versa) to
these mapped locations. With even a small transfer of few megabytes taking
minutes to complete, whereas transfers between the workstations are much
quicker and take but a few seconds for the same size files.

Locally the server runs perfectly (with plenty of Processing, RAM and HDD
capacity), as does its network interface (which is connected at 1 Gbps).

I have read that disabling the SMB signing and changing the TCP ACK
frequency can help, but i have not noticed any improvement after making the
suggested changes.

I really don’t know where to start resolving this problem, and so hope you
can point me in the right direction.

Many thanks in anticipation of your most welcome assistance.



--
Nicholas Combellack

I am migrating from NW to MSAD and this file copy stuff has reared up ugly
here as well. hardware, gigabit adapters/cisco3750, other servers/stuff
running just fine. just something particular about the windows on some
machines.

two examples-
Server A maps to Server B and takes hundreds of minutes to copy a folder
(about 300MB size is irrelevant) revers the mapping and Server B can pull the
file over in normal speed. (both boxes S2003standard)

Today, I try Arcserve to the new MSF&P server and get 5MB/min backup to
disk.. (should be 600+) Whoa! Test a file copy and see the same outrageous
performance. S2003SP1-->w2000 laptop sloooow, but if I go the other way,
normal.

this solution should be obvious to a MS expert! and hopefully solves a lot
of problems
--
system engineer


"Nicholas Combellack" wrote:

> I have an issue with a relatively straightforward client-server arrangement.
> We have one server (configured as a DC, Exchange 2003 Server, and as the
> principle file server).
>
> There are approximately 30 to 40 workstations (all running XP Professional),
> so th along on the infrastructure (100 Mbps switched) is relatively light.
>
> All clients connect to a number of mapped drives on the server, which are
> used for departmental and user file sharing. The problem appears to be a
> very slow transfer between the client and the server (and vice-versa) to
> these mapped locations. With even a small transfer of few megabytes taking
> minutes to complete, whereas transfers between the workstations are much
> quicker and take but a few seconds for the same size files.
>
> Locally the server runs perfectly (with plenty of Processing, RAM and HDD
> capacity), as does its network interface (which is connected at 1 Gbps).
>
> I have read that disabling the SMB signing and changing the TCP ACK
> frequency can help, but i have not noticed any improvement after making the
> suggested changes.
>
> I really don’t know where to start resolving this problem, and so hope you
> can point me in the right direction.
>
> Many thanks in anticipation of your most welcome assistance.
>
>
>
> --
> Nicholas Combellack
>

solved the second problem. this is a new server and it got plugged into an
avail switchport that was set to 100/Full. GigNIC was set to auto.
Eventviewer reported this could lead to mismatch, and sure enough- GNic chose
100/half. set both parties to auto and get the gig connection and fast
transfer.

This could be an issue with the other example, but not likely. then again-
auto magical isn't always perfect.
--
system engineer


"craig" wrote:

> I am migrating from NW to MSAD and this file copy stuff has reared up ugly
> here as well. hardware, gigabit adapters/cisco3750, other servers/stuff
> running just fine. just something particular about the windows on some
> machines.
>
> two examples-
> Server A maps to Server B and takes hundreds of minutes to copy a folder
> (about 300MB size is irrelevant) revers the mapping and Server B can pull the
> file over in normal speed. (both boxes S2003standard)
>
> Today, I try Arcserve to the new MSF&P server and get 5MB/min backup to
> disk.. (should be 600+) Whoa! Test a file copy and see the same outrageous
> performance. S2003SP1-->w2000 laptop sloooow, but if I go the other way,
> normal.
>
> this solution should be obvious to a MS expert! and hopefully solves a lot
> of problems
> --
> system engineer
>
>
> "Nicholas Combellack" wrote:
>
> > I have an issue with a relatively straightforward client-server arrangement.
> > We have one server (configured as a DC, Exchange 2003 Server, and as the
> > principle file server).
> >
> > There are approximately 30 to 40 workstations (all running XP Professional),
> > so th along on the infrastructure (100 Mbps switched) is relatively light.
> >
> > All clients connect to a number of mapped drives on the server, which are
> > used for departmental and user file sharing. The problem appears to be a
> > very slow transfer between the client and the server (and vice-versa) to
> > these mapped locations. With even a small transfer of few megabytes taking
> > minutes to complete, whereas transfers between the workstations are much
> > quicker and take but a few seconds for the same size files.
> >
> > Locally the server runs perfectly (with plenty of Processing, RAM and HDD
> > capacity), as does its network interface (which is connected at 1 Gbps).
> >
> > I have read that disabling the SMB signing and changing the TCP ACK
> > frequency can help, but i have not noticed any improvement after making the
> > suggested changes.
> >
> > I really don’t know where to start resolving this problem, and so hope you
> > can point me in the right direction.
> >
> > Many thanks in anticipation of your most welcome assistance.
> >
> >
> >
> > --
> > Nicholas Combellack
> >