Page 0

Solving the Inherent Problems with the Personal Computer

To Install or Not Install

Part II Revision 2 Written by:

Douglas A. Brown President & Chief Technology Officer DABCC, Inc. www.dabcc.com

Page 1

Solving the Inherent Problems with the Personal Computer

“To Install or Not Install”

Solving the Application Management Nightmare

Part II

Welcome to part II of; “Solving the Inherent Problems with the Personal Computer”, an ongoing

series of papers discussing the problems facing IT. At the conclusion of this series, my objective

is to outline a complete solution, not a bunch of workarounds.

To date, the series includes the following papers:

• Preface……The Reality of the Situation (Assumptions and Facts) – coming soon

• Part I……… The Quest for Unified Management

• Part II…….. To Install or Not

• Part III……. The Need for a Common Console - coming soon

• Part IV……. The Centralized Computing Landscape - coming soon

• Part V…….. Preventing the ‘Usual Suspects’ Syndrome

• Epilogue…..A Unified Solution! - coming soon

DABCC’s core goal is to create simple solutions to solve complex problems. Throughout my

years in IT, I’ve come to realize that there are numerous complex issues as the result of the

Personal Computer (PC) and its associated software. DABCC believes you should not address

each issue through a workaround, but should address the core problems.

With the emergence of numerous virtualization technologies like VMware® and Softricity®

SoftGrid®, the release of Citrix® Presentation Server 4.0, and Citrix’s announcement of Project

Tarpon, the age old challenges around operating system and software installations are being

brought to the forefront. Solutions like VMware and Microsoft® Virtual Server address issues

with operating system rollouts. You now have the ability to separate your operating systems from

your hardware by creating a level of indirection or an abstraction layer between the physical

hardware and the operating system. This technology is being widely adopted to overcome rapid

server deployment as well as driver conflicts, disaster recovery, and many other issues.

Page 2

Now that we have a solution for overcoming operating system to hardware installation and

deployment issues, the critical questions become:

• Is there a better way to install and run applications?

• Can we solve application conflicts, application installations, and application management

issues in the way VMware and Microsoft Virtual Server have addressed similar problems

with operating systems and hardware?

In this paper, I will detail the problems that IT departments face deploying and supporting

applications. I will identify the pros and cons of various technologies that are designed to address

these issues. We will explore server-based computing (including Citrix’s new application isolation

feature), electronic software distribution (ESD), and on-demand virtual application computing,

which includes new comer Citrix.

Page 3

The Origins of the Problems

When I was a little boy, I was fascinated with PCs. But when I would try to explain to my father,

who was from the mainframe engineering world, about how the PC was going to “change the

world” he would just laugh at me. He would say things like, “Boy, you just don’t know what you’re

talking about. PCs are going to create so many more problems than they solve. How are you

going to manage them? How are you going to secure them, and how are you going to physically

install the PCs and deploy applications to them?” I did not know how to reply, as I was just a

young boy who was very excited about what I saw as the PC future.

Over the years, I found out both of us were right. I was correct, as the future was all about the

PC, but my father was more than correct as the PC created decentralized environments in deep

need of some sort of centralized management of the device, the OS, and most importantly, the

software installed on all those PCs. With solutions like VMware and Microsoft Virtual Server, we

are seeing a better way to deploy the operating system. So I ask “Is there a better way to

overcome the issues with installing applications?” Applications installations cause conflicts. In

fact, it’s estimated that 20-40% of all Windows application installations conflict with each other. Is

there a way to overcome these conflicts? To answer these questions, we need to look at what

causes application conflicts, the technologies on the market that may cure the problem, and how

centralized application management and deployment are affected.

The problem of application conflicts dates back to the invention of the PC and the early design of

Windows itself. If you have been in IT for over 10 years, you might remember the days prior to

Microsoft Windows 95, when applications were self-contained. An application had a folder and in

that folder lived every file needed to run the application. Applications used INI files, not a registry.

An administrator could take that folder and copy it from machine to machine and it would run just

fine. With the release of Windows 95, Microsoft added a concept called The Registry, shared

DLLs (dynamic link libraries) and, later, named objects. End-user use scenarios generated the

need for applications to communicate and share information more tightly to facilitate “ease of

use.” But like Newton’s law states, “Every action has an equal and opposite reaction” and the

reaction of these powerful changes to Windows and application installation was the creation of

two of the biggest problems we still face today: the problem that every install has the reaction of

additional complexity, and the potential to step on each other and cause conflicts.

Page 4

To summarize, we have a major problem supporting the PC. We need a single solution to

physically install applications to a Microsoft Windows operating system that will 1) overcome

application conflicts, 2) be centrally managed and 3) occur with little or no administrator

intervention. Before we go into various approaches for application management, let me give you

a bit of background on the debilitating application conflict problem.

The Installation Problem

The problem with application installations is that they permanently alter operating systems with

specific configurations which inevitably lead to application conflicts. This has become far too

