Per: https://docs.microsoft.com/en-us/sccm/sum/deploy-use/manage-express-installation-files-for-windows-10-updates

"Using express installation files provides for smaller downloads and faster installation times on clients."

Through a case I opened with Microsoft, it was communicated to me that the current express update design is solely meant to reduce network bandwidth. There is no promise of expedited installation time. This is misleading and limits the purpose of express updates for remote office scenarios.

Additionally the express update deltas have to be decompressed and recombined in order to complete the installation which requires significant CPU usage.

The combination of these issues causes express updates to provide little benefit to customers in it's current state. I propose that express updates be reworked for faster client installation.

Today, you configure maintenance tasks under the administration workspace in the console. To see the results and details around those tasks, you have to go into the component status and parse through the SMS_DATABASE_NOTIFICATION_MONITOR to see when tasks started, stopped, how many records were cleaned, or whether the task failed, or, you can run a query directly against the database that shows when the tasks last started/stopped....but even then the task names in the DB don't necessarily match the names in the console. I propose that there is an area in Monitoring workspace that shows the status for each task, for each site:
enabled/disabled
scheduled start window
last start/end
last result
result details (ie removed 1234 obsolete records).

I would like to see Trusted Source locations to be added to ConfigMgr as a Node in Administration, and permission so that only Full Administrator or a specific RBA Role can manage these locations.

All ConfigMgr wizards that allow path data-entry will be changed to become a drop down list of approved Trusted Source locations. The User will be able to navigate into the folder structure of the Trusted Source location, creating new directories with a restriction on placing content on the root of the Trusted Source location, since this can induce data-loss if the sub-folder is not specified in rare conditions.

No new Source locations will be allowed to be entered, unless created by a Full Administrator or an Administrator with the appropriate Security Role.

This will remove A) free-styling of UNC paths B) Fat-fingering during data entry of paths C) Data loss due to placing content on the root of a location and aborting then cleaning up by deleting everything in the specified folder (root folder). Other MVP's have witnessed this condition occur, Trusted Source locations and a restriction on placing content in the root of a location will resolve this issue without any code-changes required in other areas of the product (to solve the deletions of other content by mistake) and finally D) invalid or inappropriate Content Source locations being configured on-the-fly (really fat fingering) by support teams with enough rights to do so.

Brian Mason added: I have this share out there already: \\Apps\apps$ and under that share is say Workstations and Servers and DCs. When I create the DC scope, I get to add the UNC Source I've named as DC. The DC team never has to enter the name of the share, but instead they browse to that share, see their root folder and pick a sub-folder. No UI ever lets them pick the root either. Anytime they make a package\app\etc., they browse to where I've limited them to and must pick a folder there.

Please add in suggestions to compliment this proposed solution, and vote it up to complete the Trusted Source Story. Being in complete control of our source locations should be on every administrators "I want that feature right now" list

Right now, the automatic Client upgrade scheduled Task is not aware of any running installations. So if appenforce.log shows a running Installation and at the same time the randomly timed scheduled tasks kicks in, the Installation cannot finish without error and will randomly leave the Installation or the SCCM Client itself in a unhealthy state. A reinstallation is the only way out.

Repro steps
- Activate automatic Client Upgrade in Hierarchy settings
- Exclude some test clients from automatic client upgrade
- Create an Application with a deploymenttype using a custom script
- As the script, use a batch file pinging localhost with parameter -t so that the dummy installation will newer end. That gives you time for the test.
- Deploy the app to the excluded test clients
- Let the installation run
- Set the clients to not be excluded from automatic client upgrade, so that the scheduled task for the upgrade will be created locally
- run the scheduled task manually to simulate the client upgrade
- you will see some errors in appenforce.log telling you that the installation could not be finished without error

Expected behaviour:
- The automatic client upgrade function should not run if an installation is allready running
- instead of scheduling a scheduled task you should schedule a package install, so that the sccm client can only start the package/upgrade if no other installation is running

When a package is deleted from the console, the packages/apps are removed from the database. If for any reason a pull DP or DP is not available, or WMI has issues on those remotes site systems, the files on the remote SCCM content Lib are not removed. This creates orphaned files on the Content Lib and causes storage issues on the servers.
We are working with a customer that as a large number of PullDP's so we would like to suggest on the behalf of our customer, to have a retry mechanism in the console to delete the content from the PullDP/DP when they are available and/or the WMI issues are fixed.
This could help to minimize orphaned files and prevent storage issues in the customers DPs/PullDPs.