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

This post has moved here

Comments (29)

  1. Anonymous says:

    I am experiencing the same behavior described by Gareth. An executable started from the App-V 5 integration location is acting differently to launching from the package store itself.

    Executable is not started when launched from the following location: (No error, just starts and then stops without a Gui)

    Executable is starting ok when launched from the following location:

    On both locations file permissions are the same and the process name “mavinject32.exe” is started. Other executables work without any problems. I hope someone can help me solve this strange issue.

  2. Thamim Karim says:

    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.

  3. Thamim Karim says:

    Hi, would really need more information around this to help further. Your best bet is you log a call with Microsoft support to get this looked into further.

  4. Thamim Karim says:

    R.G, if you are referring to upgrades, we only actually use differentials in the App-V cache:

    If you are referring to independent packages then you will have to manually target these for removal.

  5. Thamim Karim says:

    Hi Cory,

    Yes I understand what you are seeing, the publish itself is taking a while to populate, this takes even longer if the add operation into PROGRAMDATA hasn’t happened either. Performance is firmly on our radar in terms of how we can make for a better stateless environment experience, for now pre-adding applications and globally publishing where possible will ensure the best experience.

  6. Anonymous says:

    @Mark Van Noy Did you get this issue resolved ? Had you configured the SCCM to download and run
    I am new to AppV and learing, this QA seems interesting…

  7. Thamim Karim says:

    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:…/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.

  8. Thamim Karim says:

    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%MicrosoftAppVClientVFS 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:…/permissions-in-the-pvad-and-vfs-with-app-v-5-0.aspx

    Hope that helps

  9. Thamim Karim says:

    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.

  10. Anonymous says:

    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 ProgramDataApp-VProductGUIDVersionGUID 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.

  11. tom says:

    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.

  12. Amal Zahab says:

    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}RootDirectoryName – folder structure.  Is this also the way you can troubleshoot if you had missing files?  Can you just manually copy files here to test?

  13. Gaurav Agarwal says:

    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?

  14. Gaurav Agarwal says:

    or directly inside %appdata% for that matter

  15. Mark Van Noy says:

    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%MicrosoftAppVClientIntegration 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.

  16. Thamim Karim says:

    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?

  17. Mark Van Noy says:

    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:ProgramDataMicrosoft 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.

  18. Thamim Karim says:

    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.

  19. gareth.douce says:

    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%microsoftappvclientintegration 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.

  20. Thamim Karim says:

    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!

  21. gareth.douce says:

    Hi, the application name is 'Primayer_PhocusSMS' and the service application is 'Primayer_Data Manager'

    Do you know of a way of variabalising the packageguid and versionguid folders so I can force the shortcut to run from this path?


  22. Arokiyaraj M says:

    Hi Thamim,

        I have couple of questions as below

    1. If we install the App-v 5.0 packages via SCCM, do we have to follow any specific command line to get it cached and let me know if not what is the actual cache location if I install the package through MSI.

    2. How can I use the XML files [Deployment and Users Config XML] if I use only the MSI during installation/distribution. Thanks.

  23. Thamim Karim says:

    Gareth – You could create an environment variable locally which stores the path

  24. Thamim Karim says:

    Hi Arokiyaraj,

    In answer to your questions:

    1. If you mean App-V 5.0 and CM 2012 SP1, then simply import your App-V 5.0 package and deploy as download and execute, this will auto mount on delivery. If you are referring to App-V 5.0 and CM 2007 then you will need to deploy a mount-appvclientpackage command to the machines.

    2. You will need to run the relevant PowerShell commands on the clients to specify the deployment or user configurations, you could leverage CM 2007 to deliver these as post installation tasks I guess.

  25. Cory Goffrier says:

    First off fantastic article! Thanks for laying everything out so clearly, it’s been very helpful trying to retrain my brain around the concepts of App-V 5, especially coming from a Citrix streaming profiler background. 🙂

    We’re noticing an interesting behavior with our RDS App-V 5 clients: for any new user session, the population of the symbolic links under “%localappdata%MicrosoftAppVClient*” takes a significant amount of time – during which app-v packaged apps will not launch for the user. Only after the particular app’s GUID is sync’d to local app data will the application load. Because these are RDS servers, the local profiles are cleared after log off, so this behavior will occur at every new login. Applications run great after the process completes, but it’s on average 2-3 minutes of waiting.

    Have you observed similar behavior?

  26. R.G. says:

    Is there an easy way to remove all old packages that have been superseded by a newer one? Or are we really supposed to create some task with SCCM for every package that gets updated so that the harddrives won’t fill up?
    There should be an easier way to clean them up…

  27. R.G says:

    How can i confirm that? Because when i look at the folder size of each version locally, they all seem to be full sized.

    And even if its just the differentials, there is still going to be alot of files that are no longer needed. And it would be nice to have an easy way to clean it all up and only keep the newest version of each Package.

  28. Anonymous says:

    PLEASE NOTE: Enabling PackageStoreAccessControl client configuration setting on a computer that is running

  29. navaneeth.S says:

    iam working on Apache directory studio application due appdata cache appl.ication fails to launch , i have installed the package using MSI generated from APPV5.0 Sequncer any help would be apppreaciated