App-V 5 Streaming Decision Points

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

When introducing App-V concepts to people who are new to the product one some of the more interesting conversations arise as soon as the word streaming is mentioned. Streaming means many things to different people, everyone tends to have pre-conceptions about what it entails and often the term is misused. The word streaming can also raise concerns about bandwidth and performance.

In reality with App-V there will be certain decision points from packaging to deployment to the client that will dictate the default behaviour regarding how packages will get streamed into your Package Store (cache).



Package Optimisation

There’s only one real decision to be made at packaging time regarding streaming and that is at the Prepare for Streaming phase of the sequencer workflow:


The decision made here will dictate what happens in the scenario when a package is published to a user/machine, it is not fully cached and the package is then launched. At this point its important to remember that this is only IF a package is not available locally in cache at time of launch and there are plenty of other opportunities outside the sequencing process to make sure this is not the case.

You really have three options for package optimisation which are:

You can read more about these options here  however all you probably need to know is unless you have a specific requirement the Microsoft best practice and recommendation is to fault stream. This also happens to be the easiest to set as you just have to click next and shrug off the warning prompt. Fault streaming will mean in the event that your package isn’t fully in cache, the bare minimum your application needs as and when its requested will be streamed down locally.

If you use the PowerShell Sequencer then the default will be fault stream unless you explicitly use the -FullLoad argument which will set it as fully download, there is no option or opportunity to use feature block definition unless you save, reopen the package in the GUI and run an update to reconfigure and resave.


SCCM | Download and Execute or Streaming Delivery

As far server side delivery goes there is only one delivery based option to decide and that is only in SCCM 2012 onwards. This relates to whether you would like a download and execute or streaming delivery.


You can read more about how to set the options here but below is an overview:


If you chose the default download and execute just remember the mount operation on delivery will take place meaning some of the other streaming decision points mentioned here become irrelevant.  A streaming delivery will only complete an add and publish operation but will however require connection a distribution point with the content on first launch.

The App-V Full Infrastructure doesn’t give you any streaming decisions, it will do a add and publish and let your other decision points come into play.

Content Store

So this is less a consideration for SCCM deployments where you will more than likely be using distribution points and the built in mechanisms for content distribution. Otherwise you will need to decide how you wish to house your content for retrieval by clients and also how you wish to distribute it. The content store is a file or web server location for .appv content and related files. From a client perspective files should be accessible via either SMB or HTTP(S).

Regarding distribution you will need to make a decision on how you are going to get your content to your content stores (assuming you have more than one) and also how you plan to keep this up to date and in sync. I have seen so many different approaches to this but my favourite is using DFS, this is because it is scalable, configurable, will automatically direct your client to local content where possible and will automatically keep your content in sync across servers. Otherwise less desirable methods I have seen are:

– Manual

– Scripted

– Robocopy

– vDisk copying

– SCCM (Distribution Only)



The AutoLoad setting on the client will dictate which packages if any will be automatically loaded into cache:

0 = Automatically load nothing into cache

1 = Automatically load previously used applications into cache (default)

2 = Automatically load all published applications into cache (regardless of whether they have been previously used or not)

For most scenarios the default will probably suffice however there might be instances where you rather all published apps come into App-V cache regardless of whether they have been used (option 2), for example I have seen some places where they take this approach for laptop users who may not be on the network for long but would expect to run packages locally offline.

You can set this via PowerShell (Set-AppvClientConfiguration -AutoLoad [0|1|2]), group policy or client installation time (/AUTOLOAD=[0|1|2])

Read more about this setting here.

Package Source Root

This setting won’t affect the way something is streamed, rather where it is streamed from. Package Source Root overrides and changes root streaming location. This is useful for branch office scenarios:


If original location was:


And PackageSourceRoot was set to:


Resultant path would be:


Please note however this setting will be overwritten in SCCM deliveries due to the LocationProvider unless you take the steps mentioned here.

You can set this via PowerShell (Set-AppvClientConfiguration -PackageSourceRoot [path]), group policy or client installation time /PACKAGESOURCEROOT=\\LondonServer01\Share\. I have seen this set via group policies linked to AD Sites to manage roaming users and to ensure they always pick up a local streaming source  depending on which office they travel to.

Falko has a great blog about configuring PackageSourceRoot here, by the way he’s the same guy that has made the App-V Visio stencils I use in most of my graphics!

Shared Content Store Mode

