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:

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

HKEY_LOCAL_MACHINE\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.

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

HKEY_LOCAL_MACHINE\SYSTEM\Setup
HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup
HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup\Voatile - This key will show error codes for failed upgrades.
HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup\SetupDiag - this key is created when you run SetupDiag on a box to check for failure codes.
HKEY_LOCAL_MACHINE\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.

Business Case (I know how you PMs love these):
The current CB 1902 implementation is going to make this conversation part of our helpdesk script:
“What screen is the app on?”
“Can you move that window to the monitor where X is showing?”
“No, not that one.”
“Nope, still don’t’ see it”
“Ok let me reconnect in full screen, please accept the prompt again.”
“No no no, don’t hang up the phone, that’s not how this works.”
“Ok, you should see a prompt to allow me to connect.”
“Nope it’s there, trust me.”
“Got it, thanks. Ok, let me move that over here.”
“Ok, I’m going to reconnect again so I can see what’s going on.”
*Click*
“You just hung up, didn’t you?”

This is going to waste time on support calls and leave both sides dissatisfied with the entire experience. In turn, customers will continue implementing other third party remote control tools. Remove Viewer was absolutely a selling point for ConfigMgr and was one of the features that lured us away from our previous solution.

Solution:
1) The ability to select _any_ single screen connected to the remote device in addition to the current all screen view.
2) The ability to change monitor selection without having to reconnect the remove viewer.

Notes:
I could probably live with automatic reconnection provided that the admin stays in the Remote Viewer app at all times and doesn’t need to retype anything (device name/credentials) nor the end user re-accept the prompt if one is configured.
In my dreams the ability to pick a single screen is built into the full screen mode. In full screen mode the admin clicks a button that overlays each monitor with a number and an outline. If this sounds like display setting’s ‘Identify Monitors’ that’s because that’s exactly what I’m thinking of. However, don’t stop there. In that identification mode make the monitors selectable such that when I click on one it immediately becomes the single monitor I’m connected to.

When I started working with SCCM years ago I was told that you're not really an SCCM admin until you accidently deployed MS Office to the whole company. Through my years of working with SCCM I've seen many people update a collection not knowing that there was a mandatory deployment attached which resulted in the deployment getting sent to systems that were not intended.
I would like to see a check/notification box added when a query based collection is updated that reminds you of the required deployments attached. This message will only show if an unexpired required advertisement is still set. This would ensure that admins understand the potential impact of their collection change.

It has become a semi-regular occurrence in the various communities that someone has created a new environment or rebuilt their SUPs and suddenly none of their clients updates are managed by ConfigMgr and they're getting updates direct from Microsoft.

Often the root cause is that they did not add the new SUP to any boundary groups. It's an additional step that users just need to kinda of magically know ahead of time to do. Which is to say people aren't going to know and find out the hard way.

Let's solve this somehow. For me, making boundary group selection part of the SUP configuration makes sense. I'd suggest defaulting to the default boundary group in that scenario.

We have a need to run a scripted action [i.e. Ability to run one or more .ps1 Powershell scripts/vbscripts/batch files/cmd files] both before patching and after patching on specific machines that receive a SUG deployment.

These actions can be for a variety of reasons:

• Reboots before patching
• Stopping services or other applications processes
• Read server state and making sure it is set correctly after patching is finished

Currently we reboot 90% of our fleet before running patching to make sure system memory (we check memory?) etc. are clean, to allow the best possible patching result.
We have some systems that need a service shut down via a script as the stop action of the service requires a password. Or we have an application that needs to be stopped cleanly before patching can proceed successfully.

Also, with SQL clusters (and some other systems), we want to record the current state of the environment, patch, reboot and then make sure the server is set back to the recorded state or services and system are returned to a working state.

Currently there are two default configuration manager managed roles in ssrs: configmgr report users, configmgr report administrators. Both of these roles are managed by SCCM and you wont have an ability to modify any of the role permissions as SCCM will overwrite those. I would like to give users a bit more permissions by giving the administrators bit more flexibility to modify the default role permissions or an option to create a custom role in SSRS with the permission to do customization and map that role to the users through SCCM.

For me i need to remove "manage individual subscription" option for my report users. When i try to revoke that in the default role SCCM overwrites that using the stored procedures. Another option i have is to create a custom role in SSRS and give permissions outside of SCCM. That works but any reports using RBAC will fail to deliver the output. So i look for a feature either to edit the default role or to add a new role so that i can have users to run all sorts of SSRS reports including the one using RBAC.

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.