When deploying the new Cloud Proxy Service role in SCCM 1606, the user is asked to provide a Cloud Service Name. However, the UX does not explain that this is needs to be globally unique in all of Azure. I chose the name of 'SCCMCloud' turns out someone else already got that one though, and so the wizard completes and then fails in provisioning.

This is sloppy. The UX should include instructions for the end-user to validate their name first (which can be done in Azure -> Cloud Service -> New, you're able to test various names until you find one which is unique to all of Azure), OR the UX should integrate the same logic found in Azure and validate the name before we proceed.

Some replications groups are big like 'Configuration Data' and for big enterprises could go up to 30-50 Gigs. The issue is that is the BCPIn fails for some reason, the retry count is only 3 and until we realize we are in failed state. So if we fix the issue after sometime we have to again reinit the big group and that is again waste of time and bandwidth.
Currently we expose these settings in the SiteControlFile.
//
select * from SCComponentProperty where name like '%bcp%'

BCPOutRetryCount
BCPInRetryCount
BCPInBatch
//
We want to modify these settings say BCPInRetryCount to be more so that we can fix the issues that we incur and avoid the Reinit.

The introduction of preferred management points in SP2/R2 SP1 is GREAT! But I'd like to see the following added to the console to improve usability.

When viewing the properties of a boundary group in the console, you can add/remove site system servers on the 'References' tab. Pre SP2/R2 SP1, all you were adding here were DPs... now, those site systems can be DP's, MP's, and SMP's.

By simply looking at the list of site system servers, you cannot tell whether the server is a DP, MP, SMP, or any combination.

Please add 3 more columns or similar (one for each possible role) to display with check marks/dots indicating what roles are installed on each of the selected servers.

My customers would find this very useful, especially in environments with 100's of DP/MP/SMP's.

If we have a Named Instance and Intune Connector is installed, SQL connectivity is broken and most of the threads for SMSEXEC gets stuck in starting state until we modify the below registry
Go to “HKLM\SOFTWARE\Microsoft\SMS\Components\SMSDMPUPLOADER”

Original Values for the below keys will be as below:
Database Name = CM_PR1

 SQL Server Name = PR1.contoso.com\SCCM

Change the values as below: (Remove write permissions to this key only, and keep only Read permissions for all or alternatively make a copy of the original before doing so)
Database Name = SCCM\CM_PR1

 SQL Server Name = PR1.contoso.com

Where,
SCCM = Named Instance
CM_PR1 = Standalone Primary DB
PR1.contoso.com = Primary SQL Server

After this change, although everything else works fine, we see from a past case and my case that the Intune component gets broken
In our Case, Intune Component DMP Uploader still continues to be healthy

Flexibility in the upgrade process for allowing manual execution (in part or 100% - in the manner of the process used for the updates of Cumulative Updates and new releases made to the 2012 version and the 2012 to 1511 - more flexible and less plaster, mature, stable and be technically more professional for whom is running). This can eliminate the dependence of customers for handling patches of unsuccessful updates failures in SCCM databases by Microsoft engineering in case of failure (especially in the tables that control the update process itself), since this type handling is not supported by Microsoft is done by engineers who are not Microsoft's own.

The prereq checker will check a number of "things" on all site systems, including if the OS version is supported or not. However, if you have a large number of remote distribution points across very poor lines this can take many hours. I have recently upgraded a CM12R2 site to 1511. The prereq checker ran for more than 8 hours.

My suggestion is simple, in an upgrade scenario the prereq checker should read the number of packages that distmgr is allowed to process an use the same number of threads to check remote distribution points (or other site roles).

This would greatly reduce the time it takes to upgrade a site.

Currently ConfigMgr comes with tons of default Settings, Discovery Methods, Site Maintenance, Client Eval Settings, etc.
They are super generic, doesn't matter if I'm settings up a lab for 10 VMs on PC Hardware, or for prod with 500K clients on enterprise hardware, I get the same settings. I'd like the installer to scan the hardware it's getting installed on, and have that as a starting point, then ask me additional questions, Intended purpose, approx expected clients, single site server, or future additional servers, and expected roles, then give custom recommended template for settings to best fit my environment. I'd also like it to a button to "Show list of settings" so I can see what they will be with option to then modify it. I'd also like to export that setting template, so when I automate the install for a lab, I can just say setup.exe -template SmallLabSetting.xml and have all of those billion settings already pre-configured for my lab, etc. Thanks in advance.

It would be really great if there was an easy way to decouple components that run on one large Primary Site Server and transfer them on to a number of smaller machines and be able to migrate those roles across machines quickly (similarly to how this is done in SCOM with Management Servers and Resource Pools). That would allow the following:
1. Simplify Maintenance - currently, every time we need to patch SCCM Primary Site Server, we need to agree upon the outage window with all the teams that rely on SCCM. If we could move the workload, we'd be able to patch SCCM infrastructure without causing any downtime, That would also simplify the process of upgrading the underlying OS of the servers.
2. Better performance - If we could see that components of our Primary Server are overloaded (i.e. SUP, or Inventory processing, etc.), we could just add in more instances for those specific components.

Over any new feature, I'd love SCCM to just be faster in general. Just creating deployments and testing deployments is a notoriously slow process, even for a small 200 user organisation like ours.

First of all, the console itself is sluggish. There's a measurable delay accompanying almost every click. I'm not sure where the bottleneck is, but I'm suspecting it's the server-side architecture. It's bearable, but still frustrating when you're trying to get something done quickly. Replacing the clunky console with a snappier web interface (overdue in my opinion) would likely help, along with some architectural improvement in the background.

More frustrating, is the client. Refreshing policies and initiating scans, etc, is slow, and there's no feedback on progress or anything. If I'm wanting to test a deployment, there's so much waiting involved, and so little feedback for what's going on.

So where possible, please improve the general speed of SCCM. I'm sure there's a lot that can be done concurrently that's currently only single threaded. Also, please provide some means of checking progress on policy refreshes, etc. Trolling log files doesn't count as a solution.