From: MICHAEL@BMGTMAIL.UMD.EDU
Newsgroups: bit.listserv.novell
Subject: re: Windows local permanent swapfile (or temporary?)
Date: 14 Aug 92 16:54:59 GMT
Reply-To: Novell LAN Interest Group <NOVELL@SUVM.BITNET>
Organization: College of Business, U of Maryland
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Pmrqc:      1
X-Mailer:     Pegasus Mail v2.3 (R2).
X-To:         NOVELL@suvm.acs.syr.EDU, jbeck@bmgtmail.umd.edu,
              ccx020@cck.coventry.ac.uk

It is my understanding that a swapfile should be created locally
to save the server.  If you have a number of users trying to work a
networked version the harddisk will crawl to a halt without a
swapfile.

Temporary swapfiles are o.k. but startup is a lot slower since the
machine needs to assess the space available and then set the specs
for usage.  Permanent swapfiles would definetly be more realistic as
a result.  The setup /n feature (after installing to the server using
setup /a) used with the server copy of windows will copy only those
files needed for personal customization of the local machine.  This
only eats up approximately 300k.

As for your old local copies of windows with swapfiles, reinstall
Windows (using /n or not).  You should be prompted, stating that an
old swap exists and you will have the chance to delete it and create
a new one.  I see no reason to bother with "spart.par".

Ideally, if you have the space on the harddisks, your best bet is to
install windows locally with a permantent swapfile and use a shared
network group.  This minimizes the use of the server and gives
maximum performance to the user.

If the drive behind all of this is for the supervisor to keep
control of the windows system, doing the following will disable
the ability for modifications by the local user:
in Progman.ini, place the following

[restriction]
norun=n    1 disables the run feature under File menu
noclose=n  1 disables the ability to exit windows with File|Close or
                  Alt-F4
nosavesettings=n  1 disables the ability to change the settings of
                       the desktop
nofilemenu=n    1 removes the File menu from windows completely, but
                this alone will still allow users to use Alt-F4 to
                close windows
editlevel=n     0, users can make any changes
                1, users can not create, delete or rename groups
                2, users can not create, delete or rename items on top
                      of the group restrictions
                3, users can not change command lines of items on top
                      of the restrictions of level 2
                4, users can not change anything concerning items on
                      top of the level 3 restrictions

The last note is that the .ini files for each user will need to be
updated when new software is installed.  This is a problem when you
use either server home directories or local windows directories.  My
solution is to set every restriction to its highest level.  Do all
software installation yourself.  The updated "master" win.ini and
program specific .ini can then be loaded on the server to be copied
to everyone's machines or home directories after any update.  Since
the size of the win.ini never gets too big (no matter how many
different packages you organization may have) everyone will have the
right configurations, and you can selectively modify users' groups to
add the icons if the user it to get access to the software.

I hope this all makes sense.  Good luck!


Michael@bmgtmail.umd.edu  :)
College of Business and Management
University of Maryland, College Park