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.