White Paper - Computer Classes Installation

Situation:

We have several student computer labs on the campus. The aim is to create a similar working environment for the students in all these labs, while keeping each lab unique in the software packages it offers. At the same time we want to manage all our PCs centrally from the network and control as much as possible from the network. In all classes exist groups of identical PCs (in terms of hardware) and each class is connected to a local file server. Currently all classes have their own, separate installation with local users, but do not make use of ZEN. The computers have to be protected against harm from students and against abuse and software installation.

Final Solution:

All classes present an identical working environment to the student (who have an account on a central student file server). In each class the existing local users continue to work with their previous accounts and environment they got used to. At the same time the students can log on in all the classes and use their own home dir and applications. All classes have a certain amount of "standard applications" (like Office and tools), while each class supplies in addition programs local to it (mostly specialized applications like MatLAB, Geology programs etc).

The computers in the classes have an automatic installation system that allows the local admin to easily re-install a broken computer. Also many routine tasks are done automatically and centralized (like NAV update). Printer settings, applications and many aspects of the Workstation setup can be changed from the network. Also the computers protection can be set from the network, administrators have only light protection while students enjoy more severe limitations of their activities.

Application icons are managed in the network and user see different icons depending where they log on.

All computers have a unique ID and are registered on the network to allow direct manipulation of a specific computer via the network. This includes Remote Control to help students from a helpdesk team.

Detailed Solution:

