App-V 5: On the PackageSourceRoot
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.
Operations
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 (\\server\share vs. https://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.
Comments
- Anonymous
January 08, 2015
In a previous blog entry, ( http://blogs.technet.com/b/gladiatormsft/archive/2014/12/10/app-v-5-on-the - Anonymous
January 08, 2015
In a previous blog entry, ( http://blogs.technet.com/b/gladiatormsft/archive/2014/12/10/app-v-5-on-the - 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