Tag Archives: Terminal Server

To continue the discussion of “What is Virtualization?” that I started back on December 4, I bring you the next installment - Application Virtualization.

Application Virtualization is the isolation and separation of an application from its underlying Operating System (OS) as well as from other applications. The application is fooled into believing that it is working as normal, interacting with the OS and using those resources as if the application had been installed directly on the OS as normal.

Additionally, the application can be installed once within the datacenter and preserved as a “golden image” to be delivered out to the end users. This gives you one instance to manage, one instance to patch, one instance to maintain - all housed in one location. This will help cut IT application maintenance costs as well as help control licensing costs as it will be easier to track application utilization.

Since each virtualized application is isolated from other applications it becomes possible to deploy, on the same piece of hardware, applications that typically didn’t play nicely together in the past. This cuts down on the time needed to test application compatibility since each application resides inside its own “bubble” (much like teenagers).

Traditionally, both desktop admins and admins who were in charge of Terminal Servers (and XenApp servers) spent hours and hours on application compatibility testing. When a new application was added to the official desktop or server image, or an existing application was upgraded, regression testing was necessary to insure that the new or upgraded application didn’t break some other application by, for example, overwriting a shared DLL file. By providing a method for virtualizing Registry entries and calls to particular folder locations, application isolation overcomes most of these headaches.

The real trick with application virtualization is the delivery method, since the delivery methods of these virtual applications is what separates the different vendor solutions in this field. The big three application virtualization solutions are Citrix XenApp, VMware ThinApp, and Microsoft Application Virtualization (a.k.a. “App-V”). These three vendors use either one method or a combination of delivery methods to get the applications to the end users.

Application Streaming: This refers to streaming the application over the network to the client PC on demand. The “secret sauce” here is in figuring out how to stream down just enough of the code to launch the application and allow the user to begin interacting with it. The rest of the code can be streamed down when the user attempts to use a feature that requires it, or it can be simply streamed down in the background until all of the application code is cached locally. An added benefit of streaming all of the code down is that it allows the application to continue to be used when the PC is not connected to the network. (E.g., you can unplug your laptop and take it on the road.)

The application streaming technology you use will determine the control and security of the application once it has been streamed to the end user device. For example, Citrix allows you to administratively set a “time to live” limit on how long apps will run in a disconnected state. If the PC isn’t reconnected to the network within that time limit, the app simply stops working - giving you some level of protection if a PC is lost or stolen. For another example, ThinApp allows you to make an application completely portable - you could carry the Office Suite with you on a USB stick, plug it into any PC, use it, and leave no trace behind when you unplugged the USB stick. (Note: Doing this with the Office Suite could result in a violation of the Office EULA!)

Another “secret sauce” ingredient is the ability to allow limited communication between applications, even though they’re running in their own isolation environments (the “bubble” referred to earlier). For example, your accounting application may need to call Excel to render the output of a particular report. Early versions of application isolation required these applications to be “packaged” together, i.e., installed into the same isolation environment - otherwise, the accounting app wouldn’t know that Excel was available, and you’d get an application error. The latest implementations allow enough inter-isolation communication to take place to avoid problems like this while still avoiding application compatibility conflicts.

Application Hosting: This method can take a couple of different forms. The first is to virtualize the presentation of a typical Windows application by installing the application on a Terminal Server (in most cases, a Terminal Server with Citrix XenApp installed on it), and connecting to that Terminal Server using some kind of remote communications protocol (e.g., Microsoft’s RDP, Citrix’s ICA, etc.). We’ve been doing this for years, and thousands of customers and millions of users access applications this way every day.

Most readers of this blog are probably familiar with the advantages of this deployment model: centralized deployment and management, tighter security, granular control over what can be saved and/or printed at the client location, etc.

Application Streaming can work with this kind of Application Hosting by allowing you to stream applications to your Terminal Servers rather than having to explicitly install them or build them into your official server image. Citrix XenApp customers have the rights to use the Citrix streaming technology to do this, and Microsoft recently announced that the new Server 2008 R2 Remote Desktop Services CAL (formerly called a Terminal Services CAL) will include the rights to use App-V to stream applications to Terminal Servers.

Web-based applications can also be legitimately called “hosted applications” - whether they’re hosted in your own corporate data center, or by some kind of application service provider (e.g., Salesforce.com). In this scenario, all that’s required on the client PC is a browser - at least in theory.

In fact, the browser then becomes an application that must be managed! For example, you may find that you require a specific version of Java to access a particular hosted Web application - and if the user has local admin rights to the PC, the possibility exists that s/he will inadvertently install something that breaks its compatibility with your critical Web application. Some Microsoft applications require the use of Internet Explorer (e.g., Microsoft CRM is not compatible with Firefox). Some applications may even require a specific browser version. (When IE7 was first released, it caused compatibility issues for users of Microsoft CRM v3.0.)

Also, as a general rule, a Web application will require a more powerful client PC as well as more bandwidth between the client and the Web server to yield a good user experience, compared to an RDP or ICA client device connecting to a Terminal Server.

There is, of course, the option of installing an application directly on a device either by physically visiting the machine with installation media in hand or by using some kind of central management system to push the bits onto the client’s hard drive. These options, however, do not fall under the definition of application virtualization that we’re using here.

The important thing to take away from application virtualization is that no matter how you approach it, it will save you money:

• Hardware – being able to host multiple applications on a single piece of hardware without worrying about application incompatibility. This can virtually eliminate the “silos” of servers with different configurations in large XenApp environments that used to be necessary to isolate those problem apps that wouldn’t play nicely with any others.
• Licensing costs – with all your applications being housed in the data center you will have a better understanding of how many instances of each application you are using and will be able to better track your licensing needs
• Maintenance – being able to update or patch a single instance of the application rather than needing to physically update and patch each machine.
• Management – less hardware to look after, less time spent with helping end users with application issues, less time spent in application regression testing

Hope this clears up that “what is application virtualization” question. However if you have more questions feel free to use the comments or contact me directly.