Feature Request Discussion

[ChrisBCarlson]

Ok, First of all app volumes initially is a great product. However i think there are a few things that they have missed to really make this product next level. From my experiance so far it would be great to have the following.

-Insight via the web gui on used storage on a writable volume.

-Instead of a long guide on creating a new template just to change the size of a writable or appstack. there should be a workflow to easily extending/creating the size of a disk.

-Filters for a writable volume to exclude certain directories.

-if possible but not needed would be a nice thing to have some sort of better insight on the writable with a hybrid of space sniffer/tree size on writables

[Ray_handels]

Hey

Totally agree with you on the first line (and fourth line). It would be nice to have an overview on how large the writable volume actually is. At this point you could browse the datastore and check the size of the disk there. Unfortenately it could be that this figure is much larger than the actual data within the volume. It would also be nice for a user if he (or she) can see the size being used in the writable volume.

The second question in my opinion is quite easy. Copy the template you need to change the size from, attach it to a VM without AppVolumes, enlarge the volume using VCenter, log into the machine and extend using either diskpart or Disk Management. IMHO this is already quite easy.

The third question is also possible (handle with care ). You can attach the writable volume template to a VM without AppVolumes and change the snapvol.cfg file on the root of the writable volume. This file sets all exclusions and stuff for the writable volume. Still I would not change this file yourself to be honest.

[ChrisBCarlson]

is that recommended to extend a template that way? have you seen the guide to extend and create a new template. there are quite a few steps.

how is your experience with writable. For me as an admin my 10gb writable filled up in 1 month.

[Ray_handels]

Euhm wel yes and no

I did see the guide but we just copied the file and renamed it (there is a link at the bottom of the guide how to rename a VMDK file) and extended it to 20Gb in this case. For us it worked cause we have a few users that are allready working with a new writable volume based on this template.

And regarding the 10GB. Looking at the fact that we are actually creating a 20GB template might just answer that question

I myself did not have to use more than 10GB. I only have about 1 to 2 GB in use after 2 months or so and daily working with it.

What we did do is install very very large applications within an appstack (think about SQL management server or RSAT tools), this does save quite the space in our writable.

The only issue we do see is with users that sync their Onedrive or Dropbox. This almost instantly fills up the writable.

You also need to tweak the golden image quite a lot. Make sure to set the IE cache very low. Try to appstack FireFox for example and maybe install a few addons that everyone uses. These are the tricks we are using to keep it as small as possible.

[ChrisBCarlson]

yeah i see it literally captures everything. even things on the root of the c drive.

Do your gpo's apply properly?

[Ray_handels]

Yes they do.

When looking at the snapvol.cfg you will actually see that the HKLM\Software\Policies (and the syswow equivelent) is excluded from the writable volume. This means that policies that you are applying are not written in the writable volume. Otherwise new policies would never be applied when logging in because the writable volume always takes precedence.

We do however have a golden image that is stored in the same OU as our virtual machines. This way all machine policies are already applied to the VDI machines. Otherwise you could end up with policies that can only be applied after the machine is rebooted. For a linked clone it is quite hard to accomplish this