If you would like to be notified when Brien Posey publishes Using SoftGrid to Support the Use of Conflicting Applications in a Terminal Service Environment – Part 2, please sign up to our Real time article update newsletter.
One of the problems with hosting applications in a Terminal Service environment is that not every application can be run alongside every other application. For example, two applications may require different versions of the same DLL file, meaning that you can run one application or the other, but not both.
Most of the time, applications do play nice with each other, but application conflicts can be especially problematic when upgrading from one version of an application to another. For example, Microsoft recently released Office 2007. Office 2007 cannot run on the same system as the previous version, Office 2003. Therefore, if you were contemplating an upgrade from Office 2003 to Office 2007, you would have to make a choice. One option would be to toss caution to the wind and go ahead with the upgrade, and hope that everything works correctly. In most organizations Office would be considered a critical application, so this upgrade strategy probably isn’t advisable. Another option would be to add another terminal server to your organization and run Office 2007 on the new server, while your old server continues to run Office 2003.
This strategy is much safer than a reckless upgrade, but it tends to be expensive. After all, there is the cost of the new server hardware, the software licenses for the new server, and of course any necessary overtime that you have to pay the IT staff during the installation. Once the server is up and running, there are ongoing maintenance and support costs. I could go on, but I think you get the idea. Adding an additional server to an organization involves making a large and ongoing financial commitment.
There is a third option available to you when you need to run conflicting applications. This option involves taking advantage of a somewhat “new” technology called application virtualization.
Over the last couple of years, another virtualization technology has gained popularity; server virtualization. Application virtualization and server virtualization are two completely different technologies that operate on similar principles.
Server Virtualization
As you probably know, server virtualization is a technology that allows you to run multiple virtual machines on top of a host operating system. Each of these virtual machines behaves as an independent computer, and runs its own operating system and its own set of applications. For all practical purposes, the host operating system (the computer’s primary operating system) as well as any other virtual machines are invisible to a virtual machine.
Server virtualization definitely has its place, but it isn’t really practical if you just need to run conflicting applications. As I already explained, each virtual server runs its own operating system. As you are no doubt aware, Windows operating systems consume lots of system resources. Since the server is burdened with running its primary operating system, plus the virtual machine’s operating system, it does not perform nearly as well as it would if it were running a single operating system.
Another issue that makes server virtualization a poor solution to running conflicting applications is that each virtual machine must be independently maintained in the same way that you would maintain a physical server. Even if resource consumption and server maintenance were not issues, machines running on separate virtual servers are as isolated from each other as they would be if they were running on separate physical servers. In a non-terminal service environment, this would mean that moving data between applications using OLE or by using cut and paste would be impossible.
Application Virtualization
Application virtualization works in a similar manner to server virtualization, except that all of the applications run within a common operating system. This means that applications can exchange data with each other using OLE or cut and paste, just as they could if they were not virtualized. In fact, a virtualized application looks and behaves very similarly to the way that they would if they were not virtualized.
In order to understand how application virtualization works, it is necessary to understand how applications normally run in a Windows environment. For the sake of simplicity, let’s forget about the Terminal Services for the rest of this article. In Part 2, I will discuss how application virtualization works with the Terminal Services.
When an application runs within a Windows operating system, there are three sets of resources that the application typically accesses; data, system services, and configuration information.
Data can mean a lot of different things, but from the standpoint of a generic application, data refers to a user’s individual data. More specifically, the application needs to be able to access a user’s profile folder and of course the user’s documents folder.
System services refers to all of the individual operating system components that the application absolutely could not run without. This refers to everything from screen fonts to operating system services. Some other system services include COM, OLE, DCOM, and cut and paste.
The third set of resources that applications depend on is configuration information. Configuration information is stored in the Windows registry, various .INI files, and in some cases, in DLL files.
Generally speaking, applications need to be able to write data to and read data from these three types of resources. When an application is virtualized, the application maintains its own set of data, system services, and configuration information. This set of system resources is created at the time that the application is installed. The nice thing about it is that with the way that these system resources are created, the application will not make any changes to the computer’s operating system during the installation process. For example, most installers will create various registry entries as an application is installed. When application virtualization is in use, installers write registry entries to a dedicated location that is accessible only to the application that is being installed (these registry entries are also indirectly accessible to the operating system as well). Being that the Windows registry remains untouched, there is no danger of conflicting registry entries.
Conclusion
As you can see, application virtualization is ideal for situations in which you want to run conflicting applications on a common machine without resorting to using server virtualization. In Part 2 of this article series, I will explain how application virtualization works, in much greater detail. I will also explain how applications can be virtualized in a Terminal Service environment.
If you would like to be notified when Brien Posey publishes Using SoftGrid to Support the Use of Conflicting Applications in a Terminal Service Environment – Part 2, please sign up to our Real time article update newsletter.
