In-Place Upgrade Completes in MDT, but stuck on "Working on Updates 100%" RRS feed

  • Question

  • Hi

    I'm running into an issue where in-place upgrades (Win 7 > Win 10 1607) initiated from \\[server]\mdtproduction$\scripts\LiteTouch.vbs, then choosing the Upgrade task sequence, results in a machine that's essentially bricked.

    MDT monitoring shows the machine at Completed, 100%, but the machine is stuck on "Working on updates - 100%". Then, after waiting several hours, if the machine is given a hard shutdown and started back up, it won't load windows. It will show the blue "Windows" logo and the spinning circle of dots, then just the dots, then it goes blank and tries to reboot again. It's set to Legacy boot from the HDD. Since I can't get it to boot, I can't see any of the local logs.

    Can anyone tell me which logs I should be looking for? Should I be looking at WSUS? Any help is appreciated!

    Wednesday, April 19, 2017 3:30 PM

All replies

  • First I would check out WSUS.  Run the SQL query to find out if your WSUS server is affected.

    Then, make sure you're using the 1511.2 or 1607.1 updated ISOs from the VLS site.  They should have fixes for the cumulative update issues that occurred early on.

    There's no place like

    • Proposed as answer by Matt5150 Monday, April 24, 2017 11:34 PM
    Friday, April 21, 2017 4:14 AM
  • I've had exactly the same issue as Garrett B!

    Has anyone managed to fix the fault? I've tried this with new media downloaded from Microsoft and a fresh MDT install with a upgrade task with nothing but the default settings, and no modifications to the customsettings.ini file.

    Monday, May 22, 2017 11:01 AM
  • I learned something about the upgrade with some machines. I thought some were bricking and getting stuck at a screen where SetupComplete.cmd ran. I finally gave a machine lots of time and it would finish on its own. Ever since then all my upgrades have been successful no matter if I run it on 7, 8 or and older 10. You just have to be really patient with some of them.

    By the way it's also possible to roll back to the previous OS. Power the machine off during bootup a time or two to get the recovery mode to run. In the advanced recovery you can get to the option to roll back.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, May 23, 2017 8:32 PM
  • Having this same problem now, but only after fixing all the other 1703 / GPO / WSUS related issues I was having.

    Anyone have a cause / solution?


    There's no place like

    Tuesday, August 8, 2017 4:10 PM
  • We still haven't found a solution for this, having prioritised other projects and left Windows 10 to one side for the last few months we're about to start looking at it again.. in the meantime, has anyone found a fix, or way around this ? Any help would be appreciated. Unfortunately Dan_Vega's advice above did not help.
    Tuesday, September 19, 2017 9:12 AM
  • I don't have a solution, but I have a workaround.  Even after I got all the Defer settings cleared out and anything else that's documented to trigger Dual-Scan / WUfB, my machines are still taking hours to complete a TS with the Windows Update task enabled.  Without they will finish quickly, but then Windows Update won't function with WSUS for the same period of time it would have taken the TS to complete with it running there.  There is some kind of timeout that I can't locate.

    The workaround, is setting those sites it's hitting in your Windows Update log, in the HOSTS file pointed to your WSUS server.  See my "Wednesday, September 20, 2017 4:16 AM" post here:


    There's no place like

    • Edited by Matt5150 Friday, September 29, 2017 3:30 PM Edited "See my post"
    Wednesday, September 20, 2017 4:19 AM