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 provided Application Model Operation System Conditions for Windows 10 versions are limited in scope. Currently the Operator options for Windows 10 are two choices.

Windows 10 (Select This to get the two below)
All Windows 10 64bit ( or select one of these)
All Windows 10 32bit

As I am operating in an environment that now has multiple Windows 10 builds (IE 1709, 1809, 1903 etc) These each should be provided as evaluation conditions because I may have specific software that I am updated that is necessary on specific builds of Windows 10.

Windows Server should also be updated to reflect the same.

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.

By introducing new features or capabilities into CM not all wizards have been updated. That creates an inconsistent behavior. I tried to address that as bugs but was told this would be feature requests and must go to user voice.

Software Update Group Deployment & Automatic Deployment Rules
Software Update Groups can be deployed as available (we use this e.g. for the newest driver updates), but ADRs can only create Required deployments.

Provisioned appx
You can set on appx based applications ‘Provision this application for all users on the device’ and ‘Allow that application to be installed from the Install Application task sequence action without being deployed’, but task sequence Install Application UI is filtering all appx based applications out.
This is tested on CMCB 1910

There are many suggestions about reboots, but really, generally, there needs to be a robust and completely customize-able way to configure EVERYTHING about system restarts in ALL circumstances. Ideally this would be in a dedicated module, with the ability to create multiple definitions that can be applied to maintenance windows, application and update deployments, OSD, etc..

That means everything.....what kinds of prompts the users sees, what their options are in terms of postponing, conditional rules based on whether a user is logged on or not, EVERYTHING.

The VAST majority of my user complaints about system maintenance are related to systems restarting when they don't want them to, or failing to restart automatically without bothering them. I need to be able to force restarts during maintenance windows, if systems are locked, only if Application X is not running, only if the system is docked, etc...

Office Customization Tool should reference subcategories and needs to be updated from Office 2016 language. The same settings that existed in the Office 2016 Customization Tool still exist in the new tool but they are all lumped together in the root categories. Some of the settings names are vague and only make sense once you figure out what subcategory they were formerly associated with. For example, the settings for auto-correct are lumped together with security and encryption settings. Like the Office "Arabic modes" setting. I had to open up the description before it was clear this was a spell check setting and not a UI setting or character-set option. This wouldn't be confusing if it was listed under "Spell-check" or "Autocorrect."

Many of the setting descriptions still refer back to Office 2016. This seams to indicate that the settings were just carbon-copied from the old 2016 OCT. Unfortunely, they are not presented with the same context as originally intended so they make less sense. It shouldn't be difficult to just put the same categories into the new tool.

The new tool has room for improvement.