Flexible remote access to applications at Durham University - Presentation

Thanks to AppsAnywhere and its integration with Cloudpaging and Parallels RAS, Durham University IT are transforming the student experience by securely deploying software to any device.

In this presentation, recorded at a recent AppsAnywhere User Day, Durham University's Jim Macura (former Project Manager) explains how IT are enabling flexible and remote access to applications across campus. And in doing so, meeting the expectations and needs of the 21st century student.

By using AppsAnywhere – and taking advantage of its integration with Cloudpaging [application virtualization] and Parallels RAS – Durham University are able to make Windows apps available on both Windows and non-Windows, with just one point of access regardless of device, user or location.

Flexible remote access to apps - Video transcription

So I’m Jim Macura, University of Durham and I’m a project manager there. So I’m not technical. We’ll talk about how we put a concept together of the project that we now call the Flexible Remote Access and how we came to be using Cloudpaging, AppsAnywhere, and Parallels RAS any degree at that. Like I said, I’m not technical. I will take questions anytime you have them but I might not be able to answer them. I do have a background in sales and consultancy, so obviously I'll try and bluff my way through any questions that you might have. But if needs be, I’ve got some technical colleagues at the back who might be able to give you a more convincing answer.

So just a bit of background first. Durham University, you’ve probably all heard about us, but we’re established 1832. We’ve got 3 faculties, 25 departments, 16 colleges, 9 research institutes. Around 17,500 students of undergrad and post grads. So that’s where we are, old university that’s spread around Durham.

So, what’s the background to this project? Well, back in 2013, we put together a quite extensive program of infrastructure and process of grades. Part of the covering what I’m going to talk about today but it encompassed everything about the entire state. The Network, the Core services which is creating two new [01:39] fully equipping them out which was done before we decide that we go cloud first as a policy. Identity management, End User, tools in collaboration and the Access project. The Access Project had a few facets but the one which is most important to us today is the project brief. And I put the project brief I had for that in its entirety in this slide. Deliver remote desktop/application system allowing users to access common applications not installed on their PC from locations on and off campus. And that was it. That was handed over to me and said, “Right, deal over that”.

For the first year or so, I ignored that because I was scared but what on earth am I going to do with that? But we did some other things as well, putting in a new VPA, [02:30]  from things like that. We spent a bit of time serving and interviewing staff and students to find out what were the issues that they had to deal with accessing the applications and getting work done? And there were some consistent themes that came out of that. They wanted consistency. They didn’t want things to change depending on what they were doing or where they were. They wanted simplicity of operation. Not everybody is an IT geek, and sometimes I think we forget that. And they  wanted the flexibility. Flexibility is my way of saying they demand what they want when they want it. So they want us to be flexible over their inflexible demands basically is what they’re after. We’ve all heard that before.

For us as an IT service, it needed to be cost-effective, it needed to be sustainable. So not something where we could just throw lots of money at from the budget and put it in but we have to be able to maintain that for a number of years. And naturally, it had to be secure. Funny enough, a lot of the users said it had to be secure. Don’t know why. I think you probably do but there you go. So that was where we started from.

So bearing in mind all along what I have in mind was the end goal which was the ability to access all these things remotely. But to get there, we have to look at where we started from, what we were starting from. What we were starting from was probably something you’ve all experienced yourselves. Multiple systems around the players, multiple applications spread in different places, and quite a degree of inflexibility. We have 2,500 student PCs in classrooms, in open access areas, and about 4,000 staff PCs, about 400 applications. That was a challenge, just counting the applications we had because they’re all over the place. Some were installed in some places, some weren’t. Different versions of applications were in different states across the PC systems. So we decided we needed to centralize and simplify that desktop environment. And for that, we selected Cloudpaging and AppsAnywhere as is now with the time but it was Application Jukebox and AppsAnywhere hub to try and keep our applications consistent and available from a single location, instead of being spread around everywhere.  So ease the management of the applications that we’re going to deliver in some way. We also selected AppSense to user environment manager. With both that we put it, I wouldn’t say that we’re using it at a great effect at the moment but it’s there and it’s something which will pick up when we’re maybe a little less busy.

And just to make sure that the technical team involved in doing this didn’t get too bored or interested, we thought we’d go off Windows 10 as well to make it a little bit more exciting.  And that was what we put together in the new desktop environment  which we launched out to the students in September 2016 and started this summer launching it out to the staff as well.

