App Volumes components

We will start by covering an overview of the different core components that make up the complete App Volumes solution—a glossary, if you like. These are either components of the actual App Volumes solution or additional components that are required to build your complete environment.

App Volumes Manager

App Volumes Manager is the heart of the solution. Installed on the Windows Server operating system, App Volumes Manager controls the application-delivery engine and provides you with access to a web-based dashboard and console from which you can manage your entire App Volumes environment.

You will get your first glimpse of App Volumes Manager in Chapter 4, Installing and Configuring the App Volumes Software, when you complete the installation and start the post-installation tasks, where you will configure details for your virtual host servers, storage, Active Directory, and other environment variables.

Once you have completed the installation tasks, you will use App Volumes Manager to perform tasks such as creating new and updating existing AppStacks, creating Writable Volumes, and then assigning both AppStacks and Writable Volumes to end users or virtual desktop machines.

App Volumes Manager also manages the virtual desktop machines that have an App Volumes Agent installed. Once a virtual desktop machine has the agent installed, it will appear within the App Volumes Manager inventory so that you are able to configure assignments.

In summary, App Volumes Manager performs the following functions:

• Orchestrating the key infrastructure components, such as Active Directory, AppStack/Writable Volumes attachments, and the virtual hosting infrastructure (ESXi hosts and vCenter Servers)
• Managing the assignment of AppStacks/Writable Volumes to users, groups, and virtual desktop machines
• Collating AppStacks and Writable Volumes usage
• Providing a history of administrative actions
• Acting as a broker for App Volumes Agents for the automated assignment of AppStacks and Writable Volumes when virtual desktop machines boot up and the end users log in
• Providing a web-based graphical interface from which to manage the entire environment

Throughout this book, you will see the following graphic used in drawings or schematics to denote App Volumes Manager:

App Volumes Agents

An App Volumes Agent is installed onto a virtual desktop machine to which you want to be able to attach AppStacks or Writable Volumes and it runs as a service on that machine. As such, it is invisible to the end user.

When you attach an AppStack or Writable Volume to a virtual machine, then the agent acts as a filter driver and takes care of any application calls and file system redirects between the operating system and the AppStack or Writable Volume.

Rather than you seeing your AppStack, it appears as an additional hard drive within the operating system. The agent makes the applications appear as if they were natively installed. So, for example, the icons for your applications will automatically appear on your desktop/taskbar.

The App Volumes Agent is also responsible for registering the virtual machine with App Volumes Manager, as we discussed in the previous section.

Throughout this book, you will see the following graphic used in drawings or schematics to denote an App Volumes Agent:

App Volumes Agents can also be installed onto an RDSH host server to allow the attachment of AppStacks within a hosted-applications environment. We will cover this in detail in Chapter 11, Deploying App Volumes in a RemoteApp Environment.

AppStacks

An AppStack is a read-only volume that contains your applications and is mounted as a VMDK file (VMware environments) or a VHD file (Citrix and Microsoft environments) on your virtual desktop machine or RDSH host server.

An AppStack is created using a provisioning machine that has an App Volumes Agent installed on it. Then, as part of the provisioning process, you mount an empty container (VMDK or VHD file) and then install the application(s) as you would normally do. The App Volumes Agent redirects the installation files, file system, and registry settings to the AppStack. Once this is completed, the AppStack is set to read-only mode, which allows one AppStack to be used for multiple users. This helps reduce the storage requirements (an App Stack is also thin-provisioned), but also allows any application that is delivered via an AppStack to be centrally managed and updated.

AppStacks are then delivered to the end users either as inpidual user assignments or via group membership using Active Directory.

Throughout this book, you will see the following graphic used in drawings or schematics to denote an AppStack:

We will cover AppStacks in more detail in Chapter 6, Working with AppStacks.

Writable Volumes

One of the many use cases not best suited to a VDI has been that of developers, as they need to install various applications and her software. To cater to this use case, you need to deploy a dedicated, persistent desktop to meet their requirements. This method of deployment is not necessarily the most cost-effective one, potentially requiring additional infrastructure resources and management.

With App Volumes, all this changes with the Writable Volumes feature. In the same way that you assign an AppStack containing preinstalled and configured applications to an end user, with Writable Volumes you attach an empty container as a VMDK file to their virtual desktop machine, into which they can install their own applications.

This virtual desktop machine will be running an App Volumes Agent, which provides a filter between any application that the end user installs into the Writable Volume and the native operating system of the virtual desktop machine. The user then has their own drive onto which they can install applications.

Now, you can deploy non-persistent, floating desktops for these users and attach not only their corporate applications via AppStacks but also their own user-installed applications via a Writable Volume.

Throughout this book, you will see the following graphic used in drawings or schematics to denote a Writable Volume:

The provisioning virtual machine

Although not an actual part of the App Volumes software, a key component is a clean virtual desktop machine to use as a reference point to create your AppStacks from. This is known as a provisioning machine.

Once you have your provisioning virtual desktop machine, you firstly install an App Volumes Agent onto it. Then, from App Volumes Manager, you initiate the provisioning process, which attaches an empty VMDK file to the provisioning virtual desktop machine and then prompts you, the IT admin, to install the application.

Note

Before you start the installation of the application(s) that you are going to create as an AppStack, it's good practice to take a snapshot. This way, you can roll back to the clean state of your virtual desktop machine prior to installation, ready to create the next AppStack.

Throughout this book, you will see the following graphic used in drawings or schematics to denote a provisioning machine:

We will cover the use of the provisioning machine in more detail in Chapter 6, Working with AppStacks, when we create our first AppStack.

Storage groups

Again, although not a specific component of App Volumes, you have the ability to define storage groups for storing your AppStacks and Writable Volumes.

Storage groups are primarily used to provide replications of AppStacks and to distribute Writable Volumes across multiple datastores. With AppStack storage groups, you can define a group of datastores that will be used to store the same AppStacks, enabling replication to be automatically deployed on those datastores.

With Writable Volumes, only some of the storage group settings will apply attributes to the storage group, for example, the template location and distribution strategy.

The distribution strategy allows you to define how Writable Volumes are distributed across the storage group. There are two settings for this, as follows:

• Spread: This will distribute files evenly across all the storage locations. When a file is created, the storage location with the most available space is used.
• Round-robin: This works by distributing the Writable Volume files sequentially, using the storage location that hasn't been used for the longest time.

Throughout this book, you will see the following graphic used in drawings or schematics to denote storage groups:

Now that you have been introduced to the core components that make up an App Volumes deployment, in the next section, we will start looking at how all these fit together, and we will take a look at the architecture.