A lot of customers would like to customize their admin consoles to add some missing views, columns and actions. For example, displaying User device affinity in Devices list or vice versa.

AdminUI.ConsoleBuilder is a good tool for this but it is very unfriendly and there is zero documentation on it.

It would be great if you add docs on it and improve the tool itself

The new client peer cache functionality is great and we are currently evaluating whether it can replace our current alternate content provider.
The main functionality that is missing in Client Peer Cache is a CLI or API that can be used on the SCCM client to download a specific content id.
It would be great if we could launch a command or cmdlet to trigger the download of content using client peer cache and if that is not available download from the DP.

Expose SMS_UpdateComplianceStatusAll in addition to SMS_UpdateComplianceStatus to allow 3rd party tools to differentiate between 'Not Required' and 'Unknown' compliance states for software updates.

The Control Panel app Configuration Manager Properties tool is an easy way to manually start client side actions on PCs. However you have no way to tell that the action worked unless you dig through numerous log files. A simple status message next to each command would allow you to see what is currently running on the client and when each step last completed. Would greatly speed up troubleshooting time and allow non SCCM admins a way to tell what is actively running.

The Messaging.dll only Support the old Boundary model for content requests and MP request. We need support for the new boundary model.

Each Company want's to have a 'software' catalog and be able to customize it the way they want.

Having one mandatory software center, even a new one, does not fill this need.

I believe the model with a WebSite and a Web Service like the sofware catalog should be extend for the whole applications, even applications actually targeted with the use of the software center.

At the moment, informations are acquired by wmi and also by the catalog web service, and it does not make it easy to develop our own catalog.

The built-in CM Client package is a predefined package and is locked/read-only. Alternate Content Providers (ACP) such as 1E Nomad are not able to officially enable this built-in package for distribution by Nomad.
This request is to formally allow and support the built-in CM Client package to be enabled for content distribution by ACP's.
This would require the ability to set the AlternateContentProvider property of the built-in CM Client package.

When running an action from the ConfigMgr control panel applet, e.g. "File Collection" or "Software Inventory" the action should be executed immediatley and not respect the throttling settings. Internally it should be handled differently whether an action is triggered by the scheduler or an user.

Currently there is no way to use Secret Task Sequence Variables in third-party extension to SCCM. Please, add API for this or document how to achieve this.

Currently we have the ability to post status messages in the OS, but not under WinPE. We'd very much like to be able to report on Nomad download progress during the WinPE stage of the deployment in order to true up the new Nomad dashboard with this part of the deployment process.

SMS_TaskSequence_RunCommandLineAction uses PackageID
SMS_TaskSequence_InstallApplicationAction uses AppInfo (and ApplicationName?)
SMS_TaskSequence_ApplyDriverPackageAction uses DriverPackageID
SMS_TaskSequence_ApplyOperatingSystemAction uses ImagePackageID
SMS_TaskSequence_UpgradeOperatingSystemAction uses InstallPackageID

While they are different objects and they do different things, shouldn't this be standardized across classes that can have content dependencies in a TS? This makes the data coming out of Get-CMTaskSequenceStep difficult to work with, as you have to keep a rolling library of properties to check for Package ID's.

If you play around with the possibility to send messages like inventory, ddr,... with the Microsoft.ConfigurationManagement.Messaging.dll it would be nice to write the message to a file on the lokal development system (for validation / verify purposes) instead of sending it over the wire to get the result.

We use Microsoft.ConfigurationManagement.Messaging.dll in Version 5.1706.1034.1000. The Discover() Method from "Microsoft.ConfigurationManagement.Messaging.Messages.ConfigMgrDataDiscoveryRecordMessage" return wrong results on CCM_Client (InstanceDataXml : <CCM_Client><ClientId>GUID:4D440652-FEC7-4709-B84C-1EC844F910FD</ClientId><ClientIdChangeDate>09/20/2017 14:50:30</ClientIdChangeDate><ClientVersion>5.00.8325.0000</ClientVersion><PreviousClientId>Unknown</PreviousClientId></CCM_Client>, We use current Version SCCM1702) and on CCM_DiscoveryData, the OS is Microsoft Windows NT Server 10.0 on a Windows 10 1703 Client (InstanceDataXml : <CCM_DiscoveryData><PlatformID>Microsoft Windows NT Server 10.0</PlatformID></CCM_DiscoveryData>)

Allow Console Extensions to access the Connected Site Code and Connected Server when launched from areas in the console that aren't IResultObjects. When an extension is launched from a node such as Applications or Packages, we no longer can use the ##SUB:__Server## or ##SUB:__Namespace## fields. Similarly for assembly based extensions, the IResultObject is null and we can't get at the IResultObject.ConnectionManager property.

ConfigMgr agents are able to fallback to an alternative SUP if the original SUP failed - agents do not fallback to the original SUP once it’s available again. In this case fallback needs to be triggered manually. This can be done from the console using „client notification“ – wouldn’t it be good to also be able to force SUP fallback on the client itself? Document a script method to switch to the next SUP that can be run on the client itself.

Administrators can use the "client notification" feature from the admin console to trigger actions clients. This is a very useful feature - it would be even more useful, if this actions could be scripted. Pls. document how to script "client notification" actions.