This week, we have released more guidance on deploying Office 2013 with App-V 5.0 through MVA. In this 4 module course, I discuss licensing, planning, package Creation, deployment, and caveats when delivering Office 2013 through App-V 5.
The full course content can be found here:
If you want to bypass the course and just view the videos, you can do that on Channel 9 directly using the links below:
- Module 1: Overview – https://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/01
- Module 2: Package Creation – https://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/02
- Module 3: Deployment – https://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/03
- Module 4: Caveats – https://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/04
One way App-V client administrators are able to centrally control and override content streaming locations has been through a client-based content-path override. In App-V 5, this is called the PackageSourceRoot configuration item. The PackageSourceRoot configuration item is used to override the Package URL of the individual package retrieved from the publishing server. Otherwise, the package will stream from the location specified in the publishing metadata received from the App-V Publishing server (which matches the URL specified when the package is imported and stored in the management database.)
Moving from Test Content Share to Production Content Shares
Often when administrators are staging content, they will place the content in temporary directories that are commonly labeled as test or UAT for “user acceptance testing.” This might not be the final path as the UAT path may be local and the production path may reside on a replicated DFS share. Rather than remove and reimport to correct the path, the PackageSourceRoot override resolves this issue.
Branch Office Scenarios
In environments where you have centralized publishing servers managing multiple branch office sites, you may not necessarily want the content streaming over slow WAN links and BranchCache may not give you enough first launch stream speed. You can leverage local file servers to stream content locally and use either installation switches, environment variables, or AD Site-based group policies to control the PackageSourceRoot location as opposed to specifying an environment variable.
The concept of the PackageSourceRoot is nothing new. It was originally introduced in App-V 4.5 as the ApplicationSourceRoot which allowed for the same flexibility. Like the ASR in 4.x, the protocol used for the PackageSourceRoot depends on the URL format used (\servershare vs. http://server/share.) Bear in mind the value is checked ONLY when a new streaming session needs to be created for a package – NOT before every single streaming operation or stream fault. This is the reason the effect is not instantaneously seen on existing packages that have already done streaming operations (including background streaming operations) since the last restart. Expect to wait a minimum of 30 minutes if packages already exists as this is the default timeout to close idle streaming sessions for a package. The PackageSourceRoot works with Shared Content Store configurations as well. It will be overridden if the Location Provider has been configured when using Configuration Manager scenarios.
If for some reason the PackageSourceRoot is incorrectly configured either manually or through policy, packages will NOT revert back to the package’s default URL from the Publishing Server metadata and will throw an error when trying to publish (0C-80070035) which translates to ERROR_BAD_NET_PATH due to the PackageSourceRoot location not being accessible.
There were some issues early on with App-V 5.0 where there were issues if the PackageSourceRoot was several levels deep or leveraged the same server under a different port for HTTP. Please make sure you are using the most updated build of App-V 5.
The latest version of the Microsoft Desktop Optimization Pack has been released! This release includes UE-V 2.1 plus App-V 5.0 SP3!
For UE-V, this includes some significant addition of features including:
- Credential Roaming Support
- Improved Office 2013 integration (especially email signatures)
- Support for cloud-based storage paths!?
For App-V 5.0 SP3, we have fixed several issues and added some key features such as:
- Mixed Targeted Connection Groups integrated into the Management/Publishing System
- User-Targeted RunVirtual
- Consolidated Event Logging
- Improved Connection Group Performance
See the official Windows for your Business Blog for more details:
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: http://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 (http://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:
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_MACHINESOFTWAREMicrosoftAppVClientStreamingPackages<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.
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.
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.