[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 579
  • Last Modified:

Novell Mapped Drives Open Slow

I am using Novell Client 4.90.0.0 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?
0
wonika
Asked:
wonika
  • 4
1 Solution
 
ShineOnCommented:
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.
0
 
ShineOnCommented:
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.
0
 
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.
0
Upgrade your Question Security!

Add Premium security features to your question to ensure its privacy or anonymity. Learn more about your ability to control Question Security today.

 
ShineOnCommented:
There were patches after SP1a was released, with updated NWFS.SYS and a couple other modules that could have an impact on your problem.
0
 
twkerbyCommented:
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 www.ethereal.com to capture a LAN trace and see what is actually happening on the wire when it is stuck in the long delay.
0
 
ShineOnCommented:
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"
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now