App-V 5: On Background Streaming

  • Article

Several years ago, I wrote an article for the App-V team blog on the Autoload feature that was first introduced in App-V 4.5: https://blogs.technet.com/b/appv/archive/2009/07/28/understanding-the-autoload-feature-of-microsoft-app-v-4-5.aspx. The combinations and scenarios (not to mention, the potential network storms that could occur from post-upgrade default settings) yielded a necessary detailed explanation.

The Autoload feature continues in App-V 5 in a slightly simplified implementation through the use of low priority background tasks. These occur only in stream-to-disk scenarios and the values are totally ignored for Shared Content Store mode (unless it is toggled off.) You will recall from a previous blog (https://blogs.technet.com/b/gladiatormsft/archive/2014/10/31/on-troubleshooting-http-streaming.aspx) that these run always at low priority, have a 7 day timeout, and will try forever with a 15 minute interval between retries.

What was simplified was the autoload trigger settings in the registry. There is a single configuration value called Autoload located in:

HKLM\SOFTWARE\Microsoft\AppV\Client\Streaming

The potential values are:

  • 0: Autoload is disabled.

  • 1: A background task to stream will be generated after an application has been initially launched. This is the default value. These tasks will also kick in upon login if the application has been launched before. The PreviouslyUsed value for the package (located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming\Packages\<GUID>) is how this is tracked. This will also occur if the package is updated to a new version as the PreviouslyUsed value will remain at 1.

  • 2: This value means all packages will be background streamed regardless of whether or not they have been previously launched. This value can sometimes leverage unpredictable results as background streaming can begin as soon as packages are published.

Exceptions

There are some exceptions to the above configuration items:

User Logoff: Auto-loading occurs in the background under the context of the currently logged on user matched with the publishing target. This means that once a user has logged on, in order for an autoload task to initiate, the user must be assigned that package either implicitly (package globally published) or explicitly (user targeting.) When the user logs out, any autoloads running are stopped. They may resume upon another user logon on the same computer should entitlements match, otherwise, it will resume upon the user’s next logon.

Metered Connections: If you are running Windows 8 or later and the device has just moved from a normal corporate network or high-speed Wi-fi to a high cost network, the App-V client will suspend background loading tasks. This exception only occurs when streaming from a UNC path or an HTTP path. If the package is mounting from a local path, it will continue to background stream.

Connected Standby Mode: Connected Standby Mode is a new low-power state that features extremely low power consumption while maintaining Internet connectivity. Starting with Windows 8 and Windows 8.1, Devices that implement the connected standby power model run at very low power levels, but stay connected and up-to-date, even when they appear to the user to be turned off. Autoloads/Background tasks will be suspended by the App-V client when the device is in connected standby mode.

Caveats

I worked a few cases in support where the configured Autoload settings for newly provisioned (or upgraded) App-V clients created network traffic storms – especially in shift-oriented environments where everyone tends to log on at the same time. Most of this was due to the dual settings of 4.x where the trigger would occur upon logon and background stream previously used applications. However, setting this value to 2 in App-V 5 could yield similar results.

Comments

  • Anonymous
    June 30, 2015
    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like
  • Anonymous
    June 30, 2015
    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like