The University Wiki Service has upgraded the Confluence Server software, from version 5.9.14 to 5.10.8. Please refer to the knowledge base article, KB0015891, for a high level summary of upgrade changes. Thank you!

Page tree
Skip to end of metadata
Go to start of metadata

Lab Configuration Policy

Preface

The College of Communication’s Technology Services supports computer systems in student labs and classrooms in BMC, CMA and CMB.  Student lab and classroom support is our top service priority.

I.  Intent of policy

This policy will simplify the management of lab computer software by establishing a common look, feel and configuration for all lab computers throughout the College.  Because the software configurations will be consistent in every lab, users can move between labs without sacrificing capabilities.  Students, faculty and staff will always be greeted with a familiar setup on every managed computer in the College.  Most importantly, Tech Services staff will be able to maintain safe, secure and reliable computer labs.

II.  Scope of policy

The following computer labs will be managed according to this policy:

  • Advertising Creative Lab (CMA 6.202)
  • Broadcast Journalism Studio (CMB 4.128, 4.130, 4.132)
  • Communication Sciences and Disorders Clinic Lab (CMA 2.222, 2.224)
  • Computer Assisted Journalism Labs (CMA 4.300)
  • Digital Media Labs (CMA 4.204)
  • Photojournalism Lab (CMA 6.200)
  • Radio-TV-Film Studio 4B Lab (CMB 4.110)
  • Classroom Teaching Consoles (various CMA & CMB meeting rooms & classrooms)

III.  Requesting changes to system configuration

Requests for new software installations or updates will be solicited from faculty and staff prior to the beginning of each long semester.  The final “build” will be considered “complete” once the semester begins, therefore users should plan their requests accordingly.  Software installations and updates may be requested during the semester by faculty and staff, but will only be deployed on a set schedule (below).  To allow for testing and administrative review, we must set software request deadlines in advance of actual deployment targets.

Regular software deployment schedule:

 

Fall

Fall Update

Spring

Spring Update

Summer

Request deadline

21 days prior to 1st Class Day

5th week

21 days prior to 1st Class Day

5th week

14 days prior to 1st Class Day

Deployment target

7 days prior to 1st Class Day

7th week

7 days prior to 1st Class Day

7th week

7 days prior to 1st Class Day

 

Application and operating system preferences will remain the defaults, whenever possible.  We cannot incorporate every request for preference changes without affecting other users.  Additionally, students, faculty and staff working on their own computer systems will face these same defaults.  Any customizations we make will result in a configuration they are unfamiliar with.

IV.  Operating system and application security updates/upgrades, patches, fixes

Operating system and application security updates will be deployed as quickly as possible. Security updates will not be bundled with other updates to allow rollback in case of problems.

Minor application updates (“bug fixes” and enhancements) will be deployed according to the normal software update schedule and may be bundled with other updates at the Help Desk’s discretion.

Minor operating system updates (“dot upgrades”) will be deployed according to the regular software update schedule (section III). These updates will NOT be bundled with other updates and can be rolled back if needed.

Major operating system updates (including service packs) will only be performed during semester breaks to allow for extended evaluation and testing.

V.  Storage configuration

Internal disk drives will be partitioned to include one “system” disk that contains the operating system, applications, preferences, etc. necessary for the system to function.  This will be “locked down” to the best extent possible, to protect the system from unintentional or malicious damage.

There will be at least one “temporary storage” partition that will have no restrictions on reading, writing or modifying.  Any user can save files to this partition, or can erase any or all files stored within.  Some applications require this partition for “scratch files,” as well.  These will be configured to prefer this partition when possible.

On Macintosh systems, this partition will be named “tempstorage.”  On Windows systems, this will be the “D:\” partition.  These temporary partitions will be automatically cleared (every file removed) at 5:00a.m. every Sunday morning.

VI. Routine maintenance

Computer systems will employ some mechanism to restore their configuration to the state before a user logged on.  When a user logs out, this mechanism will trigger and cause any files the user has saved to the system disk, temporary preferences, bookmarks, caches, etc. to be erased.  This will ensure that a system remains as “pristine” as possible, and will help to mitigate the risk that personal or confidential data is stored on lab systems.  This will NOT affect any temporary storage partitions, so take care to remove personal or confidential documents you have stored there, or they are subject to exposure until the automatic clearing schedule (section V).

VII. Periodic maintenance

Periodic maintenance will be designed to keep client computers free of any programs, spyware, various user files, etc.  This maintenance, also referred to as “rebuilding” or “re-imaging” will essentially restore the computers to their original state before any users had logged on.  This will occur as needed.

VIII.  Network file services provided

The College will provide network shares for the labs listed in section II.  The following types of shares will be provided:

“Transfer” share

This is a temporary space that allows you to move files from one lab/computer to another.

1.  Storage is temporary:  all contents will be erased every Sunday morning at 5:00am.

2.  Will be a single large share that all labs across the College will be able to access, facilitating the moving of files between labs.

3.  Data security, privacy and backup should NOT be assumed by the user.

4.  Access will be limited to College of Communication networks.

“Special Projects” shares

This share will be available upon faculty or staff request, according to the following guidelines.

1. Project must have a stated end date.

2. Shares will be restricted to those EIDs provided by the requestor (non-University users will be required to sign up for a guest EID).  We can provide a list of EIDs of students registered for any course – just provide the course Unique Numbers.

3. Shares will be backed up routinely (schedule determined by Tech Services).

4. Shares must be requested at least 7 days before required.

Contact the Help Desk for more information, or to request a share.

“Instructional Materials” share

This is a single “read-only” share that contains any resource materials for use by students, faculty and staff in their coursework.

1.  Inclusion of materials is at instructor request, but must be accompanied by license agreement allowing royalty-free use.

2.  Materials are kept until we are asked by the requestor to remove them.

3.  Access will be limited to College of Communication networks.

4.  We may not be able to accommodate all requests, if space or preparation workload does not allow.

Other file services

The University provides individual file services via the WebSpace service.  See http://webspace.utexas.edu/ for more information.

For any questions about this or any College of Communication technology policy, please contact the Director of Information Technology (Charles Soto, 512-475-8661).