The Current Branch 2002 release introduced a feature to install SSUs first but only when triggered by the deadline.
From the docs:
"SSUs are installed first only for non-user initiated installs. For instance, if a user initiates an installation for multiple updates from Software Center, the SSU might not be installed first."

A lot of work has been put into encouraging user-participation in the patching process. I want the user to decide when they're ready to install the updates and avoid situations where the deadlines impact their work. In those scenarios the behavior introduced in 2002 therefore not helpful.

I realize that if a user manually triggers the installs one-by-one that there's not much you can do about it. However, in pretty much every other scenario I would like to see the SSU install first.

For example:
User schedules the install from the update notification dialog.
User clicks 'Install All'.
User select multiple updates, including an SSU.

When you only use ConfigMgr to install updates, the date on the Windows Update control panel applet often reflects something that is really inaccurate as ConfigMgr doesn't update it. This often leads to a very negative reaction of "I thought those darn ConfigMgr admins were updating our workstations and servers!?!" And then we have to explain that we are, but that date doesn't get changed.

Can we please just ensure that when Software Update Management installs any updates, the Windows Update control panel applet gets set to the current date?

I stole the screenshots from this thread: https://social.technet.microsoft.com/Forums/en-US/b33dd5b2-64b3-476d-8fc5-232cbafced47/sccm-updates-are-installed-but-windows-update-status-wrong?forum=ConfigMgrCompliance

And I stole the idea of submitting the feedback from this thread:

https://social.technet.microsoft.com/Forums/en-US/812eef00-bdef-4c8d-a8ea-1d4424f1941e/software-updates-does-not-change-last-update-install-date-in-windows-update?forum=ConfigMgrCompliance

Thank you for your help!

Improve the ADR engine

• Automate the cleanup of the previous software update groups created by the rules, i.e. before creating a new SUG it will check for older SUG members and based on criteria automatically manage updates that are member of a specific SUG. If updates are published or revised in 2016 then move the updates to our 2016 SUG, or previous month etc. Or, if they are superseeded or expired then remove the updates from the SUG...




• Allow to name the deployment create by the ADR, this will be useful for reporting purpose if you have more than one deployment for a rule.




• Allow to deploy updates manually, well as available rather than required. Well for this you can workaround with dealine... but it's not cleanest way.




• Add some criterias to avoid to redeploy some updates that are members of a previous SUG created by the rule and being sure that all the updates that are published or revised will be in the SUG.




• If your rules add the updates to an existing SUG, allow to delete all previous deployment created by the rules.

With Windows 10, the system's drivers are updated directly from Windows Update. This is usually a good thing because it means the system will have the latest WHQL drivers installed. It also means the system administrator needs to maintain less driver packs for individual models (at least for corporate / enterprise computer models).

However, it sometimes happen that an updated driver will have a MSI co-installer that will run outside the scope of the SCCM client and might run concurrently with an application or package installation step from a task sequence. It will cause the installation to fail and maybe the whole task sequence to fail too. I've had this many times with Office 2016.

So the task sequence engine need a way to control when Windows will apply those driver updates so they don't happen concurrently during other OSD steps. Either the task sequence wait until the drivers are fully updated from Windows Update or the updates are postponed until the task sequence is over.