App-V 5.0 OS Integration - Part 2 - File System Cache
This post has moved here
Comments
Anonymous
January 01, 2003
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:ProgramDataMicrosoftAppVClientIntegrationAE93DED5-F130-4D4B-BBCC-E2E76D463D27RootRuntimemd8rntm.exeExecutable is starting ok when launched from the following location:C:ProgramDataApp-VAE93DED5-F130-4D4B-BBCC-E2E76D463D27B5CEC2A9-0687-4868-89DD-EF7AB310C498RootRuntimemd8rntm.exeOn 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.Anonymous
January 01, 2003
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.Anonymous
January 01, 2003
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.Anonymous
January 01, 2003
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.Anonymous
January 01, 2003
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.Anonymous
January 01, 2003
@Mark Van Noy Did you get this issue resolved ? Had you configured the SCCM to download and runI am new to AppV and learing, this QA seems interesting...Anonymous
January 01, 2003
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.Anonymous
January 01, 2003
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: blogs.technet.com/.../permissions-in-the-pvad-and-vfs-with-app-v-5-0.aspx Hope that helpsAnonymous
January 01, 2003
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.Anonymous
January 01, 2003
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.Anonymous
March 28, 2013
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.Anonymous
April 10, 2013
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?Anonymous
September 03, 2013
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?Anonymous
September 03, 2013
or directly inside %appdata% for that matterAnonymous
October 17, 2013
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.Anonymous
October 18, 2013
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?Anonymous
October 18, 2013
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.Anonymous
November 01, 2013
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.Anonymous
November 03, 2013
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.Anonymous
November 04, 2013
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!Anonymous
November 04, 2013
The comment has been removedAnonymous
November 05, 2013
The comment has been removedAnonymous
November 06, 2013
Gareth - You could create an environment variable locally which stores the pathAnonymous
November 06, 2013
The comment has been removedAnonymous
March 04, 2014
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?Anonymous
March 07, 2014
Hi
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...Anonymous
March 17, 2014
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.Anonymous
March 28, 2014
PLEASE NOTE: Enabling PackageStoreAccessControl client configuration setting on a computer that is runningAnonymous
December 03, 2014
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