common in desktop environments, and even more prevalent in SBC environments. An

application conflict occurs when application X is installed on a machine with application Y, and

one or more of application X’s dependencies or files conflicts with the OS itself or application Y’s

dependencies, leaving the entire application, or even worse, the system unusable.

Application conflicts are commonly caused by one of three things:

• Registry conflicts - Applications that do not conform to Microsoft’s guidelines for use of

HKEY_LOCAL_MACHINE can cause a number of problems, such as limiting the application

to run as a single instance, overwriting the previous user’s settings, an increased likelihood of

crashes, or in a worst-case scenario, allowing a user to read the previous user’s credentials.

Conflicts can also occur between applications, especially between multiple versions of the

same application.

• DLL versioning - Applications can install a specific version of a DLL in a system folder while

another application overwrites that DLL with a different version, causing the first application to

execute incorrectly. For most applications, installing a different version removes or conflicts

with prior versions.

Page 5

• Incompatibility with Terminal Services - Some applications do not run successfully in a

Terminal Services environment and therefore do not run successfully on Citrix Presentation

Server. Incompatibility with Terminal Services is often caused by registry conflicts, system

conflicts, shared files that are locked by a single user, and system objects conflicts. In

addition, graphics- and compute-intensive applications cannot run in Terminal Services.

In the early days, many administrators tried to solve the application conflict issue on desktops by

giving an end-user two computers, one for application x and one for application y. To simplify

things, they give the end-user a switch box and tell them that when they want to run application X,

they need to flip a switch to switch A and for application Y, flip it to B. I must admit, I remember

configuring a few of these for more than one customer.

Did it solve the problem? No, it just added a big, fat, expensive band-aid that attempted to

address the application conflict issue but actually worsened manageability, deployment, and

security. It was nothing more than a band-aid that required double the administration and double

the cost while only really providing for one additional application. Now can you imagine an

environment with five applications that did not work together on one PC? I wonder how much

the TCO jumped with that band-aid. As you can see, this is a nightmare and one that is not

solved by adding extra hardware.

Now let’s look at the various application management approaches, and then examine how they

are impacted by application conflicts.

Page 6

Application Management Approaches

In this section, I will give you background on three different application management models and

how each deals with:

• Installation

• Support

• Update

• Uninstall

Traditional Computing Model The most common and oldest method is the traditional computing model. It consists of two

techniques for deploying and supporting applications: manual and ESD.

Probably the most common way that small to medium-size companies deploy and support

applications is what I call “SneakerWare.” In this method, the administrator must manually install,

configure and support the application. She is required to physically visit the end-user’s PC in

order to install the application. If at any time the end-user’s PC experiences issues, the

administrator is required to physically return to the PC to address the problem.

It can be argued that an administrator can use software such as GoToMyPC® or VNC to virtually

visit the problem application’s operating system. This is just another workaround and another

headache in installing applications. It is NOT a solution.

Probably the most common way that large companies deploy and support applications is ESD. In

this method, a software tool is deployed to allow an administrator to package and push

applications to the end-user PCs. The most common tools are Microsoft Systems Management

Server, Altiris, LANDESK, Novell ZenWorks and Citrix Installation Manager, to name a few.

To package the application that will be deployed to the end-user’s device, the administrator must

install and configure a series of workstations and/or terminal servers in a clean validation

environment comprising the same type of operating machine and configuration as the devices

upon which they will deploy the application. Once the clean environment is installed and

configured, the administrator installs the ESD software that is used to “package” the application.

Then they install the end-user application while the ESD software monitors the installation and

turns the application into a package that can be deployed to similar operating systems through

Page 7

the centralized ESD software. The package is then pushed to the validation environment for

testing. If everything passes, the package is ready to be deployed into production.

To examine this from a timing and sequence perspective, take a look at Figure 1. Using ESD, you

will notice that if everything goes perfectly, there are still a lot of time-consuming, redundant

operations in the enablement processes that make ESD a difficult solution, albeit better than a

manual installation. The problem is that it is very time-consuming and resource-intensive when

things do not work as advertised. With ESD you can expect a certain percentage of

installations—as the industry average is 15%--to fail for every package and that percentage will

increase with package complexity. In addition you may have to package the application for

different clients and builds, and still troubleshoot the application conflicts and the clients that the

applications would not install to. This will increase rollout time and total cost of ownership.

Figure 2: Simplified Application distribution in a SBC environment.

Figure 1: Simplified ESD Process Diagram:

A benefit of ESD is that it generally helps an administrator perform asset management to reduce

software costs and stay compliant with application licensing. A good ESD system will also allow

an administrator to “patch” local software for both bug fixes and security fixes.

Page 8

Let’s now look at what is required to install, support, update, and uninstall the application using

the manual traditional computing model, including ESD.

• Install – With purely manual computing, you are required to physically install each

application. This means that you are required to visit each workstation and install the

