App-V 5 is in the loop and this time around Microsoft has greatly revamped the architecture on how the virtualization part of App-V will be implemented. However, inorder to understand the tremendous advantage we will have with the new architecture – lets look at previous problems of Application Virtualization.
Softgrid and what became Microsoft Application VIrtualization was a great product that made deploying applications very simple and removed a large portion of why application deployments were scary. As opposed to deploying an application in its traditional sense – melting it together with the operating system and all its other application – we gained the possibility of providing a virtualized layer on top of the operating system. This layer provided two main components which removed the threat of breaking other applications or the operating system – virtualization and isolation. By allowing only a specific agent (aka sfttray) to spin up the virtual environment we created a nice line of defense that would ensure our computers integrity and allow the application to utilize local system resources.
The downside of the coin was that if only a single agent could access our virtual environment – we have also isolated the resources within that virtual environment and any type of call into that environment need to pass through our single guardian. The main problem with this was that sfttray (our guard) only allowed certain things to pass through by default, and as Windows and applications came up with new ways of integrating with applications – those “defaults” soon became to few and eventually altered the user experience of an application. For quite some time there haven’t been any technical limitation to virtualize just about any application, but the client that was delivering those applications proved to be very limited in allowing users to interact with the applications seamlessly. Sfttray supported file type associations and shortcuts. Simply not good enough if you are supporting todays demanding end-users.
App-V 5 will change this paradigm and provide an architecture that can ensure future abilities will be extended with much less effort – if any effort is necessary. As opposed to passing through a guard – we will not be limited to accessing it via an agent instead we can now gain access directly and only virtualizing it. Sfttray is history – and so is the Q: – drive. Lets poke around at a virtual application to understand why this architecture makes such a difference.
Meet the shortcut. A shortcut was supported in App-V 4, however the command-line in the shortcut always referenced sfttray.exe and then invoking your virtual application. Say hello to App-V 5 type of shortcut;
As you can see – we are now directly calling vlc.exe. It seems to be placed directly onto our filesystem – infact it is!
Directly under C:\Programdata – our packages are now placed in the native filesystem. As you can see we also have another improvement which is not even mentioned – the previous requirement of a unique 8.3-compliant name is gone. Instead all packages are executed under their unique (very long) GUID – to allow us to focus more on application packaging and less on naming conventions.
App-V 4 also supported file type associations – which are still there. With an improved experience!
This is a wmv-file – associated to our virtualized instance of App-V. Lets say we want to set another file type to be associated with our virtualized VLC. Previously we had to go through sfttray – but that’s gone…
VLC is now presented as any other program. Previously we had to retrain our users to select sfttray (here also presented as we allow the App-V 4.6 SP2 and App-V 5 to co-exist on the same system) and then select their program. Now – a native experience is given to the end-user and they can select the application that they want start a file type association with.
This all seems great that the experience with existing extensions (anyone who has been forced to listen to me knows that I call these entry points – but from now on I will favor extensions) – lets see what new stuff is out there. Right-clicking a file type will bring context-menus;
If the user is more familiar with altering a file type association through the Default Programs from within the Control Panel – VLC will also be presented here as a regular application;
We can see all the file type associations that our virtualized VLC currently is set to be the default application to handle;
However, if we insert a DVD – that’s not a file-type association is it? Well – how external media (DVDs for example) are started or at least what options are presented to the end-user is defined from Autoplay in the Control Panel. Yet again – we can see the virtualized VLC showing up as the end-user would expect it to;
All of these interactions were previously not available (still possible through manual labor and tweaking in the registry) – now we get them out of the box from a virtualized application! To move further – Spotify will be used to demonstrate even more interaction! When creating a package – a couple of files are created. The content is .appv, the installer in a standalone mode is the .msi – but we also have two configuration files – named Deployment and User config. If reviewing Deployment-config for our Spotify package – we can see the following;
This looks awesome – as Spotify has its own protocol handler which allows users to click a link and directly open a playlist within Spotify.
This are all visible extensions for the end-user and will make the gap of the experience between a virtual application and a natively installed application even smaller. However, the App-V team didn’t stop here and made even more possible extensions beyond of what we were expecting.
There are two methods that are used under the hood of everything – that provides a greater interaction between applications and allows for seamless exchange of data between applications. Quite often – we admins had to find out the hard way that this “report” for application X actually depend on beeing able to locate Excel, Adobe Acrobat or some other program. Many ways are used to send to the proper data to this “other” program – quite a few articles to resolve problems regarding this inter-application communication problems are written by me personally and even more questions are asked in the forums. We know about them – but what are they really?
AppPaths are one way – its an easy way to locate a needed .EXE if the application has registered itself. If reading the article – it allows for quite a few different ways to use this feature, however – we most commonly deal with it because a program calls an application (say excel.exe) by simply asking for excel.exe – and not a full path. When registered properly – apppaths will allow us to start our specific version that we currently have installed. Filling in the full-path to the executable in question.
If our application is virtualized (excel.exe for example) – it will not be registered at all and the main application will simply state that you need this application installed. Fortunately – App-V 5 will now allow applications to register themselves properly and there be found by any application (virtualized or not) requesting them!
The other alternative are is COM. COM has been around since 1993. COM is something that has been and still is beyond me. Usually – when you realize that an obscure error message is given when the program attempts to send data to an external program COM is related. Wikipedia has a great article which clarifies it to some extent in what ways we are dealing with COM. OLE, OLE Automation, ActiveX, COM+ and DCOM are the more commonly used words.
Here is an example of a COM that was detected by the sequencer;
Wow – so we have just learned that App-V 5 will bring in many new ways that will improve the application experience and make previous scenarios that seemed impossible suddenly appear simple and work right out of the box.
Interesting post. Thank you, Nicke!