With the release of CB 1806 we are now able to publish third party updates using custom catalogs. Ideally, third party patches would function exactly like first party patches from an administration and automation perspective. Currently there's two main areas where this is not the case.

Synchronization Schedule:
I could be wrong on this but I believe that subscribed catalogs sync automatically every 24-hours. While that's nice, it would be great to simply integrate with the existing sync schedule. Sync the catalogs, publish relevant metadata to WSUS, then sync the SUP(s).

Automatic Deployment Rules:
Currently, only update metadata is published by the automated sync process. In order to actually deploy an update you must manually right click on it and select 'Publish Third-Party Software Update Content'. That a big cold automation wet blanket. A few ideas, in increasing order of greatness:
-Publish the full content of a given catalog. Not ideal, but it solves the automation problem.
-Publish full content for only the product selected to sync in ConfigMgr. Much better than everything, solves automation, but still will include updates you don't want.
-Publish full content when selected by an ADR. A bit tricky since you'd need to publish the content, resync, and then deploy but your the best team ever so I know you have it in you.

 Bryan

When you use Task Sequences (TS) to deploy software (non OS TS) and there is a reboot inside of the TS there will be no ProgressUI at the logon Screen after the reboot. So you can't see the Progress of the running TS or there is a TS running.
If You logon, after a short time the ProgressUI will start.
We started a MS Case (REG:116092814729429): This is a expected behavior because it's not planned for out of WinPE stage.

Please implement the start of the ProgressUI after the reboot inside of the TS, so we can see the Progress at the logon Screen.

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 Microsoft Local Admin Password Solution (LAPS) is great because of the security it provides, but is not in widespread use because it isn't enabled by default and requires desktop/server teams to work together to implement.

Integrate the functionality of Microsoft LAPS into the ConfigMgr infrastructure.

This could include simple steps to control replace the group policy need with a new compliance item node, or could include completely supplanting of the functionality (similar to how MBAM makes it so you don't need AD for managing BitLocker recovery keys).

Anything that ConfigMgr can do to bring down the bar for securing local admin passwords would do a great service to organizations.