Application Virtualization

Home

Sitemap

Call Us

What is Application Virtualization (App-V)?

The idea behind application virtualization is a simple one: you run an application on your desktop without ever having installed it. Unlike using Terminal Services, this application executes locally, using local resources (e.g., processor, memory, disk, and network card). In other words, the application runs, saves data, prints, and acts as if it’s installed locally even though it is not.

Besides this, you can run multiple versions of the same application on your desktop without conflict—again, with all the applications executing locally – and not as “screen scrapes” from a remote terminal server.

Let’s clarify things a bit with a simple visualization. The image below shows the basic concepts of application virtualization—the application executes on the local machine using its resources, but is not allowed to modify anything. Instead, it runs in a small virtual environment that contains the registry entries, files, COM objects, and other components that it needs to execute. This virtual environment acts as a layer between the application and the OS. The virtual layer is very “light” (generally only a couple megabytes of memory) and loads just prior to the application loading.

This means it is now possible to deploy desktop PC’s with little more than an operating system and use the App-V system as a mechanism to manage and deploy software across your organizations

What does application virtualization do for you?

From a technology standpoint, the idea of virtualizing an application is certainly intriguing. But the real test for the long-term success of any technology is: “Will this benefit me or improve my existing environment? If so,how?”
Application Virtualization works by solving a particular set of problems for an organization. How it benefits you and improves your environment depends on the answers to a few questions:

Do you currently suffer from any of the following application deployment challenges:
Intolerably long time to deploy applications to the desktop
Complexity of application packaging
Lack of a means to monitor application license compliance
Frequently changing applications
Do you have applications that conflict with one another but must be run simultaneously?
Is your helpdesk staff required to “fix” applications on a regular basis due to user changes or
modifications by other programs?
Does your organization spend a large amount of time regression testing new applications or application updates?
Is there a need to run multiple versions of the same application (such as Microsoft Access or other Office components)?
Do you have a terminal server environment with multiple application silos as a result of application
configurations or conflicts?
Do you have any applications that just will not run in a terminal server environment?
If you are not facing any of these issues, then App-V may be a product that would not significantly benefit you or your environment. As such, we can assume that your environment has the following attributes:
Small/limited application portfolio
No application conflicts
Limited application changes or updates
No need to monitor for license compliance
No need for application roll-back after an installation
No need for application updates
Applications are not packaged, or packaging is a simple process
No terminal servers or Citrix, or only a very small terminal server environment with limited applications
and no application silos.

If that describes your environment, then consider yourself fortunate! If not, then the App-V technology may be your best when it comes to virtualizing your applications. But what exactly is this?

Virtual applications, not virtual machines (or operating systems)

A virtual machine is a great tool for virtualizing the machine on which you are installing an operating system (and applications). Think of it this way: a virtual machine provides an abstraction layer between your hardware and the operating system that’s running on top of it. It also allows you to manage and simultaneously operate multiple environments on a single machine. The power of machine virtualization is that you can consolidate servers and PCs, sharing under-utilized hardware resources and reducing the total cost of ownership when it comes to hardware purchasing, monitoring, management and maintenance.

App-V takes this concept and moves it up the logical stack. In fact, it is complementary to virtual machines many customers use both. The abstraction layer created by App-V lies between the operating system and the applications that run within it. By virtualizing all the aspects of an application, you don’t affect the operating system or other applications running on that machine.

App-V changes how the operating system perceives applications whose very installation and execution can reduce the stability of the operating system and other applications. The power of App-V is that it allows applications to be delivered dynamically as services that can be added or removed without leaving a trail on the client system. This in turn reduces the total cost of deploying and maintaining applications and systems.

How do applications get to the desktop?

Now that we know where the applications run and that there are real benefits to this technology, the question becomes: “How does the application package get to the desktop if the package isn’t installed?”

To state it simply, we could say that it runs out of a cache on the local machine. This cache is populated from a App-V Management Server that maintains the application packages. Once the application is cached, the App-V Client virtualizes the file system, registry, and other application elements and loads the application out of cache and into the virtual environment. Of course, there’s still the question of how the application gets into the cache in the first place. To visualize this, we’ve created a diagram (below) that shows the paths the data traverses prior to an application launch.

There are several components in this system. The two components we’re concerned with are the App-V Management Server and the App-V Client

The App-V Management Server maintains the application packages and streams them to the client’s cache. The word “stream” means that this is not a flat file transfer of the package. Initially, only portions of the application are sent to the client so that the user can launch the application. Once the application is launched, the remaining segments of the package are sent to the cache as the user runs the application and accesses functions that are not already cached. The transfer of the package is done via an RTP stream between the client and the server.

The on-demand delivery of applications is a very efficient way to deploy and manage applications. The first parts of the package that are sent to the client are the minimum pieces the application requires to launch (about 10-30% of the application on average). In this way, the application executes without the user having to wait for the entire application package to be transferred to the client.

Once these pieces are in place (generally 5-15 seconds on first launch) the application will open and be ready for use. Subsequent launches will not require these components to be re-streamed, because they are now cached on the client, therefore launch time is similar to the installed case.

Before we go further, we should mention that it is possible to automatically pre-cache an entire application on a user’s machine without having to go through the process of streaming the first time.

The App-V system is permission-based and uses Active Directory (and other directory services) as its account authority. This means that every time a user tries to run an application (whether for the 1st or 101st time), the system will check AD to ensure that the user is authorized. In addition, the system can be configured to perform audit-based license tracking or strict license enforcement. For example, an administrator can assign a concurrent license to an application so that no more than 20 users can run the application simultaneously. In this case, a 21st concurrent user will receive a message stating there are no more licenses available.

What App-V Does and Does Not Do

What it Does	What it doesn’t do
Applications Fonts Appication registry Settings Application file system changes services Runtime objects MDAC Versions Java virtual machines Common program files Database drivers Mobile mode	Drivers OS Hotfixes Antivirus Software

What Do You Need to Make This Work?

The basic components required for App-V are fairly simple, regardless of how large or small your environment is. Like anything else, though, as the environment scales and fault tolerance becomes a requirement (rather than a “nice-to-have”), the design can become more complex.
To get a basic system up and running requires seven components:

App-V Sequencer (discuss this component in App-V Sequencing section).
App-V Content Share maintain the packages.
App-V Data Store to maintain application information.
App-V Management Console.
App-V Management Server.
An authoritative source for accounts (Active Directory or NT domain).
App-V Clients (App-V for Desktops, App-V for Terminal Services).