application from the manufacturer’s installation package.

With ESD, you must create the validation environment, create the package, and regression

test the package. Once that application passes the test, it can be deployed to the end-user’s

Windows device where it will be run and processed locally.

• Support – You are still required to visit each workstation in the event the application runs into

any problems.

• Update – For traditional manual methods, you are required to apply any updates on-site on

the local machine. With ESD, you will have to re-package the application and then re-apply

the package to the local device.

• Uninstall – For traditional manual and ESD, an administrator is required to use the

add/remove programs applet in the control panel of the end-user device. Unfortunately, there

are many cases where the manual and ESD methods of uninstalling an application do not

uninstall the entire application, thus leaving what are called “orphan files.” These orphan files

can lead to additional support calls, and hence an increased total cost of ownership.

Server-based computing (Citrix Presentation Server 4.0)

With the release of Citrix Presentation Server 4.0, Citrix created two types of application

installation scenarios: with Application Isolation Environments (Citrix Presentation Server 4.0) and

without (Citrix Presentation Server 3.0 and below). I will describe each and note how an

administrator installs, supports, upgrades and uninstalls the application.

Server-based Computing (without Application Isolation Environments) The server-based computing method allows administrators to centralize application deployment

and application process execution. This model consists of a farm of servers that act as virtual

Page 9

workstations. An administrator installs the end-user’s applications on the farm servers and the

server-based computing software separates the application logic processing from the

presentation display. The application is physically processed and executed on the server, while

the images are displayed on the end-user’s device. The most common server-based computing

packages are Microsoft Terminal Services and Citrix Presentation Server.

A critical point to remember about server-based computing is that the application presents the

display to the end-user’s device; it does not virtualize the installation of the application. To look

at this from timing and sequence perspectives, see Figure 2. You notice the process is a lot like

the ESD method: if everything goes perfectly the process works great. When this is not the case

you will run in to the same issues as when using the ESD method plus the additional time, cost,

and resources needed to create and configure the application silo. This will increase rollout time

and total cost of ownership.

Figure 2: Simplified Application distribution in a SBC environment:

Let’s now look at what is required to install, support, update, and uninstall the application using

the server-based computing method without Application Isolation Environments.

• Install – In the eyes of an application, a server-based computing server is really just a

workstation. In deploying applications to users, server-based computing presents the

application to an end-user device so that the end-user has very close to the same type of

functionality he would if the application was actually installed locally. When you ask, “What

Page 10

does it take to install an application using server-based computing?” you have to understand

two things:

1. When talking about the end-user device, then there is zero install of the application.

2. There is the need to physically install the application on the server-based computing

server and with it you are required to manage the install and workaround any conflicts.

In effect, you are back to choosing between the manual and ESD application deployment

methods because the problems we are trying to solve still exist since we still need to

physically install the application somewhere. I want to make this point very clear as it is very

important in formulating a “solution” to the problem, not just a workaround. In a server-based

computing environment, you do NOT install the applications on the client device but you DO

install them to the servers and thus you will still run into all the same problems that you face

on the end-user device.

• Support, Update, Uninstall– Because you still need to physically install the application, you

must use chose either traditional computing or on-demand virtual application computing

model and support, update and uninstall applications accordingly.

Server-based Computing (Using Application Isolation Environments) With the release of Citrix Presentation Server 4.0, Citrix added a much needed feature called

Application Isolation Environments (AIE). AIE was designed to address application conflicts and

add more applications and thus potential user to Presentation Server 4.0. AIE is available for

customers running the Enterprise version of Presentation Server 4.0. The core benefits AIE

offers are:

• Install a greater number of applications than possible with previous versions of Presentation

Server.

• Install and execute multiple applications that require different versions of the same shared

component

• Install and execute applications that conflict with one another on the same server

• Update applications independently of each other without fear of impacting existing

applications

• Install and execute applications that were not designed to be run in a server-based

computing environment.

Page 11

This is accomplished through per-user and per-application file system, registry, and named

objects redirection, which Citrix calls “isolation.” AIE also provides the administrator with the

ability to create rules to add advanced configuration to the redirection.

File System Redirection – All end-user and application data can be redirected per user, and an

administrator can specify if a file or folder can or cannot be redirected. By default, file

redirection will apply to all subdirectories and files of a previously redirected parent directory. An

administrator can create a rule that enables any user specific or application-specific fully qualified

file pathname to be redirected to a different fully qualified file pathname. This rule punches

through the isolation environment to the physical file system, and can be created to override the

redirection of an individual subdirectory or file from that of its parent. Each rule has security

attributes that allow or deny read, write and execute access.

Registry Redirection – Like the file system, registry keys can be redirected for the application or

per user and an administrator can specify if a registry key can be or can not be redirected. By

default, the redirection will apply to all sub keys of a previously redirected parent registry key. An

administrator can create a rule that enables or overwrites the ability for any fully qualified registry

