One of the beautiful things about utilizing a good application virtualization strategy is that is allows for the desktop machine–whether shared hosted desktop via RDS or individual VDI–to remain pure. One of the difficult things about RDS/VDI image management in the first place is one of the same difficulties with traditional PC implementations, and that is that some applications just do not play well together. And when there is an update to one of them, all others can be affected, and therefore, in a very disciplined world, all apps have to be regression tested at that point. That’s a lot of updating.

Here’s how application virtualization works.

In a traditionally-installed operating system with installed applications, the operating system manages all access to registry, shared DLLs, files, folders, and data. Thus, each line of business needs their own image to run from. We call these Application Set Silos. The installation looks something like this.

Conversely, in an operating system where the applications are delivered via a virtual deliver method (such as App-V or Citrix Streamed Applications), the application is segmented off into its own bubble, so to speak. The application has a virtualized view of the underlying operating system, controlled by the application virtualization agent. Anything written to the registry or any of the shared files or folders are virtually kept and optionally saved to the user’s profile folder. That way, if another application has a conflicting DLL or registry entry, it really doesn’t matter. A virtualized application delivery looks something more like this.

Although the up-front installation of an application may seem resource-intensive, the process need only be done once per operating system. This saves a lot of time and money in delivering applications, regression testing, and keeping that desktop image as pure (and stable) as possible.