Virtualizing Desktops and Apps with Windows Server 2012 R2 Inside Out: Planning and Implementing App-V

Virtualization usage has been expanding throughout the last several years. Although many IT administrators are now familiar with desktop and server virtualization, application virtualization is a lesser-known technology that is expanding rapidly. Simply put, application virtualization is a technology that delivers applications to computing devices in isolated containers without the need to perform a standard application installation on each computing device.

App-V provides a new way to deliver applications to users, a new way to centrally manage applications, and additional application capabilities for complex environments. Virtualizing applications, when appropriately planned and implemented, is an effective supplement to desktop and server virtualization and can help organizations move closer to cloud computing.

Overview of App-V

Microsoft Application Virtualization (App-V) is Microsoft’s application virtualization technology. It is part of the Microsoft Desktop Optimization Pack (MDOP). MDOP is available to Microsoft Software Assurance customers and to Microsoft MSDN subscribers. It is a suite of desktop optimization applications that help IT administrators deploy, manage, and troubleshoot desktop computing environments. The newest version, at the time of this writing, is App-V 5.0 Service Pack 3.

Benefits of App-V

You know that App-V is Microsoft’s application virtualization technology, and you have an idea of how to access it. But, to fully appreciate it, you should have a good understanding of its capabilities. The core capabilities that you can deliver with App-V are the following:

• Run multiple versions of applications at the same time You can use App-V to run different versions of applications concurrently on the same computer. For example, it’s possible to run Internet Explorer 9, Internet Explorer 10, and Internet Explorer 11 concurrently if they all are set up as App-V applications; otherwise, you can’t run multiple versions of Internet Explorer side by side on the same computer. It’s also possible to use App-V in conjunction with Remote Desktop Services (RDS). This allows users to run applications side by side on Remote Desktop Session Host (RD Session Host. servers.
• Minimize application conflicts Sometimes two or more applications conflict with one another because of dynamic-link library (DLL) or application programming interface (API) conflicts. When you deliver these applications as App-V applications, however, there isn’t a conflict because each App-V application runs in its own isolated environment.
• Simplify application removal App-V applications do not install locally, which makes it easier to remove them. Clean removal isn’t always possible with applications that install directly on Windows-based clients, even if an application has been designed to remove all files and settings when it uninstalls. Virtualized applications are removed easily after a user signs out from a computer.
• Simplify application upgrades Instead of upgrading a locally installed application on all computers in your organization with a hotfix. service pack, or new version, the modular nature of virtualized applications means that you can replace one version of an application with an updated version with less effort. You only need to update an application on the App-V server(s), and clients receive the latest version of the application from the publishing server the next time they launch the application.
• Minimize license-compliance risks App-V has application metering functionality that enables you to detect every use of a virtualized application to ensure license compliance.
• Scale infrastructure You can add publishing servers to an App-V deployment as necessary to ensure that service levels are maintained as demand grows.
• Take advantage of client hardware resources Even though App-V applications do not install locally, they can use a local computer’s processor and RAM resources. In environments where client computers have adequate hardware resources, this can create a better experience for users than running applications on an RD Session Host server would.
• Allow users to use roaming applications If applications stream with App-V rather than install locally, users can sign in to any computer that has an App-V client and quickly access their applications. You also can configure App-V to work with user virtualization to allow users to have application settings and data for App-V applications that roam across client computers.
• Give users quick access to their applications Imagine a scenario in which a user needs to have an application installed. In many environments, a routine application installation requires several steps, such as copying the installation files to the client computer, manually performing the installation, manually performing application updates, and cleaning up the installation files. With App-V, you can just add the users to a group, and they can immediately run the application through App-V.

Differences between standard and virtualized applications

In a traditional IT environment, applications are installed on each computing device. For this discussion, we’ll refer to the traditional installed application as a standard application. During a standard application installation, the computing device is modified to meet the application’s requirements. For example, a common installation of a standard application would include the following steps:

The application’s files are copied During the installation, the installer copies the necessary application files to a specified folder. During this process, the files often are uncompressed first.

The registry is modified to support the application Most applications add to the registry to support the installation and running of the application. In addition, it’s common for existing registry keys and values to be modified to support automatic application startup on boot and to set any required dependencies.

DLL files are registered Often,.dll files must be registered during the installation.

Permissions are configured You often need to set permissions to configure which user(s) can run the application, which profiles the shortcuts are added to, and which users can modify configuration files.

Shortcuts are added to the device Many applications add a shortcut to the Start screen, desktop, and taskbar. Additionally, it is common for applications to add a tray icon for quick user access.

App-V applications, which are virtualized, aren’t installed onto computing devices. Instead, they are packaged for deployment. In App-V. packaging an application for deployment is known as sequencing an application. Later in this chapter, we’ll discuss sequencing further. For now, let’s examine the differences between an App-V application deployed to a computing device and a standard application installed locally on a computing device. For applications deployed with App-V, the following characteristics highlight the different methods by which applications interact with the computing device:

App-V applications run in their own isolated environment This reduces application conflicts and application crashes impacting other applications or the operating system and provides the foundation to allow multiple versions of applications to run at the same time.

App-V applications use a virtual registry This reduces installation difficulties and application conflicts and improves the stability of a client computer because applications aren’t sharing a single registry.

App-V applications use virtual file systems This reduces conflicts by ensuring that applications don’t overwrite shared files.

App-V applications use virtual services This also reduces conflicts because virtual services do not have dependencies on other non-virtual services and provide isolation from other virtual services.

App-V applications are installed by being packaged and delivered to computing devices. App-V applications only need to be updated once, by updating the application’s package on the App-V server. By reducing the number of times you have to install and update an application, you can greatly reduce the number of hours required to manage your application infrastructure.

Placing and functionality of the virtualization engine

Virtual applications require access to resources on a host computer. Access typically uses a system request that a virtualization engine needs to intercept. The engine provides functions for capturing an application’s system call and manipulating it where needed.

Interception in user mode

Applications run in user mode and perform operations on system services that reside in kernel mode. When an interception occurs in user mode, the virtualization engine must be placed over the native API layer. Some applications call the functions of the native API directly instead of by using Windows API.

One advantage of the user mode strategy is that the virtualization engine doesn’t have to filter between system calls of different applications. The virtualization engine only works with an application that it built for the virtual environment.

Interception in kernel mode

In contrast, if the virtualization engine operates in kernel mode, it can intercept all system calls before they reach Windows executive services. The advantage is that it is easy to loosen the isolation of applications and let them share the same virtual environment. This enables you to create dependencies between packages, similar to working with middleware or plug-ins. However, the agent that builds the virtual environment must install natively on a computer to gain the required privileges for an interception in kernel mode. In this case, all applications that run on the host machine are affected. Furthermore, the virtualization layer captures system calls from all applications and must filter the processes to respond to every call correctly.

App-V implements a hybrid approach by identifying the locations of resources that the application requires. While the application is running, the virtualization engine ensures that function calls are modified only if they request a path inside the virtual file system or a key inside the virtual registry. When the engine runs in kernel mode, it also must check which package to consult to find the rules, because it will receive function calls from several running applications that belong to different packages.

The virtualization layer must intercept and redirect requests to the file system and registry to virtual counterparts that contain the files and keys that belong to a certain application. To decide which function calls to intercept and which to handle as usual, the virtualization layer needs rules. These rules generate when the App-V Sequencer, which collects all the files and registry keys that the installer creates or modifies, monitors an application’s installation. Then, at the application’s runtime, the virtualization engine ensures that function calls are modified only if they request a path inside the virtual file system or a key inside the virtual registry.