Novell Mapped Drives Open Slow

I am using Novell Client SP1a on Windows XP.  When I try to connect to a mapped drive it takes from 30 secs to 3 mins to open. What could be the problem?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Depends on a bunch of things.  There have been several previously-answered questions in this topic area that address most of them.

The first thing I suggest you try is, in Windows Explorer, Tools, Folder Options, in the View tab, make sure the following settings are UNchecked:

1)  Automatically search for network folders and printers
2)  Use simple file sharing  (which, apparently Microsoft recommends, even though it can even screw up their own networking)

Apply the settings change to all folders.  While you're in there, turn off "hide extensions for known file types" so you can see what you're opening when you get the next email-borne virus is actually an executable file type.

If that doesn't help, and you don't mind editing your registry, there's a registry hack to prevent searching for other users' scheduled tasks that helps.

You should also download and apply the latest post-SP1a patch to the client, if you don't want to use SP2, which also has post-SP fixes out.

You should disable all unnecessary XP services - use the recommendations on blackviper's site as a guideline.
Oh, and you also should make sure the Novell client is installed CUSTOM, selecting only those protocols and services you use in your NetWare environment.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
wonikaAuthor Commented:
I did install CUSTOM and made IP the only protocol and I do have SP1a.  I will try the suggestions you made and get back with you today.
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

There were patches after SP1a was released, with updated NWFS.SYS and a couple other modules that could have an impact on your problem.
I have read probably several hundred LAN traces on this type of symptom before. The most common configuration cause for slow responsiveness usually had to do with how the Novell and Microsoft Name Space Providers (NSPs) are configured. When you try and map a network drive, you are likely using \\servername\volumename or some similar derivation. Since both Novell's and Microsoft's network client is running on the computer, they don't know who this request should belong to. The MS MUP (Multiple UNC Provider) controls how the OS checks each to see if they can handle the request.  It checks the Provider Order to see who it should be talking to first, MS, or Novell. You can control this by going to Control Panel / Network / Advanced / Advanced Settings / Provider Order.

Normally this is set NetWare Services first and Microsoft Windows Network second. If MS is listed first, that means the Novell provider must wait for it to timeout before trying to resolve the name. So putting NetWare first speeds up NetWare access times.

I am getting kinda long winded here, let me put some brief suggestions:

1. Verify NetWare Services is first on the Provider Order.
2. Verify that the Novell Client is properly configured to use SLP or DNS (if you are not sure which, then you should be using SLP).
3. Verify that the SLP DAs listed on the Novell Client actually have SLP registrations from the server you are mapping a drive to for the bindery.novell service (have to dump the DA cache to be sure on this one... DISPLAY SLP SERVICES uses broadcast info from the SLP UA on the server to complete it).
4. Verify that the MS WINS and Master Browser services are functioning like they should to prevent long timeouts on invalid server names.
5. If this doesn't help, then use the free trace software from to capture a LAN trace and see what is actually happening on the wire when it is stuck in the long delay.
The workaround for the MUP problem in more recent versions of the Novell client is the UNC path filter.  It only lets the MS client see UNC requests if the server name is unknown to the NW client.  There was a bug in 4.83 and 4.9SP1 client that had the UNC path filter sending requests for MS servers through the NW client, but I think that was fixed in post-SP1a patches and SP2.

Hence the recommendation to patch the client.  4.9 SP2 even has a post-SP patch that should be applied, last I looked it was version "c"
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Novell Netware

From novice to tech pro — start learning today.

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.