James Pickett at the University of Surrey outlines why the University chose to virtualize their apps, which technologies they looked at using, and the methods they used in this process. James explains how they implemented AppsAnywhere's technology (branded Surrey Software) to streamline their application delivery and introduce a BYOD process, too.



Streamling App Delivery at University of Surrey with Surrey Software - Video Transcription

My name is James Pickett. I’ve worked at the University of Surrey for 13 years now. I began my career in support and worked through front line and second line technical support, before joining the systems team roundabout the time we were migrating from Windows NT to XP. Our journey with Application Jukebox [AppsAnywhere] and software virtualization began in about 2008, when Surrey went through a very large restructure with a big cost-saving remit. A painful experience for everybody at the time but something that needed to happen, especially given the economic outlook for the following few years. What it meant was that for IT, we went from being a very dispersed group—Surrey is very big in engineering, business, we have a large faculty of humanities, we have a big dance school, so very different things going on—presenting very disparate IT challenges but engineering is probably our focus, and that gives you the idea of the kind of applications that we were having to deal with and make available to students. So, in 2008, after our restructure, we moved from being this disparate group to being one IT services, with faculty IT, reporting into the same structure as central IT, where I became a Senior Assistant Analyst. When we sat around the table for the first time and started ironing out the politics of who knew the most about what, we realized that we were all in different positions moving towards the Windows 7 rollout, but nobody had a good, cohesive solution for being able to deploy software. Certainly not “anywhere, anytime,” which is what our goal became.

So where we started was our desktop applications were managed independently by five different groups, so there was a lot of the same applications being accessed more than once. a lot of very different applications being needed in different areas, with the expertise all pocketed away in different places. That duplication and lack of reporting meant that our compliancy was probably embarrassing, had we been anywhere near an audit back in those days. And in terms of keeping our software up to date, we pretty much couldn’t during term time. The image was huge. My own image ran a good 80 applications at certain points, across the campus. So even on day 1, when students came back from their holiday, these were pretty slow machines. Even our new machines were pretty slow compared to what they could have been. So I think the challenges will be quite familiar to a lot of campuses. We looked like a big business but we don’t operate like a big business because we have thousands of people come at the beginning of an academic year, go to thousands of different PCs, rarely sitting in the same place twice, and then thousands of people leaving again at the end. So it’s a different kind of challenge in finding companies. When you need enterprise grade software that scales, finding companies that understand the unique challenges to universities is definitely something that should be valued.

Moving forward, we realized that application virtualization was the technology that offered the benefits that we needed. We needed to deploy across these different Windows work base services that we already had investment in. We needed a single point of management for license control and updates and we also needed on-demand deployments to labs where app usage was less known. So like I said, I had a good 80 in one particular open access lab and that meant that lab was pretty much substandard from day one. We needed that app to follow the user, rather than them all trying to be everywhere. So we went to market and we looked at the big players. We looked at Microsoft App-V, Alteris, Citrix XenApp, VMWare ThinApp, and Numecent and AppsAnywhere. Kind of got lucky; it was a flyer through the door at the right time, aiming this solution at education so we thought let’s give them a go. The timing was very good. The actual evaluation, we started off with the usual presale stuff and we very quickly had to rule out Citrix and VMWare ThinApp on cost and functionality. Citrix is a good solution but it’s an expensive solution and it’s almost overkill for what we wanted to do. VMWare ThinApp was the other way; it was being sold to us as a powerful plugin for VDI but outside of that world, its management potential is limited. We took Microsoft App-V, And Alteris, and Application Jukebox’s [AppsAnywhere] proof of concept, ran a three-month side-by-side test, packaging up applications, doing deployments, and so on. And it became very clear that the 100% claim that the Application Jukebox [AppsAnywhere] make, put it head and shoulders above the other products. So for example, Microsoft App-V, they’re very honest in their documentation. The version at the time, it was about 80% they would claim. And roughly the same for Alteris Client Management Suite, but if you had the full suite, you could sort of pull back to an integrated deployment. The App-V for us in the center may have got to 80%, but the engineering department was struggling to virtualize any of those heavy AutoCads, CHEMCADs, RTIS, and so on. So they immediately felt that they couldn’t work with that at all. But Application Jukebox [AppsAnywhere], we had the guys in, we had Tony in, and he showed us that these applications—CHEMCAD, for example—we had no method of deploying CHEMCAD. We used scripts that moved the mouse around and pressed, “Next.” I remember that well. And it went straight in without a hitch. The actual packaging, yes, some applications are more troublesome than others to get to play but it’s able to do it. That led to us thinking that’s the one that’s generations ahead, in terms of what they’re able to do.

