Oct 02, 2013 - 5 Comments - Virtual Vibes -

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

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:

4.x

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

And more like this:

5.0

%LOCALAPPDATA%\Microsoft\AppV\Client\Integration\CA43F9E3-4C6F-4A71-8EE9-977EF8FF5F20\Root\VFS\ProgramFilesX86\Paint.NET\PaintDotNet.exe

LocationProvider

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.

locationprovider

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.

clsid

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

vapplaunchmgr

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

virtualappstep1

A list of DPs where the content is available is returned

virtualappstep2

We attempt to use the first DP in the list

virtualappstep3

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

virtualappstep4

The failure is recorded and we skip the DP

virtualappstep5

We repeat this process for the remaining DPs in the list

virtualappstep6

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

virtualappstep7

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

appenforcestep1

Any registered App-V Publishing Servers are removed

appenforcestep2

appenforcestep2-1

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

appenforcestep3

appenforcestep3-1

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

appenforcestep4

appenforcestep4-1

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

appenforcestep5

appenforcestep5-1

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:

onstreamvirtualapplog

Set-AppVClientPackage

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!

setdash

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.

PackageSourceRoot

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.

adddash

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.

appenforcestep2-1

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.

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

  1. App-V 5.0 Ramp up Guide | VirtualVibes

    […] Configuration Manager 2012 SP1 and App-V 5.0 Integration – More Than Meets the Eye | Blog […]

    1 May 2014 - Reply
  2. Gauntlett

    Great article mate, thanks!

    18 Jul 2014 - Reply
    • Thamim Karim

      No problems!

      18 Jul 2014 - Reply
  3. App-V 5 Streaming Decision Points | Virtual Vibes

    […] note however this setting will be overwritten in SCCM deliveries due to the LocationProvider unless you take the steps mentioned […]

    21 Jan 2016 - Reply
  4. Ian

    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()?

    4 Jan 2017 - Reply

Leave a Reply

Your email address will not be published. Required fields are marked *