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 separately 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 some 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 Windows NT.