As an alternative to presenting a warning for HTTPS and potentially causing confusion, Enhanced HTTP should be enabled by default and there would be no need for warnings or prompts. EHTTP no longer requires Azure on-boarding so there is no reason not to enable it by default going forward. If the user wanted to use HTTPS they could still do so in the console after initial setup or upgrade is complete. The new warnings for HTTPS do not belong in the initial setup wizard because this is not a setting to be taken lightly, but being presented these choices up front is misleading users into thinking they need to make the choice right away. Supporting a PKI environment is a major undertaking that many customers are not fully understanding, but they are getting the impression that the other options are not secure, I feel this is leading them to choose HTTPS which then is generating a higher number of support cases.

The VM that is automatically provisioned as part of the Cloud Management Gateway setup from the ConfigMgr console, when security scanned, indicates HSTS is not turned on/ enforced.

This has been discussed with Microsoft Support and Configuration Manager experts from Microsoft, as this is obviously a concern. All attempts to mitigate this issue failed as any settings made as advised by Microsoft were reverted or failed to mitigate the issue.

We have assurances the service is secure however, we are aware that HSTS being off is recognised as a vulnerability to Microsoft and you recommend all to enforce this on all affected Microsoft Servers/services.

Could you please address this issue, as indicated above, by your own documentation and advice, this setting should be enforced.

Maintenance mode for Distribution Points is an awesome feature. Thank you for implementing it!
It significantly reduces amount of "false positive" errors and makes monitoring significantly easier.
Please also include DP upgrades in list of tasks that are suspended when DP is in Maintenance mode.
Currently (v 2006), as also noted in documentation, Distribution Manager continues trying to upgrade DPs that are in Maintenance mode, which generates error messages that make monitoring more difficult.
Our remote sites occasionally go offline for extended periods of time, so this would reduce number of errors support engineers need to review.
Due to pandemic we have many sites where staff is working from home and servers are off.
If stopping DP upgrades is not an option, then at least stop generating errors for DPs that are in MM and are offline.
Removing and then re-adding DP role is not a good option.
Thank you.

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