Configuration Manager 2012 SP1 and App-V 5.0 Integration – More Than Meets the Eye

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on stumbleupon

Anyone would be forgiven for thinking that App-V 5.0 and CM 2012 SP1 integration is just a simple managed way of using standalone mode. By that I mean that Configuration Manager simply sends out PowerShell commands to add and publish packages leaving App-V to handle the rest. The truth is there is more than meets the eye!

Configuration Manager plays a much more active role than simply issuing the PowerShell commands to your App-V client. Those who recall App-V 4.x and Configuration Manager 2007 integration will remember VAppLauncher.exe taking over the shortcut extensions, well things haven’t changed as much as you think even though our shortcut paths no longer look like this:


C:\WINDOWS\system32\CCM\VAppLauncher.exe /launch “Paint.NET”

And more like this:




In the App-V registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming we have a value called LocationProvider. It is here that Configuration Manger will register itself once integrated with App-V 5.0, this happens after a package is deployed.


So what is the value we see? This can be found under HKEY_CLASSES_ROOT\CLSID\ where we register COM class objects. This particular GUID actually is a reference to the VAppLaunchManager component in Configuration Manager.


Further in the registry we can actually see the references to the CM component in C:\Windows\CCM\VAppLaunchMgr.dll:


When this LocationProvider key is populated App-V triggers a call into our LocationProvider to retrieve a Distribution Point (DP) URL to stream from at key points in time such as on publish or on creation of a streaming session. The LocationProvider also changes how certain App-V configurations are treated as we will go on to discuss.

On Publish

If we look into the VirtualApp.log on the client we can actually see how CM reacts to the publishing of an App-V application that is set to use the streaming delivery, here’s how the events unfold:

We publish an application (via streaming delivery) and a request for where the content resides is passed to the location provider


A list of DPs where the content is available is returned


We attempt to use the first DP in the list


The DP is not available so we fail to get the content


The failure is recorded and we skip the DP


We repeat this process for the remaining DPs in the list


This continues until we finally find a DP that is available with the content


So that explains the process the VAppLaunchManager goes through to determine where a package should be streamed from. The resultant actions can be found in the AppEnforce.log:

Configuration Manager assesses whether we need the package delivered


Any registered App-V Publishing Servers are removed



The install is then initiated with the stream location as the DP identified during the VAppLaunchManager process



The command to add the package into the App-V Client is then run



The command to publish the package into the App-V Client is then run



On Stream

Take the scenario when we are using a streaming delivery, potentially to a SCS mode client. This means even after a package has been published we will have a reliance on the DP being available to serve up our .appv content.  On creation of a streaming session we also go through the same process we would on publish of a package as explained above.

GetContentLocation(), Discover DPs, UpdateURL

Here we can see when we trigger a streaming session to be created for this application, we go through a very similar process on which we have already described:



Attempts to manually change the path of a package previously delivered with Configuration Manager via PowerShell are intercepted by the LocationProvider too and it also triggers the process as described above!


You can see here that even though we issue a command to change the path of the package, this triggers off the LocationProvider process and returns a DP value regardless. So we are unable to change the path manually via PowerShell.


So you might be thinking the PackageSourceRoot key which traditionally serves to override the default location of stream may be leveraged to change the streaming location, well infact once the LocationProvider is set, PackageSourceRoot is ignored and overridden. So no matter what value you put here it will be superseded by the LocationProvider.

Standalone Mode

Standalone mode works as normal, so we can deliver applications outside of CMs management, however that’s not to say it isn’t on the radar of our LocationProvider, when triggered, we will use the package GUIDs to check whether it has already been deployed via Configuration Manager, if not we will get the confirmation; “We will not set streaming DP for it, Ignore this request”. Thus allowing us to add a package with full control over its path.


Full Infrastructure Mode

As mentioned when the LocationProvider is triggered at publish or creation of a stream for an App-V package delivered via CM we actively remove any publishing servers registered with the client. This puts to bed the idea of managing and delivering App-V packages to a client via both CM and App-V Full Infrastructure! Even though you may get the delivery working from App-V Full Infrastructure, sooner or later CM integration will run the following commands to remove any publishing servers.


So to summarise!

  • ·        Configuration Manager 2012 SP1 tightly integrates with App-V 5.0
  • ·        It registers itself as a LocationProvider in App-V registry which allows its VAppLaunchManager component to dynamically choose content locations from available DPs.
  • ·        The CM VAppLaunchManager component retrieves a list of DPs where the content resides and iterates through the list to find where the content is available.
  • ·        The LocationProvider calls are triggered on publish of an application, creation of a new streaming session or attempts to change the path via PowerShell.
  • ·        The LocationProvider disables the ability to use Set-AppVClientPackage –Path to amend the path we use to retrieve a package from.
  • ·        The LocationProvider supercedes and overrides the PackgeSourceRoot key
  • ·        The LocationProvider removes any App-V Publishing Servers registered with the App-V client.

Leave a Reply.

5 thoughts on “Configuration Manager 2012 SP1 and App-V 5.0 Integration – More Than Meets the Eye”

  1. Hello Tham, I currently have an issue after we have removed a DP. The client is still looking at the server when it tries to stream and fails with a network error. The server was removed from the distribution group but is still up and running. Reading your article, which log file did you get the information from about Getcontentlocation()?

Comments are closed.