The windows 10 adk has changed a few times since the original release of Windows 10, there have been two major releases and one hotfix to fix issues with the second release, as a consequence of that many people got jittery about upgrading to ADK 10 1511.

How are we going to deal with this in a good way, a really good way. Prior to this we didn't have to upgrade our boot images every 6 months or so.

Here's the suggestion:-

1. When we update from 1602 to 1607 (or whatever) to support the next generation of Windows, it would be great if (via) the configmgr updates and servicing node that during the installation of the next update pack, that it automagically uninstalls the current ADK, downloads the new Windows 10 ADK, installs the new ADK and continues with its' business until Configmgr XXXX is upgraded.

And wouldn't it be great if that behaviour was available via the wizard as a choice

Automatically update the Windows ADK [Yes/No]

2. Secondly, we may need to revert to a previous version of the ADK due to unseen issues therefore another option that we'd want would be to allow the ability to rollback the Windows ADK to the previously installed version via a choice:

Rollback ADK [Yes/No]

3. Thirdly, let's imagine the 1511 ADK scenario, where an ADK is released, has issues, and everyone finds out, and they rollback to the previous version. How about the Updates and Servicing node also allows resolution of this via an ADK hotfix ?

Install applicable ADK Hotfix [Yes/No]

cheers !
niall

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.