Once we’ve chosen our technology, we went to a phased rollout of the service across the campus, starting with the PC labs, which is the most challenging environment, as Leon alluded to. We have about 1,500 PCs in open access labs across our faculties, and like I said, that included engineering, business areas, and the central areas that I look after. We did a project to move about 150 applications from our original app deployment into Application Jukebox [AppsAnywhere], across the summer of 2011. And at the same time, we in the center were completing our Windows 7 project, so it was a pretty big time. And we used the September of 2011 to rollout our new Windows 7 build, with Application Jukebox across the whole campus. We went through some fears at the time. The self-service portal is a powerful thing, but one of the things that we realized part in, is that when you’ve got tens of thousands of students, you don’t want them necessarily to be doing anything different to what they do on a traditional Windows PC. You want it to be totally familiar, because otherwise you’ve got to communicate those differences, and do training, and so on. We want this PC to look like their home PC. So the self-service portal, as good as it is, having to go to a different PC every day and then having to go to that portal for every application didn’t seem right. So we worked with AppsAnywhere and some of their colleagues, and we came up with the idea of doing shortcuts, using group policy extensions to machines, and that has worked incredibly well. So where we are, from September 2011, we managed to get 70% of the applications on day one, which included some of the big heavyweights. There were also some, with time being the constraint that it is, we decided that we would hold back and spend the time to get them just right. The 70%, within a couple of months across the summer, I think was a big achievement. But the bigger achievement was that lab that had 80 applications in it because anyone from anywhere could come and use it. I think it’s a 60 PC lab. That had Microsoft Office, Adobe Reader, some runtimes, and that was more or less it. Everything else in there looked like it was installed because it was a shortcut in the Start menu. So the student could go and look for it in exactly the same way that they would if it was installed on their own machine. But what actually happened was that shortcut did the same job as the portal, pulled that application down on demand, then it’s there for their session. But when they log off at the end of the day, there’s a cache keeping some files in the application locally, but otherwise, that next person gets that clean machine experience. Your big NVivos and so on, that ran SQL Server in the background and end up leaving some weight on the machine, it’s all just gone—it’s just files on the PC. But then if the next student needs it, again, it’s in the Start menu—traditional user experience. One of the compromises that this brought—and I’m not here to sell it so I’ll tell you what the compromises are as well—the compromises are that the summit applications will take a little time to actually virtualize on a machine. So what we did was we took it one at a time and if an application added more than 30 seconds to the start-up, that it would normally go if it was deployed ‘fat’. Then what we would probably do is deploy that application fat where it was taught, but we could use the shortcuts to make it available anywhere else. So the student could go pretty much anywhere on campus but we have managed machines and still use NVivo, or CHEMCAD, or whatever. And NVivo is one that we still deploy fat to the areas where it’s taught because it is used so much. We know where it is, we know how it’s being used, but we didn’t know whether people needed to take it anywhere else. We can put it out there and then we can use the reporting to find out how it is being used and where it is being used. And then you can get on to finding your licenses more intelligently and making savings there. The builds became streamlined and lightweight. The performance was better. We moved to being able to deploy software during term time. I used to be twice a year our academics could speak to us and ask for new software. Now it’s any time with a clear SLA and everybody knows what to expect. So our process has got a heck of a lot cleaner because we know our environment so much better. So we were able to control the actual life cycle of the software, not just the clever streaming technology.

