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