Home > App-V > Application Virtualization (App-V) – Use Case Scenarios

Application Virtualization (App-V) – Use Case Scenarios

When, where and how to use Microsoft Application Virtualization

Scenarios of using Application Virtualization

Virtualization of applications in recent years is slowly but surely being used more and more often, but still  I can not say that it is generally accepted technology such as server virtualization. The first step towards a general acceptance of application virtualization is certainly a  good awareness of  possible implementation scenarios and the various benefits that technology brings.



What is application virtualization?
Virtual applicationMicrosoft Application Virtualization (App-V) is one of application virtualization solutions on which you probably ran into somewhere.  However, it is better to briefly summarize the theoretical aspects so that the usability of technology can also be clarified. So, application virtualization brings a new approach to interaction of applications and operating system. Namely, with standard approach we are aware that we first need to install application on OS to make it work. Also we know that applications are closely related to the operating system on which they are installed (e.g. a lot of registry entries, dll files etc…). If you ignore all those standard application lifecycle behavior  (installation, maintenance, uninstall), then you’d get a lot more dynamic applications and more manageable applications. In simple words, when using App-V Solution applications are turning into services that are available on request. Most applications today can be converted into virtual which brings many new application scenarios.

No more installation!
No installationNot so long ago to install some applications we needed to bring a dozen diskettes and bunch of patience. And then (as we are lucky bastards) on tenth diskette we run into some kind of a read error. That was frustrating in many ways!  Through the years the process has changed in the sense that we do not need so many floppy disks, but still applications "require" to be installed by following specific installation procedure. With App-V, application installation process is gone. Once created, the virtual application package is placed on the central server and deployed to users on request. There are of course many other systems for application deployment (SCCM…), but what with applications that do not have the installation procedure? They can also be packaged using App-V solution. Examples are in-house developed applications that do not have a standard installation procedure, but they must be installed and configured separately and manually on each computer.  For example if you configure application settings (e.g. strings to database, view settings and many others) during packaging phase (App-v Sequencing) those settings will be applied on every application when distributed to clients.


Simple application upgrade

Application upgradeOnce installed applications eventually need to be upgraded,  and that can be a tedious job because of computer restarts, errors etc… Virtual applications behave differently. Namely, when applications are placed on a central server, you need to make just one virtual package update on the server and all applications on clients will be upgraded to the latest version or patch. In addition, users will experience no interruption in work. Users can use application at the same time when system administrator wants to set a new upgrade. The next time the user runs the same application it will be upgraded (no restart, no interruptions, no errors, no update procedure). Ok, let’s  briefly switch to the central App-V Server and its relationship with the client computers. Unlike the standard push principle deployment of applications (with SCCM or other ESD solutions), App-V Server uses the pull approach where client computers literally pull a package by package (using SMB, HTTP, or RTSP protocol) until the virtual application is successfully  running. After that entire application is cached on client side (if so configured)  you no longer need a connection to server. That is one of many misunderstandings when it comes to virtual applications. Namely, a lot of users thinks that they need to be constantly connected to central App-V server (Application Virtualization Management Server).

Portable virtual applications
Portable applicationsOn the other hand, if there are no possibilities of using App-V server, applications can be deployed simply using  shared folder on a server or using portable USB drive. One of the characteristics of virtual application here imposes itself – portability of applications. We can say that the virtual application can be transferred from one computer to another using just USB. Of course APP-V client is required on computer for those virtual applications. Without App-V client installed on computer you can not run any App-V virtual applications.

Isolation (Sandbox), virtual plugins… 
Hy there I'm isolated virtual appIn the previous section, I have often mentioned the installation process, which was eliminated in virtual applications. On this characteristic is based on one of the biggest advantages of virtual applications. Specifically, each virtual application is running in so-called isolated environment – Sandbox. When running in sandbox, virtual applications are not in conflict. Today is not uncommon on a single computer that at the same time there are hundred applications, which often causes conflict between them. In such scenarios, there are two possible solutions; simply stop using the conflicting application or implementation of App-V solution. Certainly the latter case is better solution because it does not require much investment in new infrastructure and you  can keep all applications. In addition, it is possible to use application virtualization in scenarios when  having multiple versions of the same application, which is a common need in cases of testing or adaptation of new versions. For example, you can simultaneously on one computer run Office 2007 and Office 2010 (or other combinations).
On the other hand it is possible to integrate"normally" installed applications with virtual plugins. Wondering what is the benefit of this scenario?  Take for example a company with 100 employees who on a daily basis run web applications that use Java version 6, and on the other hand couple of users or departments use applications that do not work normally with specified version of Java.  In this case there is a problem because  upon installing Java update a previous version of Java is replaced and some older web applications does not work.  With the help of App-V solution on the same computer different versions of Java (or any other plugin) can be used simultaneously. Clearly, in this case, these plugins are virtualized.. The same goes for any other applications and plug-ins.
When mentioning conflict of applications, then  probably most affected are terminal servers. Specifically, on terminal server there are bunch of applications which users run using Remote desktop protocol. So all applications are actually executed on terminal server while users only see presentation layer of application. As servers are now quite powerful, it is clear that Terminal Server can run hundreds of application simultaneously. But that is often not the case because a  lot of applications are in conflict. In those scenarios companies implement so called Terminal Server Farms. By doing that, a lot of servers are underutilized and that’s exactly what we want to avoid by using virtualization.  App-V can save the day in that case. Specifically when using App-V on Terminal Server, you can run as many applications as you want, because they are not in conflict – they are in sandbox. So if applications can run on terminal server, they can be served to users using TS (RDS) Remote App etc.

64 bits, VDI, shared cache …
Banner_vApp-V solution tightly integrates with Active Directory so that the applications are only delivered to those users that are entitled to use applications. So administrator defines security group in Active Directory and defines users which should receive the application on their desktop. Once the user logs on to a computer (with domain user and pass),he will see all virtual applications instantly. But keep in mind that virtual applications are not tied to computer meaning that user will see his applications on every computer on which he log on (Roaming).  This scenario is particularly suited for call centers and in general for situations where employees do not use the same computer every day. Scenario can be further extended to remote users, who can use the application wherever they are.
Tight integration of App-V solution with Active Directory has a beneficial effect on the OS deployment process, and generally process of  creating the OS image. By default, companies are creating fat OS images with a lot of preinstalled applications so that every department is covered with all applications. This increases the size of the OS image, and users often have applications which they do not use. On the other hand, if using App-V, OS image can be “clean” with maybe just a few preinstalled applications, while other users receive virtual applications as soon as they firs log on to domain.
Deployment of the new OS is particularly interesting topic at a time when most people still use Windows XP and have  good intention to switch to Windows 7. Since version App-V 4.5 SP1 virtual applications are officially supported on Windows 7. In addition, this year version 4.6 was released with  support for 64 bit platform. The new version also comes with  a little-known possibility of shared cache , which is particularly useful in Virtual Desktop Infrastructure (VDI) solutions. In VDI solutions virtual machines are located in data centers and users access them from their computer, or using thin clients. Of course, users will access these virtual machines to use certain applications. If those applications are installed separately on each virtual machine, then the capacity of these virtual machines occupy a fairly large amount of storage. Take for example that the average virtual machine user have about 20 applications with a total capacity of 10 GB. For 100 users,in this case it is necessary to book 1000 GB of disk space only for applications. Using App-V shared cache all applications doesn’t have to be placed in each virtual machine individually. Instead applications can be placed on shared storage. So all virtual machines will use the same shared cache of virtual applications (10GB), meaning that you could potentially save 90% or more of storage space.

Finally, it is easy to conclude that with the use of virtual applications many new application scenarios appear and virtual applications bring many benefits. According to research, the use of virtual applications significantly reduces the time required for deployment, reducing the number of help desk calls and generally reducing the costs associated with maintaining applications. But of course, with each technology and therefore with App-V there are some risks and limitations. Some applications can not be virtualized, some do not behave well in a virtual environment, but for all other applications I must say that it is really very beneficial to use App-V and by doing that take one step closer to real dynamic desktop.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: