Integrate the SCUP tool on to SCCM Admin Console. This will give a single pane of glass view for all patching activities (including importing 3rd party patches).

Currently, when servicing stack updates and regular updates are deployed in the same software update group, the patches do not apply in a determinant order. This leads to cases where a cumulative update that requires a new servicing stack is installed before the servicing stack itself.

While this can be worked around by separately deploying the servicing stack update before updates that require said servicing stack, it would be much more convenient if the update installation process checked if there are any servicing stack updates to be deployed and automatically installed them first

In Windows client, after receiving software updates from the SUP, I want you to be able to use the" install and reboot / shutdown and update" botton.

Integration of the express installation files from WSUS
I think this is becoming mandatory with the size of updates of Windows 10.

Cluster patching feature was added in #SCCM CB 1602, but has been in prelease for a long time. It needs to:
1) Have improved/revamped UI
2) Remove dependency on collections
3) Orchestrate patching for any machines, not just servers/clusters
4) Remove the feature from prerelease

There should be a few built in maintenance tasks to go through and complete all the maintenance tasks that are needed for WSUS. I find having to run through these steps every month to be quite tedious requiring a lot of change control each month to get the maintenance work completed for WSUS.

Everything described in this article should be automatically done by CM: https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/

Now that we have the option to define both Distribution Points and Management Points as preferred, it'd be terrific if we could have the same option for Software Update Points. It would make a strong case when designing a flat hierarchy.

It would be really great if when configuring an Automated Deployment Rule you could configure it to run based on the number of days / weeks since "patch Tuesday" (especially in countries other than the USA where "patch Tuesday" is actually a Wednesday and not necessarily the second Wednesday of each month). I currently get around this by having a script detect when patch Tuesday has passed and subsequently execute an ADR and create one or more deployments based on the number of weeks since that date. This works fine, but an in product solution would be better

With the new 'cumulative updates' model I think it would be a good idea to change the maximum run time of cumulative updates to 30 minutes (or whatever is best suited). I have noticed more timeout issues with patching in the last couple of months due to the default 10 minutes not being enough time to install 'X' patches as a single CU. This would be preferred to manually overriding them every month.

Enable easier integration with partner products or have the ability to pull down 3rd party catalogs.

With more and more people working from home these days, having the ability to specify in a Software Update Group deployment to force download from MS update site would be terrific. I'd still like those clients to download content for applications from the internal DP over VPN, but downloading monthly updates would be much quicker if you could force them to use internet instead of VPN.

I propose a new search criteria for ADR, to avoid multiple deployments for a single update. This is a pain to clean up afterwards.

When I go to the Windows 10 Servicing Dashboard, I got a nice PieChart of the Windows 10 Clients and their Version.
But when I click on the PieChart, nothing happens. It would be great to have the same experience on this Dashboard like on the SCEP Dashboards.
That means, if I click on the PieChart one of the Windows 10 Version, a new collection would be opened, with the corresponding Devices.

You know that "x" number of machines require this update. Would you please list the machines names below. Screenshot for what I would like.

In SCCM 1610 users are not displaying notification message in clients to close any Office 365 opened apps before Office updates installation started in "Software Center" and even we set forceappshutdown=False switch in Configuration.xml file for Office 365

We can not have production applications close automatically.

Revert back to having required Office 365 updates install at reboot by default and make the force closing of applications with optional display/postpone options a separate configurable option which can be selected per deployment (not client policy).

If a SUP/WSUS server is offline or in a disaster situation, clients should be allowed to failover to another SUP.

Currently if a SUP goes offline, clients simply will never scan again, and this is not an ideal situation.