App-V 5: On the LocationProvider and the IgnoreLocationProvider Feature

In a previous blog entry, ( I discussed the PackageSourceRoot override and how it can be used to control source content locations for packages. There is another option for overriding source content locations for App-V packages: the LocationProvider registry value located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming.

This registry value is not designed to be changed or adjusted manually. It is simply a configuration item that denotes the COM interface and its subsequent registration. When this value is empty, that means there is no LocationProvider interface registered. If one is registered {by GUID} than whatever its setting for the package source root per package takes precedent over the PackageSourceRoot registry setting or other per-package settings. This is how the Configuration Manager client hooks into the App-V client. It uses the COM provider called the VAppLaunchManager which essentially takes over package management with an event-driven methodology.

From the context of how is overrides the PackageSourceRoot, think of this as being a replacement for the manual registry setting of the OverrideURL setting done in previous versions of App-V and SCCM integration. If the application has not been streamed or fully loaded, the App-V Streaming Subsystem will reference this interface to retrieve the Override URL for the package (i.e. the SCCM Distribution Point) from which the package will stream from. This will happen under each time there is a:

  • First connection to a package.

  • Reconnection after a previous session was closed or a user has logged off.

  • Change in the network (move to new network, network interface reset, etc.)

The interface will be registered initially once the clients receives the first targeted advertisement of an App-V 5 virtual application from Configuration Manager. This is a much improved experience from the implementation of Configuration Manager 2007 and App-V 4.6 as existing packages will remain on the client

Now this brings up another likely question: Can you create exceptions to clients being controlled by the Configuration Manager client or some other ISV that might leverage the LocationProvider interface? Let’s say you have a subset of computers within a collection that you not only do not want receiving virtual advertisements from Configuration Manager, but you may also desire managing the applications by way of another mean altogether. In previous implementations of Configuration Manager and App-V integration, field resources came up with using custom policy exceptions (see Rob York’s old blog here: and this worked.

So if you wanted to globally manage all of your resource physical machines, virtual machines, and devices through Configuration Manager (including the delivery of virtual applications) except for possibly a subset of machines in which you may want to manage the applications in a stand-alone fashion (i.e. RDS Servers, etc.) – how do you go about setting that exception in App-V 5? You could probably easily go about the same process – but what if you wanted to use Configuration Manager to publish the applications but still take advantage of the PackageSourceRoot? Why? Well, for reasons such as:

  • Having multiple App-V delivery systems but would like to reduce duplicity on content between content servers and distribution servers.

  • You want to manage affinity with content locations out-of-band from Configuration Manager

  • You want to provide streaming high availability with better failover than the distribution point failovers in Configuration Manager (which are not instantaneous as load-balanced shares.)  

You can have this by setting the value IgnoreLocationProvider to 0x1 (DWORD) in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming. This setting will force the client to ignore the path returned by the LocationProvider interface and instead use the Package Source Root. This was first introduced in App-V 5 SP2 but it was somewhat problematic. The feature works well now in Service Pack 3.

Comments (0)

Skip to main content