Novell OES2 Linux and Active Directory File Share slow down problems

I haven't got a slowdown while logging in.  Maybe it's because I don't use the typical client install, or maybe it's because of settings I normally use, like specifying my DA server IP.

Can you tell at what point during login it appears to lag?

As far as the slow Windows Explorer thing, that's a combination of stuff.  One thing for sure - it goes faster the 2nd time you open Windows Explorer because the Novell client has populated its bad server cache, so UNC requests to Windows go to the Windows client and UNC requests to NetWare/OES go to the Novell client.

That's why you want the Novell client to be primary network provider, first in line - so it can act as traffic cop, because Windows treats all mapped drives and network-reachable servers as "shares" - meaning it expects them all to be on Windows servers and to respond to requests for shared printers and tasks and crap like that - the slowdown of accessing NetWare directories when you had Windows as primary is a timeout of that sort of search.

If the UNC path filter is on in the Novell client and you pre-populate the bad server cache with non-NetWare/OES servers, you'll get rid of most of the first-open of Explorer lag, which is in part the Novell client populating the bad server cache for the UNC path filter to do its traffic-cop duties.

How are you mapping drives?  NetWare login script, Windows login script, manually on the workstation via Windows Explorer, or what?   How you're doing that might explain the slow login...

Also, as far as Windows shares taking a while after the session "sits" - that lag is Windows and its auto-disconnect/reconnect process.  When a connection between a Windows PC and a Windows 2003 server is idle for a while, it disconnects the session.  When the user tries to browse the share again, the client does a reconnect, which re-authenticates the user and re-establishes the session, which is why there's a lag with shares.  

NetWare doesn't have that problem because it uses keep-alive packets, and assumes the user wants to stay logged in until they log out, so it doesn't drop the idle sessions like Windows does.

You can tweak both the Windows Server and all the PC's registries to increase that idle time so it doesn't auto-disconnect so frequently.

"After users log into the Novell Client, it seems like the system has to think about it for 15 - 20 seconds, kind of like when you mis-type your password.  After that the scripts begin to execute."

So, in other words, at the Novell GINA, the user enters their userID and password and hits Enter or clicks OK, then the animated icon does its "Connecting" activity for 15-20 seconds before the screen changes to the desktop and the login script runs?  Sounds like perhaps it's having a bit of a hard time finding the DA, or you're using contextless login or something?

Of course you did say you usually use "typical" when installing, so if the version of the Novell Client32 you installed "typically" installs both IP and IPX, you could be having an issue cause by too many protocols bound.  Make sure IPX is not bound to the client.

One thing that contributes to the time lag in these situations is in the Novell Client32 properties, Protocol Preferences tab.  If you have both IP and IPX installed, they are both listed, but one should be indicated as preferred.  Make sure it's IP.

The protocol naming components that are listed for IP generally include NDS, Host File, DNS, SLP and DHCP NDS.  For each one that is highlighted, the client will attempt to resolve resource names using that component, starting with DNS.

I usually only have DNS, NDS and SLP highlighted.  I also make sure that the tree name is hostname-resolvable to the DA server's IP, and the servers are hostname-resolvable to their IP.  That means that if your internal DNS suffix is mycompany.lan, you should have a  tree.mycompany.lan A record as well as a ServerA.mycompany.lan A record, and your clients should have mycompany.lan in the domain suffix list, so if something is looking for "tree" it will find it and resolve the address.

If you didn't have private DNS before you put in AD, you do now - and DNS resolution will be tried first and then after that times out, it will try SLP.  If your SLP DA server's IP address isn't in the Directory Agent list on the Service Location tab, then the client has to multicast for the DA server.  If it can unicast for it, it won't time out on a blocked multicast and backpedal to broadcast looking for a DA.

NDS resolution won't work until you're logged in, so you need either DNS or SLP resolution to work.  When the client has to work really hard to find what address to use to find the tree so it can find a login service, that's where a good part of your initial lag between login "OK" button and actual login process comes in.

Also, on the same topic, in the Client32 Properties, Advanced Settings tab, find the Name Resolution Timeout entry.  It defaults to 10 seconds.  Change it to 5 seconds to cut your lag in half, but don't set it too low for the client to find the resources needed to log in.  How long is long enough depends on your environment.  The Advanced Settings tab has other timeout limits that you might experiment with.  Everyone's environment is a bit different.

While you're there, change File Caching to Off and File Commit to On, to ensure file integrity when working with MS-Office files on NetWare.  Even if you have oplocks off on the server side, changing the client side makes it so Windows won't attempt an oplock and wait for the oplock request to time out before opening a Word or Excel file.

If you're not using any NMAS methods, another speed-killer is having NMAS Authentication on in the Advanced Login tab with no NMAS methods enabled.  Set that to Off.

After you tweak the Novell Client and the local connection (the TCP/IP DNS settings...) using these easy-to-access settings, try things out for a bit and post back.

One more thing to tweak, for your users' sake.

In their Windows Explorer, Tools, Folder Options, View tab, make sure "Automatically search for network folders and printers" is unchecked.  That adds to Explorer's lag time, because every mapped drive gets searched at first launch for shares (folders and printers) which results in timeout lags because NetWare mapped drives don't respond to Explorers "got any shares" requests.  This happens despite the UNC Path Filter, because they're mapped.  This appears worse if any NetWare drives are mapped manually using Windows Explorer's "map network drives" function.

If you can tweak that entry via policy, all the better, because it's stored in the registry in the user profile, not in HKLM.
 

Yes, that's the pre-populating of the cache I mentioned earlier.  How to create and populate the registry entries is explained in this TID: http://support.novell.com/docs/Tids/Solutions/10065560.html

It should be a multi-valued string entry with the server names in a <CR> list, meaning enter your Windows hostnames and press <enter> after each one.

I believe it should just be host names.

Vaxman2, can you maybe take a screen-print of what your list looks like, and attach the file (provided nothing's confidential, that is...)