Newsgroups: comp.os.ms-windows.win95.misc,comp.os.ms-windows.setup.win95,comp.os.ms-windows.networking.win95,comp.os.ms-windows.apps.compatibility.win95,comp.os.ms-windows.apps.utilities.win95,comp.answers,news.answers
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hecate.umd.edu!haven.umd.edu!news.cs.jhu.edu!news3.his.com!news.lightlink.com!news-xfer.mccc.edu!news.IAEhv.nl!Cabal.CESspool!bofh.vszbr.cz!newscore.univie.ac.at!newsfeed.nacamar.de!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.internetmci.com!204.174.67.209!news.bctel.net!srv4.reelwest.bc.ca!not-for-mail
From: gordonf@intouch.bc.ca
Subject: Win95 FAQ Part 6 of 14: NetWare (tm) Networking
Message-ID: <19980107.8D7D740.13BDC@ras2com20.reelwest.bc.ca>
Date: Wed, 7 Jan 98 21:55:39
Approved: news-answers-request@MIT.EDU
Followup-To: comp.os.ms-windows.win95.misc
Summary: These postings list many questions asked in said newsgroups,
         and answers them as best as I can.  I make references to other
         Web sites and FAQs when appropriate.  Visit the WWW home of
         this FAQ (http://www.orca.bc.ca/win95) for the appropriate
         links.  This section is the 6th: NetWare (tm) Networking
Organization: Personal and Win95 FAQ maintainence
X-NoSpamWanted: This address is not for unsolicited commercial e-mail
X-ImNotKidding: By sending UCE to this address you agree to pay $50.00 CDN
X-pensive-Spam: Payable to G. Fecyk, c/o P.O. Box 373 Oakville, MB  R0H 0Y0
Lines: 1234
Xref: senator-bedfellow.mit.edu comp.os.ms-windows.win95.misc:291421 comp.os.ms-windows.setup.win95:63504 comp.os.ms-windows.networking.win95:44660 comp.os.ms-windows.apps.compatibility.win95:15802 comp.os.ms-windows.apps.utilities.win95:51933 comp.answers:29589 news.answers:120388

Archive-name: windows/win95/faq/part06
Last-Modified: 1998/01/07
Posting-Frequency: Every two months
URL: http://www.orca.bc.ca/win95/faq6.htm

6. Novell NetWare (TM) Networking 

     * 6.1. How do I connect to NetWare servers?
     * 6.2. What do I have to do to make the NetWare server work
            safely with Win95 clients?
          + 6.2.1. NetWare 2.x
          + 6.2.2. NetWare 3.x
          + 6.2.3. NetWare 3.12
          + 6.2.4. NetWare 4.x (Directory Services)
     * 6.3. How to I make NetWare-related TSRs work? They won't work
            in the login script.
     * 6.4. How do I use a client other than Microsoft's Client for
            NetWare?
          + 6.4.1. NETX
          + 6.4.2. VLM
          + 6.4.3. Client32
     * 6.5. How do I connect to the server from Single mode DOS?
            (Outside of Win95)
     * 6.6. How can I receive NetWare pop-up messages?
     * 6.7. Why don't I get a login prompt when Win95 starts?
     * 6.8. What bugs should I watch out for? Where can I get fixes?
          + 6.8.1. Automatic frame detection doesn't work
          + 6.8.2. NetWare C$ peer sharing bug
          + 6.8.3. WAN routing tables keep getting trashed
          + 6.8.4. Password caching bugs
               o 6.8.4.1. How do I disable password caching?
          + 6.8.5. Server ABENDs when I start a Win95 client (and
                   other bugs)
     * 6.9. Top ten NetWare client mistakes
     * 6.10. What does Novell's Client32 offer that Microsoft's
             Client for NetWare does not?
     * 6.11. What's this I heard about MS's client only being NetWare
             2.2 compliant?
     * 6.12. How do I share my hard drive or printer to other NetWare
             users? (Avoid if possible!)
          + 6.12.1. How do I share my printer through RPRINTER or
                    PSERVER instead?
          + 6.12.2. ...on a Directory Services network? (NetWare 4.x)
     * 6.13. How do I make Win95's cool network features work on
             NetWare?
          + 6.13.1. System Policies
          + 6.13.2. System Policies on a Directory Services network
          + 6.13.3. Group Policies
          + 6.13.4. User Profiles and Roving Desktops
          + 6.13.5. User-level Security
          + 6.13.6. Remote Administration
          + 6.13.7. Remote Admin on a Directory Services network
     * 6.14. My suggestions for preparing an automated Win95
             installation and workstation replication
       
   This particular section is rather anti-Novell. Forgive me, but this is
   a Win95 FAQ, not a NetWare FAQ. My objective is to make using Win95
   easier, and if it means patching and hacking the server, so be it.
   Chances are, you have a lot more clients than servers. :-)
   
   However, I do want to start a Client32 sub-FAQ in here. Client32
   experts are welcome to provide answers to FAQs about it and I'll
   collect them into a separate section. Please help, and you'll get your
   name in lights on this page.
   
   Novell MHS mail system users will want to check out the MS
   Exchange FAQ, especially the part about the MHS delivery service now
   available from Infinite Technologies.
     _________________________________________________________________
   
   6.1. How do I connect to Novell NetWare (TM) servers? 
   
   First, ask your administrator if he prepared the server for Win95
   clients. This is critical, if you want your administrator to like you.
   
   Then, Install Client for NetWare networks, and fill in the "Preferred
   Server" value in CNW's Properties. Set your primary login to "Client
   for NetWare Networks".
   
   Also, install IPX/SPX protocol (It will install automatically along
   with Client for NetWare), and select a frame type in its Advanced
   properties. Auto-detect does not always work. Your choice of frame
   type depends on what the NetWare server uses. NetWare 3.11 and earlier
   typically use 802.3, later servers use 802.2.
   
   The next time you restart, you will get a NetWare login requester
   asking for your name and password. When you feed it this, your NetWare
   login script will execute.
   
   More details for NetWare Directory Services later.
     _________________________________________________________________
   
   6.2. What do I have to do to a NetWare server to work with Win95
   clients? 
   
   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
   netwire.novell.com, 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:

[nwredir]
SupportBurst=0
SupportLFN=0

   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:

[nwredir]
SupportLFN=2

   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,
   Admin Edition. 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 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
   MYORG):

