Delay occurs when initially opening a mapped drive

[Guest]

On my Windows 2000 workstation, when I initially open a mapped drive to a Windows 2000 server, a 7-10 second delay occurs before I see any files. (While waiting for this caching operation, I hear a lot of disk activity on my machine.) Once this "caching operation" completes, I can then proceed to open any series of nested folders within the mapped drive without experiencing any delay. If I leave the session idle for a period of a few minutes, the caching operation occurs again.

I tried the registry hack "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" to set NtfsDisableLastAccessUpdate to "1" and it didn't help

This problem only occurs on my machine... If I use another workstation, the problem doesn't occur. Anybody have any ideas

 

[Rick]

On my Windows 2000 workstation, when I initially open a mapped drive to a Windows 2000 server, a 7-10 second delay occurs before I

see any files. (While waiting for this caching operation, I hear a lot of disk activity on my machine.) Once this "caching
operation" completes, I can then proceed to open any series of nested folders within the mapped drive without experiencing any
delay. If I leave the session idle for a period of a few minutes, the caching operation occurs again.

I tried the registry hack "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" to set NtfsDisableLastAccessUpdate to "1" and it didn't help.

This problem only occurs on my machine... If I use another workstation, the problem doesn't occur. Anybody have any ideas?

I bet you have Novell client software installed. If so, you have
three options:

-- Live with it until Novell fixes the problem

-- Uninstall the Novell client software

-- Follow this procedure to work around the problem:
(copied from a post
(OK, it's not a fix; more of a crude hack which works around the problem.
It's had minimal testing, works for me, use at your own risk, etc. Hope it
helps somebody out there.)

Description of the problem: Right-click over any shortcut (or quick-launch
toolbar icon). It takes about 10-25 seconds before the context menu pops
up. Try again, on the same or another shortcut, and it's fast. Wait about
5 minutes, and it is slow again. It happens on Windows 2000 SP4, but not
on Windows 2000 SP3. It happens with Netware Client 4.83, or 4.83+sp2, or
4.83+sp2+"update e". If you remove the Netware Client, it goes away.

What seems to be happening, based on Ethereal traces, is that the Netware
Client is trying to resolve the short-cut target's drive letter (usually
"C") as a network name. In my case, it tries IPX SAP, SLP, and Bindery,
making multiple requests (even though it gets negative replies, but that's
another problem) until it finally gives up.

My fix is based on Novell TID # 10065560 item 6, which tells how to
pre-load the Bad Server Name Cache with permanent entries for servers you
don't want to try to resolve. But I'm abusing this to preload the cache
with the letters A through Z. (I hope you don't have any servers on your
network with these names.) This appears to work around the bizarre behavior
of NWC 4.83 with Win2K SP4 trying to resolve drive letters on short-cuts as
if they were network names.

If you want to try the fix, import the .reg file below, or do it
manually as follows: Using regedt32, create a REG_MULTI_SZ value
called "BadServer" under the key:
HKLM\SYSTEM\CurrentControlSet\Services\NetwareWorkstation\Parameters
The data is the letters A through Z, each on a separate line.
Note: The change does not take effect until you reboot.

======== start badserver.reg ==========
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetwareWorkstation\Parameters]
"BadServer"=hex(7):41,00,00,00,42,00,00,00,43,00,00,00,44,00,00,00,45,00,00,00,\
46,00,00,00,47,00,00,00,48,00,00,00,49,00,00,00,4a,00,00,00,4b,00,00,00,4c,\
00,00,00,4d,00,00,00,4e,00,00,00,4f,00,00,00,50,00,00,00,51,00,00,00,52,00,\
00,00,53,00,00,00,54,00,00,00,55,00,00,00,56,00,00,00,57,00,00,00,58,00,00,\
00,59,00,00,00,5a,00,00,00,00,00
======== end badserver.reg ==========

 

[Marcelo]

Paul

Perhaps you have a name resolution problem to target the server name, when
the name cache timeouts, y need to resolve the name again ??? Could this be
your problem ???


--
Dr. Marcelo Ponce
mcp, mcp+i, mcsa, mcse

On my Windows 2000 workstation, when I initially open a mapped drive to a

Windows 2000 server, a 7-10 second delay occurs before I see any files.
(While waiting for this caching operation, I hear a lot of disk activity on
my machine.) Once this "caching operation" completes, I can then proceed to
open any series of nested folders within the mapped drive without
experiencing any delay. If I leave the session idle for a period of a few
minutes, the caching operation occurs again.

I tried the registry hack

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" to set
NtfsDisableLastAccessUpdate to "1" and it didn't help.

This problem only occurs on my machine... If I use another workstation,

the problem doesn't occur. Anybody have any ideas?

 

[Peter van der Woude]

-- Live with it until Novell fixes the problem

-- Uninstall the Novell client software

Hi,

Two things:
Novell can't fix things if MS keeps meddling with there own client without
giving information to other vendors.
There might a simpler way to get rid of these delays. Take a look at
http://www.ithowto.com/novell/clientspeed.htm
Especially tip 9 improves browsing speed a lot. BTW this is not a Novell
issue but a MS issue.
http://support.microsoft.com/support/kb/articles/Q245/8/00.asp

Good luck,

Peter

 

[Rick]

Hi,

Two things:
Novell can't fix things if MS keeps meddling with there own client without
giving information to other vendors.

Give us a break. Novell's development team like most other
major development teams has access to MS Service Packs
months before they're released to the public. This problem
has existed throughout the 4.8x and 4.9x series of Novell
client software -- it should have been fixed over a year ago.

There might a simpler way to get rid of these delays. Take a look at
http://www.ithowto.com/novell/clientspeed.htm
Especially tip 9 improves browsing speed a lot. BTW this is not a Novell
issue but a MS issue.
http://support.microsoft.com/support/kb/articles/Q245/8/00.asp

That issue has to do with Win98 Task Scheduler and has
absolutely nothing to do with Novell's client software.

Rick

 

[Peter van der Woude]

Rick,

Give us a break. Novell's development team like most other
major development teams has access to MS Service Packs
months before they're released to the public.

Opinions differ whether this is sufficient. Novell and other vendors feel
their are hindered unnecessarily in adapting their products, because they
get no info on what gets changed. As I understand it this the issue they
fighting over in court right now.

This problem has existed throughout the 4.8x and 4.9x series of Novell
client software -- it should have been fixed over a year ago.

It has. Removing the Remote Scheduler namespace helps.
This can be done by deleting the key
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameS
pace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}
Problem is they can not do this through the client setup, because it would
mean changing system functionality that has nothing to do with the client.
Latest clients include a UNC Path Filter driver that should make this
workaround unnessary.

That issue has to do with Win98 Task Scheduler and has
absolutely nothing to do with Novell's client software.

The link was to illustrate that the Task Scheduler causes problems with MS
OSes too. Maybe this one is better:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q316874

Peter