I think it would be safe to say that Shared Cache in App-V 4.6 was not the most popular solution for reducing the impact of App-V cache on client machines. From VDI to RDS, people didn’t want to duplicate the potentially huge sftfs.fsd cache file across their disks and consume unnecessary space. The Share Cache solution was a way around this however it could prove to be hard to manage when trying to update a centrally located cache file to which multiple machines had a handle to.
Enter Shared Content Store with App-V 5.0!
Shared Content Store in App-V 5.0 allows us to stream directly from a content source without having to stream the package to the local platform. The great thing is App-V 5.0 packages now use a flat file format and are no longer stored collectively in a single cache file, which means we no longer have the read only challenges we faced with the Shared Cache solution in App-V 4.6 when it comes to updating applications and replacing the cache.
By default when a App-V 5.0 package is published to the client it is stored in a flat file format in %PROGRAMDATA% as shown below where we can see a WinRar package:
You will notice the size on disk matches the file size, this package is currently cached locally on this machine.
However if we enable Shared Content Store we can choose not to hold these files locally and instead stream from the content source directly. We can enable this setting during installation by using the following switch for installation: appv_client_setup.exe /SHAREDCONTENTSTOREMODE=1 /q
We can also enable this setting after installation by using PowerShell:
Set-AppvClientConfiguration -SharedContentStoreMode 1Or we can use this simple registry change on the client as shown:
After a reboot of the client, next time we publish an application, it no longer downloads the entire package but instead creates NTFS pointers to the files which only consume 4KB on disk:
You will notice the change in icons for the App-V WinRar package files also indicating that these are sparse files which actually do not contain the data locally. The package will now utilise the original stream location for these files to run the application without ever having to download them locally to disk. A very small percentage of package files will always have to stay local however such as icons and metadata, this is called the publishing feature block, read more about it here.
So that is a quick overview of Shared Content Store in App-V 5.0, click here for a deeper look into how this great feature works.
50 thoughts on “Introducing Shared Content Store in App-V 5.0 (Goodbye Read Only Shared Cache!)”
nice article
thanks!
Is management server required to use shared content store?
Hi Aku,
There is no dependency on the management/publishing server. Along as the client has the relevant registry key set and it has an accessible location for the package assets, it will be able to utilise shared content store. Hope that helps!
Ok i did some testing…. This works with standalone scenario… Cool:)
Is there any performance lose if Shared Content Mode is enabled? Like longer loading time and slow response.
Good question Kenshinvc, there are no official performance stats published yet but on a low bandwidth/high latency network I can imagine there definitely would be an impact . This feature however is more geared to the datacentre solutions such as RDS and VDI where we would expect fast attached storage and good network connectivity, in such scenarios I don’t see this as being a concern or at least no more than shared read only cache in App-V 4.6.
Thanks
Good blog and informative nice one mate!
Thanks Omar!
Ok, what am I missing here. I want to bypass the management and publishing server altogether and just use a share content store. I installed my client and set the registry to HKLM\Software\Microsoft\Appv\streaming\SHAREDCONTENTSTOREMODE=1
I created my packages and put then in a packages share (ensuring everyone had read access)
How do I set the location of where the actual packages are? Is that the PackageInstallationRoot String? I set that to \\servername\packagesharelocation but my client is still not picking up any packages, even after restarting the client service. Any help would be greatly appreciated. Thanks!
Hi Rob,
If by bypass the management and publishing server you mean you don’t want the infrastructure involved in the delivery on the app then you want to use standalone mode to publish the app as described here: blogs.technet.com/…/app-v-5-0-standalone-mode-adding-and-publishing-a-package.aspx
The -Path argument will specify where the client can retrieve the content on aper app basis and because you have put your client into SCS mode it will simply stream the content directly from there and not attempt to bring it locally.
The PackageInstallationRoot you mentioned in registry has nothing to do with where you will stream packages from but where they get stored locally in cache. This should be left as the %ProgramData%\App-V location unless you have a specific reason to change it.
Hope that helps and let me know how you get on…
Hi Thamim,
If we are enabling the SCS then user has to stream the application directly from the content source. Suppose multiple users are using the content source at the same time. will there be any performance issue.
Hi Surrender, we use the intelligence of Windows memory management to reduce that load in terms of RAM in the case of multiple users running the same application. in terms of the data itself, this solution would primarily be used in data centre environments where there is fast attached storage.
Hi Thamim,
In a mixed environemnt scenario with the desktop client and the RDS client is it possible to point the RDS client to a local content source, I am thinking a disk near the XenApp servers, would the PackageSourceRoot in the RDS client pointing to the local disk mean that with shared content mode enabled the files would be streamed from the local disk regardless of the original publishing location? (I have seperate content stores for the desktop clients).
Thanks
Hi Kevin,
Your exactly right in your thinking. Specifying the PackageSourceRoot setting as your root directory for your alternative content share will make sure your RDS machines stream from that location. If they are in SCS mode then they will work from that location exactly as above.
Hope that helps!
I would like to add some information. If you have packages loaded allready, you need to remove and add the packages.
If you change scs after installation, the common users are able to precache the applications. If you set scs during installation, the users arent able to precache applications.
Thanks for the additional info Roel, very useful observations.
We’re install app-v version 5 into a stateless vmware view 5.2 instance running on UCS servers with 2.4tb of fusion I/O cards. App-V is in shared cache mode, the experience can be quite poor with start menu stutter for up to 2 minutes whilst it populates with around 10 app shortcuts. App performance varies from ok with minor delay to poor. does anyone know how to pre-stage/pre-cache ‘hot’ apps whilst leaving the rest to stream?
tyvm, jason
Hi Jason,
Pre-staging can be done by using the add-appvclientpackage command. Pre-caching can be done via the mount-appvclientpackage command. Then all you need is to publish the packages via your method of choice. Please let me know if that makes sense and more importantly if it improves your experience.
Hello Karim,
We’re seeing some delay when building up the start menu as well as Jason describes (If I’ve understood his post correctly).
A user logs on and it takes up to 3 minutes before his applications are shown.
How can we speed this up? by pre-staging the applications?
Do we do this by running Powershell cmdlets?
Thx!
Filip
Hi Filip,
Have you tried pre-adding the packages? This is done via the add-appvclientpackage command, this should speed up the time to publish substantially. The general speed of publish is definitely on our radar internally and I would be interested to know how much pre-adding the applications helps you speed the process up so please do let me know!
Hello Karim,
I just tried this but get an error stating that admin rights are required.
In our organisation, users don’t have admin rights..
How can I get around this?
Thx!
Filip
Hi,
just to let you know that if we run the ps cmdlets, then the application is published in under 45 seconds.
Now all we need is a workaround that allows users to run them..
Filip
Dear Tamim,
I am running Windows Power Shell V4.0 on Windows 7 SP1 Pro, is App-V 5 SP1 client supports Power Shell 4.0 yet?
I am facing publishing issues on the client with POS V4.0, I tried the same packages on a client with POS 3.0 and everything is working fine.
Please advise.
Thank you.
Hi,
We do support PowerShell 4.0. Can you provide examples of packages that do not publish? Is it only certain packages?
Thank you dear Thamim for your prompt reply,
I am having issues with Office 2010 X86 and Office365 on PowerShell 4.0 using App-V Client Standalone mode.
Other applications are working fine.
I am testing as you suggested with Standalone before using Full Infrastructure mode.
The Client OS is Windows Embedded 7 Professional x86 SP1 with POS 4.0.
Please advise?
Regards,
I believe this might be to do with the platform rather than PowerShell version. Are you sure all other factors are the same? If you upgrade the working platform to PowerShell 4.0 does this stop working?
Hi Thamim,
Usefull article.
I tried with one package, if we publish a package normally before launching the application the size of the .exe is around 190kb. i.e., when published futere block is loaded. if we publish a package after giving /SHAREDCONTENTSTOREMODE=1, the size of the .exe file is 4kb. what makes the difference. both are published future blocks only
Hi, currenty I’m testing with Shared Content Store. When published and refreshed on the VDI client the application consists of sparsefiles. When started the full application is loaded and runs from %programdata%/App-V. Sharedcontentstoremode is enabled through policies though. What could be wrong ?
Trying the install using the option /SHAREDCONTENTSTOREMODE=1 but I’d rather have a generic install, so the same SCCM package with the same program is usable for fat clients, and VDI’s.
Problem was solved, my ‘persistant VDI’ was not..
What if I want some apps to use Shared Content Store mode and some to use normal mode? Is that possible, and if so, how would you go about doing that?
Hi Emma,
You could set the client into shared content store mode and then use the mount-appvclientpackage command for the packages you wanted to run fully cached.
Hope that helps
but where is this content store located ? on server ? in case of a standalone msi installation, from where the files get streamed ?
In any SMB or HTTP(S) location, typically would be a SAN or file share somewhere. For MSI installations it would stream the .appv from the same root as the MSI.
Do we need to do anything different if we are using SCCM 2012 to deploy our AppV app? We have set this up with the //SHAREDCONTENTSTOREMODE=1 set in the Registry but it still seems to distribute the whole application.
Do we need to do anything else for SCCM deployment?
John
Hi John,
You need to make sure the deployment type in CM specifies a “Streaming” delivery.
At our site we have SCCM deploying app-v applications targeted at users. This, combined with a non-persistent VDI environment, means that once a user logs in they need to wait 3-4 minutes before all of their applications are available. We’re already using SCS. There are very few “core” applications that are used by many. Is there any way this can be made more efficient?
Thanks,
There are not many options unfortunately. Delivering machine is an option but I understand you will not want all your users getting all apps. Another option is to deliver to the machine with no shortcuts and use a different technology such as Group Policy preferences to deliver the shortcuts to users at logon, this works but is not very clean or manageable. The best option for non-persistent VDI in my opinion is App-V Management Server with UE-V roaming published state.
We are trying to implement SCS on a Server 2016 non-persistent XenApp server to stream user apps from Configuration Manager 1710 and minimise storage space. As App-V client is pre-installed on Server 2016 we didn’t have to install, instead just enable the client and at the same time enable SCS through powershell. The App-V package is configured in SCCM to Stream, yet we still see the content caching in ProgramData\App-V. We have enabled SCS in both registry and GPO to be sure it is enabled, but still packages are caching at launch. Is my understanding of SCS incorrect and this behaviour correct, or should the applications have a smaller footprint on server? Thanks.
HELLO,
IF I AM USING RDSH HOST AND VDI SOLUTION, CAN I ENABLE SCS MODE ON RDSH AND DISABLE IT ON VDI’S? WILL IT WORK?
Comments are closed.