The Current Branch 2002 release introduced a feature to install SSUs first but only when triggered by the deadline.
From the docs:
"SSUs are installed first only for non-user initiated installs. For instance, if a user initiates an installation for multiple updates from Software Center, the SSU might not be installed first."

A lot of work has been put into encouraging user-participation in the patching process. I want the user to decide when they're ready to install the updates and avoid situations where the deadlines impact their work. In those scenarios the behavior introduced in 2002 therefore not helpful.

I realize that if a user manually triggers the installs one-by-one that there's not much you can do about it. However, in pretty much every other scenario I would like to see the SSU install first.

For example:
User schedules the install from the update notification dialog.
User clicks 'Install All'.
User select multiple updates, including an SSU.

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.

The sccm client startup process is very heavy. On our machines we have a very demanding security baseline which gives us a huge windows security eventlog. Reading out this eventlog alone takes over 30 seconds at 25% CPU which makes the startup process of the computers even slower than it is. As we understand it SCCM reads pretty much the entire security log every time the service is started. Even if it's started twice in 30 minutes for whatever reason. We aren't sure what the point is of reading out 100MB of security logs, but it seems a waste. We'd like to see the startup routine be lighter, tweakable or maybe that it would just read out the delta with the previous time it read out those logs?

It would be very helpful if the Properties window of a device included all of the information in the Resource Explorer.

Motivation:
1. I almost never open the Properties view because it rarely contains the information I'm looking for. The Resource Explorer, on the other hand, has almost everything.
2. Having the Resource Explorer buried under a sub-menu makes it difficult to train and convince technicians to use it in their day-to-day workflow to find information and solve problems.
3. Since Resource Explorer is far more useful than Properties, it should be the easier of the two things to get to. Currently, Properties is a simple double-click while Resource Explorer is a right click, two mouse movements and one or two single clicks.

Implementation Ideas:
1. It could be a tab contained within Properties (while retaining a full version of Resource Explorer for when you need a larger window), or it could be a complete rework of the Properties GUI.
2. All information currently accessible still needs to be accessible.
3. Combined window still needs to be resizable like the Resource Explorer window.
4. Double-click on the device should open the combined window.
5. Lazy loading of data may be helpful if opening the embedded resource explorer hurts the responsiveness of the Properties window.

Alternative Suggestion: As an alternative, I'd be OK with having a console option that replaces Properties with the existing Resource Explorer as the double-click target. This may be more polarizing among the user base though as some users may prefer the quick access of the Properties window as the default target. If this alternative were implemented, it should allow the user to choose which view is their default.

We have a lot of different kinds of Dell client computers and some of the model names are very alike.

We also have a network which doesn’t allow us to use peer-to-peer techniques to lower bandwidth usage so we need to create rings and make a couple of computers at the time pre-download osupgrade packages and drivers before deploying an IPU to the mass.

Two of the models we have are "Latitude 7390" and "Latitude 7390 2-in-1".
(This is not the only combo of models that suffers from this behavior)
We've created one driver package for each of them.
But the "Latitude 7390 2-in-1" will always download them both due to what is stated here:
https://docs.microsoft.com/en-us/mem/configmgr/osd/deploy-use/configure-precache-content

"The actual query uses a LIKE statement with wildcards: select * from win32_computersystemproduct where name like "%yourstring%". For example, if you specify Surface as the model, the query matches all models that include that string."

"Latitude 7390 2-in-1" LIKE "%Latitude 7390%" will always be evaluated as true so a "Latitude 7390 2-in-1" will not only download the correct driver package, but the package for the "Latitude 7390" as well.

This is the direct opposite of what we're trying to accomplish, saving bandwidth.

Suggestion:
Add an "Exact match of model name"-kind of checkbox to driver packages and make the query model="yourstring" if it's checked.
Or even better, let us write the query, just as with conditions of a TS step.

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.