Let's start with our typical virtual desktop environment. Although the desktop operating system has been abstracted from the underlying hardware, the applications are still tightly integrated into that operating system. The ideal virtual desktop solution is to deliver fully stateless desktops and have the user elements added on the fly, depending on the user's profile. The fully stateless desktop model provides the most cost-effective solution by being easier to manage and requiring less infrastructure.

Today, there are a number of tools that can take care of delivering the user personalization, user data, and user profile elements to the desktop; however, applications are still delivered either as part of the base operating system image or using some form of application remoting or publishing.

App Volumes provides a layer of abstraction between the operating system and applications by delivering the applications in separate containers. These containers are called AppStacks and they integrate seamlessly into the operating system of the virtual desktop machine.

The following diagram shows the traditional, static model on the left and the App Volumes on-demand delivery method on the right:

As well as application containers, App Volumes provides the end users with their own container or virtual hard disk, into which they can install their own applications. This container, called a Writable Volume, "follows" them when they log in to different virtual desktop machines, bringing all their applications with them.

The following diagram illustrates the App Volumes model of having application containers (AppStacks) and user-writable containers (Writable Volumes):

So how do you get started? The first thing you do is create or capture an application that can be delivered by App Volumes. You start the process by installing the application on a virtual desktop machine, which is referred to as the provisioning machine. This provisioning machine is basically a vanilla installation of the operating system, with no applications installed.

When you start the capture process, an empty Virtual Machine Disk (VMDK) file, called an AppStack, is mounted on to the provisioning machine. Next, you start the application installation as you would normally do. All the files associated with this application are then redirected to the AppStack or VMDK file.

Once you have completed the capture process, the AppStack is set to read-only mode and is ready to be assigned to end users based on their Active Directory group membership. AppStacks can also be assigned to individual users or other groups.

For the users to be able to access the applications in their assigned AppStack, an App Volumes Agent runs on their desktop, mounting the VMDK file and making the application appear as if it were fully integrated and installed locally rather than running from an additional drive. This is how applications are able to be delivered to a user in real time, as AppStacks can be assigned on the fly.

As well as the applications that get delivered as part of the AppStack, a user is able to have their own disk or VMDK file on which they can install their own applications. This is called a Writable Volume and will also follow the user when they roam among virtual desktops, making it perfect for developers to have non-persistent virtual desktops.

In the next chapter, Chapter 2, Architectural and Feature Overview, we will dive a little deeper into what exactly each of the different components does, and then in Chapter 6, Working with AppStacks, and Chapter 7, Working with Writable Volumes, we will take a deeper dive into how App Volumes, AppStacks, and Writable Volumes work.

So the question is what App Volumes does differently and what benefits it will bring.

As we have already discussed, App Volumes gives you the ability to deliver applications to users in real time; however, you also benefit from being able to manage application life cycles much more easily, as well as a reduction in costs.

Once you have created your AppStack, it's simply a case of a few clicks to assign it to a user or group of users. Conversely, it's that simple to remove it as well. This means that, when a user requests a new application, for example, it's very easy to assign it to them without having to go and install it.

If you are running a virtual desktop environment, then App Volumes helps you drive towards achieving a truly stateless desktop since applications are immediately and dynamically made available upon login, or even while the user is already logged in.

A question that comes up most of the time when talking about App Volumes and application delivery in general, in a VMware context, is this: which technology should you use and when?

People often ask whether or not App Volumes is going to replace ThinApp and Mirage, and whether these technologies are still required. The key thing to point out here is that each solution addresses a specific use case, and they actually do not all do the same thing. In fact, combining all three delivers a more complete solution.

To the question of whether or not App Volumes is going to replace ThinApp and Mirage, the answer is no. All three technologies are key to the VMware vision and strategy, and won't be going anywhere for the foreseeable future.

In this section, we will discuss which solution you will need, why you will need it, and then see how they are complementary to each other.

