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.

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:

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

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.