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).

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.

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.

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).

Everyone who knows WSUS misses the feature in ConfigMgr to allow the installation of software updates when the machine is shut down. This is being requested for a very long time now. For most businesses it's not the best approach to install updates only when a user is logged on. Of course the scenario changes with Windows 8 and 10, but it's still a valuable addition to the option a ConfigMgr admin should have.

Please do not force applications closed when applying office 365 updates. We have had to suspend the deployment of office 365 updates due to user impact until we can work this out. This same topic was marked as complete in the feedback section but it is still happening with SCCM 1710 and KBKB4057517 Installed.
reference:
https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/32048548-office-365-required-updates-in-1706-should-not-for

Also I have not seen any user presented countdowns when the deadline approaches. Thanks.

Cumulative Updates for Windows Server 2016 sync with a maximum run time of 10 minutes every month. The same cumulative update for Windows 10 1607 is set to 60 minutes.

Could you set the Server 2016 to 60 minutes instead of 10? This update never completes in less that 30 or 45 minutes.

Currently Office 365 can't be patched with WSUS, instead you have to have your clients either contacting the Internet (not very good option for large enterprise), or you will have to distribute the new updated version on shared folders and define the new update source. it would be interesting to be able to use WSUS also for C2R apps.

When Installing Feature Update 1607 or 1703 via WSUS and Software Update Group the clients System Center reports error 0x80070422.
The error is reported, even the client installed the feature update fully successful. This is caused, by a delay or not running Services after the first boot of the Client after the Feature update. A solution could be, that the ccmexec process waits longer for the Windows update Service to Startup or Trigger the start of the Windows update Service itself.

Windows 10 1703 CB versions are showing as "other" on the Windows 10 Servicing Dashboard. Also not even represented in the Windows 10 timeline yet.

When a user installs updates from Software Center only the updates that were selected to be installed are evaluated for their state post reboot. The whole deployment those updates were in, even if all updates in the deployment were selected, will not be queried for compliance post reboot. This causes a delay in the deployment compliance reporting as you need to wait for the deployment to be evaluated on schedule. In some instances this could be days. Running evaluation on the deployments those selected updates were in post reboot would solve the reporting delay.

It would be nice to use Co-Management not for all Win10 1709 devices but only for a dedicated set represented in ConfigMgr as a collection. It would be easier for big customers to start testing.

Boundary awareness for SUPs / WSUS

Example:
- Clients do not switch automatically to Secondary Site WSUS, if the Secondary Site was installed later as the Primary Site
- Travellers / VPN connection within the company network
- No automatic failback if Secondary Site server was done
etc.

see also MS Support Case 115121413489660