The windows 10 adk has changed a few times since the original release of Windows 10, there have been two major releases and one hotfix to fix issues with the second release, as a consequence of that many people got jittery about upgrading to ADK 10 1511.

How are we going to deal with this in a good way, a really good way. Prior to this we didn't have to upgrade our boot images every 6 months or so.

Here's the suggestion:-

1. When we update from 1602 to 1607 (or whatever) to support the next generation of Windows, it would be great if (via) the configmgr updates and servicing node that during the installation of the next update pack, that it automagically uninstalls the current ADK, downloads the new Windows 10 ADK, installs the new ADK and continues with its' business until Configmgr XXXX is upgraded.

And wouldn't it be great if that behaviour was available via the wizard as a choice

Automatically update the Windows ADK [Yes/No]

2. Secondly, we may need to revert to a previous version of the ADK due to unseen issues therefore another option that we'd want would be to allow the ability to rollback the Windows ADK to the previously installed version via a choice:

Rollback ADK [Yes/No]

3. Thirdly, let's imagine the 1511 ADK scenario, where an ADK is released, has issues, and everyone finds out, and they rollback to the previous version. How about the Updates and Servicing node also allows resolution of this via an ADK hotfix ?

Install applicable ADK Hotfix [Yes/No]

cheers !
niall

With CM 1511, SMS Backup task enabled by default. And that does a volume shadow copy of the DB which means full-sized files. For my tiny lab that means I'm backing up 8 GB alone.

For production it'll mean 850GB per primary site. Under CM12 when we backup just SQL using compression, it's just 160GB per primary site.

Please allow an option to just invoke a database backup instead so that compression can be used and I don't need to go order terabytes of data just for backups.

Also the current backup just erases the last backup. But in a hierarchy situation, I want 5 days of data to be backed up.

1.) When running the SCCM Setup Wizard and choosing “Modify SQL Server configuration” there does not appear to be an adequate preflight check to ensure Config Manager is running with full administrative rights to A) operating systems, B) SQL instances and C) Config Manager itself. These permissions are (obviously) critical to a SQL configuration change. In enterprise environments, setup.exe should be reaching out to check rights to all the things it needs to modify (file system, registry, certificates, etc.) before it executes the changes. Partial modification of the configuration has catastrophic results.

2.) Execution of the SQL configuration change does not perform quite enough validation during modification to determine that each small change was successful, with errors listed in the setup.log. It is possible for setup.exe to complete with success according to the GUI, but ultimately fail to create certificates, registry changes, and propagate SQL broker updates.

3.) Documentation around how to effectively prepare and run the “Modify SQL Server configuration” could use improvements in the areas of A) minimum rights required to the OS CAS, PRI, SQL systems and CM, B) stopping site components C) detaching a database D) copying database files E) attaching and configuring the new database, F) running setup wizard with more detail around what setup.exe performs, and how long it takes... and last G) how to validate the changes were successful with SPDiagDRS and Replication Link Analyzer.

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/ccm_system/request, Port=443, Options=448, Code=12007, Text=ERRORWINHTTPNAMENOTRESOLVED

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

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.