The idea of leveraging a Windows 10 Servicing plan is great. It's a relatively simple process that can keep companies on a defined Windows 10 lifecycle. However, due to the nature of the upgrades and processes in which things get reset or reinstalled customers are forced to leverage task sequences. With the announcement of Windows 10 1803 pre/post configuration scripts, there now appears to be somewhat of an avenue where these items can start to be managed. However, when you look at our customers failure percentages for any deployment, you have to ask yourself, would a customer really want a 10% deviation from their standard after every upgrade? To enable more customers to leverage Servicing, it would be great if we had the ability to manage the pre/post scripts built into servicing. However this only address half of the problem. Customers are also dealing with application uninstalls/installs to support new versions of Windows 10. If we had the ability to tag SCCM Applications for uninstall and install, during the servicing process, it would provide a great deal of control where customers could start leveraging Servicing.

Attached is a simple flow diagram of the process I am proposing.

Consider the following user story on 1802:

I decided to organize all my software updates that are synchronized in my hierarchy by creating folders such as YYYY-MM. After performing move operations on these updates that were released within this format I noticed that the folders are duplicated underneath the 'Windows 10 Servicing" node and Office 365 Updates node. When I browse for the updates in the folders I created under "All Software Updates" my updates visible as expected; however these folders are triplicated down the side of the console and are all empty in other nodes.

From the All Software Updates Pane, create a folder and name it something numeric like YYYY-MM. Next from the All Software Updates area; search for an amount of updates you choose to move to this folder that are released within this year/month format.

Next, when you expand the Windows 10 Serviing Node and Office 365 Client Management > Office 365 Updates > You will notice that the folders are triplicated; yet empty within the Office 365 Client Management and Windows 10 Servicing Area.

Please allow these nodes to have independent folder structures. My intent was to create new folders under these two other areas; that had their own names and own orgnization structure.

For example:

in Office I was going to create a folder called Semi-Annual Channel and another called Semi-Annual Channel (Targeted) and organize the updates... but I am impacted by having a whole list of other empty folders to contend with.

I've attached some pictures.

To make automatic deployment rules work site servers in enterprise environments needs proxy and firewall exceptions. So site servers should be able to download software updates. But in remote console sessions the console users also need proxy permissions because the downloads are done in context of the console users and for their workstations firewall exceptions need to be defined. This makes it unimpossible to run the console on a secured Workstation by an administrator account that can not access the internet. It would be usefull if we had the option to choose who downloads the patches. In example "use my account to download the patches", "Use proxy account to download" or "Let the site server download".

Patch Tuesday can be hard, especially like April 2018 when an update is expired after 2 days and new version is available. Unless you knew to pull the new update in or have the ADR set to run every day, there is no way to know about this update. I don't want just a auto push on Friday Moring of Patch Tuesday week with out some kind of notice first.
This would generate a notice that a patch X has been removed and patch Y has been added.

This would not good for Defender or some other updates but If you want to be aware of an update that has changed in the week after patch Tuesday run or 2 weeks after, etc. Given O365 Monthly updates are random, this would be nice to see when they come out.

It would be useful if the activities in SCCM could be prioritized.
If SCCM is busy installing patches, software updates can not be loaded until all patches are pending.
For urgent software updates, the user must wait until all other activities have been completed. Partly several hours.
Unfortunately, this is very impractical in practice.
Therefore, it would be useful if software updates generally have the highest priority and patches get a lower priority.
If an urgent software update is now pending, the patch installation would have to be interrupted IMMEDIATELY,
then the software update (s) will be uploaded, and if there are no updates available, you can continue with patching.