Mar 28, 2013 - 49 Comments - Virtual Vibes -

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

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.

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.

ProgramData

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:

get-appclientpackage

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

ProgramDataVersionGUID

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:

Package

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:

Package1

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.

Shortcuts

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%

properties

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

appdatalocal

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!

integration

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

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

  1. Tom

    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.

    26 Apr 2014 - Reply
    • Thamim Karim

      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.

      26 Apr 2014 - Reply
  2. Graham Beaumont

    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.

    26 Apr 2014 - Reply
  3. Amal Zayab

    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?

    26 Apr 2014 - Reply
    • Thamim Karim

      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.

      26 Apr 2014 - Reply
  4. Gaurav Agarwal

    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?

    26 Apr 2014 - Reply
  5. Gaurav Agarwal

    or directly inside %appdata% for that matter

    26 Apr 2014 - Reply
    • Thamim Karim

      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

      26 Apr 2014 - Reply
  6. Mark Van Noy

    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.

    26 Apr 2014 - Reply
    • Thamim Karim

      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?

      26 Apr 2014 - Reply
      • Mark Van Noy

        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.

        26 Apr 2014 - Reply
        • Thamim Karim

          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.

          26 Apr 2014 - Reply
      • Chris

        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.

        7 Aug 2014 - Reply
        • Thamim Karim

          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.

          9 Aug 2014 - Reply
          • Chris

            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?

            11 Aug 2014 -
          • Thamim Karim

            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

            11 Aug 2014 -
  7. Gareth

    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.

    26 Apr 2014 - Reply
    • Thamim Karim

      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!

      26 Apr 2014 - Reply
      • Gareth

        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.

        26 Apr 2014 - Reply
        • Thamim Karim

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

          26 Apr 2014 - Reply
  8. Arokiyaraj M 5

    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.

    26 Apr 2014 - Reply
    • Thamim Karim

      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.

      26 Apr 2014 - Reply
  9. Anonymous

    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.

    26 Apr 2014 - Reply
    • Thamim Karim

      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.

      26 Apr 2014 - Reply
  10. Anonymous

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

    26 Apr 2014 - Reply
  11. Cory Goffrier

    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?

    26 Apr 2014 - Reply
    • Thamim Karim

      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.

      26 Apr 2014 - Reply
  12. R.G.

    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…

    26 Apr 2014 - Reply
    • Thamim Karim

      R.G, if you are referring to upgrades, we only actually use differentials in the App-V cache: http://blogs.technet.com/b/virtualvibes/archive/2014/02/18/differential-upgrades-with-app-v-5-0.aspx

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

      26 Apr 2014 - Reply
      • R.G.

        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.

        26 Apr 2014 - Reply
  13. App-V 5.0 Ramp up Guide | VirtualVibes

    […] App-V 5.0 OS Integration – Part 2 – File System Cache | Blog […]

    1 May 2014 - Reply
  14. manish

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

    Thanks.

    1 Jul 2014 - Reply
  15. manish

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

    9 Jul 2014 - Reply
    • Thamim Karim

      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.

      10 Jul 2014 - Reply
  16. App-V 5.0 OS Integration – Part 3 – Registry | VirtualVibes

    […] we understand the package format and client file system for App-V 5.0, let’s take a look out how the registry looks in terms of OS […]

    14 Jan 2015 - Reply
  17. Application Cache Login | Free Documents App

    […] App-V 5.0 OS Integration – Part 2 – File System Cache … – 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 …… […]

    15 Jan 2015 - Reply
  18. App-V 4.6 to 5.0 - Comparison Cheat Sheet - VirtualVibes - Site Home - TechNet Blogs

    […] Flat file structure in %ProgramData% […]

    13 Feb 2015 - Reply
  19. Azhar

    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.

    Regards,
    Azhar.

    19 Feb 2015 - Reply
    • Thamim Karim

      Hi Azhar,

      Does this behaviour happen for all applications or just one in particular?

      19 Feb 2015 - Reply
  20. Azhar

    It happens in every application

    19 Feb 2015 - Reply
  21. The Microsoft App-V 5.0 Sequencer and Client Troubleshooting Guide - The Official Microsoft App-V Team Blog - Site Home - TechNet Blogs

    […] App-V 5.0 OS Integration – Part 2 – File System Cache | Blog […]

    30 Jun 2015 - Reply
  22. The Microsoft App-V 5.0 Sequencer and Client Troubleshooting Guide | The World Simplified is a Virtual World

    […] App-V 5.0 OS Integration – Part 2 – File System Cache | Blog […]

    28 Apr 2016 - Reply
  23. Jason

    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?

    3 Aug 2016 - Reply
  24. Prema

    Great article for beginners like me.. thanks a lot Thamim

    3 Aug 2016 - Reply

Leave a Reply

Your email address will not be published. Required fields are marked *