none
Trying to deploy an upgraded Win10 image failing because MDT runs as SYSTEM account instead of Administrator RRS feed

  • Question

  • Starting with windows 1607, you can actually run sysprep on an upgraded Windows 10 install. (https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview) This is a welcome change since we'll be seeing new Windows 10 versions twice a year.

    However, it doesn't seem to actually work. (Update: It doesn't work at least for my deploy/upgrade/capture task sequences - I've got evidence now that it works in at least one manual upgrade case. So there's a chance it is something specific to my sequences.) I've taken a 1607 original image, created a reference image from it, upgraded it to 1703, and then created a reference image from that. All of this works great. But then when I deploy the image, after the image is applied and we boot into the new OS, I get this prompt:

    "Cannot find c:\ltibootstrap.vbs"

    I started digging, and the first sign that something is going wrong is that the task sequence is not running as Administrator like it usually does. Instead it is running as SYSTEM. (I put in a task sequence step that just writes the name of the current user to a file on disk to discover this.)

    If I start with a 1703 image and apply the same sequence of steps (minus the upgrade to 1703), everything works just fine on deployment. So it does really seem that it is the upgrade that is causing the problems.

    Any ideas on why the task sequence starts running as SYSTEM? I know there were initial issues with 1703 and admin autologin, but I still see this issue even if I update to the latest cumulative update for 1703 (which fixes these issues) before recapturing.


    • Edited by aggieNick02again Sunday, August 13, 2017 12:24 AM update after trying more things to narrow down problem
    Saturday, August 12, 2017 3:46 AM

Answers

  • It really is the setupcomplete.cmd that needs to go. I promise. :-) I've got a good bit of time in the MDT codebase under my belt now and can readily admit when I don't fully understand something, but I'm absolutely certain on this one. A simple step in your capture sequence to run the following command after the "Configure" step in "Capture Image" should fix things when you later deploy the image:

    cmd /c "del /q /f c:\Windows\Setup\Scripts\setupcomplete.cmd"

    Keith has a high reputation and he offers a lot of helpful advice, and there are a few different things that can lead to the c:\ltibootstrap.vbs missing error. But in this case the problem being encountered is a fairly new one. (The windows inplace upgrade sequence is, I believe, unique to upgrading to Windows 10, and capturing an upgraded OS was not supported until quite recently). His diagnosis in this case is not accurate.


    • Proposed as answer by the1rickster Thursday, September 7, 2017 6:33 PM
    • Marked as answer by aggieNick02again Friday, September 8, 2017 2:02 PM
    Thursday, September 7, 2017 3:06 AM

