Slow access to network shares under XP

Hello,

I have the following problem:

When accessing a shared folder with a large number of files/subfolders
(around 2000) from any XP client, opening the folder takes 5-6 seconds.

Performing the same task from any win98 client takes less than a second.
The shared folder is located on a win2003 server (pure file server, static
addressing through lmhosts, no domain).

However, in another environment I haven't noticed any such slowdowns in the
similar scenario: XP client, large shared folders, BUT: the XP client and
the file server are domain members (the server is not the DC itself).

I am guessing that this is an XP authentication issue but I can't think of
anything to alleviate this problem. Currently, the authentication is set up
so that I have the same username/password on both the client and the
server. Is this a bad practice?

I have tried mapping the share through the IP address but it didn't help.
TCP/IP is the only protocol used.

Any ideas?

Kind regards,
Vedran

Hi,

I am having the same problem,

So you are not alone.

I have reloaded every thing several times but still have problem.

Looking through the web sites I see a what looks like a pattern to do with
DLINK DFE-530TX+ network cards.

All my systems uses these cards but the server which is a HP Intel card.

The 2003 Server can access the XP Pro system like your 98 systems.

If it is not network cards then must be 2003 server.

Allan


"Vedran Vrbanc" <vvrbanc@bla-hotmail.com> wrote in message
news:MPG.1970f6e5e9577899989687@news.vip.hr...
> Hello,
>
> I have the following problem:
>
> When accessing a shared folder with a large number of files/subfolders
> (around 2000) from any XP client, opening the folder takes 5-6 seconds.
>
> Performing the same task from any win98 client takes less than a second.
> The shared folder is located on a win2003 server (pure file server, static
> addressing through lmhosts, no domain).
>
> However, in another environment I haven't noticed any such slowdowns in
the
> similar scenario: XP client, large shared folders, BUT: the XP client and
> the file server are domain members (the server is not the DC itself).
>
> I am guessing that this is an XP authentication issue but I can't think of
> anything to alleviate this problem. Currently, the authentication is set
up
> so that I have the same username/password on both the client and the
> server. Is this a bad practice?
>
> I have tried mapping the share through the IP address but it didn't help.
> TCP/IP is the only protocol used.
>
> Any ideas?
>
> Kind regards,
> Vedran

Vedran Vrbanc wrote:
> In article <pgKNa.100$pg6.5207@news-server.bigpond.net.au>,
> apps_nt@hotmail.com says...
>
>>Hi,
>>
>>I am having the same problem,
>>
>
> YESSSS I fixx0red it! )
>
> At first I didn't know exactly what fixed it so I compared service/registry
> entries against my laptop (also running XP and slowly opening large
> shares). Thus, I came up with a .reg file and after importing it on the
> laptop, it started browsing shares at a normal speed, too!
>
> Here's the reg branch:
>
> ---begin---
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
> "Tcp1323Opts"=dword:00000002
> "EnablePMTUDiscovery"=dword:00000000
> "EnablePMTUBHDetect"=dword:00000000
> "SackOpts"=dword:00000000
> "GlobalMaxTcpWindowSize"=dword:ffffffff
> "TcpWindowSize"=dword:ffffffff
> "DefaultTTL"=dword:00000000
> "TcpRecvSegmentSize"=dword:00000003
> ---end---
>
> I don't know exactly which of these keys fixed the problem, I didn't have
> time to optimize it yet (and I'm not going to, it's 1 am . Note that
> these settings are applied to all interfaces and you may not really want
> that. A better solution would be to apply the parameters to a specific
> adapter under HKLM_CurrentControlSet\Services\Tcpip\Parameters\Interfaces ,
> supposing that the paramaters are acknowledged by windows (didn't try that
> out, either).
>
> Note that my webclient service is disabled and the following registry key
> is deleted:
>
> KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
> CurrentVersion\Explorer\RemoteComputer\NameSpace\
> {D6277990-4C6A-11CF-8D87-00AA0060F5BF}
>
> These two tweaks may be the prerequisites for fixing the problem.
>
> Let me know if it works out for anyone.
>
> Kind regards,
> Vedran
>
This is the OS Microsoft says is easy to use???

Hi,
It did not work for me looks like I am restoring ghost image of 2000 server
till this problem is fixed.

Allan

"Vedran Vrbanc" <vvrbanc@bla-hotmail.com> wrote in message
news:MPG.1972d0093f743ef698968d@news.vip.hr...
> In article <pgKNa.100$pg6.5207@news-server.bigpond.net.au>,
> apps_nt@hotmail.com says...
> > Hi,
> >
> > I am having the same problem,
> >
> YESSSS I fixx0red it! )
>
> At first I didn't know exactly what fixed it so I compared
service/registry
> entries against my laptop (also running XP and slowly opening large
> shares). Thus, I came up with a .reg file and after importing it on the
> laptop, it started browsing shares at a normal speed, too!
>
> Here's the reg branch:
>
> ---begin---
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
> "Tcp1323Opts"=dword:00000002
> "EnablePMTUDiscovery"=dword:00000000
> "EnablePMTUBHDetect"=dword:00000000
> "SackOpts"=dword:00000000
> "GlobalMaxTcpWindowSize"=dword:ffffffff
> "TcpWindowSize"=dword:ffffffff
> "DefaultTTL"=dword:00000000
> "TcpRecvSegmentSize"=dword:00000003
> ---end---
>
> I don't know exactly which of these keys fixed the problem, I didn't have
> time to optimize it yet (and I'm not going to, it's 1 am . Note that
> these settings are applied to all interfaces and you may not really want
> that. A better solution would be to apply the parameters to a specific
> adapter under HKLM_CurrentControlSet\Services\Tcpip\Parameters\Interfaces
,
> supposing that the paramaters are acknowledged by windows (didn't try that
> out, either).
>
> Note that my webclient service is disabled and the following registry key
> is deleted:
>
> KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
> CurrentVersion\Explorer\RemoteComputer\NameSpace\
> {D6277990-4C6A-11CF-8D87-00AA0060F5BF}
>
> These two tweaks may be the prerequisites for fixing the problem.
>
> Let me know if it works out for anyone.
>
> Kind regards,
> Vedran
>