Moving forward, once we had successfully launched our labs, we moved onto our staff supported PCs. The focus here was on the central machines, of which there are around 2,000. These include desktops and laptops; we have reasonable control over them. They are deployed with an SCCM-like infrastructure, so we can manage the build after we fight it out. But we also have that challenge of people operating off campus. There are laptops that sometimes never come back and all that good stuff. So we have combined Application Jukebox [AppsAnywhere] with our Windows 7 rollout to start and this time made use of that self-service portal because this time there are some clear goals to having staff be able to self-serve and get applications for themselves, without having to approach IT, wait for the ticketing system SLA, wait for us to assign a technician or an analyst to push that application, wait for the next maintenance window if it’s going to interrupt the smooth operation of the PC. They now go to a website called Surry Software, which I’ll show you shortly, and they’re able to—if they’re already licensed for it—that active directory authentication that they’re using here will list the applications that they’re able to run the license for already. If they can’t see the application they want, they press a button, fill out a form, and again we have, for the first time, a nice, clean process of checking the licensing, getting that application into a package that we can test and deploy, and send it back out to the user. One of the other nice things about that test and deploy element is I can actually test that package by sending it to the user, saying, “Is it okay?” Whereas a fat deployment, you don’t know what impact you’re going to have at the other end. There’s much more control over, “The right click didn’t work, I’ve missed a registry key, I’ve done something wrong,” I pull that application back, I check the package, I push it again. So we have signoffs for those applications because most of our techies, we might be experts in deploying Windows, deploying software, but we cannot know the software as much as the user does. They are the people that can sign off for us now. We can actually put it in their office and get them to check at their own leisure. So we get people on board, we can start moving away from needing to dish out admin rights quite as much, when people are away. It was a huge success and as you can see on the slide, we actually got to around 90% at launch and that wasn’t a technical stop at all. It was just that some of the applications we choose to have in the product build. With things like Adobe Reader, and so on, people don’t necessarily go to the application and then the file—the go to the file and then the application, so things like Adobe Reader, and so on, we have as part of the build of Microsoft Office and we can easily maintain those in other ways anyway. So at the present time—I’ve actually got 200+ applications there—it’s actually 300+ now, so we’ve got a rolling program of migrating stuff across. We have a clear methodology for patching. Patching is one of the best things as a Systems Admin that I’ve got out of this, so something big and cumbersome, like Adobe Acrobat Pro, I can package a patch update or a completely new version, or indeed if we weren’t licensed for anything anymore, I could actually pull that application without having to worry about the places it’s actually running 24 hours a lot of the time. Pushing out a patch can be pushed out automatically, and it can be accepted by the user, if you want to make it an option, or you can force it and every machine that has that application will get the patch. That’s been fantastic.

Eventually, the good stuff took until 2013, we saw the student self-service portal go. Here we decided that we would go it alone effectively, and forge ahead and develop our own portal. We had some guys who were very keen. We had identified some tricks and things about AppJ that we could use slightly differently and actually get to the point where we could stream our applications to unmanaged machines as comfortably as we could to managed machined. BYOD is bandied around as some modern buzzword all over the place. I find that universities have been doing it since day one. We have students and academics who turn up with their own machines, expecting to be able to turn up and use them. It’s not just the managed estate that’s nice and locked down, and visible to us. It’s much wider than that. And at the beginning of academic years, we would have queues around the building of people coming to activate their accounts, pick up CDs to install software. We would have to have our techies on full-time helping those people who didn’t know how to install the software, and all of that good stuff that you probably see at your own sites. And now we have no keys. They activate their accounts online as part of the welcome pack. Once they’ve got their account, they can then go to Surrey Software, and they can actually start pulling the applications they need for that course. What I would say is that if you’re on a home broadband connection, pulling down an entire MATLAB can take some time, but a lot of our students are in China, Brazil, across the world. It’s a lot quicker than their equivalent and they can be ready on day one, or at least not have to stand in a queue, waiting for CDs. Our administration of those students, at the help desk end, has plummeted. Less tickets, less queues, and so on. And again, when that student is no longer a student, it’s their account that goes and that will revoke the licensing terms, so I don’t have to physically worry about what’s going on. We’ve been running this portal since Easter, 2013. So just a quick summary before I actually show you some of it, this is where we are. We have a single management point for desktop application administration, we have a low impact and greatly improved update process, we have our self-service portal for both staff and students, and we have our detailed reporting so we can understand our estate.

Now you can see I’m not in sales because that’s a very basic presentation. I just want to show you a couple of things. This machine here is kind of a hybrid between our student machine and our staff machine, so what we do is—you can see there’s a lot of applications listed here, so this represents one of the labs that we’ve got. Most of these applications are just a shortcut, and on clicking a shortcut, it’s a traditional user experience. I actually fire up the Application Jukebox player, which is a client and is up and running. That’s streamed on demand and it’s actually not quite interesting to look at because it’s providing a standard user experience, but that’s a virtual application running on my PC, but it’s all contained within Application Jukebox player. And I can prove that by stopping it and you can see it’s gone. Then I can remove it and there’s no trace left once it’s done there. Just to note, one of the things that Application Jukebox does well is its integration into the operating system and the other applications, so plugins, dependencies, all those type of things can be taken care of. So for example, Endnote has a tab within Word. I didn’t have to do anything clever when I was packaging that in order to integrate those two applications. And your control, as a packager of the application, ranges from either being able to completely babble something away, either a whole application or part of it, or integrate it completely and make it behave like an installed app the way it is here. So that’s kind of how a student gets around. They use those shortcuts.