Let's start with Mirage. Mirage is a centralized, Windows image-management solution, primarily designed to manage physical desktop PCs and laptops. It is also used to deliver the containerized desktop solution, Horizon FLEX, for delivering virtual desktops in a BYOD (short for Bring Your Own Device) environment on both Mac and Windows laptops.

Next up is ThinApp. ThinApp is an application virtualization/packaging technology that is primarily used when you need isolation between applications. For example, you might need to deploy an older version of an application that doesn't run on your current operating system version. You may also need to run multiple versions of applications; for example, you may need to run different versions of Internet Explorer. This is one of the key differences in what the solutions deliver. ThinApp is an application-packaging technology. Mirage and App Volumes do not provide any packaging capabilities.

We have outlined what these technologies deliver and we have talked about them being complementary. Depending on your use case, you can use them in combination.

When it comes to managing a physical desktop environment or delivering containerized desktops with Horizon FLEX, Mirage is the technology you should use. If you have applications that need to be isolated, you will combine them with ThinApp to create Mirage application layers, with the application layers containing those ThinApp packages.

If we now take virtual desktop environments and, in particular, those that are built using linked clones and have a floating user assignment, then App Volumes will be the ideal solution for this use case. When they log in, end users will be assigned a vanilla desktop from a pool of floating desktops. Their applications will then be deployed by simply mounting the relevant VMDK file, thus containing the applications in real time.

That was the model for non-persistent, linked, clone desktops, but what about virtual desktops that are built using full clones and have a persistent assignment? For this use case, all three solutions can be combined: Mirage to manage the operating system element, App Volumes to deliver the applications, and the applications potentially being packaged using ThinApp, if you require the isolation between applications.

The VMware documentation for the latest version of App Volumes talks about being able to deliver AppStacks to physical desktops. Although this is possible, Mirage would be a better option for managing physical desktops.

As you can see, there are several use cases that lend themselves to the different technologies, and this is the key to deciding which ones to use and when.

The following diagram shows a high-level overview of how the technologies complement each other and work together:

In the next section, we will discuss the key use cases for App Volumes in more detail.

There are several key use cases for deploying App Volumes within your environment.

The first of these use cases is deploying App Volumes within a virtual desktop infrastructure environment.

There are several ways in which you can purchase and license App Volumes.

Firstly, App Volumes is a standard component of the Horizon Enterprise Edition license.

The second option is to purchase App Volumes as a part of the VMware Horizon Application Management Bundle. This bundle includes all the components except the core VDI solution, Horizon View, and is designed to complement existing Citrix environments.

Lastly, you can purchase App Volumes as a standalone product as part of an à la carte list of solutions. Whichever option you choose to purchase App Volumes, the product itself is licensed on a per-concurrent-user basis.

Now that we have covered the introduction to App Volumes, let's just take five minutes to introduce you to how this book works and what you will need to get the most out of it.

This book will guide you through the key use cases for App Volumes, from the theory of how it works and how to design a solution, to the more practical elements, such as installation.

Each section of this book has been written based on everyday, real-world experiences of working with the product in both production and proof-of-concept/pilot environments.

In parallel with the chapters, you can set up your own lab environment, which will cover practical examples of how the technology works, giving you the option to follow the steps and try them for yourself. This can either be as an exercise while reading the chapters or to assist you in setting up a proof-of-concept, pilot, or live deployment.

Accompanying this book, as previously mentioned, is an Example Lab that you can build along the way. In this introductory section, we are going to cover the requirements for this lab and what it will look like. The lab is optional, and you can choose to build your own environment.

What you will need for the lab

The lab environment used in this book was built on a Dell PowerEdge R720xd LE configured with two E5-2680V2 2.8-GHz 10-core processors and 64 GB RAM, running VMware vSphere 6 as the hypervisor.

Although the server had internal storage, the lab was built using a Tintri all-flash array. By using Tintri and its VM-aware capabilities, you can monitor right down to the virtual-machine level.

The reason I chose Tintri storage is the fact that it has been developed from the ground up for virtualized environments removing contention points and collision domains such as the LUN construct. Tintri was very easy to deploy. It was done in just under 15 minutes. The folks at Tintri have created a new storage category. They call it VAS (short for VM Aware Storage). This "awareness" is backed by Tintri's analytics engine learning the behavior of individual VMs underpinned by an intelligent filesystem. The architecture is designed to adapt to the fluidity that comes with virtualized workloads enabling it to deliver the right quality of service where and when it is needed. This makes Tintri ideal for VDI-type deployments as it has the ability to respond to performance bursts that can result from use cases such as App Volumes.

All of this was used to host the following virtual machines. The computer names of the virtual machines are shown in brackets and will be referred to in the lab examples throughout the book:

• Windows Server 2012 R2: configured with AD, DNS, and a file server (DC)
• VMware vCenter Server Appliance (VCSA)
• VMware ESXi v5.5 host server (ESX-1)
• Windows Server 2012 R2: App Volumes Manager (APP-VOL-MGR)
• Windows Server 2012 R2: Microsoft SQL 2008 Express*
• Windows Server 2012 R2: configured with the RDSH role**
• Windows Server 2012 R2: Horizon View Connection Server (VIEW-CS)***
• Windows 7: AppStack-provisioning desktop (AV-PROVISION)
• Windows 7: used as a virtual desktop machine (WIN7-DESKTOP-1)
• Windows 7: used as a virtual desktop machine (WIN7-DESKTOP-2)
• Windows 7: virtual desktop machine delivered by Horizon View (VIEW-1)
• Windows XP: used for ThinApp Setup Capture (WINXP-DESKTOP-1)

* In the Example Lab, the Microsoft SQL Express server is also installed on the same server as the App Volumes Manager. As this lab is just for testing, it is fine to configure it in this way. This is not recommended for production environments.

** Only required in Chapter 11, Deploying App Volumes in a RemoteApp Environment. If you don't plan to install and test this feature, there is no need to deploy an RDSH server.

*** Only required in Chapter 9, Horizon View Integration. If you don't plan to install and test Horizon View, there is no need to deploy a Horizon View connection server.

If you plan to build a lab as you follow the chapters, it's worth building the infrastructure detailed here beforehand. Build and install all the virtual machines, but with the exception of installing any of the App Volumes software components.

In writing this book, VMware vSphere 6 has been used as the hypervisor to host all of the VMs used in the Example Lab, but you could also run this in VMware Workstation.

If you choose not to follow the steps described, they will still help by providing you with a reference and foundation for building and managing your own environment.

A schematic diagram of the core lab environment used for the examples is detailed in the following diagram:

The next schematic diagram shows the optional lab components for integrating App Volumes with VMware Horizon View and RDSH servers:

The file server in the lab environment was used to host a shared folder containing all the installation files so that they are accessible by all the other virtual machines.

This final schematic diagram shows the optional lab for Chapter 8, Delivering ThinApp Packages with App Volumes:

We also require an administrator account and a number of Organizational Unit (OU) groups and user accounts.

For administering App Volumes, a group called AppVol Admin was created. The administrator account was then added to this group. You can, of course, create other App Volumes administrator accounts.

In addition to the administrator account, we have created a number of Active Directory groups to reflect different departments. In each group, there are a few user accounts. These have been set up as shown in the following table:

These users and groups will be used throughout the Example Lab to demonstrate user assignments.

In this chapter, we have covered a high-level introduction to App Volumes, looking at what it is, how it works, and what it can deliver.

We then went on to cover exactly where App Volumes fits into the overall VMware EUC portfolio, bearing in mind that products such as ThinApp and Mirage seem to deliver almost the same functionality.

Finally, we saw how to get the most out of this book, and you were introduced to the Example Lab that you can build along the way in each chapter.

In the next chapter, Chapter 2, Architectural and Feature Overview, we will start to look a little deeper into each of the App Volumes components.