With 1610, the Cloud Management Gateway feature arrived. Although it's a Pre-Release feature, as Cloud Solution Provider we're UNABLE to use/implement this. And so are our customers...!

When you try to set this up from the ConfigMgr console, a prerequisite is the Azure Management Certificate, which can't be configured as CSP-tenant because this needs the Classic Azure Portal (ASM). This is unacceptable for us, as CSP, as we would have to instruct our customers to get an Azure Subscription separately.

https://blogs.msdn.microsoft.com/cie/2016/11/28/azure-management-certificates-and-publishing-setting-file-with-csp-subscriptions/

Current architecture around SCCM’s management of SQL configuration and maintenance is old and hard to use. It requires a lot of manual oversight, and manual SQL tasks. And the default SQL settings created by SCCM are non-optimal. SQL is a powerful beast. Rethink ways SCCM can use it better, and keep it more optimally tuned and configured. Rethink how to run maintenance and backup tasks without downtime or impact to the production sites and deployments (this especially becomes more important with features like Conditional Access, that can never really have downtime.)

It's a real pain to have to tear down and rebuild the MP replicas every time I want to install a servicing update. It would be great to have the update process automatically save the replica state, point the MPs at the primary DB, tear down the MP replicas, do the update and then put it all back.

When doing an upgrade to SCCM, it has been recommended to disable some, or even all of the site maintenance tasks. (per the upgrade checklist) Would be awesome to have a box on the Maintenance Tasks screen to temporarily disable ALL tasks while the upgrade is being performed. (as opposed to manually disabling all of them) An "upgrade/maintenance mode" box essentially!

Support ConfigMgr to be installed on Azure VM IaaS using SQL Paas as DB.

Configuration Manager currently installs binaries and configures the SQL backup site component service on the database server, running under LocalSystem authority. Many environments have separate groups that host and manage the SQL Server enterprise environment, and do not allow for services or additional software to be installed on them, creating unnecessary conflict and drama when SCCM needs to be installed. SQL Server is a networked service, there shouldn't be a reason to install software on the database server running under a privileged account in order to leverage backup routines.

Have the ability to add a second Primary Site Server to an environment running as a standalone site to allow migration from an older Operating System to the latest version e.g. Migrate your 2012 R2 SCCM server from 2008 R2 to 2012 R2 by adding a second primary site server, and allowing settings, data etc. to synchronise. Then retire the old 2008 R2 server.

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

CM12 is able to migrate only one secondary at a time.

Service accounts should be domain aware so that they do not attempt to authenticate against the wrong domain to lock out service accounts with the same username but on another domain.

When going through the process of changing the configuration for the site database (in order to move it to a new SQL server), if you are keeping your SQL server name the same, the wizard will not allow you to input the same SQL server name as the old. We want to get rid of our SQL 2008 R2 servers running on Windows 2008 R2 and replace with Server 2016 and SQL 2016, but also keep the same hostname for the new server. Our only option since the wizard doesn't support this scenario is to do a backup and restore.

Setting up and managing the certificates for MPs, DPs and boot media is not straight forward. Could you improve the certificate management process to reduce the complexity and overhead in managing it. So automation with internal CAs for automatic certificate issuing would be good.

Upgrade needs to have better logging - for example during an upgrade, the spimportinventory stored procedure was failing on a merge with SQL error 8672:
The MERGE statement attempted to UPDATE or DELETE the same row more than once. This happens when a target row matches more than one source row.

Tracking this down was difficult because of the MERGE statement - if each row were being processed separately, the specific problem data could be called out when an error occurs.

I found some customers which has "SMS" as name of SCCM site. This make a lot of problems with normal management. This name should also be make as do not allowed (wizard blocks also other names). And if already named, it should allow one time change.

If prerequisite checker fails with a warning there should be an option to continue with the upgrade anyway.