Once the cache has been filled all subsequent application deployments fail until the cache self-cleans. In CAS.log you see that the client is refusing to download the content because the cache, not the actual disk, is full.

This strikes me as a non-optimal design choice if the goal is to successfully install applications. If I want to install an application I do not want it to fail because of an artificial limit that until very recently was set at the time of client install. Most of the time the cache clears in 24 hours and there's no problem but there are two specific and prevalent cases where it is.

Task Sequences: During OSD we want every app and every update applied before the user gets the machine and we want it done quickly. It's very easy to go over a limit that day-to-day is ideal. This has forced SCCM admins to either abandon the application model during TS (a common MVP suggestion) or write custom scripts to temporarily increase the cache. Neither of these are ideal.

Large Applications: There are some applications (ex. CAD) that are just incredibly large (20+ GB) and all their own will exceed what an organization desires to reserve for cache size. Again, admins are either abandoning the app model entirely for these or running temporary cache modification scripts. This simply shouldn't be necessary for a system designed to deploy applicatons.

So, what to do? One option would to implement a rolling (first in, first out) cache where if cache space is needed the oldest non-persistent content for a compliant application is removed to make space. If the new app's content is larger than the cache itself then simply don't cache it. The only hard limit should be on the amount of free disk space to reserve before the SCCM client refuses to download content of any type.

TL;DR: Stop breaking application deployment just because the cache is full. No one wants to troubleshoot app failures.

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
AND
- 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): http://www.getonict.nl/docs/app-v-5-configuration-manager-2012-sp1-integration.pdf “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: https://blogs.technet.microsoft.com/configmgrdogs/2013/12/22/understanding-configmgr-2012-app-v-virtual-environments/ “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="http://schemas.microsoft.com/appv/2010/virtualapplicationconnectiongroup">
<CustomData xmlns="http://schemas.microsoft.com/appv/2010/virtualapplicationconnectiongroup">ScopeId_9F25ADC7-CC23-4D29-A9ED-ACF7E10130F2/VirtualEnvironment_20293df5-f3fa-41d0-b16c-57c1ad45bc06</CustomData>
<appv:Packages>
<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"/>
</appv:Packages>
</appv:AppConnectionGroup>

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 http://schemas.microsoft.com/appv/2010/virtualapplicationconnectiongroup schema is not used and is always the same.

SCCM 1702 introduced the Install Behavior tab for deployment types which lets you specify executables for the application to monitor during deployment. Currently, if the deployment is "Available" or "Available but before the deadline" then the install fails and users receive a pop-up indicating which executables need to be closed prior to your application running.

Enhancements:
1. Modify the feature so that the pop-up appears before the application install fails. If the user clicks "OK" then the application will perform the check again. If the executables are still open then the pop-up appears again. The pop-up will continue to appear until the user successfully closes the executables. Then the application install will continue. If no action is taken then the install will fail after the maximum allowed run time. This is similar behavior to the PowerShell App Deploy Toolkit.

2. Modify the feature to work even if a required deployment has hit the deadline. If the required deployment is past the deadline then the pop-up should appear until the monitored executables are closed. Again, if no action is taken then the install will fail after the maximum allowed run time.

3. Allow the same behavior to occur for both Install and Uninstall deployments.

The changes described above would allow for required deployments to exceed the deadline and always prompt a user to close applications before an install/uninstall occurs. It would also reduce confusion caused by failure messages presented before the pop-up explaining which executables need to be closed.