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

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on stumbleupon

Following on from my post App-V 5.0 OS Integration – Part 1 – Package Format  where we talked about how a App-V 5.0 package is made up, now we can move on to look at how this package is reflected on your client operating system after the package has been delivered in terms of file system and cache.


When App-V 5.0 packages are delivered by default they are stored in %ProgramData%\App-V, this is the physical cache location. In here we will find folders labelled with the GUID of the packages they contain.


To easily find what our package GUID is we can use the Get-AppvClientPackage command, wildcards are great to return a filtered result, and for example here I am searching for Paint.NET:


We can see Paint.NET has a package GUID starting with CA43, if we drill into this folder we are faced with another GUID!


This is our version GUID, as we only have one version of this package published at present there is only one folder. If we go into this folder we see a very familiar sight:


Well familiar enough for anyone who knows about the App-V 5.0 package format as discussed in Part One of this series. Here we can see the key files of our .appv outputted by our sequencer. Our .xml documents contain all the metadata and our Registry.dat file which we will look at in more detail in Part 3 of this series.

Drilling down into the root folder we can see our package files in clear view:


This is a refreshing view compared to the sftfs.fsd cache file we had with App-V 4.6 where things weren’t natively browsable. You will also noticed that some of the files have an X symbol next to them, indicating they are sparse files and not yet streamed. This is because this package has just been published and not yet streamed, at present only the Publishing Feature Block – FB0 is present.

After triggering a stream of the package, we will find these files get streamed locally and become fully present, remember if we don’t this behaviour we can put our client into Share Content Store Mode.

One point to note is the cache will not be cleared after an unpublish, it must be removed, read this KB for more details.


So now we understand how our package sits on our client, let’s look at how it runs, if we right click our App-V 5.0 shortcut we will notice two things:

1.      We call the .exe directly

2.      We call it from %LOCALAPPDATA%


So you might thinking, why does the package launch from this location when we already discussed how the package sits physically in %PROGRAMDATA%\App-V


Well at first glance it would appear we are duplicating the cache for the user we have published to however that isn’t the case. IF we go a few levels up in the folder structure we can see that the folder structure is made up out of symbolic links back to our %PROGRAMDATA% location!


Right, now we understand how our file system works on your client, look out for Part 3 of this series where we will talk about the registry.

App-V 5.0 OS Integration

Part 1 – Package Format

Part 2 – File System Cache

Part 3 – Registry

Part 4 – State Changes

Leave a Reply.

50 thoughts on “App-V 5.0 OS Integration – Part 2 – File System Cache”

  1. 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.

  2. 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.

  3. 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.

      • I realize this is an old thread yet hope I might get a response. Would you have any documentation\video that outlines the process of setting configuration files?

  4. 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?

  5. 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, referring to app-v 5.0 unable to set cache limit as raised up by Mark, just wanted to confirm if that is true? If yes, any suggestion on how to control the app-v cache size in this case? As this could potentially be impacting client device with limited disk space.

        • That is correct there is no way to set the cache limit, as the cache is just a plain file system rather than a file itself. It basically follows the same principle as .msi. A explicit remove-appvclient package will have to be issued to clear the cache, unless using config manager which does this by default, you will need to either script or issue this remove command in some other managed way.

          • In this case, how does the App-V client cache work? So, assuming I have 10 app-v applications being cached and with only say 50MB free disk space available, if we deploy the 11th app (requires 100MB) to the computer, will the cache be overridden where the oldest cache will be the first to go? Or it will not be cached until the apps have been removed?

          • The application will be unable to cache and run of disk space. There is no over arching control on the cache at all, this needs to be managed outside of App-V

  6. 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!

      • 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? Ta.

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

    • 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.

  8. 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) C:\ProgramData\Microsoft\AppV\Client\Integration\AE93DED5-F130-4D4B-BBCC-E2E76D463D27\Root\Runtime\md8rntm.exe Executable is starting ok when launched from the following location: C:\ProgramData\App-V\AE93DED5-F130-4D4B-BBCC-E2E76D463D27\B5CEC2A9-0687-4868-89DD-EF7AB310C498\Root\Runtime\md8rntm.exe 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.

    • 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.

  9. @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…

  10. 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%\Microsoft\AppV\Client\*” 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?

    • 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.

  11. HiIs 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…

  12. Hi ,

    Its an interesting blog. I have few basic queries reg appv.
    1.) In the “prepare for streaming” window during sequencing, what if I dont launch shortcut? A single feature block will be created ? And when user launch shortcut, there will b a delay since the entire app block wil be streamed from server ? If thats the case, then why they have given the checkbox option of “force app to be fully downloaded”. This option too does the same thing, right ? stream the entire app from server !!!!

    2.) when we use word “virtualized”, we mean a virtual app wont b installed like traditional installations (files goes to C:\PF and reg goes to registries) …. but in reality, when we install a virtual app, it puts everythin under C:\PD\appv , right ? then wht is the use of virtualization when the entire application resides under PD instead of C:\PF (which is d case wid traditional instlln).. there is no saving in terms of disk space too!!!

    3.) When the entire app resides under C:\PD\appv then wht is actually being streamed ? (when we say streaming is there and all !!!!). why we say tht blocks will be streamed and all !!!

    4.) why some folders under these PD and appdata have a cross sign on them and some not ?

    i kno its a ramayan , sry for that..!!!


  13. I read those blogs…its truely a very well organised blog. On a slightly diff note ,hopin tht u wud have work wid ThinApp, acc to u which is better ? like thinapp is agentless and there is no need to install any client or server app etc .!!!

    • Hi Manish,

      I have had limited experience with ThinApp but I believe a very small agent is embedded into each individual package. There is no requirement for a server in ThinApp or App-V.

  14. Hi Thamim,

    In many machines, when i launch the virtualized application, it gives an error that the application is not compatible or not a valid win32 application. When i checked the Programdata folder, it seems like the target exe and all the files are not cached. When i download the application completely using Mount-appvclient package and launch the shortcut, the application works fine. Or else i have wait for 15 to 30 mins even for a small application to be downloaded. Can you please let me know what are the reasons for such behavior? This behavior is observed in Standalone mode as well as Full Infrastructure mode.


  15. I have an updated App-V package that is locking up in some actions, but it works fine for the same user on the same workstation if I rename their profile and build out a new user profile for them.

    What all is touched from the end users perspective that a new profile could fix an issue with an update to an App-V published application?

Comments are closed.