Hey SK,
Yes, we handle this basically 2 ways with a 3rd optional method.
- The first option is automated and is usually the most effective. We have an SMP policy that looks at a filter for systems running older builds of Windows 10. Examples include builds 1511, 1607, etc. and we leverage the built in Patch management update logic provided in the .bat file of the Windows 10 upgrade package to upgrade system naturally via the SMP. This usually works pretty smoothly but can encounter some hiccups along the way.
Some things the SMP native logic does not account for is Software compatibilty such as Symantec Endpoint Protection version which has to be newer for the latest builds of Windows 10, it does not look to make sure the system is running on AC Power before starting the upgrade process, the ammount of free space available on the target system is not considered, and it does not account for driver compatibility for legacy hardware.
These things may not affect you, but we have some really old stuff in our environment and unattended upgrades without vetting can cause major disruptions so we invalidate systems that don't meet the explicit criteria for an upgrade.
- Our compliance issues are usually systems that are mobile and get stored in mobile carts so they are never on and running during the maintanence window. To address these, the second option in our environment is for a site based admin to manually target systems with the aformentioned logic and perform the upgrades manually outside of the maintanence window. This can be very effective as well since the site based admin is staging devices and receiving that instant gratification feedback with a product like Ghost Solution Suite (which we also leverage at our sites) and would highlight issues that can be adjusted/corrected right away.
The third option is one that we could use in our environment, but we currently don't leverage because of the varied skill sets of the end users in our environment. In some situations where there might not be a dedicated site based admin to administer the upgrade manually, and where the systems are just never on during the maintanence window - we could present the upgrade for a non-administrative users to request the upgrade via the software portal. This would allow users to self serve, and we could invalidate systems using the logic I mentioned earlier. The hard part here would be providing the end user with some meaningful feedback in the event that the validation criteria was not met and the system could not upgrade. That language barrier might be so great that no matter how friendly and jargon-free it is worded...it still might not make sense to them which could just lead to more tickets and could just get messy real quick, so we have stayed away from this option for now...but it is possible and may be just as viable as the first two options if no validation issues are encountered and it performs the upgrade as intended.
From a logistical standpoint, for the second/third options, we copy the ISO to a central location, and if the system passes the validation check, the ISO is copied locally to the system and mounted for execution. Alternatively you could extract the contents of the ISO but the transfer would take quite a bit longer for all the little files, and prolong the upgrade process significantly.
After passing the validation sequence, To perform the unattended upgrade we use the following command line:
setup.exe" /Auto:Upgrade /showoobe none /quiet /uninstall enable /DynamicUpdate Disable /Telemetry Disable /Copylogs %SystemDrive%\ProgramData\temp
If this solves your issue, kindly mark this as a solution. Thanks :)