“When are you going to publish the list of applications Citrix XenApp can virtualize with Application Streaming?”
It’s a simple question, but the answer is not. There’s just no way to test all of the applications that are out there, especially when you consider that some of the best candidates for virtualization are those troublesome homegrown apps that only exist in customers’ environments.
The Application Streaming feature of Citrix XenApp (the new name for Presentation Server) is designed to support all Windows applications and most run just fine when virtualized on desktop machines. We’ll do everything we can to make a Windows app run in isolation and there’s a great article on the Citrix Knowledge Base with tips and tricks on troubleshooting problems, but there are exceptions.
It’s a simple fact that certain kinds of applications cannot be isolated and therefore are not good candidates for client-side application virtualization. These applications contain components that cannot be successfully isolated, such as:
• Device or kernel drivers: We are working on this, but as of today, isolation environments cannot isolate device or kernel drivers. For example, if the application installs and depends on a driver to function, it does not work in an isolation environment.
• Windows services: Some applications install and rely on a Windows service to function correctly. These applications cannot be isolated. (We are also working on this. Stay tuned. To verify whether an application attempted to install a service, examine the Event Viewer’s Application Log. Look for messages with source CtxSbxAppMsg)
• Windows class names or window names: Isolation environments do not isolate Window class names or Window names. Applications that use Windows messages as an inter-process communication (IPC) mechanism will not work correctly with the Application Streaming feature.
• COM+ applications: Support for COM+ is limited, but fortunately, this isn’t a big hindrance to most applications. There’s another Knowledge Base article on this. COM and OLE are fully supported.
Just because an application installs things in the above list does not necessarily mean that the application will not work to the customer’s satisfaction. One way to get around these limitations is to install the problematic component locally. The isolation environment in which the apps are virtualized can be tuned to allow communication between the application and local environment. This works with some license services that run in applications, for instance. When the service is installed locally, the application can be virtualized without a problem. Another workaround is to just turn the component off, if this can be done without impacting the application itself.
We can’t guarantee that these will work for every application, but they will for many. Just be sure to test thoroughly to make sure that the application isn’t adversely affected. And let me know what you find out. Some of the best feedback comes from people in the field under the gun to make something work.