In staff land, we took the portal and we redeveloped it. And what AppsAnywhere are doing is developing a portal as part of their product but we’re one of their early customers and we forged ahead and did it ourselves. So this is what it looks like. We are able to search applications out and you get a list of results so you can quickly find the applications you want. And when you launch an application, you can bring up your mobile with the information and launch the application with one click that is then brought down. In this case, the license is paging the entire application so that I can take that away for offline use. All of our staff get to take applications away. The student ones are streamed on demand. It can take a little bit longer, but of course they’re up against calling IT, so it’s definitely a better experience. Skype is now fully integrated and will behave like an installed application, regardless of whether I’m taking it home on a laptop or not. But the administrator still has control. I can patch it, pull it, and so on, again, without worrying about where that computer happens to be.

The final thing to quickly show you about what happens on the back end. I should say that our portal includes things like geolocation. The challenge you have once you get to where we are, is actually licensing. We cast things like MATLAB and SPSS, which are licensed for the uses that we’re actually doing, so we can get them out to students. But there are a lot of publishers who are way behind the curve on this stuff and there are conversations to be had to show them we retain this control. It’s a better control than a fat application in that disks and installation sources can go wonky. You do find that some don’t support this method and conversations have to be had in order to get those breakthroughs. Last little bit, I just wanted to show the studio, just to show what it actually takes to get an application into this system. I’ve just got a very simple application, so you can use anything to create a template representative of the manage build with Application Jukebox Studio running on it. The actual act of packing is fairly familiar to a lot of people who do this on traditional platforms. You have a project section, you have a good way to ensure it’s a unique reference for your application. You give it a title and a description, both appear in the portal, so it’s worth maybe putting a bit more effort in than I did. You can restrict the operating system that the application is going to play well with. Generally, if they’re written for an operating system, then they will play well. It’s not AppJ [AppsAnywhere] putting in the restriction there, but it gives you a bit of control as an administrator. You create a project, just save that project, and I can get on with the action of capturing this application. So I’ve got my source bar on the desktop. There it is. So all I’m doing is running the installation and having the studio monitor it. It’s not monitoring the PC, it’s only going to monitor the installer process and any process that is kicked off by that installer. Most installers, the first thing they do is unpack. It’s going to ignore all those temporary files. But I, as an administrator, all I have to do is comb through and choose my configuration that I want to capture. If I want to do things like avoid having icons on the desktop, all of those preferences that I’m doing will be captured as part of the deployment package. So I have checked the desktop shortcut—that will not appear in the package. I tend not to want to launch an application, but I can capture a launch and then use that run to further customize my image. So you don’t have to get into that old XML file registry key hack, trying to make packages behave the way you want. You just go in and record yourself, effectively, customizing how you want the application to behave, turning off auto update, that sort of thing. After that, all you have to do is comb through, and you can see that certain of the standard Windows folders in the file section of the studio are picked up files and folders. You go through and you just sanity check that it has picked up the files and folders that it should. You can tell the player what the command line for the application is, the working folder and so on. So when you press that launch button on the portal, the application does what you want it to do. So we comb through the registry and there is noise occasionally picked up. It becomes quite familiar. In that case, it’s picked up pretty much the right stuff, although the restart folder has been written. I can just exclude that from this package and then should I exclude the wrong thing, I can just make sure that I put it back again. Within the studio, it natively will capture environment variables, fonts, starter items, and services and drivers. I can’t show you that today, but this went from—when we came on board—writing clever scripts to make sure those services and drivers were available, to AppsAnywhere working to integrate that capture into the studio natively. And then all I have to do is choose whether I want those to start up automatically, to fire immediately when the application streams, so you can avoid some reboots. All that kind of stuff. Very simple, very straightforward. Our experience of using it, 80% of applications will go straight in. It’s now my second screen habit whilst I’m doing my e-mails—it can be that easy. The challenging ones, there’s about 10%, 15%, maybe you’ll spend some time on it, tidying it up, making sure it virtualizes quickly, perhaps making sure the odd function does play the way you want. And then there are 5% where I go and ask AppsAnywhere for help. And as a customer, I can confidently say that AppsAnywhere have the skills to help us pick up the 5% where we need that extra bit of help.

So that’s really it, as far as we’re concerned. We’re a happy customer, we’re looking forward to our next versions, and we’re very proud of our portal.