From: medici@dorm.rutgers.edu (Mark Medici)
Newsgroups: bit.listserv.novell
Subject: Re: Updating Network Drivers
Date: 14 Aug 92 17:10:30 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I maintain the network connections for about 400 MS-DOS workstations
pretty much all by myself.  In order to do this, I require that all
machines conform to a particular network configuration.  This does not
mean that all workstations must run the same version of the NetWare
utilities, but that an upgrade can be automatically performed if a
problem requires the latest files.  Only public-access machines are
required to use the latest supported version of the network software,
private machines have some flexibility.

The standards are as follows:

  -  Each machine must have a C:\DOS, C:\NET, C:\WIN and C:\TEMP
     directory.  The network files AND anti-virus files are kept in
     C:\NET.
  -  C:\NET\LOADNET.BAT scans the machine for viruses then sets some
     machine-specific environment variables, loads the network drivers
     and then loads the TSR anti-virus software.  LOADNET.BAT is in a
     standardized format so it can be modified via SED or PEARL.  The
     LOADNET.BAT on all public machines cannot be modified.  However,
     private machine users may modify LOADNET.BAT at their own peril,
     with the understanding that any substantial changes may result
     in disaster during automatic updates.  One notable environment
     variable set by LOADNET.BAT is %VERSION%=n.nn, which is used to
     determine the local revision level of the network configuration.
  -  C:\NET\NET.CFG is generally consistant accross all machines.
     However, we do set the LONG MACHINE TYPE to the system's IP host
     name (truncated to 8 characters, if needed).  This makes our
     identification of the workstations easier.  We do not generally
     allow users to modify NET.CFG.
  -  Aside from the above requirements, the only other thing we
     require is that C:\AUTOEXEC.BAT contains as the first commands:

        @echo off
        set PROMPT=userprompt
        set PATH=userpath
        call c:\net\LOADNET.BAT
        rem  Rest of AUTOEXEC.BAT follows...

How do we maintain all this?

Maintenance of public workstations is different than private
workstations.  Each server provides access to public machines tests
the network address to determine whether the machine logging-in is in
on a public or private network, and then acts accordingly.

For public machines, the C:\CONFIG.SYS, C:\AUTOEXEC.BAT,
C:\NET\LOADNET.BAT and C:\NET\NET.CFG are tested against valid
versions maintained in protected areas of the server.  We presently
compare the file write times and dates of the server-based versions
with those on the workstation, though we have plans to use a more
reliable CRC comparison method in the future.  If a difference is
noted, the copies on the workstation are deleted, known good files are
copied from the server to the workstation, the workstation files are
then flagged +RH and the machine is logged-out and rebooted.  When a
change to CONFIG.SYS, AUTOEXEC.BAT, LOADNET.BAT or NET.CFG itself is
required, we generate these copies and put them on the server where
they will be compared to the workstation-based copies the next time
the machine logs-in, which should trigger an update of the
workstation.  We also enable commands in the system login script to
use WSUPDATE as needed to update the binary files in C:\NET.

For private, office-based machines, we enable lines in the system
LOGIN script that informs the user when updates to the binaray files
in C:\NET are available, and then asks the user if s/he wants to have
the updates automatically installed via WSUPDATE.  If changes to
NET.CFG or LOADNET.BAT are needed, I develop SED scripts to merge them
into the user's existing LOADNET.BAT and/or NET.CFG.  Since different
users may use different memory managers, I have to pay special
attention to how I have SED implement the changes.

The biggest pain was going around and setting-up all machines in a
standard way.  Each site had its own standardized configuration that
was different than others.  It took us about 6 months to finish the
standardization process.  Now updates can be done by making the
changes on the server and enabling the appropriate sections in the
system login scripts.
-- 
_________________________________________________________________________
RUCS     | Mark A. Medici, Systems Programmer III, User Services Division
User     | Rutgers University Computing Services, New Brunswick, NJ 08903
Services | [medici@gandalf.rutgers.edu]                    [908-932-2412]