If you missed the first article in this series please read Using SoftGrid to Support the Use of Conflicting Applications in a Terminal Service Environment – Part 1.
In the first part of this article series, I explained that Microsoft’s SoftGrid could be used to run otherwise incompatible applications together on a common server. In this article, I will continue the discussion by explaining how SoftGrid works in a Terminal Service environment.
The Application Virtualization Process
As I explained in the first part of this article series, the Windows operating system normally manages resources such as data, system services, and configuration information. An application would normally make calls to the operating system in order to gain access to these various resources.
When SoftGrid is in use, things work a bit differently. SoftGrid uses a component called SystemGuard to virtualize part of the Windows operating system. The basic idea is that SystemGuard makes copies of key system components that are typically used by applications. As such, a virtualized application never communicates directly with the Windows operating system. The application only communicates with SystemGuard. SystemGuard then communicates with the operating system should it require access to any additional operating system resources.
With the way that SystemGuard works, each virtualized application has its own copy of the virtualized operating system components. This means that each application is free to make modifications to its virtual operating environment as needed, without having to worry about impacting other applications or the Windows operating system.
As you can imagine, there are a number of different operating system components that applications must interact with. Each of these components does a different job, so SystemGuard uses different virtualization techniques for each component. In the sections below, I will show you how virtualization works for some of the major operating system components.
The File System
In a true virtual server environment, each virtual server has its own virtual hard drive. The virtual hard drive is a file that acts as a hard drive for the virtual machine. SystemGuard uses a similar technique, but in a much more limited manner.
In a virtual server environment, the virtual hard drive contains a full copy of the Windows operating system and a full set of applications. In contrast, SystemGuard provides a virtual file system for each individual application. This virtual file system contains a partial copy of the Windows operating system.
As I’m sure you recall from Part 1, the goal of using SoftGrid isn’t to completely isolate all of your applications from each other. The only reason for isolating applications is because they are not compatible with each other. From an end user’s perspective, the applications need to function in the usual way and appear to exist within a common operating system.
To accomplish this partial isolation, only the parts of the Windows operating system that are directly related to running the application are virtualized. More specifically, this means that the virtual file system contains the Windows registry, INI files, DLL files, user profiles, etc.
When a virtualized application needs to access the hard disk, SystemGuard directs the request to the virtual file system. If the virtual file system does not contain the necessary information, then the request is redirected by SystemGuard to the server’s real file system.
The Registry
Virtualizing the entire Windows registry would cause a variety of problems. When the registry is virtualized, it is invisible to any application other than the one that it has been assigned to. This means that not even the Registry Editor can read a virtual registry.
The point being that it would be a really bad idea to virtualize the entire Windows Registry. For one thing, the registry is large, and virtualizing the whole thing would waste a lot of system resources. More importantly, a change to the registry made at the operating system level would not be recognized by the virtual registry, and could potentially result in some serious inconsistencies. Suppose that you decided to rename the server, the new name would be applied to the server’s registry, but the change would not be applied to the virtual registries because Windows doesn’t even know that they exist. Therefore, applications would still see the server’s old name.
To avoid these types of problems, only a subset of the registry is virtualized. When a virtualized application needs to read something from the registry, it tries the virtual copy first. If the requested registry key exists in the virtualized copy of the registry, then the key is read. Otherwise, SystemGuard redirects the request to the server’s real registry.
Application Portability
Perhaps the most interesting thing about the way that SoftGrid works is that it allows applications to be truly portable. For many years now, applications have been tightly integrated into the Windows operating system . In addition to writing executable files to the hard drive, applications install things like registry entries, DLL files, and INI file entries. In fact, some applications (such as some of the Symantec products) are so tightly interwoven with the operating system that manually uninstalling them is virtually impossible.
Applications weren’t always written in this way. In the days of DOS, applications were self contained. Sure, there might be a few configuration files or data files, but applications were not embedded into the operating system. It was actually possible to copy an application to a floppy disk and then either run it directly off of the floppy or take the floppy to another computer, offload the files, and run the application. The application ran on top of the operating system, not in it.
The remarkable thing about SoftGrid is that it brings back this type of simplicity (although in a slightly different manner). Applications are packaged along with virtual copies of all of the operating system components that they depend on. This means that it is possible to move an application from one server to another without having to perform a complicated uninstall / reinstall procedure.
Another reason why SoftGrid allows applications to be portable is because SoftGrid is integrated into Active Directory. When an administrator needs to install an application onto a server, they do not actually have to install the application, they assign it. SoftGrid is equipped with a Web interface that makes it possible to publish applications to your Terminal Servers, manage licenses, etc. If at a later time you decide that you need to remove an application from your Terminal Server, you can simply use the management console to disable the application. There is no need to uninstall it, because it was never actually “installed” in the first place.
Conclusion
In this article series, I have explained that Terminal Servers are often underutilized because incompatibilities in applications sometimes make it impossible to run all of the necessary applications on a single terminal server. However, a new Microsoft product named SoftGrid uses application virtualization to make it possible to run conflicting applications on a single terminal server. If you would like to learn more about SoftGrid, you can visit the Microsoft SoftGrid Web site at: http://www.softricity.com/index.asp
If you missed the first article in this series please read Using SoftGrid to Support the Use of Conflicting Applications in a Terminal Service Environment – Part 1.
