VMware AppVolumes–Writable Volumes

CloudVolumes-SquareWelcome to the fifth and long over due post in my VMware AppVolumes series. In this post I am going to cover my favorite feature in AppVolumes, Writable Volumes. Writable Volumes can be used to capture either user profile date, user installed applications, or both. Each of these options is provided by three Writable Volume “Templates” that provided via AppVolumes by default. The three templates are a follows:

  • Template_uia_only – Allows for the use of “User Installed Applications” when mounted. Note that users still the appropriate OS permissions to install applications
  • Template_profile_only – Leveraging a filter driver in the AppVolumes agent, user profile settings will be be redirected and saved to the Writable Volume
  • Template_uia_plus_proflie – The best of both worlds listed above. User installed applications and user profile changes are saved and persisted to the writable volume.

With the option to leverage Writable Volumes in a Horizon View environment (bundled with the Enterprise Suite or purchased standalone) it will definitely help ease the burden of delivering the appearance of a dedicated desktop in a floating, non-persistent environment. The below example walks through the process of creating Writable Volumes for a group of users and then seeing it in action in my Horizon View environment.

The Prerequisites

In order to give the appearance of complete desktop experience on a floating, non-persistent desktop utilizing AppVolumes the following have been created in my lab environment:

  • Creation Active Directory Security Group AppVolumes_Writable_Profile
  • Active Directory user accounts created and assigned to the AppVolumes_Writable_Profile security group (AppVol01, AppVol02, etc)
  • Creation of a floating, non-persistent desktop pool in VMware Horizon View 6.0.1

Creating Writable Volumes

With the assumption that you have already logged into the AppVolumes Manager Dashboard, select the Volumes menu context and click on the Writables tab. Finally click on the Create Writable button:


Since I will be creating Writable Volumes for a group of users I entered AppVolumes_Writable in the Search field. From the output you can see the three Active Directory groups I have created, one for each type of Writable Volumes templates:


For this post I will be using the Template_profile_only  Writable template so I selected the corespondng Active Directory group, AppVolumes_Writable_Profile. With the Active Directory group selected additional AppVolumes options are available. I selected to use my VSAN Datastore and the default destination path to hold the Writable Volumes. The last option is when you select the type of Writable Volumes template to use:


Confirm the volumes creation:


During the creation process I popped over to my vCenter connection and as you can see below the tasks to create the new VMDK’s finished. Browsing the Datastore you can see the four unique VMDK’s created per use (notice the VMDK file names). One other thing to point out, each of the VMDK’s are Thin-Provisioned and configured with a maximum size of 10GB per VMDK by default:



Back in the AppVolumes Manager dashboard we can see each of the volumes that were created and their current status:


And just like that we are ready to give the volumes a test.

Working with Writable Volumes

With the Writable Volumes up and running it is time to see what they can do. As mentioned for our test scenario I am going to log into my Horizon View environment using a test account. The desktop pool is set up for floating, non-persistent so each time I login I will get a different desktop. After login I verified in the AppVolumes Management dashboard the volume status. As you can see below the volume for AppVol1 is Attached:


Logging into the View Administrator console I can see the account AppVol1 is logged into desktop VSAN-Win7-NP03:


From the user perspective there is no evidence that an additional disk has been added:


Viewing the properties of the virtual desktop we can see the additional hard disk for the Writable Volume has been mounted to the virtual machine:


While the AppVol1 user doesn’t know he is running on a VM, he changes his desktop background to reflect his true feelings. Along with the new desktop he changes the default home page for IE and downloads the ISO for VMware vCenter installation:


With downloading the ISO image to the Desktop we can check the size of the Writable Volume VDMK as the users profile is being redirected. Browsing the Datastore we can see that the VMDK for AppVol1 is roughly at 3.7GB in size:


With a couple of changes made, I will logoff the AppVol1 user and reconnect. With the login completed, again a peek into View Administrator shows us connected to a different desktop:


From the user perspective he still has his favorite desktop background and ISO image he downloaded during his previous session. Launching Internet Explorer by default takes him to his favorite blog:



Though this was a quick walk through setting up and using Writable Volumes one thing is easy to see, the flexibility in redirecting a user profile (or installed applications) to a VMDK eases the administration of user persona. No more clunky GPO settings or profile shares sitting on your network. One thing to watch out for is the default 10GB VMDK sizing per user, but in a future post I will cover creating a new template that will allow for smaller user disks.

Thanks for reading,


%d bloggers like this: