How to deploy and virtualize any software app to university computer labs in 2017

It's 2017 and it's no surprise that students want to work anywhere; whether it's with friends or in a campus near their residence.

Today's students expect university IT to be flexible, or at least flexible enough to allow them to work where they want, when they want. An important part of that flexibility is having anywhere-access to the apps they need to study; students don't want to have to go to computer labs at set times.

But when it comes to enabling that level of flexibility with app deployment and delivery, it can be easier said than done...

What are university labs?

University labs (sometimes known as computing clusters) are part of a university's IT facility. They're typically on campus; a place students go to access a range of software applications, all provided by the university, on university-owned machines.

Computer labs can be open access with some general apps available, or they can be subject specific, say engineering. It simply depends on the size and scale of the institution as to the number and range of areas that are available to students.

What's the purpose of computer labs?

Labs are primarily trying to keep students happy! Originally, labs existed as a way for universities to provide students with a device and a range of apps to do their work. Nowadays, with 99% of students having their own super-powerful laptop, labs often only exist as way for students to access university-provided software.

For example, if a student has an assignment for which they need to access to a specific app, say SolidWorks, then there's an expectation that they'll be able to go to a room and find a machine to do that work.

How does university IT deliver apps to labs?

Historically, apps were just put in an image and pushed out as one. This often involved a technician sitting in the room waiting for the network to fall down so they could restart the exercise. The major issue though was that apps were getting larger and larger, and in turn image sizes became unmanageable.

One way of solving this was having labs that were subject specific, and then the institution managing multiple images. This wasn’t ideal; it allowed for little flexibility on the students' part, and often presented timetabling issues.

What technology is used to deploy apps to labs?

Most universities and colleges use a variety of technologies. At the heart of this is their core imaging technology, most commonly Microsoft's SCCM. This is used to push images out to end machines. Whilst it does a great job of that, it offers little flexibility: managing a last-minute room change would cause severe headaches for example.

Though it's absolutely fine at pushing out the image, pulling it back typically isn’t possible, and therefore it's not a suitable solution for strategies like BYOD (bring your own device). AppsAnywhere works alongside imaging technology such as SCCM, giving you greater flexibility in deploying apps to labs and students.      

What are the problems in deploying apps to labs?

The challenge educational institutions face when it comes to getting apps to labs is: how do you keep all your users happy? With potentially thousands of students and staff wanting access to any one of 300-500 apps, what do you do? Where do you start?

The traditional model in deploying apps, therefore, is that often different rooms will be set aside with specific software on. For instance, rooms within an engineering campus with just some engineering apps. But going to those specific rooms is probably not what students want...

What do students want?

A lovely phrase mentioned by one of our customers is that "students don’t care about the desktop, they just want apps". Admins, on the other hand, love desktops!

Students want to be able to go to the building, campus or coffee shop nearest their accommodation, sit with their friends (who are maybe studying something different!), choose the nicest room, and generally work in the most productive or enjoyable environment.

How do we solve the problem?

The AppsAnywhere model is ideally one image (perhaps two at a push, but one is the dream!). This image is then considerably smaller than historic models – often not much more than MS Office, anti-virus and some other core services. We then push down apps on demand using Cloudpaging application virtualization, where and when they're needed. This makes the imaging process considerably easier; far less work and time is required to build the standard image!

By separating apps out, it also allows for upgrades/patches at any point in time, without the need to pull down the services to change images. We know that everyone has that vendor who sends an update in September at the start of term after the image has been built, or the academic that complains that the wrong version of software is included and it doesn’t match their course notes (this is despite the repeated emails asking for this information earlier in the summer….).

In a AppsAnywhere world, these challenges are no more and you can deliver a service that exceeds the expectations of both students and staff. You might even get your summer back!