Process for
image updates:
This document has been created to reduce or avoid confusion and help eliminate incorrect information being distributed. The processes by which image updates are implemented are as follows:
1) The person responsible for the distribution and updating of the image (here forth called “Image manager”) announces a deadline date 3 weeks prior to the start of the semester. This date is established to allow all software being requested to be received, installed, tested and image distributed prior to the first day of class.
2) This announcement goes to all ACMs (Academic Computing Managers) and the Language Resource Center Manager. These are the people responsible for managing all faculty software requests and reducing the actual list to a manageable and reasonable set of software.
3) Once the software is received and all database records are updated with the necessary installation information the image is updated with the new software. A record is kept on the image (PC—modfile.txt found at “C:\” and Mac-OS X—modfile.rtf located at “\\local_drive\Applications”) of all image changes, updates, deletions and OS/application preference/configuration changes.
4) An e-mail notifying the ACMs, LRC manager as well as the HelpDesk and all image supporting staff is sent with a brief list of what image changes have been made. It is best to make a reference to the modfiles and their appropriate locations to allow those who want a complete list of changes to easily find them.
5) The image is deployed by whatever means happens to be in use. (Ghost for Windows, NetRestore and Assimilator for OS 9, NetRestore and radmind for OS X)
1) ACMs send note to professors before the beginning of the semester alerting them to the software submission deadline provided by the Image Manager.
2) Professors bring software to ACMs.
3) The ACMs determine if the software can be accepted (cost, size, etc. are items considered)
4) Enter/update software information in the Software database
5) Software then submitted to the Image Manager for further analysis of acceptability.
Application updates occur on an almost weekly basis. The reason for this is software developers constantly find and repair bugs in their software as well as image tweaks and adjustments. Application updates require the same process of:
1) Professor notifies ACM
2) ACM notifies Image manager.
3) Updates are promised 2 Fridays after update is requested unless ACM is notified of problems created by updates (breaks other applications, causes image to not boot on one or more models, etc).
4) Image manager notifies ACM of update being placed in the image(s).
5) Image is deployed to labs.
Classroom images are a slightly different situation. In order to provide the most reliability, stability and continuity classroom images are updated in these three situations:
1) Semester breaks (Summer, winter)
2) If major updates occur during the early part of the semester updates are distributed during fall and spring breaks.
3) Major application revisions or updates due to security, class necessity (class cannot continue without this new or updated package). This is done on an “as needed basis” only in the rooms that are applicable.
Reasons software requests can be refused by the Image manager (via authorization by the Instructional Media Services Manager or the Academic Computing Manager) are as follows but not limited to:
1) Hard drive space limitations
2) Expense of software (depending on whose budget is impacted and necessity)
3) Difficulty in distributing the software (licensing restrictions, requires technology to restrict access or make machine specific that we do not currently have or employ)
4) The package causes a conflict with another package of software of equal import
5) Circumvents current network security, network policy or general use policies
6) Software request is not from an “authorized representative” (ACM and LRC Manager)
This sections describes the process of what a faculty member can do when denied a software addition they have requested.
1) Request the reason (supplied by the Image Manager when refused) and work with the ACM to identify a compromise (if it is a space issue—what can be deleted to make space; what app is conflicting and see if the two tech support teams of the conflicting apps can help; etc.)
2) In the case of the request not coming through an “authorized representative” then pass the request through such a person.
3) Request a meeting with the ACM and the Image Manager (and ACS Manager if deemed necessary) to resolve the issue.
This describes the mechanism by which the PC images are distributed to the Public computing labs and the classrooms.
Classrooms are imaged on a very basic schedule to offer the most stability and continuity. This schedule is during long breaks (Summer, Winter, and Spring breaks) and ad-hoc for those rooms that may require an update due to software updates/additions a professor might need to teach class. Note, these changes may already be in place in the labs that are imaged weekly and updated based on the previously mentioned schedule (During Semester image changes—item 2).
Occasionally there are errors created in the image and then distributed. The errors can be omitted shortcuts, preferences/configurations not set to requested setting or applications deleted (accidental or otherwise). When these items are discovered the following steps need to be taken to rectify the situation as soon as possible.
1) Notify your ACM. They will immediately notify the Image Manager. If the deployment is in the middle of a cycle (not all machines have been imaged for that week) the imaging for the rest of the week can/will be halted depending on the urgency of the remedy being in place. Only the Image Manager and the backup person have this ability.
2) Image update is made and tested as quickly as possible. Then the new image is made ready for deployment.
3) For those machines already imaged with the “bad” image and not scheduled to be imaged again for another week an update containing only the necessary changes will be made and immediately deployed at the first major opportunity (lunch hour, before 8:30am and/or after 5pm—all to avoid major disruption of machine use in the various locations. Classrooms can be updated upon room being vacant of class).
The method of testing applications for image deployment is rather limited. It is currently based on successful launch of the application before and after imaging. Then, 3 stations representing the 3 different production model PCs are imaged with the newly created image. However, if an application is updated and components not immediately associated or known to associate with the updated application are deleted they will not be not likely be detected to be deleted or malfunctioning. This is where knowing how to notify the Image Manager of necessary changes becomes apparent.
Macintosh image update testing is similar in that the changes are deployed to a few random Macs and run. If errors are discovered they are rectified and retested. If the final test finds the update to be reliable they updates are them made universally available.
If there are questions about an application that the Image Manager cannot answer during testing the ACM responsible for the application request is contacted for basic testing.
Draft 3 updated 1-26-04 by Vincent Spiars