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.

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.

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.

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.

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!

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.

I would love to see a infrastructure health dashboard. A go to location for making sure all MPs, SUPs, DBs etc. are healthy, rather than having to go through system statuses in the console. Perhaps have some tiles that show how many endpoints are hitting each MP, SUP as well.

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.

When checking Client Status it would improve the experience if I could run ccmeval on a client that has failed any test immediately to see if the issue still exists.

The third party application SCCM client center provides essential troubleshooting support for the client. Why not integrate the features into the Admin console?

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