Upgrade Operating System Task should be able to use Windows Servicing Content and Allow user interaction
• Current state of windows 10 servicing via upgrade sequence requires full media to take the client through setup.
o Full media is 2x the size of existing ESD (upgrade content)
o The Upgrade Operating System step does not allow the end user to defer the reboot nor does it warn the user of a reboot pending once setup has been kicked off
Change Request (Requirements)
I. The Upgrade Operating System step in the task sequence shall permit the administrator to reference windows 10 servicing content
II. The Upgrade Operating System step in the task sequence shall permit the administrator to define a notification to the end user
III. The Upgrade Operating System step in the task sequence shall permit the administrator to define if the user can defer the system reboot and for how long
Update to status, we released CM1902 HFRU this morning.
KB article https://support.microsoft.com/help/4500571
We got the new variable SMSTSRebootDelayNext included in that roll up. https://docs.microsoft.com/en-us/sccm/core/get-started/2019/technical-preview-1904#bkmk_osd
To Aaron Smith: This variable is shown in AdminConsole in the "Set Dynamic Variable" > Add Variable > Existing Variable in 1906 release. For the time being after applying the hotfix CM1902 HFRU define it as a custom variable.
Bob, the Variable SMSTSRebootDelayNext is not shown in the "Set Dynamic Variable" > Add Variable > Existing Variable.
I have upgraded to 1902 and installed the KB4500571 Update, should i add it as a custom variable ?
Impressive! Thanks for the update Bob!
Love the sound of this, were in the process of trying to roll out Windows 10 1809 upgrade to our estate using a TS, for the moment, iv had to set the TS reboot delay to 20 mins, which as we already discussed, adds 40 mins to a plain upgrade under the current version of SCCM.
any chances that this new variable could be released as a hotfix for SCCM 1902 (pretty please ;)
Thanks, I should've mentioned SMSTSRebootDelay affects the subsequent restarts like Aaron mentioned.
Last week we we're talking about the same and how to solve. There'll be a new variable to set the timeout for subsequent restarts - this should be in the next Technical Preview. We'll update again once that's available.
The flaw with SMSTSRebootDelay that Aaron mentioned is documented here: tinyurl.com/yxzrcmp9
There's also clever a workaround, but it's an awkward and unsupported hack-job. We shouldn't need to do that to fix this.
I agree with Bob Mac Neill's comment about the SMSTSRebootDelay variable, but the problem with this is that the overwrite value set here is global for the whole task sequence, so the user gets a nice prompt while in windows saying the machine will be rebooted in x mins, but after the machine reboots, there is a second prompt which appears at the end of the offline part of the OS Upgrade, this also takes the SMSTSRebootDelay setting.
This means if i set it to something nice like 3600 seconds, and the user isnt around to press Restart, it will sit there counting down for 60 mins for no reason...
This idea seems a really simple thing to implement, especially now most of the OS upgrade is done online and invisible to the user, just adding a "defer reboot" would make Task Sequence upgrading an OS much more viable !
Adam Leinss commented
Essentially, the way the IPU works now is most of the work is done in the "online" OS (running) vs "offline" OS (WinPE). When users use to pick operating system upgrade in Software Center, it would go offline within 15 minutes and Windows 10 would upgrade within roughly a hour. Now they they moved the bulk of migration process to the online phase which is great, except when it wants a reboot it gives the end user 30 seconds to save their work and reboot. This reboot is started by setup.exe itself and not the Restart Computer option withing the TS, so configuring any options for this step has no effect on suppressing the reboot.
With the new SAC this could be great!
User information and ability for user to have some kind of control for such big upgrades is also key for our company - Thx.
Daniel Harper commented
This should be voted on by every deployment admin soon. All great ideas and great solutions to feature update problems. Trying to schedule around thousands of users is a tremendous pain. Network strain is a bother as well. Great request James!