So we ended up in with an environment which was the basic foundation for where we wanted to be in terms of what we want to provide by going remote. So what do we mean by “remote”? What is remote? What do we mean by remote access? When you think about it, everything is remote access, isn’t it? Yeah? That’s what we’re used to doing today. We consider where we want to work, what is it we want to do, and how we want to do it. We ask those questions and we pause when we thought about it and realize that what we have today what I’d term the “connected society”. Everybody is used to being able to do what they want to do on their devices whenever they like. We’re all running around with laptops and smart phones and tablets. I’m guessing everybody in this room’s got at least one of those with them today, probably some have two or three of those devices today.  We’re used to doing it and we’re used to doing things on demand. And that’s what we needed to try and replicate and bring in to the university.

It was access to applications on demand. Don’t think about it being remote access. It’s just access to applications on demand. And that’s why we reduced the name of the overall project to just “access”. It became the Access Project because we’re giving people access to things regardless of wherever they are. What we don’t want to do is restrict people to be in a certain place to do something or to have to have a certain piece of equipment  to be able to do anything. What we want to do is enable people to access anything anywhere at any time using any kind of device. That was the end goal that we always had in mind to be able to do that.

So, we had to think about how do we get there and what do we make the solution for that? Well, first off, there was kind of an assumption amongst those who were involved in this project. They were going to go with VDI, and had quite a challenge, actually, during the life of the project to stop calling this or get people to stop calling this VDI Project. VDI has a specific connotation, Virtual Desktop Infrastructure. We did look at that but there was quite an overhead in doing that. We calculated around an extra 600,000 in a year just in licensing cost to run that VDI if we want to expand it out to all the students as well. But we’ve considered that VDI itself was too complex and too expensive to go with for what it was we wanted to do. We already had a significant investment in PCs and laptops. The processing power was already in people’s desks, what they want to do. VDI itself would have meant shifting all of that into the data center and for what purpose? People will still be running the same applications the same way. So try to find a way which will protect our investment and make it simple to maintain and so on.

So we focused on what it was we want to do and focused on accessing just those applications and we looked at the whole scenario, the devices that people were using, the environment, the operating system, the desktop if you like, who the users were, and what they want to do, and try to separate out the user from the application, from the device, and the operating system. Separate them out so they only come together at the point of views. And that’s why how we ended up with virtualizing the applications, really user environment management system, and being able to present that on any kind of devices people wanted to use.

That’s where Parallels came in. Parallels, to me, at the time was just something else I was working with. I was working on one of the aspects of the project was to be able to provide it with managing Macintoshes. Parallels offer a Macintosh management solution via CCM and so I’d been looking at what do we do in there. And while looking at that, they had this product called “Remote Access Server”. Got a Webex of that, get one to demonstrate to us, and to be honest, I was just absolutely astounded at how simple it was to set up and run the cost-effectiveness of it and the flexibility of it. The ease which was to maintain and manage and support it, although I don’t have to do that. I’m looking at you guys at the back there. But to me, it looked simple. It wasn’t just me, lots of other people looked at it and thought, “Yeah, that looked like the right solution for us”.

So then we had to bring it all together, make it work a bit better. We specified some key requirement s that the solution must have. It must support multiple device types, and that meant pretty much any device you can think of, Chromebooks, iPads, Macintoshes, laptops, Windows devices, anything. We had to access it through a single gateway, a single portal, a single place that anybody would go to to execute and access their applications.

Can’t expect users to make that decision for themselves based on where they currently are and what device they are using. One place for everything. That had to be context-sensitive. The user must go to one place only and it had to understand the context of the user on the network, off the network, what device type they’re using, who are you, what application do you like to have access to. All of that had to be built in so the user didn’t have to make those decisions and got more surprises when they came to use it.

Naturally, our security team said it had to be secure. We’ve done a little bit about that, talked about that just now. And it had to be flexible for the user and simple for them. One place only, go there, clock on this, consistent, answering the feedback that we’ve got in those initial surveys and interviews that we carried out. Everyone said, “Yeah, we can do that”. AppsAnywhere said, “Yeah, we can do that”. Parallel, “Yeah, we can do that”. But the [11:37] so we put a design workshop together.

