Slow UNC path to Server


I have a server at a site which has Netware 6.5 Installed.
The machine had been running fine for quite some time, but since they have moved office (we think) that this issues has started coming up. When I go to \\uncpath\share it takes a damn long time to browse the network. Selecting a folder and trying to browse into it, takes another age to process.

I decided to open up my computer, map drive and selected this same share as a mapped drive. Now... Browsing it is nice and fast! yet, a UNC path to it is still very slow.
Anyone seen anything like this before?
Clients are on version 4.90.
Nothing has changed on server or workstations it seems.
LVL 15
Who is Participating?
alextoftConnect With a Mentor Commented:
Mapping a drive as opposed to usnig a UNC path vastly reduces the number of times the server address needs to be resolved. I'd suspect some kind of name resolution problem. If you put the server and it's IP in the hosts file does it magically cure the problem? If so have a look at your DNS.
MarkMichaelAuthor Commented:
There is no DNS running on this server. Everything is linked via IP addresses unfortunately. I've wrongly added in my opening post that I was typing the server name, but actually I was using IP instead. skipping out DNS altogether...
ShineOnConnect With a Mentor Commented:
I suspect that the MS client is somehow "first redirector" (for lack of a better term) for UNC-path servers (at least this one,) which, when using the Novell Client32 4.9 or later, should not happen unless somehow the address you're using is in the "bad server name cache" or "bad address cache" on the client, or you've got the UNC path filter turned off.  

The UNC path filter feature of the client should prevent that slow browse effect if it's working.  The slow browse happens when the Novell client doesn't grab control of the redirect and lets the Windows client handle it.

The Windows client always, by default, expects any network (aka UNC-path) resource to be another Windows PC, and searches the server and "share" for Windows-only things like "shared tasks" and "shared printers" and the desktop.ini file, and the big lag you're getting is waiting for the client to time out on all of those Windows-only searches.  Once it gives up on all that, then it will behave in a fashion we consider "normal."

Now, one possibility, since you say they moved, perhaps they changed IP address as well, but didn't fully propagate the change through NDS/eDirectory, so it's not as easily recognized as a NetWare resource as it should be.

I suggest, as a test, set the "bad address cache timeout" and "bad server name cache timeout" to zero and turn the "bad server name cache" off, in the Client32 properties, Advanced Settings tab, on one of your PC's - if that makes a difference, that's a big clue.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.