All replies

  • Whatever the root cause is, I now know it is not as simple as "upgrade plus sysprep equals deployment failure". Just taking a 1607 image and manually updating to 1703 then capturing and deploying that works fine. Which means it is either something in the upgrade script from MDT, or something specific in one of my deploy/upgrade/capture sequences.

    I'll play with it more and see what I can narrow it down to, starting with just vanilla task sequences. In the meantime if anyone has any guesses on what might lead to SYSTEM running LiteTouch.vbs instead of Administrator, I'm all ears. :-)

    Sunday, August 13, 2017 12:22 AM
  • Digging more, it appears to be a problem with MDT/Windows deployment, and not with my task sequences. I created two VMs (MDT_Ref and MDT_Deploy) and four vanilla task sequences from scratch. The first three sequences run on MDT_Ref and install vanilla Win 1607, upgrade it to 1703, and then sysprep/capture. The fourth sequence runs on MDT_Deploy and just deploys the captured wim.

    The end result is a similar (but slightly different) "cannot find script file" on first logon.

    The really interesting bit is that when this problem happens, in the deployed image, the following registry key exists and is set to 1:

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SystemAutoLogon

    I imagine that key does is at the root of the problem. I've no idea why it is being set. It is not present in the captured image. It doesn't exist if I deploy 1607 or if I deploy a manually upgraded (via Windows Update) 1703. There is almost nothing about the key on google.

    Thursday, August 17, 2017 11:23 PM
  • I figured out what was going on.

    The MDT Upgrade task sequence invokes the upgrade with the command line /postoobe option pointing to setupcomplete.cmd. This causes the file to be copied to c:\windows\setup\scripts\setupcomplete.cmd. When windows install is complete, if a file is present at that location, it is run under the SYSTEM account.

    The problem is that this file remains even after the upgrade task sequence is totally complete. So if you then capture the image and deploy it to a real machine, it will see setupcomplete.cmd and run it after the deploy, instead of using the usual default Administrator account.

    I imagine the presence of this file at c:\windows\... is what causes the registry changes mentioned above. setupcomplete.cmd is only built to bootstrap an upgrade back into the MDT task sequence, and needs to be removed from c:\windows\... when the task sequence is done running.

    Knowing that the post-upgrade portion of the upgrade task-sequence runs as SYSTEM instead of Administrator via a very different mechanism than standard deployment is important, as there are then limits to what you can do. By default the sequence lets you install applications.. they need to be apps that are ok being installed by SYSTEM.

    For now I've updated my local SetupComplete.cmd in my scripts directory to delete itself when it is done by changing the last for loop to this (there was also a typo in the for loop before preventing the exit echo):

    for %%d in (c d e f g h i j k l m n o p q r s t u v w x y z) do if exist %%d:\Windows\Setup\Scripts\setupcomplete.cmd ( 
    del /q /f %%d:\Windows\Setup\Scripts\setupcomplete.cmd
    echo %DATE%-%TIME% Exiting SetupComplete.cmd >> %WINDIR%\Temp\setupcomplete.log)

    Friday, August 18, 2017 11:27 PM
  • After thinking about this more and hitting issues due to running as the SYSTEM account, I started playing with avoiding running as the SYSTEM account. (One big problem is that if you want to shutdown at the end of the task sequence right after a reboot occurs, SYSTEM starts running too fast, and the call to shutdown in MDT fails.)

    The idea is to instead use SetupComplete.cmd running as SYSTEM to simply bootstrap back into running the task sequence as the default Administrator.

    There are a few wrinkles to implementing this. Namely, the synchronous commands that run from unattend.xml during a normal install do not run, so things like enabling admin, disabling uac for admin, disable user account page, disable async run once all have to be invoked manually. Beyond that, it is just a matter of setting the right registry entries by calls to PopulateAutoAdminLogon and SetStartMDT via a step in the task sequence after the OS upgrade is complete, and then performing a restart. This seems to work pretty well. The ideal way to do this would be to have the same script that calls PopulateAutoAdminLogon/SetStartMDT also parse unattend.xml and run those commands.

    For some reason shell hiding does not work even though everything is set for it. My best guess is that the task sequence runner is doing this because IsOSUpgrade is set, but am not sure.

    With this approach, SetupComplete.cmd is just responsible for a single bootstrap back into the task sequence, and the task sequence can delete it at the same time that it calls a script to do PopulateAutoAdminLogon/SetStartMDT

    There is enough work to be done to fully polish this approach that I'll just workaround the one autologin issue for now, but it really does feel like a better way for MDT to work when doing upgrades. Hopefully they'll flesh it out in the future.


    Thursday, August 24, 2017 8:07 PM
  • Discovered that my edit to SetupComplete.cmd is not sufficient. If you want to finish your task sequence with a shutdown, it means that SetupComplete.cmd will still be present and not removed until the next time you boot your machine. This may be minor in some cases, but causes a problem for me.

    So I've moved to a manual step at the end of the task sequence to remove SetupComplete.cmd, and moved the cleanup code from SetupComplete.cmd to this new manual step.

    Friday, August 25, 2017 7:00 PM
  • When MDT performs a capture, it leaves some leftover components behind (it can't clean everything).

    This is a super long thread, but your original problem: "Cannot find c:\ltibootstrap.vbs" is caused by the c:\windows\panther\unattend.xml file being left behind.

    You are *SUPPOSED* to use the image captured by MDT in a MDT Litetouch or SCCM Deployment. BOth of these deployment methods will inject their own unattend.xml file, overriding this left over file. 

    Summary: MDT is working as designed. 


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, September 5, 2017 5:28 AM
    Moderator
  • I realize the thread is long. It contains my debugging steps as I worked through this off and on over a couple weeks.

    In other scenarios the error I'm seeing may caused by unattend.xml being left behind. But that is absolutely not what is going on here. I am using the image captured by MDT in an MDT LiteTouch; MDT is *NOT* working correctly. There is a bug in the MDT upgrade OS task sequence/approach.

    The tl;dr is that doing a MDT upgrade OS step incorrectly leaves behind c:\windows\setup\scripts\setupcomplete.cmd. When you later do a regular deploy of an image that contains this file, it results in the MDT task sequence running/finishing as SYSTEM instead of Administrator, post LTIApply. Then when the Administrator account logs in for the first time, it tries to run c:\ltibootstrap.vbs (as it should) to continue the task sequence post LTIApply. But the file is missing since the upgrade OS step left setupcomplete.cmd behind, causing the deploy task sequence to finish executing under the SYSTEM account.

    Tuesday, September 5, 2017 2:15 PM
  • I would like to add a comment to this, Keith. In my scenario, I have several VM's I created in Hyper-V and then Captured in MDT as WIM files.

    After I upgraded MDT/ADK, I created an upgrade TS which upgraded my VM to 1703 from 1607.

    I then Captured that upgraded VM to MDT to create a WIM, all within MDT.

    I, too, see the same message, C:\LTIBootstrap.vbs

    Is there something I need to clean off of my upgraded VM before I capture it? Honestly, I don't know what the script does. Just to test my progress with 1703, I deleted the Run Sync in OOBE where it references it, which gives no error now. But, I assume I need that to run....so any help about getting it set up properly would be very helpful
    Thanks

    Wednesday, September 6, 2017 11:07 PM
  • You need to make sure to delete "c:\windows\setup\scripts\setupcomplete.cmd" before doing a capture. The upgrade process should not be leaving that file around, but it does.

    The quick/easy fix is to manually remove the file, or add removing that file as a run command step in your capture task sequence.

    Hopefully Microsoft will address this bug in the next MDT release so we don't have to hack around it.

    (There are other ways to fix it too - since the issue is with upgrade OS I prefer not to modify my capture sequence to compensate; I've settled on modifying setupcomplete.cmd in my deployment share and having a step towards the end of upgrade os that removes it appropriately.)

    Wednesday, September 6, 2017 11:28 PM
  • Is it the

    setupcomplete.cmd file or

    c:\windows\panther\unattend.xml

    being left behind that needs to be deleted? Technet is great for solutions, but it all depends on who you ask. Each person offers a different solution as the solution. Maybe I should delete them both from my VM prior to capture. I'm not sure now.

    Thursday, September 7, 2017 1:35 AM
  • It really is the setupcomplete.cmd that needs to go. I promise. :-) I've got a good bit of time in the MDT codebase under my belt now and can readily admit when I don't fully understand something, but I'm absolutely certain on this one. A simple step in your capture sequence to run the following command after the "Configure" step in "Capture Image" should fix things when you later deploy the image:

    cmd /c "del /q /f c:\Windows\Setup\Scripts\setupcomplete.cmd"

    Keith has a high reputation and he offers a lot of helpful advice, and there are a few different things that can lead to the c:\ltibootstrap.vbs missing error. But in this case the problem being encountered is a fairly new one. (The windows inplace upgrade sequence is, I believe, unique to upgrading to Windows 10, and capturing an upgraded OS was not supported until quite recently). His diagnosis in this case is not accurate.


    • Proposed as answer by the1rickster Thursday, September 7, 2017 6:33 PM
    • Marked as answer by aggieNick02again Friday, September 8, 2017 2:02 PM
    Thursday, September 7, 2017 3:06 AM
  • I should add you definitely don't want to be playing with manually removing unattend.xml behind the back of the MDT process. It takes care of generating/modifying/cleaning that file up. Keith was referencing scenarios where folks try to deploy a captured image through a mechanism other than MDT, which can be problematic, but is not what we are dealing with here.
    Thursday, September 7, 2017 3:09 AM
  • I did recapture my VM. I had upgraded it from 1607 to 1703 via an upgrade TS I made in MDT.
    Looking at the VM, I did see the setupcomplete file and removed it. I then went back into the unattend and re-added the step in 7, First Sync which was the cscript for the vbs file. I don't see that error anymore.
    I feel confident having that step in there, rather than just omitting it, which I see people all over the web doing.
    Thanks
    Thursday, September 7, 2017 6:32 PM
  • Glad that worked. :-)

    I definitely saw a lot of the same stuff you referenced (attempts to modify unattend.xml) when I initially googled the symptoms I was seeing, and you definitely don't want an unattend.xml that doesn't reference ltibootstrap.vbs, so it's good you have it back to normal. That bit of unattend.xml is what keeps the task sequence running after the OS is installed in a deployment task sequence.


    Thursday, September 7, 2017 6:49 PM