We used Softcat to do that. Many of you will know Softcat, an IT services company. For us based in Manchester, we use in a number of other projects. The reason I use Softcat was to really drive the design for that. I didn’t have the resource to do that within the university. This had to be right. We had to get the design right up front and Softcat pulled together Parallels and AppsAnywhere and the university people to contribute towards that and put together an overall design for that. And the key integration on there was integrating apps anywhere with Parallels. AppsAnywhere was the front piece that was the portal that was going to do all the context-sensitivity and Parallels was going to drive and deliver the software on top of that.

And at the beginning of this year, I think it was, we put together an initial proof of concept working on developments which was kind of intuitive from both AppsAnywhere and from Parallels, and to make that work in a little proof of concept infrastructure that we built back at Durham to make that work. It took a while to get there but it just worked. When we saw it working, the simplicity of it was great and more than that, it just completely matched the vision I had right at the beginning. One poll for everything. Tony’s already mentioned, AppsAnywhere, AppsAnywhere think which now looks at the user environment and the context. It will deliver the application where it was likely installed, whether it’s from Macintosh, whether it could be streamed because it’s capable of doing that, and it just works. It just does it. And in fact, that demo that Tony showed this morning didn’t specifically show Parallels but it pretty much is what the Parallels and AppsAnywhere integration is all about. It just works like that.

I put together this conceptual diagram. It’s not a functional diagram. It’s not anything to do with how it works but it’s just reading from the concept of how the whole thing works is simply [13:52] end user is multiple devices, authenticates with the portal AppsAnywhere that determines who the user is, what he’s got, what he wants to do, and if necessary, it can stream through Cloudpaging and application to the device or runs the application on the device that the user’s got. If not, it will contact Parallels RAS and that will create the Cloudpaging session which will then deliver the application to a cluster of RDSH service which will execute the application and send the presentation of that back to the user on the device. And the only interaction, the only input from the user is that initial log-in to there and authenticate it. And everything else, just handled from there. It’s pretty seamless and it’s pretty performance.

I’ll tell you why I don’t know whether it is in real world or not just now. One of the requirements behind was for security but the security had to be simple as well. It had to be something which didn’t irritate the user. Now, in any one session, a user might access three, four, or more applications in any one session. What we didn’t want to happen was that every time they accessed an application, it would ask the user to re-authenticate. So we got them to settle so that AppsAnywhere would do the authentication and remembers and if necessary, resubmit it every time you need it to join a particular session. So user authenticates once and then is authenticated for the session. You could call it single sign-on.

Some application, we specify as being secure or more secure than the standard applications. Those applications require two factor authentication and again, AppsAnywhere does that for us. So it will carry out the authentication, remember it and deliver it after the first time it’s been used. So you can either authenticate when you start. So you can either authenticate when you start with the session and go initially into the portal, they’ll remember it, or if you select an application that requires two factor authentication. AppsAnywhere will click the credentials, use them for application. If you then run another application, it will automatically authenticate you on there. Simplicity and consistency and doesn’t irritate the user too much.

So that was where we came from and this is where we are now. We still haven’t got it installed in a live environment and it has nothing to do with Parallels and nothing to do with AppsAnywhere. It’s more to do with us. We’ve had a few resource problems in the last couple months or so. We’re also kind of a brand new environment. I mentioned this part of this program. We built new data centers, a new network, new firewalls, and few little problems just getting used to all of that and work together.

We have to specify an environment which are resilient. So we [16:49] on the Parallels gateways and publishing agents. Each one of those are sitting on virtual service in two different data centers. Started off with a cluster of 12 RDSH service which are split between the two data centers. We’re going for a license for about 500 users. I think it is for Parallels initially 500 concurrent users.

I’m that far away from making it live. We almost got it completed this week but not quite. Parallels have done their bit. We’re now just waiting for the last bit, for Ryan to get back in the office and do his bit. And then I’ve got a cluster of users I’m going to use with testing through December potentially if not too busy with Christmas lunches and things, and then we’ll launch it to the users in January. But it’s taken us probably – it’s taken me probably two-and-a-half to three years to get where I am today, from the initial vision that we had right at the beginning. And I just want to say a big thank you to AppsAnywhere and Parallels and Softcat for making this work, putting it all together, understanding where we’re trying to be, and for them to make it work for us. So thank you very much, guys.