Category Archives: Application Virtualisation

100,000 good reasons to virtualise those apps

A few years ago the IT department I work for set about revolutionising it’s software delivery methods using application virtualisation. As a University we were faced with the challenge of providing all applications to the staff and students on any PC- fighting the situation where “Package A is only available in the Engineering labs, Package B is only available in the Library” and so on.
The Legacy way of dealing with this was to provide ever-more-massive disk images, but this meant desktop computers were requiring larger and larger hard disks and were faced with longer and longer rebuild times. Added to this was the problem that the wide application portfolio would get out of date quicker and quicker as individual apps couldn’t be updated independently of that master image.
Using systems such as SCCM Software Centre to deploy apps on request to a slimmer Gold image was great in the traditional office setting where each computer has 1 user so can be setup with their apps. But imagine a student turning up to a lesson in a computer lab and having to wait 30 minutes or more whilst the package they need for that lesson is installed. An hour later a different student on a different course sits down at the same PC and needs different software so also has to wait. Doing the full-fat install in this manner doesn’t work when you have hundreds (or potentially thousands) of different users of a single PC.

Application Virtualisation

Along came Application Virtualisation- for us in the form of Numecent’s Application Jukebox product provided via Software2 (other suppliers and products are available). This meant that a Windows desktop could be quickly deployed as the image only contained a core of applications (Antivirus, Office etc). Additional applications could then be streamed directly from the central repository on demand- with all but the biggest packages the user could be up and running within seconds, rather than waiting for a whole application to be downloaded and installed. Applications could be updated individually and automatically deployed without the need for a rebuild operation. Additionally, just like a traditionally installed application, the virtualised apps work offline- once an app has streamed a laptop can be unplugged, taken home, and the user can continue to work.

Building the Portal

However, we did find a limitation. We wanted to take this a step beyond the computer-lab environment, we wanted to offer a portal whereby staff could install software on demand (and without the security risk of giving them admin rights) and even better students could install apps on their personal devices without collecting a CD from the helpdesk. Unfortunately the user-facing web interface which was included with AppJ at the time was very limited- basically just an unsortable, unsearchable, list of applications.
A team of us set about building a custom portal- building a new friendlier user interface and (after a bit of experimentation and reverse engineering) putting together the back end to use the Jukebox platform to deploy the selected apps.
Screenshot from Application PortalMidway through 2013 this new front-end went live and even though it was a soft launch an immediate following developed. Previously students wanting to BYOD had to visit the helpdesk where they could sign for and collect a CD of an application. They then had to manually install this themselves- child’s play for a computing student, but possibly a bit more of a challenge for someone studying a less technological discipline. Now anyone could login to the website from their home PC, click on their app of choice, and start using it seconds later. By the end of the year we had reached ten thousand applications deployed from the portal, and had some cake to celebrate.

Today

Fast forward to 2017 and The Application Jukebox platform is now developed into CloudPaging and thankfully customers no longer have to build their own front-end thanks to Software2’s S2Hub product .
Our custom portal is still running and we’ve passed a hundred-thousand applications installed from the site. That’s potentially 100,000 CDRs saved and presumably quite a few external-CD drives to install them on modern laptops. To put that into context that many CDs is about the same weight as a Stegosaurus!

Stegosaurus

The Stegosaurus. A legacy measurement of weight.

The portal has developed over time and now also includes links to Mac and Linux installers, and VDI connections to run Windows apps on other platforms – I’ve discussed integrating RemoteApp into a portal on this blog back in 2014 and we’ve even linked managed SCCM deployments into the same front end.

Conclusion

In our environment, with a massive app portfolio supporting subjects from Astrophysics to Zoology and an historically sizable appetite for BYOD, application virtualisation has been incredibly useful in answering the needs of a diverse user base both on the corporate managed platform and also the constantly changing variety of personal devices.
As a supplier of services our customers are now better served, and from an internal management perspective we have not only a much better understanding of the applications in use out there, but we have better, finer control over licenses.
If you are stuck deploying workstations with a legacy Gold Image which is getting unwieldy, I’d recommend having a look at Application Virtualisation.


Advert:

Deploying SCCM Applications via a custom web portal

My organisation has a user-facing application portal, distributing Application Jukebox and direct download apps from one central location. However, we use SCCM to distribute some applications and have been stuck in the unsatisfactory situation of having to direct users to two different sites depending on what application they want – “go to the normal portal for these apps, but Software Center for these ones”. Using the method described here we can include web links directly to the application in the SCCM catalog into our existing portal- the result, we can send our users to one place, regardless of the delivery method we have chosen for that specific application.

The solution involves a PowerShell script given below (and based on some work done here). We feed it the name of the application, and some details of our SCCM environment (the site code and the Application Catalog server) and it produces a URL. This URL can then be added to our existing web portal.

Example PowerShell

Example PowerShell to generate app URL

In this example the script (Get-SCCM-Link.ps1) is called with three arguments:

  • Application- this is the name of the application in the SCCM Catalog we want to generate a link for.
  • SiteCode- this is the sitecode of our SCCM site
  • AppCatalogServer- this is the server hosting  the SCCM Application Catalog

The result of running this script is a veeeery long URL. But that’s not a problem, as we’re going to place it in a web page rather than reading it out to a user over the ‘phone!

When a user clicks on the link they will be taken directly to the download page for that app in the SCCM Application Catalog as shown below. Then they just need to click “Install” and the app will be installed as normal- no need to send users to two different places or have them hunt through Software Center. The only caveat is that the application must be deployed to a User Collection of which the logged in user is a member- deploying to a Device Collection is not sufficient. But if your user can already see the app in the listing in the Application Catalog then you should be good to go.

Application Catalog

An example application in the SCCM web based catalog

Continue reading

Using RemoteApp to stream Application Jukebox packages

I’m currently working in an environment where we use the Application Jukebox architecture as an Application Virtualisation platform to package and stream software to our Windows estate.  Recently I have also been running a POC system based on Server 2012R2 to provide Windows Apps to our Macintosh users via RemoteApp.

The concept works, a Apple user running the Microsoft Remote Desktop client can stream an individual application to their Mac (or indeed to an iOS or Android device). However, we want to minimise the effort required from IT in provisioning these apps- we have over 300 Windows applications currently in use.

The solution was to use the existing Application Jukebox packages and make them available on the server and the method to do this is surprisingly simple.

First we install the Application Jukebox Player onto our Windows RemoteApp server. Then, using the same VBScript  used to create shortcuts in multi-user computer lab environments we create a batch file for each application we want to provision.

RemoteApp Properties in Server Manager

RemoteApp Properties in Server Manager

Once we have this batch file which will launch the application, this can be added to the list of RemoteApps in the normal way using Server Manager. When this is done, the packaged application appears in the normal way in the RemoteApp client interface alongside traditional applications, and can be launched on any device.

RemoteApp Resources Listing

RemoteApp Resources Listing

This whole process could be automated through a piece of PowerShell pulling the package information from the Jukebox database and then creating the batch files and provisioning the RemoteApp entries. But that’s a job for the new year……