As the Year 2000 approaches and the onrush of technology overwhelm staff students, and faculty, universities must remain flexible in how computer labs are managed. In order to keep students on track, computers in lab environment must remain in the same operating condition day after day. As the technology grows so does the ability to lock out more and more features on personal computers, seeming to make administration easier. However for students to be successful in learning new and better operating systems they must be allowed to change system settings, install software, and generally make a mess of a computer system. The necessity now is to have a system that can restore itself or be restored easily to its original state. Remote distribution systems maintain images on the local network that are accessed by the lab computers. The remote system "cleans" the local system, including registry settings, extra files, unwanted programs and the like. This paper discusses when why and how this should be done.

When Is Remote Distribution Needed

Remote distribution is a necessity in an environment containing 2 or more sets of computers with separate hardware and software needs.

Why Remote Disribution?

UNM-Valencia first began Remote Distribution before the network was installed. According to UNM-Valencia's LAN manager remote distribution began by linking two personal computers together with a direct parallel connection and copying the necessary files straight from hard drive to hard drive. From there remote distribution progressed along with the network. As new network components were installed, and new operating systems were being developed, new methods of dealing with the problems of multiple computers in a lab environment were also being developed, starting with standardization of hardware.

New, better, stronger, faster. These were the buzzwords heard throughout computer labs in New Mexico. At UNM-Valencia a decision was made to purchase enough computers to fill one lab at a time, from a single vendor. The new systems had to meet ever-changing hardware requirements, as well as warrantee requirements. A minimum three-year warrantee on all system components was instituted. Bids were requested from different vendors and a choice was made, based on price, availability, warrantee, and service. The first of many sets of computers was purchased in 1995.

Now that the computers in a lab were identical, it became possible to install all of the software and drivers necessary for that lab, based on what was being taught in the lab, onto one system and then distribute, via the network, to the rest of the machines. A series of MSDOS batch files were used to update the files on the systems in a particular lab based on an identifier that was stored on the hard drive. This ID made the computer a member of a group of computers and downloaded the appropriate files and fixes. The hard drives ranged in size from 20MB to 540 MB. MSDOS could and did handle these size drives very nicely. The files for that made up a drive image were not permanently stored on the server, rather files were copied up to the server for the duration necessary to insure that they had been copied down to the local machines. The files were then removed from the server. Remote distribution allows the student in a lab environment the flexibility to learn what a computer can and cannot do what can and cannot be done to them, and what can happen when mistakes are made. The student may experiment without being afraid.

Windows 95

With the release of Windows 95 new ways had to be found to deal with distribution of Operating System files and software. The Operating System had taken control of the PC's and administration had become a nightmare. Microsoft boasted of remote administration, however their remote administration tools never quite filled the needs of lab technicians. Art first Windows 95 did not seem like a good idea for a lab learning environment. The systems could be locked down, allowing the students only the bare minimum of access to the Operating System, but in a computer teaching lab environment this was neither helpful nor useful. The students needed to be able to "play" with a system. They need to be allowed to see how the system reacts to changes. They need to make mistakes, the kind of mistakes that horrify administrators.

About the same time hard drives in the 1GB range were being shipped with our new systems. As the size of the drives grew, so did the size of the software packages that were being requested in the labs.

The search began for a possible third party utility that would allow a system to be rebuilt in much the same fashion as was done with MSDOS. Utilities such as, Ghost, Drive Image, and other imaging software packages showed promise, but did not allow for on the fly system restoration. UNM-Valencia's LAN Administrator heard mention of a shareware package called PCRdist (PC Remote Distribution) through one of the many listserves that he is a member of. This shareware was an adaptation of the Apple utility REVDIST.

PCRdist was tested on a limited number of workstations in a lab and the decision was made to purchase and implement the software. The software is capable of copying large amounts of data over the LAN in a short amount of time. The files that constitute an image are stored on the local server where they are secure. When PCRdist runs, the files on the images are compared to the files on the machines in the labs and the labs are changed to match the images. A time stamp file is established on the local drive so that unneeded files can be marked and stored for a predetermined period before deletion. The same time stamp is used as a marker to tell PCRdist when to run. A distribution system that runs every time a machine is rebooted is a nuisance.

Implementation

