It's time

Make the log files directly accessible via the console rather than digging around in the file system trying to remember which file holds which logs and ideally make them accessible from a context menu in the relevant areas.

There is a lot of very detailed information in the individual component client logs files, But with all that detail in so many logs, it can be difficult to tell what the client is doing at any given time. I would like to see a master log of all the high level client activity and timestamps.
12:00 hardware inventory started
12:02 hardware inventory complete
12:05 policy download
12:08 software inventory started
etc...
It would help narrow down the number of logs to examine and the timeframes to look at.

On client machines, in Configuration Manager Properties and the Actions tab I would like to see the addition of a 'Run All' button rather than having to click on each individual action and then click Run Now.

Thanks,

Andrew

There should be a built-in PowerShell Cmdlet to disable/enable verbose,debug,sql...etc. logging options instead changing Registry keys.

Please remove feedback button from the rubbon and add-it only on the (Alt-F) Menu (Backstage tab).

Too many feedback button appear on the console since 1702.

we need a better way to check, and resolve client health from within the console with out having to go the web and collect a wide range of third party scripts/apps to help resolve the issues.

for example: duplicates GUID. inactive clients, etc..

things like this should be available from the start.

The easiest way to find a device on a network is with the physical layer information. I can't even understand why this wouldn't be an option. At times while troubleshooting getting the IP address from the end user is the only information that you can gather.

One of the most issues found is database performance based on fragmented indexes. A notification or automatic defragmentation on for the relevant indexes would be nice.

@JasonSandys: "When it works, it works fine. When it breaks, God help you cause no one else can."

Add your comments on how we can make this better.

Configuration Manager Service Manager (the start/stop services window) should be in built-in as part of Monitoring, and sped up!

Make Software Center available (as an App?) so that you can see exactly what is in Software Center for a remote machine. You launch the app on your technician PC, supply the machine name and user name and the Software Center shows up on the technician PC with exactly what the user sees. This would be very valuable for level 2 and service desk people to help users.

Many times when you are testing something with ConfigMgr, you'd like to send client state messages immediately to MP. Now you need to wait for state message reporting cycle to occur. You can start the other client cycles manually with Configuration Manager Control Panel utility (or remotely from ConfigMgr console) except state messages.

In https://support.microsoft.com/en-us/help/3213242/software-metering-agent-fails-with-software-metering-failed-to-start-p, MtrMgr.log may indicate that the prepdrv is no longer successfully registered. A potential fix could be adding a CCMEval task which would detect if Metering is enabled on the client, and if so, confirm that prepdrv is successfully registered (read mtrmtr.log, but there may be a better programmatic way to do so), and if not successfully registered, register it.

Issue:
SCCM clients get stuck after a while when devices use only sleep/hibernate mode instead of restart. The ccmexec service still show running but logs are not updated anymore and not reporting at all. Only killing service and restart solve the problem. Two times showed during MS cases.
Idea: Improve Client health to check for instance once per day the health of ccmexec service and logs timestamp and restart service if required.

For large environments the ability to log to a central database. this would collective provide a central location for all server logs (DPs, MPs, ect..) deployments with a high server count (500 DPs), if\when there is a issue, the logs role over very quickly and the chance at catching the issue is not likely

Record log file entries in local client time NOT UTC. cant accurately trouble shoot time sensitive event.