The Run as High Performance Power Plan option for task sequences does not work properly. Even though it does set the current plan to High Performance, the default values under this plan for standby-timeout-ac (10 minutes) and standby-timeout-d (4 minutes) which is not adequate for most tasksequences to complete before a device sleeps. This option needs to be able to configure the plan to not sleep or hibernate in addition to setting it as the current plan. I've attached a copy of the High Performance power plan for Windows 10 1909 for reference. This power plan is mostly default except for the hibernation settings which we are disabling during the Tasksequence. It would be much nicer to have a single check box be able to keep the devices from sleeping or hibernating during a Tasksequence rather than have to implement work arounds wihtin the tasksequence. Whatever the solution is, it will also needs to be able to handle Connected Standby settings as well as warn when GPOs present might be preventing the changing of plan settings.

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.

Microsoft Case ID: [Case #:24522893] - TrackingID#120121125002133.

While troubleshooting on the case we noticed that Windows Defender was performing 2 WMI queries through SCCM every minute, even when Defender was disabled on the system. These queries generate about 70.000 events (detected via procmon) related to the registry every minute.

The cause of the query is ccmexec.exe
The queries are (detected via procdump):
select * from _instancecreationevent within 60 where targetinstance isa "win32service" and ( targetinstance.name="msmpsvc" or targetinstance.name="windefend")

select * from _instancemodificationevent within 60 where targetinstance isa "win32service" and targetinstance.state="running" and ( targetinstance.name="msmpsvc" or targetinstance.name="windefend")

Antivirus scans those actions (as any Antivirus program does), and as a result the CPU usage caused by these WMI queries was multiplied.
 
These queries cannot be disabled, while it was confirmed by Microsoft that these queries are not required in case an external thirdparty antivirus program is being used.
 
The advised approach was to try to minimize the amplification by Antivirus, which indeed added a positive impact. Detailed tuning of the antivirus policy with a focus in these WMI queries resulted in a reduction of the amplification.

It was agreed that this solution is an acceptable work around. And for the WMI Queries to be disabled, we already have a Design change request in place with SCCM Team to take this into consideration and validate if this could be resolved in upcoming versions. I was advised to raise this issue in the Microsoft User Voice in order to gain support for this Design change request.

See process explorer printscreen:

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).