Read To Install or Not Install text version

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 0

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 1

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 2

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 3

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 4

·

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. addition, graphics- and compute-intensive applications cannot run in Terminal Services. In

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 5

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 6

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 7

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 8

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 9

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 10

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 serverbased 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 11

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 12

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 13

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 14

· · ·

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 15

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 16

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 17

·

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 18

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 enduser'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 enduser 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 19

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 serverbased 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 For example, if the application in

acceptable workaround for the application conflict issue.

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 20

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. 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 Administrators must first determine which

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 webbased applications with different dependencies on the same server but it cannot support different group policies per user and application instance.

Page 21

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 serverbased 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 22

· · · ·

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 serverbased 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 23

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 webbased applications with different dependencies on the same server, but it cannot support different group policies per user and application instance.

Page 24

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 ondemand virtual application computing model is if the product actually complies with the virtualized Page 25

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 26

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 27

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.

Page 28

Information

To Install or Not Install

29 pages

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

1338955


Notice: fwrite(): send of 213 bytes failed with errno=104 Connection reset by peer in /home/readbag.com/web/sphinxapi.php on line 531