Server virtualization and application virtualization solve very different problems. Server virtualization addresses server hardware utilization levels and server deployment and availability. Application virtualization addresses application deployment, isolation and management.

Software running on the client system provides support for virtual applications. The client-virtualization layer provides the virtual application with a virtual copy of the system’s file system, registry, and other system I/O points. When the virtual application runs, it interacts with the virtual system environment and doesn’t modify the host system’s physical registry and file system. This capability allows multiple applications that might normally conflict with one another to run together on the same system with no conflicts because each application runs in its own virtual environment. Likewise, it eliminates “DLL hell,” where installing one application can overwrite the DLLs that another application uses. For the enterprise, the biggest App-V advantage probably lies in its no-touch application deployment. App-V is integrated with Active Directory (AD), and the administrator can assign virtual applications to users and groups, and stream those applications to end-user systems without any manual intervention.

App-V does require supporting infrastructure. The application to be virtualized runs through a process called the Microsoft Application Virtualization Sequencer, which breaks the application into pieces that can stream to desktops. The system stores the virtual applications on the System Center Application Virtualization Management Server, which is also responsible for streaming them to desktops, where the virtualization client software executes them.

One benefit of the sequencing process is that only the parts of the application that are necessary are streamed to the desktop. For example, when you run an application such as Microsoft Office (which normally requires several hundred megabytes) through the sequencer, it becomes many smaller pieces that can be individually streamed to the client. Now, when the client initially uses the application, he or she doesn’t need to wait for hundreds of megabytes to stream to the system before it’s useable. Instead, only the code necessary to run the executable part of the requested application streams to the client. The necessary part might be only a few megabytes, but the application will execute normally in the virtual client environment. Later, as the end user requests additional functions and features, only the code needed to execute those features will stream to the client. The virtual applications are executed on the client system, and the code streamed to the client systems remains cached there, so there’s no need to re-stream the parts of the virtual applications that have been previously streamed to the client systems.