UIU Blog

Considerations for Supporting Student PCs

On May 13, 2014 in Deployment Discussion by SuperUser Account

As an educational institution in the age of ubiquitous computing, decisions need to be made regarding the technical support of any individual student's hardware and/or software. There are many factors that must be considered prior to establishing a policy with regard to the same. These include, but are not limited to, hardware purchasing, standardization, support commitments (how far to troubleshoot before re-imaging), deployment and logistics - and let's not forget network security.

How do we support student PCs? Or shouldn't we?
As with everything else, there are reasons for and at least an equal quantity of reasons opposed. Without pretending to know all of the intricacies of every type of institution and give advice on what to do, I'll simply offer up some points for consideration.

Assumptions:

All students have PCs/laptops.
All institutions offer some form of network-based computing resources, ranging from web pages (public or internal) to direct network connectivity.

Considerations:

Is PC computing required for curricula execution?
Is hardware supplied by/through the institution?
Is software supplied by/through the institution?

In the case where hardware is supplied by the institution, cost and tuition issues aside, efforts can (and should) be made to limit the selections of make/model and operating system. Uniformity enhances standardization, reduces security vulnerabilities, leverages purchasing discounts, and reduces logistics and support costs.

Student-supplied hardware could represent any make/model and could be in any state of vulnerability/security risk at any given time.

The case where an institution recommends or requires students to supply their own hardware, the problems change face a bit. For example, a criterion that enters the equation is whether the institution insists on providing an OS/Software image for the student computing population. Therein lie software (incl. OS) licensing as well as compatibility and version control issues. That's a topic for another day…

How is this different from supporting PC Lab machines or staff PCs?

All student PCs are mobile (or at least we'll assume/consider them to be as such). As student machines may be inaccessible by network administration services at any given time for any reason and without notice, we need to consider them to effectively be considered as mobile even if they may be traditional desktop/mini-tower models.

Simply put, PC Lab machines are not only under the control of some institutional entity, they are also static; they don't move around. Desktop policies can be set, physical access can be gained at will, and visual inspections can be performed with regularity. Staff machines, although they may be mobile, are still firmly under control and policies and standards apply, whereas student machines are very often an unknown and frequently present not only security vulnerabilities but also logistics and maintenance issues. How can the institution be sure that updates are regularly applied? How can the institution be sure that the machine is not infected with a digital pathogen?

If student-maintained machines are to be let anywhere near an institutional network, great care should be taken to mitigate threats, not just before they infect a network resource, but also after this has inevitably occurred. In addition to the standard anti-virus and anti-malware software, strategies such as the employment of honey pots or ghost armies can misdirect and distract would-be hackers, allowing more time to detect the intrusion and respond to the threat.

Let's face it, support of multifarious machines with questionable levels of security and significant limitations on institutional control is looming if not already upon us.
How do we protect our network resources from the risk of infected student machines?

Is standardization an option? If so, use it heavily. Mandate that all student PCs have anti-virus/anti-malware installed and updated in order to gain access to network resources. Ensure that all public or Lab PCs have AV/AM enabled on all removable devices. Keep AV/AM as well as operating system patches up-to-date!

As it's not a matter of if but when, have a lockdown protocol and practice it. Employ advanced misdirection strategies as discussed above. There are or will soon be both appliance and software implementations available to make it easier to instantiate.

How about break/fix?
Some institutions provide break/fix services; I would wager, however, that most insist that the student take care of their PC issues on their own. This, in my opinion is strictly a liability/cost vs. service/value proposition. If the intention is to provide such a service on non-institutional machines, have the necessary waivers in place and, for the love of Homer, provide adequate training for your technicians.

That said, as institutions become more and more dependent upon PC computing to execute their curricula, they may be compelled to assist students with hardware/software problems in order to maximize the effectiveness of the application of same.

I hope that this is received as helpful and has provoked some thought. Please feel free to send constructive feedback.

Comments are closed.

Showing 0 Comment

Tagged With: pc standardization, student machines, student PC support, student PCs, student-supplied hardware, support student pcs, technical support

Search

Categories

Archives

About Us

Recent Posts

Contact Us

Message Us