VirtualVibes

Thamim Karim on a virtual vibe...

App-V 5.0 OS Integration - Part 2 - File System Cache

App-V 5.0 OS Integration - Part 2 - File System Cache

  • Comments 28
  • Likes

This post has moved here

Comments
  • I don't think many software vendors, including Microsoft, will be very forgiving with software licensing of applications that App-V 5.0 does not clean out of the cache after it has been removed.  Your KB method to remove AppV packages does not scale easily or well.

  • Hi Tom, I understand your comments and have heard similar sentiments from some of our customers but in some ways things are the same as they were in previous versions of App-V whereby an unpublish never actually removed the app from cache, we just whitespaced it for overwrite. I guess its more obvious in App-V 5.0 with the flat file system and the fact there aren't any controls for the cache size limit and overwrite.

  • I have observed a situation where an App-v 5.0 package has been imported in to SCCM and then failed to be installed to a workstation through the software center.  Having reviewed the AppEnforce.log it mentions that althogh the commands to add the package have worked the publish failed.  As a coincendence i have noticed that some of the extracted .appv files that appear in the ProgramData\App-V\ProductGUID\VersionGUID\ have the cross next to them.  So if the publish has failed due to some sort of sftmime command error i am yet to troubleshoot; these files won't be published into the client correctly.  Therefore they won't appear fully streamed until the application is launched, which i can't do if the package hasn't been published.

  • That's an interesting issue Graham but the behaviour is exactly what I would expect if only an add had taken place, I explain add and publish in depth here: blogs.technet.com/.../app-v-5-0-standalone-mode-adding-and-publishing-a-package.aspx

    As you say, the question is why the publish is failing. The App-V event logs may also help you get an insight into what is going on with App-V too.

  • Hi Thamim,  If I have an application that I want to use across multiple sites and it requires different configuration files (based on location) under a certain directory on the local disk, can I just create 1 virtual app-v 5.0 package and then deliver the configuration files per site via group policy to just copy files to the C:\ProgramData\{PackakeGUID}\{VersionID}\Root\DirectoryName - folder structure.  Is this also the way you can troubleshoot if you had missing files?  Can you just manually copy files here to test?

  • Hi Amal, you can have one package with multiple configurations however writing to the ProgramData location of the package is not an option as it is protected with read only access, the most you can do is copy files out of the location.

    Group Policy would achieve what you want but the file would have to be placed outside of the cache location, you could also use the DeploymentConfig.xml/UserConfig.xml to achieve this.

  • Hi Thamim,I want to understand whether an user or an admin has privileges to modify the content of root and VFS folder. If i want to make any changes to any particular file that i have already sequenced can i directly go inside programdata-root ,vfs and edit them?

  • or directly inside %appdata% for that matter

  • Hi Gaurav,

    The cache in %ProgramData% is read only protected for both admins and non-admins. We do nothing to stop anyone writing to %AppData%\Microsoft\AppV\Client\VFS however.

    App-V packages will have different permissions when running depending on user privilege and whether the application tries to write to PVAD or VFS, as explained here: blogs.technet.com/.../permissions-in-the-pvad-and-vfs-with-app-v-5-0.aspx

    Hope that helps

  • Hello Thamim,

      We were wondering why the ability to set cache limits was removed for App-V 5.0?  Parts of the cache appear to be behaving as your article describes and in other ways not.  We deployed App-V 5.0 SP1 into production this August using SCCM and the cache has filled up the hard drives on nearly 300 computers preventing users from logging in.  The sparse files are supposed to just be place holders, but the file system is seeing them as taking up the full amount of space.  For example, AppVClientUX.exe on a sample computer reports that we only have 4 out of 20 applications ready for offline use and fully cached. At least half of the applications have been published, but never run.  So the four applications that are fully streamed should be using up a maximum of 5GB.  Our %ProgramData%\App-V directory on the sample system is reporting that it is 21.4GB.  I know that the %LOCALAPPDATA%\Microsoft\AppV\Client\Integration directories are supposed to be symlink back to the %PROGRAMDATA%\App-V directory, but when we audit the filesystem the total used disk space reported matches up when we add both caches together.  So on this sample machine it looks as though App-V 5.0 is actually using up 42.8GB of space despite the directories clearly being marked in Windows Explorer as symlinks/shortcuts.

      It is not clear to us what exactly is happening.  However, we do know that when we were using App-V 4.6 this spring with many of the exact same applications, most of them were converted to App-V 5.0 rather than re-sequenced, we had plenty of file space on the same computers and were not hitting the cache limits we had set.  App-V 5.0 has some great improvements, but the cache issue is really causing some serious problems.

    Thank you for posting your various articles.  They have really been a fantastic resource.

  • Hi Mark,

    Very interested in what you are seeing. Could you confirm what tool you are using to inspect disk space or are you just using explorer? Also are you accounting for F0 of all the apps that have been delivered?

  • Good morning Thamim,

      We are using a freeware tool called Disktective to profile disk use.  I am reasonably confident that it simply uses the Windows API to look at space usage.  That has two positives: it saved me from writing a Powershell script and it is looking at disk use the same way Windows is when Windows reports we are out of disk space.  I know that Disktective will report symlinks as the size of files or directories that they point to because it was reporting the All Users profile links back to the App-V cache under Windows 7 x64 and we know that no such profile exists.

      I am not accounting for the F0 space only because I am not aware of a way to determine how big that block actually is.  I know about how large the applications that have fully streamed are when they are locally installed so that is what I am using for the expected file size.  Though, even adding in the F0 blocks for all the applications that have not been invoked I would not expect the cache to exceed 10GB.  The 21.4 GB seems about right if all the applications were fully streamed and running from the cache.  In another computer lab that was running out of space I saw that the cache was 17GB and when I launched an application that had not been invoked and waited to see that it was fully streamed the cache size was still reporting 17GB.  I even closed and re-opened explorer to make sure it was not a refresh error; the cache size had not changed.

      So in checking another sample machine with the exact same image and same streaming applications as the last sample, I see that Windows Explorer reports that 178GB of space is used on disk.  If I add the totals from Disktective and exclude all App-V cache locations including ones that use symlinks then the used space is 128.3GB.  C:\ProgramData takes up 36.8GB if I add the App-V cache only; bringing the total space to 165.1GB.  If I add the C:\ProgramData\Microsoft directory to that total, a 27GB add, we get 192.1GB which is clearly off, but if I subtract out the 23.16GB in the AppV directory we are back down to 168.94GB which is still off by at least 9GB that Windows Explorer is reporting used.  Perhaps the 9GB is being held by the Windows swap space; it does not show up explicitly in the report while Windows Explorer reports that pagefile.sys is taking up 7.92GB.  This computer has a couple more small applications fully streamed.  When I add up the size of the fully streamed applications I come up with about 6GB without accounting for F0 for the other applications.

    Thank you for letting us throw all these numbers at you.  These results are a bit different than the last time I dug around on a computer, but they are similarly confusing.  Perhaps we have about 2GB of user data in the App-V cache so that added with the swap space that looks about right for the total disk space with the rest of the cache under Microsoft pointing back to the App-V directory.  However, the App-V directory itself still seems to be awfully large given the number of applications that are cached.

  • Hi Mark, I have been unable to replicate this issue on my environment. I would recommend you get a support case logged with us so we can investigate this properly.

  • Hi Thamim,

    I have app-v app that will not connect to a service running from a non virtualised app - but only when accessing it through the %LOCALAPPDATA%\microsoft\appv\client\integration\ path. However if I run the app directly from ProgramData%\App-V, it can connect to the service with no issues. Do you know why this might be? I can't quite understand the difference between the two locations. Is there a way of creating a shortcut to force it to run from correct location?

    I have another issue with this package also. I get a access is denied error to a particular folder when clicking on a button within the app. Now I got the same problem when running it as a non virtualised location, however granting the users group full rights over the folder solved the issue. But in the virtual env, granting these rights makes no difference. Any ideas??

    Thank you.

  • Hi Gareth, interesting behaviour, to my knowledge there is no reason why launching an app from the integration location should act differently to launching from the package store itself. Would be very keen to test this however if you are able to share the packages with me.

    Regarding the access denied error, are you able to sequence the application with the PVAD as including the folder you are trying to write to? This will ensure all users are able to write to this location in the virtual environment.

    Let me know how you get on!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment