When, where and how to use Microsoft 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?
Microsoft 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!
Not 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

Once 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
On 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… 
In the previous section, I have often mentioned the installation process, which was eliminated in virtual applications. On this character
istic 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 …
App-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.

Announced on MDOP blog  – Microsoft Application Virtualization 4.6, including App-V for RDS, is now publicly available as part of MDOP 2010. You can download MDOP 2010 via Microsoft Volume Licensing Site. As I wrote before App-V brings following new features:

• App-V 4.6 is now compatible with 64-bit Windows client and server platforms
• App-V 4.6 saves on SAN storage space by using a cache of virtualized applications that is shared across all your VDI desktops
• App-V 4.6 and SCCM 2007 R2 SP2 now deliver virtual applications faster
• More.

Today many companies implemented some version of Sharepoint as their internal document management system and overall document repository system. Sharepoint is great and easy to use, and companies can really benefit of Sharepoint’s use, so in some point they decided to use sharepoint site for various kind of documents. That’s really great, and everything work fine for those kind of documents if users have Office installed locally. They simply open Internet explorer, type sharepoint url and click on document they need. Of course, because everything is installed localy, when user click on, for example, xml document it is automaticly opened with Microsoft Office Infopath. Same rule applies to Word documents. But what when users are using virtualized version of Office applications? Well then the thing get little more complicated. When Office is virtualized with Microsoft Application Virtualization and then streamed to a client, every file association is discovered properly, so with virtualized Word, users normaly open .doc or .docx documents if these documents are placed somewhere on users disk. But if those documents are placed on Sharepoint site, then when user click on xml or .docx document,  SharePoint is looking for ProgID’s “Sharepoint.OpenDocuments.*” which are not part of file association, but are part of SharePoint COM objects. So when you try to open those documents with virtualized Infopath or Word you will get error that you don’t have appropriate application for opening documents, or something similar. But luckily things can be fixed.

How can this be fixed?

So if you have Sharepoint site and virtualized Office(Infopath or Word), you should do the following:

1. Sequence Infopath (Word) by best practices, but then in shortcut phase of sequencing include shortcut to Internet Explorer (It is easy, on application phase just click Add new application and then browse to executable of local Internet Explorer.)
2. Install Sharepoint services support from the Office CD. You can find this by normally installing Office and then in Office Tools subtree only check on Sharepoint services support.

If you do all that, opening document from sharepoint site should normally work.

One day I was doing demo of all six MDOP products, and 5 minutes after demo my Hyper-V virtual machine suddenly paused and my screen froze. What’s the deal with that, I was asking myself? So if something similar happened to you, and you were asking yourself the same question, the answer lies within low disk space. Anyway free space on hard disk for your virtual machine must not be lower than 200 mb, and if it does your virtual machine goes into PAUSED CRITICAL state. So if you have important presentation and demo, check your free space, and check it after you start virtual machine.

Especially if you plan to demo application virtualization, and one of demo scenarios is installing and virtualizing big applications. Then your vhd file could become bigger and you could run out of free space. And you don’t want that happen to you during demo.

Application Virtualization is getting more popular every day. Popularity means that a lot of people are using it, so they are trying to be more and more productive, and for that use, they develop some cool and useful tools. Here I  will mention few great tools developed by Login Consultants. All tools are completely free, you just need to register or login. After you login, there are five App-V tools available for download:

• App-V (Softgrid) Client Setup Kit

By using this tool you can easily create vb scripts for deploying App-V client to end user dekstop.

•  App-V Migration Tool 1.1.1

With this tool you can convert your automated applications setups to App-V Virtualized Applications, with little amount of user intervention.

•  App-V OSD Editor- As the name of this tool says, you can edit OSD files more easily. This can be extremely useful because in editing OSD files you can easily make mistake and then forget where the mistake is.
• App-V Add-on ADM v1.0  - The tool for configuring client settings for App-V for Windows Desktop Client.
• App-V Client Diagnostic and Configuration Tool

Really great and useful tool for getting the right diagnose out of your virtual applications.

With all of these tools in your ‘hands’ you can really solve your App-V problems more faster and easier. In my future blogs I will explain all of these tools with more details.

Cheers!