Ability to automatically install Windows 10 ADK releases (or rollback or apply hotfix) via Updates and Servicing.
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]
Updated to Noted. We’ve been discussing the same in our planning meetings.
BobMN on behalf of SangeeV for SCCM OS Deployment
Tom Gibson commented
What about MDT updates as well??
Great idea Niall. To add to bdam's comments ... After a Win ADK update, the previous Boot Image drivers and other settings are no longer displayed (whole tabs of each Boot Image Property are missing). You only need to forget to make a manual note of these settings once, to never forget to do so again (unless your drivers and installation notes are well structured)! Nevertheless, it would be great if these existing settings were captured and re-applied by the upgrade process - even if they were saved to a config file and then re-applied, for each image.
As an addendum, the ability to update (regenerate) customized bootdisks (including MDT bootdisks) from the console. Currently you have to rebuild the bootdisks from scratch when the ADK changes. With the release of 1702 only bootdisks based on the 1607 ADK can be customized. However, it's not just that, you can't even see the customizations you had on your old bootdisks so you have no way to directly replicate them.
Great idea, the ADK process as it is right now is a real pain point!
Great one..hope feature gets added asap...
David - www.easycfg.com commented
Great idea, you've my vote as well!
José Vasconcelos commented
You have my votes!!
Make it so! One of those 'why has no-one ever suggested this before?' ideas.. Anything that adds automation and removes manual fiddling gets my vote.
Mike Marable commented
I think this is an excellent idea, Niall.
Nickolaj Andersen commented
This would be extremely useful and easy the pain for a lot of customers that have issues with dealing with ADK.
Mark Cochrane commented
The forecast of what the network will have to support would be more compelling for sure. In France, WANs are quite expensive and this is a fear for major accounts. If they have subs in Africa and/or in Aspac this becomes even more a concern.
Rings should be like "full environments", and should be able to deliver every service (including OSD, so probably multiple PEs).