Link to home
Start Free TrialLog in
Avatar of timhemmerich

asked on

novell client for 2000 time lapse

When loading clint4.8 or 4.9 onto a windows 2000 pc, I always end up with the same problem. When i right click on any shortcut or net object it takes aprox 30 secs to 1 minute just to see the menu. Once its up its fine but that time lapse drives me nuts. I know this must be common since its happened to me more thatn once in differeent places.Its not good when you install a new pc and the user right clicks something and it takes that long. The looks on thier faces are not the look of a new exciting computer. I also know if i take the novell client off the problem disappears.I can have a folder on my c: and send a shortcut to it to the desktop...once i right click on it...30 sec wait.ARghhhhhhh
Thanks in advance for any help
Avatar of PsiCop
Flag of United States of America image

Hmmm.....well, you haven't said anything about your network environment, so I'll assume you have either a modern version of NetWare (v6.5 SP5) or OES SP2. Further, since you don't say, I'll assume that your network is designed as Pure IP (no IPX) and that SLP is correctly configured.

Given those assumptions...

First thing I'd look at is the client installation - you should perform a Custom installation of the client and be sure to install only IP support. Do not install IPX support. Also, be sure that NDS is selected, not Bindery. Lastly, make sure to omit any optional component (for example, NMAS) if you don't actually use it.

If my assumptions are incorrect, well, that shows why you need to take the time to detail your environment. We're Experts, not mindreaders.
Avatar of RubenvdLinden

