Kirx' Blog -

PackageSourceRoot Configuration in App-V 5 | March 3, 2014

TwoArrowsChange generally happens, and so it may happen for the location of your .appv file store, too; esp. in a Native App-V deployment scenario or in a Shared Content Store mode scenario. With PackageSourceRoot you can tell the App-V Clients to get the data from a new location and to forget about the old one… particularly

The situation

You are using an App-V Native Deployment (with an App-V Management Server, Publishing Server and Streaming Server), you are using a deployment with Shared Content Store mode enabled, or you are using another deployment method that does not initially download all package data down to the client – in such scenarios you may face a situation where you want to relocate the central package store (where all the .appv files are located). Common reasons are:

  • You started with a Single Server Native Infrastructure and want to scale-out the streaming feature
  • You started with web based streaming and want to change to file based operations (or vice-versa)
  • You want to extend your existing streaming server to a clustered of load-balanced entity
  • You want departmental clients to download data from their local, decentralized server
  • You want… I think you get the idea.

Where did we get misconfigured packages?

‘Bringing’ an App-V package to a client always starts with adding it, and after that it gets published. The package may or may not be mounted (=fully loaded), it may or may not be partially streamed or it may or may not be operate in Shared Content Store mode.

Either way, during the step of adding, an URI (Uniform Resource Identifier, see has to be specified that points to the package’s .appv file. The URI might point to a web server (http or https), to a file server (smb) or to a local drive like a fixed or removable disk, flash drive or whatever.

In this step, the App-V client creates some package information entries in the client’s Registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming\Packages. As an identifier it uses the packages VersionGUID as a key. Underneath of that key the client creates various values. The most interesting value for our topic is PackageURI and contains, well, the URI of the .appv file. In the example below it is a web server, but it might be your ConfigManager Distribution Point or a local drive, too.


Right after these entries are created, the App-V client may load some data (the Publishing Feature Block) from that location into its local file system (ProgramData by default).

All later attempts to load data from the .appv file normally would use that initially provided location, PackageURI.

The Challenge

If you want to relocated your original download location, you have to do something. Otherwise some clients almost always would try to load data from the decomissioned source. For a change, you may consider using scripts that re-write all your package’s URIs on all your clients, or you may remove and re-add the packages (and before you ask: set-appvclientpackage doesn’t allow to change the URI) – but PackageSourceRoot is a more convenient way of doing that.

The Solution

The settings PackageSourceRoot that can be set using GPO, set-appvclientconfiguration or directly in the registry [Client/Streaming:PackageSourceRoot]. I prefer the methods in the order just provided.

Shortly after you changed that value, all subsequent attempts to read data from the .appv file are affected by PackageSourceRoot.

In PackageSourceRoot, you specify the ‘entry point’ for the new folder structure; underneath of it, the exact structure of the original URI location has to be mirrored.

Imagine your original URI was something like


And you were given a clustered file space at


Then you have to specify exactly that UNC stub as PackagSourceRoot (never mind the traling \ it’s automatically determined) and you have to copy all your packages into an appvfiles subfolder underneath of that.

This is because the App-V client strictly cuts off the ‘server part’ of the original URI (which may include protocols and ports) and replaces that with the PackageSourceRoot value. So the new URI would be:


Note that the client is smart enough to adjust slashes and back-slashes accordingly (back in the old Softricity days I was taught to call the back-slash a whack though others call the slash a whack and the back-slash a hack – thanks, Wikipedia!)


You need App-V 5 SP2 or App-V 5 SP1 HF3 in order to use PackageSourceRoot with more-that-one level of hierarchy! 

So, this is the URI the client is connecting to from now on, whenever it requires anything from the .appv file. This might be a mount-command initiated on the client (‘download all’), an out-of-sequence operation (that is: a bit has not yet been cached on the client and needs to be loaded in MS’ language) or the connection in Shared Content Store mode.


Even after configuring PackageSourceRoot globally on a client, the ‘add‘ command for new packages uses the location that is provided as a parameter to it. Your ‘old’ add scripts need to be adjusted to the new location. The same goes for specifying the location of a DeploymentConfig.XML file or UserConfig.XML file – they are passed as parameters to the cmdlets and have to point to the right – the new – location. PackageSourceRoot gets not interpreted for that.

Note that get-appvclientvonfiguration sometimes shows the new URI, while the registry still holds the original PackageURI.

Also note that the ‘normal’ App-V log doesn’t tell that much about using PackageSourceRoot. It is the Streaming Transport debug log that should be better here (except for Shared Content Store Mode errors..)



PackageSourceRoot can be used to re-configure the path to .appv-files afterwards, but it doesn’t get used for add operations or for pointing to Dynamic Configuration Files. It can, however, be used to relocate the Shared Content Store location.

To generate the new URI, the PackageSourceRoot string replaces the original server part of a package’s URI.

Hm too bad,  that page reached its end… you may find some additional details in the yet-to-come Client chapter of the App-V book ;-)

Posted in App-V, Client
Tags: , ,

1 Comment »

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: