Would like to have the ability for the end user to not just install an available deployment, but also launch it there. The way I envision this happening is once the user has installed an available deployment, the "Install" button would change to a "Launch" button, and the Uninstall button would be perhaps a separate button, etc., or perhaps even the icon of the application could be used to launch it and the Install/Uninstall behavior could remain the same.

The benefit of this would be (1) if you removed the start menu or other entry points to the application and forced the user to launch it this way, you could truly know every time they launched the application unless they pinned it or browsed to the executable manually and (2) this would provide an elegant way to implement changes for the current user (e.g. HKCU registry entries required for the application to function, or %USERPROFILE% changes required for the application to function).

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

There are several registry keys which contain information about the currently installed Operating System as well as Installation/Upgrade history/errors/status information. These keys provide a valuable source of information that could be used for building reports/collections related to OS Deployment. One of the major barriers mentioned for not deploying Windows 10 Feature Updates from Windows 10 Servicing in the console is the lack of visibility/reporting available. Adding these registry keys to the default hardware inventory included in SCCM instead of having to customize inventory would make it easier to share reports/scripts/etc related to this data and could likely be built so that it could all be collected into a single table instead of several separate tables which result from current MOF customizations.

Examples of the keys (and sub keys in most cases) include:

HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion - shows all current OS installation information including the ReleaseId which is not included in inventory today.

HKEYLOCALMACHINE\SYSTEM\Setup\Source OS * - a new date stamped key is created for each upgrade that is done on a machine. You can use this to build upgrade history reports and distinguish between upgrades and new builds.

HKEYLOCALMACHINE\SYSTEM\Setup\Upgrade - the DownLevelBuildNumber key shows build of the last OS that was upgraded from.

HKEYLOCALMACHINE\SYSTEM\Setup
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup\Voatile - This key will show error codes for failed upgrades.
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup\SetupDiag - this key is created when you run SetupDiag on a box to check for failure codes.
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup\Tracking - logs the number of install attempts and failures.

We have been extending our inventory to included these keys and it has greatly simplified our upgrade and OSD reporting and remediation efforts.

Status messages are amazingly helpful in the SCCM console, but difficult to get to. For instance, whoever wrote the status messages for Task Sequence deployments did an amazing job, yet I cannot access these without making a custom query! This is an amazing troubleshooting tool that is hidden from the average user.

I'd like to get access to status messages from the object that makes the status message. For instance, if I right click on a task sequence deployment, I want to be able to view all status messages associated with that object. If I right click on a distribution point, I want to see all messages associated with that DP. The same with content, devices, users, etc.

I've written console extensions that pass data from the console to statview.exe to add these features in myself, but really it should be something that's included by default. It'd be amazing if it just opened statview.exe and didn't redirect to another screen in the console also.

Once I wrote the extension, I couldn't live without it at any client I went to. Being able to view all the OSD status messages for a specific deployment by simply right clicking on that deployment is an amazing help!

When creating the Configuration Item (Create Configuration Item Wizard, Settings step) and choosing Registry setting type for the Create Setting window, there are some bizarre registry types mentioned in Data type drop-down box: String, Integer, Date and Time, Floating Point, Version and String Array. Most of these data types are all REGSZ type. But where is REGMULTISZ? REGEXPANDSZ? REGDWORD? REGQWORD? REGBINARY?
There is also possibility to set/check compliance for those registry settings with script, but why the Registry Configuration Item in first place?
These actual registry data types need to be implemented instead of/additionally to currently existing ones.

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.