Set Bindery Context = O=MYORG,OU=UNIT1.MYORG,OU=UNIT2.MYORG
     _________________________________________________________________
   
   6.3. How do I make NetWare-related TSRs work? They won't work in the
   login script? 
   
   They won't, no matter how hard you try either. Win95 runs the login
   script from a single DOS session, which completely unloads when the
   login script finishes. Loading TSRs from a login script is stupid
   anyway, in fact, loading DOS TSRs in Win95 in general is stupid.
   
   But if you have to load network TSRs, Win95 did keep the old
   WINSTART.BAT capability. WINSTART.BAT, in your Win95 directory,
   executes just after all the network components load, and just before
   the login prompt comes on. Load your TSRs in that. They will be
   available from all DOS sessions afterwards. Details are in KB article
   Q127794. Yes this does work; I can run Cheyenne's ARCSERVE (TM)
   for Windows 5.01 by loading BREQUEST.EXE this way. Which reminds me:
   Do any of you know of a 32-bit BTRIEVE requester for Win95 yet? Oh
   yes, TSRs loaded in WINSTART.BAT execute in an independent DOS session
   which you'll never see.
     _________________________________________________________________
   
   6.4. How do I use a client other than Microsoft's Client for NetWare? 
   
   I won't touch Client32 yet; you can read about it at Novell's
   Client32 Home Page and make your own judgments. However, some
   applications need to see real mode NetWare clients (even though all
   the real mode hooks are there with Client for NetWare, and with
   Services for NDS). So...
   
   To use a DOS client, you will need all the regular DOS client software
   (LSL, IPXODI, etc). Once you have all that in place, you can add Win
   3.1 support from Network Control Panel as a Client.

     * 6.4.1. NETX: 
       
   Novell no longer recommends running NETX, but it does work as it did
   with Win 3.1. Install the DOS client, then add "Novell NetWare Shell
   3.x" as a Client from Network Control Panel. Setup will prompt you for
   Novell's disks when needed.

     * 6.4.2. VLM: 
       
   This works better with Win95 than NETX, and is "Safer" than Client for
   NetWare for your finicky programs and NDS apps. Try this as a last
   resort, if you can't get the app makers to clean up their programs.
   Use Novell's regular DOS installation of this client (Don't add the
   Windows software from Novell's setup), then add "Novell NetWare Shell
   4.x and above" as a Client from Network Control Panel. Setup will
   prompt you for Novell's disks when needed.
   
   NOTE: Do NOT use Client for MS/File & Print Sharing for MS networks
   alongside a real mode NetWare client! Neither Novell nor Microsoft
   support this, and the mix of real mode/protected mode clients can
   cause loss of hair for network administrators. Use all protected mode
   clients and services if you want NetWare logins AND peer sharing.
   Client/FPS for MS networks works great alongside Client for NetWare,
   and even Client32 from Novell.

     * 6.4.3. Client32 
       
   Well, I don't believe in it myself, because Novell introduced its
   server concepts to Win95; concepts that belong in the server. Read all
   about it in Novell's Client32 FAQ. I don't have the web space to
   write about this, but I would like any and all input on using this
   client (preferably from administrators who don't work for Novell.)
   
   Basically, you get the big 4 MB download, extract it to
   SYS:PUBLIC\CLIENT\CLIENT32 (or other convenient space) and either run
   its Setup program, or install it from Network Control panel as a
   Client. The Setup program will automatically remove any other NetWare
   client for you, but it has a hard time with Client for NetWare. You're
   probably better off manually removing CNW and installing Client32 by
   hand. Installing this client also installs a Novell version of IPX
   protocol, which extends MS's NWLINK (You still need MS's IPX protocol
   for Win95 compatibility). You can use any Win95 net card driver, or
   use Novell's 32-bit ODI drivers. I suggest you keep it simple and use
   a proper Win95 NDIS 3.1 driver.
   
   Client32's properties are quite extensive, so take the time to view
   that client's properties and settings, as is their IPX32 protocol.
   Novell also has instructions for forcing Client32 into a Win95 setup
   using the MSBATCH.INF file. You may also use BATCH.EXE (from the Win95
   CD-ROM) to attach it to a server-based installation.
   
   Ultimately, I don't think Client32's needed except for very special
   cases (basket cases maybe?) so try to avoid this, unless you like
   seeing multiple instances of IPX or you don't use a notebook computer
   (Novell didn't get Dial-up Networking working right with Client32
   quite yet). If you update the server, Win95 clients can run VLM or
   Client for NetWare safely.
   
   WARNING: Novell's got a Windows 95 conspiracy going. (OK this is my
   imagination but think about it for a bit...) They released an NPRINTER
   "Open Beta" a while back, which requires their Client32 because it
   uses NLMs instead of VxDs. Read about Win95 NLMs in Novell's Client32
   FAQ; they're basically writing a CLIB/NLM subsystem for Windows 95
   that completely replicates Win95's VxD functionality and takes up more
   space. I figured out how to make MSPSRV (Microsoft's PSERVER for
   Win95) working in NDS so you can use that instead. 3Com now includes
   special drivers for Client32 in their network card software kits.
   
   Why do I care? You ever see Novell writing NLM subsystems for the
   Macintosh client? For the OS/2 client? No. So why are they wasting
   their time here? What makes Novell so special they can't work with the
   OS instead of against it?
     _________________________________________________________________
   
   6.5. How do I connect to the server from Single mode DOS? (Outside of
   Win95) 
   
   Win95 Network Setup installed a real mode client for NetWare at the
   same time as the protected mode one. If you exit to DOS ("Restart in
   DOS mode") or boot to "Command Prompt Only", and you're using
   Microsoft's Client for NetWare, you can log in to the NetWare server
   by typing

NET START NWREDIR

   at the DOS prompt. This will load a NETX compatible client using NDIS2
   drivers and protocols. You can then change to your login drive and
   perform a normal DOS client login. Since it's only a NETX compatible
   client it can't perform NDS logins; so you could try:

NET START NWLINK
VLM

   Which uses Novell's VLM client, to do NDS logins. I haven't tried
   using Microsoft's IPX and Novell's client together, but in theory it
   should work. If it doesn't, you can always load Novell's net card
   drivers (LSL, etc) and VLM.
   
   NOTE: NWREDIR's real mode components take more conventional memory
   than a NETX client would, so you should only use this if your
   application can't run in a DOS session, or if you're performing any
   debugging. However, these components will automatically load high if
   you have upper memory available. You should prepare a special PIF
   file for this kind of configuration.
   
   In addition, I found sometimes NET START NWREDIR would give a "This
   file system is incompatible" style of message, which happens more
   often on NetWare 4 servers. If this happens, NET START NWLINK followed
   by NETX or VLM should work.
     _________________________________________________________________
   
   6.6. How can I receive NetWare popup messages? 
   
   With Client for NetWare, use WINPOPUP. Add it from Add/Remove
   Programs/Windows Setup, in the Accessories components. Keep this
   loaded or you won't be able to see or send pop up messages. WINPOPUP
   will receive messages from Bindery and NDS clients, but you can only
   send messages to Bindery clients. Novell's SEND command in a DOS
   session will let you send messages to NDS clients.
   
   You can force WINPOPUP to load by keeping a copy of it in SYS:PUBLIC
   (or any other public place) and enforce a System Policy to run it
   on start-up. In Default Computer/System/Run, insert an entry with a
   UNC path to WINPOPUP.EXE, such as \\SRV\SYS\PUBLIC\WINPOPUP.EXE. This
   way, the users don't have any excuse for not seeing pop up messages.
   
   NOTE: Enforcing a policy like this will prevent any other programs
   that run from this Registry entry (like SAGE.EXE from MS Plus) from
   running. If you have to, include an entry for SAGE.EXE as well (No
   error messages come up if the file is missing, so no worries if some
   machines don't have Plus) or any other programs that run from this
   Registry key (Example: MSPSRV.EXE; Print Agent for NetWare). Again, if
   a machine doesn't happen to have the file, the user won't notice an
   error message or anything.
   
   I've tried a couple of ways of getting WINPOPUP in people's faces
   without disturbing the Run Registry key. One of them is to set up a
   custom Startup folder in the server, but this requires User
   Profiles and prevents anything else running from the Startup group.
   I've also tried including it in the system login script
   (#C:\WIN95\WINPOPUP); this works very well but it won't start
   minimized. I can't seem to get the START.EXE command working in a
   login script but feel free to try it; the login script processor will
   run any DOS or Windows program. There's of course, putting it in load=
   in WIN.INI, or better yet, sticking a shortcut (WINPOPUP.LNK) in the
   load= in WIN.INI so you can start it minimized, but you have to go
   edit each Win95 station to do it. (Sigh) Another way to do the load=
   entry in WIN.INI would be to add it to Client for NetWare's .INF file,
   so it adds this line when it installs. This way you wouldn't have to
   go around and change it afterwards. Or you may also use INFGEN.EXE
   (Part of the Win95 service pack 1 Admin Edition) to build an .INF file
   which adds said line to WIN.INI, and then merge it to MSBATCH.INF
   using BATCH.EXE to install it automatically.
   
   For all of Novell's clients, their supplied NWPOPUP works just fine.
   NWPOPUP however, looks for a Novell version of NETWARE.DRV (Yes I mean
   the old 16-bit driver) and won't work with MS's NETWARE.DRV stub.
     _________________________________________________________________
   
   6.7. Why don't I get a NetWare login prompt when Win95 starts?
   
   This is related to a password caching problem I read about on
   Win95NetBugs. If the .PWL file is around 900 bytes, it will
   by-pass the NetWare login prompt and start Win95 straight away. Login
   scripts won't execute, and the only way to get them to execute is to
   Shut Down/Close all programs and log on as different user, and re-log
   in.
   
   To correct this, delete all .PWL files in your Win95 directory and
   re-start the computer. While you're at it, disable password caching
   via system policies.
     _________________________________________________________________
   
   6.8. Bugs to watch out for, and patches (and links to appropriate
   Win95NetBugs pages) 

     * 6.8.1. Automatic Frame Detection Bug: 
       
   Auto detect does not always work, especially in multi-protocol
   networks. Bring up IPX properties and manually select a frame type.
   Use 802.3 on pre-NetWare 3.12 networks, use 802.2 on 3.12 and later
   networks.

     * 6.8.2. NetWare C$ peer sharing bug: 
       
   If you use Remote Administration, it may keep the Admin share
   active after you disconnect! Apply Service Pack 1 to fix.

     * 6.8.3. WAN routing tables keep getting trashed: 
       
   When Win95 stations act like NetWare servers, all hell can break
   loose. SAP traffic can bog the network, RIP routing tables get
   re-built, clients might log in to a Win95 station instead of the real
   NetWare server. Don't use File & Print Sharing for NetWare to share
   out printers and files to non-Win95 clients; use the server and print
   queues like you're supposed to, or use Client/FPS for MS networks
   instead. More on print sharing via RPRINTER later.
   
   NOTE: Novell's latest patch sets for NetWare 3.11, 3.12, and 4.1
   correct routing problems caused by lots of SAP traffic. Visit
   netwire.novell.com and get the base OS patch sets for your
   version of NetWare. Also, to prevent non-Win95 stations from trying to
   log in to Win95 machines using FPS for NetWare, set their Preferred
   Server switch to the server you're supposed to log in to.

     * 6.8.4. Password caching bugs: 
       
   Win95 will store your login password locally, and the password
   encryption is easily cracked! Apply Service Pack 1 to fix, or better
   yet, disable password caching and use User Level Security for
   peer sharing. Check out the System Policies part to find out how
   to do force this.

     * 6.8.4.1. How do I disable password caching? 
       
   Set up a system policy file, and include "Disable Caching of
   Login Password" or "Disable Password Caching" in Default
   Computer/Network.

     * 6.8.5. Server ABENDs when I start a Win95 machine (and other
       bugs): 
       
   Any general mishap that occurs to the server that either causes an
   ABEND or otherwise kills it (I won't get into technical details; all I
   know is that Win95's demonstrated that it does bad stuff to NetWare
   servers). Check the steps you need to prepare the server or
   dis-arm the Win95 client.
     _________________________________________________________________
   
   6.9. Top ten NetWare client mistakes 
   
   10. Using a '386 machine as a server with Pentiums running Win95 as
   clients
   
   9. Installing File & Print Sharing for NetWare without knowing what
   you're doing
   
   8. Enabling long filenames on a NetWare 3.11 server (Patch it
   first!)
   
   7. Installing Novell's Client32 out of fear
   
   6. Capturing LPT1: to a network printer when you have MSPSRV (Print
   Agent for NetWare) on some workstation
   
   5. Turning on SAP advertising in a large routed network
   
   4. Leaving "Auto-Detect" as the frame type for IPX
   
   3. Not specifying the preferred server in Client for NetWare
   properties
   
   2. Not updating the server before adding Win95 clients
   
   1. Not using system policies (Always a good idea to use system
   policies for basic stuff)
     _________________________________________________________________
   
   6.10. What does Client32 offer that MS's client does not? 
   
   This question bugs me all the way down to Hell. Novell Client32's
   features probably won't be used by about 90% of us. For the remaining
   10%, I will assume you already know everything about Windows 95, and
   this FAQ will consequently be useless to you.
   
   OK, back to reality: What does Client32 have extra?
     * Synchronizes time with the preferred server automatically
     * Lets you log in to multiple NDS trees
     * Lets you use NetWare over TCP/IP (referred to by Novell as
       NetWare/IP)
     * Brings Novell's NLM technology to Win95
     * More control over IPX protocol
     * Supports Packet Signature for extra security
     * Tells you when it's time to change your password (If you have
       expiring passwords!!!!)
       
   There are a couple of other tidbits, but these are the biggest
   attractive features of Client32. Here are my arguments against the
   above features:
     * Use MS's NDS client in addition to the Client for NetWare (even
       for Bindery servers) to sync time automatically, or include #NET
       TIME in the login script.
     * I thought the whole point of NDS was to avoid multiple "domains"
       or directories. Who needs multiple NDS trees? Merge your trees
       into organizational units and simplify.
     * No answer for NetWare/IP, but understand that NetWare/IP is just
       IPX over TCP/IP. I would say don't waste time with TCP/IP and
       stick with IPX. it's more flexible than TCP/IP for NetWare
       networks anyway.
     * NLMs replicate Win95's VxD technology needlessly. We don't need no
       stinkin' NLMs in Win95.
     * IPX is the easiest routable protocol to implement. The only
       settings I found needed to change are frame type, max sockets, and
       max connections, all controllable with MS's IPX "compatible"
       protocol just fine.
     * Packet Sig belongs in the realm of Maxwell Smart and the Cone of
       Silence. If you're not in this realm, don't bother.
     * Expiring passwords? Well... this was a definite MS oversight.
       Disable password caching, and send broadcast messages if you have
       to when it's time to change them.
       
   The point I'm trying to make is, try to use the stuff that comes with
   the OS before resorting to memory-hogging add-ons. Client32's the
   biggest hunk of code to grace the networking scene and it complicates
   the system far too much for 90% of us.
     _________________________________________________________________
   
   6.11. What's this I heard about Client for NetWare only being NetWare
   2.2 compliant? 
   
   I've heard bullsh*t about this since Novell's tech note announcement
   regarding FPS for NetWare. In their tech document 2907903, Novell
   states that Microsoft's File & Print Sharing for NetWare identifies
   itself as a NetWare 3.12 NCP server, but really uses codes and packet
   types from NetWare 2.2 servers. This is why that Client32 can't see
   Win95 computers running FPS for NetWare, even with SAP advertising
   turned on. Novell has a reputation for accuracy so I think this is
   true.
   
   OK, I believe that MS reverse-engineered NetWare 2.2 to make FPS work.
   What I don't believe is everyone else claiming that the REST of Client
   for NetWare is only 2.2 compliant. NetWare 2.2 clients (and MS's FPS
   for NetWare) can't do Packet Burst. Client for NetWare and NetWare
   3.12 servers (and better) can. NetWare 2.2 clients (like NETX) can't
   log into NDS trees. OK, neither can Client for NetWare, but the NDS
   add-on fills that gap. You're going to say that MS's NDS client is
   only NetWare 2.2 compliant?
   
   Novell's obviously published the NCP client and IPX specifications,
   because other developers (notably Artisoft and IBM) released NetWare
   clients for their products. Microsoft followed suit as well. I don't
   expect Novell to release NCP SERVER specs, which lead, most likely, to
   MS's decision to take NetWare 2.2 apart and re-write it as a Win95
   service.
   
   And so what if FPS for NetWare only acts like a 2.2 server? I only
   recommended FPS for NetWare for sharing between Win95 machines
   and for Remote Administration. In these two jobs, FPS for NetWare
   works as designed.
   
   And here's a good one for Novell. In the same document, they claim
   that Remote Registry Service depends on FPS for NetWare. Wrong.
   (Insert buzzer sound here.) While Remote Registry depends on User
   Level Security, that security comes from a security API in Win95
   (SECUR32.DLL), which goes through the security provider software that
   comes with the CLIENT. It does not depend on any file sharing service,
   though, yes, you would need file and print sharing to go peeking into
   someone else's hard drive remotely. If Novell wanted to make Client32
   work with remote administration, they could license code from
   Microsoft (gasp!) and write their own security provider code. Bet they
   can't do that in NLMs.
     _________________________________________________________________
   
   6.12. How do I share my hard drive or printer to other NetWare users?
   (Avoid if possible) 
   
   Depending on whether the clients are Win95 clients or DOS clients, it
   can be either really easy or really messy! Complications include the
   SAP Advertising bug.
   
   If the clients are other Win95 machines running Client for NetWare,
   you merely have to install File & Print Sharing for NetWare networks,
   and specify your NetWare server as the security provider in Access
   Control. When you re-boot you can share out drives and printers to
   specific users in the NetWare server's Bindery.
   
   Now, if the client runs Win95 there's no real troubles, because Win95
   will perform "Workgroup advertising" which works like the workgroup
   naming service (browse master) in WFWG, and this won't interfere with
   normal NetWare communication. To ease browsing troubles, set one of
   the sharing machines (like the one with the printer attached) and have
   Workgroup Advertising: "Enabled: Preferred Master" so the browse
   master control doesn't bounce from machine to machine, and broadcast
   useless messages to your server.
   
   Beware if you want to share to non-Win95 clients via FPS for NetWare;
   you have to turn on "Service Advertising Protocol" (SAP). This is how
   NetWare servers become aware of each other, and if you turn on SAP for
   a Win95 machine, it will appear in SLISTs and SYSCON etc as NetWare
   servers. You can even get connection info (Server version: "Windows 95
   4.00.950, 250 user") from SYSCON. Problem is, not only would SAP
   advertising by a lot of Win95 systems cause a lot of network traffic,
   it could possibly kill any routing in an inter-network, and make DOS
   clients try to log in (as in Preferred Server login) to Win95 servers,
   which won't work. If you really want to screw up your network, share
   out your hard drive with the share name SYS and make a directory
   called LOGIN, and watch what happens. NOTE: Please don't do this,
   unless you LIKE getting beaten up by your network administrator.
   
   A better solution is to install FPS for MS networks and put either
   WFWG on the non-Win95 clients, or if they can't run Windows, Workgroup
   Connection for DOS. Both of these can run alongside Novell's NETX and
   VLM client software. OS/2 Warp Connect can load Windows and NetWare
   clients simultaneously as well. To save on memory on the DOS
   computers, consider using "Direct Hosting over IPX", which will remove
   the need to use NetBEUI and save 40 KB of memory or so. The absolute
   smartest way, however, is to use a common space on the server.
   
   Now printer sharing is another story...

     * 6.12.1. How do I share my printer through RPRINTER or PSERVER
       instead? 
       
   Oh no... you can't run RPRINTER.EXE on a Win95 station because you
   have to run it before Windows loads! Well, you could use VLM and
   RPRINTER together but what's the point of real mode network software
   on Win95? There is a better way. And no, running it from WINSTART.BAT
   doesn't work. Actually I haven't tried loading it from WINSTART.BAT;
   if you want to try it out, please let me know how you made out. But
   otherwise...
   
   Download and Install Microsoft Print Agent for NetWare. Add a
   Service from Network control panel and hit "Have disk", then tell it
   to look in ADMIN\NETTOOLS\PRTAGENT on the Win95 CD-ROM, or wherever
   you extracted that download. Note that Print Agent will only work if
   you run Client for NetWare; it won't run with VLM or Novell's
   Client32. MSPSRV is a Queue Server (as opposed to a Remote Printer).
   
   BE WARNED: MSPSRV was a last minute hack by Microsoft and doesn't have
   the re-connect features, etc of Client for NetWare. In addition, it
   requires a Bindery print server object. NetWare 4.x Administrators:
   Use PCONSOLE to make Bindery mode print server objects.
   
   Just before you re-boot, change your IPX properties so you have
   Maximum Sockets and Maximum Connections set to at least 70, like
   RPRINTER/PSERVER's recommended setting of

SPX CONENCTIONS=60

   I suggest 70 instead of 60 because FPS for NetWare and Remote Registry
   require additional free sockets. And speaking of Sockets, you can't
   use a third party TCP/IP dialer if you plan to use MSPSRV, because it
   uses the Winsock interface over IPX.
   
   Now, also just before you re-boot, run PCONSOLE and create a new print
   server object. Add one printer to it named "Printer 0", set for Remote
   Parallel, LPT1 (Or just Parallel on NW 4.x servers). Attach it to a
   print queue on the NetWare server, if necessary, detaching the queue
   from any other print server object it was attached to. If you did
   detach it from an existing print server object, you will have to
   re-start that PSERVER, which usually means typing "unload pserver" and
   "load pserver xxxxxxxx" (whatever the print server object's name was)
   from the NetWare console.
   
   Now finally, re-boot the Win95 station and log in. The local printer
   attached to LPT1: will now have a "Print Server" tab in its properties
   sheet. Be warned: This tab has bugs, so follow these six steps
   precisely!
    1. Select the Print Server tab and turn on "Enable print server for
       NetWare". If you get any evil error message just ignore it.
    2. Select the NetWare server with your new pserver object, from the
       DROP DOWN LIST, even if it was already selected.
    3. Select the pserver object you just created from the NetWare server
       drop down list.
    4. Select how often you want this computer to check the queue for
       print jobs. The 30 second default is fine.
    5. Hit OK.
    6. Hit Start Menu/Shut Down, close all programs and log in as
       different user, and re-log in. Now all jobs in that NetWare queue
       will find their way to this printer.
       
   The reason you have to re-log in, is you will lose your drive mappings
   as soon as you OK those settings! MSPSRV is riddled with many dumb
   bugs, but Microsoft seems to swear by it. Check out KB article
   Q134747 for all the gory details. Every time you view this
   "Print Server" tab, it seems you will lose all your drive mappings.
   Re-logging in will restore them.
   
   You will also have to create a print server object for EVERY Win95
   computer sharing a printer this way, because each system becomes a
   PSERVER look-alike (called a Queue Server), with all the requirements
   of a stand alone PSERVER.EXE or PSERVER.NLM; the only difference is
   that it multi-tasks. You will also have to remain logged in to keep
   MSPSRV running, as logging out causes all programs to close, including
   MSPSRV. It will re-start when you re-log in, or cancel the log in. On
   machines with very active printers, you might want to consider setting
   their Default Login to "Windows Logon" with a blank password, so they
   automatically log in to NetWare on power-up, and re-enabling Automatic
   NetWare Login for those specific machines, if you disabled it via
   system policies.
   
   Oh yeah, one more thing: Don't capture LPT1: to a network queue if
   you're running MSPSRV to share a printer. This might have worked in
   RPRINTER, but it doesn't work here. What will happen is that MSPSRV
   will suck the job off the queue and send it to the printer hooked up
   to LPT1, then that printer will send the job to wherever LPT1 was
   captured to, instead of to the local printer! I've seen this happen!
   Create a second printer in Win95 and have it point to the queue, if
   you're afraid of cutting in front of other people's print jobs.
   
   So to recap: Create a print server object with a single printer for
   each Win95 computer sharing a printer through MSPSRV. Attach a print
   queue to each of them. Make sure you aren't capturing LPT1: to a
   network printer. Install MSPSRV on the Win95 computers sharing
   printers. Set Max Connections and Max Sockets to at least 70 in
   IPX/SPX properties. Re-boot to activate. Select the "Print Server" tab
   in the printer you want to share. Select the file server from the
   drop-down list and the print server object from its drop down list.
   Hit OK. Re-log in. And Pray.

     * 6.12.2. ...on a Directory Services network? 
       
   I managed to get MSPSRV running on an NDS network. Originally, I
   thought switching the NetWare 4.1 version of PCONSOLE to Bindery mode,
   and creating Bindery queues and print server objects, would do the
   job. Apparently not. NDS clients can't readily print to Bindery print
   queues.
   
   So, after a lot of fiddling I realized that Novell's Quick Setup
   option in PCONSOLE does the job almost perfectly! Quick Setup creates
   a new NDS queue, NDS printer, and NDS print server object, and makes a
   Bindery version of the queue and print server object, granting
   printing rights to everyone in the NDS tree. A little extra fine
   tuning and it works straight away with MSPSRV. Here's what I did, with
   my example object names in (parenthesis):
    1. Use PCONSOLE's Quick Setup option, in NDS mode, to create an NDS
       queue (Q1), printer (P1), and print server object (PS-INLINE). If
       you already have an NDS print server object, be sure to specify a
       NEW print server object and not use any existing ones.
    2. Change the new printer object (P1) so it uses LPT1, IRQ 7, "Change
       forms as needed", and have it service the NDS queue (Q1).
    3. Switch PCONSOLE to Bindery mode (Press F4), edit the Bindery queue
       (Q1) so its settings match the NDS queue. Add the Bindery print
       server object (PS-INLINE) to the list of print servers for this
       queue.
    4. Edit the Bindery print server object (PS-INLINE) so its settings
       match the NDS print server object, and create a Bindery printer
       within this object with the same name as the NDS printer object
       (P1), and the same settings (printer number 0, LPT1, IRQ 7, Change
       forms as needed). Have this Bindery printer service the Bindery
       queue (Q1). The big catch is that Bindery configurations aren't
       accessed by NDS objects, or vice versa, as PCONSOLE's warning
       tells you. Heed that warning.
    5. With all that accomplished, the NDS objects and Bindery
       equivalents will work together as if they were one set of objects.
       Now, go to the Win95 station running MSPSRV and have it service
       this print server object (PS-INLINE) as per the regular
       instructions. If you're switching an existing queue to this new
       print server, you'll need to stop and re-start PSERVER.NLM on the
       server so it won't try to service that queue anymore.
       
   All this fiddling may take a while, but it's the quickest way I could
   get it working, so that both NDS and Bindery clients can print to the
   printer shared via MSPSRV. And surprisingly, many of the bugs
   Microsoft mentioned in KB article Q134747 above, don't show up this
   time. Not bad at all! Yes, you have to do this for each Win95 station
   sharing a printer this way.
   
   Best of all, MSPSRV takes far less memory (a mere 64 KB on the
   workstation) than Novell's NPRINTER Open Beta.
   
   Rob Menasco outlined a few additional things to watch out for:
     * Go through the Print Server tab and reselect all items, click on
       "Apply". (This is documented in the MSPSRV KB article above;
       reselect the print server from the drop down list)
     * Re-boot, make sure print server is active. I do a USERLIST from
       DOS and look for an attached print server in PCONSOLE.
     * In the Spool button on Printer Setup: Set to "Direct Print" and
       "Bi-Directional". This fixes the unknown system error. (I gather
       this is so MSPSRV writes to LPT1: directly, rather than through
       the Win32 print API)
     * Watch for the source or error messages. The Spool errors come from
       SPOOL32 or the PRINTERS folder.
     * Watch for Rights problems (Use WINDOWS_PASSTHRU account; make sure
       it has rights to the spool).
         _________________________________________________________________
   
   6.13. How do I make Win95's cool network features work on NetWare? 
   
   It took a bit of practice but I managed to get everything working,
   including Remote Registry. Some basic items to remember when
   installing Client for NetWare alongside of these cool features:
     * Use IPX Maximum Connections and Maximum Sockets values of 32 each
       (70 if using MSPSRV too)
     * Create a separate Administrators group if you have a team of
       administrators to simplify setting up Admin permissions.
     * Set aside lots of space (250 MB total about) on your SYS: volume
       for user profiles. (About 200 KB per user)
     * Install any patches needed to make long filename support work, in
       fact, install the base OS patch set for your version of NetWare.
     * Create a WINDOWS_PASSTHRU user with 0 KB disk space limit, a blank
       password, and no privileges whatsoever. (This is so you can
       administer workstations that don't have anyone logged in to. You
       can do without this account, but someone will have to log into
       that station before you can remotely administer it. Kinda
       pointless actually.)
       
   So here's how to do all those cool features...

     * 6.13.1. System Policies 
       
   Prepare the CONFIG.POL file using POLEDIT.EXE (On the Win95 CD-ROM)
   and copy it to your Preferred Server's SYS:PUBLIC directory. I finally
   verified this and sure enough, it reads from SYS:PUBLIC. Make sure
   that everyone has read and file scan rights to this directory,
   including GUEST if you have such a user.
   
   Useful policies for NetWare networks include:
     * Network path for Windows files
     * Remote Update: Automatic (Use default path. In this case, the
       default path is \\loginserver\SYS\PUBLIC\CONFIG.POL)
     * Disable/Enable Long Filename support (You have three choices here,
       disable, enable, enable for NW 3.11 or older servers)
     * Disable Password Caching
     * Disable File and Print Sharing Controls (Remote
       Administration still works)
     * Disable Automatic NetWare Login
     * Preferred Server
     * Disable SAP Advertising
     * User-Level Security (Use your server's name as security provider)

     * 6.13.2. System Policies on a DS network 
       
   Microsoft's Services for NDS has some pretty cool extensions to this
   policy logic; you can enforce policies dependent on whatever level on
   the NDS tree you log in to (whatever your current context is),
   including specific Organizational Units, or the entire Organization.
   All this stuff only works if you installed MS's Services for NDS in
   addition to the Client for NetWare, and you're doing NDS logins.
   Otherwise, for Bindery logins, it still reads CONFIG.POL from
   SYS:PUBLIC.
   
   Let me make that clear: The NDS client has two separate rules, one for
   a Bindery login (Same as for original Client for NetWare) and one for
   a DS login. You need to specify the DS policy file and the Bindery
   policy file if users switch between DS and Bindery logins.
   
   To add NDS policies, change your POLEDIT template to the MAPLE.ADM
   template included with Services for NDS. Then load your
   previously-made CONFIG.POL file and make the appropriate NDS policy
   changes. All other policy settings made from ADMIN.ADM will stay
   unchanged.
   
   Bring up your Organization and Organizational Unit icons up in Network
   Neighborhood. If you have Admin privileges in these units, bring up
   properties for them. You'll see an "NDS Administration Settings" tab.
   Here, enable system policies and specify the volume name (including
   context, such as MYSERVER_SYS.MYORG) and file name (including path,
   such as PUBLIC\CONFIG.POL) for the policy file. The name need not be
   CONFIG.POL; it can be INLINE.POL or whatever, but you should make sure
   that the policy file is in a public place, such as the good old PUBLIC
   directory. Do this for each Organizational Unit and for the whole
   Organization as you see fit. Both Bindery and DS policies can come
   from the same CONFIG.POL file.
   
   NOTE: Policies don't flow down the NDS tree like other properties do.
   You will have to re-apply the policy setting to each Organizational
   Unit within your master Organization, or you may use different
   policies for each Organizational Unit.
   
   Two very useful NDS policies (Include these in the Organization's
   properties along with other basic policies):
     * Load NetWare DLLs at Startup (To make dumb NDS apps work. Also
       copy the DLLs themselves from SYS:PUBLIC\CLIENT\DOSWIN to
       SYS:PUBLIC)
     * Allow only NDS logins (To prevent User Profile and System
       Policy screwups)
       
   LICENSING ALERT: If you maintain multiple servers and one policy file,
   a single login will consume one license on the default login server,
   AND on the server with the policy file! If these are the same server
   there's no problem, but if the policy file is on a different server
   (as you specify with the NDS Admin settings), Win95 won't log out from
   that server until the user logs out from that station (Perhaps not
   until shutdown?)
   
   One workaround could be to use that Win95 NCP server, as suggested in
   section 6.16.7 below, to store the policy files (which has a "250
   user" license, if SYSCON is to be believed). To accomplish this, first
   add the Win95 machine in question to the DS tree, using NWADMIN, as a
   NW 3.12 (or other non-DS) server. Then add a volume object which
   matches one of that machine's share names. (You need this because the
   policy file has to exist on a defined DS volume!) Finally, copy that
   policy file there and specify it in the NDS Admin settings as normal.
   This is a hair-brain scheme; I can't test it because I don't have
   access to a DS network to try it on.

     * 6.13.3. Group Policies 
       
   You will need to include group policy support on each workstation to
   enforce policies for GROUPS of users, and the groups themselves must
   exist in the server's Bindery or Directory.
   
   To add group policy support, run Add/Remove Programs/Windows Setup,
   hit "Have Disk..." and pick the path on the CD-ROM
   ADMIN\APPTOOLS\GROUPPOL, and select Group Policy support. Once done,
   Win95 knows to grab policies you set for groups of users as well as
   specific users.
   
   You can automatically install group policy support on workstations by
   adding Group Policy support, using INFINST.EXE to add it to the server
   copy.

     * 6.13.4. User Profiles and Roving Desktops 
       
   Win95's Client for NetWare stores a user profile in their MAIL
   directory, so be sure you give each user one. SYSCON automatically
   creates a MAIL directory for each new user. The Win95 station copies
   their profile to the MAIL directory on log out, and reads it in on log
   in.
   
   You should enforce "Enable User Profiles" as a system policy, to
   keep multiple profiles straightened out.
   
   Now regarding Roving Desktops. The Desktop directory and Start Menu
   directory (which as you would recall, are just a bunch of .LNK
   and .PIF files) get copied to the user's MAIL directory too, if they
   turned on "Include Desktop" and "Include Start Menu" in Passwords/User
   Profiles. Because Shortcuts have long filenames, you need to enable
   LFN support on the SYS: volume. This will only work on patched NW
   3.11, NW 3.12, or NW 4.x servers with the OS/2 name space installed.
   Enforce LFN support via system policies.
   
   You should also ensure you have enough space on your SYS: volume for
   the shortcuts! Microsoft recommended setting aside 150 KB per user,
   but my own custom profile eats 250 KB easily!
   
   Services for NDS stores a user profile in the user's HOME directory
   instead of the MAIL directory, so make sure you define a home
   directory for each user, but the same rules regarding roving Desktop
   and Start Menu (LFN support, space requirements) apply.
   
   NDS clients can perform Bindery and NDS logins, so it is possible to
   have two sets of profiles for each user, one in their HOME directory
   and one in their MAIL directory! You should enforce NDS logins only,
   via system policies, to prevent this mix up. Remember that MS's
   NDS client has two separate policy rules for Bindery and DS logins.

     * 6.13.5. User-Level Security 
       
   Quite easy. Do it through System Policies. In the CONFIG.POL you
   create, specify User-Level Access, and type in the name of the server,
   and specify the type of server as NetWare server.
   
   If you do this on a DS network, the server you specify needs Bindery
   Emulation turned on. To do this, make sure you have this somewhere in
   your AUTOEXEC.NCF file on the server:

Set Bindery Context = 0=MYORG (and how many other OU= entries you want)

     * 6.13.6. Remote Administration 
       
   Install FPS for NetWare or FPS for MS networks, install Remote
   Registry service, and enable User level security (No choice
   really for FPS for NetWare). Keep SAP advertising OFF. Then, from any
   other Win95 station, log in as SUPERVISOR or ADMIN and get properties
   on the Win95 station from Network Neighborhood. Use the new Tools tab
   to access administrative programs.
   
   Of the available remote admin tools, Net Watcher will also work for
   viewing activity on the NetWare server, as well as the Win95 machines.
   Net Watcher grabs the same information made available via SYSCON. You
   may remove users from the server as needed too.
   
   There is one bug in Remote Administration, that makes the remote
   system keep sharing its hard drive, even when you end the Remote Admin
   session. Install Service Pack 1 on the remote station to correct
   this. To see if you have this bug, Administer the target machine (so
   you can view its HD contents) then try logging in as someone else and
   hit Start\Run... and type in \\machine\C$. If this brings up a window
   with that drive's contents, you have the unpatched services on there.
   Again, apply SP1 to fix it.
   
   The most wicked tool available, Remote Registry, lets you edit the
   remote machine's registry to fix Win95-specific problems. You need
   this service is you want to run System Monitor, REGEDIT, or POLEDIT to
   monitor or edit the remote machine.

     * 6.16.7. Remote Admin on a DS network 
       
   Remote Administration (and many of Win95's NetWare add-ons) depend on
   Bindery services running on your preferred server. Net Watcher and
   Administer work without hassles, but anything requiring Remote
   Registry (System Monitor, REGEDIT, POLEDIT) needs a separate Bindery
   server to act as security provider. This is a SECUR32 bug in MS's NDS
   client that they admitted to in KB article Q143398. If you use
   the regular Client for NetWare on a DS network, you can use Remote
   Registry on machines that have the NDS client.
   
   So, if you can live without Remote Registry, or if you use the regular
   Bindery client on your Admin machine, you can treat the administrative
   setup like you would for a Bindery network. Of course you can't run
   NWADMIN then, but...
   
   I did manage to get Remote Registry running on an NDS network about
   the same time I got MSPSRV working. Remember where MS said you needed
   to have a separate Bindery server to provide security? Well... Win95
   with FPS for NetWare acts as a Bindery server, so why not use another
   Win95 station as a security provider? It does work! And I was able to
   log in to the NDS tree and run Remote Registry, and NWADMIN, on other
   stations with users logged into the NDS tree, and FPS for NetWare
   worked normally too. This trick comes in handy if you also have
   multiple servers and you're running into the licensing problem I
   mentioned in section 6.13.12; this Win95 machine can also hold the
   policy file and not eat up any licenses on your "real" servers.
   
   Remember: You only need to do this if you want to use Remote Registry
   service on a Win95 DS client running MS's services for NDS in a DS
   network, and you're using MS's Services for NDS on the machine you're
   administering from. Net Watcher and Administer both work without this
   nonsense, and the standard Client for NetWare works with Remote
   Registry straight away.
   
   So here's what I did:
    1. Set aside one Win95 computer (an 8 MB machine will do) and install
       Client for NetWare and FPS for NetWare. No other clients or
       services. Have its User Level Security settings point to your NDS
       server. Check that server's Bindery context so it at least has
       your Administrators' user names available. On that one machine
       ONLY, turn on SAP advertising and turn off Workgroup advertising.
       You might want to get the latest patches for NetWare 4.1, to
       prevent SAP traffic from killing any routing in your network. This
       machine won't work with Remote Registry, so don't bother
       installing it.
    2. On all the other Win95 machines running NDS, change their User
       Level Security settings to point to this one Win95 machine. They
       can still have their original Preferred Server and Preferred Tree
       defaults the way they were. See that all these machines have
       Remote Registry service and FPS for NetWare, and they have SAP
       turned OFF. You can do this through System Policies, but the
       machines will have to re-boot once to make this take effect.
    3. After rebooting the other Win95 machines, change their Remote
       Administration settings so they include users from the emulated
       Bindery on the security-providing Win95 machine. You can even
       specify this machine, if you wish, in MSBATCH.INF during a Win95
       installation.
    4. At this point, all Win95 stations except one are using that one
       Win95 machine for a security provider. That one machine is using
       the NetWare 4.1 server as a security provider, mirroring its user
       list. Remote Registry services will work as they did for the
       original Client for NetWare. If it prompts you for a password, use
       your login name and password.
    5. (Optional) You can even enforce this via System Policies; you
       can add the single machine to the CONFIG.POL file (File/New
       Computer...) and have it use the NetWare 4.1 server for security
       and turn on SAP. Have the Default Computer settings use that one
       machine as provider, and turn OFF SAP. This way you don't have to
       go to each machine to change their security provider settings.
       
   This is a lot of work really. At this point, most sysadmins would've
   probably gone to NT.
     _________________________________________________________________
   
   6.14. My suggestions for preparing an automated Win95 installation 
   
   In the last few weeks (8 AUG 96) many administrators asked how they
   can copy Win95 to several machines at once. Well, they are trying to
   use XCOPY to copy the whole Win95 directory. Let me get one thing
   straight: THIS DOESN'T WORK!!!!!!!!!
   
   Why doesn't a straight XCOPY work?
     * Long filenames
     * 20 MB of hidden files
     * Registry
     * Unique IO.SYS and MSDOS.SYS
     * Program Files directory
     * Different system device drivers for different motherboard
       chipsets!
       
   OK? Image-copying Win95 doesn't work. Get over it. Would you
   image-copy a NetWare server? An OS/2 client? An NT client? No. So
   don't try to image-copy a Win95 client. Make a server based
   installation using the steps below, and automate as much of the setup
   as you can. This way, you can run a Win95 setup from the server and it
   would take just a little longer than a straight XCOPY would, but be a
   lot cleaner.
   
   So, if you're building a Win95 network based on NetWare servers,
   here's my suggestions. These come from my NDS experiments, so you can
   omit any references to the NDS add-on if you aren't using a DS
   network. I based this scenario on workstations that have their own
   hard drives (minimum 200 MB) and copy all Win95 files to the station.
   The stations themselves had these components automatically added to
   them:
     * Client for NetWare Networks
     * IPX/SPX Protocol
     * Net card driver of your choice
     * File and Print Sharing for NetWare Networks
     * Microsoft Remote Registry
     * Microsoft Print Agent for NetWare
     * Services for NetWare Directory Services
       
   Believe me, don't waste time with minimal shared installs if you can
   avoid it. You can do shared installs of the apps themselves later. The
   stations featured full client functionality, Queue Server capability
   as needed, and Remote Admin access.
   
   Optionally, you can replace FPS for NetWare with Client for MS and FPS
   for MS networks. The key to making Remote Admin work is to have some
   kind of file sharing service and some kind of security provider. FPS
   for MS networks does work with NetWare servers acting as a security
   provider. If you do this, make sure you make the NetWare login the
   primary login, and make sure the machines have enough memory to handle
   both clients. If you're doing this on 8 MB machines or you're tight on
   memory, just stick with the single client and services.
    1. Download and install the base OS patch sets for all your NetWare
       servers, and download the Admin edition of Win95 Service Packs.
    2. Make an Administrative installation of Win95 using NETSETUP.EXE on
       one, or more, of your servers. You will need to prepare one Win95
       client to perform the Admin installation from, and this machine
       will probably become your admin workstation. Prepare this Admin
       machine just like you would any of the targets. You could also
       make up your policy file using POLEDIT.EXE, and copy it to the
       server.
    3. Use INFINST.EXE to apply the service pack to the Admin copy. Run
       INFINST, give it the Admin copy's UNC path
       (\\server\SYS\PUBLIC\WIN95 or whatever), give it the path to the
       Admin service pack, and let it install.
    4. Keep using INFINST to apply the needed additional components
       (Services for NDS, Remote Registry, MS Print Agent, etc) to the
       Admin copy. Remote Registry and Print Agent are on the CD-ROM in
       ADMIN\NETTOOLS\REMOTREG or \PRTAGENT. Don't forget to include the
       Group Policy support here too, if you have group policies.
    5. Exit INFINST and run BATCH.EXE (The new version that comes with
       the service pack) and make all the settings you need. In the list
       of Services, pay special attention to the ordering of services
       (NWREDIR4, NWSERVER, REMOTEREG, PSERVER) for those three, because
       MSPSRV (the PSERVER entry) will balk if you add PSERVER before
       NWREDIR4. I know it sucks. You can switch them around later if you
       need. Use BATCH.EXE to make any settings you want for the
       automated install, but be extra sure to keep "Immediately re-boot
       PnP and PCI machines" turned off to prevent Setup from exiting
       prematurely. COOL TRICK: Use BATCH.EXE's "Read settings from
       Registry" to copy the Admin machine's settings. Finally, save the
       settings with filename MSBATCH.INF to the Win95 Admin copy's
       directory.
    6. Make up a network boot disk so you can access the server, and boot
       up a target workstation so you can try installing Win95. Keep the
       Admin machine on and logged in so you can make quick fixes during
       this test.
    7. As Setup runs, you should be allowed to install the right net card
       driver. Also, when that network screen comes up, make sure you
       don't get any errors about "Print agent cannot be installed
       with...". If you do, change the ordering of services back in
       BATCH.EXE and try again. Cancel the Setup here and try again,
       until said message does not come up. PRTAGENT should be the LAST
       entry in the Services box back in BATCH.EXE.
    8. Pay attention to any error messages that occur during file
       copying. You will probably get an error that it couldn't find
       MSNDS.BAT or some such file. If so, go to your ADMIN machine and
       copy the needed files from the NDS client copy to the shared copy
       of Win95, then hit "Retry" on the test machine. You will only have
       to do this ONCE; since the file now exists it won't complain the
       next time you try.
    9. During the second part of Setup, if you get any messages saying it
       found new hardware and it wants you to re-start the computer, hit
       "NO" so Setup can finish. Wait until Setup finishes before
       allowing the system to re-boot.
   10. After Setup finalizes the settings, check to make sure everything
       works. Inspect the network properties so all your settings took as
       you specified. You can then do some final tuning, like setting the
       [vcache] entry in system.ini, and take whatever settings you did
       in your final tuning, and use INFGEN.EXE to have them install
       automatically next time.
   11. Once you're comfortable with your automatic setup, make a few
       copies of that boot disk and happily start making workstations.
       You can continue to add components to this server copy and install
       from them as needed (like the dial-up scripter, Ben Goetter's
       Widgets for Exchange, etc).
       
   NOTE: If you want to maintain more than one Admin copy of Win95, yes,
   you CAN image-copy this Admin installation to multiple SERVERS. Make
   up one good Admin copy, then spread it to all your servers in your WAN
   if you choose.
   
   90% of the NetWare networks out there have remote printers I'm quite
   sure people want to print to. There is no harm in installing MSPSRV on
   every machine (it only eats 64 KB of disk space, and it won't take up
   memory unless you invoke it), or Remote Registry, or File & Print
   Sharing if you disable file and print sharing controls via System
   Policies.
   
   If you add components to the server install AFTER you installed the
   workstations, you can usually copy said components from Add/Remove
   Programs/Windows Setup, then hitting "Have disk" and pointing to the
   server copy of Win95. Anything you can install using INFINST.EXE is
   installable from this control panel, and it will show in the list of
   components to choose from. Definitely see about including a [vcache]
   setting in a custom INF file you can create with INFGEN, and install
   it automatically for a maximum cache size (1024 KB) to make room for
   MSPSRV and Remote Registry.
   
   INFGEN.EXE is a very valuable tool for inserting custom settings. You
   can copy your computer's .INI or Registry settings to this .INF file,
   then install those settings to the server copy using INFINST. It's
   only available with the Win95 Service Pack's Admin edition.
     _________________________________________________________________

--
==============================================================================
= I am Gordon of Winterpeg. Junk mail is futile.          Post MakeMoneyFast =
= Find out why: http://spam.abuse.net/           Or eat pink meat from a can =
= World's best computer: http://www.amiga.de/          they're both the same =
= Win95 FAQ: http://www.orca.bc.ca/win95/ http://www.clark.net/pub/rolf/mmf/ =
==============================================================================