key to be redirected to a different fully qualified registry key. Each rule has security attributes that

allow or deny read, write and execute access.

Named Object Redirection – Named objects are programming constructs used mainly for

synchronization and passing of information between processes. Terminal Services already

isolates named objects by user session, and by installing an application into an Application

Isolation Environment an administrator can make rules to enable a named object operation to be

redirected to a different named object within a user session.

Now that we understand what an Application Isolation Environment is designed to do, we can

look at what is required to install, support, update, and uninstall the application using the server-

based computing method:

• Install – When using Application Isolation Environments the same basic installation steps

used to deploy applications without AIE are required—plus the following steps:

1. Enable application isolation environments for the farm, if not already done through the

Management Console for Presentation Server 4.0

2. Create application isolation environments through the Management Console for

Presentation Server 4.0

Page 12

3. Configure the properties, redirection paths, of the application isolation environment

though the Management Console for Presentation Server 4.0

4. Install the application into an application isolation environment. This is done via the

command line switch AIESETUP. This requires a great understanding of the application

and its components and command line switches.

5. Isolate the published application though the Citrix Management Console

When you ask, “What does it take to install an application using server-based computing

using application isolation environments?” you get the same answer as when installing

without AIE: You must still physically install the application on the server-based computing

server. Thus, you are back to choosing between the other application deployment methods

discussed earlier to get around the application conflict problems.

• Support, Update, Uninstall – Because you still need to physically install the application, you

must use chose either a traditional computing or on-demand virtual application computing

model and support, update and uninstall applications accordingly.

Page 13

On-demand virtual application computing

The on-demand virtual application computing model, which first came to market with Softricity

SoftGrid, changes the paradigm of how applications are run and managed, through virtualization

of the application. This means that applications are completely insulated from the operating

system and from each other using an abstraction layer. There is no writing to the registry or to

where DLLs are stored. As a result, the OS is kept completely clean. Just as VMware and

Microsoft machine virtualization don't install operating systems to hardware, what true application

virtualization does is make it so software doesn't get installed to the operating system.

Why is this so important? The goal of virtual application computing is to turn every computer into

a generic computing device that can, in real-time, provide users with exactly the applications they

need and have the right to, personalized for their own use. Just as machine virtualization allows

you to dynamically run any operating system on a server the moment you want it there,

application virtualization allows you to dynamically run any application on any desktop or server

the moment a users needs the software.

This is a great goal for IT, and here's why. If you have a computer that has software installed

onto it, it has become changed from its original state and, once a user starts using the program,

becomes customized to that specific user. The machine is no longer able to support a second

user, newly installed apps start conflicting with the other installed apps, and the management

headache begins.

To do away with this, virtual application computing eliminates the application from actually

installing to the computer - or be dependent on any of the operating system's configurations.

Instead, each application comes with it’s own set of configurations and captures any

personalization that the user may do.

Softricity has been talking about "application virtualization" for a long time. With the growing

popularity of the virtualization space, they're beginning to get the credit they deserve, but at the

same time other companies are starting to claim their solutions are also doing application

virtualization. For instance, at this year's iForum, Citrix made the claim that Presentation Server

and newly announced Project Tarpon is application virtualization software. But is it really

application virtualization?

The following discusses Softricity SoftGrid and Project Tarpon, how they work, their differences

and if they are true virtualization technologies.

Page 14

Softricity SoftGrid 3.2 SoftGrid, changes the paradigm of how applications are installed. Using SoftGrid, an application

is transformed from software that is required to be installed and configured on every device into a

centrally managed service that is not required to be installed or preconfigured on the computer

that will be executing it. It is truly virtualized. Applications are turned into a few files that are

deployed to and executed from the end-user device. Ultimately, this allows administrators to

accelerate the entire application management process and fully address the problems resulting

from distributed management and installation requirements of PC and server-based computing

applications.

Figure 5: Simplified On-demand Virtual Application Model:

As you can see, the major impediments to both SBC and ESD deployment of applications are

eliminated using application virtualization technology. The concept is simple, yet has far-reaching

implications. Since the application and its run-time environment are virtualized, there is no chance

for application conflicts. This removes the most time-consuming parts of application deployments:

regression testing, troubleshooting failed installs, and ongoing management of multiple silos.

The benefits behind virtualizing applications are as follows:

• The application’s source code does not need to be modified in any way

• Removes the need for application installation and thus the application conflict issue

• No altering of the client computer. (In server-based computing the server acts as the client.)

• In most cases, once the application is sequenced, it can run on multiple Windows operating

systems without the need to change any of the application packages

• Enables any application to run in a multi-user environment, even those not designed to do so

• Can assign applications to end-users based on login credentials

• Centrally assigns and meters application licensing

Page 15

• Single solution for deploying and managing applications on desktop workstations, mobile

laptops and server-based computing servers

• Significantly reduces—or even eliminates--the amount of regression testing required as the

