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?

Most of the support desk do not have the needed knowledge to go to all the logs on a client and check why an application is not installed or do not appears in Catalog.
Is it a policy issue , a Global conditions issue , does a requirement is not met , is a dependencies not installed ?
Add to this one time to go to log you need ScopeId or CI , or Policy ID , all this make difficult the job for a SD Level 1 or 2
Results it come too often to Level 3 and Admin level and cost money for nothing

Starting with ConfigMgr 2010 the functions of the CEviewer are being moved into the console. One thing that the old tool was useful for was quickly showing how many incremental collections were in in an environment and what their total runtime was. Since there are performance limits to incremental evaluation it would be helpful to show inexperienced admins that they might be running into trouble by having too many or poorly performing collections set this way. I suggest that functionality be added either to the user/device collections view to show if incremental is set or not for a collection and that a I notification be shown in Insights if there are issues found (too many incremental or processing time too long).

We get about 1000 deltamismatch BADMIFs generated each day.

Here is the case of sccm client Inventoryagent.log says successfully sent but the ccmessaging.log shows the upload failed.
Why can’t the client inventory agent act on the status back from ccmmessaginglog and if the upload of the inventory fails, don’t increment the delta number.
This would greatly reduce the number of deltamismatch files generated each day and improvement keeping the inventory up to date without having to force a full inventory sync for this case.

Here are the details:

Dataldr.log for computer: CHOSIJ1-L2

Thread: 6108 will use GUID GUID:c28fa179-d722-4692-be69-a71f5a81e75c SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
Processing Inventory for Machine: CHOSIJ1-L2 Version 2.7 Generated: 06/23/2020 14:04:44 SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
Begin transaction: Machine=CHOSIJ1-L2(GUID:c28fa179-d722-4692-be69-a71f5a81e75c) SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
WARNING - Attempting to resync due to missed delta reports (sp return code = 7) SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
Rollback transaction: Machine=CHOSIJ1-L2(GUID:c28fa179-d722-4692-be69-a71f5a81e75c) SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
SQL MESSAGE: dbo.spAddInventoryLog - Inventory Log for machine:CHOSIJ1-L2,Server:2.5,Client:2.7,Message:Missing Delta. Resync,Detail: SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)

Shows processing 2.7 but database is 2.5 – force a re-sync

Client tried to send delta 2.6 at 6/22/ 10:55am – but the network was not working client probably dropped vpn or connected vpn

Client Inventory Agent.log at 6/22 @ 7:41am starts processing delta 2.6
Inventory: Action=Hardware, ReportType=Delta, MajorVersion=2, MinorVersion=6
Reports successfully sent at 10:55am
Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint, ID: {1090DA21-86C6-44C8-9C38-260F7824060E}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted

CCMMessaging.log @ 10:55AM shows it failed:
[CCMHTTP] ERROR: URL=https://MSPM1BADP20.ent.core.medtronic.com/ccmsystem/request, Port=443, Options=448, Code=12007, Text=ERRORWINHTTPNAMENOT_RESOLVED

In summary if the InventoryAgent.log could detect that the Inventory was not successfully sent then don’t increment delta to 2.6 leave at 2.5

Thanks