Tried my luck at Google-Fu but I didn't find much information on this. We're starting to transition our users over to AppVolumes for managing applications. Currently I'm trying to diagnose an issue with some user writable volumes growing much bigger and faster than they should. I have a couple users with less than 20 attachments/sessions that hit the 10GB free space we've given them.
We've had problems with both Firefox and Google Chrome auto-updating and breaking themselves within the writable volume, causing SideBySide errors on next launch. I've resolved this by adding exclude_path entries in SnapVolConfig for the Program Files folders. Similar issues might exist with Windows Updates, however I've started pausing them in between monthly update tasks, a setting that seems to hold on the clones. We have another security app that does a lot of logging and could have blown the writable size up, but I've followed their best practices and added the exclusions they recommend to SnapVolConfig. I believe these could have been causing some size issues.
The most recent user to encounter this issue has only been using their writable for 2 days with 4 attachments. The writable was created after all of the modifications to AppVolumes and gold were done. I backed up the vmdk and recreated it for her. On attaching the backup to my own system, the only sizeable file I can find is the Outlook OST. This is around 1GB but doesn't account for the missing 9. When I attach it as a disk drive, it reports 10GB size with 1.5GB free (deleted the OST). Is there a better way to read the vmdk file to see what's going on?
Gold: Windows 10 64-bit Ent, 19041
EDIT: I forgot to mention: the missing space doesn't seem to be impacted by any hidden or normal files. I have Show hidden and system files turned on. I've tried using WinDirStat to search for the missing space, but no luck. Either there's some special folder share I do not know about taking up the space, or the volume's partition table could be incorrect. Not sure what else I should be looking for.
Have you found an answer to your writable volume size issues? We actually made our default writable volume 25GB, but that compounds the issue, as the writable volume is just using the space pretty quickly. We keep adding datastores and extending datastores to meet these new Writable Volume 4 demand.
Just curious if you found your culprit, vmware so far for us hasn't given us a straight answer on what we are seeing.
I haven't yet.
Most of the space issues we've run into recently have been due to .OST files, however I do still see some writable volumes that seem to fail within the first half dozen attachments with no obvious user profile bloat. A couple I've been able to temporarily fix by attempting to expand the drive. I say attempting as I don't believe it actually expanded, however it does seem to clean up something which allows it to continue working. One of the drives that ran into this issue has been running for a couple months after the expansion, the other failed and had to be replaced but lasted at least 3 months. For us we're using roaming profiles and DEM to store most everything, even Chrome settings, so wiping the drive and replacing doesn't impact users too much.
I also looked at Volume Shadow Copy but it was disabled, likely by the VMware VDI Optimization tool. Otherwise I'm not certain what else would cause this.
Did you try adding the disk to a machine that does not have an Appvolumes agent so you can actually see what is being stored on the writable volume? We have seen this issue mostly within TEMP folders that are not being excluded from the writable.
That being said, 10GB is not enough. We used to have 20GB which workd quite well if configured correctly (which is NOT out of the box 🙂 ).
I did attach the drive manually, although I think the machine had the AppVolumes agent. I had logged in via console and local account to bypass any triggering of attachment. The drive looked pretty clean and only had a couple gigs reporting for the user's profile. The rest wasn't accounted for.
I've got another drive to look at, if you have any recommendations on what tools to use I'll give them a shot. Likely I'll be using WinDirStat as it may detect something that wasn't being reported last time.
Just checked the image that recently broke. Biggest offender was an OST file that was hiding under Writable\UEM\OST\. There were a couple out of date copies of some apps that I added the exclusion list during some previous tweaking.
WinDirStat does report that total usage by files is about 1.5GB less than what the disk is reporting as full. This is one of the drives I previously attempted to expand to 20GB, although it's still a 10GB drive.
If the machine has the Appvolumes Agent installed it will still show the info correctly.
If Appvolumes is installed run the following command
net stop svservice
net stop svdriver