* 7.6.1. ...system policies? 
       
   System Policies let you enforce a bunch of settings for Win95
   computers on a network. This is real handy to disable long filename
   support for NetWare, or disable password caching, for example, without
   going to each and every computer on the network and editing SYSTEM.INI
   or the Registry.
   
   Copy the contents of ADMIN\APPTOOLS\POLEDIT from the CD-ROM, to a
   convenient directory that only you (the Administrator) have access to.
   The first time you run POLEDIT, it will ask you for a policy template.
   Choose ADMIN.ADM. There are other policy templates for other networks
   (including NDS), but ADMIN covers most of the stuff for now.
   
   Have a nice look at all the settings you can enforce on, enforce off,
   or not enforce. Notice you have three choices; an "On", "Off", and
   "Don't Care"; the "Don't Care" state means that the computer will use
   the setting it already has. "Default User" refers to people, and you
   can add unique policies for unique users if you have a central
   security provider (like an NT domain controller or NetWare server) by
   adding users to this policy file. "Default Computer" refers to
   computers, and you can add computers here as well, named by the
   "Identification" tab back in Network Control Panel.
   
   Definitely set these policies up at a bare minimum:
     * Network path for Windows 95 files
     * Remote Update: Automatic (Use Default Path). Remote Update refers
       to updating local settings from the policy file, and Default Path
       refers to the location of the policy file itself. The default path
       depends on the kind of network client installed (Microsoft
       Networks, NetWare, LANtastic, whatever) and this "Automatic"
       option only works if you have a Win95 client for a central server
       of some kind. You can do non-central policies too, but I'll cover
       that later.
       
   Save this policy file with the name CONFIG.POL and copy it to the path
   your client expects to find it.
   
   POLEDIT also works directly on a local Registry, which is really
   convenient if you don't trust yourself with REGEDIT.

     * 7.6.1.1. ...on a Windows NT network? 
       
   Create the CONFIG.POL and copy it to the NETLOGON share of your
   primary domain controller. You can spread the policy file to all your
   backup domain controllers as well, in which case, the "Load Balancing"
   option can save some server overhead on slow WAN links.
   
   Useful policies for NT networks:
     * Log on to Windows NT (Specify domain name here too)
     * Workgroup (Use same name as the domain to ease browsing troubles)
     * Disable Password Caching
     * Enable Load Balancing (If you use multiple domain controllers per
       domain)

     * 7.6.1.2. ...on another network with a 32-bit client? 
       
   Other Win95 clients will have their own policy templates and their own
   unique location for the policy file. Check with the vendor for the
   details. If there's no default path, you can enforce the "Manual
   Update" policy and specify a UNC path to the policy file (like
   \\SRV\POLICIES\CONFIG.POL), but you will need to run POLEDIT on each
   station to set this in each Registry.

     * 7.6.1.3. ...on another network with a DOS client? 
       
   You will have to set the "Manual Update" policy and set a DOS
   Drive:\DIR\CONFIG.POL path on each station in each Registry. You will
   also need to map this network drive before then end of AUTOEXEC.BAT as
   well.

     * 7.6.1.4. ...on a peer to peer Win95 network? 
       
   If you keep one Win95 station on all the time (Usually the machine
   with the printer attached) you can put a policy file there. You will
   still have to manually change the Remote Update path in each station,
   but this time it can be a UNC path.

     * 7.6.2. ...User Profiles? 
       
   User Profiles are a really, really, cool feature of Win95. Not only
   can you set a personalized desktop for each user and have personal
   Start Menus, but you can have personalized settings for MS Exchange,
   Word for 95, or pretty much any program that stores user preferences
   in HKEY_CURRENT_USER in the Registry! Profiles will also follow a user
   around in a centralized network, copying their program settings to
   each station as required.
   
   To turn on User Profiles, run the Passwords control panel. Regardless
   of whether you installed Networking or not, you turn on "Users may
   select their own preferences" on the User Profiles tab.
   
   Custom Desktops and Start Menus are actually one of these user
   preferences. You can enable or enforce User Profiles, but it's up to
   the users if they want their shortcuts to be unique to them.
   
   Regardless of user profile preferences, Win95 creates a Profiles
   folder, and a sub-folder for each user to store a personal copy of
   USER.DAT, the user portion of The Registry. If the user chooses to
   have custom Desktops and Start Menus, it stores them in that folder as
   well. Deleting shortcuts from Win95's default Dekstop and Start Menu
   folders will not affect a user's personal Desktop or Start Menu.
   
   Profiles work best when you have all Win32 apps, and if you keep
   copies of the apps in the local hard drives, that you install the apps
   in the same place on each computer! The "C:\Program Files" Directory
   is a good place for apps in a User Profile environment. Keep the
   Windows directory the same name on all your workstations too.
   
   SOFTWARE DEVELOPERS: Be VERY VERY CAREFUL where you store your program
   settings! Hardware settings (like local cache directories or modem
   preferences) belong in HKEY_LOCAL_MACHINE, mobile and user settings
   (like bookmarks or spell check preferences) belong in
   HKEY_CURRENT_USER. Test your software in a User Profile environment!
   Netscape Communications gets kudos from me in this regard; Navigator 2
   and 3 support user profiles.

     * 7.6.2.1. ...on a stand-alone workstation? 
       
   The Password Control Panel is always there, whether you have a network
   client loaded or not. In here, select the User Profiles tab, and
   select "Users can customize their settings". Specific users can choose
   to keep a custom Desktop and Start Menu included in their profile.
   
   When you aren't on a network and you have User Profiles turned on, you
   need to have a password for each user, otherwise it will happily
   automatically use the last password-less user's profile. Selecting
   "Shut Down" and "Close all programs and log on as different user" will
   let you enter your own name and password.

     * 7.6.2.2. ...on a Windows NT network so it'll follow the user
       around? 
       
   NT clients keep their profiles in their HOME directory, so make sure
   you define a home directory for each user, in User Manager. NT servers
   3.5 or later have long filename support built in, even for FAT file
   systems, so you have no worries regarding roving desktops and Start
   Menus... just the space requirements.
   
   Also, enforce "Enable User Profiles" through system policies, to
   keep multiple profiles straightened out.

     * 7.6.2.3. ...on another network? 
       
   Roving User Profiles require a central storage space, and are specific
   to what network client you run. So the location of user profiles on
   that network depend on that client. This won't work with Client for MS
   networks without a Windows NT domain to log in to (So it doesn't work
   on just a bunch of Win95 machines together), but you can define a
   custom Desktop or Start Menu for each user, with POLEDIT.
   
   In Default User (Or whoever user) Shell settings, you can define a
   path for custom folders. The custom folders include Desktop, Start
   Menu, Programs, NetHood, and "Hide Start Menu Subfolders". So for each
   user (By selecting Edit/Add User) you can insert a custom path for
   these items. If you do this in one master CONFIG.POL file stored in
   one location, and you have "Remote Update: Manual Path" turned on, you
   can enforce a different Desktop and Start Menu for each user without a
   central server. Just make sure the path exists when Win95 starts
   (Either by using a UNC path, or by logging in before running Win95, in
   the case of real mode clients).
   
   If you also enforce user profiles through the central policy file as
   well, Win95 will store USER.DAT for each user on the machine, but it
   will not follow the user around. If you want the benefit of full
   roving user profiles, get a central server with Win95 client support,
   and check with the network OS vendor about user profile support, if it
   isn't an NT or NetWare server.
   
   Oliver Knorr says it is possible to use roving user profiles on a
   simple peer network. He explained some mistakes in the Win95 resource
   kit that MS documented in KB article Q135849. You first need to
   add Registry entries to each peer machine you want roving profiles to
   work on as described in the article. Then create a PROFILES.INI file
   on your central peer server (isn't "central peer server" a
   contradiction of terms?) and edit one Registry key on all the stations
   to point to that profiles.ini file.

     * 7.6.2.4. Why user profiles is a really cool and useful feature! 
       
   One time I read a question on how to make Netscape 2.0 work with more
   than one user's E-MAIL settings, so it would work with more than one
   provider. The answer was simply: Turn on User Profiles in the
   Passwords Control Panel. With that, Netscape had different settings
   for each user, and what was better, each user had their own dial-up
   networking preferences stored under their own profile!
   
   User Profiles is cool because it offers a central control for
   personalized settings, regardless of whose program you run! The
   software developer doesn't have to account for multiple users for a
   given program; they need only store personal settings in the USER.DAT
   portion of The Registry, and let the OS take care of the rest. I know
   this works with these programs:
     * MS Office 95 suite
     * Corel Graphics suite 6.0
     * MS Exchange
     * Netscape 1.2N up to 3.04 (You will need to fix the cache path for
       each user though, or accept its default)
     * NCSA Mosaic
       
   Other programs Designed for Windows 95 had better work with this.

     * 7.6.3. ...remote administration? 
       
   The Passwords Control Panel has a "Remote Administration" tab that
   works only if you have networking installed. If you use a central
   server, you can assign administrative privilege to a SUPERVISOR or
   Domain Admin.
   
   First, install File & Print Sharing for either MS networks (for a pure
   Win95 or NT domain network) or NetWare (For NetWare networks). If you
   use FPS for NetWare, keep SAP advertising OFF. In addition, install
   the Remote Registry service from Network Control Panel, as a Service
   (in ADMIN\NETTOOLS\REMOTREG on the CD-ROM) on the remote machines. You
   can do this (and even enforce this) when you install Win95 as well.
   
   Now, if the workstations use User level security (highly
   advisable on NT Domains and NetWare networks), Setup will
   automatically enable remote administration for ADMIN and SUPERVISOR
   (NetWare) or DOMAIN ADMINS (NT Domain). If the stations use passwords
   instead of user lists (Share level security), or you don't have a
   central server, you will need to manually enable Remote Administration
   and supply a password to each station. Remote Administration settings
   will differ with each type of network client installed.
   
   Once done, you (the administrator) can control computers via Network
   Neighborhood. Right-click on any Win95 station and select
   "Properties". You will see a "Tools" tab that lets you edit the
   Registry, view network activity, or even browse the hard drives, on
   the remote computer. REGEDIT and POLEDIT also works on these stations.
   
   Of the tools listed, Remote Registry service is the biggest service
   (250 KB). To free up memory so you don't slow down the machines, check
   out How to Prevent Random Hard Drive Access, which also frees
   lots of memory for these services.

     * 7.6.3.1. ...on a Windows NT network? 
       
   Install FPS for MS networks, install Remote Registry service, and
   enable User level security. Remote Admin privileges are
   automatically given to anyone in the Domain Admins group on the domain
   controller. Re-boot. Then, go to another Win95 station, log in as
   Administrator (or anyone else in Domain Admins) and get properties on
   the remote station from Network Neighborhood.
   
   WARNING: This service will allow you to remotely edit an NT Server's
   Registry! I was able to get in to several (but not all) Registry keys
   on my own NT server by logging in as a member of Domain Admins. I'd
   hate to think what could happen to my poor server if someone ran
   REGEDIT on this network with malicious intent!
   
   WARNING: Remember the NetWare C$ bug? It's back, this time in FPS for
   Microsoft networks! Now if you perform a Remote Admin session on a
   Win95 station and view its hard drives, the Admin shares
   (\\machine\c$) remain active, available for read-only viewing when a
   user types \\machine\c$ from Start Menu/Run. This bug may have always
   been around, but I suspect it emerged with Service Pack 1.

     * 7.6.3.2. ...on a Peer Win95 network? 
       
   You don't need to install Remote Registry service on the workstations
   to use peer to peer remote administration. You only need a file and
   print sharing service. When you use the Admin tools, the target
   computer will prompt you for a password.
   
   Be sure to set this password on all the workstations you want to
   administer remotely.
   
   NOTE: According to the Remote Registry readme files, Remote Registry
   service only works if you use User Level Security from a central
   server. 

     * 7.6.4. ...user level access? 
       
   User Level access spares us the potential of lost passwords and
   multiple, security-killing, cached passwords, because the passwords
   remain on the central security provider. You need only log in once and
   type your password once, and you have access to any resources shared
   on the network that have you on their access list.
   
   Enable User Level security from Network Control Panel, in Access
   Control. Pick a security provider (the name of an NT domain, NetWare
   server, or other central server if your client/service software allows
   for it). The next time you re-boot, all your share requesters and
   password requesters will have user list requesters in their place. You
   could also enforce user level security via system policies.
   
   If the server is a NetWare 4.x server, you will need to set a Bindery
   context on it. This will allow all NDS clients access to any Win95
   stations sharing resources via FPS for NetWare.
   
   Unusual combinations to avoid:
     * FPS for MS networks, using a NetWare server as security provider
       (WFWG stations can't get access then! Win95 machines could get
       access, however)
     * FPS for NetWare, using an NT server as a security provider (Quite
       impossible, as the NCP server doesn't recognize NT security)
     * FPS for NetWare, using Share level security (It won't let you; NCP
       servers don't allow separate logins)
         * 7.6.5. ...server-based setup and MSBATCH.INF? 
       
   I'm going to probably create a new FAQ page dedicated to this in the
   new year. But in the meantime, here's some basic stuff to get your
   server based setup running.
   
   First, why do a server based installation of Win95 in the first place?
     * Automated installation of several workstations
     * Can apply software updates or widgets for everyone
     * Can apply special changes to the systems, hacks or otherwise, in
       all new machines quickly
     * Save disk space on workstations by running pieces of Win95 off the
       server
       
   Oops... that last one isn't such a good idea, because it requires
   real-mode (DOS) networking to start first, eating up conventional
   memory. I'd say, make a normal installation of Win95, then use shared
   copies of your apps to save disk space instead.
   
   I cover basics in page 2, but in addition to this, get the Win95
   SP1 Diskette Set and use the updated INFINST, INFGEN, and BATCH
   tools instead of the ones that come with the CD-ROM.