application is run in the virtualized SystemGuard “bubble”

• Reduces application security issues

Specifically, here is how virtualization impacts the application management lifecycle:

• Install – You are required to sequence the application, copy it to the SoftGrid server, and

assign it to the appropriate users and groups. The first time a user with rights to the

application logs onto their device and attempts to execute the app, the SoftGrid client

communicates with the SoftGrid Server and streams the application to the end-user device.

Because the application is really just a few files, it is also possible to deliver the application to

workstations, laptops and terminal servers in advance.

• Support – Because the application is truly virtualized and runs within the SystemGuard

bubble, there is no operating system configuration required.

• Update – When the administrator wishes to install a service pack and/or a product upgrade,

they simply return to the sequencer, open the sequenced application and install the update

just as they would on a stand-alone PC. Once finished, the application package is copied

back to the SoftGrid Server and automatically streamed to all SoftGrid clients the next time

the application is used. This means an application can be updated without rebooting the PC

or server.

• Uninstall –To uninstall an application from an end-user device, all the administrator must do

is remove the access rights from the end-user in Active Directory. The next time the user

logs on, and/or the SoftGrid client refreshes its list of available applications, the entire

application is removed, leaving no orphan files.

Page 16

Citrix Project Tarpon At Citrix iForum, Citrix announced Project Tarpon and described it as a vitalization software

solution. Project Tarpon was designed to “stream” applications to a desktop and to address

application conflicts through utilizing Application Isolation Environment, as described earlier in this

document. The one thing to keep in mind throughout this analysis is the version of Project

Tarpon that was presented at iForum was an early Alpha release. Citrix would not comment on

what the final release date will be, but from what I’m hearing, it will be the middle to late part of

2006. The core benefits Project Tarpon offers, as shown at iForum are:

• Centrally “stream” applications to a Windows desktop

• Centrally Install and execute applications that conflict with one another on the same

workstation.

• Centrally update applications independently of each other without fear of impacting

existing applications

Citrix Project Tarpon is a package and stream technology that leverages Citrix Isolation

Environments to overcome application conflicts. The administrator installs the application they

wish to deploy through the Citrix Project Tarpon profiler which also assists in publishing the

application. All additional administration is done through the Citrix Access Suite Console.

Once the application is profiled (packaged) and published, the end-user’s Citrix client will

enumerate the application and when the end-users clicks on the application to execute it the

application will be copied to remote device. Once the application is copied from the central file

share to the end-user’s device, the application is able to run through a local Citrix Application

Isolation Environment. The application files are cached for future launches. If this process fails

for any reason, then the administrator is left to find another method to install and manage the

application.

To examine this from a process and flow perspective, let’s take a look at Figure 4. Using Project

Tarpon you will notice that if everything goes perfectly, there is still additional time used to verify

the application meets all the requirements of Project Tarpon’s isolation environments. The

problem is that if the application does not meet Project Tarpon’s isolation environment

requirements for not only packaging the application, but for deploying the application through

Project Tarpon’s file streaming limitation, then IT will be forced to find a different method of

deploying the application in question. (i.e., ESD, SBC and or Softricity SoftGrid) This will

increase rollout time and total cost of ownership.

Page 17

Figure 4: Simplified Project Tarpon Process Diagram:

Now that we understand what Project Tarpon is designed to do, we can look at what is required

to install, support, update, and uninstall the application:

• Install – The first thing an administrator needs to do is “package” the application by installing

it through the Project Tarpon profiler. The profiler will analyze the installation and add all the

files and registry entries necessary in to a “pkg” file. Once the “pkg” file is created, it will be

copied to a file share and then published to the desktop through the Citrix Program

Neighborhood Agent and or through the Web Interface. Then when the end-user clicks on a

Project Tarpon published application the application’s “pkg” file is copied to the desktop and

run through a application isolation environment, as described earlier.

• Support – This is a gray area that to date we don’t have all the details on. If the application

runs perfect in the isolation environment, then no support is needed. If the application does

not comply with the requirements of an isolation environment as described in the Application

Isolation Environments section above, then either the application will need to be repackaged

with custom rules and or the particular application will not be deployable via this solution.

• Update – When the administrator wishes to install a service pack and or a product upgrade,

they simply return to the Project Tarpon profiler, open the pkg file and install the update just

as they would on a stand-alone PC. Once finished, the application package is copied back to

the pkg file share and automatically copied to all Project Tarpon clients the next time the

application is used.

Page 18

• Uninstall – To uninstall an application from an end-user device, all the administrator must do

is remove the application from the Citrix Access Suite Console. The next time the user logs

on, and/or the Citrix client refreshes its list of available applications, the entire application is

removed.

To define whether or not Project Tarpon is “Virtualization Software” as Citrix claims it to be, we

need to look back at the definition as defined above. From this definition, virtualization software

is required to create an “abstraction layer along with the logical management and physical

storage of the applications settings, registry, and file structure in a virtual file system, through or a

