none
Upgrade Task Sequence STILL not working on Windows ADK 10 v1709 and MDT 8450 - fails big time on real hardware? RRS feed

  • Question

  • After struggling like many others with an in-place upgrade (Windows 10 1607->Windows 10 1709) - I was very excited to see the new MDT update (8450) appear a week ago. I upgraded my MDT build share and got down to testing out my in place upgrade scenario with several VMs that I had sitting at 1607.

    Was very relieved to see that if I ran my standard upgrade task sequence against a VM - it worked 100% spot on. The TS ran perfectly and ended right on the dot with the standard "success" dialog. And as soon as I pressed Finish on that dialog box - the VM would reboot and I would be placed right at the Win 10 login screen. Login and find the upgrade was perfectly installed.

    So since the test runs looked so good - I decided to apply this upgrade to three real world workstations here at the office - all three running Windows 10 1607 with all the latest Dec 2017 updates. 

    All three were a disaster and all three behaved identically - even tho all three machines were of different hardware and different vintage. The issues were all the same - the TS would start properly. It would seem to apply the upgrade fine. The upgrade itself would do it's requisite three reboots - each happening at a different stage of the upgrade process (35%, 75% and then the last run leading to 100%. As soon as all three installs hit the 100% range - all three would hang with this message "Working on Updates 100%. Don't turn off your PC. This will take a while."

    In the case of PC #1 - I watched the hard drive light flicker away (while at 100% for at least 12-15 minutes). I finally got the "success" dialog from the TS but did not get a mouse pointer - so I could not click the Finish button. While that dialog was on screen for another minute or so - I could see the "Working on updates" message still grinding away on screen in the background. I finally hit Enter on the keyboard and dismissed the dialog. The "working on updates" message sat there for at least another 5 minutes until I finally got fed up and did a hard restart. The PC booted normally to the login screen - I logged in and checked it out - all updated correctly to 1709 (latest 16299.125) Everything else was in order.

    For PC#2 - which is much newer - only 10 months old - I thought I might have better luck. Made sure that I logged in the MDTBuild share using my MDT_BA account and fired up the litetouch.vbs file. TS popped up normally and did it's thing for about 10 mins. For this run - I paused the anti-virus and made sure the only thing running was the TS. But again - "working on updates" was at 100% for what seemed like 10 mins. I finally got the "success" dialog from the TS but again - no mouse pointer - so I could not click the Finish button. This time I was annoyed and waited 2 more minutes of 100% and then did a hard restart. This time the PC booted back into the end of the TS and I saw a small DOS dialog in the upper left trying to run the setupcomplete.cmd file. After a minute or two - that finally did something and the PC restarted again - booted normally to the login screen - I logged in and checked it out - all updated correctly to 1709 (latest 16299.125) Everything else was in order.

    Finally PC #3 was my own workstation - took 12-15 minutes until I finally got the "success" dialog from the TS. No mouse pointer - so I immediately hit Enter on the keyboard. This time the PC shutdown instantly and my Dell Monitor started it's 5 min sleep countdown of all things. I immediately hit the power button and the PC booted back up and went normally to the login screen - I logged in and checked it out - all updated correctly to 1709 (latest 16299.125) Everything else was in order.

    The MDT logs from all three PC's had all sorts of oddball crap in them - like this from SMSTS.log for my workstation:

    Error group 1

    Failed to delete directory 'C:\_SMSTaskSequence' TSManager 12/27/2017 12:15:21 PM 5780 (0x1694)
    SetNamedSecurityInfo() failed. TSManager 12/27/2017 12:15:21 PM 5780 (0x1694)
    SetObjectOwner() failed. 0x80070005. TSManager 12/27/2017 12:15:21 PM 5780 (0x1694)
    RemoveFile() failed for C:\_SMSTaskSequence\TSEnv.dat. 0x80070005. TSManager 12/27/2017 12:15:21 PM 5780 (0x1694)
    RemoveDirectoryW failed (0x80070091) for C:\_SMSTaskSequence TSManager 12/27/2017 12:15:21 PM 5780 (0x1694)

    Error group 2

    RegQueryValueExW is unsuccessful for Software\Microsoft\SMS\Task Sequence, SMSTSEndProgram TSManager 12/27/2017 12:15:21 PM 5780 (0x1694)
    GetTsRegValue() is unsuccessful. 0x80070002. TSManager 12/27/2017 12:15:21 PM 5780 (0x1694)

    Error group 3

    Start executing an instruction. Instruction name: Capture Setup Failures. Instruction pointer: 8 TSManager 12/27/2017 12:12:12 PM 5780 (0x1694)
    Set a global environment variable _SMSTSCurrentActionName=Capture Setup Failures TSManager 12/27/2017 12:12:12 PM 5780 (0x1694)

    Overall - a huge disappointment. And as usual - the logs speak in such bizarre technical terms - that their usefullness is pointless. None of these errors tell the user what is wrong or where to even start looking.

    My environment is pretty stock over here. My upgrade TS is about a simple as it gets. There is node to upgrade to OS and another to check our WSUS for the latest updates.

    My install source is genuine Microsoft from MSDN (Windows 10 Multi-Edition VL Updated Dec 2017). I am installing Enterprise to Enterprise. My source .wim was modified using NTLite - but only to remove a handful of UWI apps that I do not wish to deploy and to run a .reg file that does a few basics to the Desktop, Explorer etc.

    This TS worked flawlessly against a VM yet it cannot even complete itself when applied to an actual machine. What's the point of using MDT if it does not behave like it does in the VM test environment?

    Would love to know what I am missing or doing wrong here - because I may as well just have run the DVD inside Windows and done this in-place the old fashioned way.

    Hope someone has some insight here.

    Cheers,

    Bruce

    Thursday, December 28, 2017 4:30 AM