Augusto Alvarez

Implementing App-V – Part I: Introduction to Application Virtualization

May 26, 2009 at 1:31 am | Posted in App-V, Virtualization | 8 Comments
Tags: App-V, application virtualization, Virtualization

 

Other posts in this series:

Implementing App-V – Part II: Choosing and Preparing the Environment

Implementing App-V – Part III: Integrating Clients

Implementing App-V – Part IV: Sequencing Applications

Virtualizing applications it is not a very common requirement for most administrators or companies. These solutions doesn’t seem like a “must” in any given environment, but why? One of the main reasons it’s related to the benefit/cost equation it’s not quite clear for most of us.

With these posts I’ll try to give a small introduction to the technology, explain the environment, provide a step-by-step deployment for App-V and the benefits that could apply to your organization.

What is Application Virtualization?

Application virtualization represents the technologies that permits to remove the complexity of deploying and maintaining applications for desktop users by providing:

• Applications centralized management. Facilitates the process of deploying, updating and removing applications. 
• Removing potential conflicts on desktop clients. Each application deployed using this type of technology runs in a isolated environment.
• Capability to capture a set of interconnected applications into a single package to be distributed among clients.

Common Scenarios

Let me give you a few common scenarios where application virtualization applies:

Scenario A

Problem: You are using a company’s application that requires some special configurations every time that is deployed, and that is also interconnected with other applications (for example: A local database engine, Java Runtime Environment or some other particular requirement). It demands you several hours every week to support end-users for deploying or troubleshooting configurations.

Solution: Providing application virtualization you can guarantee end-users to always have the same configuration deployed, no matter when or where; since you only need to configure it once and then wrap up the entire set of applications into one package.

Scenario B

Problem: You have a dynamic base operating system image that changes constantly, there are several type of base images according to the users, and you not have deployed Microsoft Deployment Toolkit (MDT) combined with System Center Configuration Manager (SCCM) to maintain images. You have two options: Manually and locally change the desktop image on every client by installing or removing applications; or providing end-users with local administrator privileges to achieve some kind of auto-management (don’t get me started on that).

Solution: Implement application virtualization with a clean base image will help you to minimize the impact every time there’s a change. With a centralized management of the applications you can make all the necessary changes and implement those instantly. Adding also granularity on the type of images, special applications can only be distributed to selected group of users.

Did you read the scenario problems and feel like “been there, done that”? Then you definitely should continue reading these posts.

Existing Platforms

There are several platforms provided to achieve application virtualization, the most common are:

• Microsoft Application Virtualization (App-V). Formerly known as SoftGrid.
• VMWare ThinApp.
• Citrix XenApp.
• Symantec Software Virtualization Solutions (SVS).

To name a few differences among them:

• ThinApp is the only one that supports 64 bits OS deployments.
• App-V, SVS and XenApp use a set of kernel mode drivers and supporting services to manage virtualization process. ThinApp includes the entire virtual environment directly into the application package.

This set of posts will be focused on reviewing the components and process within an App-V environment. As well as providing an step by step deployment.

App-V Components

App-V is the solution provided by Microsoft to achieve a secure, scalable and high performing applications deployment. Here’s a quick review about which components are involved.

App-V Management Server

In charge of delivering sequenced applications on-demand to selected clients. Any Management Server needs a SQL data store (multiple Management Servers can access the same data store) where it retrieves information like application assignments, records and permissions within the App-V management environment.

App-V Management System

Composed by the App-V Management Console and the App-V Management Service. It represents the communication channel between the MMC and the SQL data store, controlling any read/write requests to the database. It can be installed together with the Management Server or in a separate computer with IIS.

App-V Sequencer

In charge of producing the application package. It is basically a tool installed on a computer (preferred using the same OS as App-V clients) that captures the installation of the applications to generate the package, that consists in several files: Open Software Description (.osd file that links other files); sequenced application file (.sft file); icon files (.ico); XML manifest and a project file (.sprj). Optionally an MSI file can be included for offline deployments, but we’ll see how to do that later.

App-V Streaming Server

This server will have a the role of streaming applications to the clients where these do not have an acceptable connection to the Management Server, like a branch office. Streaming applications is the only functionality enabled for this server, and it represents, on most cases, as an optional role to be installed.

App-V Client

Installed on the end-user operating system, interacts with the App-V Server. Manages package streaming into cache and publishing refresh. Stores user-specific information related to the virtual applications in each user profile, so every time the client reboots the machine, the virtualized applications conserves last changes made. This client it is also represented with “Terminal Services” version, the only obvious reason is that the applications are published using Terminal Services virtual desktop.

Here’s a graphical description of the entire App-V environment

Resources

Here are some of the recommended resources you can find about the technology

• Application Virtualization 4.5 Documentation
• Microsoft Desktop Optimization Pack Home Page
• Microsoft Application Virtualization 4.5 Resource Kit Tools
• App-V Team Blog
• Planning and Deployment Guide for the Application Virtualization System

On the next posts I’ll use more practical examples and show you how to deploy an entire environment for virtualizing application. Stay tuned.

Other posts in this series:

Implementing App-V – Part II: Choosing and Preparing the Environment

Implementing App-V – Part III: Integrating Clients

Implementing App-V – Part IV: Sequencing Applications

Cheers!