Novell Mapped Drives Open Slow

Posted on 2004-11-19
Last Modified: 2011-08-16
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?
Question by:wonika
    LVL 35

    Expert Comment

    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.
    LVL 35

    Accepted Solution

    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.

    Author Comment

    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.
    LVL 35

    Expert Comment

    There were patches after SP1a was released, with updated NWFS.SYS and a couple other modules that could have an impact on your problem.
    LVL 1

    Expert Comment

    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.
    LVL 35

    Expert Comment

    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"

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Enabling OSINT in Activity Based Intelligence

    Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

    Suggested Solutions

    Digital marketing agencies have encountered both the opportunities and difficulties that emerge from working with a wide-ranging organizations.
    This paper addresses the security of Sennheiser DECT Contact Center and Office (CC&O) headsets. It describes the DECT security chain comprised of “Pairing”, “Per Call Authentication” and “Encryption”, which are all part of the standard DECT protocol.
    Sending a Secure fax is easy with eFax Corporate ( First, Just open a new email message.  In the To field, type your recipient's fax number You can even send a secure international fax — just include t…
    Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

    759 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    11 Experts available now in Live!

    Get 1:1 Help Now