Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

Win95 FAQ Part 6 of 14: NetWare (tm) Networking
Section - 6.2. What do I have to do to a NetWare server to work with Win95 clients?

( Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 - Part9 - Part10 - Part11 - Part12 - Part13 - Part14 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Schools ]

Top Document: Win95 FAQ Part 6 of 14: NetWare (tm) Networking
Previous Document: 6.1. How do I connect to Novell NetWare (TM) servers?
Next Document: 6.3. How do I make NetWare-related TSRs work? They won't work in the login script?
See reader questions & answers on this topic! - Help others by sharing your knowledge
   Many, many, people have crashed NetWare servers with Win95
   computers using Microsoft's Client for NetWare. A lot of this is from
   the client pushing the server, but a lot more of it comes from
   misunderstandings from users!
   The most critical thing to do to a NetWare server is to update its
   software. Old .LAN drivers might not keep up with the Win95 clients.
   An old '386 or '486 class server will also have troubles keeping up
   with Pentiums running Client for NetWare. Novell's VLM Client for DOS
   causes many of these troubles too. Details are at Rich Graves'
   Win95NetBugs site.
   In each of these cases, get the latest .LAN driver for your server's
   net cards, get the latest base OS patch sets for your server from, and get the Admin edition of the Win95
   Service Pack. The service pack tools, in particular, include
   improvements in batch setup for NDS networks, and fix the nasty
   problems caused by the original Win95 release.
   Special notes for server versions below:

     * 6.2.1. NetWare 2.x 
   Ensure you disable Packet Burst and long filenames on the Win95
   clients, by adding these lines to the clients' system.ini file:


   You can also use a non-burst frame type (802.3), and enforce no LFNs
   via system policies.

     * 6.2.2. NetWare 3.x 
   These servers have a nasty time with Win95 clients using long
   filenames and packet burst. Use the NetWare 2.x techniques above, or
   apply pburst.nlm and the OS/2 name space fix, available at Novell's
   NetWire site. Back up your server before powering up a Win95 client
   for the first time!
   Client for NetWare will not use long filenames on a NetWare 3.11
   server unless you explicitly tell it to, meaning you KNOW you have the
   name space patch installed. If you want to use long filenames on a
   patched NetWare 3.11 server, you should set up a system policy to
   enforce LFN usage, or include:


   in system.ini

     * 6.2.3. NetWare 3.12 
   This, according to my observations, is a patched and bug-fixed NW
   3.11. This is the server that Microsoft did most of their client
   testing on, and it will work with packet burst and long filenames
   without patches. You still need the OS/2 name space to support long
   filenames. Set the frame type on the Win95 stations to Ethernet_802.2.

     * 6.2.4. NetWare 4.x (Directory Services) 
   If you don't need to use NDS and you have Bindery emulation available
   on the server, you can use the Client for NetWare as per NetWare 3.12
   servers. The big catch is it won't recognize an NDS login script! To
   work around this, you can hand-copy the NDS system login script to
   sys:public and call it net$log.dat. Another work-around is to log
   into the server in Bindery mode (An option available in login.exe, or
   just log in with regular Client for NetWare) and run a copy of NW
   3.12's syscon to make system and user login scripts for Bindery mode.
   Details are in KB article Q128253.
   However, Microsoft released an NDS Service which will use NDS
   login scripts and work with NDS programs. Install Services for NDS by
   adding it as a Service (you still need Client for NetWare installed).
   Services for NDS is part of Microsoft's Win95 Service Pack 1
   complete disk set. You will also need the Shell32 Fix and the NWSERVER
   fix, which come with Service Pack 1, and six DLL files from Novell
   which come with the NetWare 4.x server. You will still need Bindery
   emulation for peer sharing (File & print sharing for NetWare) and
   Remote Administration. Set the User Level security provider to
   point to this server running Bindery emulation and you're all set. Or
   just don't bother with peer sharing via NetWare (Which you shouldn't
   do anyway except for Remote Administration.)
   I had the opportunity to finally try Services for NDS (25 APR 96) and
   it appears to run just fine. After I hand-copied all DLL files from
   Novell's SYS:\PUBLIC\CLIENT\DOSWIN directory to SYS:PUBLIC, I could
   run nwadmin.exe and the other Win 3.1 NDS utilities in there.
   WARNING: Novell now has a 32-bit NetWare API (32-bit versions of their
   DLLs) and these DLLs, as far as I know, do NOT work with MS's NDS
   client. I haven't tried them, but on more than one occasion I got a
   letter from a user regarding them. For example, Pegasus Mail for Win95
   requires the 32-bit NetWare DLLs but they don't work with MSNDS. Also,
   for the 16-bit DLLs, use the ones in SYS:\PUBLIC\CLIENT\DOSWIN\ and no
   others, because the ones that come with Client32 are really 16/32
   stubs and require the Novell 32-bit DLLs.
   NOTE: The NDS client still depends on accurate Bindery emulation
   running on the Preferred Server. If you use any additional services
   that depend on User Level Security (such as Remote Administration)
   be sure you set the Bindery context to match the Organizational Unit
   you want your user list for. In an absolute worst case, set the
   Bindery context to point to each of your Organizational Units and
   Organization. Type this at the server console, or include it in
   AUTOEXEC.NCF (Of course, use your real unit names, not the example


User Contributions:

Comment about this article, ask questions, or add new information about this topic: