locked
SCCM Upgrade task sequence - Reboot control RRS feed

  • Question

  • Hi,

    Currently i am testing the Windows 10 upgrade task sequence to upgrade 1607 machines to 1703 using the inbuilt upgrade task sequence.  The problem is with the reboot, the reboot is happening automatically with out any notification to user during the upgrade. we are trying to show the reboot notification to user with some time period(1800 seconds) i have configured the same for default restart step but the settings are not taking any affect and machine is getting rebooted automatically.  Could you please suggest if there is any possibility to include reboot notification in task sequence to allow users to save their work before computer reboots ?


    Satya

    Friday, September 22, 2017 7:16 AM

All replies

  • Hi,

    Are you showing the Task Sequence progess to the user? then the reboot step itself should show a reboot notification...

    Regards,

    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    Friday, September 22, 2017 10:16 AM
  • Hi Nilson,

    Yes, we are showing the task sequence progress to user, i want to show more reboot countdown to users incited of the default(60 seconds). i have tried increasing the value to more but the changes are not taking affect.

    Could you please help on this ?


    Satya

    Friday, September 22, 2017 11:17 AM
  • Before the upgrade step, set the SMSTSRebootDelay TS variable to the number of seconds that you want for the reboot delay.

    • Proposed as answer by Frank Dong Saturday, September 30, 2017 11:10 AM
    Friday, September 22, 2017 10:56 PM
  • Hi Kerwin,

    Your suggestion works nice and the first reboot is delayed for what you set in the variable. But, after reboot the upgrade starts fine and then reboots a 2nd time and then finishes the rest of the task sequence steps (installing Language Packs,...).

    If I set the variable to 1 hour, the 2nd reboot also delays 1 hour time before rebooting, but there it shouldn't because user isn't able to work and that would take 1 hour extra of their time.

    I already tried changing the variable after the upgrade OS step, but that doesn't help, because the 2nd reboot is in the middle of the Upgrade OS step.

    Any ideas how I can change that behavior?

    Friday, December 29, 2017 8:36 AM
  • I have the same issue as Jody, can the user control a reboot manually? like software updates restart behaviour.

    I want to provide a user this control and resume task sequence once computer is rebooted.

    These upgrades have a high user experience impact..

    Friday, December 29, 2017 12:34 PM
  • I am also having this issue. 

    Using Configuration Manager's Windows 10 Servicing is much better for the end user. Unfortunately this method does not allow additional tasks to be run since it's just an update.

    We perform a couple tweaks to the default profile and any existing user profiles after OSD or OS Upgrade. Because of this, we need to use a Task Sequence. The problem is the reboot. I'd like to be able to have the task sequence start in the background, just like Windows 10 Servicing, and then prompt the user to reboot when it's time. However hiding the task sequence progress results in a random reboot. Setting the SMSTSRebootDelay Task Sequence Variable affects any reboots within the task sequence. If a user reboots before they leave for lunch, they would return to another reboot prompt and still have to wait for the upgrade to complete... 

    I was hoping this behavior would be altered in Configuration Manager 1802 with the new In-Place Upgrade Task Sequence template but no such luck, https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1802#improvements-to-windows-10-in-place-upgrade-task-sequence. 

    This issue is forcing us to wait before servicing our 1607 clients. It would be nice if there was a way to run a script after a Feature Update was applied - that would potentially resolve this issue and we wouldn't need to rely on a task sequence to service our Windows 10 clients. 



    • Edited by C0rmang Wednesday, March 21, 2018 1:05 PM
    Wednesday, March 21, 2018 1:03 PM
  • I am also having this Problem.

    We have the same Szenario we've tested 3 ways to fix that:

    - SMTSWaitforSecondReboot = 3600
    - Prompt the User Before Upgrade starts
    - Start Upgrade per Script and prompt user after "Setup.exe"

    The Problem was that the Tasksequence didn't start after a Reboot from ConfigMgr.
    Is their any other Solution possible?

    Thx and Regards,

    Daniel

    Wednesday, April 25, 2018 12:40 PM
  • Getting the exact same problem with SCCM 1802. We're trying to go from Win10 1703 to 1709 and have to use task sequences due to software we have that doesn't survive the inplace upgrade.

    I also set the restart step to 2 hours with a message giving users a warning to save work before it restarts. However it is the built in upgrade operating system step in the task sequence that reboots the computer, not the restart computer step that directly follows it.

    This means that during the first phase of the upgrade the user can use the computer but it will restart without warning, the second phase of the upgrade then happens, where the computer is unusable. After this second phase when the task sequence starts back up, it then processes the restart step, and the user is then given the 2 hour warning, which is no good at this point.

    If you look at the smsts logs for the command and switches that the upgrade operating task step passes to the Windows 10 setup.exe it includes the /noreboot switch. When running setup manually using that switch setup doesn't automatically restart the computer. There is something with the upgrade operating step that ignores the /noreboot switch and reboots without warning.

    As further testing, I have removed the upgrade operating system step from the task sequence, and added a run command line step with the exact same switches that i got from the log file. This works in part, the task sequence now doesn't automatically reboot, it moves on to the restart computer step, so you are presented with the 2 hour warning. However after the Windows 10 upgrade completes its second phase, the task sequence doesn't start back up and continue on, so further customisations and app installs don't happen.

    My next phase of testing, which I'm about to look into, is to fall back to the vNext upgrade scripts that MS provided for upgrading using SCCM 2012.

    Thursday, April 26, 2018 9:03 AM
  • I can confirm when using the old scripts I can upgrade Windows 10 with a restart warning and then the task sequence continues on.
    Friday, April 27, 2018 9:50 AM
  • If anyone is interested, I have a blog discussing what I did to accomplish the same reboot notification scenario.

    https://configmrgdave.wordpress.com/

    Monday, April 30, 2018 2:47 PM
  • Although not the answer, there's a new Windows 10 Upgrade Tools kit on TechNet Galleries https://gallery.technet.microsoft.com/Windows-10-Upgrade-Tools-431094ca. More information is here, http://ccmexec.com/2018/05/windows-10-upgradeservicing-tools-demoed-at-mms-2018/. I have not tested it yet but plan to test it next week. I'll report back. 
    • Edited by C0rmang Friday, May 25, 2018 12:15 PM
    Friday, May 25, 2018 12:14 PM
  • Does anyone have any other answers for this?  It appears Dave's answer would work, but boy what a hack.  The issue here is the way Windows 10 IPU use to work is most of the work was done offline (click Upgrade and then go offline in a matter of 15 minutes or so).  Now they moved most of it to being "online" in the current OS which is great, except now the IPU takes 2 hours (vs 1 hour with most of the work done offline).  The user sits and uses their computer for 2 hours and then is given 30 seconds to reboot when it hits a goal post.  What?
    Monday, June 4, 2018 4:04 PM
  • Does anyone have any other answers for this?  It appears Dave's answer would work, but boy what a hack.  The issue here is the way Windows 10 IPU use to work is most of the work was done offline (click Upgrade and then go offline in a matter of 15 minutes or so).  Now they moved most of it to being "online" in the current OS which is great, except now the IPU takes 2 hours (vs 1 hour with most of the work done offline).  The user sits and uses their computer for 2 hours and then is given 30 seconds to reboot when it hits a goal post.  What?

    Nope, Dave's solution don't work. Being lazy at all, I just tried it on the fly and scratching my head, so I scrutinize the bits and pieces. Nice work David though but the issue the guys here are saying is around the 2nd restart as part of the upgrade process which is in between the first restart and the time it runs the setupcomplete.cmd. You dont need David's hack to achieve the delay, just setting up the smstsrebootdelay already does the trick. what you have to do now is just find that middle ground enough for the user to save their work and restart to finish the upgrade. The time the 2nd restarts the device is out of the TS realm and reconnects itself as the setupcomplete.cmd runs again. hope it helps. in our case we had it to a min of 10-15 mins. 

    This is the only answer for now. Sorry guys to keep the down time at a minimum, have the reboot delay just enough for the users to save their work which is between 10-15 minutes and restart. In this way, the next restart we cant customise is only at a minimum. When I get my blog up and running will share more to you guys. If I find a way to alter that 2nd reboot, I will let u all know. Happy days!

    Tuesday, July 24, 2018 7:47 PM
  • If anyone is interested, I have a blog discussing what I did to accomplish the same reboot notification scenario.


    nice work David but it doesn't work to address the 2nd restart :) nice
    Tuesday, July 24, 2018 7:48 PM
  • Check my response below. Add a step to modify SMSTSRebootDelay. This will affect the next TS that just forces an auto restart in this case your upgrade OS step. https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-built-in-variables for more details.

    The reboot resets itself back to whatever time you want. Dave's great work is an awesome hack but we didn't need to use it in our case. We are now on CB 1802.

    I know you wanted to delay it more, I suggest is make it as available TS for the users to let them do it at their convenient time and then you force them after ie 2-3 week period. Users will only have to do this 2x in a year if you are doing it biyearly, otherwise it is a yearly thing depending on your situation.

    Tuesday, July 24, 2018 11:24 PM
  • Bump! I'm using SCCM 1806 with Win10 1809 inplace upgrade - Has anyone been able to find a solution to the second reboot? Dave's scripts above do not work because the reboot occurs before the setupcomplete stage.

    I've tried Simon Whitfield's attempts with vNext scripts however the task sequence doesn't continue after the installation.

    Tuesday, June 4, 2019 11:05 PM
  • Another Bump!  This seems to happen fairly often where the TS just exits the TS after the upgrade step.

    Tuesday, August 13, 2019 4:44 PM
  • Hi guys,

    This seems to be resolved with a new Task Sequence variable SMSTSRebootDelayNext. This variable is available after the installation of Configuration Manager 1902 Hotfix Rollup (KB4500571):

    https://support.microsoft.com/en-us/help/4500571/update-rollup-for-configuration-manager-current-branch-1902

    For explanation of the new variable, see here:

    https://docs.microsoft.com/en-us/sccm/core/get-started/2019/technical-preview-1904#bkmk_osd

    I haven't tried it yet, will try it soon...

    Kind regards,

    Jody

    Wednesday, August 14, 2019 8:08 AM
  • I think that sort of fixes the OP - but later in the thread they are talking about the extra reboot after or during hte OS upgrade step.

    Does this fix that particular reboot?

    Wednesday, August 14, 2019 2:03 PM
  • I don't know, haven't tried it yet.

    Accordingly to the MS site, that new variable sets the delay for the second reboot after the OS Upgrade step.

    Wednesday, August 14, 2019 2:53 PM