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.

There is SCCM CB 1806 (5.0.8692.1509) with the update "kb4462978" in the console installed.
When using automatic upgrade and package deployment to provide CM client version upgrades,
From the distribution point, although "client.msi" can be acquired, if "configmgr 1806-client-kb4462978-x64.msp" can not be acquired for some reason, a scenario occurs that results in "5.00.8698.1008" version did.
If the MSP file can not be obtained, CM client version upgrade is expected to fail, but the result is not "5.00.869. 1509" but the "5. 08. 692. 1008" version.
Success itself is a problem. The administrator misunderstands that the version upgrade of the CM client by the target version is successful.

As a workaround, for example, it can be avoided by including "configmgr 1806-client-kb4462978-x64.msp" in "client.msi".
If it is a version other than the purpose, we will ask for functional improvements that make it fail.

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

Please Make CM aware if an OSUninstall (Reverting to previous Build) has happened, so it can heal itself into a functional state. Currently if you perform an OSUninstall from say 1809 to 1709, after you've upgraded originally to 1809 using a CM Task Sequence, the CM Client is non-functional.
Client is in Provisioning Mode, Services are disabled, and once you fix that, it thinks it's int he middle of the Task Sequence and shows the Upgrade TS "Installing", so then you need to clear that out.

Please make OSUninstall & CM Play Nice together, so we can offer users the ability to revert to previous build if they find an application problem or other issues after upgraded.

In the customer environment, help desk users have installed the Configuration Manager console and used the remote control function.
In this situation, when the load on SCCM server is high, there is a problem that a session can not be established temporarily.
We would like CmRcViewer.exe to be provided as a single application without depending on the load of SCCM server, as it will interfere with help desk operations.

Additional Information:
Although not supported at present, we have confirmed that session establishment can be performed by executing the following files.

1. Copy the following files from the SCCM primary site:
<SCCM installation path> \ Program Files (x86) \ Microsoft Configuration Manager \ AdminConsole \ bin \ i386

Required files and folders:
-CmRcViewer.exe
-RdpCoreSccm.dll
-0000409 folder (CmRcViewerRes.dll only)

2. Run CmRcViewer.exe on the help desk client.