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.
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.
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:
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:
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
Summation of Computer setup and some advantages:
The automatic installation procedure consists of several parts:
All of the above is implemented either using DOS batch scripts or, if necessary, small Pascal programs with source code included.
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
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:
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.
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:
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.
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.