Initial testing and implementation took about three months. At the end of this period PCRdist was installed and running in a bare bones fashion. The first, and most formidable, obstacle in using PCRdist was the Windows 95 system registry.

In early testing for full implementation Windows 95 installations were sacrificed on a regular basis. The problem was passing the Plug and Play (PNP) information stored in the registry to each machine in the lab. The registry key that stores this information on each computer has to be left alone. The decision was made to automate, as much as possible, a Windows 95 setup on each system, and then ignore the portion of the registry responsible for the PNP settings. PCRdist is equipped with a registry utility for ignoring, changing, or replacing registry settings.

Initially a global registry for each set of systems was stored on a server, along with a distribution configuration file for each set of computers. The local or individual registry settings were stored on the individual machines. The independent registry files were called by the registry utility inside PCRdist and used to restore the system registry each time PCRdist was run. This worked but was very inefficient. There were too many files to maintain to keep each lab going. Anytime that a printer setting needed to be changed a lab technician had to visit each machine, make the change, and update the local registry. UNM-Valencia's labs have a minimum of twenty computers each, making this a time consuming process.

With time discoveries were made about more and more of the internal utilities available in PCRdist. Most of the utilities were known about but not used. With the semester beginning time was the enemy and PCRdist was implemented without most of its tools enabled. The following is a list of the tools currently being used and a brief explanation of each.
; Sample distribution file for PC-Rdist 1.57d for Windows 95
; Chris Volkert 9/15/97
;-----------------------------Config Variables----------------------------- ;
; First, we define some configuration variables. All of these  variables are optional and can be removed if you don't need the; ; functionality they provide.
; Interval tells PC-Rdist how often to update the computer. If ; less than interval hours have elapsed since the last run, PC-Rdist ; will exit without performing any updates. Removing this line will cause ; PC-Rdist to update the computer every time it runs. interval=7 hours

; The file to use as a timestamp. PC-Rdist uses this file to determine ; the last time it updated the computer. timestamp=c:\pcrdist.tsp

;Connect to a time server to set the system time. ;timeserver=ntp0.strath.ac.uk
; Tempdir specifies the directory where "junked" files will ; be stored.
tempdir=c:\temp

; Expire specifies how long you want to keep junked files ; until they are deleted. Remove this line to keep junked ; files around ; indefinitely.
expire=5 days

; Freespace tells PC-Rdist how much room you want to keep free on  the drive. If the available space on the drive falls below ; the  amount defined by freespace (in this case, 30 megabytes), junked  files will be automatically deleted.
freespace=30 meg

; Maxtemp specifies the maximum allowable size for the temp directory.  If it is larger than maxtemp, junked files will be ; deleted.
maxtemp=10 meg

; Maxtempfile is the largest allowable size for a single file in the  temp directory. Files marked with the J flag will be deleted if ; they are larger than this size.
maxtempfile=1 meg

;The file used to store logging info
logfile=c:\pcrdist.log

;What do you want logged? log=errors logs error messages, log=all logs everything. Set log=none to disable logging. log=all ;maximum size for the logfile. If the logfile grows larger than this, ;it will be truncated before the next run. Setting it to zero ; causes only the most recent run to be stored in the logfile.
logmax=0

;Kill all running programs before updating the drive
;kill=*

