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.
   
   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.
   
   UPDATE September 1998: Microsoft released bugfixes to a LOT of the
   problems documented here. The files needed, however, appear
   unavailable for download. According to KB article Q132786, the
   following three files replaced will correct them:
     * MSPSRV.EXE v4.00.952
     * NWPP32.DLL v4.00.952 or later
     * NWREDIR.VXD v4.00.952 or later
       
   These come with Win95 OSR 2.1 and 2.5, but I've prepared a
   special download that contains these updated files in case you
   don't have one of these releases (minus NWREDIR.VXD because I only had
   the NDS version).
   
   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).