When installing an application there is frequently a system-space component (the main install) requiring admin/system level access and a user-space component (usually configuration or licensing). Less frequently but frequent enough is that all existing users and any new users that log into the device need those user-space components. Currently there is no good, supported, method for doing so. Admins are forced to use either Active Setup (unsupported and recently broken by Win 10 IPUs), Group Policy Preferences (messy, poor targeting, and very non-obvious separation of app logic), or roll their own (login script that does a bunch of custom stuff).

What I am proposing is a supported method within Configuration Manager to install the main app in the system context and then optionally run something else in user space for the logged-in user, all existing users, and/or all future users of the device. Minimal viable product: ability to run a script along with content.

All Existing Users: This would involve looping through all existing user profiles and injecting the registry values and files or running the script.

All Future Users: This is slightly more complicated and gets into replicating what Active Setup does. During login use some method to determine if the user-space configuration exists. If so, do nothing. If not, apply the user-space configuration.

Stretch-Goals:
GUI – It’d be awesome if there was a UI for registry and file configurations instead of having to script those every single time. It’s not hard to script but doing so is tedious, outside of many admins comfort zones, rarely logged correctly, and thus prone to error.
Versioning – Allow the user-space configuration to be versioned and if a new version exists optionally overwrite this on existing installs.
Uninstall – When the application is uninstalled undo the user-space configurations. This is where having a GUI would be awesome: ConfigMgr could automate it. A script-based solution would require and uninstall command.

Note: With the arrival of Application Groups the ‘only for logged in user’ use case could be considered already handled within ConfigMgr. While true that would only really benefit user-targeted apps otherwise it’s a ****-shoot if the user(s) are logged in at the time. If you made a user being logged in a requirement then you lose the immediacy of doing this at logon. They may have the app installed but it’s not going to be configured (ie: work) until the second app gets evaluated.

TL;DR: Active Setup is a real need, widely used, but unsupported and recently broken. Please fix that by implementing those features and more in ConfigMgr.

The installation program visibility in the User Experience tab on Application Deployment Types allows the selection "Hidden" which is defined as "Hidden: The deployment type runs hidden on client devices. Users see no installation activity." (https://docs.microsoft.com/en-us/sccm/apps/deploy-use/create-applications#bkmk_dt-ux)
However, this only applies to the FIRST process being spawned by the execution of the defined install/uninstall/repair commandline. All other processes are spawned *interactively* on the logged on user's desktop even if the option "Allow users to view and interact with the program installation" is NOT checked.

Right now this behavior prevents us from using Applications instead of Packages as exposing the installation process or script execution to the logged on user poses a risk in users interfering with the correct execution of the application.
This is a no-issue for Packages as their Program environment and deselected option "Allow users to interact with this program" actually hides *everything* the Package/Program are supposed to do.

I know that in the attached example the MSI runs with /QB- instead of /QN (which would hide that single instance) but that does not change the big picture: "Hidden" should be "hidden" and not "First process starts hidden and the selected option for the program interaction also does not apply".

Also submitted as Feedback SubmissionID 0b688ee3-7af0-44bb-9c25-24d38a08f2bb as I think this is more of a bug or lack of clear documentation than it is a "new" feature.

Since 2012 RTM, ConfigMgr has inconsistent experience for application deployment monitoring described in these blog entries:

@Michael Wray: https://techcommunity.microsoft.com/t5/Configuration-Manager-Archive/Troubleshooting-In-Console-Monitoring-for-Deployments-in-System/ba-p/273015
@Umair Khan: https://blogs.technet.microsoft.com/umairkhan/2014/10/02/the-case-of-the-unexplained-application-deployment-monitoring-reports-which-one-to-rely/

Basically, we count Application Infrastructure errors in all pie charts both in Monitoring\Deployments Console node and application reports, but we don't have any pre-created way to find failing clients except "Application infrastructure Errors" report.

It would be good idea to list the assets affected by infra errors in separate deployment monitoring tab, or together with failing DTs in the console. Also it would be nice to modify pre-defined reports to be more consistent and list also affected assets in All Application Deployments (Basic and Detailed) reports.

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