What Is Application Virtualization?

Some folks out there are still scratching their heads over the Citrix decision to change the name of Presentation Server to XenApp. There were actually several reasons for that change. For one thing, we’ve all seen Remote Desktop Services (formerly known as Terminal Services) get better and better with every release of Windows Server – and don’t think for a minute that Citrix didn’t see that coming. As closely as they work with Microsoft, of course they did. So it became obvious to Citrix long ago that they needed a better value proposition for their product than “something that I add to Terminal Services to get better performance.”

In point of fact, Citrix does have a considerably better value proposition than that – but not everyone was “getting it.” One way to help people get it is to re-frame the conversation by repositioning the product, and sometimes changing the product name can help make that happen.

But why XenApp? Well, that goes back to the acquisition of XenSource a few years ago. It seems that, after making that aquisition, Citrix decided that, in their vocabulary, “Xen” = “Virtualization.” Therefore…

• “XenServer” = “Server Virtualization”
• “XenDesktop” = “Desktop Virtualization”
• “XenApp” = “Application Virtualization”

But does it, really? (XenApp, I mean.) Well, sort of. These days, application virtualization is a component of XenApp, but XenApp is more than just application virtualization.

Which brings me back to the question: What is application virtualization? I would suggest, as a good working definition, that, just as server virtualization is the abstraction of a server operating system from the underlying hardware, application virtualization is the abstraction of an application from the operating system it’s executing on.

We virtualize servers by interposing a layer of software – the hypervisor – between the hardware and the operating system. Although some operating systems, like Windows Server 2008, are virtualization-aware, meaning that they know when they’re running on a hypervisor and modify their behavior accordingly, earlier OS versions had to be fooled into thinking that they were running directly on server hardware when in fact they were not.

Applications today are still at the stage of development where they have to be fooled into thinking that they’ve been installed normally when in fact they have not. When they’re installed, applications typically write specific information to specific locations in the Windows registry. They place .DLL files into specific folders (most frequently into C:WindowsSystem32) – and sometimes these .DLL files overwrite or conflict with others, which is why you can’t, for example, run two different versions of Microsoft Access on the same PC workstation without some kind of application virtualization. Application virtualization places a sort of “software wrapper” around the application – sometimes referred to as an “isolation environment,” or a “sandbox.” It causes these Registry keys and files to be written to an application specific location, and redirects the application calls so they can be found when the application executes.

By contrast, when an application is executed via Remote Desktop Services (with or without the involvement of XenApp), you’re really virtualizing the presentation of the application. The application is executing on the server, and the user interface is being presented remotely at a client device, using a protocol such as RDP (Microsoft) or ICA (Citrix) to transport keystrokes and mouse movements from the client to the server, and screen updates from the server to the client.

In the old days – and often today as well – that application was installed directly on the Remote Desktop server. Today, we can instead use application virtualization to deliver the application to the server for execution on demand rather than installing the application in advance in the traditional way. But it’s important to understand that presentation virtualization – running the application in one place and displaying the user interface in another – is not the same thing as application virtualization, which, as we have defined it, has to do with how that application is installed on the desired execution platform and how it behaves when it executes.

The first product to do application virtualization on a large scale for Windows apps was Softricity, by a company called SoftGrid. Softricity evolved into App-V after Microsoft acquired SoftGrid. App-V not only virtualizes the application as described above, it also allows the application to be streamed on demand to the computer that needs to execute it. Application streaming works better than you might think, because it turns out that for most Windows apps, most of the code is seldom (if ever) used. (Just think of all the arcane features in Word or Excel that the average user will probably never use.) So we can stream down just enough code to get the user interface up and running, and continue to stream additional code in the background as features are actually required.

The combination of (1) not having to explicitly install applications on workstations (or Citrix servers, for that matter), and (2) not having to worry about applications conflicting with one another can make life much easier for the IT staff:

• You no longer have to run around from workstation to workstation with a backpack full of installation CDs.
• It can potentially eliminate the old practice of having multiple “silos” of servers within a Citrix server farm to run applications that would not play nicely with one another.
• It makes image management for both workstations and XenApp servers much simpler, because if all of your applications are baked into your OS image, then any application change requires that you change (and regression test) your OS image – but if a streamed application changes, all you have to change is that application.

Meanwhile, back in Fort Lauderdale, Citrix had been working on its own approach to application isolation, which was added to the Enterprise and Platinum editions of Presentation Server when v4.0 was released. This “Application Isolation Environment” then evolved into application streaming with the release of Presentation Server v4.5. For those who are familiar with the Citrix application publishing paradigm, you can now:

• Run the application through the Citrix packaging utility
• Park the resulting package on a shared folder that’s accessible by your target machines
• Step through the process of publishing the application, with a new twist: “I want to make this application available to this group of users, on this set of XenApp servers, and here’s the path to the application package.”

NOTE: Yes, I know that not all applications can be successfully packaged for streaming. But most modern Windows applications can be. Yes, you’ll have to test your apps, or, if you have a lot of apps, use a tool like AppDNA to analyze them for compatibility.

Administrative options allow you to specify whether an application package will be streamed to a XenApp server to be executed there, or streamed directly to the client PC to be executed there, or conditionally streamed (e.g., stream to the client PC if a particular set of criteria is satisfied, otherwise execute the app via XenApp). You can also stream it and cache it on the client PC so, in the case of a laptop, it can be disconnected from the network and continue to run the app for a specified period of time.

So, in a sense, the application virtualization component of XenApp competes with App-V. Prior to the release of XenApp 6, our advice would have been to use XenApp to package and stream apps if your need was primarily to serve up apps to Citrix users, and use App-V if Citrix represented only a small piece of your infrastructure and you primarily needed to package and stream apps to Windows-based workstations. This was mostly based on the fact that App-V needed its own servers to control publishing and streaming of the applications – so if your primary need was to deliver apps to XenApp users, it didn’t make sense to build that App-V control infrastructure when your Citrix farm already had everything you needed to stream apps via XenApp.

One of the features of XenApp 6, however, is the ability to deliver App-V packages through the Citrix application publishing infrastructure, without having to build out the App-V back-end server infrastructure. So now you can use whichever packaging tool you prefer with your Citrix infrastructure. If your staff is more familiar with – or just prefers – App-V, it’s not a problem, because XenApp will support those packages natively.

A discussion of application virtualization wouldn’t be complete without mentioning VMware’s ThinApp. A while back, VMware, seeing which way the competitive winds were blowing, realized it needed an application virtualization solution of its own, so it went out and bought one. In addition to packaging and streaming, ThinApp can also wrap an application up as a free-standing executable, meaning that you could theoretically carry the entire Microsoft Office suite with you on a USB stick, and plug it into any Windows PC anywhere regardless of whether (or which version of) Office was installed on that PC. Of course, if you actually did that with a PC that wasn’t already legally licensed for Office, you’re violating your Microsoft Office license, but I digress.

There are other application virtualization products in the marketplace, but at the moment, the “big three” are App-V, ThinApp, and XenApp. However, as I said way back in the beginning of this post, XenApp is more than just application virtualization. And that will be the subject of my next post.