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.

1. 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.




2. 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.

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">ScopeId9F25ADC7-CC23-4D29-A9ED-ACF7E10130F2/VirtualEnvironment20293df5-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.

TL;DR: Make Phased Deployments for Applications the same as Phased Deployments for Task Sequences where you can create up to 10 phases and manually initiate the second phase of deployment.

Explanation:
Currently in 1806 although you can create a phased deployment for an Application, you're limited in two key areas:

1) You cannot manually create phases for an application
2) You cannot manually begin the second phase of deployment for an application
3) You are limited to 2 phases for an application

In our environment we follow a controlled graceful deployment process where an Application Model application is deployed office-by-office to prevent flood of support calls should an unexpected situation arise. Since we have multiple offices across the globe, a single application may have as many as 13 deployments, although it's typically around 6.

Phased Deployments is the solution here but it's usefulness in the context of Applications is limited. If it could match features available in Task Sequence deployments it would be of significant value.

Documentation:
https://docs.microsoft.com/en-us/sccm/apps/deploy-use/deploy-applications
https://docs.microsoft.com/en-us/sccm/osd/deploy-use/create-phased-deployment-for-task-sequence?toc=/sccm/apps/toc.json&bc=/sccm/apps/breadcrumb/toc.json
https://docs.microsoft.com/en-us/sccm/osd/deploy-use/create-phased-deployment-for-task-sequence

For complex software deployments, we regularly use Task Sequences to sequence reboots and installation orders, as well as containing logic on the various steps to only run when certain conditions are met. This allows for much more complex and flexible deployments.

The problem is, if a reboot step is initiated, no Task Sequence progress is displayed to the user to let them know that installations are taking place behind the scenes. To them, the reboot occurs and then they return to the CTRL+AT+DEL screen.

It would be great if a new class of Task Sequence could be created that would show progress to the interactive user after a reboot. Call these "Application Task Sequences"