Source: http://serveratschool.net/doc/manual/software.html
Timestamp: 2019-04-20 08:27:05+00:00

Document:
This chapter describes, in general terms, the installation of educational software on a workstation in a ServerAtSchool environment. We cannot describe installing your applications; we do not know them. Besides that, applications differ in installation methods and configuration options; even between versions of the same software.
What we describe are our experiences in installing numerous educational applications that are used in primary schools in The Netherlands. We have condensed our experience into a handful of different cases, in section 3. Example installations. These examples are based on real educational applications, allthough we have changed the actual titles, to protect the innocent.
Before you can successfully install educational software on the workstation the following assumptions should hold true.
You have worked your way through chapters IV. Workstation setup and VI. DAEMON Tools virtual CD player.
You have read chapter V. Managing disk images with ghost for unix and therefore know how to create disk images and also how to restore a workstation.
The server is up and running, the workstation you are using is connected to the server and you have a working connection to the internet.
You are able to use the special 'scholar' account (see section 2.4 The special 'scholar' account in chapter IV. Workstation setup).
You also can use your own account and a 'generic' account such as 'grade8', for testing purposes.
You are aware of the conventions in a mixed Linux, DOS and Windows environment as discussed in section 1.2 Conventions in chapter IV. Workstation setup).
Nowadays most software is distributed via CD-ROM. Even though it would be possible to install software using CD-ROM images via the server, it may be more practical to work on a workstation that has a physical CD-ROM player, even though it is not necessary.
Furthermore it would be very efficient to have more than just your 'golden image' machine-to-be at your disposal. A second workststation can be used to get to know new educational applications (by 'trial and error') without messing up your 'golden image'. If at all possible a third machine could be handy to keep your notes.
Of course you should have access to all the necessary software and relevant documentation. Please do remember that some software requires an activation key or a license code.
When installing educational software, you have to collect data and have to make choices on how to do install it, depending on the kind of software, hardware, network and your schools needs. Below you find some general remarks to explore this mine field.
Please bear in mind that we have chosen the bad examples on purpose. There are many excellent educational software packages, however, we did not want to bore you with trivial examples that boil down to [Next], [Next], [Finish].
Generally speaking, there is software designed to run on servers and software for standalone computers. When inspecting a software package, that is something you need to find out. However, that is not always easy because of the following reasons.
Badly designed or programmed software.
It used to be standalone software which was (not well) modified to be published again as server software.
Sometimes it looks like server-based software, but some functions appear to be designed for standalone use.
Sometimes you may discover, to your surprise it is not even one of the above mentioned types, but software that must be installed on the webserver and runs with a webbrowser.
The general advice is: get as much documentation about the software as you can. Ask other users about their experiences. Read the FAQ-lists on the software manufacterers website.
Educational software often has lots of images and sounds, especially when it is targeted at the lower grades. Running these programs from the server, and specially when a complete class in the computerlab is using the same application, and when having a 10 Mb/s network with hubs, congestion might occur, causing slow performance. This may result in impatient pupils double or triple clicking in an attempt to speedup the program, thus causing the program to crash or not behave according to what the teacher was trained for.
You might have to find out if these images and sounds laden applications can be run from the server. Or that it is wiser, if the program permits this, to install the sounds and images on the workstation and the program itself, including the database if any, on the server. That might speed up the program while at the same time building a central database with pupils progress.
Very old software is often used for good educational reasons. This software can sometimes no longer live up to today's screen resolutions; the modern hardware is simply too good. This often happens with high-resolution graphics screens. If the application insists on a full screen 640x480, you can hardly work with the application if the screen usually runs at 1024x768.
NOTICE: This particular problem has a work-around in the form of the QRes helper program. See section 11.1.2 QRes in chapter IV. Workstation setup for more information.
Many educational applications use a database or a shared directory to store pupils' progress and other data. It is clear that this data should be stored on the server so that pupils can login from any workstation to work with that application and still continue with their existing data. That is what networking computers is all about.
You have to find out if the application you plan to install uses a database and if it is possible to install the program and the database in different directories.
You probably have CD-ROMs which can have differing installation requirements. Some applications need the CD-ROM to be available in a CD-ROM drive after installation. Others only need the CD-ROM once, during installation. Sometimes you have the option to choose.
Read the documentation and hope for an extensive explanation. (Do not be too disappointed if this does not work). If documentation is lacking and the website of the manufacturer gives no clues either, one solution remains: try-out installations. Maybe the behaviour of the program during its installation tells you something.
There might be strategic decisions on where to install softawre. Suppose the server crashes. Is there any piece of software you want to keep on going even when the server is down? This question might be rethoric, because most applications need the server. However, this is the moment to raise the question.
We do not have the answers to all these considerations. They depend on your school's hardware, software, ICT and educational policies. However, we hope to made clear that installing educational software can cause deep frowns in the foreheads of the local systems administrator and the ICT coordinator.
The ServerAtSchool environment has various places where programs can be run from and data can be stored. Some of these network shares have a very specific purpose. A list of available local drives and network file shares can be found in the table below. This list shows the intended use of the various resources and also some guidance on where to install educational software.
A file share is "A network resource exported by a server. It usually corresponds directly to a directory on the server which has been exported for network access." (adapted from http://www.obdev.at/resources/sharity/manual/A02-appGlossary.html).
The table shows the UNC name of the file shares. UNC stands for Uniform Naming Convention. The format of a UNC name is two backslashes followed by the (netbios) name of the server, followed by a single backslash, followed by the name of the share. Many software packages accept UNC names. However, older software sometimes chokes on those names and really needs a drive letter to access files on the server.
C: (local drive) Drive C: refers to the (first partition of the first) disk in the computer. This is the place where the workstations Operating System is stored. Also, necessary drivers and other software could be installed there.
H: \\SERVER\userid Drive H: equates to the user's home directory on the server. userid is replaced with the name of the user that is currently logged in, e.g. \\SERVER\ffrint or \\SERVER\grade8. This drive contains all the user's documents and other data files. Details will be discussed in chapter XI. My Documents and My Backups. The H: drive also holds a the personal settings of a user (the so-called 'profile').
K: (virtual drive) Drive K: refers to the (first) virtual CD-ROM player, see chapter VI. DAEMON Tools virtual CD player.
P: \\SERVER\PROGRAM1 This share is for programs, or to be more specific, that part of program known as the executable and its related files. Important to know is that this share can be considered read only. No data can be written on this share by ordinary users. Notable exceptions to this rule are members of the group 'janitors'. This share equates to the directory /home/share/program1 on the server.
Q: \\SERVER\PROGRAM2 This share is for databases. The share is both readable and writable by ordinary users. When it is possible to install the database of a program in its own share, separated from the program, the database should be stored on this share. (see notice below). This share equates to the directory /home/share/program2 on the server.
R: \\SERVER\CDROMS This share is the place where CD-ROM images are stored by the CD-ROM imaging tool (see 6. Managing CD-ROM images in III. Janitor). Just like the P: drive, this share is read only for ordinary users and read/write for members of the group 'janitors'. This share equates to the directory /home/share/iso on the server.
V: \\SERVER\TMP This share equates to the directory /tmp on the server. This share is available to all users to temporarily store data. It can be used to exchange files between one user and another. However, only the original owner can delete a file. Note that the server itself automatically removes files from this share if they are not accessed for some time (about 4 weeks). Therefore this share should not be used to archive files.
\\SERVER\INSTALL The install directory holds a directory with all sorts of 'goodies'. It is also a good place to store downloaded files such as drivers or other software. By default no drive letter is associated with this share, even though I: would be a very logical choice. Without the drive letter this share can be accessed via 'Network Neighbourhood'.
\\SERVER\NETLOGON This share equates to the directory /home/samba/netlogon on the server. This directory holds the DOS batch file LOGON.BAT. This file is executed whenever a user logs on.
The connections between file shares and drive letters are established during network logon (the small black window that flashes by). At that time the DOS batch file \\SERVER\NETLOGON\LOGON.BAT is executed.
NOTICE: Apart from the file shares discussed here, the server may also provide printer shares. These can be seen via 'Network Neighbourhood'. Discussion of printer shares is not the topic of this chapter. See section 10.1 Printers overview in chapter IV. Workstation setup for more information.
The Q: drive deserves some extra attention. This share poses a security risk because every ordinary user can write to it. That also implies that every ordinary user can delete files from the share, either by accident or on purpose. Unfortunately it is necessary to have such a writable share because some educational software packages need a place to store pupil results, highscores, etc. Because of the design of these programs, write privileges are required. This security risk can be somewhat reduced by making this share invisible. The procedure is described in section 2.2 Preparing policies in chapter VIII. Managing user profiles.
The V: drive is the least important share. Its purpose is to serve as a test bed for the local systems administrator, e.g. to 'try' a new software package before installing it for real onto the 'golden image'. It also could be used to exchange files between any two users be it that the original owner is the only person that is able to remove these files on the V: drive. Note that the system itself automatically removes files that have not been accessed in 4 weeks. Therefore V: is definitely not a good place for permanent storage. The size of the share is limited: by default only 512 MB is allocated to the partition that holds this share.
All workstatations in a ServerAtSchool environment should at least have a C: drive; the harddisk on which the OS is installed and maybe other software too. A workstation also should have either a floppy drive A: or a CD-ROM player, e.g. D:. This is necessary for use with g4u, see V. Managing disk images with ghost for unix. If the software for a virtual CD-ROM player is installed (see chapter VI. DAEMON Tools virtual CD player), the workstation will also have K: drive which can hold (virtual) CD-ROMs.
NOTICE: Depending on the number of disks in the computer and the way these are partitioned, the drive letters may differ. Also, if a computer has a second CD-ROM-device or a DVD-player or a CD/DVD burner, other drive letters may also be in use. Special care has to be taken with multi-purpose 8-in-1 card readers because these devices sometimes happen to 'capture' the all important drive letter H:.
It is difficult to give the ultimate answer or even specific guidelines for the best place to install educational software. In the ideal situation, with the ideal software, with the correct installation options, with the right hardware and network, this is our opinion.
Install programs that do not write data on the P: share.
Install programs that use a database on P: (the executable program and other static read-only files) and configure the application to store data on Q: (the database or datafiles and directories).
Install unconfigurable programs (i.e. the location of the database is determined by the location of the .EXE and you can not change that) on Q:.
Install tools like browsers, PDF reader, picture viewer, word processor, etc. on the client, i.e. on C:.
Install CD-ROMs that require the CD player on R: and access the program and/or necessary files via the virtual CD-ROM player in K:.
Install web software, depending on its usage, either on P: or somewhere under /home/httpd/htdocs; the webserver's document root directory.
Among Windows and network pundits, these choices can lead to heated discussions, only illustrating that many choices are possible. Maybe this is the moment to ask your local Linux or Windows group for advice. Do not be surprised when you meet contradictions. This is complicated matter.
The question remains: where to install? Most software is not all that well documented. This often makes it difficult to take a well-informed decision (or even an educated guess for that matter) on how to proceed.
In many cases there is only one installation method: trial and error. When you have to opt for this method, it is a must to write down the exact steps you took during an installation, even the steps that led into the wrong direction. Without good notes it is impossible to track the cause of a failing installation, to circumvent a 'known issue' the next time or to redo a successfull installation when necessary.
At the Exemplum Primary School we have developed a very strict method of installing educational software. It works as follows.
As a rule we use three workstations during software installation.
The first one is our 'golden image' to be. We use this machine for the 'real' installation of software. This is always done using the special 'scholar' account. This machine is not used for frivolous tasks such as surfing the web for information. While the work of creating a 'golden image' is in progress it is simply a matter of "don't touch the art".
The second one is an experimental machine. Here we can try new and unknown software without contaminating our 'golden image'. We never use this machine to login with that special account 'scholar'. Instead, we use the account of another member of the special 'janitors' group to install/test software. We also use this experimental machine to test experimental installations. This is done with the account of a user with minimal privileges, e.g. the account of 'grade8'. This makes sure that the test is realistic. It means we will not have issues with lack of writing privileges on say the P:-share because grade8 has no write privileges there.
The third one is a machine with which you can login using your own account, assuming that you are a member of the special 'janitors' group. We never use this machine to login with the special account 'scholar'. If you are logged in on this third machine as a member of the group 'janitors', you can add to your installation journal (in say H:\My Documents\janitors\install\software.txt).
Note that we only use the 'scholar' account on the 'golden image' machine in order to prevent contamination of the 'scholar' account via another machine.
It is very important to know exactly what you did when installing software. This is especially the case when you make a mistake and you have to redo part or all of an (experimental) installation. We use a file like H:\My Documents\janitors\install\software.txt to write down every little thing. It has saved us a few times already, especially when upgrading to a newer version of an existing software package. By saving the notes in this (shared) directory, all members of the 'janitors' are able to see what was done on a workstation during software installation. See below for more detailed information on this installation journal. See also section 2.5 Documenting your work below.
We often make milestone images in order not to lose a lot of work due to some rogue software package. When installing a new server and a bunch of educational software packages in one go, we make a milestone image at least twice a day and often more often.
Apart from writing down the (very detailed) steps during software installation it is a good idea to keep track of installed packages in a simple text file that is part of the g4u image. We use a file like C:\CONTENTS.TXT. Every time we successfully install a software package, we add a line to this file. Also, when we make a new g4u image, we write the name of the image in this file, including a date and time stamp. This way you can always check which image is installed on a workstation simply by looking at this file in the root directory of C:. See also section 2.5 Documenting your work below.
Some software packages have 'secret' ways in which the 'teacher' or the 'administrator' can login to a protected part of the application. This is often done with a fixed (and unchangable) password. It can be very convenient to make a simple list (on plain paper or in a file on the server if you trust it enough) of applications and corresponding passwords. It really is next to impossible to remember all those passwords and not to forget the special key-combinations to switch to teacher-mode or administrator-mode. (e.g. [Ctrl-L], [Ctrl-T], holding down the left [Shift] key when starting the program, click on a secret 'hotspot' in the pupil's screen, etc. etc.).
NOTICE: The two additional workstations should at least have some basic functionality, especially the test machine. The easiest way to create a working test environment is to restore a milestone image onto the test machine.This also makes certain that the milestone image that was created before on the 'golden image' machine actually works on another workstation.
We use the following conventions in our journal file in H:\My Documents\janitors\install\software.txt.
The beginning of a new educational application starts with a new line starting with an asterisk and a space followed by the name of the application.
The (summarised) output of the program is denoted by a line starting with a dot and a space.
Sometimes a comment is appropriate. That is written between parentheses.
The exact point where a milestone image is made is identified by a line starting and ending with three hashes, showing name + date + time when the image was created.
Here is a (constructed) illustration of these conventions.
This example of installing 'Traffic Trainer 1.0' leads to the following addition to the file C:\CONTENTS.TXT on the workstation (just before the image is made).
NOTICE: Even if an application installs smoothly, by the book, it can be rewarding to take notes, if only a short remark that the installation went exactly according the software publishers instructions. However, we almost never have experienced an educational software install behaving completely like the documentation.
This section contains a handful of examples based on real-world experiences. We chose to show you the contents of our installation journal bit by bit, adding further explanations along the way. By simply reading our notes you can get a good idea what we did and what's more, why we did things this way. The journal also shows the dead-end streets we encountered; documenting failure is at least as important as documenting success.
In an attempt to make the journal more readable we have emphasised the lines starting with an asterisk (used to indicate the name of the software package) and the lines starting with a dash (used to indicate user input). These examples will not be treated in a step-by-step way, only the problematic installation issues will be discussed in the comments.
NOTICE: As stipulated before the examples all assume that the special 'scholar' account is used during software installation. There should be no more than one user 'scholar' logged in. That would be the user on the 'golden image' machine.
Note that all experiments and installation attempts are carried out on the test machine. The final installation is done on the 'golden image' after the test installation succeeded. This keeps the 'golden image' machine as clean as possible.
The CD-ROM title is 'Bwian's Witing Challenge'. We do not know this program yet, so we first install it on our experimentation machine. We do keep notes in our journal, though. Here goes.
- Navigate to: My Computer | D:. SETUP.EXE found.
. Propose install on C:, H:, P:, Q:, R:, or V:.
- Choose P:. Click [OK].
. Install in: P:\Writers Guild\Bwians Witing Challenge?
Here we immediately found the SETUP.EXE in the root of the CD-ROM. However, your mileage may vary. Often you can find a file AUTORUN.INF, in which you find a line, for example Open=Setup.exe, or some other executable, or you have to search the CD-ROM or diskette(s) for an executable that starts the program or the installer. There are many possibilites and we do not know them all.
NOTICE: A short note on file and directory names. We do not like directory names with spaces and with more than eight characters. We prefer the DOS 8.3 naming conventions, so we create a directory P:\WRITING. Here we will store all our writing software, including Bwian's Witing Challenge.
In this particular case we could not browse to the exact location where we want the software to be installed because there was no [Browse] button in the installer. However we managed to type P:\WRITING\BWC manually.
Even though we tried to change the installation path to P:\WRITING\BWC\, the software insisted on adding two extra levels in the directory tree. Sometimes this happens. It is simply a matter of accepting this strange behaviour. Trying to 'fix' it sometimes makes it even worse.
NOTICE: Some applications only allow you to choose the drive letter. In these cases you could end up with things like P:\Program Files\Writers Guild\Bwians Witing Challenge. On the other hand: some software only allows installation on drive C: which is even worse.
No Desktop icons were created automatically. We will create some ourselves by navigating to the installation directory.
- Create shortcut: Right click desktop | New | Shortcut.
- Browse to P:\WRITING\BWC\Writers Guild\Bwians Witing Challenge.
. Create shortcut: Command line path set.
- Change 'Shortcut to BWC' into Bwian's Witing Challenge.
. Select a Title for the Program closes.
- Copy desktop icon to H:\My Documents\janitors\shortcuts.
- Copy shortcut Bwian's Teacher to H:\My Documents\janitors\shortcuts.
The program seems installed in P:\WRITING\BWC. After unloading the CD-ROM and rebooting the workststation the program still 'works'; i.e. both BWC.EXE and TEACHER.EXE start. That looks good. It also works when logged in as 'grade8'; better still.
NOTICE: At this point a further test of the program with the checklist in section 4.1 Checking the installation is a good idea. When everything stays OK, the program can be installed 'for real' on the image machine.
NOTICE: After testing the experimental installation you might want to try to change some details that failed in the experiment. Resist the temptation to experiment with your 'golden image'. For example, in this particular case you might want to instruct the installer to install to P:\WRITING, or even P:\ instead of P:\WRITING\BWC. That may work, but be careful! It is very well possible that the installer thinks that P:\ is NOT acceptable because it is not a subdirectory, never mind the fact that the path Writers Guild\Bwians Witing Challenge is added anyway. Sometimes it really drives you nuts. Note that you may need to create new icons if you change the install path.
In the end, we can say, this was an installation on the P: share, no database, no CD-ROM necessary after installation. This was an easy one.
The next software package is also delivered on a CD-ROM. It bears the title 'Roberta's Reading Rally' (where needed abbreviated as 'RRR'). Note that we do not know the details of this application. Therefore we will first try to install on the test machine. Here is the installation report with the comments.
We start using the local CD-ROM player.
That is correct: the installer starts automatically, thanks to the 'AutoRun'-feature. We will deal with disabling this feature via registry key NoDriveTypeAutoRun in section 2.2 Preparing policies in chapter VIII. Managing user profiles. For now we will simply accept this behaviour. See also section 11.2.9 Getting rid of Autorun in chapter IV. Workstation setup.
Install in C:\Program Files\Roberta's Reading Rally?
. Select Target Directory. Dropdown menu.
- Dropdown, select P:. Select P:\RRR. Click [OK].
. Select Target Location: P:\RRR\Roberta's Reading Rally.
. Start Installation. You are ready to install ... etc.
. Found DirectX. Found more recent version.
Note that the installer has detected an existing version of DirectX. Fortunately this application detects that the installed version is more recent than the version it would install otherwise. What is even better is that this installer has decided to offer you a choice to install the older version or not. Keeping the latest version of these kind of helper software is probably the best choice. Unfortunately some installers insist on overwriting an existing (newer) version with an older one, no questions asked. More often than not this breaks other applications that rely on the newer version. In these cases it is always good to have a milestone image to which you can return.
We unchecked the checkbox 'Start RRR' because we do not want to immediately start the program. First we remove the CD-ROM from the CD-ROM player and then we will try to start the program, in order to find out if the CD-ROM is necessary or not while running the program.
. RRR: "The RRR CD-ROM cannot be found. Please insert in drive D:..."
When we removed the CD-ROM, the program cannot be executed. That is a real bummer. From this (first) installation attempt we did learn a few things.
Apparently this application requires the CD-ROM to be available in the CD-ROM drive. Even worse: it appears to require the CD-ROM in the CD-ROM drive from which the application was installed (here D:). That suggests that it will probably not work even when we would provide the CD-ROM in another CD-ROM drive (such as K:).
The installation did not take very long. It was too short for the installer to copy the complete contents from CD-ROM to the directory P:\RRR\Roberta's Reading Rally we specified. Further inspection of this particular directory reveals that only a single .EXE file and a handful of other files were installed. Perhaps accepting the default location on C: was not that bad after all.
A few entries were added to the Start Menu but no icons were placed on the Desktop. We have to make a copy of the relevant icons lateron.
The preliminary conclusion must be that this CD-ROM is a candidate for installing on the R: drive. The actual installation does not take too much space on the image, so we decide to accept the default location in our next attempt. However, first we need to do a bit of cleaning up, removing the remains of the initial attempt. After that we can start with a clean slate. The installation report continues.
This program should not be installed from the D: drive; i.e. the CD-ROM player in the workstation, but from the K: drive, i.e. the virtual CD-ROM player with a CD-ROM image located on the R: drive. When installed from K:, the program will ask for a CD-ROM in K:, every time the program is requested by a user. That would be better.
To be able to load a CD-ROM in the virtual CD-ROM player, you have to create a CD-ROM image and store the image on the R: share. The Janitor CD-Tool will create the image. This procedure is described in section 6. Managing CD-ROM images in chapter III. Janitor.
At this point the batch file ISO.BAT takes care of loading the CD-ROM image that was created with the Janitor program into the K: drive.
ISO.BAT shows a message indicating the CD ABP46A~1.ISO is being loaded. This is a strange name because we doubleclicked the file RobertasReadingRally.iso. The explanation is as follows. We started the .ISO file from R:. In chapter V. DAEMON Tools virtual CD player we configured Windows to open all files with the .ISO extension with ISO.BAT, which is a DOS batch file. Because Windows considers this program to be a DOS program it automatically converts the long filename into the familiar DOS 8.3 format that any DOS program should understand. In this case the short name of RobertasReadingRally.iso equates to ABP46A~1.ISO.
Now we are back at the point where the CD-ROM is inserted into the CD-ROM drive, be it that this time it will be in K: rather than D:. We will now take the same steps as in the first attempt, be it that this time we will allow the installer to install on C:. The installation report continues.
. RobertasReadingRally.iso installer starts automatically.
. Select Target Location: C:\Program Files\Roberta's Reading Rally.
At this point the basic installation is more or less done. Note that we accepted the default location. Nothing much will be installed in this directory as we observed when we peeked in P:\RRR after the first attempt.
After the installer closes the black DOS-screen with the message from ISO.BAT is still visible. We will deal with that later. For now we can simply click it away with the little X in the topright corner of the window.
At this point the program is (again) installed on the test machine. The installer (again) has created the various icons in the Start Menu. The program could now be started by navigating the Start Menu and clicking on the program icon. If we were to start the program this way it would in fact start. However, this only works because the virtual CD-ROM was already (or still) loaded in the K: drive. If this were not the case, you would get an error message like 'CD-ROM not found. Please insert into drive K:...'. We will attempt to solve this problem by using the features of ISO.BAT, see section 4.3 Using ISO.BAT in chapter V. DAEMON Tools virtual CD player.
create a shortcut to the program on the Desktop.
modify the properties of the shortcut.
test the modified shortcut, verify if it is working.
save the modified shortcut in the shortcuts collection.
. Target: "C:\Program Files\Roberta's Reading Rally\rrrally.exe"
At this point the original shortcut (called RRR.lnk) was copied to the Desktop where subsequently the properties were modified. In the original copy there was a field labeled 'Target:'. It contained "C:\Program Files\Roberta's Reading Rally\rrrally.exe" (including the quotes). This is the explicit path to the application. Apparently the actual program is called RRRALLY.EXE and it is stored in the directory C:\Program Files\Roberta's Reading Rally. Note that the complete target string is quoted with double quotes. This is necessary because the path contains spaces. If not for the quotes the contents of the 'Target:' field would be interpreted as the command 'C:\Program' followed by three parameters 'Files\Roberta's', 'Reading' and 'Rally\rrrally.exe'.
By prepending this target with P:\BIN\ISO.BAT R:\RobertasReadingRally.iso the target changes into a line that will be interpreted as a command P:\BIN\ISO.BAT, followed by a total of two parameters: 'R:\RobertasReadingRally.iso' and '"C:\Program Files\Roberta's Reading Rally\rrrally.exe"'.
This matches the usage listed in third place in section 4.3 Using ISO.BAT in chapter V. DAEMON Tools virtual CD player. The idea is that the command P:\BIN\ISO.BAT will load the (virtual) CD-ROM named R:\RobertasReadingRally.iso into the K: drive. After that is done, ISO.BAT will execute the program RRRALLY.EXE. Effectively this would automate the task of loading the correct CD-ROM into drive K: and running the program, all in one go. This is very efficient.
Note that the shortcut now has the MS-DOS icon. Please do not pay attention to it. We will change this later on.
P:\BIN\ISO.BAT R:\RobertasReadingRally.iso "C:\Program Files\Roberta's Reading Rally\rrrally.exe"
It looks like there is a limit on the length of the command line (of 78 characters) and it appears that Windows has silently truncated the command line.
The fact that the application starts anyway must be a result of the Autorun feature because ISO.BAT failed, as indicated by the two messages Bad command or file name.
At this point we have figured out that the command line is too long. There are several ways to deal with this.
Working: "C:\Program Files\Roberta's Reading Rally"
Note that the quotes are still required when specifying the working directory because of the embedded spaces. With 54 characters the command line is now well within the limits. This solution works. It is based on the effect that DOS always searches for executable programs and scripts in the current directory before it searches the PATH. By making the directory which contains the program RRRALLY.EXE the current directory, the program is found even when the explicit path to RRRALLY.EXE is not specified.
A second solution might be to choose shorter names for CD-ROM images and to leave off the extension .BAT in the program name ISO.BAT. If the CD-ROM image would have been called R:\RRR.iso instead of R:\RobertasReadingRally.iso the command line could have looked like this.
Cmdline: P:\BIN\ISO R:\RRR.iso "C:\Program Files\Roberta's Reading Rally\rrrally.exe"
Note that this command line is now 76 characters long, only 2 characters away from the limit of 78 characters. A drawback is that the name 'RRR.iso' gives no clue about the contents of that file. A name like 'RobertaRR.iso' would be better but then the command line would still exceed the 78 character limit.
A third solution could have been to create a new helper script specifically for this CD-ROM. Such a modified version of ISO.BAT might look like this (see also section 3.3 Installing ISO.BAT in chapter V. DAEMON Tools virtual CD player). Changed lines are emphasised.
ECHO No ISO-file was specified!
By storing this batch file under the name P:\BIN\RRR.BAT the problem with the long command line would be solved because it now would look like this.
This is well within the 78-character limit. Note, however, that this is a very specific solution. You may need to create many files derived from ISO.BAT to accomodate all long command lines. This can easily lead to a maintenance nightmare, especially when upgrading the software.
After giving the matter some thought, we decide to solve the problem with the long command line using the trick with working directory (the first solution in the previous section). We also solve the remaining issues with this program, e.g. changing the MS-DOS icon and getting rid of the black DOS-screen automatically. The installation report continues.
- Working: "C:\Program Files\Roberta's Reading Rally\rrrally.exe"
. the properties dialogue closes.
This example was done on the test machine. Obviously the installation has to be done 'for real' on the machine that is used to create the 'golden image'. The program should then be checked as described in section 4.1 Checking the installation below.
NOTICE: The effect that the CD-ROM also runs automatically can be very annoying. We will deal with disabling this feature via registry key NoDriveTypeAutoRun in section 2.2 Preparing policies in chapter VIII. Managing user profiles. For now we will simply accept this behaviour. See also section 11.2.9 Getting rid of Autorun in chapter IV. Workstation setup.
We specifically chose to run the apppropriate command (here: RRRALLY.EXE) even though the program is also started via the Autorun feature. This is because we do not want to rely on this feature. If we did and the feature was disabled, nothing would happen. That is worse than starting two instances of the program in our opinion. Of course, the program should only be started once, period.
This concludes our second example, which, in the end, was an installation on the R: drive. This example showed that there are many ways to fix startup problems.
In this example we use an Internet download, i.e. 'Mad Math Minute', created as part of Brown University's Educational Software Seminar, CS92 in May 2000. It can be downloaded at http://www.cs.brown.edu/courses/cs092/2000/madminute/.
NOTICE: We did not choose this program for any educational purpose but only for technical reasons.
Here is the installation report.
This is a straightforward installation. As can be seen in the report, the download is first copied to V: for unpacking. This is a security measure. You do not know in advance what is in the zipfile.
The installation described above can serve as a model in several ways. The README-file contained all necessary instructions to install the program on P: and the central database on Q:.
Exemplaric in MMM is that many programs lack installers. You have to manually edit one or more configuration file to set the correct path to the database. Sometimes other options also need to be set. It's not especially good or bad to not have an installer.
There is plenty of educational software that uses a database, but does not allow setting a different location for the database. The best solution is to completely install these programs on the Q: share. Even worse are programs with a database that only installs on the C: drive of the workstation. This means you have a number of local databases. In this case the best solution is to look for another program.
After the program is installed it needs to be checked as described in 4.1 Checking the installation.
In the end this was an example of an installation on the P: and Q: drive.
The next example is a CD-ROM called 'Treasure Words'. According to the (scarce) documentation on the CD cover the program can supposedly be run directly from the CD. A short inspection of the contents of the CD-ROM reveals that there are only two files on the CD-ROM: a file TW.EXE of some 8 MB and also a file called TW.ICO of a few hundred bytes. If the documentation says the program can directly be run from the CD, apparently no write privileges are necessary. It seems only logical to simply copy the contents of the CD to P: (which is also read-only for ordinary users, just like a CD-ROM) and create a shortcut to TW.EXE on the Desktop.
Well that was an easy one.
Alas, famous last words. After removing the CD-ROM from the CD-ROM player and testing the program (using the account 'grade8') it fails miserabely: Can't find CD. Exiting.... That is really weird: there are only two files on the CD and we copied those to P:. The copy is identical and it still does not work. There must be some 'trickery' on the CD-ROM. It seems like the installation report will be a little longer than we expected.
. System Error: Windows cannot read from drive K:.
If this is a network drive, make sure the network drive is working.
If it is a local drive, check the disk.
There is a problem. When the CD-ROM is loaded in K:, the program will start, just like before when the CD-ROM was still in the D: drive. However, when the TreasureWords.iso is not in K:, the link to TW.EXE cannot be found. So it seems that we have a situation comparable to the one with Roberta's Reading Rally (see section 3.2.3 Loading the CD-ROM automatically above). The installation report continues.
- Rightclick TW shortcut again (now a .PIF instead of .LNK).
- Double click on TW shortcut.
If the CD-ROM is still in the drive, it may require cleaning.
This is becoming annoying. Somehow the shortcut does NOT work, even after we did our trick with ISO.BAT and all. This certainly is puzzling.
After studying the properties of TW.pif once again it becomes clear that somehow the working directory was pointing to K:\. This means that Windows will try to make K:\ the working directory before the command line P:\BIN\ISO R:\TreasureWords.iso K:\TW.EXE is executed. As a matter of fact the (virtual) TreasureWords CD-ROM was still in drive K: during the test above but, unfortunately in this case, ISO.BAT always unloads the old CD-ROM before loading a new one, even if it is the same CD-ROM. This means that at some point the working directory becomes invalid because there is nothing loaded in the K: drive. This explains the blue screen. The easy solution: change the working directory in the shortcut properties.
NOTICE: We have re-used a left-over of a previous experiment. We already figured out that it would not be a good idea to use the icon on the CD-ROM as the icon for the shortcut because this file is not available when the CD-ROM is not available. In the first attempt, however, we already copied the .ICO file to P:\TW\TW.ICO. We need to remember to clean up P:\TW\TW.EXE lateron but to keep the icon file.
This calls for more drastic measures. Somehow something goes wrong with ISO.BAT. Because this script starts with the command @ECHO OFF you can not see where it fails. After commenting out that first line by prepending it with REM and effectively changing the line into a mere remark, all commands from ISO.BAT are displayed on the screen before they are executed.
After executing the modified ISO.BAT it is easy to see that the error message ('Windows can not read from drive K:') is caused by the following line in ISO.BAT.
This line directly follows the line in which the virtual CD-ROM is loaded. It looks like loading the CD-ROM needs a little more time. The instruction to do something with K:\TW.EXE (here: testing for existence) comes too early. The solution is to copy ISO.BAT to ISOWAIT.BAT and subsequently modify the ISOWAIT.BAT script in such a way that a pause of say 2 seconds is added right after the CD is loaded. This gives DAEMON Tools the necessary time. Here is a snippet illustrating this. The change compared to ISO.BAT is emphasised.
Now we are getting somewhere. This actually works, be it that it now takes 7 seconds before a program is started compared to the original 5 seconds. However, this is good enough because not all programs will be using ISOWAIT.BAT. Other CD-ROM-based programs such as Roberta's Reading Rally will still be using the original version of ISO.BAT without this extra delay.
Yet another solution might have been to copy the TW.EXE file to P:\TW\TW.EXE like we did in the first attempt. Then a shortcut pointing to P:\TW\TW.EXE might have worked too.
The program still needs to be tested as described in 4.1 Checking the installation. In this case nothing was installed on the workstation; in the end we only installed an .ICO file on P: and we invested quite some effort in constructing a shortcut TW.pif.
This example illustrates that there are many ways to get an application working. Experimenting on the contaminated machine can reveal new options. In the end this was an application that requires the presence of the CD-ROM in K:, a little like Roberta's Reading Rally.
The next program is on a CD-ROM called 'Magical Math' (abbreviated to 'MM').
Magical Math, many files, among them start.html and mm.ico.
The .html extension already revealed that this is web based software, accessible with a web browser. This software is very easy to install once the target location is chosen. The question is: should the content be accessible world wide or only within school?
In the latter case, you simply copy the software to the P: drive, for example in the mmath directory. The program can then be accessed by pointing a web browser to P:\mmath\start.html.
In the former case, you have to ask the webmaster or the local systems administrator to copy the files to a directory from where they can be served by the school's webserver, maybe in /home/httpd/htdocs/mmath. If permissions and ownership are set correctly, the files can then be accessed from within the school or outside the school using the website. For the Exemplum Primary School that would be something like http://www.exemplum.serveratschool.net/mmath/start.html.
A big advantage of installing this software on the webserver is that pupils can use the software from home, even if they do not have Windows-based computer at home; an Apple Mac with Safari or a Linux-machine with Mozilla or any other browser will work at least as good.
A disadvantage is that serving the software this way may violate the terms of the software license. Furthermore, it takes up bandwidth on the school's Internet connection. In this example the ICT coordinator decided that the software should only be available within school in order to reduce internet traffic.
- Create directory mmath in P:.
. Shortcut created. Name: Shortcut to start.
- Shortcut renamed to: Magical Math.
Note that only the contents of the directory D:\Magical Math was copied to P:. There were many more files on the CD-ROM, such as a version of a particular plugin that might be necessary or handy. In our case we do not need these files because our browser already has all necessary plugins. No need to install files that will never be used.
At this point we have a working shortcut called Magical Math. However, there is a problem with this shortcut: the shortcut has the wrong icon, namely the Mozilla Firefox icon. We want to use the special Magical Math-icon which we found on the CD-ROM (in D:\Magical Math\MM.ICO).
NOTICE: The shortcut might be a so-called Internet Shortcut (what's in name?) which is nothing more than a special file with extention .URL. Files with this extension are not considered part of a user's roving profile; Windows only allows .LNK and .PIF files to be used in these profiles. Therefore you can not use these files. You have to create a file of type .LNK or .PIF.
We fix the issue with the icon shortly. The installation report continues.
. Magical Math Properties | Shortcut opens.
. Magical Math Properties | Program opens.
- Browse to P:\mmath\MM.ICO and select it.
. Magical Math Properties closes.
The shortcut has the MM icon. Now the program should be checked using the checklist in 4.1 Checking the installation below.
In the end this was an easy program to install. Because it basically is a read-only program it was possible to install on P:.
When an installation seemed successful, only two things have to be done: checking the installation, and when approved, cleaning up the mess caused by failed installations, downloads or experiments.
When you have successfully (?) installed a program, it is a good idea to check a couple of things. The list below sums up various checkpoints for all installation types on all shares.
When testing always remove diskettes, CD's, etc.
Never test an installation as user belonging to the 'janitors' group. Members of the janitors group can reach parts of the server other users can not reach. The also have access rights ordinary users may not have. It is better to perform a test using the account of a user that is actually going to use the application, say 'grade3' or 'hparkh'.
Many educational programs have a special module to let teachers manage the scores of the pupils using the program. Do not forget to test this functionality too. It may be necessary to enter the names of all individual pupils before the teacher module can be properly tested.
Test if an application that uses the network still functions when more users make use of it at the same time.
When the program has a print funtion, does it indeed print?
Do a quick test if the program starts.
Inspect Start | Programs | Program to see if the program has options you want on the desktop. If so, create or copy the shortcuts.
Always check if the program is indeed installed on the chosen share(s). Some programs are not that well programmed. You specified the path to P:, but the programmer made other decisions and still installs on Q: or C:.
Check if the program has a database. Can you register yourself?
Does the program need extra configuraton (sound on/off, printing allowed, etc.).
Can the program import pupil data from one of your other programs (pupil administration program)?
Run the program by registering yourself and checking if your name exists in mmtmp.mdb and, when you have made no errors in the exercise, check if your name appears in HallOfFame.mdb.
'Mad Math Minute' uses an Access database. When you have no program to check the contents of this file, just open the files with Wordpad and try to find your name. If it is somewhere in the garbage, data is written to the file. Note: do not write in the file with Wordpad but exit without saving.
Delete the database files you used for testing and copy mmtmp-orig.mdb and HallOfFame-orig.mdb back to mmtmp.mdb and HallOfFame.mdb. This way you make sure the pupils will start with a clean database.
Always check if all the options in the Start Menu work as they should.
The ultimate test for a programs functionality is to ask the teacher that works with the program to test it with her pupils. A local systems administrator can not be expected to know all the programs functions and idiosyncrasies.
After checking all these points, install the program 'for real', on the machine with the 'golden image'. Do not forget to update C:\CONTENTS.TXT with the at least the name of the installed progam and a date/time stamp.
After installing (educational) software it is a good idea to do some cleaning up. Section 11.3 Cleaning up in chapter IV. Workstation setup has a short list with cleanup tasks.
If you followed the advice to use two or three workstations during installation of educational software, most of the leftovers of the experiments will be on the test machine. The 'golden image' machine should still be a clean machine.
It may be handy to create a fresh 'milestone image' now. After that is done, you may want to restore that image onto the test machine and perhaps on the machine you used to keep notes. This way you have at least one other machine with the current image, ready for another batch of experiments and tests with educational software.
We hope we made clear in this chapter that installing educational software can be a task with many pitfalls, hidden treasures and unexpected events.
When you have installed all software packages, the Desktop of the special 'scholar' user account will be filled with shortcuts as will be the H:\My Documents\janitors\shortcuts directory. The Programs section in the Start menu will also contain a long list of programs.
In chapter VIII. Managing user profiles the personal profiles for all users will be enabled. After that, in chapter IX. Shortcuts, desktops and start menus, we will assign each user and group their own shortcuts.

References: V. 
 V. 
 V. 
 V. 
 V. 
 V.