single file that is executed through in a completely isolated environment (i.e., VMware, Microsoft

Virtual Server, and Softricity SoftGrid)”. From what Citrix previewed at iForum and the knowledge

that they are using Application Isolation Environments, this analysis would have to conclude that

Project Tarpon is more of a redirection system than a virtualization system in the sense that it

redirects the file system, registry and named objects as described in detail in the Application

Isolation Environments section above. Thus concluding that, at this date, Project Tarpon is NOT

Virtualization Software as defined by the community. It is more of a next generation ESD solution

that enhances the ability to rapidly deploy, support and update an application.

Now that we have learned about the major application deployment and management approaches

let’s look in more detail at how they address application conflicts.

Page 19

Addressing Application Conflicts

Application conflicts are a given in today’s world, and the application management approaches

are impacted to varying degrees by them:

Traditional Computing Model / ESD

When using the traditional computing model of software deployment, supporting an application is

more difficult because it is physically installed on the end-user’s device, and managing the end-

user’s PC is left to the end-users themselves. It is not uncommon for end-users to delete key

files or registry entries or install other, un-tested and un-approved applications to their systems.

This causes application conflicts, and in return, more administrator support is needed.

Pros:

• In ESD, applications are packaged once and then pushed out and installed on the end-

user device

• Application and operating systems can be patched centrally

• Most ESD management suites available today have the ability to do asset inventory and

control

Cons:

• Applications are still physically installed on each local device

• Administrators are still required to visit the end-user device or some form of remote

control software, in order to support the application

• Applications are not always uninstalled cleanly by the ESD software and thus it leaves

orphaned files and registry settings on the end-user device

• It is not uncommon for an application to be installed on a device and have it break

another installed application, which results in IT needing to troubleshoot and solve the

conflict problem

• While installing application using ESD, the PC is left unusable for the user until the

software is done installing, creating downtime if done during the day, or a late night

change window that is difficult on IT

Page 20

Server-based computing (Citrix Presentation Server 4.0):

One of the core draws of server-based computing is that it can be designed to address

application conflicts by creating application-centric server farms. When I first discovered server-

based computing, I remember going back to the customer for whom I had deployed the “switch

box” method to explain the huge value add of Citrix and centralized computing. I told them that

with Citrix, they could deploy just one PC to each end-user and can deliver the applications via

Citrix in a “virtual session.” I was and still am very impressed! My customer was sold on the idea

and off we went to deploy a Citrix solution. We gave each end-user one PC and we bought a

slew of servers to be our “virtual workstation” farm servers. To overcome the application conflict

issue, we grouped applications that played well with each other on their own servers, called silos,

and then through Citrix we gave the end-user one interface to log in through. Everything worked

great, and we addressed the application conflict issues. But we did not actually solve the

problem; we just moved the problem from the client-side to the server-side.

With Application Isolation Environments (AIE) in Citrix Presentation Server 4.0, Citrix has made

another attempt to address application conflicts by redirecting the application and user data from

the file system and registry. In some cases, application isolation environments will be an

acceptable workaround for the application conflict issue. For example, if the application in

question is failing because the application writes all user data to one INI file then AIE will copy

this file to the end-users home directory, thus solving the problem. AIE can also be used in small

environments with a few Presentation Servers and/or a small amount of applications where the

complexity of physically installing the application is not enough of a burden to justify a better

solution.

However, is AIE a solution to installing applications? Not at all. Even with application isolation

environments the administrator is still required to physically install the application on the

Presentation Server machine and then must configure and customize items required to be

redirected.

Page 21

Pros

• The number of machines requiring physical application installation is severely decreased.

With application isolation environments, this number is even better as application

isolation environments will allow applications that meet the requirements to be installed

on the same server, reducing the amount of application silos.

• Centralized control of the application presentation process to the end-user device.

• Application Isolation Environments will allow an administrator to configure a terminal

sever from the “relaxed” security mode to “enhanced.” The relaxed security model allows

for applications that write settings to HKEY_LOCAL_MACHINE key or to restricted

locations in the file system by redirecting this data.

Cons

• Redirection is an “after the fact” process. Administrators must first determine which

applications conflict with each other

• While installing application on the server, the server must be taken off line. This could

cause service interruptions to the end-users.

• If a server or application does not function right, everyone is affected.

• Application conflicts are likely and regression testing is required to determine which

applications will need to be redirected through an AIE.

• Applications still need to be physically installed on the server

• Roaming application data resides in the user’s profile, and thus the profile is likely to

become corrupted and, in return, the end-user loses data.

• Applications are Windows version dependent

• Not all applications run in terminal services environment (graphically and CPU intensive

applications. This will change in the future as Citrix recently announced Project

Constellation’s Extreme Graphics Acceleration technology.)

• Application Isolation Environments requires a vast knowledge of the applications files,

registry, and any named objects to be redirected.

• Application Isolation Environments do not work with all applications. For example,