Probably one of the headline features that came with App-V 5, shared content store (SCS) mode gives us the ability to never cache anything locally above and beyond feature block 0. By enabling this setting you can negate packages streaming into local cache upon launch however remember that some of the previous decision points might override this behaviour. For example if you are using download and execute delivery with SCCM, this will automatically mount the package locally, overriding the SCS setting for the given package.


Find further information on shared content store mode here.

You can set this via PowerShell (Set-AppvClientConfiguration -SharedContentStoreMode [0|1]), group policy or client installation time /SHAREDCONTENTSTOREMODE=[0|1]

Package Installation Root

While most of the settings relate to how things will stream to cache, this setting governs where that cache actually resides. By default your cache will reside in %ProgramData%\App-V and to be honest it makes sense to leave this as default unless you have a very specific requirement to have this elsewhere. The only real restriction on where this can be configured to reside is that it should be a global location locally on the machine.

You can set this via PowerShell (Set-AppvClientConfiguration -PackageInstallationRoot [path]), group policy or client installation time /PACKAGEINSTALLATIONROOT=[path]

Support Branch Cache

This simple setting allows App-V to take advantage of any current Branch Cache implementation in your environment. It is off by default to allow for multi-range HTTP but if you want to enable this feature you can set it via PowerShell (Set-AppvClientConfiguration -SupportBranchCache [0|1]).

For a full explanation check out my friend Steve’s post here.

Allow High Cost Launch

This setting dictates whether or not your clients will attempt to stream when on a metered connection (for example 3G/4G) on platforms from Windows 8 and newer. This is set to disabled (0) as default as you would expect however can be enabled via PowerShell (Set-AppvClientConfiguration -AllowHighCostLaunch [0|1]) or via group policy.

Streaming Decision Points Summary


Please use the comments section below for any follow up questions…

Leave a Reply.

27 thoughts on “App-V 5 Streaming Decision Points”

  1. Hi Tham, my client use Thinapp and VSphere as well it’s useful as no client side pre deployment is required. I’d like to leverage App-V in the same manner. Do you have any notes on publishing via RemoteApp.

    • Hi Mate,

      ThinApp embed a client component into the package itself. My friend Rory has an amazing comparison whitepaper which you can read here:

      Regarding RemoteApp, its really a case of just delivering App-V packages to a RDS machine and utilising the standard techniques to deliver access to the package via RemoteApp, that part is exactly the same as publishing a local application to an end point.

      I’ll post a step by step when I get a chance!

  2. Note: Using Mount-AppvClientPackage in combination with Shared Content Store needs “Run as Administrator” to work but would cache the application on local disk.

  3. Hi Thamim, really useful article this one. If I wanted to utilize the ‘Support Branch Cache’ setting using full infrastructure, do you know if I need to be streaming via http(s), or can I still add the packages using SMB (e.g. specifying a UNC path)? Thanks Jon 🙂

      • Thanks Thamim, does that just mean it’s a case of installing the BranchCache role on the publishing servers then?

        • Depends on your BranchCache design. You need to enable it on your content server (if that happens to also be your publishing server then go ahead). Then depending on whether you are using distributed cache mode or hosted cache mode you should enable the Branch feature on the clients or server (if this happens to be a publishing server then go ahead).

          Then just enable the App-V BranchCache setting as detailed above.

  4. Hello Thamin I know this is an old Blog but I have a question

    I’ve been testing deploying an App-v Office 2013 created through ODT and deployed through SCCM 2012.

    This is what I see and I was wondering if this is what you’d expect:

    Deployed via “Download and Execute” 2gb downloaded to App-v cache under the versionid folder.
    When I then package the latest version via ODT I get another 2gb downloaded to the new versionid folder in the cache and so on.

    Deployed via “Streaming” 125mb initially in the cache after lauch streams as expected. but after upgrade I again get a doubling of disk space used.

    From what I’ve read only the bits that have changed should be downloaded but I’m assuming this behaviour only happens with an app-v server and not streaming from a DP.

    Bit of a long question but I’d really appreciate your input

  5. Hello Thamim, so far we never used Appv streaming in my current organization as we still migrating to SCCM 2012 (as you know SCCM 2007 doesn’t support Appv streaming). So can you please guide me or provide the links which can help me to build the understating on streaming. Thank you!!

  6. not using a tool just testing so it’s a visual check of disk space.

    Is the Download and execute behaviour as expected too?

    It makes no sense to me either

    • Download and execute will add-publish-mount. Again for updates of the same package ID only differentials will be streamed. Windows Explorer may just be reporting back on file sizes but you will see when you add the package, it immediately jumps to being predominately in cache.

Comments are closed.