;Uncomment this line to have PC-Rdist automatically reboot when it tries ;to replace a file that is in use. ;implicitw=yes ;implicitb=yes
;-----------------------Mail Features------------------------------ ;
define these variables if you want PC-Rdist to mail you when  an error occurs. ;
;The address you want to receive the mail
;mailto=admin@yoursite.com ;
;The SMTP server to use to send the mail
;mailserver=mail.yoursite.com ; ;The exit codes for which you would like notification. ;mailon=EXIT_FATAL,EXIT_NONFATAL ;
;Set this variable to YES to include the logfile in the mail message.
;maillog=yes ;------------------------------------------------------------------
;Uncomment this line and specify the network path to the master
;image.
;#define master \\server\volume
;Make sure that the master image exists
#if !exists %master%
#echo Can't find %master%. Exiting.
#exit %EXIT_FATAL% #endif ;
Mount the master image as Z:
+mount %master% Z:
;----------------------Registry Update-----------------------------
;Uncomment these lines if you want to use the registry updating feature. The master image is specified using one or more .reg ;files generated by the Win95 Registry Editor (regedit.exe).
;The path to the master regfiles (so that you don't have to specify ;a full path for each of them).
;REGPATH=Z:\pcrdist\regfiles ;
;This assumes that you have two registry files, global.reg and ;local.reg. Global.reg stores the registry information shared by all ;the computers, while local.reg has machine specific keys (computer ;name, IP address, etc). ;
;> registry global.reg local.reg : m s c d ;

; Ignore HKEY_LOCAL_MACHINE\Enum, which stores plug and play info ; > HKEY_LOCAL_MACHINE\Enum : i ; < ; ;< ; ;------------------------------------------------------------------
;--------------------C: Drive Update-------------------------------
;This is the main distblock which updates the C: drive. This will update the C: drive, using Z:\PCRdist\master as the master ; ; image. It will replace files that are missing or modified, reset file attributes that have changed, and junk any extra files.
> c:\ Z:\PCRdist\master : m s t a j
; delete any extra programs users have put on the machine
| *.exe : d r
| *.com : d r

; If Netscape is installed on the machine, delete everything in the cache.  Otherwise it would flood the temp directory.
> "Program Files\Netscape\Navigator\Cache" : d <
> windows

; Ignore the registry files if you plan on using PC-Rdist to update  the registry.
| user.dat : i
| system.dat : i

; Ignore the Windows swap file.
| win386.swp : i <

; Ignore the PC-Rdist timestamp and log files.
| pcrdist.tsp : i
| pcrdist.log : i <
; Unmount the Z: drive now that we are finished with it
unmount Z:
; restart explorer after the run, if you killed it with kill=*
;+exec explorer.exe &[1].
A utility called GETHA (GET HARDWARE ADDRESS) was setup to assign variables in a pipe delimited text database. The identifier in the database is the hardware addresses assigned to the Network Interface Card (NIC). The NIC's Hardware address uniquely identifies a machine to PCRdist, registry settings like network usernames, IP addresses, image and file locations, as well as other independent system settings are being administered from a single database file located on the network.

Using this utility allows a single system registry file to be used for a set of computers in a lab, and a single distribution file to manage all of the labs. The possibility remains to use remote distribution in a lab of dissimilar machine, however the process becomes much more difficult. Adhering to the decision to purchase only full sets of computers for a single lab ensures the integrity of the distribution system. A high level of control of the hardware and software that go into a lab keeps the number of files needed for the distribution system to operate to a minimum.

All in all implementation has taken about a year to get to this point.

A Word of Caution

Networks that have limited internal bandwidth will experience problems running this software. On boot up, all of the workstations start the software and download the new files, delete the unneeded files a change the system registry. For UNM-Valencia this about 190 computers all trying run the software at the same time. This was a real problem before we installed the new switches. With the switches installed and operating the software runs without a hitch.
 
 

What Next?

Remote distribution is making labs proactive. Reactive labs require a great deal of maintenance. Proactive labs require very little maintenance. Most lab problems can be solved with remote distribution. Changes in software, new printers, trashed systems are all handled in a short period of time. A Pentium II system that has had the Operating System wiped out is restored in about 45 minutes. 30 minutes of this is spent waiting for the Operating System to install. Another 15 minutes for PCRdist to run and a system is completely restored to working order.

Proactive labs also mean more time to research new hardware, test new software, and train workstudies, all of the things that have been pushed aside so that the labs could be fixed.

New areas for computer labs are opening up every day. The latest addition to our lab environment is our library. Libraries have always been places to study and research. More and more research is being accomplished online making it necessary for libraries to embrace technology. In the past managing the computers in the library has been difficult. The machines were not standardized hardware or software. Recently standardization was accomplished when one of our teaching labs was upgraded and the older machines were moved to the library. The machines from the lab were purchased as a set and the decision was made to use the distribution system to take care of them. Since the new machines were installed a dramatic decrease in trouble calls to the library has been noted.

The next change in the remote distribution system will be to service all of the teaching labs with a single software image. Using logical structure inside the distribution file it is possible to call or ignore specific portions of the image. Currently the images on the server take up about 7GB of storage. Using a single image would reduce this to around 1GB.

References

[1] Chris Volkert, http://www.pyzzo.com, September 15 1997