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.

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.

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.

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.

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.

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.

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.

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

We get about 1000 deltamismatch BADMIFs generated each day.

Here is the case of sccm client Inventoryagent.log says successfully sent but the ccmessaging.log shows the upload failed.
Why can’t the client inventory agent act on the status back from ccmmessaginglog and if the upload of the inventory fails, don’t increment the delta number.
This would greatly reduce the number of deltamismatch files generated each day and improvement keeping the inventory up to date without having to force a full inventory sync for this case.

Here are the details:

Dataldr.log for computer: CHOSIJ1-L2

Thread: 6108 will use GUID GUID:c28fa179-d722-4692-be69-a71f5a81e75c SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
Processing Inventory for Machine: CHOSIJ1-L2 Version 2.7 Generated: 06/23/2020 14:04:44 SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
Begin transaction: Machine=CHOSIJ1-L2(GUID:c28fa179-d722-4692-be69-a71f5a81e75c) SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
WARNING - Attempting to resync due to missed delta reports (sp return code = 7) SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
Rollback transaction: Machine=CHOSIJ1-L2(GUID:c28fa179-d722-4692-be69-a71f5a81e75c) SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
SQL MESSAGE: dbo.spAddInventoryLog - Inventory Log for machine:CHOSIJ1-L2,Server:2.5,Client:2.7,Message:Missing Delta. Resync,Detail: SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)

Shows processing 2.7 but database is 2.5 – force a re-sync

Client tried to send delta 2.6 at 6/22/ 10:55am – but the network was not working client probably dropped vpn or connected vpn

Client Inventory Agent.log at 6/22 @ 7:41am starts processing delta 2.6
Inventory: Action=Hardware, ReportType=Delta, MajorVersion=2, MinorVersion=6
Reports successfully sent at 10:55am
Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint, ID: {1090DA21-86C6-44C8-9C38-260F7824060E}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted

CCMMessaging.log @ 10:55AM shows it failed:
[CCMHTTP] ERROR: URL=https://MSPM1BADP20.ent.core.medtronic.com/ccmsystem/request, Port=443, Options=448, Code=12007, Text=ERRORWINHTTPNAMENOT_RESOLVED

In summary if the InventoryAgent.log could detect that the Inventory was not successfully sent then don’t increment delta to 2.6 leave at 2.5

Thanks