1. Programs & Tools used:

  • Novell ZENWorks
  • Fortres 4
  • Symantec Ghost
  • UpdateWS & AutoGhost2 (a set of applications to automatically install computers from the network, developed in-house)

    2. Computer setup:

    We work with ghost images to install the computers. Therefore we first create a standard image for each group of identical PC hardware. This installation contains Windows 98, MS Office, IE5, NS4.08 and many tools (GS, WinZIP, Acrobat, TclTK, NAV etc.). These images are installed in each class and then customized to the local classes demands (usually installation of further software packages).

    The next step is to connect the computers to the network, both physically and logically. For each computer we create a ZENWorks workstation object. The naming convention we use is "Computer Name"+"MAC-Address", where the Computer-Name is related to the name of the class the computer is in. Like this we have a naming scheme which on one hand gives most information (what computer in what class) while at the same time containing only information which the computer itself has (This is important for automatic registration of the computer after installation). The computers WS objects are created in a new sub-container for each class to have easy access to a computer in a specific class and to allow for easy grouping of computers. In most cases we create the new containers under the existing containers for each class (that contain users etc. from the previous setup). To make computer installation easier we create the appropriate WS objects before installing the computers so that when the computers install and boot, they can connect to an existing WS object (See later for the exact details).

    Next we create Workstation groups for each class and Workstation Policy packages. In the Policy package we define the following parameters:

  • Printing
  • Login Restrictions
  • Start the NAL program on user login
  • (In some classes shutdown at class closing time)

    We also create an application (Called WS-Init) that is force run by the workstation at the login screen. This application runs all necessary programs that we want to have run at boot as well as sets the computers USER policy to very strict restrictions (We do this instead of using a User Policy Package for our students). This setup allows us to have both the computer aspects and the user aspects of Policy settings connected to the workstation, what is what we want (since we want to protect the workstation, not prevent the user from using Windows on a non-class computer).

    The computer's limitations are set as follows:

  • no write access on C: (Except by some specifically allowed alps) (by Fortres)
  • disable most of Windows' user interface (Control Panel & CPLs, IE features, Desktop things, Drive C: in explorer etc. (WS-Init by Policies).

    We also create a User Policy Package for admins that undoes most of WS-Init's limitations so that admins get a fairly "open" PC (except of course Fortres limitations).

    Now we create application objects for all the programs installed. We associate these applications with the workstation group of each class (we create identical app objects in each class container, though in principle it is possible to use a centralized application container and keep there all the applications which are common to all classes. This, however, puts high demands on the network infrastructure and increases NDS traffic noticeably). Some applications we associate with the user (both students and previous user in each class via their respective containers) so that they will have them everywhere. The user-associated apps are programs that depend on the user and not the computer, like "Home Directory", "Logout", "Change Password" (for the legacy users. Students use an external system for password changes), and "Account Information" to display some info and statistics. All applications that we create do their own setup (if necessary), like mapping of search drives, creation of temporary files etc..

    The login script of each container involved (both the student container and the class containers) is stripped to a bare minimum of

  • setting ENV variables about almost everything
  • map search drives to sys:public and a dir with our utils
  • if exists, map drive to user's home directory

    Summation of Computer setup and some advantages:

  • All computer related settings are connected to the computer and not to users (via workstation objects), this includes running NAL and other programs and protecting the computer.
  • All application specific settings are in the respective application object
  • Full control of computers in the network, from assigning apps or scheduled items to remote control.
  • Flexible computer protection: Strong for users and weak for admins.

    3. Automatic installation

    The automatic installation procedure consists of several parts:

  • A version control system that assigns each computer and installation a unique computer group and version. Each computer checks its version against the "should be" version kept on the network and installs itself if necessary
  • A unique and "native" naming scheme for the computers' workstation objects in NDS (Name+MAC Address). After installation the computer patches itself on first boot to point to the correct workstation object (easy because we use MAC address and not some arbitrary or changing data to build the name).
  • Simple to use bootdisks for image creation and workstation installation to help local admins re-install broken PCs and admins create new images.

    All of the above is implemented either using DOS batch scripts or, if necessary, small Pascal programs with source code included.

    Detailed Description:

    We give each group of identical PCs a group name, e.g. A. In this group we keep a version number, e.g. 4. This information is stored locally on each PC in the CONFIG.SYS file (in two ENV vars, WSGROUP & VERSION). On the network it sits in SYS:LOGIN\WSGROUP\%WSGROUP%\updatews.dat of the local classroom file servers. A small program (UpdateWS) run on boot before login (from either RunServices in the registry, a force-run application or the Workstation Policy Package) compares the two versions and if they do not agree replaces config.sys and autoexec.bat on the computer with a set that boots to the network in DOS and restarts the computer. The computer then boots into the network and uses the AutoGhost2 system to install the correct image for this workstation (see below).

    The AutoGhost2 system is a set of DOS batches that

  • recognizes the correct workstation group by IPX network number and other means of identifying the computer (strings in BIOS, nic drivers loaded etc)
  • maps drives to the correct locations of the updatews.dat version file on the network and the location of the actual ghost images
  • dumps the correct ghost image and reboots the computer or shuts it down (depending on the computers hardware)

    The advantage of the AutoGhost2 system is that all the intelligence to decide what to install is on the network thus enabling us to use generic bootdisks for all computers that do not ask any questions as to what to install etc (unattended install). Also it allows us to boot into the network in several unattended ways and make use of the SAME system there:

  • UpdateWS initiated updating/installation
  • Remote boot PROMS with Wake On LAN
  • local admin uses bootdisk to install computer.

    A run-once style set of DOS batches is run on a workstation on the first boot after ghost image dump (calls PatchWS). This loads the nic drivers, extracts from the output the MAC address, unloads the nic drivers and patches the ZENWorks workstation association object in the registry according to the correct workstation name. Thus already on the first boot the Workstation is completely set up and ready to be used.

    Especially together with Wake On Lan it is very easy to automatically reinstall complete computer classes at night, since the whole process is automatic and asynchronous, meaning that one computer is completely independent from the other computers (as opposed to multicast installations where the operators have to make sure that all computers are ready before beginning the image dump). With modern network infrastructures and compression also large classes can easily be installed during one or two hours, even without multicast or similar techniques.

    4. Network based management & Conclusions

    After thus installing the computer labs and creating a good basis for re-installing the system with the least effort we try to manage and install the computers only from the network. This includes:

  • Applying regular updates & changes through NAL application installations
  • Running oftenly changing things from the network
  • Easily changing computer setup and level of Windows protection from the network, as well as other settings like printer setup etc.
  • Installing temporary applications through NAL in %TEMP% or run them from the network.
  • Using applications exclusively for almost everything that we want to do to the computers.
  • Associating applications with sub-groups of workstations to give some temporary application to some course in only part of the class.
  • Shutting down computers, sending messages to users etc. via application objects or scheduled items that execute within the next 5 minutes (or whatever we set as refresh time).
  • Enabling the helpdesk to view a user's desktop to help solve problems where they occur.

    Since we use Fortres to protect our computers and not some hardware based solution that undoes all changes on reboot we can use all of the above features since they rely on saving information to the disk permanently (like NAL GUID stamps of application versions, post-image-installation etc.). For computers where Fortres is too limiting it is possible to simply re-install the computers each night and use only light or none Windows policy restrictions.

    An added advantage of using application objects and of moving most of the setup to the network is easy backup through our central backup system and documentation through the details in the application itself.

    Conclusion:

    With the above strategy of computer installation we on one hand achieve a very well installed and manageable system using mostly standard tools (where they exist) while keeping all possibilities for future changes and improvements even from the network while on the other hand we distribute the load over the network (by using sub-containers) and including previous installations and user setups in each location. The high amount of items that are manageable through the network helps us admins to administrate our network more efficient since many problems we can now solve from remote and through the network.


    Schlomo Schapiro
    Computation Authority
    Hebrew University of Jerusalem

    Tel: ++972 / 2 / 65-85812
    email: huji at schlomo dot schapiro dot org
    Copyright & Disclaimer , 1999, The Hebrew University of Jerusalem. All Rights Reserved.