I think I know exactly what your problem is, as I had the same performance problem after applying service pack 4 to our Windows 2000 workstations.
In my case, the Novell Client tried to resolve drive letters as network resources.
So, if I had a shortcut to a program on drive C, the Novell Client tried to find a network resource C (which doesn't exist, so after a while it times out).

I found the following solution for the problem:
- Start regedt32 (not regedit)
- Find the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetwareWorkstation\Parameters
- Create a REG_MULTI_SZ value called BadServer in this key
- Add all the drive letters you use (e.g. C and D) on a seperate line (just the letter)
- Close regedt32 and reboot

Right-clicking a shortcut should be fast again.

Hope this helps.
There is a timeout parameter in the Novell Client configuration screens that changes the same key - no need to use RegEdit. I'd tell you exactly where it is, but I don't have a Windoze box handy.
I do know exactly what it is.

It's a "feature" of Windoze 2000 that requires a reg tweak.  I have to check where to tweak, but it's something that's "fixed" in WinXP so you need to make a Windoze Exploder setting change instead of a reg tweak.

It has something to do with searching for "shares" and scheduled tasks on network PCs.  Windoze is too stupid to recognize that a resource isn't a peer-to-peer Windoze resource and automatically checks for scheduled tasks and shared printers, and what you're experiencing is the time out period for that "feature."
It's HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer.

There are 2 subkeys, each has a default value only.  One's default value is "Printers" and the other one is "Scheduled Tasks."

Delete 'em both.  The big culprit is "Scheduled Tasks, but it's not necessary to have the "Printers" one there, either.  

<Disclaimer> Be sure to back up your registry before making changes.  All registry changes you make are at your own risk. </Desclaimer>
Note: delete the subkeys, not the default values...
Avatar of timhemmerich


it seems to have worked on my pc. If you could fing the paramwter in client it would make my life easier.
here some i would guess at
bad server name cache timeout
name resolution timeout
if not one of theses appreciate a check in a windoze pc
thanks in advance
The workaround, enumerating all of the drives, is just that - it's a workaround.

If that's what you did, then if you are accessing NetWare drives that are mapped, and you included those in the workaround, then you should remove them.  It's making it bypass the Novell client for those redirects.  Only physical drive letters should be included, not mapped NetWare volumes, and if you have Windoze servers, you can also add those Windoze server names - not any drive letters mapped to them, just their NetBIOS names.

The Novell client, if you're using a current version/sp/patch level, shouldn't need such a kludgy workaround.  Windows 2000, however, does need to have the registry tweaked.

Look at your Novell client properties, Protocol Preferences tab.  How many Protocol components are highlighted?  If you're running IP only, the default is 4.  The default timeout is 10 seconds per protocol used to find a name.

If it's a name resolution timeout, you'd see a 40 second lag, and it would only be the first time during a session; all subsequent access attempts would be nearly immediate, as the resource would be in the name cache, and the Novell client wouldn't even look.

If it gives you the same lag with subsequent accesses as it does with the first access, then it's not the Novell client doing it.

However, if it doesn't give you the same lag every time, then you should only add Windows-only resources to the bad server name cache key ReubenvdLinden gave you - that is the way to prevent name resolution timeout from affecting first-access of a non-NetWare service; the UNC path filter will bypass the Novell client's name resolution for anything that's in that multi-value string value, first time, every time.

Note that you mention using the 4.8 and 4.9 client.  The 4.8 client is deprecated.  The 4.90 client should be updated to SP2, with post-SP2 patch "E."  If you don't update it to SP2/E then you may be running into a bug that has been fixed.  Before applying the reg hack for bad server names, update your client.
Avatar of RubenvdLinden

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
To clarify:

The only parameter in the client settings is for the timeout itself, not to list exceptions.  The purpose of adding entries to the bad server name cache registry key is to force the Novell client to pass whatever's there to other redirectors, not so it can respond that the server is not available.

It's used to assist the UNC path filter processing, the purpose of which is to have the Novell client always be first in line for network redirects, and anything that's not a NetWare resource gets "filtered out" so the Novell client doesn't attempt to process the request.

That was put in place to fix the inherent problem the native Windoze client has with assuming everything is a Windoze peer system, which causes redirects to NetWare resources to have slow response because the Windoze process has to time out on its requests for shared printer info and shared task info before it gives up and passes the redirect request to another redirector.  With the UNC path filter on, if a known service is not a NetWare service, and it's not enumerated in the bad server name cache registry key, it gets placed into the temporary cache after the first timeout, so subsequent accesses bypass the Novell client.

This can cause problems with things like wireless, where the NetWare server gets put into bad server name cache because of delays in the wireless authentication at startup, so I have disabled both bad server name cache and bad address cache on those systems.

You can, if you so desire, change the timeouts for bad server name cache and bad address cache from the Novell client properties, Advanced Settings tab.  In fact, you can disable the bad server name cache altogether from that tab.

Both caches default to 5 minutes (300 seconds.)  If you set them to zero, you effectively disable them as cache entities, but there's a separate entry for turning off the bad server name cache, probably to disable the processing of the registry key added with ReubenvdLinden's tweak.  My guess (haven't tested it) is that you could set the cache timeout to zero so that down server situation won't result in a 5-minute lag after it comes back up where the client still thinks it's unavailable, but still have that registry key populated with non-NetWare resources, and thus still have it assist the UNC path filter to pass redirects immediately to the next provider down the line.

If you use ReubenvdLinden's tweak to add Windoze servers and Linux SAMBA servers to the name cache, you shouldn't limit it to only Windows 2000.  Any NT-based system with the Novell client32 can benefit from it, which includes Win2K pro and server, WinXP and Win2K3 server.

If updating your client to include the current SP and patches fixes the issue, then forget about adding local drives to the bad server name cache.  I've never had to do that, and it's an obvious workaround to address a Win2K-specific issue that, as I said, may have been fixed with newer versions than what you're using.  It's always better to use the latest versions with the latest bugfixes, if that fixes the issue, than to do workarounds, because the workarounds tend to hang around long after they're no longer needed, muddying the waters so to speak.

The author stated that my registry tweak works on his pc:
"it seems to have worked on my pc. If you could fing the paramwter in client it would make my life easier."

Unfortunately, the settings from the registry tweak are not settable in the client, so I also provided a few methods to distribute the registry tweak to all Windows 2000 workstations in his network.

I hope my solution is acceptable.
Hard to say without feedback from the asker beyond the one post RubenvdLinden refers to.

It may have been a workaround for an old version of the Novell client, but this is the first I've heard of it.

If the symptom appears after applying W2KSP4 then it may be that the SP changed one of the registry entries relevant to the NetwareWorkstation provider, usually:

It had the annoying tendency to change that value's data from "\Device\NetwareRedirector" to "\Device\NetwareWorkstation" which confused things since the provider for the Novell client32 is NetwareRedirector while the "native" Windoze client for NetWare Networks is "NetwareWorkstation".

That simple change can bollux stuff pretty well.

It also may be a symptom of a problem with an old version of NWFS.SYS from an unpatched Novell 4.8x client or 4.90 client.  NWFS.SYS is what provides the bad name cache and bad address cache capability to the Novell client.

The only way I can envision even an old, unpatched Novell client even >looking< at local drives as network resources would be if for some reason the "first network drive" entry was set to a local drive letter like C or D, which problem can be easily cured by setting it to E, F, G or whatever the first mapped drive >really< is, rather than adding local drives to the bad server name cache unnecessarily.

Again, not having response from the asker makes it difficult to say.  I hate to see a workaround that's not documented anywhere in a Novell TID or CoolSolutions AppNote being a PAQ here on E-E.

If it is a documented solution, RubenvdLinden, please provide a link, and I will eat my virtual hat and apologize.

You can find the documented solution in TID10100475, last modified on March 30 this year:

The TID does not specifically mention Windows 2000 Servicepack 4. However, more Novell administrators had the same experience after applying sp4:

I hope you find the TID sufficient.
Wow.  That's a new one on me.  It still feels like a workaround for a Windoze problem and not a real fix, to me, but


Apologies to RubenvdLinden

Just so you all know, evidence that it is a Microsoft problem:
That has a different reg-tweak fix, and it's in a Windoze network.

Microsoft doc 819101 apparently also has another fix, for WinXP only, of turning off the transition effects for menus and tool-tips in the Fischer-Price interface.

It all points at some kind of change Microsoft made in the context handler, where it's somehow misinterpreting a local drive as a hostname, possibly in the URL handler or some such, and the fix may really be in an obscure registry entry that has nothing to do with the Novell client at all...