System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Virtual environment management

We cannot have AppV connection groups be successfully managed by current branch SCCM Virtual Environments.
It looks like:
- an application cannot be part of more than one virtual environment
- an application cannot have more than one deployment type in a virtual environment

According to what can be found in the documentation, it should be possible to achieve what we want.
- Old whitepaper (not anymore officially available, but we still have it): “Applications are allowed to be in multiple virtual environments to allow a single package to communicate with multiple, separate applications.”
- SCCM Current Branch documentation : no limitation.
But, according to: “a ConfigMgr virtual application can only ever be a member of one VE at any one time”

More technical details and scenarios:

We have 2 applications that needs to be in the same connection group : MyApplication and MyToolBox
For each application we have 2 deployment types:
- MyApplicationDT1 and MyApplicationDT2
- MyToolBoxDT1 and MyToolBoxDT2
for example to choose between “download” or “streaming”, depending on the target computers (RDS servers, branch offices, “road warriors” users laptops)

Scenario 1:

We create one single VE "MyVE":
(MyApplicationDT1 OR MyApplicationDT2) AND (MyToolBoxDT1 OR MyToolBoxDT2)

This is then what we got in the connection group ConnectionGroup_<GUID>.xml configuration file:

<?xml version="1.0"?>
<appv:AppConnectionGroup DisplayName="MyVE" IgnorableNamespaces="" VersionId="E0FC044B-EC5C-4796-BF76-80E47091FF1E" AppConnectionGroupId="27B2C858-ABB1-47F1-A086-096CBCC348C6" xmlns:appv="">
<CustomData xmlns="">ScopeId_9F25ADC7-CC23-4D29-A9ED-ACF7E10130F2/VirtualEnvironment_20293df5-f3fa-41d0-b16c-57c1ad45bc06</CustomData>
<appv:Package VersionId="fddfbc5e-1b31-4171-b747-c35a910b3d48" PackageId="6e70925c-6688-44d3-ab3d-571646e9abc1"/>
<appv:Package VersionId="fddfbc5e-1b31-4171-b747-c35a910b3d48" PackageId="6e70925c-6688-44d3-ab3d-571646e9abc1"/>
<appv:Package VersionId="1f488086-5820-4311-a853-a60f305ddd53" PackageId="3c9a6ddb-ae9f-4d6e-9f6a-528687e155b4"/>
<appv:Package VersionId="1f488086-5820-4311-a853-a60f305ddd53" PackageId="3c9a6ddb-ae9f-4d6e-9f6a-528687e155b4"/>

Therefore, when CCM tries to create the connection group, it fails with error 0480071392 / 0x87d0128f.

Appenforce log shows:
Add-AppvClientConnectionGroup : Application Virtualization Service failed to
complete requested operation.
Operation attempted: Add AppV Connection Group.
AppV Error Code: 0480071392.
Error module: Virtualization Manager. Internal error detail: 4FC02B0480071392.
AppVCommandUtil::RunAppVCommand() failed. (0x87d0128f)

Scenario 2:

We create two VEs:
"VE1" : MyApplicationDT1 AND MyToolBoxDT1
"VE2" : MyApplicationDT2 AND MyToolBoxDT2

=> connection group is created successfully, but every application evaluation cycle results in having the VE replaced: " A matched connection group created by App-V Server already exists in the client. Creating a new revision of it."
This messes up reporting and status in console.

It looks like SCCM's (Application, Deployment Type) couple is only translated into AppV's {package id} singleton.
We also have the issue that priority property of the <appv:AppConnectionGroup> node in schema is not used and is always the same.

106 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Sandrine LEGRAND shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Amit commented  ·   ·  Flag as inappropriate

    @ YQ thanks for acknowledging it. Hope we get resolution soon on random guid issue for XenApp farm.

  • YQ commented  ·   ·  Flag as inappropriate

    This should be resolved asap, as AppV 5.1 is pretty popular on XenApp 7.x farm.

  • Amit commented  ·   ·  Flag as inappropriate

    We currently use AppV 5.1 in our environment and use SCCM VE to link one or more AppV packages . Recently for our XenApp 7.15 migration work user reported issue where user settings were not getting saved when they move from one server to another. Upon detailed investigation we found that random GUID is getting created under HKCU\Software\Microsoft\AppV\Client\Packagegroups\{GUID}.
    In order to overcome this issue we need to include all pre-reqs like Sybase, oracle, java etc within same AppV bubble. This method is least preferred here and also not the best practise.

    We want MS to rectify it asap so that we can leverage usage of AppV VE in sccm more effectively.

  • naveen commented  ·   ·  Flag as inappropriate

    My customer have large number of app-v apps, are interested to use VE. the limitation of app-v application can not be added to multiple VE concern the customer . however, customer is expecting if this feature can be improved in near future will help them in managing app-v apps using SCCM and add value in using SCCM for app-v apps deployments

Feedback and Knowledge Base