applications that require a reboot during install, and redirecting via wildcard (c:\program

files\DABCC\*).

• Application Isolation Environments allow for an administrator to publish different web-

based applications with different dependencies on the same server but it cannot support

different group policies per user and application instance.

Page 22

On-demand virtual application computing:

When using the On-demand virtual application computing model of software deployment,

supporting an application conflicts is much easier. This is a key benefit of the virtualization

aspect the application is executed in. The following discusses Citrix Project Tarpon and Softricity

SoftGrid and how they were designed to address application conflicts along with the pros and

cons of each solution.

Softricity SoftGrid 3.2 Softricity SoftGrid is designed to address applications that cause conflicts by completely

virtualizing and running them in their own world, what Softricity calls SystemGuard. When I first

discovered on-demand virtual application computing, it took me some time to truly see and

understand the paradigm. It was not until I had used SoftGrid and got my hands deep into the

software, that I realized virtual application computing was truly a reality, and began to understand

the tremendous impact it would have on application deployment and management.

Unlike the “switch box” method I had used in earlier times to overcome application conflicts, and

the server-based computing siloing I was currently using, the on-demand virtual application

computing allowed me to easily deploy applications to end-users’ Windows devices and to server-

based servers without any application conflicts—and without any time-consuming workarounds.

This also meant I would no longer need to silo the servers. I saw that the mobile users I was

supporting could now work while on an airplane or in a remote area even when they weren’t

connected to my SBC solution. Finally, I realized that I did not have to visit the client or end-user

device for installation. Even the SoftGrid client could be easily installed in just a couple of

minutes by the end-users themselves or distributed via script.

Pros

• SoftGrid is a very mature product that has successfully sequenced over 20,000

applications.

• Applications are never physically installed on the client

• Application that in the past caused conflicts are not required to be placed in own silo or

on separate devices because conflicts are eliminated

• Centralized control over application deployment, upgrades, patching, terminations

• No application files or settings are ever loaded locally into the Registry or file system, so

application conflicts are eliminated

• Authentication, security and licensing control of all applications

Page 23

• On-the-fly updating of application on the client computers (including Terminal Servers)

without administrator intervention

• Dramatically reduces the cost of deploying, updating, support, and terminating

applications

• Dramatically reduces the size and complexity of the user’s roaming profile in a server-

based computing environment.

• The administrator does not have to make sure that an application is pre-installed on a

Citrix Presentation Server / Microsoft Terminal Server as the applications and user data

follows the user from Windows device to Windows device

• Reduces the potential for profile corruption in terminal server environments as the

application user data is stored with the application not in the user’s profile

Cons

• Sequencing an application requires end-user knowledge of the application

• Lack of application support for some types of applications, namely boot time apps,

drivers, and Service Packs

• Limited client support (no Windows 95, 98, NT or ME clients)

Citrix Project Tarpon Citrix Project Tarpon is designed to address applications that cause conflicts through Citrix

Application Isolation Environments running at the desktop level. The same pros and cons apply

to addressing application conflicts as to AIE running on a Citrix solution, as described earlier in

this document. The process Project Tarpon uses to stream adds additional pros and cons to the

potential solution.

Pros

• Centralized control and distribution of applications to the end-user device.

• The ability to overcome applications conflicts with applications that comply with the

requirements for Application Isolation Environments.

• If a user deletes and or corrupts an application file, Project Tarpon will refresh the

missing and or corrupt file from the central file share. This does require an additional

SMB file transfer

• Applications are cached locally thus allowing for offline and fast access for future

application launches

Page 24

Cons

• Project Tarpon is still in prototype phase. Currently Citrix has no existing customers and

proof of knowledge on how Project Tarpon will function in production.

• The process of “streaming” the application to the client devices uses SMB file transfers

thus requiring the NETBIOS port to be opened on any firewalls between the client and

the server. This is considered a potential security risk.

• A file share is required to house the application package. This requires access rights to

the domain or workgroup the file share resides in. This has the potential to limit non

domain / workgroup end-user with opening up an additional security issue.

• The entire application is required to be copied from the file share before the application

can run. Depending on the size of the package this could take a long time. (Microsoft

Office 2003 is 485 MB on my machine)

• Roaming application data resides in the user’s profile and thus the profile is likely to

become corrupted and, in return, the end-user loses data.

• In order to configure Application Isolation Environments rules, the administrator is

required to have a vast knowledge of the applications files, registry, and any named

objects.

• Application Isolation Environments do not work with all applications, for example,

applications that require a reboot during install, and redirecting via wildcard (c:\program

files\DABCC\*).

• Application Isolation Environments allow for an administrator to publish different web-

based applications with different dependencies on the same server, but it cannot support

different group policies per user and application instance.

Page 25

Conclusion At the beginning of this analysis, I asked the question, is there a better way to physically install

applications to operating systems? Can we solve the problems that create application conflicts,

application installation, and application management issues in the way VMware and Microsoft

have addressed similar problems with operating systems?

The answer, after examining the three application management approaches, is a resounding

yes. Here’s a summary of how they stack up:

The traditional computing model of deploying applications does not adequately solve the core

problem of application management: conflicts abound because applications are physically

installed on the client device.

The fully manual method does not solve the problem at all. ESD does an ok job helping with

application management because it simplifies installing and uninstalling applications. However, it

does not address the problem of application conflicts.

The server-based computing model is an excellent way to present applications to end-users on

almost any device, but it does not solve the application installation or conflict issues. While it

reduces complexity and the number of installations on desktop clients, it transfers that complexity

to the server side where the applications have just been installed manually or via ESD, and

multiple hardware devices and silos are needed to avoid conflicts.

With Citrix Presentation Server 4.0 and Application Isolation Environments, an administrator can

install troubled applications on the same server by redirecting the applications and users file

system, registry and, named object entries to another physical location. However, this requires a

very deep understanding of each application you wish to deploy and at the same time it is not true

isolation but redirection. Because of this, it still requires regression testing to determine if

applications will conflict when installed and, as a result, need to be redirected. In enterprises with

large numbers of applications, the administration of installing—and therefore also supporting and

terminating each application—is very time consuming. It also requires additional system

resources leaving you server with ultimately less users.

The on-demand virtual application computing model is the only method that answers both

questions although with companies like Citrix claming a place in this market they sort of convolute

the space a bit. Because of this, the first thing you must decide upon when thinking about on-

demand virtual application computing model is if the product actually complies with the virtualized

Page 26

application definition. From this analysis, I would conclude that Citrix does not meet this

standard and does not comply with the definition of a truly virtualized application. This being said,

the only product that does is Softricity SoftGrid.

I believe Softricity SoftGrid to be the solution to the application installation and management

nightmare. Its benefits far outweigh the pros of any other method and or solution. It truly solves

management issues and conflicts by virtualizing applications while allowing for centralized

support, updates and uninstalls. Because the application runs in a “bubble” and does not affect—

or get affected by—other applications or the operating system, this also dramatically reduces the

number of application issues as well as the time it takes to troubleshoot remaining application

issues. Help desk calls are drastically reduced across, workstations, laptops and terminal

servers.

Softricity SoftGrid enables end-users to run all their desired applications and safely self-provision

new applications without administrator intervention. Administrators are only responsible for

supporting the end-users’ operating systems and the SoftGrid client as the applications

themselves are tested and supported very easily through the SoftGrid server. While a similar

level of client management is required with server-based computing, the great advantage of being

able to support any application allows a customer to use the same packages they use to deploy

applications to workstations and mobile devices` to the terminal servers makes on-demand

application virtualization the far better choice.

If you are an organization with a large amount of applications, and or are feeling increased pain

from application conflicts then you should explore using on-demand virtual application computing

to manage:

1. LAN and mobile workstations – If the end-user resides on the LAN and/or will require offline

access.

2. Server-Based Computing – If the end-user is working from an offsite device and/or is working

with applications that requires a considerable amount of bandwidth.

This solution enables IT to guarantee excellent application response time and functionality for

end-users by allowing them to compute via workstations, laptops and or through terminal

servers.

Page 27

Softricity SoftGrid then coupled with RES PowerFuse, as discussed in Part I of this white paper

series allows IT to truly manage end-user configurations and applications seamlessly across the

enterprise while enabling administrators to configured back-end servers and services as needed.

The end-user works through a constant interface and application set no matter the location and or

device, leaving the end-user to manage an unchanged OS. Now this is powerful.

Those are my conclusions. I challenge you to look at your environment and take the ideas I’ve

tried to illustrate in this white paper series and ask yourself, “Can I solve the problems I face,

while reducing complexity, increasing end-user satisfaction and reducing long term costs?” I’m

excited to say that with the right technologies and management approach, you can.

Page 28

About the Author Douglas A. Brown (DABCC, Inc.)

DABCC specializes in the design and development of techniques,

methodologies, authoring, education, training, outsourcing and

software products that add immediate value to server-based

computing and on-demand virtual application computing world. The

company was formed in 2004 to reduce complexity in corporate

computing by developing and teaching a proven methodology for

providing seamless, real-time access to strategic company

information.

Douglas Brown worked at Citrix Systems, Inc. as a Senior Systems Engineer from 2001 to 2004

in which time he was voted Systems Engineer of the Year 2002 by his peers and management at

Citrix. He was awarded the Microsoft MVP (Most Valuable Professional) by Microsoft Corporation

in 2005 for his contributions to the industry. Mr. Brown has earned worldwide recognition for his

dedication to providing server-based computing professionals with proven solutions for

implementation, infrastructure design, time-saving utilities, performance tips and best practices.

DABCC.com is one of the most frequently visited sites internationally for server-based computing

information and networking opportunities.